丨以終為始如何才能做好測(cè)試計(jì)劃

只不過(guò)是，測(cè)試計(jì)劃的表現(xiàn)形式已經(jīng)不再是傳統(tǒng)意義上龐大的、正式的測(cè)試計(jì)劃文檔了，而的是體現(xiàn)在每個(gè)迭代（sprint）的計(jì)劃環(huán)節(jié)，而且這樣的短期測(cè)試計(jì)劃可以非常迅速地根據(jù)項(xiàng)目情況實(shí)時(shí)調(diào)整。，計(jì)劃存在是從的集中測(cè)試，變以迭方式持續(xù)制定測(cè)試計(jì)劃。但是對(duì)于傳統(tǒng)軟件企業(yè)，或者是做非互聯(lián)網(wǎng)軟件產(chǎn)品的企業(yè)，它們通常還是會(huì)有非常正式的軟件測(cè)試計(jì)劃。從這些問(wèn)題中，你可以逆向思維推導(dǎo)出，一份好的測(cè)試計(jì)劃要包括：測(cè)試范圍、測(cè)試策略、測(cè)試資源、測(cè)試進(jìn)度和測(cè)試風(fēng)險(xiǎn)預(yù)估，這五大方面，并且每一部分都要給出應(yīng)對(duì)可能出現(xiàn)問(wèn)題的解決辦法。比如，對(duì)用戶登錄模塊來(lái)講，“用戶無(wú)法正常登錄”和用戶無(wú)法重置”這兩個(gè)潛在問(wèn)用戶重置。對(duì)于兼容性測(cè)試來(lái)說(shuō)，Web定覆蓋的設(shè)備類型和具體iOS/Android的版本等。iOS/AndroidTop30以及iOS/Android的版本列表，那么兼容性測(cè)試只需覆蓋這部分即可。如果是一個(gè)全新的產(chǎn)品，你可以通過(guò)TalkingData這樣的來(lái)查看目前主流的移動(dòng)設(shè)備，分辨率大小、iOS/Android版本等信息來(lái)確定測(cè)試范圍。兼容性測(cè)試用例的選取，往往來(lái)自于已經(jīng)實(shí)現(xiàn)的自動(dòng)化測(cè)試用例。道理很簡(jiǎn)單，因?yàn)榧嫒菪詼y(cè)試往往要覆蓋最常用的業(yè)務(wù)場(chǎng)景，而這些最常用的業(yè)務(wù)場(chǎng)景通常也是首批實(shí)現(xiàn)自動(dòng)化測(cè)試所以，我們的GUI自動(dòng)化框架，就需要能夠支持同一套測(cè)試在不做修改的前提下，運(yùn)對(duì)于性能測(cè)試，需要在明確了性能需求（并發(fā)用戶數(shù)、響應(yīng)時(shí)間、事務(wù)吞吐量等）下，結(jié)合被測(cè)系統(tǒng)的特點(diǎn)，設(shè)計(jì)性能測(cè)試場(chǎng)景并確定性能測(cè)試框架。API技術(shù)方案，比如是通過(guò)API并發(fā)調(diào)用來(lái)產(chǎn)生測(cè)試數(shù)據(jù)，還是直接在數(shù)據(jù)庫(kù)上做批量insert和update操作，或者是兩種方式的結(jié)合。性能測(cè)試的實(shí)施，往往先要根據(jù)業(yè)務(wù)場(chǎng)景來(lái)決定需要開發(fā)哪些單用戶，的發(fā)會(huì)涉及到很多性能測(cè)試特有的概念，比如思考時(shí)間、集合點(diǎn)、動(dòng)態(tài)關(guān)聯(lián)等等。開發(fā)完成后，你還要以為單位組織測(cè)試場(chǎng)景（ro），定單來(lái)說(shuō)就是百分之多少的用戶在做登錄、百分之多少的用戶在做查詢、每個(gè)用戶的操作步驟之間需要等待多少時(shí)間、并發(fā)用戶的增速是55秒2（比如，接口測(cè)試、集成測(cè)試、安全測(cè)試、容量驗(yàn)證、安裝測(cè)試、故障恢復(fù)測(cè)試等）測(cè)試類型，都有各自的應(yīng)用場(chǎng)景，也相應(yīng)有獨(dú)特的測(cè)試方法，在這里我就不再一一展開了，如果你有關(guān)于這些測(cè)試類型的問(wèn)題，可以給我留言討論。測(cè)試資源通常包括測(cè)試人員和測(cè)試環(huán)境，這兩類資源都是有限的。測(cè)試計(jì)劃的目的就是，保證在有限資源下的產(chǎn)出最大化。所以，測(cè)試資源就是需要明確“測(cè)”和“在哪里測(cè)”這兩個(gè)問(wèn)題。通常在測(cè)試團(tuán)隊(duì)中，測(cè)試工程師既有資深，也會(huì)有初級(jí)，那么你就必須針對(duì)團(tuán)隊(duì)的實(shí)際情況去安排測(cè)試計(jì)劃。比如，難度較大的工作，或者一些新工具、新方法的應(yīng)用，又或者自動(dòng)化測(cè)試開發(fā)工作，通常由資深的測(cè)試工程師來(lái)承擔(dān)；而那些相對(duì)機(jī)械性、難度較小的工作，則由初級(jí)工程師完成?？梢姡阋胍?guī)劃好測(cè)試資源，除了要了解項(xiàng)目本身外，還必須對(duì)測(cè)試團(tuán)隊(duì)的人員特點(diǎn)有清晰的把控。另外，我強(qiáng)烈建議你把具體的任務(wù)清晰地到每個(gè)人的身上，這將有利于建立清晰的責(zé)任機(jī)制，避免后續(xù)可能發(fā)生的扯皮。相對(duì)于測(cè)試人員，測(cè)試環(huán)境就比較好理解了。不同的項(xiàng)目，可能會(huì)使用共享的測(cè)試環(huán)境，也可能使用的測(cè)試環(huán)境，甚至還會(huì)直接使用生產(chǎn)環(huán)境。另外，對(duì)于目前一些已經(jīng)實(shí)現(xiàn)容器化部署與發(fā)布的項(xiàng)目，測(cè)試環(huán)境就會(huì)變得更簡(jiǎn)單與輕量級(jí)，這部分內(nèi)容我會(huì)在后續(xù)的文章中給你詳細(xì)講解。在明確了測(cè)試范圍、測(cè)試策略和測(cè)試資源之后，你就要考慮具體的測(cè)試進(jìn)度了。要描述各類測(cè)試的開始時(shí)間，所需工作量，預(yù)計(jì)完成時(shí)間，并以此為依據(jù)來(lái)建議最終產(chǎn)品的上線。比如，版本接受測(cè)試（BuildAcceptanceTest）的工作量，冒煙測(cè)試（SmokeTest）的r-rnopment模式，這樣測(cè)試進(jìn)度就不會(huì)完全依賴于開發(fā)遞交可測(cè)試版本的時(shí)間。行為驅(qū)動(dòng)開發(fā)，就是平時(shí)我們經(jīng)常說(shuō)的BDD，指的是可以通過(guò)自然語(yǔ)言書寫非程序員可讀的測(cè)試用例，并通過(guò)StepDef來(lái)關(guān)聯(lián)基于自然語(yǔ)言的步驟描述和具體的業(yè)務(wù)操作，最典型俗話說(shuō)，計(jì)劃趕不上變化，對(duì)于測(cè)試也是一樣的道理，很少有整個(gè)測(cè)試過(guò)程是完全按照原本測(cè)試計(jì)劃執(zhí)行的。通常需求變更、開發(fā)延期、發(fā)現(xiàn)重大缺陷和人員變動(dòng)是引入項(xiàng)目測(cè)試風(fēng)險(xiǎn)的主要原因。需求，比加需刪減、修求等定要進(jìn)需求，確/測(cè)試切忌不能有自己咬牙扛過(guò)去的想法，否則無(wú)論是對(duì)測(cè)試團(tuán)隊(duì)還是對(duì)產(chǎn)品本身都不會(huì)有任何好處。另外，隨著測(cè)試的開展，你可能會(huì)發(fā)現(xiàn)前期對(duì)于測(cè)試工作量的預(yù)估不夠準(zhǔn)確，也可能發(fā)現(xiàn)需要增加的測(cè)試類型，也可能發(fā)現(xiàn)因?yàn)橐薷臏y(cè)試架構(gòu)的嚴(yán)重缺陷而導(dǎo)致很多的測(cè)試需要全回歸，還有可能出現(xiàn)開發(fā)遞交測(cè)試版本延期，或者人員變動(dòng)等各種情況。那么，在真的遇到類似問(wèn)題時(shí)，你才可以做到心中不慌，有條不紊地應(yīng)對(duì)這些?！焙汀叭绾蝸?lái)測(cè)；測(cè)試資源需要明確“測(cè)”和在哪里”；測(cè)試進(jìn)度是需要明確各類測(cè)試的開始時(shí)間，所需工作量和預(yù)計(jì)完成時(shí)間；測(cè)試風(fēng)險(xiǎn)預(yù)估是需要明確如何有效應(yīng)對(duì)各種潛在的變化。 售賣。頁(yè)面已增加防盜追蹤，將依 其上一 07|如何高效填寫軟件缺陷報(bào)告下一 09|軟件測(cè)試工程師的競(jìng)爭(zhēng)力是什么言言 14余衫 作者回復(fù):非常同意你的觀點(diǎn)，這其實(shí)也是傳達(dá)的信息 10 口水 2小老 2做好測(cè)試計(jì)劃很多時(shí)候被風(fēng)險(xiǎn)給打亂，也就是不確定性打亂。周那最后的發(fā)布日期都定下來(lái)很可能就堆人，壓縮測(cè)試周期了天天向 1阿 秋 1 1