當然，如果希望可以進一步提高某個階段測試工作的效率，還可以考慮應用“設計測試過程”的方法。這里所說的測試過程，指的是我們在執行測試時所設定的執行測試用例的先后順序。之所以這樣作，是因為可以充分的利用不同功能之間的耦合性，盡量通過一次操作來檢查盡量多的內容，從而降低已完成工作的無效性或低效性，最終提高某個階段的整體工作效率。不過，這項工作同樣要求操作者必須對被測的系統所涉及的所有業務以及這些業務之間的關系都非常熟悉才行。
如果您正被測試工作的低效問題所困擾，那么建議您嘗試一下上面的方法，希望會對您的工作有所幫助。
如何評價測試用例的好壞?
這部分內容的出現，完全是因為不久前同幾個朋友的一次討論。當時大家都認為對于一個測試用例好壞的評價，無外乎兩個標準：是否可以發現尚未發現的軟件缺陷?是否可以覆蓋全部的測試需求?但是后來發現這兩個標準對于一些問題是處理不了的。例如，對于一個質量非常好的軟件產品，存在的軟件缺陷異乎尋常的少，測試用例設計人員準備了大量的測試用例，已經完全覆蓋了測試需求，但是只有很少一部分測試用例在執行時發現了缺陷，而其他用例都順利通過了。那么是否就可以認為順利通過的那部分測試用例不好呢?
對于這個問題，筆者認為不管是測試用例是否可以發現尚未發現的缺陷，還是測試用例對測試需求的覆蓋度，都是用來評估測試設計人員工作能力和經驗的標準，而對于如何評價測試用例的優劣，應該還有其他標準。當然，在不同的團隊中可能存在不同的標準，但下面兩條應該是適合于任何團隊的。
1.易用性。對于一個即熟悉測試工作，又熟悉被測應用的測試人員，應當可以花費
很少的時間就可以理解測試用例中表達的測試思路，并可以很快的執行完這個測試用例。
2.易維護性。當開發過程中的某些因素影響了測試需求，測試用例的作者或其他測試設
計人員，應該可以花費很少的時間就完成定位并維護所有相關測試用例的工作。
一些題外話
曾經有朋友問：如果測試用例同軟件的具體實現互相獨立，怎么保證測試用例的可操作性呢?怎么保證任何一個人都可以一拿到測試用例就可以直接上機執行測試呢?筆者的回答是：盡量不要讓這種事情發生。
首先，筆者一直不贊同那種讓“任何人”都可以充當測試人員，按照手中測試用例執行測試的做法。因為對于被測應用的全面了解和熟悉，是作為一個測試人員最基本的要求——在前面的文字中對于軟件需求的熟悉也多次被強調。我們無法預知讓一個對軟件以及軟件所涉及的實際業務不夠熟悉的人，依靠一份他同樣不熟悉的操作步驟列表來執行測試會有什么樣的結果。但是有一點可以明確，這就好像讓一個沒有醫學背景的人，僅僅依靠一本七年制本碩連讀的《內科學》教材來為患者檢查是否患有心臟病，最終結果是患者承擔了全部的風險。
其次，測試用例的本來目的是為了描述我們的“測試思想”——也就是“怎樣測”，而是否可以熟練的操作被測應用，并不是在測試用例這個“對象”中所要考慮和保證的，應當剝離出來，作為獨立的部分進行處理。而問題的關鍵，在于如何保證拿到測試用例的人有足夠的能力和經驗來執行測試，這完全可以通過公司內部對軟件及軟件所涉及的實際業務的培訓，或者軟件的操作手冊�？傊�，還是盡量不要隨意的加入“任何人”到測試工作中吧。
作者簡介
網絡ID ：jackei，長期活躍于“測試時代”、“中國軟件測試社區”、“51testing”、“51CMM”、“CSDN”等測試網站和測試論壇�！稖y試時代期刊》雜志責任編輯及撰稿人。
學院派測試人員，堅信“實踐是檢驗真理的唯一標準”。反對學術腐敗、造假。堅信做一個好的測試人員，首先要為人正直、誠實、嚴謹、耐心、樂于助人�，F供職于廣州某軟件公司，從事軟件測試工作，致力于測試過程改進和測試基礎理論方面的研究。
對于本文中已經包含的以及還未包含的內容，如果需要討論，您都可以使用E-Mail：jackei_chan@hotmail.com 同筆者聯系。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
