在業務流程的分析上，我們應該得到以下信息：
1）系統的主流程是什么
2）條件備選流程是什么
3）數據流向是什么
4）關鍵的判斷條件是什么
流程測試是測試人員把系統各個模塊連貫起來運行、模擬真實用戶實際的工作流程，滿足用戶需求定義的功能來進行測試的過程。
業務流程測試是系統測試最重要的內容，而測試的依據就是用戶定義的需求和測試人員的測試設計，因此下面就從需求、測試設計、測試執行等角度上重點來闡述如何做好業務流程測試。
一、關注需求和用戶
1、站在用戶的角度
優秀的需求應該是站在用戶的角度來思考問題，是用戶能夠利用系統完成什么，而不是系統自己完成。因此在需求理解時要多和軟件的最終用戶進行交流，了解他們的訴求，以便有針對性的進行測試。
2、重視全局，而非細節
工作重點應該是放在盡可能全面的收集需求要點、了解整體的業務流程、分析主體業務流程和重點業務流程等工作上。在獲得了系統的全貌之后，我們會發現原先在編寫功能測試用例對系統的認識是不充分的，這時要編寫的流程測試用例需要根據新的思路進行重新排列。
3、現場客戶
現場客戶隨時提供對需求細節的指導。如果沒有條件，可以定期的邀請用戶參加項目例會或安排和用戶交流等。另外在需求理解評審和測試設計評審會盡量邀請用戶參與。
二、精心設計流程用例
1、流程用例編寫要點
● 要有基本數據，以便系統測試多次使用，同時方便自動化工具介入。
● 其他流程要依賴這套數據，使之每個流程可以更有針對性的執行。
● 構建的數據要盡量有具體的意義，嚴禁用a、b、c；1、2、3等
● 流程要符合用戶常用的業務操作習慣，盡量考慮用戶的實際操作去編寫。
● 流程可大可小，但每一個流程都要是一個典型的業務操作。
● 流程不必覆蓋到所有功能點，因為流程用例是功能用例的一個補充。
● 流程不要被具體的模塊所限制，各個模塊可以交叉。用戶實際的業務操作是沒有界限的。
2、流程用例編寫實踐
● 系統總流程表
該表制定的目的首先是理清系統脈絡，和編寫者的思路；其次是給后進入項目的tester，一個對系統大概的認識，對於系統的功能和各個模塊之間的關系有個宏觀的認識。
● 角色功能表
因為我們現在所做的系統大都是多用戶多權限的，對應不同角色有不同的權限。包括菜單級和操作級的。比如E-Sales系統中就有8種角色50多種權限，所以有一個清晰的列表對於用戶理解和測試系統是有很大幫助的，在測試不同角色對應的不同功能頁面或操作可以通過該表進行二維的對應。
● 測試數據列表
流程測試要依賴一套可以重用的並且盡量符合用戶實際操作的數據。測試用例中包含精心准備的數據，在執行時會有的放矢，更貼近用戶的操作。
● 流程測試用例表
這是最重要的一個部分，是我們測試流程的出發點和根據，和功能測試用例不同的是，
我們這里所關注的是業務操作的流程，編寫時參照“流程用例編寫要點”。
流程測試用例編寫參照流程測試模版及案例。
三、測試執行
● 在系統測試每輪測試保持測試數據庫都是完整的一套初始數據，通過exp/imp實現；
● 在數據穩定、界面穩定的前提下通過自動化工具錄制流程測試腳本；現在部門推薦MI公司WinRunner和LoadRunner。
● WinRunner使用參照vss中測試組整理的WinRunner7.6使用指南
LoadRunner使用參照vss中測試組整理的LoadRunner 壓力測試實例
一、業務流程整理
1、充分掌握業務知識，業務流程以及業務的數據流向。
站在用戶的角度思考，而不僅僅考慮在系統中如何操作業務流程；搞清楚每一項業務中的詳細流程和各個環節涉及的角色，一項比較復雜的業務其詳細流程往往比較多，只有了徹底掌握了這項業務，才能對當前業務環節進行全方位的測試。
2、從需求人員或者客戶那里了解到各業務流程的重要程度和使用頻率。（這點對把握測試重點很重要）
3、了解業務流程在系統中對應的功能。（建立業務與系統的映射，為編寫測試用例做好准備）
二、編寫測試用例（在需求文檔以及UI原型評審之后）
1、繪制業務流程圖（對於較簡單的流程，也可以用文字描述的形式，但流程圖比較直觀，也便於進行路徑的分析）。
2、根據業務流程的重要程度、使用頻率為各流程設置好優先級。
3、采用場景法、路徑法或其他方法（方法其實是不固定的，有時候可以綜合使用多種方法）梳理出每個業務流程在系統中對應的操作步驟，形成業務流程的測試用例。
注意：
* 這里的操作步驟沒有必要像功能點測試用例的步驟那么詳細，這個操作步驟可能是一個業務操作集，可以分解成多個步驟，這些業務操作集合，也可以對應具體的功能點測試用例，從而做到測試用例的復用。所以可以說這里的業務流程測試用例就像是將多個功能點的測試用例組合成一個集合，形成一個業務流。
* 在每個步驟中需要標識出執行該操作的用戶角色，因為在一個業務流程中，很可能涉及到不同的角色。
* 需要平衡項目的進度、成本，不一定需要覆蓋所有的路徑。
三、測試數據設計
1、輸入數據：
測試業務流程與功能點測試的重點不一樣，因此設計測試數據的時候更多需要考慮下面的因素（按重要到次要排列）：
1）關鍵的判斷條件
2）符合業務意義的數據
3）邊界數據
4）異常數據
另外，對流程無任何影響的數據，我認為可以在此不考慮，放到功能點測試中更加合適，這樣可以減少不必要的干擾。不過，有些功能點對流程的依賴很強，或者業務流程非常簡單，也可以將業務流程測試與功能點測試結合。（實際我覺得功能點測試與業務流程測試的數據分開會好一點，因為畢竟重點不一樣；但有時迫於進度的壓力，也會將這些數據結合在一起）
2、輸出數據：
系統中得到的結果數據以及報表中的數據，都需要體現出來，必要的時候還需要根據報表的格式提供輸出數據，以便在測試時進行核對。
注意：需要平衡項目的進度、成本，盡可能用少的測試數據發現多的問題。
四、測試執行
主要在下面幾個階段執行業務流程測試：
1、最主要是在系統測試階段進行（將優先級高的主要業務流程測試用例作為冒煙測試用例）。
2、在集成測試的后期，已經對部分業務測試流程進行了測試，可以根據系統集成的順序，在集成測試階段對部分業務流程進行測試。集成測試階段重點是測試功能點，功能點測試存在嚴重問題，是無法進行業務流程測試的，所以一般是等功能比較穩定的時間才會進行業務流程測試。
3、驗收測試。
4、個人觀點：保證質量最有力的手段還是預防，如果能夠將業務流程測試用於測試的前期，比如：用於開發人員進行聯調、或者送測前的測試，這樣可能會提高送測質量，減少測試輪次，提高編碼質量。
另外，有了具體的步驟，以及測試數據，可以結合自動化測試工具進行業務流程測試。