測試用例設計步驟
測試用例就是一個文檔，描述輸入、動作、或者時間和一個期望的結果，其目的是確定應用程序的某個特性是否正常的工作。有哪些具體的列設計步驟可以關注的。小編給大家整理了關于測試用例設計流程，希望你們喜歡!
測試用例設計步驟
——從登陸開始說起
一個完整的software testing life cycle包括諸多內容，本文僅從測試用例的編寫開始，聊聊測試用例編寫的一般步驟，以使編寫的測試用例最大程度上滿足完備的要求，而又不產生重復而冗余的負擔。 測試用例的來源是產品需求，如果足夠幸運，我們應當有一份不錯的可依賴的Use Case文檔，但大部分情況下，Use Case恐怕是不存在，能有一份不錯的PRD文檔和原型設計圖已經是不錯的待遇了，如果可能的話，最好還能夠有HLD文檔，這些已經足夠我們開始寫詳細的測試用例文檔(我相信在這之前無法產出詳細的測試用例文檔①)。也許LLD文檔產生之后或者產品的第一個版本發布之后，我們會不斷的更新已有的測試用例，但那將是不斷的迭代過程，暫不做討論。
首先讓我們先從理論上了解測試用例編寫的一般步驟②：
1、確定測試套件(Test Suite)：測試套件是功能上的劃分，是相似測試場景的組合，而非技術劃分。如果技術設計中各模塊耦合度較高(強烈推薦解耦，哪怕復制粘貼代碼)，可能功能上不相干的模塊由于代碼重用的原因會在bug fix時互相引致錯誤，實際上回歸測試即是為了避免這種情況。但是我們在做功能測試劃分模塊時，還是要從用戶的角度出發，按照用戶場景劃分測試的“模塊”。值得慶幸的是，相似或相關的功能總是傾向于在同一組頁面出現，按鈕和輸入框、選擇菜單等內容并不是隨機組合的一堆零件。
2、針對每一個測試套件，確定一個或多個基本流程(basic flow)和可選流程(alternative flow)，即測試場景(Test Scenario)：可以借助scenario matrix來清晰地對可能出現的場景進行排列組合。值得注意的是，一方面Use Case或PRD文檔中的描述很有可能并沒有完整的寫盡所有的場景，測試人員盡可能地挖掘測試場景，既有可能是出于測試本身的需要，也可能是基于開發團隊的工作;另一方面，在復雜系統中，測試場景不可能覆蓋所有可能的場景，這便需要測試人員采用一定的測試策略③，對SUT(System under Testing)進行“足夠(adequate)”的測試，而不是完全的測試。
3、針對每一個測試場景，確定一到多個測試用例(Test Case)：仍然可以借助matrix來清晰地規劃測試用例，每一個測試用例都有其對應的預置條件④、輸入和期望結果。測試用例分為Positive Test Case和Negative Test Case兩種，分別用來測試產品是否完成應當完成的工作和不執行不應當完成的操作。更詳盡地說，測試用例一般包括以下列column：用例編號/測試場景/用例描述/需求對應/用例分類(Positive/Negative)/用例類型/用例級別/是否自動化/預置條件/測試步驟/測試數據/預期結果/實際結果/備注/
4、增加測試數據(Test Data)完成測試用例：測試數據是測試用例中很重要的內容，一個用例可能對應多套測試數據，測試工程師根據某種測試技術⑤，將盡可能的設計較少的測試數據完成“足夠”的測試。 任何規范、流程都是為了讓工作更加可靠，對于項目工程，天外飛仙靈機一動應當放在合適的位置，而不應當成為規范和流程的反例存在⑥。
現在讓我們開始從登陸(PC端網頁，如果是PC客戶端比如QQ或手機客戶端則又不同)開始說起。 不打開任何網站的登陸框，想象一下登陸框的樣子。
然后對照一下本文最后的附圖，一個優秀的登陸框除了基本的用戶名/密碼輸入框、登陸按鈕之外、(不考慮注冊、找回密碼、第三方登陸、登陸版本、幫助)，包含的內容有：輸入框文字提示/免登陸選項/輸入的表單提示(新浪微博)/必要的驗證碼(出錯時的處理)/用戶名和密碼輸入錯誤(正確)提示/焦點反饋/快速刪除已輸入字符/Tab切換/鼠標點擊有字符輸入框光標位置/Enter鍵選中/密碼非明文顯示/是否彈窗顯示(不要打斷正在處理的任務)/頁面跳轉/進度反饋(網絡較差的情況)/多賬戶登錄/多終端登錄/Cookie/token
最后值得強調的是，真正能夠保證產品質量的是開發人員而不是測試。在一個完整的軟件工程周期中，開發人員從建設的角度保證產品質量，測試人員從破壞的角度檢驗產品質量。如果在測試用例執行環節提交了成百上千的bug，即便最終每個bug都被修復，新產生的bug數量一直在收斂，這樣的軟件產品恐怕也不是讓人有足夠信心發布出去的產品。實際上，從經驗來看，總是有大量的bug被用戶發現，即使測試人員采用了單元、接口、自動化、Monkey等諸多手段進行測試，由于受限于測試場景、測試次數等因素，這種情況仍然是無法避免的。
讓測試人員在項目早期介入，與開發人員一起評審技術設計，是減少這種情況并從根源上提高產品質量的方法之一。但是需要指出的是，這只是理想化的假設。一是測試工程師缺乏項目經驗，測試開發與開發畢竟是兩種工作，評審技術設計有一定的難度;二是如果測試工程師有大量的項目經驗，很容易與開發人員從同樣的角度思考問題，這便偏離了初衷。
由此可見，成為一個優秀的測試工程師并不是一件容易的事情，既需要有專業的技術，又需要能夠從技術中抽身，從不同的角度考慮問題;既要有吹毛求疵的完美主義精神，又要能夠權衡效率，并對自己的選擇所可能產生的風險有所估量。運用之妙存乎一心，這實際上就是大量實踐中才能獲得的經驗了，無法詳述。
Notes：
①關于這種說法需要進一步關注Model-based Testing;另，Software Development Life Cycle(SDLC)是一個讓人眼花繚亂的概念，務虛，但又十分有用。
②這實際上是采用了自頂向下的設計方法
③測試策略：Traceability Matrix等，待完善
④我希望Test Cases成為一個池子，測試條件放在System Testing Specification文檔中來統一歸檔，該文檔中還應當包括測試環境等相關配置。除此之外，如果有Test Procedure，也使用另外的文檔用來管理。
⑤測試技術：等價類劃分、邊界值條件等
⑥敏捷、探索性測試待深入理解
測試用例設計結果分析
軟件測試執行結束后，測試活動還沒有結束。測試結果分析是必不可少的重要環節， “ 編筐編簍，全在收口 ” ，測試結果的分析對下一輪測試工作的開展有很大的借鑒意義。前面的 “ 測試準備工作 ” 中，建議測試人員走讀缺陷跟蹤庫，查閱其他測試人員發現的軟件缺陷。測試結束后，也應該分析自己發現的軟件缺陷，對發現的缺陷分類，你會發現自己提交的問題只有固定的幾個類別;然后，再把一起完成測試執行工作的其他測試人員發現的問題也匯總起來，你會發現，你所提交問題的類別與他們有差異。這很正常，人的思維是有局限性，在測試的過程中，每個測試人員都有自己思考問題的盲區和測試執行的盲區，有效的自我分析和分析其他測試人員，你會發現自己的盲區，有針對性的分析盲區，必定會在下一輪測試中避免盲區。
測試用例設計流程相關文章：
1.測試用例流程圖
測試用例設計步驟
