軟件在發展初期，大部分實現的都是單一功能，如計算器，用戶期望計算器實現加、減、乘、除等運算功能，單一輸入，單一輸出，無論是軟件開發還是測試，相對來說較爲容易。
隨着用戶需求越來越複雜，對軟件系統的價值要求越來越高，軟件系統不再僅僅實現一些基礎功能，如信息的增、刪、改、查，而是在基礎功能平臺上，實現更多流程性、事務性的功能。
【案例1 信用卡申請功能流程】
銀行提供用戶在線申請信用卡功能，用戶訪問申請地址，輸入身份證號碼，輸入個人信用證明，銀行後臺自動校驗，如果符合，則根據規則發放信用卡，如不符合則拒絕，或發起人工審覈。可能涉及的流程圖如圖1所示。
圖1 信用卡在線申請業務處理流程
如今絕大多數的業務系統由用戶管理、權限管理、工作流管理、基礎數據維護四大核心組件構成，每個核心組件中涉及信息的增加、修改、刪除、查詢等相關操作。測試工程師測試任何軟件，應當先理解被測的業務結構，從而根據用戶需求優先級制定合理的測試計劃與策略。
從用戶角度考慮，用戶期望軟件完成其所需的業務流程，其他功能則是輔助流程的，因此流程測試是日常測試工作中非常重要的內容。
流程測試是測試工程師將被測對象的各個功能通過業務流程貫穿起來運行，模擬真實用戶實際的工作流程，從而驗證流程的正確性。
流程測試通常分爲三個步驟：流程需求分析、流程測試設計、流程測試執行。
流程需求分析
業務流程，一般可能由多個功能、多種角色、多種權限組合而成，過程中涉及較多的測試點，進行流程時，需分析業務流程涉及哪些具體的功能、角色及權限。
【案例2 ECShop用戶購買商品流程】
ECShop系統的“註冊用戶購買商品”業務流程如圖2所示。
圖2 註冊用戶商品購買流程
上圖是ECShop註冊用戶登陸平臺後購買商品的基本流程，從登陸->查詢->瀏覽商品到最終的收貨節點，從用戶應用角度分析，僅涉及一個角色、一種權限，雖然過程中包含多個功能點，但測試工程師針對這樣的流程測試時，無須關注每個節點的功能性特性，僅需考慮軟件系統是否正確實現了對應的業務流程，具體每個節點的驗證性測試活動應該單獨開展。
也有些流程較爲複雜，以請假流程來說，過程中可能涉及多個角色、多種權限，如圖3所示。
圖3 員工請假流程
測試工程師測試圖3所描述的請假流程時，需分析該流程中包含哪些角色、需要哪些權限，判定路徑有幾條。
01.角色
需確定被測流程共涉及幾種角色，因爲每種角色對應的權限不同，測試工程師應當從用戶角色考慮流程的合理性，而不僅僅關注系統實現。
上述流程圖共涉及普通員工、部門領導、公司領導、人事四種角色，測試用例設計時至少需要創建這四種角色的用戶，才能真實的模擬用戶行爲。
02.權限
不同的角色對應不同的權限，通過流程測試，可發現權限設計方面的缺陷，以請假流程爲例，部門領導應該具有審批普通員工的請假單權限，但不應當具有審批公司領導請假單的權限。測試流程前需確保權限功能的正確性。
03.路徑
路徑，是流程包含的分支路徑。分支路徑說明了業務流程的複雜度，以員工請假流程爲例，共有4條路徑，分別是：
路徑1：1、2、3
路徑2：1、2、4
路徑3：5、6、7
路徑4：5、6、8
路徑根據其處理業務流程的方式不同，劃分爲基本流、備選流及異常流等三種形式。
1）基本流
基本流從流程開始直至流程結束，中間無任何異常分支，往往表述一個正向的業務流程，也是優先級較高的流程，簡單而言，即流程中所有功能都輸入軟件系統可接受的數據，從而完成整個業務流程。如圖5- 37員工請假流程中“普通員工提交請假單->部門領導->同意->人事記錄請假信息”是基本流。
2）備選流
儘管在流程流轉過程中出現了異常，但仍能回到基本流主線，最終完成用戶期望的業務行爲，這樣的流程稱爲備選流。以ECShop用戶進行訂單支付時，密碼輸入錯誤後重新輸入，系統驗證正確後完成支付，這樣的業務過程即屬於備選流。
3）異常流
針對業務流程，一般分解到基本流與備選流即可，但筆者認爲在實際的測試過程中，應當根據實際業務情況增加異常流分支劃分。異常流是在備選流的基礎上，違反系統約束最終導致用戶期望結果未能達成的路徑。同樣以訂單支付爲例，系統調用支付接口，用戶密碼輸入錯誤超過3次，導致支付行爲鎖定，無法完成後續業務，這樣的處理路徑，理解爲異常流。
簡單的業務流程，通過文字描述即可，但很多時候流程相對較爲複雜，此時測試工程師最好繪製流程圖，這樣更利於後續的測試用例設計。分析流程的時候，根據流程的重要程度及使用頻率確定流程的優先級。