在敏捷項(xiàng)目的快速迭代中，QA要負(fù)責(zé)和推動多個(gè)質(zhì)量保障活動比如需求分析虱痕、過程改進(jìn)睹耐、風(fēng)險(xiǎn)管理、自動化測試開發(fā)維護(hù)和故事卡驗(yàn)收測試等部翘；其中留給故事卡驗(yàn)收測試的時(shí)間是有限甚至是緊迫的硝训，但是質(zhì)量要求卻一點(diǎn)也不能放松。

那么如何在敏捷快速迭代交付壓力下快速地進(jìn)行故事卡驗(yàn)收測試新思？由于故事卡驗(yàn)收測試中的測試設(shè)計(jì)是最花精力和時(shí)間的窖梁，所以這個(gè)問題又可以進(jìn)一步分解為下面兩個(gè)子問題：

1. 如何快速的進(jìn)行測試設(shè)計(jì)？
2. 如何設(shè)計(jì)出覆蓋率高的測試用例夹囚？

我們在分析解答這兩個(gè)問題之前纵刘，要強(qiáng)調(diào)一下進(jìn)行測試設(shè)計(jì)的前提：

1. 對產(chǎn)品(待測系統(tǒng))業(yè)務(wù)邏輯的充分了解 - 可以幫助QA從用戶角度進(jìn)行場景設(shè)計(jì)以及避免遺漏任何改動相關(guān)的功能

• 產(chǎn)品功能
• 產(chǎn)品平臺
• 產(chǎn)品接口
• 產(chǎn)品數(shù)據(jù)流
• 產(chǎn)品操作
• 產(chǎn)品用戶體驗(yàn)

2. 對產(chǎn)品(待測系統(tǒng))實(shí)現(xiàn)技術(shù)的充分了解 - 可以幫助QA了解實(shí)現(xiàn)細(xì)節(jié)來減少測試范圍

• 產(chǎn)品類型
  • WEB
  • Mobile
  • 桌面軟件
• 產(chǎn)品技術(shù)架構(gòu)
• 產(chǎn)品技術(shù)棧

如果上面的前提都不滿足的話，是很難設(shè)計(jì)出好的測試用例的荸哟。

現(xiàn)在我們來仔細(xì)分析上面提出的兩個(gè)問題

問題1： 如何快速的進(jìn)行測試設(shè)計(jì)彰导？

舍棄傳統(tǒng)測試設(shè)計(jì)方法，避免過度設(shè)計(jì)敲茄，采用思維導(dǎo)圖等方式進(jìn)行粗粒度的快速設(shè)計(jì)

在傳統(tǒng)的測試設(shè)計(jì)方法中位谋，QA需要依據(jù)需求文檔，進(jìn)行對應(yīng)功能的詳細(xì)的用例設(shè)計(jì)數(shù)據(jù)設(shè)計(jì)堰燎；然后把測試用例錄入到電子表格或是一些測試用例管理工具中比如Testlink掏父，QC等。類似這樣的工具都要求測試用例具有非常詳細(xì)的信息比如測試環(huán)境秆剪、測試步驟赊淑、測試數(shù)據(jù)測試期待結(jié)果爵政，于是QA會花大量的時(shí)間在測試用例的設(shè)計(jì)和編寫錄入上。

在敏捷項(xiàng)目中陶缺，我們提倡采用探索式測試來進(jìn)行手工驗(yàn)收測試钾挟。探索式測試是一種基于反饋的，邊設(shè)計(jì)邊執(zhí)行的測試方法饱岸，不會要求詳細(xì)的腳本化的測試用例掺出，只需要選定某種特殊的測試方法在產(chǎn)品上進(jìn)行深入的探索。所以苫费，QA們不會使用具體的測試用例管理工具去編寫詳細(xì)的測試用例汤锨，而是使用簡單的工具(例如思維導(dǎo)圖)記錄簡單的測試想法/測試功能點(diǎn)，在實(shí)際的測試執(zhí)行過程中百框，會針對某一個(gè)測試想法進(jìn)行探索式測試闲礼。 這些測試想法/測試功能點(diǎn)只需要描述清楚測試的功能點(diǎn)是什么，基本的用戶場景和數(shù)據(jù)是什么即可铐维，通常來說一句話就能覆蓋柬泽。此外，使用Gherkin語言描述（前提條件"GIVEN",發(fā)生什么操作"WHEN"和結(jié)果"THEN"）也是一種方法嫁蛇。

