軟件測試環境的搭建在軟件測試項目中至關重要，其中應注意的問題也是不少，本文重點介紹在測試過程中應注意的幾個問題，希望能給讀者以啟迪。
01提交一份優秀的問題報告單
軟件測試提交的問題報告單和測試日報一樣，都是軟件測試人員的工作輸出，是測試人員績效的集中體現。因此，提交一份優秀的問題報告單是很重要的。
缺陷報告單中最關鍵的幾個部分：第一部分是發現缺陷的環境，包括軟件環境、硬件環境等；第二部分是缺陷的基本描述；第三部分是開發人員對缺陷的解決方法。通過對上述缺陷報告單的三個部分進行仔細分析，從中掌握了軟件產品最常見的基本問題，並吸收了其它軟件測試人員的工作經驗。
最關鍵的域就是 “ 問題描述 ” ，這是開發人員重現問題，定位問題的依據。問題描述應該包括以下幾部分內容：軟件配置、硬件配置、測試用例輸入、操作步驟、輸出、當時輸出設備的相關輸出信息和相關的日誌等。
軟件配置： 包括操作系統類型版本和補丁版本、當前被測試軟件的版本和補丁版本、相關支撐軟件，比如數據庫軟件的版本和補丁版本等。
硬件配置： 計算機的配置情況，主要包括 CPU 、內存和硬盤的相關參數，其它硬件參數根據測試用例的實際情況添加。如果測試中使用網絡，那麼網絡的組網情況，網絡的容量、流量等情況。硬件配置情況與被測試產品類型密切相關，需要根據當時的情況，準確翔實的記錄硬件配置情況。
測試用例輸入 操作步驟 輸出： 這部分內容可以根據測試用例的描述和測試用例的實際執行情況如實填寫。
輸出設備的相關輸出信息： 輸出設備包括計算機顯示器、打印機、磁帶等等輸出設備，如果是顯示器可以採用抓屏的方式獲取當時的截圖也可以錄製視頻，其他的輸出設備可以採用其它方法獲取相關的輸出，在問題報告單中提供描述。
日誌信息： 規範的軟件產品都會提供軟件的運行日誌和用戶、管理員的操作日誌，測試人員應該把測試用例執行後的軟件產品運行日誌和操作日誌作為附件，提交到問題報告單中。
測試結果分析
軟件測試執行結束後，測試活動還沒有結束。測試結果分析是必不可少的重要環節， “ 編筐編簍，全在收口 ” ，測試結果的分析對下一輪測試工作的開展有很大的借鑑意義。前面的 “ 測試準備工作 ” 中，建議測試人員走讀缺陷跟蹤庫，查閱其他測試人員發現的軟件缺陷。
測試結束後，也應該分析自己發現的軟件缺陷，對發現的缺陷分類，你會發現自己提交的問題只有固定的幾個類別；然後，再把一起完成測試執行工作的其他測試人員發現的問題也彙總起來，你會發現，你所提交問題的類別與他們有差異。這很正常，人的思維是有侷限性，在測試的過程中，每個測試人員都有自己思考問題的盲區和測試執行的盲區，有效的自我分析和分析其他測試人員，你會發現自己的盲區，有針對性的分析盲區，必定會在下一輪測試用避免盲區。
搭建軟件測試環境時與開發的關係處理
測試用例執行過程中，搭建測試環境是第一步。一般來說，軟件產品提交測試後，開發人員應該提交一份產品安裝指導書，在指導書中詳細指明軟件產品運行的軟硬件環境，比如要求操作系統系統是 Windows 2000 pack4 版本，數據庫是 Sql Server 2000 等等。此外，應該給出被測試軟件產品的詳細安裝指導書，包括安裝的操作步驟、相關配置文件的配置方法等等。對於複雜的軟件產品，尤其是軟件項目，如果沒有安裝指導書作為參考，在搭建測試環境過程中會遇到種種問題。
如果開發人員拒絕提供相關的安裝指導書，搭建測試中遇到問題的時候，測試人員可以要求開發人員協助，這時候，一定要把開發人員解決問題的方法記錄下來，避免同樣的問題再次請教開發人員，這樣會招致開發人員的反感，也降低了開發人員對測試人員的認可程度。
02全方位的觀察測試用例執行結果
測試執行過程中，當測試的實際輸出結果與測試用例中的預期輸出結果一致的時候，是否可以認為測試用例執行成功了？答案是否定的，即便實際測試結果與測試的預期結果一致，也要查看軟件產品的操作日誌、系統運行日誌和系統資源使用情況，來判斷測試用例是否執行成功了。全方位觀察軟件產品的輸出可以發現很多隱蔽的問題。
以前，我在測試嵌入式系統軟件的時候，執行某測試用例後，測試用例的實際輸出與預期輸出完全一致，不過在查詢 CPU 佔用率地時候，發現 CPU 佔用率高達 90 ％，後來經過分析，軟件運行的時候啟動了若干個 1ms 的定時器，大量的消耗的 CPU 資源，後來通過把定時器調整到 10ms ， CPU 的佔用率降為 7 ％。如果觀察點單一，這個嚴重消耗資源的問題就無從發現了。
03加強測試過程記錄
測試執行過程中，一定要加強測試過程記錄。如果測試執行步驟與測試用例中描述的有差異，一定要記錄下來，作為日後更新測試用例的依據；如果軟件產品提供了日誌功能，比如有軟件運行日誌、用戶操作日誌，一定在每個測試用例執行後記錄相關的日誌文件，作為測試過程記錄，一旦日後發現問題，開發人員可以通過這些測試記錄方便的定位問題。而不用測試人員重新搭建測試環境，為開發人員重現問題。
04及時確認發現的問題
測試執行過程中，如果確認發現了軟件的缺陷，那麼可以毫不猶豫的提交問題報告單。如果發現了可疑問題，又無法定位是否為軟件缺陷，那麼一定要保留現場，然後知會相關開發人員到現場定位問題。
如果開發人員在短時間內可以確認是否為軟件缺陷，測試人員給予配合；如果開發人員定位問題需要花費很長的時間，測試人員千萬不要因此耽誤自己寶貴的測試執行時間，可以讓開發人員記錄重現問題的測試環境配置，然後，回到自己的開發環境上重現問題，繼續定位問題。
05提交缺陷時與開發的關係處理
測試執行過程中，當你提交了問題報告單，可能被開發人員無情駁回，拒絕修改。這時候，只能對開發人員曉之以理，做到有理、有據，有說服力。
首先，要定義軟件缺陷的標準原則，這個原則應該是開發人員和測試人員都認可的，如果沒有共同認可的原則，那麼開發人員與測試人員對問題的爭執就不可避免了。
此外，測試人員打算說服開發人員之前，考慮是否能夠先說服自己，在保證可以說服自己的前提下，再開始與開發人員交流。
06及時更新測試用例
測試執行過程中，應該注意及時更新測試用例。
往往在測試執行過程中，才發現遺漏了一些測試用例，這時候應該及時的補充；往往也會發現有些測試用例在具體的執行過程中根本無法操作，這時候應該刪除這部分用例；也會發現若干個冗餘的測試用例完全可以由某一個測試用例替代，那麼刪除冗餘的測試用例。
總之，測試執行的過程中及時地更新測試用例是很好的習慣。不要打算在測試執行結束後，統一更新測試用例，如果這樣，往往會遺漏很多本應該更新的測試用例。
閱讀更多 說說軟件測試那些事兒 的文章
