測試用例的執行能被跟蹤起來。
在碰到嚴重錯誤的時候,日志的信息可以幫助找到引起問題的模塊或代碼。
在一些模塊接口計算的區域,日志文件包含的模塊ID、數據可以幫助找出這些接口的錯誤。
在找到Bug之后,測試人員把Bug描述連同格式化的日志信息發給開發人員,有助于開發人員定位和調試問題發生的根源。例如下面的日志信息:
Function: main (main.cpp, line 100)
Machine: testsrvr (PID=2201)
Timestamp: 8/6/2009 20:26:54.721
Message: connecting to database [dbserver1, customer_db]
Function: main (main.cpp, line 125)
Machine: testsrvr (PID=2201)
Timestamp: 8/6/2009 20:26:56.153
Message: successfully connected to database
[dbserver1, customer_db]
Function: retrieveCustomer (customer.cpp line 20)
Machine: testsrvr (PID=2201)
Timestamp: 8/6/2009 20:26:56.568
Message: attempting to retrieve customer record for customer ID [A1000723]
Function: retrieveCustomer (customer.cpp line 25)
Machine: testsrvr (PID=2201)
Timestamp: 8/6/2009 20:26:57.12
Message: ERROR: failed to retrieve customer record, message [customer record for ID A1000723 not found]
從日志中可以看到,應用程序按照測試用例的執行過程,不能取到指定的顧客記錄。
在這種情況下,測試員應該檢查dbserver1數據庫,使用SQL查詢工具查詢customer_db數據庫中ID為A1000723的記錄,來驗證數據是否存在。確認是Bug之后,連同日志信息一起發送給開發人員,而不僅僅包含Bug的現象。這些日志信息對于開發人員定位問題的本質有重要的作用,可以減少問題分析和定位、調試的時間。
(2)GUI和接口測試的建議
錄制回放型的測試工具通過腳本語言記錄測試工程師在程序界面上的操作,然后通過回放來做一些基本的驗證。由于需要與GUI打交道,任何GUI的細微變化都可能引起腳本回放的失敗。因此,如果是基于位圖的錄制,則要注意下面幾個方面:
控件的字體不要隨便改動。
界面的顏色不要隨便改動。
顯示的設置需要保持不變。
如果可能,應該保持操作系統的標準設置。
開發人員在做界面層的修改之前,需要考慮到界面的修改對自動化測試腳本的影響,尤其是在界面基線已經建立起來之后,需要慎重考慮GUI的修改。
GUI測試工具通常是基于對象的屬性來識別對象的,因此開發人員最好能知道GUI測試工具的工作原理,這樣可以在修改GUI時盡量避免對自動化測試腳本造成的影響。
3、小結
為了避免掉入那些主要的自動化測試陷阱,R&D應該在開發過程中把測試這個“T”也考慮進去,而不僅僅考慮那些最新最酷的開發技術。如果發明并使用了最新最好的技術,但是不能被充分測試或者很難被測試到,那么我們如何知道它們的質量水平呢?!
測試自動化是個很關鍵的技術,在開發軟件的過程中,程序員需要把測試效果和可測試性等因素考慮進去。并且,還應該明白修改GUI的內容對于自動化測試腳本的影響。