以上的第10行表明，查詢精確地匹配上了一條日志(總命中量為1)，并在第13行開始是查詢響應，實際的日志消息在第18行開始的。

那么，我們可以使用我們的選擇工具，將這些搜索結果輸入到我們的數據庫中查詢測試，以解析JSON的響應并且確定事件是否發生了。

例如，測試用例的基本Ruby實現(你也可以在GitHub上找到它)：

require 'json'

2

3 file = open("Database_prequery_search.json")

4 prequery = JSON.parse(file.read)

5

6 file = open("Database_postquery_search.json")

7 postquery = JSON.parse(file.read)

8

9 file = open("Database_connectionfailed_search.json")

10 connectionfailed = JSON.parse(file.read)

11

12 expected_prequery_event ?= (prequery["hits"]["total"] == 1)

13 expected_postquery_event = (postquery["hits"]["total"] == 1)

14 unexpected_connectionfailed_event = (connectionfailed["hits"]["total"] == 0)

15

16 expected_prequery_event && expected_postquery_event && unexpected_connectionfailed_event

我們使用'json' Ruby gem包去解析查詢前后的curl搜索結果，這些結果是我們先前保存在重命名后的文件中的(前10行)。第12行到第14行說明了我們對測試結果的預期(即日志流中應該包含一個單一的DatabasePreQuery事件，一個單一的DatabasePostQuery事件，并且沒有DatabaseConnectionFailed或其他事件)。最后一行是實際的測試(如果我們的期望都是正確的Ruby將返回“ture”，否則就會返回false)。

更復雜的測試(或對事件的分析)可能，比如說，需要在給定時間內搜索所有數據庫事件、計算查詢次數、故障等。然而，使用的方法和上面描述的是一樣的，只是在一個較大的JSON響應包中要執行稍微復雜的迭代代碼。

這是一個對這類測試進行curl查詢的例子(你也可以在GitHub找到它)：

$ curl -XGET 'http://localhost:9200/_search?q=message:Database*&pretty' -d '

{

"query" : {

"range" : {

"@timestamp" : {

"gte" : "now-10m/m"

}

}

}

}'

我們也可以在系統中跟蹤一條單一的執行路徑，使用當活動最初被啟動時我們注入系統的相關的ID：比如，用戶點擊一個按鈕或一個批量作業開始。只要關聯ID對于我們在日志聚合工具中的搜索是能夠保證唯一的，我們將看到只與該查詢有關的結果。

通過搜索關聯ID，我們就可以精確地確定到底是哪些服務器或容器參與了請求的處理和重建請求的過程。有一些商業工具能提供這樣的功能，但通過我們自己建立這些功能中的一部分功能，我們也可以獲得對系統運行情況的有益見解。

測試日志的用戶故事

比如說，我們有一個關于法律市場的基于瀏覽器的系統，這個系統允許專業的法律從業者來編輯和保存文檔。將文檔數據保存到文檔存儲數據庫，并將消息放在消息隊列上。然而，作為一個國家的監管制度的一部分，我們需要確保該文件符合一定的要求，所以需要提供“審計”服務監聽消息隊列上的消息，然后檢查最近更新過的文檔：

在這里，我們已經有了一個異步的、分布式的系統。當在瀏覽器中應用程序明確地顯示了成功——該文檔已經成功更新時，可能實際上還需要啟動進一步的工作流程(例如，如果文檔審計發現了文件的問題)。

通過使用事件ID和事務跟蹤的日志聚合功能，我們就有能力斷言，基于在主要事務系統中的某些操作，某些特定的日志消息應該出現在日志聚合系統之中：

具體來說，如果我們知道，審計服務應以事件ID“AuditRecordCreated”寫一條日志信息，我們在Web應用程序的用戶搜索完成后，就可以運行一個測試來尋找那個ID：

有了這個能力去斷言我們對系統的行為的期望之后，我們可以寫出類似這樣的行為水平測試：

Given I run a scenario as a Lawyer

And I create a document

[And I wait 5 seconds]

When I search the logs API

Then I should find a recent entry for “AuditRecordCreated”

這意味著，日志記錄已經成為了一種可以擴展我們對分布式系統的測試的方式，只要能夠明確在某些具體時刻我們期望哪些行為或事件會被記錄下來，然后再去搜索就好了。

結論

對分布式的、可擴展的系統(通常包含不穩定的基礎設施)進行故障排除，取決于是否有足夠的日志記錄和搜索設備。我們需要記錄發生在我們的系統中的重要的事件，并通過一個唯一的關聯ID將它們關聯到一個特定的業務交易(如包裹快遞)上。日志聚合和搜索工具使我們能夠用一個簡單的ID查詢來跟蹤終端到終端的業務交易。我們也可以查詢一個類別的事件以調查組件或系統故障(例如，為了找到導致某次故障的所有的數據庫事件)。最后，我們看到，我們可以而且我們也應該以與功能需求類似的方式來測試這些操作需求，即通過用戶故事和BDD的場景。

22/2<12

總結

以上是生活随笔為你收集整理的软件测试日志怎么写,为什么要进行日志测试和如何进行日志测试？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。