流程測試，相比單個功能點(diǎn)測試更消耗測試時間，尤其是金融、通信及運(yùn)營類的系統(tǒng)平臺，往往一條路徑的測試就需要構(gòu)造大量的測試數(shù)據(jù)才能完成，因此，在執(zhí)行流程測試時，應(yīng)該提前準(zhǔn)備好相關(guān)的測試數(shù)據(jù)，如果涉及較大量的數(shù)量，可利用一些數(shù)據(jù)生成工具來制造測試數(shù)據(jù)。

敏捷測試中以一個Sprint為節(jié)點(diǎn)，通常Sprint中包括的用戶故事具有較強(qiáng)的耦合度，測試工程師根據(jù)產(chǎn)品實(shí)現(xiàn)，確定業(yè)務(wù)流程從而開展測試活動。

流程測試執(zhí)行的順序可以先從單個功能測試開始，這點(diǎn)根據(jù)開發(fā)工程師提供的模塊確定，開發(fā)工程師提供了哪些功能，測試工程師則先開始測試，當(dāng)模塊逐步集成時，再進(jìn)行流程測試，因?yàn)榱鞒虦y試的前提是單個功能點(diǎn)正確。

當(dāng)產(chǎn)品功能逐步集成后，進(jìn)行冒煙測試時，應(yīng)當(dāng)以將基本流作為冒煙測試用例執(zhí)行，驗(yàn)證被測對象是否具備可測性。冒煙測試通過后再進(jìn)行正式測試。

以上介紹的是從用戶角度出發(fā)，完成某個具體業(yè)務(wù)需求的流程測試方法，在實(shí)際測試工作中，還有一種流程測試思路，筆者稱為邏輯流程測試方法。

【案例1  ECShop商品管理功能測試】

ECShop商品管理功能的應(yīng)用邏輯流程如圖1所示。

圖1 ECShop商品管理流程

軟件測試實(shí)施過程中，從用戶角度出發(fā)，可能因每個角色的業(yè)務(wù)目標(biāo)不同，而導(dǎo)致業(yè)務(wù)邏輯斷裂，造成測試活動無邏輯，浪費(fèi)測試時間，如果測試工程師不僅僅關(guān)注用戶期望，還從數(shù)據(jù)完整性、可溯性角度考慮，將會降低這類風(fēng)險。

以圖1為例，測試工程師在實(shí)施測試過程中，可先進(jìn)行后臺商品類別管理的測試，然后再進(jìn)行商品信息管理，最后再切換用戶進(jìn)行購買業(yè)務(wù)。如果測試任務(wù)分配時，將后臺商品管理與前臺購物分開，則有可能造成數(shù)據(jù)不一致的錯誤，同時也增加了測試工程師之間的溝通成本。以筆者的測試經(jīng)驗(yàn)，通常進(jìn)行如下的測試流程：

首先測試商品類別管理功能，只有存在商品類別，才能添加商品。商品類別管理中先執(zhí)行增加商品類別測試用例，然后再執(zhí)行修改商品類別用例，最后執(zhí)行刪除商品類別用例；

商品類別管理功能測試完成后，進(jìn)行商品管理測試，同樣的順序，執(zhí)行增加商品用例->修改商品用例->刪除商品用例->查詢商品用例，遵循用戶基本的應(yīng)用習(xí)慣。

最后切換身份，使用注冊用戶帳號登陸前臺，執(zhí)行查詢商品、購買商品的用例，從而完成完整的商品管理功能（提供數(shù)據(jù)、應(yīng)用數(shù)據(jù)）。

除了上述兩種情況外，還有一種可能性，就是Web系統(tǒng)與App結(jié)合的結(jié)構(gòu)，測試這種結(jié)構(gòu)時同樣需考慮業(yè)務(wù)邏輯的一致性，筆者曾經(jīng)遇到一個缺陷，是某航空官網(wǎng)與其App注冊與登陸功能要求不一致的問題。官網(wǎng)要求注冊帳號密碼不少于6位，但App登陸時，提示密碼為6位，當(dāng)用戶在官網(wǎng)密碼設(shè)置超過6位時，則無法在App登陸，必須修改為6位。這樣的缺陷對用戶而言是無法接受的，應(yīng)用起來非常麻煩。

目前大部分的業(yè)務(wù)系統(tǒng)中，都涉及到大量的業(yè)務(wù)流程，因此測試工程師應(yīng)當(dāng)重視流程測試的方式方法。如果被測對象沒有明確的需求或者需求中沒有給出流程圖，測試工程師可根據(jù)相關(guān)測試資源繪制流程圖，流程圖不一定畫的很完美，只需要表述流程結(jié)構(gòu)即可，這樣便于對被測對象的理解、測試用例設(shè)計及后期的執(zhí)行操作。如果測試設(shè)計時，能夠接觸到實(shí)際的用戶更好，可請用戶幫忙評審流程，從而保證測試設(shè)計的正確性。