在車載項目開發過程中，測試是關鍵中關鍵的一環，包括供應商釋放每版軟件時的全量測試，也包括主機廠的驗收測試。那針對測試這塊，測試用例設計的規范一般是怎么樣呢？今天一起來探討一下。
首先是規范測試用例的背景是什么呢？主要有兩個維度，首先是為保證測試用例對需求的覆蓋率，第二個就是對單個功能點，主要驗證不同的輸入及其組合所帶來的各種輸入動作，系統輸出是否合理。
測試用例設計規范的目的是為測試用例的質量負責，使測試能有序、合理化的進行，從而提高實施測試時的測試質量。
那下面就來仔細聊聊測試用例設計的規范。首先是一條測試用例要包含哪些內容呢？
01. 編寫用例原則
在上面對整體測試規范的背景和目的簡單說明后，那先來看看測試用例編寫的原則，主要包括系統性，全面性，正確性，可操作性，下面挨個來聊聊。
系統性：要能完整的說明整個系統的業務需求、系統由幾個子系統組成以及間的關系；對模塊業務流程要說明子系統內部功能、重點功能以及之間的關系；
全面性：應盡可能覆蓋各種路徑、盡可能覆蓋各個業務點；
正確性：輸入界面后的數據應與測試文檔所記錄的數據一致，而預期結果也應與測試數據發生的業務吻合。
可操作性：測試用例中要寫清楚測試的操作步驟，以及不同的操作步驟相對應的測試結果。
02. 編寫用例標準
討論完測試用例的原則后，那用例實際應該怎么編寫呢，其標準是什么呢？首先測試用例編寫應該統一模板并約定模板的使用方法；其次測試用例編寫應當根據實際情況編寫測試用例編寫手冊，包括用例編號規則、編寫方法、維護等內容等；然后則是用例編寫應根據手冊中約定的編寫方法、內容等進行編寫，并且寫要明確步驟，輸入輸出要素清晰，并且與需求和缺陷相對應；最后按照用例編寫原來中全面性，用例編寫應嚴格根據需求及測試需求功能分析點進行，要求覆蓋全部需求功能點。
最后用例編寫要注重用例的可復用性，減少后續類似需求的測試設計工作量。
03. 用例設計步驟
在聊完用例原則和標準后，就要開始實操了，看用例設計的步驟了。
第一步是測試需求分析：從需求分析文檔中，找出待測的需求點，通過分析、理解，整理成為測試需求，要清楚被測對象具體包含哪些功能點。
第二步則是業務流程分析：首先要對業務知識要熟悉，然后對被功能需求要進行全盤的整理出來。
第三部則是測試用例設計：測試用例設計的類型主要包括功能測試、邊界測試、異常測試、性能測試、壓力測試等，在設計用例時要盡量考慮邊界、異常等情況。
第四部則是測試用例評審：由測試用例編寫者發起，參加的人員需包括測試負責人、項目經理、開發人員及其他相關的測試人員。
第五步則是測試用例完善：測試用例編寫完成之后需要不斷完善，包括功能需求迭代，或者是在軟件交付后客戶反饋的軟件缺陷，而缺陷又是因測試用例存在漏洞造成，也需要對測試用例進行完善。
04. 用例維護
測試用例編寫并不是一次性的工作，后續還需要定期的維護測試用例，為什么要維護呢？
刪除過時的測試用例
因為需求的改變等原因可能會使一個基線測試用例不再適合被測系統，那么這些測試用例就會過時，需要對這些測試用例進行及時的刪除。
修改測試用例
隨著項目的進展，測試需求可能會有部分變更，甚至大范圍的變更，這個時候就會根據需求的變化相應的對測試用例進行維護，修改已經不符合目前需求的內容，并備注加以說明。
刪除冗余的測試用例
如果存在兩個或更多測試用例對一組相同的輸入和輸入進行測試，則需要對其進行刪除，只需留下其中的一個。
增添新的測試用例
對新增的功能、在評審過程及測試過程中發現缺少測試用例或者系統出現BUG但是沒有與之對應的測試用例，需要按照測試用例的設計標準進行增添，增加測試用例時，需要在相應功能模塊的最下方插入新增的測試用例，并在備注欄中加以說明。
05. 用例設計方法
測試用例要包括欲測試的功能、應輸入的數據和預期的輸出結果。測試數據應該選用少量、高效的測試數據進行盡可能完備的測試；基本目標是：設計一組發現某個錯誤或某類錯誤的測試數據，測試用例應覆蓋方面：
等價劃分：將所有可能的輸入數據（有效的和無效的）劃分成若干個等價類。
邊界值分析法：確定邊界情況，針對系統在測試過程中主要輸入一些合法數據/非法數據，主要在邊界值附近選取。
場景法：通過運用場景來對系統的功能點或業務流程的描述，從而提高測試效果的一種方法。用例場景來測試需求是指模擬特定場景邊界發生的事情，通過事件來觸發某個動作的發生，觀察事件的最終結果，從而用來發現需求中存在的問題。
基本流：是經過用例的最簡單的路徑；
正確性測試：輸入用戶實際數據以驗證系統是滿足需求規格說明書的要求；測試用例中的測試點應首先保證要至少覆蓋需求規格說明書中的各項功能，并且正常。
健壯性測試：程序能夠接收正確數據輸入并且產生正確（預期）的輸出；輸入非法數據（非法類型、不符合要求的數據、溢出數據等），程序應能給出提示并進行相應處理。把自己想象成一名對產品操作一點也不懂的客戶，在進行任意操作。
完整性測試：對未經授權的人使用軟件系統或數據的企圖，系統能夠控制的程度，程序的數據處理能夠保持外部信息的完整。
接口間測試：測試各個模塊相互間的協調和通信情況，數據輸入輸出的一致性和正確性。
壓力測試：輸入10條記錄運行各個功能，輸入30條記錄運行，輸入50條記錄運行，進行測試。
錯誤推測：主要是根據測試經驗和直覺，參照以往的軟件系統出現錯誤之處。
效率：完成預定的功能，系統的運行時間。
可操作性：理解和使用該系統的難易程度（界面友好性）。
可移植性：在不同操作系統及硬件配置情況下的運行性。
回歸測試：按照測試用例將所有的測試點測試完畢，測試中發現的問題開發人員。
比較測試：將已經發版的類似產品或原有的老產品與測試的產品同時運行比較，或與已往的測試結果比較。
兼容性測試：操作系統的兼容性測試內容不僅包括軟件的安裝，還需對關鍵流程和功能點進行檢查。而需要測試哪些操作系統的兼容性，首先取決于軟件用戶文檔上對用戶的承諾，其次就需要對一些常用操作系統兼容的檢查
歷史版本兼容性測試：某些功能存在新版本和歷史版本數據顯示、頁面展示不一致的問題。需要不同版本進行測試。
06. 用例評審
在完成用例編寫后，就需要預約會議，對用例進行評審，為什么需要評審呢？主要是測試用例是軟件測試的原則，但由于軟件人員對在需求理解、設計等理解程度不同等因素的影響，首次產生的測試用例質量難以避免會有不同程度的差異，故對編寫的測試用例進行評審是很有必要的，其作用是測試用例的評審過程能夠起到用例結構清晰化、場景覆蓋全面化以及優先用例的合理化安排等。
評審的內容包括用例設計的結構安排是否清晰合理，是否高效的需求進行覆蓋用例的優先級別是否安排合理；是否覆蓋了測試需求的所有功能點，包括需求中的業務規則、所有用戶可能使用的流程或場景等；用例是否有很好的可執行性。例如用例的前提條件、執行步驟、輸入數據和期待結果是否清晰、正確；是否已經刪除了冗余的測試用例；是否包含充分的負面測試用例是否簡潔、復用性強、是否易于管理。
那評審過程是怎樣的呢？基于項目需求的測試計劃完成之后，進行初審，主要是對測試范圍和測試要點進行審查在測試用例的設計完成之后進行復審，主要是對測試用例的結構和覆蓋率進行評審所有測試用例結束后，主要是對測試用例的具體描述是否有很好的可執行性，是否有冗余用例的存在進行評審。
評審之后，經評審的用例由用例設計者根據評審的建議或意見進行修改，更新用例，再次發起評審、修改、更新用例，反復評審后，直至用例達到要求。
在用例經過用例評審后，則就可以排計劃讓測試人員安排測試了。包括建立測試計劃；建立對應的版本追溯；確認測試人員，測試報告輸出等。
轉自汽車ECU開發
