基本內容
曾經一段時間，同事們把做得好的測試人員分為兩種，一種是“業務流”，精通軟體需求業務，對功能的業務邏輯進行深入研究，提的bug大多是與業務實現息息相關的，只是更多的關注操作流程，每一步操作順序倒來倒去的，就常常出現了致命的bug，其實這些bug也正是客戶和市場人員最在乎的；一種是“操作流”，在我們組內大多是計算機專業畢業，動手能力較強，常常能經過複雜或者詭異的操作來發現一個bug，並沒有經過什麼仔細的分析業務，由“操作流”發現的bug，在業務上沒有太多深度，一般都是系統崩潰、報錯、或者發生較功嚴重功能錯誤，往往市場人員和用戶不是很注重這種bug，甚至有人說，誰會去做這種變態又複雜的操作呢？
兩種測試方式都是必不可少的，業務與實現既要很好的分離開來，也不能單獨的存在，只能說側重點不同罷了。
1、一個功能會有很多的入口。比如下訂單，可以從採購單下訂單，也可以從歷史訂單中下訂單等。如果我按照功能劃分寫測試用例的時候，那是不是要把每種入口作為一個測試用例寫呢？
2、不同角色處理訂單會有不同的流程，比如採購商和供應商在訂單處理中是不一樣，採購商主要是查看訂單配送情況以及取消訂單等操作，而供應商是負責配送訂單等。
那如果寫測試用例的時候，該如何體現這種業務的流轉。感覺按照每個頁面寫的用例，都是靜態頁面似的。但我們實際測試的時候肯定會先按招業務流程執行的。
1、首先需要明確，你無論從那個入口進入，是否都是調用的同一模組；如果每個入口都是調用的同一模組，我認為沒有寫每個入口的測試用例，只是需要寫初每個入口是否能夠調用訂單模組的測試用例。如果是不同模組，毫無疑問的需要寫不同的測試用例。
2、不同角色處理訂單會有不同的流程，這個根據場景法寫，重點放在不通角色的處理流程是不是正確。
簡單來說就是：
1、一個入口一個測試用例
2、一個角色一個測試用例
最關鍵是設計基於業務場景的用例，這裡的用例不是我們通常意義上的測試用例，它是業務場景，但是在設計這些場景時，要考慮業務的各種組合情況，通過業務流程、公式、數據流把業務連結起來，形成一個一個的業務流，將來這些業務流就是我們功能測試中的一個個執行流程，這些流程將把測試設計工程師設計的測試用例貫穿下來，在測試用例中不寫測試數據，而在業務場景中設計測試數據，這樣能夠讓測試用例得到最大的復用，也就是不同的業務流可能使用同一個測試用例。
但是目前，在設計中也出現了一些問題，例如，在設計這些場景時，還是需要花費大量的時間，因為場景非常多，只能先設計典型業務場景，再考慮特殊情況。
該方法是我根據銀行項目的特點以及對質量的要求設計的，以求達到對業務功能的復蓋。