比如對于To Do List這樣的一個(gè)應(yīng)用聂抢，QA不需要去設(shè)計(jì)編寫繁瑣的test cases/steps,只需要寫出類似下面的測試想法

• 測試想法1： 加入一個(gè)task，然后完成這個(gè)task
• 測試想法2： 加入多個(gè)tasks棠众，然后一次性清空全部tasks
• 測試想法3： 加入多個(gè)tasks，然后刪除某幾個(gè)tasks
• 測試想法4： 使用filter過濾tasks list

在實(shí)際測試執(zhí)行過程中在使用探索式測試(漫游測試)有决，比如拿上面測試想法來舉例

• 測試想法1
  • 超模漫游： 測試系統(tǒng)界面
  • 反叛漫游： 系統(tǒng)會不會接受錯誤的task描述闸拿，比如為空的task，全是空格的task
  • 沙發(fā)土豆漫游： 有沒有默認(rèn)值书幕？placeholder新荤？
• 測試想法2
  • 找茬漫游： 能不能清空后再次在無task狀態(tài)下清空
• 測試想法3
  • 快遞漫游： 刪除后tasks只是從前端刪除還是從后端刪除？涉及數(shù)據(jù)庫不
• 測試想法4
  • 反叛漫游： 當(dāng)沒有適合條件的task的時(shí)候台汇，filter之后的結(jié)果是什么苛骨，界面如何顯示

可見采用測試想法思維導(dǎo)圖和探索式測試將會有效的減少測試設(shè)計(jì)和執(zhí)行時(shí)間。當(dāng)然測試想法的記錄形式不局限于思維導(dǎo)圖苟呐，使用簡單的word文檔進(jìn)行文本描述痒芝，使用excel文檔進(jìn)行表格描述都是可行的，只要符合"KISS"原則即可牵素。具體怎么設(shè)計(jì)測試想法和應(yīng)用探索式測試严衬，會在稍后提到。

"Shoulder Check"可以幫助QA確認(rèn)代碼改動影響范圍從而變動測試范圍

在敏捷項(xiàng)目中笆呆，當(dāng)故事卡需要從開發(fā)狀態(tài)轉(zhuǎn)入測試狀態(tài)時(shí)请琳，開發(fā)和測試會在一起進(jìn)行"Shoulder Check"粱挡。這個(gè)活動會讓開發(fā)和測試一起“玩”一下剛開發(fā)完的新功能(或是bug fix)。開發(fā)會給QA展示這個(gè)故事卡所有的代碼改動和通過驗(yàn)收條件來展示最終效果俄精，與此同時(shí)QA也會提出自己的任何疑問询筏。通過回顧代碼改動，QA可以評估和與開發(fā)確認(rèn)代碼的影響范圍從而變動測試的范圍竖慧，一般來講嫌套，基本都能夠減少測試范圍從而避免沒必要的手工回歸測試。

問題2： 如何設(shè)計(jì)出覆蓋率高的測試用例测蘑？

由于現(xiàn)在產(chǎn)品業(yè)務(wù)邏輯日益復(fù)雜灌危，迭代交付速度日益加快，按照規(guī)格需求來寫詳細(xì)的測試用例碳胳，并加以等價(jià)類勇蝙、邊界值、因果圖和判定表等測試用例設(shè)計(jì)方法已經(jīng)不能滿足當(dāng)前對測試“快又準(zhǔn)”要求挨约∥痘欤快速地進(jìn)行粗粒度的測試設(shè)計(jì)并不等于忽略掉很多測試場景和數(shù)據(jù)，QA需要的是一種測試設(shè)計(jì)思路來指導(dǎo)具有高覆蓋率的測試用例設(shè)計(jì)诫惭。

下面主要介紹我在日常工作中如何進(jìn)行故事卡驗(yàn)收測試的設(shè)計(jì)和執(zhí)行翁锡。在故事卡已經(jīng)滿足提測標(biāo)準(zhǔn)的前提下，整個(gè)測試設(shè)計(jì)和執(zhí)行一共分為五輪：

