軟件項目，通常都會有詳細(xì)的項目計劃。
軟件測試作為整個項目中的重要一環(huán)，也要執(zhí)行詳細(xì)的測試計劃。正所謂運(yùn)籌帷幄之中，決勝千里之外，強(qiáng)調(diào)的就是預(yù)先計劃的重要性和必要性。 在早期的軟件工程實(shí)踐中，軟件測試計劃的制定通常是在需求分析以及測試需求分析完成后開始，并且是整個軟件研發(fā)生命周期中的重要環(huán)節(jié)。 但是，在敏捷開發(fā)模式下，你可能會有這樣的疑問，軟件測試計劃還有那么重要嗎？我所在的軟件項目壓根兒就沒有正式的測試計劃，不也沒出什么大問題嗎？ 的確，對于很多非產(chǎn)品型的互聯(lián)網(wǎng)公司，由于采用了敏捷開發(fā)模式，的確很少去制定傳統(tǒng)意義上的測試計劃了，但這并不是說它們就不再制定測試計劃了。 只不過是，測試計劃的表現(xiàn)形式已經(jīng)不再是傳統(tǒng)意義上龐大的、正式的測試計劃文檔了，而更多的是體現(xiàn)在每個迭代（sprint）的計劃環(huán)節(jié)，而且這樣的短期測試計劃可以非常迅速地根據(jù)項目情況實(shí)時調(diào)整。 所以說，測試計劃依舊存在，只是從原來的一次性集中制定測試計劃，變成了以迭代的方式持續(xù)制定測試計劃。 但是對于傳統(tǒng)軟件企業(yè)，或者是做非互聯(lián)網(wǎng)軟件產(chǎn)品的企業(yè)，它們通常還是會有非常正式的軟件測試計劃。 由此可見，無論對于早期最具典型性的瀑布開發(fā)模型，還是現(xiàn)在的敏捷開發(fā)模型，測試計劃的重要性始終沒有發(fā)生變化。那么，你可能會問，測試計劃的重要性到底體現(xiàn)在哪些方面呢？在回答這個問題之前，我先跟你聊聊如果沒有測試計劃會帶來什么問題。沒有測試計劃會怎么樣？ 如果沒有測試計劃，會帶來哪些問題呢？ 1. 很難確切地知道具體的測試范圍，以及應(yīng)該采取的具體測試策略； 2. 很難預(yù)估具體的工作量和所需要的測試工程師數(shù)量，同時還會造成各個測試工程師的分工不明確，引發(fā)某些測試工作被重復(fù)執(zhí)行而有些測試則被遺漏的問題； 3. 測試的整體進(jìn)度完全不可控，甚至很難確切知道目前測試的完成情況，對于測試完成時間就更難預(yù)估準(zhǔn)確的時間節(jié)點(diǎn)了, 4. 整個項目對潛在風(fēng)險的抵抗能力很弱，很難應(yīng)對需求的變更以及其他突發(fā)事件。 從這些問題中，你可以逆向思維推導(dǎo)出，一份好的測試計劃要包括：測試范圍、測試策略、測試資源、測試進(jìn)度和測試風(fēng)險預(yù)估，這五大方面，并且每一部分都要給出應(yīng)對可能出現(xiàn)問題的解決辦法。測試范圍，顧名思義，測試范圍描述的是被測對象以及主要的測試內(nèi)容。 比如，對于用戶登錄模塊，功能測試既需要測試瀏覽器端又需要測試移動端，同時還考慮登錄的安全和并發(fā)性能相關(guān)的非功能性需求的測試等。 測試范圍的確定通常是在測試需求分析完成后進(jìn)行，所以確定測試范圍的過程在一定程度上也是對測試需求分析的進(jìn)一步檢驗(yàn)，這將有助于在早期階段就發(fā)現(xiàn)潛在的測試遺漏。 同時，由于不可能進(jìn)行窮盡測試，而且測試的時間和資源都是有限的，所以必須有所取舍，進(jìn)行有針對性的測試。因此，測試范圍中需要明確“測什么”和“不測什么”。 測試策略的話題，測試策略簡單來講就是需要明確“先測什么后測什么”和“如何來測”這兩個問題。病有輕重緩急，測試也是一樣的道理，重要的項先測，而不重要的項要后測。測試策略會要求我們明確測試的重點(diǎn)，以及各項測試的先后順序。 比如，對用戶登錄模塊來講，“用戶無法正常登錄”和“用戶無法重置密碼”這兩個潛在問題，對業(yè)務(wù)的影響孰輕孰重一目了然，所以，你應(yīng)該按照優(yōu)先級來先測“用戶正常登錄”，再測“用戶重置密碼”。 測試策略還需要說明，采用什么樣的測試類型和測試方法。 這里需要注意的是，不僅要給出為什么要選用這個測試類型，還要詳細(xì)說明具體的實(shí)施方法。 第一，功能測試 對于功能測試，你應(yīng)該根據(jù)測試需求分析的思維導(dǎo)圖來設(shè)計測試用例。 主線業(yè)務(wù)的功能測試由于經(jīng)常需要執(zhí)行回歸測試，所以你需要考慮實(shí)施自動化測試，并且根據(jù)項目技術(shù)棧和測試團(tuán)隊成員的習(xí)慣與能力來選擇合適的自動化測試框架。 這里需要注意的是，你通常應(yīng)該先實(shí)現(xiàn)主干業(yè)務(wù)流程的測試自動化。 實(shí)際操作時，你通常需要先列出主要的功能測試點(diǎn)，并決定哪些測試點(diǎn)適合采用自動化測試，并且決定具體使用什么樣的框架和技術(shù)。 對于需要手工測試的測試點(diǎn)，你要決定采用什么類型的測試用例設(shè)計方法，以及如何準(zhǔn)備相關(guān)的測試數(shù)據(jù)。 另外，你還要評估被測軟件的可測試性，如果有可測試性的問題，需要提前考慮切實(shí)可行的變通方案，甚至要求開發(fā)人員提供可測試性的接口。 第二，兼容性測試 對于兼容性測試來說，Web測試需要確定覆蓋的瀏覽器類型和版本，移動設(shè)備測試需要確定覆蓋的設(shè)備類型和具體iOS/Android的版本等。 你可能會問，我要怎么確定需要覆蓋的移動設(shè)備類型以及iOS/Android的版本列表呢？這個問題其實(shí)并不難： 如果是既有產(chǎn)品，你可以通過大數(shù)據(jù)技術(shù)分析產(chǎn)品的歷史數(shù)據(jù)得出Top 30%的移動設(shè)備以 及iOS/Android的版本列表，那么兼容性測試只需覆蓋這部分即可。 如果是一個全新的產(chǎn)品，你可以通過TalkingData這樣的網(wǎng)站來查看目前主流的移動設(shè)備，分辨率大 小、iOS/Android版本等信息來確定測試范圍。 兼容性測試的實(shí)施，往往是在功能測試的后期，也就是說需要等功能基本都穩(wěn)定了，才會開始兼容性測試。 當(dāng)然也有特例，比如，對于前端引入了新的前端框架或者組件庫，往往就會先在前期做兼容性評估，以確保不會引入后期無法解決的兼容性問題。 兼容性測試用例的選取，往往來自于已經(jīng)實(shí)現(xiàn)的自動化測試用例。道理很簡單，因?yàn)榧嫒菪詼y試往往要覆蓋最常用的業(yè)務(wù)場景，而這些最常用的業(yè)務(wù)場景通常也是首批實(shí)現(xiàn)自動化測試的目標(biāo)。 所以，我們的GUI自動化框架，就需要能夠支持同一套測試腳本在不做修改的前提下，運(yùn)行于不同的瀏覽器。 第三，性能測試 對于性能測試，需要在明確了性能需求（并發(fā)用戶數(shù)、響應(yīng)時間、事務(wù)吞吐量等）的前提下，結(jié)合被測系統(tǒng)的特點(diǎn)，設(shè)計性能測試場景并確定性能測試框架。 比如，是直接在API級別發(fā)起壓力測試，還是必須模擬終端用戶行為進(jìn)行基于協(xié)議的壓力測試。再比 如，是基于模塊進(jìn)行壓力測試，還是發(fā)起全鏈路壓測。 如果性能是背景數(shù)據(jù)敏感的場景，還需要確定背景數(shù)據(jù)量級與分布，并決定產(chǎn)生背景數(shù)據(jù)的技術(shù)方案，比如是通過API并發(fā)調(diào)用來產(chǎn)生測試數(shù)據(jù)，還是直接在數(shù)據(jù)庫上做批量insert和update操作，或者是兩種方式的結(jié)合。 最后，無論采用哪種方式，都需要明確待開發(fā)的單用戶腳本的數(shù)量，以便后續(xù)能夠順利組裝壓測測試場景。 性能測試的實(shí)施，是一個比較復(fù)雜的問題。首先，需要根據(jù)你想要解決的問題，確定性能測試的類型；然后，根據(jù)具體的性能測試類型開展測試。
性能測試的實(shí)施，往往先要根據(jù)業(yè)務(wù)場景來決定需要開發(fā)哪些單用戶腳本，腳本的開發(fā)會涉及到很多性能測試腳本特有的概念，比如思考時間、集合點(diǎn)、動態(tài)關(guān)聯(lián)等等。
2. 腳本開發(fā)完成后，你還要以腳本為單位組織測試場景（Scenario），場景定義簡單來說就是百分之多少的用戶在做登錄、百分之多少的用戶在做查詢、每個用戶的操作步驟之間需要等待多少時間、 并發(fā)用戶的增速是5秒一個，還是5秒2個等等。 3. 最后，才是具體的測試場景執(zhí)行。和自動化功能測試不同，性能測試執(zhí)行完成后性能測試報告的解讀，是整個測試過程中最關(guān)鍵的點(diǎn)。 如果你現(xiàn)在不太清楚我上面提到的一些概念也沒關(guān)系，我會在后續(xù)的文章中為你詳細(xì)講解。 除了我給你詳細(xì)分析的、最常用的功能測試、兼容性測試和性能測試外，還有很多測試類型（比如，接口測試、集成測試、安全測試、容量驗(yàn)證、安裝測試、故障恢復(fù)測試等）。這些測試類型，都有各自的 應(yīng)用場景，也相應(yīng)有獨(dú)特的測試方法，在這里我就不再一一展開了，如果你有關(guān)于這些測試類型的問題，可以給我留言討論。 測試資源通常包括測試人員和測試環(huán)境，這兩類資源都是有限的。測試計劃的目的就是，保證在有限資源下的產(chǎn)出最大化。所以，測試資源就是需要明確“誰來測”和“在哪里測”這兩個問題。 測試人員是最重要的，直接關(guān)系到整個測試項目的成敗和效率。測試人員的資源通常有兩個維度：一是，測試工程師的數(shù)量；二是，測試工程師的個人經(jīng)驗(yàn)和能力。 你會發(fā)現(xiàn)，測試工程師的經(jīng)驗(yàn)和能力不足，很難通過測試人員的數(shù)量來彌補(bǔ)。相反地，測試工程師的經(jīng)驗(yàn)和能力都非常強(qiáng)的情況下，測試人員的數(shù)量可以適當(dāng)?shù)販p少。 通常在測試團(tuán)隊中，測試工程師既有資深，也會有初級，那么你就必須針對團(tuán)隊的實(shí)際情況去安排測試計劃。比如，難度較大的工作，或者一些新工具、新方法的應(yīng)用，又或者自動化測試開發(fā)工作，通常由資深的測試工程師來承擔(dān)；而那些相對機(jī)械性、難度較小的工作，則由初級工程師完成。 可見，你要想規(guī)劃好測試資源，除了要了解項目本身外，還必須對測試團(tuán)隊的人員特點(diǎn)有清晰的把控。另外，我強(qiáng)烈建議你把具體的任務(wù)清晰地落實(shí)到每個人的身上，這將有利于建立清晰的責(zé)任機(jī)制，避免 后續(xù)可能發(fā)生的扯皮。 相對于測試人員，測試環(huán)境就比較好理解了。不同的項目，可能會使用共享的測試環(huán)境，也可能使用專用的測試環(huán)境，甚至還會直接使用生產(chǎn)環(huán)境。另外，對于目前一些已經(jīng)實(shí)現(xiàn)容器化部署與發(fā)布的項目， 測試環(huán)境就會變得更簡單與輕量級，這部分內(nèi)容我會在后續(xù)的文章中給你詳細(xì)講解。 測試進(jìn)度，在明確了測試范圍、測試策略和測試資源之后，你就要考慮具體的測試進(jìn)度了。測試進(jìn)度主要描述各類測試的開始時間，所需工作量，預(yù)計完成時間，并以此為依據(jù)來建議最終產(chǎn)品的上線發(fā)布時間。 比如，版本接受測試（Build Acceptance Test）的工作量，冒煙測試（Smoke Test）的工作量，自動化腳本開發(fā)的工作量，缺陷修復(fù)的驗(yàn)證工作量，需要幾輪回歸測試、每一輪回歸測試的工作量等等。 在傳統(tǒng)瀑布模型中，測試進(jìn)度完全依賴于開發(fā)完成并遞交測試版本的時間。如果開發(fā)提交測試版本發(fā)生了延誤，那么在不裁剪測試需求的情況下，產(chǎn)品整體的上線時間就同樣會延期。 然而在敏捷模式下，測試活動貫穿于整個開發(fā)過程，很多測試工作會和開發(fā)工作同步進(jìn)行，比如采用行為驅(qū)動開發(fā)（Behavior-Driven Development）模式，這樣測試進(jìn)度就不會完全依賴于開發(fā)遞交可測試版本的時間。 行為驅(qū)動開發(fā)，就是平時我們經(jīng)常說的BDD，指的是可以通過自然語言書寫非程序員可讀的測試用例，并通過StepDef來關(guān)聯(lián)基于自然語言的步驟描述和具體的業(yè)務(wù)操作，最典型的框架就是知 名“Cucumber”。 測試風(fēng)險預(yù)估，俗話說，計劃趕不上變化，對于測試也是一樣的道理，很少有整個測試過程是完全按照原本測試計劃執(zhí)行的。通常需求變更、開發(fā)延期、發(fā)現(xiàn)重大缺陷和人員變動是引入項目測試風(fēng)險的主要原因。 對于需求變更，比如增加需求、刪減需求、修改需求等，一定要重新進(jìn)行測試需求分析，確定變更后的測試范圍和資源評估，并與項目經(jīng)理和產(chǎn)品經(jīng)理及時溝通因此引起的測試進(jìn)度變化。測試經(jīng)理/測試負(fù)責(zé)人切忌不能有自己咬牙扛過去的想法，否則無論是對測試團(tuán)隊還是對產(chǎn)品本身都不會有任何好處。 另外，隨著測試的開展，你可能會發(fā)現(xiàn)前期對于測試工作量的預(yù)估不夠準(zhǔn)確，也可能發(fā)現(xiàn)需要增加更多的測試類型，也可能發(fā)現(xiàn)因?yàn)橐薷臏y試架構(gòu)的嚴(yán)重缺陷而導(dǎo)致很多的測試需要全回歸，還有可能出現(xiàn)開發(fā)遞交測試版本延期，或者人員變動等各種情況。 所以，在制定測試計劃時，你就要預(yù)估整個測試過程中可能存在的潛在風(fēng)險，以及當(dāng)這些風(fēng)險發(fā)生時的應(yīng)對策略。 那么，在真的遇到類似問題時，你才可以做到心中不慌，有條不紊地應(yīng)對這些挑戰(zhàn)。 總結(jié) 軟件測試同軟件項目一樣，也要制定詳細(xì)的測試計劃。雖然在敏捷開發(fā)模式下，軟件測試不再局限于厚重的、正式的計劃文檔，但是測試計劃的重要性絲毫沒有發(fā)生變化。 一份成功的測試計劃，必須清楚地描述：測試范圍、測試策略、測試資源、測試進(jìn)度和測試風(fēng)險預(yù)估這五個最重要的方面。 測試范圍需要明確“測什么”和“不測什么”；測試策略需要明確“先測什么后測什么”和“如何來測”；測試資源需要明確“誰來測”和“在哪里測”；測試進(jìn)度是需要明確各類測試的開始時間，所需工作量和預(yù)計完成 時間；測試風(fēng)險預(yù)估是需要明確如何有效應(yīng)對各種潛在的變化。
聯(lián)系客服
