摘要：測試用例說明書分成覆蓋各個業務流程和預期的輸入輸出，前者這個有助于與客戶溝通，挖掘需求；后者有助于與開發人員的溝通，提高編寫符合要求的代碼。
正文：測 試用例說明書，通常定義為對一項特定的軟件產品進行測試任務的描述，體現測試方案、方法、技術和策略。在軟件產品開發中用的非常多，但在項目開發中，重要 性進行經常被忽視，很多項目組都是不做的，或者是為了敷衍編寫的。敷衍是有很多原因的，各方不重視測試，需求多變導致測試層本大幅增加、項目時間節點緊， 因此很多測試過程會被簡化。很多項目組最后只會有下1-2個左右的測試人員，或者是開發人員做兼職測試，在編碼結束后，就上系統點點，然后提交客戶了；客 戶驗收也是同樣，驗收平臺搭建好后，走走流程，可能腦袋里面會想，怎么走流程可以把所有的流程都過一遍么，缺乏系統和專業的考慮。
軟件開發，肯定比不上產品開發了，項目的成本、項目結點都是擺在那里的，要說服客戶或者領導重視測試不是一朝一夕就能解決的。測試階段肯定要簡化的，但是測試用例說明書還是建議保留的，他的作用不是僅僅停留在測試的。
測試，第一要求的盡可能是測試覆蓋業務的所有流程，邏輯分支；第二是測試的依據，不管是覆蓋流程、分支還是覆蓋頁面，都歸集為預期輸入和預期結果，輸入后的結果不是預期的，就是有問題的。
做需求有兩個產物：需求規格說明書和頁面DEMO，這都是需求靜態的描述，你會發現很多客戶在項目編碼結束測試階段后會提出很多新增需求和需求變更，有 些程序員會抱怨客戶，其實這很大原因就是，靜態的需求描述和DEMO很難讓客戶的思維有所發揮，業務是動態的，做業務的客戶的邏輯性和構思不比專業做軟件 的，只有等軟件動態后才會想到真正的需求，誰都不希望最后一大堆改動，一堆人加班，一大堆風險。測試用例說明書能很好的彌補這個靜態的問題，測試用例的業 務流程覆蓋測試，動態的描述的業務操作步驟，而且在需求做完確認后就能編寫了，因此在需求階段就做完測試用例說明書，可以有效的改善提高需求設計的質量， 降低后期的需求變更。
上面的作用，是對客戶而言，對做需求而言的；而第二個作用是做開發人員而言的。編寫好的基本設計交給開發人員開 發，經常會出現最后完成的代碼不符合要求，問題可以歸咎為開發人員理解有問題或者溝通有問題；也會出現開發人員不負責任，提交的代碼問題未經自己測試，測 試的任務推卸給測試人員。問題出在哪里，能不能溝通更加準確，能不能讓開發人員更加負責？基本設計有顆粒度到頁面級別的，也有到API級別的，但是不管怎 么樣，都可以分成預期輸入和預期輸出，在做完基本設計后，根據基本設計的顆粒度，設計頁面或者API預期的輸入和預期的輸出后，就基本給開發人員定性，編 寫完成的代碼應該是怎么樣的了，這個預期都是測試用例，明確告知開發人員，編寫的代碼只有達到這個預期后才算完成，可以提交給測試人員測試。通常，開發人 員在明白了預期的輸入和輸出后，對要編寫的代碼理解就更加深刻了。
至于測試用例說明書如何寫，到底是怎么樣的顆粒度，這個我以后在整理，這篇只是說要它的價值所在和重要性。
軟件工程中明確寫過，測試用例說明書編寫在需求階段和設計階段，是經過無數項目的總結出來的，只是沒體會到而已，這只能說自身功力的問題。