四、是執行失敗的用例要鏈接到相應的缺陷報告，如有根據缺陷報告檢索測試用例的試圖更妙，可評估該缺陷影響范圍的大小
五、是測試用例的修改，以及每個測試周期的運行都有日志記錄，以便后期追蹤和新員工參考
4) 軟件測試階段，測試負責人劃分不同的測試階段(如集成測試、系統測試、回歸測試、性能測試等)，再劃分不同的子測試周期(如前兩個星期做冒煙測試，測試方式是手工/自動，測試版本是**，測試環境是**，包括服務器端與客戶端等;接著做第一模塊功能測試;如此順次。)，再為項目組測試人員分配測試用例(通常原則是每個人負責幾塊區域的測試任務)，測試人員則按照詳細的用例文檔去執行測試，測試失敗則提交軟件缺陷報告。這里要遵循的幾個原則是：
A)有健全且嚴格的體制保證測試執行者嚴格按照測試用例執行測試。這并不妨礙測試者創造力的發揮，因為前期用例的設計和編寫就是項目全體測試人員智慧的結晶!我們一直苦苦追尋眾多測試工程師加班加點辛苦工作的原因，其實大都發生這一階段;如此實施，即便沒有解決根本問題，也會大大提高測試執行效率。
B)如有對測試用例認識模糊或內容遺漏的地方，可暫做記錄待后期解決，或經測試負責人與項目其他管理人員同意方可更新用例庫。
C)測試負責人每日負責跟蹤本測試子周期或階段的測試用例執行情況，以及每日提交的缺陷報告，根據執行進展狀態以及缺陷數量或嚴重等級與項目高層或其他人員展開交流，商議解決途徑，并確定或調整未來時間的測試任務。
D)測試執行者負責執行自己區域的測試用例，還要負責跟蹤該區域軟件缺陷的修改進展，根據其狀態不斷驗證軟件功能點。
E)應該提及的是，大多數軟件公司都采用集成的缺陷管理工具來管理軟件缺陷，如IBM Rational ClearQuest(變更管理與缺陷管理工具)等，這是值得稱頌的好跡象;這樣的集成工具都提供了清晰的報告模版及強大的追蹤功能，測試團隊的每一成員按照自己的角色和權限訪問缺陷管理工具，并不斷跟蹤軟件缺陷的狀態。
F)對于自動測試(包括自動化功能測試和性能、壓力測試)，有一些特殊要點。本人的原則是自動化測試無須編寫測試用例，只要在編寫時將用例庫里適合或需要自動測試的用例的測試方法(不同工具可能名稱不同)設為自動即可，故而到此階段才提及自動化測試。自動化測試的實施方案有所不同，每款測試工具的使用和測試流程也不同，但都可以從在這一階段編寫測試腳本，并運行自動測試。例如IBM Rational Robot或XDE Tester(http://www-900.ibm.com/cn/software/rational/products/xde_tester/index.shtml，現更名為Rational Functional Tester)。針對自動化測試原則，可參閱筆者的"自動化測試要點"譯文，這里要提的其他幾個基本原則是：
一、是選擇恰當的測試工具品牌，并要求提供培訓;
二、是項目的自動化測試工作有專人負責跟蹤，以保證工作質量，他們可不參與日常測試;
三、是確定自動化測試成員在項目中的角色，一般自動化測試成員隸屬于項目測試負責人，負責人同樣跟蹤其工作狀態;
四、是選擇最簡單、最重用的測試用例使用自動測試方法;
五、是使用工具廠商提供的測試框架編寫腳本，千萬別采用單純錄制-加校驗點-回放的方式，以開發出健壯且重用性強的測試腳本;
六、是有專人更新腳本，也有專人跟蹤自動測試結果;
七、是一般選擇的測試工具品牌和缺陷管理工具品牌是同一廠商，以方便不同類型缺陷的集中管理;
八、是在多人協作開發測試腳本、代碼量相對較大情況下，應考慮使用配置管理工具來管理測試腳本，IBM Rational ClearCase是當前業界功能最強大的配置管理工具，可以將開發代碼和測試代碼都集中管理，進行高效的版本控制和工作空間管理，保證多人開發大量代碼的穩定性。對于局域網范圍內的開發工作，使用ClearCase LT版足夠。 由于不同公司開發產品的特殊性，也許需要特殊類型的測試，如安全測試、甚至代碼級單元測試等，這些內容需要酌情考慮測試用例的編寫，以及測試的執行。
5) 軟件驗收階段，除了提交軟件測試評估報告(各種類型測試結果的評估都應有報告)這些基本工作外，對于測試用例，此時要集中時間更新，更新整個測試周期中一切需要更新的內容，以方便未來新版本的測試。即便您開發的是項目軟件--提交客戶后沒有新版本--那也需要后期維護，維護階段需要重新測試某功能點，然而用例如果不準確，碰巧又是一個新員工來做，那就死翹翹了! 退一步說，如果您公司的測試部門經歷一次這樣重大的洗禮，有一個項目真正按照此原則實施一次，也必將對未來測試工作的開展發揮推波助瀾的作用、起到事半功倍的效果。
6) 其他說明：加強測試部門內部人員的培訓教育很重要，包括工作技能與個人素質兩方面，可通過國內主要的培訓機構，也可是購買工具廠商的直接培訓。應該說，很多測試新人對于測試用例的書寫還存在問題，更別提及測試用例的管理或執行;以此可見，我們的測試工程師需要培訓的空間還很大。
另外，筆者不贊成對人員的強制性管理，例如大張旗鼓整頓公司測試部門的管理，采取缺陷報告數和人員績效掛鉤、不按測試規范執行就適當懲罰等手段;個人認為切不可急功近利，當以人為本，鼓勵+促進甚善然、甚妙哉!
文章來源于領測軟件測試網 http://www.kjueaiud.com/
