从上面的例子可以看出，在验收用例的设计过程中我们仍然使用边界值法、场景法等常用的测试用例设计方法。但是，验收测试用例的选取和设计是从 Story 给利益干系人（上述例子涉及的银行储户和银行）提供的价值为准绳。它通常覆盖一些正常业务场景，但也覆盖一些重要的异常业务场景（如上述例子的用例 4）。而有些无效等价类测试用例，虽然它们可以用于测试软件的健壮性，但在真实环境下这些用例所描述的情形往往不可能出现。因此，这些无效等价类测试用例一般都不作为验收测试用例，而只是作为后面的 Story 测试用例。比如上例中，在真实的 ATM 环境下由于输入设备的限制，取款人无法输入“abc”这样的取款金额值，因此取款金额为“abc”这样的无效等价类测试用例则不列入验收测试用例。

　　Story 演示的主动权和表决权

　　Story 演示中的测试用例是由开发人员执行的。在演示过程中，对于每条验收测试用例，开发人员会向测试人员展示和讲解其预置条件以及实际结果与期望结果的吻合。而测试人员在此过程中则评估预置条件的正确性和充分性，并复核实际结果与期望结果是否真正吻合，进而判断相应用例是否真正通过。并记录每条用例的通过情况。开发测试人员在此时也可以一起重新评估下事先设计的验收测试用例覆盖是否充分，是否有所遗漏。因为此时开发人员已经经历了该 Story 的编码，测试人员已经在编写自动化测试用例脚本了，大家对 Story 的理解较之前有了更丰富的背景因而能够发现事先所不能考虑到的测试用例。

　　在没有意识到 Story 演示给我们带来的长期利益（强化开发人员的质量意识和促进开发人员的持续改进）的情况下，测试人员往往倾向于从开发人员手上“抢过”主动权，自行执行演示测试用例。此时，本来应该是演示的活动“退化”成了检查——测试人员去检查开发人员的工作产出是否满足低质量要求。这样实施，事实上只是发挥了演示的短期利益，而没有把其长期利益发挥出来。要发挥演示的长期利益，必须由开发人员执行测试用例，这样才能增加其自行发现问题的机会，有利于其避免问题重复出现从而促进其持续改进。

　　Story 演示作为一种转测试入口控制措施，其通过与否要由测试人员来决定。测试人员在演示过程中会记录每个用例的执行通过情况。演示结束后根据执行未通过的用例数量和这些用例所暴露的问题的严重程度综合考虑演示是否通过。只有通过演示的 Story 才允许进行转 Story 测试。

　　控制 Story 演示成本

　　在 Story 演示给我们带来收益的同时，它也会产生成本。因此演示过程中要注意控制成本。

　　首先，Story 演示中执行的测试用例并不是该 Story 的全部测试用例，而是其中的验收测试用例。这意味着从所执行的用例的数量上控制演示的成本。因此，我们可以在 Story 测试用例设计时把其中符合验收测试用例选取原则的用例标记为验收测试用例，在后面演示时可以直接使用。

　　另外，测试人员在演示过程中要根据当前所发现的用例执行不通过的情况及其暴露出来的问题的数量和严重程度及时决定演示是否继续还是停止，等问题修复用户再重新演示。如果演示过程中所发现的低级问题或者严重问题比较多，说明 Story 演示准备得不充分，此时应及时停止演示，避免浪费时间。并由开发测试人员约定好再次演示的时间。

　　同时，也要注意控制每个 Story 演示的次数。一个 Story 演示的次数通常要控制在三次以内，避免过多的演示浪费时间。

　　Story 演示结果的登记与公布

　　Story 演示的结果要由测试人员及时登记并提交到配置库上，供后面迭代回顾时对 Story 演示活动进行分析与总结，以便对下一个迭代的 Story 演示活动提出改进措施。同时，通过比较两次迭代的 Story 演示结果可以明确开发质量是否有所提升，开发人员是否在进步。

　　每个 Story 的演示结果参与演示的测试人员要及时知会到全体成员。演示的结果包括通过、不通过和待确认。对于一次性演示通过的 Story，在知会演示结果时测试人员要及时对相应开发人员的高质量工作表示肯定和感谢以提高开发人员的成感，正是他们的高质量工作降低了测试人员的工作量（降低了对一个 Story 多次进行测试的可能性）。对于未过演示的 Story 及时进行知会可以提醒开发人员及时保质量地修复问题，避免同一个 Story 演示次数过多而增加演示成本。

　　Story 演示结果可以在状态墙上知会，也可以使用即时通讯工具进行知会。

　　表 1 是一个 Story 演示记录的样例。

表 1. Story 演示记录样例

　　总结

　　本文从引入 Story 演示所期望的收益入手，分享了具体实施 Story 演示活动的注意要点，以及如何控制 Story 演示的成本。Story 演示能够给敏捷团队带来的好处或者预期收益是其“意”，而采用什么样形式去实施 Story 演示以便获得预期收益是其“形”。“意”是引入一个具体实践的目的和意图，而“形”是如何落实一个具体实践的形式。“意”决定了“形”，而“形”要符合“意”的要求。同时，Story 演示活动中开发人员、测试人员紧密协作，这体现了敏捷开发中“个人与交互胜过过程于工具”的价值观。因此，本文同时也是在分享一种敏捷开发的思想。