作為測試人員，編寫測試用例是我們的核心，他最重要的作用就是讓我們跟著測試用例測試，不會遺忘一個測試的功能點。在現實的設計用例環節來說，做到很好的測試用例對我個人來說是很難的。尤其是場景測試用例設計。
本文不以概念和一些教科書似的例子來講解場景測試和業務測試的相互關系。以一個輕松交流的方式來總結場景測試的流程。當今很多產品不再是單一的互聯網或者是獨立產品作為測試的對象，往往跟多個模塊進行配合測試。即使有嚴格的規格說明書，事件流的測試也是不能忽視。
為什么要用場景測試用例：
因為用等價，邊界等設計方法對于一些流程較多或者對于沒有需求規格書來說，是非常難做到的，尤其是邏輯性比較強的嵌入式產品。他的邊界值往往都要到性能測試的性能kpi和壓力2個測試點才能夠觀察到。
測試階段中什么時候用場景測試：
在產品開發階段和測試階段同步進行時（說正規點是敏捷，說不正規點是趕工，個人意見），還有單元測試或者單個模塊測試完畢后。
場景測試用例設計的困難點：
1、需求不足和邏輯關系較多的時候。這里需要展開來講。很多時候我是不得不用到場景測試法。因為需求規格書不足和該產品從等價，邊界等測試用例方法是設 計不出有效的測試用例。流程和涉及產品較多，對比網上的場景用例實例，現實中使用場景用例的流程往往復雜很多，單單了解流程都很吃力。
2、設計事件流的過程中很容易設計出沉余的測試用例，因為就算每個流的條件不一樣，但是你實際測試過程中使用的手法和觀察點確是一樣的。難就難在這用正交法是很難瘦身這類的用例，只能通過測試來慢慢優化該用例，流程關注點越多，重復的幾率就更多。
為什么我既愛又恨場景測試法：
對于我來說，場景測試法既是我用最多的測試法也是我最不想用的設計方法。作為測試人員在長期的測試過程中，你會慢慢變得很懂內部原理，尤其是你轉化為自動化測試后，甚至做到一個確定鍵報錯都會聯想到這是數據庫和web的存儲過程入參不一致導致的境界。好處是你可以測試出很多底層的東西，壞處是經過你測試的產品，功能很多，但是卻不好用。因為我忽略了我是一個用戶的角度去測試，而是一個開發測試開發的東西。
場景測試讓我找到了平衡點，我知道了這東西的流程，可以在了解中提出改進建議，對產品有了很深的了解。讓我從自動化測試中拉回來一點點。為什么我會不想 用的此種設計方法。他很考你的經驗和總結能力，同上面所說你缺乏需求規格書的時候，你就是用想來寫用例。所以當別人表揚我測試不少用例以外的關鍵Bug的時候，我是高興我的有好的測試經驗還是我寫出了差的測試用例。
對于做測試有一定年頭的人，項目組對你的要求不再是了解普通的測試流程，還有很多里面的原理，設計，方案，進度。場景測試設計的時候你就要把關，我設計 的是多深入的測試用例？能否根據你項目的期望來測試出關鍵的bug。好比我測試的是web的流程，但是項目關注的后臺的處理流程。實際情況中，你設計場景 用例的時候不再是培訓那套理論和”真理”。
通過以上可以看出，為什么有些業務測試工程師比自動化，性能，甚至開發的地位都要高。例如銀行，無線通信業務中，手工的測試手法非常多，同樣的產品不同的人測出的效果不一樣。體現出現的就是業務流程的能力，部分情況下就是場景測試設計的功力。
總結，作為一個測試人員的我的目標測試周期，第一了解產品的應用架構，第二了解產品使用的業務流程，第三總結業務流，第四根據業務流跟各個開發組了解設計流程，第五寫出按需求的自動化測試的架構，第六寫出場景測試用例，第七進行系統測試，第八進行細節的自動化用例編寫，第九進行自動化測試，第十出測試報告和測試周期的自我”性能調優”總結文檔。
這篇就是我的場景測試總結文檔。