軟件測試,從零開始:測試新手入門必讀(3)

　　o 加強測試用例的評審

　　測試用例設計完畢后，最好能夠增加評審過程。同行評審是 CMM3 級的一個 KPA ，如果因為公司沒有通過 CMM3 級，就不開展同行評審是不恰當的。測試用例應該由產品相關的軟件測試人員和軟件開發人員評審，提交評審意見，然后根據評審意見更新測試用例。 如果認真操作這個環節，測試用例中的很多問題都會暴露出來，比如用例設計錯誤、用例設計遺漏、用例設計冗余、用例設計不充分等等;如果同行評審不充分，那么，在測試執行的過程中，上述本應在評審階段發現的測試用例相關問題，會給測試執行帶來大麻煩，甚至導致測試執行掛起。

　　o 定義測試用例的執行順序

　　在測試用例執行過程中，你會發現每個測試用例都對測試環境有特殊的要求，或者對測試環境有特殊的影響。因此，定義測試用例的執行順序，對測試的執行效率影響非常大。比如某些異常測試用例會導致服務器頻繁重新啟動，服務器的每次重新啟動都會消耗大量的時間，導致這部分測試用例執行也消耗很多的時間。那么在編排測試用例執行順序的時候，應該考慮把這部分測試用例放在最后執行，如果在測試進度很緊張的情況下，如果優先執行這部分消耗時間的異常測試用例，那么在測試執行時間過了大半的時候，測試用例執行的進度依然是緩慢的，這會影響到測試人員的心情，進而導致匆忙地測試后面的測試用例，這樣測試用例的漏測、誤測就不可避免，嚴重影響了軟件測試效果和進度。因而，合理地定義測試用例的執行順序是很有必要的。

　　o 測試用例執行

　　測試用例設計完畢后，接下來的工作是測試執行，測試執行中應該注意以下幾個問題：

　　o 搭建軟件測試環境，執行測試用例

　　測試用例執行過程中，搭建測試環境是第一步。一般來說，軟件產品提交測試后，開發人員應該提交一份產品安裝指導書，在指導書中詳細指明軟件產品運行的軟硬件環境，比如要求操作系統系統是 Windows 2000 pack4 版本，數據庫是 Sql Server 2000 等等，此外，應該給出被測試軟件產品的詳細安裝指導書，包括安裝的操作步驟、相關配置文件的配置方法等等。對于復雜的軟件產品，尤其是軟件項目，如果沒有安裝指導書作為參考，在搭建測試環境過程中會遇到種種問題。

　　如果開發人員拒絕提供相關的安裝指導書，搭建測試中遇到問題的時候，測試人員可以要求開發人員協助，這時候，一定要把開發人員解決問題的方法記錄下來，避免同樣的問題再次請教開發人員，這樣會招致開發人員的反感，也降低了開發人員對測試人員的認可程度。

　　o 測試執行過程應注意的問題

　　測試環境搭建之后，根據定義的測試用例執行順序，逐個執行測試用例。在測試執行中需要注意以下幾個問題：

　　全方位的觀察測試用例執行結果： 測試執行過程中，當測試的實際輸出結果與測試用例中的預期輸出結果一致的時候，是否可以認為測試用例執行成功了?答案是否定的，即便實際測試結果與測試的預期結果一致，也要查看軟件產品的操作日志、系統運行日志和系統資源使用情況，來判斷測試用例是否執行成功了。全方位觀察軟件產品的輸出可以發現很多隱蔽的問題。以前，我在測試嵌入式系統軟件的時候，執行某測試用例后，測試用例的實際輸出與預期輸出完全一致，不過在查詢 CPU 占用率地時候，發現 CPU 占用率高達 90 %，后來經過分析，軟件運行的時候啟動了若干個 1ms 的定時器，大量的消耗的 CPU 資源，后來通過把定時器調整到 10ms ， CPU 的占用率降為 7 %。如果觀察點單一，這個嚴重消耗資源的問題就無從發現了。

　　加強測試過程記錄： 測試執行過程中，一定要加強測試過程記錄。如果測試執行步驟與測試用例中描述的有差異，一定要記錄下來，作為日后更新測試用例的依據;如果軟件產品提供了日志功能，比如有軟件運行日志、用戶操作日志，一定在每個測試用例執行后記錄相關的日志文件，作為測試過程記錄，一旦日后發現問題，開發人員可以通過這些測試記錄方便的定位問題。而不用測試人員重新搭建測試環境，為開發人員重現問題。

　　及時確認發現的問題： 測試執行過程中，如果確認發現了軟件的缺陷，那么可以毫不猶豫的提交問題報告單。如果發現了可疑問題，又無法定位是否為軟件缺陷，那么一定要保留現場，然后知會相關開發人員到現場定位問題。如果開發人員在短時間內可以確認是否為軟件缺陷，測試人員給予配合;如果開發人員定位問題需要花費很長的時間，測試人員千萬不要因此耽誤自己寶貴的測試執行時間，可以讓開發人員記錄重新問題的測試環境配置，然后，回到自己的開發環境上重現問題，繼續定位問題。

　　與開發人員良好的溝通： 測試執行過程中，當你提交了問題報告單，可能被開發人員無情駁回，拒絕修改。這時候，只能對開發人員曉之以理，做到有理、有據，有說服力。首先，要定義軟件缺陷的標準原則，這個原則應該是開發人員和測試人員都認可的，如果沒有共同認可的原則，那么開發人員與測試人員對問題的爭執就不可避免了。此外，測試人員打算說服開發人員之前，考慮是否能夠先說服自己，在保證可以說服自己的前提下，再開始與開發人員交流。

　　o 及時更新測試用例

　　測試執行過程中，應該注意及時更新測試用例。往往在測試執行過程中，才發現遺漏了一些測試用例，這時候應該及時的補充;往往也會發現有些測試用例在具體的執行過程中根本無法操作，這時候應該刪除這部分用例;也會發現若干個冗余的測試用例完全可以由某一個測試用例替代，那么刪除冗余的測試用例。

　　總之，測試執行的過程中及時地更新測試用例是很好的習慣。不要打算在測試執行結束后，統一更新測試用例，如果這樣，往往會遺漏很多本應該更新的測試用例。

　　o 提交一份優秀的問題報告單

　　軟件測試提交的問題報告單和測試日報一樣，都是軟件測試人員的工作輸出，是測試人員績效的集中體現。因此，提交一份優秀的問題報告單是很重要的。軟件測試報告單最關鍵的域就是 " 問題描述 " ，這是開發人員重現問題，定位問題的依據。問題描述應該包括以下幾部分內容：軟件配置、硬件配置、測試用例輸入、操作步驟、輸出、當時輸出設備的相關輸出信息和相關的日志等。

原文轉自：http://www.anti-gravitydesign.com