測試用例說明書對客戶和開發人員的重要性

　　正文：測 試用例說明書，通常定義為對一項特定的軟體産品進行測試任務的描述，展現測試方案、方法、技術和政策。在軟體産品開發中用的非常多，但在項目開發中，重要 性進行經常被忽視，很多項目組都是不做的，或者是為了敷衍編寫的。敷衍是有很多原因的，各方不重視測試，需求多變導緻測試層本大幅增加、項目時間節點緊， 是以很多測試過程會被簡化。很多項目組最後隻會有下1-2個左右的測試人員，或者是開發人員做兼職測試，在編碼結束後，就上系統點點，然後送出客戶了；客 戶驗收也是同樣，驗收平台搭建好後，走走流程，可能腦袋裡面會想，怎麼走流程可以把所有的流程都過一遍麼，缺乏系統和專業的考慮。

　　測試，第一要求的盡可能是測試覆寫業務的所有流程，邏輯分支；第二是測試的依據，不管是覆寫流程、分支還是覆寫頁面，都歸集為預期輸入和預期結果，輸入後的結果不是預期的，就是有問題的。

　 　做需求有兩個産物：需求規格說明書和頁面demo，這都是需求靜态的描述，你會發現很多客戶在項目編碼結束測試階段後會提出很多新增需求和需求變更，有 些程式員會抱怨客戶，其實這很大原因就是，靜态的需求描述和demo很難讓客戶的思維有所發揮，業務是動态的，做業務的客戶的邏輯性和構思不比專業做軟體 的，隻有等軟體動态後才會想到真正的需求，誰都不希望最後一大堆改動，一堆人加班，一大堆風險。測試用例說明書能很好的彌補這個靜态的問題，測試用例的業 務流程覆寫測試，動态的描述的業務操作步驟，而且在需求做完确認後就能編寫了，是以在需求階段就做完測試用例說明書，可以有效的改善提高需求設計的品質， 降低後期的需求變更。

　　上面的作用，是對客戶而言，對做需求而言的；而第二個作用是做開發人員而言的。編寫好的基本設計交給開發人員開 發，經常會出現最後完成的代碼不符合要求，問題可以歸咎為開發人員了解有問題或者溝通有問題；也會出現開發人員不負責任，送出的代碼問題未經自己測試，測 試的任務推卸給測試人員。問題出在哪裡，能不能溝通更加準确，能不能讓開發人員更加負責？基本設計有顆粒度到頁面級别的，也有到api級别的，但是不管怎 麼樣，都可以分成預期輸入和預期輸出，在做完基本設計後，根據基本設計的顆粒度，設計頁面或者api預期的輸入和預期的輸出後，就基本給開發人員定性，編 寫完成的代碼應該是怎麼樣的了，這個預期都是測試用例，明确告知開發人員，編寫的代碼隻有達到這個預期後才算完成，可以送出給測試人員測試。通常，開發人 員在明白了預期的輸入和輸出後，對要編寫的代碼了解就更加深刻了。

　　至于測試用例說明書如何寫，到底是怎麼樣的顆粒度，這個我以後在整理，這篇隻是說要它的價值所在和重要性。

　　軟體工程中明确寫過，測試用例說明書編寫在需求階段和設計階段，是經過無數項目的總結出來的，隻是沒體會到而已，這隻能說自身功力的問題。

====================================分割線================================

最新内容請見作者的github頁：http://qaseven.github.io/