1. 使用RST(Rapid Software Testing)進(jìn)行基于風(fēng)險(xiǎn)或缺陷模型的測試夕土，目的是快速發(fā)現(xiàn)一些典型缺陷
2. 使用HTSM中的Test Techniques和軟件屬性分類創(chuàng)建測試馆衔，目的是歸納出適用于故事卡的測試維度和覆蓋到最基本的測試點(diǎn)
3. 使用各類測試建模方法創(chuàng)建指導(dǎo)測試設(shè)計(jì)的模型，目的是通過建立好的產(chǎn)品模型給每個(gè)測試維度加上豐富的測試想法
4. 使用探索式測試之漫游測試來擴(kuò)展每個(gè)測試想法怨绣，目的也是給每個(gè)測試維度加上豐富的測試想法角溃，也有可能會增加新的測試維度
5. 使用探索式測試執(zhí)行各個(gè)測試想法，目的是在執(zhí)行測試的同時(shí)擴(kuò)展思路篮撑，創(chuàng)造更多的測試路徑减细，也會基于系統(tǒng)執(zhí)行結(jié)果的反饋，不斷優(yōu)化測試想法

接下來我們深入的探討下每輪測試實(shí)現(xiàn)的方式

第一輪： 基于RST的測試設(shè)計(jì)和執(zhí)行

快速測試RST(Rapid Software Testing)是技能和思維模式赢笨，通過一種快速未蝌，低投入，可行和可靠的方式來做更加有效的測試茧妒。具體做法是針對某些常見的風(fēng)險(xiǎn)或缺陷模型進(jìn)行專項(xiàng)深度測試萧吠。RST能夠幫助QA在短時(shí)間內(nèi)發(fā)現(xiàn)一些特定類型的缺陷，這些錯誤可以是需求設(shè)計(jì)上的業(yè)務(wù)邏輯錯誤桐筏，也可以是平時(shí)測試中經(jīng)常遇到的缺陷怎憋。這一輪也類似于傳統(tǒng)測試用例方法中的“錯誤推測”方法，只不過不是基于經(jīng)驗(yàn)和直覺，而是依靠的總結(jié)歸納的“缺陷模型”绊袋。

因?yàn)镽ST只是針對一些特定的軟件缺陷進(jìn)行毕匀，所以這一輪測試不會進(jìn)行太多的測試設(shè)計(jì)也不要求QA具備豐富的產(chǎn)品知識。

典型的測試方法有

QA在這一輪中通過已有的產(chǎn)品缺陷模型和尋找故事卡改動可能會引起的缺陷來進(jìn)行測試，這樣會快速的找到一些典型的缺陷悲酷。如果還沒有產(chǎn)品缺陷模型套菜，那就趕快歸納總結(jié)出產(chǎn)品發(fā)生過的缺陷和發(fā)現(xiàn)手段。

第二輪： 基于HTSM和軟件屬性分類的測試設(shè)計(jì)

HTSM中提供了九種測試技術(shù)设易，這些測試技術(shù)用來啟發(fā)創(chuàng)建測試逗柴。

下面列出了這九種通用的測試技術(shù)《俜危“通用的測試技術(shù)”是指技術(shù)是簡單明了的且可以脫離復(fù)雜的上下文普遍適用的戏溺。很多特殊的技術(shù)都可以基于下面九種測試技術(shù)中一種或是多種。通過組合通用技術(shù)和本模型中其他的元素屠尊，我們能夠得到很多特殊的測試技術(shù)旷祸。

• 功能測試 Function Testing

  • 描述：測試軟件的能力
  • 典型思路
    • 辨識產(chǎn)品能做的事情
    • 決定你怎么知道產(chǎn)品能工作
    • 一次只測試一個(gè)功能
    • 測試每個(gè)功能只做了它應(yīng)該做的事情而沒有做它不應(yīng)該做的事情

• 域測試 Domain Testing

  • 描述： 專注于測試軟件所處理的數(shù)據(jù)
  • 典型思路
    • 找到產(chǎn)品處理的所有數(shù)據(jù)∷侠ィ看輸出也看輸入
    • 決定哪些特殊的數(shù)據(jù)需要測試托享。考慮邊界值控淡、典型值嫌吠、無效值和最佳代表數(shù)據(jù)
    • 考慮數(shù)據(jù)的組合
  • 數(shù)據(jù)初始化
  • 數(shù)據(jù)默認(rèn)值
  • 數(shù)據(jù)完整性，在不同模塊之間的賦值和調(diào)用

