之前翻譯過一篇關於情景測試的文章link，因爲現在我所在的項目的測試到了膠着階段,因此又提及情景測試。所謂膠着，自是因爲項目開發到了相對穩定階段，測試也用很多種方式進了了幾次了，如迴歸測試、全覆蓋測試等等，現在進入了效果不明顯的階段。因爲開發人員還在修bug，所以測試人員自是不能掉以輕心。但是，這個時候，測試人員效率不高，迴歸測試的具體執行不一定完全。那麼，怎麼調動測試人員的積極性，繼續測試，又怎麼能提高大家的測試效率，而不是一輪輪拿着測試用例浪費時間？
我想很多優秀的全局的測試方法可以在這個階段使用。情景測試自是一個。每每談及情景測試，就會覺得興趣盎然，因爲這個時候你可以跳出來，看看產品整體，完全從一個使用者的角度去看去想。雖然，測試人員時時都應該抱有全局觀，但是在做任務的時候難免顧此失彼。想來，情景測試也可以在項目收尾的時候，讓我們從整體上有個把握。
下面是我2008年5月曾第一次在組裏推廣的情景測試方法。情景的定義不是件容易的事情，如果定義的好，會達到很好的測試效果。不但可以找到一些遺漏的功能缺陷，也可提出些可用性方面的改善。以下提到的也許在現實角度不能完全實現，但是多數是可以受益的。這些方法理論是從很多英文資料翻譯來的。原本把原文也貼了上來的，但是日誌字數過多，被阻止發佈。如果有人想要看英文資料，請留言，我會把它整理髮到你的郵箱裏。
理想的情景測試方法應該具備的一些特徵
· 測試是基於一個用戶如何使用程序的場景，其中包括使用人員是如何被鼓勵參與到程序的使用當中的。
· 場景是具有激發性的。利益相關者可能會給開發人員壓力去改變程序。但這些改變恰恰會使測試失敗。
· 場景是可信的。它不僅僅可能發生在現實世界裏，它還要使利益相關者相信像這樣的事情會發生。
· 場景包含了程序的複雜使用或者一個複雜的環境或者一個負責的數據集。
· 測試結果容易被評估。這點是對所有的測試都意義重大，但是它對情景測試尤爲重要，因爲情景測試用例相對複雜。
爲什麼使用情景測試？
· 學習產品
· 把測試聯繫到歸檔的需求中來
· 爲了實現想要的好處，使不足暴露出來
· 從專家的角度，探索使用程序
· 使一個缺陷報告更有說服力
· 把一些需求的問題提到表面，這些問題可能引發一些對曾經討論過的需求的重新討論（用新的數據）或者還沒有被認同的未浮出水面的需求。
情景定義
設計情景測試像是需求分析，但又不是需求分析。他們依賴於相似的信息但是用法卻大不相同。
· 需求分析人員試圖促成關於要創建的系統的協定。測試人員是開拓一些不同意見去預見系統可能遇到的問題。
· 測試人員並不需要一定得到結論或者制定關於產品應該如何工作的建議。他的任務是曝露出一些可信的擔心給產品利益相關人。
· 測試人員不必要做出產品設計的折中方案。他陳述這些折中方案的推論，尤其是那些意料之外或是相對期望的結果更嚴重的推論。
· 測試人員不必要尊重之前所達成的一致。（當心：堅持強調錯誤問題的測試人員將失去可信度）
· 情景測試的工作不需要窮盡，只是有用。
創建好的情景測試用例的十六種方法
1. 寫出系統中對象的生存軌跡。對象是如何創建的，它發生了什麼，怎麼用它怎麼修改它，怎麼和它交互，什麼時候它被毀壞或是移除？
2. 列出可能的用戶，分析他們的興趣和目的。
3. 考慮一下不利的用戶，他們爲什麼會濫用你的系統？
4. 列出系統事件。系統是怎麼處理他們的？
5. 列出特殊事件。系統是怎麼調節這些事情發生的？
6. 列出好處點，然後創建點對點流程一項一項去檢查。
7. 看看用戶試圖完成的特殊執行，例如關掉一個正在發請求的頁面。什麼是期望的數據，輸出，顯示等。
8. 那些表單是和用戶交互的？針對他們試試增刪改查功能。
9. 採訪客戶，瞭解用戶最常遇到的挑戰和系統失敗的例子。
10. 在用戶旁邊看其操作，看看他們具體是怎麼做的。
11. 去試試競爭產品，看看相似系統是怎麼做的。
12. 瞭解以前做這個產品的人對它的抱怨，或者他的競爭者對它的不滿。
13. 創建一個假的業務。把它看成是真的，處理數據。
14. 試着從一個競爭的應用程序或者前面人用過的系統中轉換真實數據。
15. 看看競爭程序中的輸出。你是如何在你的應用程序中創建這些報告，對象，任何東西的？
16. 查看序列：用戶（或者系統）依照一定的順序做一個典型的任務X，爲了達到完成任務X的目的， 最常見的子任務的序列是什麼？
情景測試的風險
· 其他的測試方法更適合在測試的早期進行，代碼不穩定的時候。
§ 一個場景很複雜，將會涉及很多功能。如果第一個功能被破壞了，其他的測試將不能進行。一旦這個功能被修復，後面一個被破壞的功能又會阻礙測試。
§ 在場景測試之前，每個功能模塊的測試是分開的，這樣一旦他們出現，就可以很有效的暴露問題所在。
· 場景測試並不能用來做程序覆蓋測試
§ 它主要關注點通過一系列的用戶場景來覆蓋所有的功能或者需求。簡單的語句覆蓋率不能用這種方式達到。
· 重複使用場景可能沒有很強的立足點，效率比較低。
§ 歸檔以及重複使用場景看上去是高效的做法，因爲我們在創建一個好的用戶場景上花費了很多工作。
§ 場景經常會暴露出設計的缺陷，我們很快可以知道什麼是測試對設計的幫助。
§ 情景測試會暴露一些代碼錯誤，因爲他們連接了很多功能和很多數據。爲了覆蓋更多的關聯，我們需要創建新的測試。
§ 做迴歸測試，要用單一的功能測試或者單元測試，而不是情景測試。