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