• 壓力測試 Stress Testing

  • 描述：用極限行為和數(shù)據(jù)壓迫軟件
  • 典型思路
    • 尋找極易遭受挑戰(zhàn)性數(shù)據(jù)和被限制的資源破壞的子系統(tǒng)或是功能
    • 選擇或創(chuàng)建有挑戰(zhàn)性的數(shù)據(jù)或者資源限制條件進(jìn)行測試掺炭。比如龐大或是復(fù)雜的數(shù)據(jù)結(jié)構(gòu)辫诅，高負(fù)荷，持久測試涧狮，大規(guī)模測試用例和低內(nèi)存條件

• 流測試 Flow Testing

  • 描述： 測試軟件的操作順序
  • 典型思路
    • 測試多個(gè)活動串聯(lián)以后端到端的流程炕矮。比如在狀態(tài)模型中開展漫游測試
    • 不要在活動中重設(shè)系統(tǒng)
    • 改變時(shí)間線和順序，試試并發(fā)

• 情景測試 Scenario Testing

  • 描述： 用有說服力的場景來測試軟件
  • 典型思路
    • 開始時(shí)思考關(guān)于產(chǎn)品的一切
    • 設(shè)計(jì)測試來覆蓋與產(chǎn)品有意義的和復(fù)雜的互動
    • 一個(gè)好的場景測試是一個(gè)引人注目的故事者冤，這個(gè)故事涉及誰做了什么影響產(chǎn)品的事情

• 聲明測試 Claims Testing

  • 描述： 測試所有產(chǎn)品資料 Challenge every claim
  • 典型思路
    • 調(diào)查所有的聲明肤视，澄清所有的聲明
    • 鑒別所有關(guān)于產(chǎn)品的參考資料
    • 測試關(guān)于產(chǎn)品聲明的精準(zhǔn)性

• 用戶測試 User Testing

  • 描述：從用戶角度測試 Involve the users
  • 典型思路
    • 識別用戶的角色分類
    • 識別每一類的用戶分別會做什么事情，怎么做以及帶來的用戶價(jià)值是什么
    • 獲取真實(shí)的用戶數(shù)據(jù)來進(jìn)行測試
    • 否則涉枫，系統(tǒng)性地模擬一個(gè)用戶(這里有一個(gè)坑邢滑，就是你很容易自以為你就是真實(shí)的用戶，而不是你并不是)
    • 強(qiáng)有力的用戶測試通常都會涉及多個(gè)不同類別的用戶和不同的角色愿汰，并不是某一個(gè)

• 風(fēng)險(xiǎn)測試 Risk Testing

  • 描述：猜想一個(gè)問題困后，然后去嘗試發(fā)現(xiàn)它 Imagine a problem, then look for it
  • 典型思路
    • 這個(gè)產(chǎn)品可能會有什么樣的問題
    • 哪些問題最有嚴(yán)重或是最有可能性發(fā)生？先聚焦在這些問題
    • 如果這些問題有可能發(fā)生衬廷，應(yīng)該怎么去發(fā)現(xiàn)他們摇予？
    • 列出一個(gè)包含一些有趣問題的列表，然后設(shè)計(jì)測試去揭露他們
    • 這個(gè)測試能幫助咨詢專家吗跋，設(shè)計(jì)文檔侧戴，歷史缺陷報(bào)告或者啟發(fā)風(fēng)險(xiǎn)

• 自動化檢查 Automatic Checking

  • 描述：自動檢測大量不同的結(jié)果 Check a million different facts
  • 典型思路
    • 尋求或開發(fā)工具來做大量操作和檢查大量結(jié)果
    • 考慮能部分自動化測試覆蓋率的工具
    • 考慮能部分自動化測試先知的工具
    • 考慮能夠自動化感知變更的檢測器
    • 考慮能夠自動化產(chǎn)生數(shù)據(jù)的創(chuàng)造器
    • 考慮能夠幫助人工測試的工具

此外我們也可以從下面軟件屬性分類來思考我們的測試用例設(shè)計(jì)

