情境测试法指测评者设置一定的情境和标准，并观察被测评者在该情境中的反应，根据事先规定的标准对被测评者的品德发展状况做出评价的方法。

美国学者哈特逊和梅所设计的“诚实测验”（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）重复使用场景可能没有很强的立足点，效率比较低。

① 归档以及重复使用场景看上去是高效的做法，因为我们在创建一个好的用户场景上花费了很多工作。

② 场景经常会暴露出设计的缺陷，我们很快可以知道什么是测试对设计的帮助。

③ 情景测试会暴露一些代码错误，因为他们连接了很多功能和很多数据。为了覆盖更多的关联，我们需要创建新的测试。

④ 做回归测试，要用单一的功能测试或者单元测试，而不是情景测试。