測試用例設計步驟

　　測試用例就是一個文件，描述輸入、動作、或者時間和一個期望的結果，其目的是確定應用程式的某個特性是否正常的工作。有哪些具體的列設計步驟可以關注的。小編給大家整理了關於測試用例設計流程，希望你們喜歡!

　　——從登陸開始說起

　　一個完整的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文件中的描述很有可能並沒有完整的寫盡所有的場景，測試人員儘可能地挖掘測試場景，既有可能是出於測試本身的需要，也可能是基於開發團隊的工作;另一方面，在複雜系統中，測試場景不可能覆蓋所有可能的場景，這便需要測試人員採用一定的測試策略③，對SUTSystem 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 CycleSDLC是一個讓人眼花繚亂的概念，務虛，但又十分有用。

　　②這實際上是採用了自頂向下的設計方法

　　③測試策略：Traceability Matrix等，待完善

　　④我希望Test Cases成為一個池子，測試條件放在System Testing Specification文件中來統一歸檔，該文件中還應當包括測試環境等相關配置。除此之外，如果有Test Procedure，也使用另外的文件用來管理。

　　⑤測試技術：等價類劃分、邊界值條件等

　　⑥敏捷、探索性測試待深入理解

　　測試用例設計結果分析

　　軟體測試執行結束後，測試活動還沒有結束。測試結果分析是必不可少的重要環節， “ 編筐編簍，全在收口 ” ，測試結果的分析對下一輪測試工作的開展有很大的借鑑意義。前面的 “ 測試準備工作 ” 中，建議測試人員走讀缺陷跟蹤庫，查閱其他測試人員發現的軟體缺陷。測試結束後，也應該分析自己發現的軟體缺陷，對發現的缺陷分類，你會發現自己提交的問題只有固定的幾個類別;然後，再把一起完成測試執行工作的其他測試人員發現的問題也彙總起來，你會發現，你所提交問題的類別與他們有差異。這很正常，人的思維是有侷限性，在測試的過程中，每個測試人員都有自己思考問題的盲區和測試執行的盲區，有效的自我分析和分析其他測試人員，你會發現自己的盲區，有針對性的分析盲區，必定會在下一輪測試中避免盲區。