• 結(jié)構(gòu) --> 自動化檢查 Automatic Checking
  • 代碼路徑
• 功能 --> 功能測試 Function Testing
  • 產(chǎn)品功能正常
  • 產(chǎn)品異常處理
  • 產(chǎn)品符合需求
  • 后臺功能正常
• 業(yè)務(wù)價(jià)值 --> 情景測試 Scenario Testing, 用戶測試 User Testing
  • 給客戶帶來的價(jià)值
  • 依賴方
  • 影響其他系統(tǒng)
• 平臺 - 執(zhí)行環(huán)境
  • 測試產(chǎn)品依賴的環(huán)境
    • 瀏覽器
    • OS
    • 不同配置項(xiàng)
    • 網(wǎng)絡(luò)
    • 硬件資源使用情況
• 數(shù)據(jù) --> 域測試 Domain Testing
  • 測試不同的數(shù)據(jù)類型
    • 有效無效
    • 大規(guī)模
    • 輸入輸出
• 接口 --> 情景測試 Scenario Testing, 用戶測試 User Testing
  • 交互方式
    • 人工界面
    • 自動程序
• 狀態(tài) --> 流測試 Flow Testing
  • 不同狀態(tài)
    • 持久
    • 一致

可見HTSM還是覆蓋了大部分上面的軟件屬性宁昭，需要注意的是"平臺"所對應(yīng)的兼容性測試并沒有在HTSM中列出來，而QA需要測試軟件在不同執(zhí)行環(huán)境下的表現(xiàn)酗宋。

QA在這一輪需要探索和決定上面測試技術(shù)中哪些適用于當(dāng)前的故事卡(產(chǎn)品功能)积仗，把適合的測試技術(shù)與故事卡的變動聯(lián)系起來，確定了針對本次改動的測試范圍和基本測試點(diǎn)本缠。比如說"Domain Testing"域測試是專注于測試數(shù)據(jù)的測試技術(shù)斥扛，基本適用于每一個(gè)故事卡。當(dāng)確定域測試適用之后丹锹，QA就會產(chǎn)生下面的測試想法：

• 該變動影響和涉及的測試數(shù)據(jù)有哪些稀颁？
  • 數(shù)據(jù)作為輸入變量
  • 數(shù)據(jù)作為輸出變量
• 測試數(shù)據(jù)有什么類型？
  • 有哪些無效的數(shù)據(jù)楣黍？如何被系統(tǒng)識別和處理匾灶？
  • 有哪些有效的數(shù)據(jù)？不同的有效數(shù)據(jù)類型如何被系統(tǒng)接收和處理租漂？
  • 最重要的測試數(shù)據(jù)是哪些阶女？考慮邊界值、典型值哩治、無效值和最佳代表數(shù)據(jù)
• 測試數(shù)據(jù)如何產(chǎn)生秃踩？
  • 用戶產(chǎn)生數(shù)據(jù)的方式有有哪些？
• 測試數(shù)據(jù)如何被系統(tǒng)處理业筏？
  • 大規(guī)模的數(shù)據(jù)處理
  • 同一數(shù)據(jù)在不同模塊之間的處理
  • 能否被存儲成功
• 測試數(shù)據(jù)會在哪些地方以什么方式呈現(xiàn)給用戶憔杨？
• 測試數(shù)據(jù)有哪些特點(diǎn)
  • 完整性 - 數(shù)據(jù)在被不同功能或模塊容納處理后依然完整
  • 唯一性 - 數(shù)據(jù)是否在系統(tǒng)里唯一，不能有重復(fù)
  • 一致性 - 單一數(shù)據(jù)在系統(tǒng)里顯示一致
  • 沖突性 - 不同數(shù)據(jù)之間是否沖突

上面提到這九種技術(shù)是非常通用的蒜胖，如果發(fā)現(xiàn)故事卡有需求變動不能被這九種技術(shù)覆蓋掉消别，那么QA需要考慮自己“創(chuàng)造”一種測試技術(shù)來覆蓋需求。此輪測試相比于RST台谢，這一輪測試會涉及更多業(yè)務(wù)領(lǐng)域知識寻狂，最基本的業(yè)務(wù)功能都會在此輪測試中被覆蓋到。

基于測試建模的測試設(shè)計(jì)

