情境測試法
定義
實例
美國學者哈特遜和梅所設計的“誠實測驗”（CEI）給被測評者提供各種可以乘隙作弊、伺機說謊甚至是可以從中行竊的機會，通過觀察被測評者在這些情境下的行為反應，對其誠實性給予評定。 例如，教師在考試後收回試卷，對學生的試卷進行批改並記錄學生的成績，但在卷面上不做任何標記。之後，教師將中外學生品德測評的比較研究試捲髮給學生，在宣讀正確答案的同時讓學生自己評分，如果學生改動了自己的答卷或評分結果與教師所記錄的分數差別很大，說明這位學生不夠誠實。
中國學者也曾設計了評價學生誠實和公正的情境測試。例如，將兩個玻璃球放在一個碗裡，要求被試在半分鐘內，用筷子將球夾到距離5公分的另一個空碗裡，每夾過去一個球獎給一張畫片，但不得用手拿。測試時主試不在場，讓被試單獨玩這個遊戲。主試通過單向孔觀察被試半分鐘內的活動，如發現不誠實者，可對其進行個別教育。
再如，給被測評者每人10張彩色手工紙，要求被測評者將這10張彩色手工紙平 均分配給包括自己在內的3個人，規定不得將紙張撕開進行分配。在分配前，告訴負責分配的被測評者，分完後，分給自己的一份就歸自己所有了。通過這個測試，可以反映出被測評者是否做到先人後己。
情景測試的方法
情境測試法可以將品德測評與遊戲或日常生活結合起來，其設計巧妙，即實施了專門的品德測評，又不容易被測評者察覺到測評者的真正目的。
在測評時，應該注意精心設計，首先要注意測評目的的隱蔽性，防止被測評者只是按公認的社會規則行事；其次，要注意情境設計的巧妙性，精心設計每一個環節；再次，我們也可以考慮把多個情境結合起來，從而在整體上提高這種測評方法的信度和效度。
應聘中的情景測試
簡介
應聘時，人力資源經常會使用此法，假定一定的情景，將應聘者置身其中。根據應聘者的回答測試出應聘者各種素質和反應能力。
實例
La有一份很重要的契約遞上去已經2天了，但是Z總到現在還沒有回覆，合作方又催得很緊，La實在沒有辦法，決定硬著頭皮去找Z總問問。一進門La問道：“您好，Z總。前兩天我交給您的檔案簽了嗎？”Z總想了想，然後翻箱倒櫃，最後攤開雙手：“對不起，我從未見過你的檔案。”
這不是睜著眼說瞎話嗎？如果你是La，你會怎么說呢？
A．“張總，前兩天給您的時候，我看著您將檔案擺在桌子上了，要不您再想想？”
B．“對不起，是我的問題，我回去找找那份檔案。”
C．“我明明給您了！”
實例簡析
A．你的回答將把你放在一個非常危險的境地。你的上司當然記得你把檔案給他了，要不然也不會翻箱倒櫃的去找，這時跟你說他沒有見過，只是想維護自己的尊嚴罷了。你如果還不識相繼續為了他“冤枉”你這件事情而堅持，那你真是大錯特錯了。好在你的說法還比較委婉，也算是給自己留了退路。
B．聰明的回答。你明白在公司工作，有時候受到一點小小的委屈時正常的。
C．你的做法太危險了！這樣不給你的上司面子。給你的建議是：如果上司錯了，開動腦筋為上司尋找一個下台的台階，無論如何解決衝突的前提是合作！當你把檔案重新列印一份拿給他的時候，他一定不會特別為難你的，反而會積極配合你的工作，畢竟就這件事情而言，他心裡非常清楚，你是為了照顧他的顏面而受到委屈了！
軟體中的情景測試
理想的情景測試方法應該具備的一些特徵
1）測試是基於一個用戶如何使用程式的場景，其中包括使用人員是如何被鼓勵參與到程式的使用當中的。
2）場景是具有激發性的。利益相關者可能會給開發人員壓力去改變程式。但這些改變恰恰會使測試失敗。
3）場景是可信的。它不僅僅可能發生在現實世界裡，它還要使利益相關者相信像這樣的事情會發生。
4）場景包含了程式的複雜使用或者一個複雜的環境或者一個負責的數據集。
5）測試結果容易被評估。這點是對所有的測試都意義重大，但是它對情景測試尤為重要，因為情景測試用例相對複雜。
為什麼使用情景測試？
1） 學習產品
2）把測試聯繫到歸檔的需求中來
3）為了實現想要的好處，使不足暴露出來
4）從專家的角度，探索使用程式
5）使一個缺陷報告更有說服力
6）把一些需求的問題提到表面，這些問題可能引發一些對曾經討論過的需求的重新討論（用新的數據）或者還沒有被認同的未浮出水面的需求。
情景定義
設計情景測試像是需求分析，但又不是需求分析。他們依賴於相似的信息但是用法卻大不相同。
1）需求分析人員試圖促成關於要創建的系統的協定。測試人員是開拓一些不同意見去預見系統可能遇到的問題。
2）測試人員並不需要一定得到結論或者制定關於產品應該如何 工作的建議。他的任務是曝露出一些可信的擔心給產品利益相關人。
3）測試人員不必要做出產品設計的折中方案。他陳述這些折中方案的推論，尤其是那些意料之外或是相對期望的結果更嚴重的推論。
4）測試人員不必要尊重之前所達成的一致。（當心：堅持強調錯誤問題的測試人員將失去可信度）
5）情景測試的工作不需要窮盡，只是有用。
創建好的情景測試用例的十六種方法
1）寫出系統中對象的生存軌跡。對象是如何創建的，它發生了什麼，怎么用它怎么修改它，怎么和它互動，什麼時候它被毀壞或是移除？
2）列出可能的用戶，分析他們的興趣和目的。
3）考慮一下不利的用戶，他們為什麼會濫用你的系統？
4）列出系統事件。系統是怎么處理他們的？
5）列出特殊事件。系統是怎么調節這些事情發生的？
6）列出好處點，然後創建點對點流程一項一項去檢查。
7）看看用戶試圖完成的特殊執行，例如關掉一個正在發請求的頁面。什麼是期望的數據，輸出，顯示等。
8）那些表單是和用戶互動的？針對他們試試增刪改查功能。
9）採訪客戶，了解用戶最常遇到的挑戰和系統失敗的例子。
10）在用戶旁邊看其操作，看看他們具體是怎么做的。
11）去試試競爭產品，看看相似系統是怎么做的。
12）了解以前做這個產品的人對它的抱怨，或者他的競爭者對它的不滿。
13）創建一個假的業務。把它看成是真的，處理數據。
14）試著從一個競爭的應用程式或者前面人用過的系統中轉換真實數據。
15）看看競爭程式中的輸出。你是如何在你的應用程式中創建這些報告，對象，任何東西的？
16）查看序列：用戶（或者系統）依照一定的順序做一個典型的任務X，為了達到完成任務X的目的， 最常見的子任務的序列是什麼？
情景測試的風險
1）其他的測試方法更適合在測試的早期進行，代碼不穩定的時候。
① 一個場景很複雜，將會涉及很多功能。如果第一個功能被破壞了，其他的測試將不能進行。一旦這個功能被修復，後面一個被破壞的功能又會阻礙測試。
② 在場景測試之前，每個功能模組的測試是分開的，這樣一旦他們出現，就可以很有效的暴露問題所在。
2）場景測試並不能用來做程式覆蓋測試
它主要關注點通過一系列的用戶場景來覆蓋所有的功能或者需求。簡單的語句覆蓋率不能用這種方式達到。
3)重複使用場景可能沒有很強的立足點，效率比較低。
① 歸檔以及重複使用場景看上去是高效的做法，因為我們在創建一個好的用戶場景上花費了很多工作。
② 場景經常會暴露出設計的缺陷，我們很快可以知道什麼是測試對設計的幫助。
③ 情景測試會暴露一些代碼錯誤，因為他們連線了很多功能和很多數據。為了覆蓋更多的關聯，我們需要創建新的測試。
④ 做回歸測試，要用單一的功能測試或者單元測試，而不是情景測試。
