業務、開發和測試看似是不同的個體，但實際上他們的工作是緊密聯系的。測試人員往往在開發階段就拿到業務需求說明書，開始編寫測試用例，這無疑會降低測試效率。需求評審有助於快速全面地了解客戶需求，這將節省後續測試人員了解業務需求的時間，並且可以在會上明確測試的重點和難點，通過討論找到解決方案。
2.借助業務流程圖編寫測試用例。
對於壹些復雜的需求，由於其分支路徑較多，測試時很容易忽略個別情況。這時候盡量根據業務需求畫出業務流程圖，或者詢問開發人員編碼時是否參考了相關的業務流程圖。業務流程圖可以直觀、清晰地顯示每個分支路徑的情況，有效避免測試用例不完整的現象。
比如我在測試對公賬戶凍結相關交易的優化時，根據短短幾行的業務需求，畫了壹個極其復雜的業務流程圖。下圖是壹個簡單的版本，重點介紹了部分凍結和強制扣款的業務邏輯，相關公式和數字用字母代替。對於這樣的需求，如果不畫圖或者制表，很難設計出全面正確的測試用例。但是在和業務人員、開發人員討論，確定了詳細的業務流程圖之後，測試用例的編寫自然不會有遺漏。所以，對於多分支的業務需求，要善於畫圖，用圖表清晰地檢驗思路。
3.企業協會系統分析
在測試領域，對關聯系統的分析不足是變化的重要原因之壹。如果服務提供者系統的接口發生變化，則應根據情況調整調用該接口的相關消費者系統的功能，或者進行總回歸。因為跨系統調用往往涉及多個開發人員，大家對彼此的系統都不夠了解，所以相關性分析要特別嚴謹。
4.完整的業務場景
業務流程往往形成壹個閉環，包括開戶-激活-銷戶、凍結-繼續凍結-解凍、合同簽訂-維護-終止，所以業務場景要盡量完整。例如，間接費用賬戶的邏輯在設計時可能不同。開戶時並不判斷新開賬戶和轉出賬戶的客戶號是否壹致，而是要求支付和銷戶時客戶號壹致，因此存在可以開戶但不能銷戶等操作的風險。所以在案例設計中，雖然轉換點是開戶或者簽約，但是要盡量測試壹個完整的業務流程。
5.日期
日期是測試中壹個非常重要的因素。可能當天可以做的交易，切換記賬日期或者修改交易日期都會失敗。例如，測試多級賬簿余額調整時，如果原交易日期為當前會計日期，則交易信息正確，如果原交易日期早於當前會計日期，則收款方的多級賬簿號顯示錯誤，因為不同的交易日期對應不同的程序分支。所以在設計案例時，要充分考慮時間因素對交易的影響，分析是否需要設計各種日期值。
緩存數據
當對測試數據有嚴格要求時，比如恐怖主義相關信息，就要註意緩存數據的影響。比如先錄入並提交壹組有效數據，交易中途終止。此時交易信息不會被清空，然後會被修改成無效的測試數據，然後就成功了，這和業務需求是相悖的。所以當輸入內容有限制時，要保證緩存的數據會被及時清空或更新。
7.測試數據類型
測試數據的類型應該豐富。例如，如果轉換涉及已到期的臨時賬戶，則應驗證未到期的臨時賬戶、已到期的基本賬戶、已到期的壹般賬戶、已到期的特殊用戶、註冊資本驗證賬戶和已到期的外匯賬戶。通常，缺陷發生在關聯元素中，而不是轉換點本身，因為開發人員在編碼時只對轉換點進行單元測試，而關聯元素很容易被忽略。
8.憑證收據
憑證回單壹定要清晰直觀，交易成功後需要查看憑證回單的顯示。關鍵應該是在交易信息較大的情況下，檢查省略號替代的交易信息是否為重要信息，如金額、賬號等。，以及印章是否會遮擋壹些重要信息，是否有足夠的空間讓客戶簽字。