測試建模是以指導(dǎo)測試設(shè)計(jì)為目的建立產(chǎn)品模型朋沮，此產(chǎn)品模型就是測試建模的產(chǎn)出蛇券。這個(gè)產(chǎn)品模型包含著大量測試需要關(guān)注的信息。

QA常使用的測試建模手段有哪些呢樊拓？

1.組合測試

• 組合測試(combinatorial testing)是一種測試用例生成方法纠亚。測試人員將被測試對象抽象成一個(gè)受到多個(gè)變量影響的系統(tǒng)，其中每個(gè)變量的取值是離散且有限的骑脱。
  • 兩因素組合測試(pairwise combinatorial testing菜枷，配對測試苍糠，全對偶測試) 生成的測試集可以覆蓋任意兩個(gè)變量的所有取值組合叁丧。在理論上，該用例集可以暴露所有的兩個(gè)變量共同作用而引發(fā)的缺陷
  • 多因素組合測試(n-way combinatorial testing) 生成的測試集可以覆蓋任意n個(gè)變量的所有取值組合。在理論上拥娄，該測試用例集可以發(fā)現(xiàn)所有由n個(gè)因素共同作用引發(fā)的缺陷
• 常用工具：PICT生成滿足特定組合覆蓋標(biāo)準(zhǔn)的組合測試用例集
• 更多工具集

2.輸入輸出模型/IO模型

• 輸入輸出模型是最基本的測試模型蚊锹，這個(gè)模型列舉了被測對象所有的輸入變量和輸出變量，然后定義了輸入輸出的關(guān)系稚瘾。這個(gè)模型經(jīng)常被用來設(shè)計(jì)數(shù)據(jù)和流程相關(guān)的測試牡昆。

3.狀態(tài)機(jī)模型

• 分析識別出被測對象所有的狀態(tài)以及狀態(tài)之間進(jìn)行變遷的觸發(fā)事件，這樣我們可以得到一個(gè)狀態(tài)圖
• 通過分析狀態(tài)圖摊欠，QA可以設(shè)計(jì)測試用例覆蓋所有狀態(tài)丢烘、所有狀態(tài)變遷和所有觸發(fā)事件
• 也可以把狀態(tài)圖轉(zhuǎn)變?yōu)闋顟B(tài)表

4.功能列表

• 用列表的方式列出產(chǎn)品的主要功能和子功能

QA在這一輪測試中需要觀察上輪中得到的測試想法可否使用測試建模技術(shù)來細(xì)化；如果可以細(xì)化些椒，那QA可以得到更多的測試想法和更加精確的測試數(shù)據(jù)播瞳。

基于探索式測試之漫游測試的測試設(shè)計(jì)

探索式測試可以用于幫我們在測試設(shè)計(jì)中開發(fā)出測試用例，它也可以幫助我們發(fā)現(xiàn)在規(guī)范說明書中可能漏掉的用戶場景免糕，還可以組織測試人員的測試思路赢乓。探索式測試之漫游測試是在特定主題指導(dǎo)下對產(chǎn)品進(jìn)行探索的一組測試方法，這里列出一些最常見的方法石窑。因?yàn)檫@一輪測試是基于上幾輪測試的結(jié)果牌芋，所以我們使用HTSM的九種技術(shù)來展示漫游測試方法可以發(fā)揮巨大作用的地方。

• 功能測試 Function Testing

  • 賣點(diǎn)漫游：測試人員發(fā)現(xiàn)并測試軟件的賣點(diǎn)松逊，這通常是銷售人員和廣告資料重點(diǎn)強(qiáng)調(diào)的特性躺屁。該漫游與之前介紹的價(jià)值漫游都有助于分析軟件的核心價(jià)值是否存在風(fēng)險(xiǎn)
  • 配角漫游： 測試人員重點(diǎn)測試軟件的非主要功能。例如棺棵，對話框上有一條指向幫助文檔的鏈接楼咳，很少有用戶會注意到它。測試人員則需要點(diǎn)擊該鏈接烛恤，以檢查它指向正確的文檔母怜。該漫游有助于完整地測試軟件的每個(gè)功能
  • 超模漫游： 測試人員重點(diǎn)測試軟件界面，檢查界面是否美觀缚柏、控件是否正確苹熏、動畫是否流暢、色彩是否協(xié)調(diào)币喧、刷新是否及時(shí)轨域、字體是否優(yōu)雅等
  • 破壞者漫游：測試人員實(shí)施故障注入和錯誤容忍方面的測試。他故意破壞或移除軟件操作需要的資源杀餐，然后強(qiáng)制軟件執(zhí)行注定導(dǎo)致失敗的操作干发。該漫游將測試軟件能否合理地處理(不可避免的)失敗，且不會導(dǎo)致更嚴(yán)重的后果(如用戶數(shù)據(jù)丟失)

• 域測試 Domain Testing

  • 快遞漫游：測試人員跟隨一組數(shù)據(jù)走遍軟件的功能史翘。例如枉长，測試PowerPoint圖片時(shí)冀续，測試人員跟隨一組圖片，測試圖片導(dǎo)入必峰、圖片編輯洪唐、圖文混排、圖片導(dǎo)出吼蚁、幻燈片打印等功能凭需，并時(shí)刻檢查圖片操作的正確性
  • 沙發(fā)土豆漫游：測試人員盡可能不提供或修改數(shù)據(jù)，這意味著接受軟件提供的默認(rèn)值肝匆、保持表單字段為空粒蜈、或只提交最少的數(shù)據(jù)。該漫游檢查軟件可以處理它提供的默認(rèn)值旗国、空值和可選字段
  • 收藏家漫游： 測試人員通過測試去收集軟件的輸出薪伏，收集得越多越好。例如粗仓，測試PowerPoint圖片時(shí)嫁怀，測試人員要收集各種圖片導(dǎo)出的結(jié)果，以覆蓋圖片格式借浊、圖片色彩塘淑、圖片效果、圖片尺寸等因素蚂斤。該漫游有助于周密地覆蓋軟件的計(jì)算結(jié)果

• 流測試 Flow Testing

  • 地標(biāo)漫游： 測試人員選擇一組相關(guān)的功能存捺，依次測試，直到測試了所有功能曙蒸。該漫游與功能漫游相似捌治，都可以探索并學(xué)習(xí)軟件的功能，用一組地標(biāo)(功能列表的主干)產(chǎn)生詳細(xì)的地圖(功能列表的分支)
  • 停車場漫游： 該漫游探測軟件的’地形’纽窟， 其主要目標(biāo)是發(fā)現(xiàn)所有功能的入口(面向覆蓋)和有可能發(fā)生的問題(面向風(fēng)險(xiǎn))肖油，次要目標(biāo)是確定具體的漫游方法可以應(yīng)用的地方，幸運(yùn)目標(biāo)是發(fā)現(xiàn)一些極端嚴(yán)重的缺陷
  • 出租車漫游： 測試人員發(fā)現(xiàn)并測試觸發(fā)某一功能的所有途徑臂港，或完成某項(xiàng)任務(wù)的所有方式森枪。該漫游有助于完整地考慮并測試一個(gè)功能或情景
  • 歧路漫游：該漫游是一種特殊的反叛漫游，它要求測試人員以錯誤的方式或順序來操作軟件审孽。例如县袱，測試人員故意調(diào)換工作流的步驟，故意利用未經(jīng)初始化的數(shù)據(jù)等

• 情景測試 Scenario Testing

  • 傲慢美佬漫游：測試人員用一些不合“正秤恿Γ”邏輯的情景來測試軟件式散。例如，測試在線交易網(wǎng)站打颤，提交訂單并支付后暴拄，又取消訂單并要求退款宛畦。又例如，提交訂單后揍移，又申請去更改送貨地點(diǎn)和送貨方式。該漫游有助于發(fā)現(xiàn)軟件在不常見情景中所暴露的錯誤
  • 混票漫游：該漫游針對情景測試反肋，以引入更多的測試變化那伐。它要求測試人員跟隨一個(gè)測試情景訪問某個(gè)功能，然后再利用另一個(gè)測試情景去測試其他功能石蔗。這有助于混合測試多個(gè)情景罕邀，發(fā)現(xiàn)由功能交互引發(fā)的問題

• 風(fēng)險(xiǎn)測試 Risk Testing

  • 找茬漫游： 測試人員在測試軟件時(shí)，以找茬的心態(tài)去挑戰(zhàn)軟件养距。他提出各種問題去質(zhì)疑軟件诉探，例如：“如果我這么做，會如何棍厌？如果我偏不這么做肾胯，又如何？如果我不想這么做耘纱，有什么替代方案敬肚？” 該漫游有助于發(fā)現(xiàn)程序員設(shè)計(jì)的不足和軟件邏輯的漏洞
  • 風(fēng)險(xiǎn)識別漫游： 風(fēng)險(xiǎn)識別漫游產(chǎn)生軟件的風(fēng)險(xiǎn)列表。測試人員可以分析軟件的各個(gè)部分束析，想象它可能遭遇的失敗艳馒，以列出一組軟件面臨的風(fēng)險(xiǎn)。測試人員還可以漫游產(chǎn)品的功能并沿路思考：“此外员寇， 軟件可能發(fā)生什么錯誤弄慰？它可能遇到什么異常情況？”以獲得一組潛在風(fēng)險(xiǎn)
  • 極限值漫游：極限值漫游是一種特殊的風(fēng)險(xiǎn)識別漫游蝶锋。它通過輸入極限值或制造軟件的極限狀態(tài)來發(fā)現(xiàn)軟件的錯誤陆爽。常見的極限值包括零、最小值扳缕、最大值墓陈、空值、NULL第献、負(fù)值(當(dāng)軟件期望用戶輸入正數(shù)時(shí))贡必、不正確的數(shù)據(jù)格式等
  • 知識分子漫游： 測試人員運(yùn)用業(yè)務(wù)和技術(shù)知識向軟件提出極具挑戰(zhàn)的問題，例如：“軟件能處理的最大流量是多少庸毫？ 哪些操作會索取最多的內(nèi)存仔拟？” 成功運(yùn)用該漫游的前提是測試人員深刻地理解業(yè)務(wù)、設(shè)計(jì)和實(shí)現(xiàn)飒赃，并可以設(shè)計(jì)出有挑戰(zhàn)性的測試用例

QA在這一輪測試中需要利用漫游測試方法帶來的啟發(fā)在每個(gè)測試分類中創(chuàng)建更多的測試點(diǎn)和測試數(shù)據(jù), 這一輪測試設(shè)計(jì)中利花，更多的異常測試用例會被挖掘科侈。測試設(shè)計(jì)也基本完成了。

基于探索式測試的測試執(zhí)行

接下來我們需要“按部就班”的執(zhí)行設(shè)計(jì)好的測試點(diǎn)炒事，不會像執(zhí)行固定的腳本一樣去執(zhí)行測試用例臀栈，而是還會在執(zhí)行的過程加入一些變化。

在執(zhí)行某個(gè)測試點(diǎn)時(shí)挠乳，我們可以

• 根據(jù)實(shí)時(shí)測試結(jié)果反饋
  • 發(fā)現(xiàn)是否遺漏了一些需求
  • 挖掘新的測試數(shù)據(jù)
  • 決定是否創(chuàng)建新的測試點(diǎn)或是刪除無效測試點(diǎn)
  • 變動某個(gè)測試步驟來增加場景的多樣性
• 在遇到有業(yè)務(wù)邏輯分歧的時(shí)候权薯，可以嘗試先往不同路徑測試，最終再回到主路徑

所以整個(gè)測試執(zhí)行是基于測試結(jié)果反饋的睡扬，QA既測試了之前設(shè)計(jì)好的用例盟蚣，又在測試擴(kuò)展測試了其它沒有提前設(shè)計(jì)的用例。

總結(jié)

通過改變測試設(shè)計(jì)方法和精準(zhǔn)定位代碼變動影響范圍卖怜，QA可以減少大量測試設(shè)計(jì)和執(zhí)行時(shí)間屎开。通過五輪不同目的的測試，QA考慮到了一次故事卡變動影響的方方面面马靠，每一輪測試有其獨(dú)特的使命奄抽，提高了測試用例覆蓋率，避免了測試冗余甩鳄。只有把所有可行的測試方法都組合起來使用如孝，才能設(shè)計(jì)出高覆蓋率的測試用例。

參考資料

• 軟件測試實(shí)戰(zhàn)
• 測試架構(gòu)師修煉之道
• HTSM
• RST
• ET