验收测试在传统的软件产品开发中由业务部门代表或客户代表进行，一般情况验收测试的设计和案例编写也是由业务部门代表或客户来完成的。通俗的讲，在研发团队中一般称呼业务代表或客户代表为业务老师。在敏捷项目中，产品负责人对应为传统项目中的业务老师。验收设计和验收案例一般由产品负责人和敏捷研发团队一起确定，产品负责人给出验收测试的用户使用场景，敏捷研发团队负责把场景传化为测试案例和对应的自动化测试代码。
我们首先介绍在传统项目中验收测试设计是如何进行的。我们之所以要讲传统项目中的验收测试，是因为根据以往的敏捷项目经验，有很多在传统项目中的测试技巧在敏捷项目中还是可以使用的，并且也是敏捷项目测试获得成功的基石。敏捷项目中的很多技术和技巧来源于传统项目，敏捷管理方法不是凭空产生的，除了项目管理思想与传统项目差别较大之外。敏捷项目中的技能和技术需要从传统项目中继承过来。这样才能从传统项目到敏捷项目管理方法的转型过程中项目成功的可靠性。
我们首先确定一下验收测试的设计思想，作为我们的的验收测试指导原则。这个原则同样适用于接口测试、单元测试等其他类型的测试。
从图1可以看出，如果想在测试中发现全部缺陷，将是一个无穷无尽的工作，在现实情况下时间、投资、人员等都是有限的，方逸华 子女不可能毫无规则和目的的一直测下去。验收测试应该有验收的目标，为达到目标应该有规划，设计和计划。验收测试目标应该根据被验收系统的特性来确定，目标最终为可以衡量和检验的指标。例如业务场景覆盖率、功能覆盖率、缺陷率、允许遗留各等级的缺陷数。
举例来说，作为一个银行软件的验收，因为涉及客户资产的安全，高等级缺陷不允许带入生成，只能允许少许的类缺陷，这些被允许遗留的缺陷当然是应该经过相关需求负责人和专业人员评估后才能被允许遗留的。每个机构对缺陷等级的表示可能不一致，例如有的机构使用 A/B/C/D/E 等字母表示五个缺陷等级。有的机构也许划分为4个缺陷等级，也许用数字 1/2/3/4 等表述。每个缺陷等级应该是所有相关利益相关者都容易理解的描述。
为了确保验收测试的质量，验收测试的测试案例应该覆盖用户可能使用的场景，验收测试案例对于功能点的覆盖。下面是根据工作经验总结出的测试案例设计指导思想。
小明童鞋的敏捷团队收到了一个用户需求：增加常旅客积分积累和使用功能，通过我们公司电子商务网站或相关渠道购买机票的旅客可以积累里程积分。这些积分可以在下次购买机票时使用积分购买机票，也可以设置积分共享，让他（她）的亲友使用自己的积分购买机票。
这段需求描述可以分为多个用户故事，例如常旅客购票累积积分、常旅客使用积分购票、常旅客设置积分共享、常旅客亲友使用其积分购票等等。
产品负责人和敏捷团队约定上午10:00在“笑傲江湖”会议室召开用户故事梳理会议，讨论用户故事和验收测试，见图3所示的用户故事梳理图。
用户故事梳理会上，产品负责人和敏捷团队一起对用户故事进行了分析，并针对每个用户故事描述了用户可能使用的场景。用户故事场景按照敏捷项目约定的格式进行描述，例如常旅客使用积分购票这个用户故事。场景描述如下：
假如：我的账号积分中有累积积分10000分，积分兑换比为10个积分等于1元人民币，电子商务网站从上海虹桥到首都国际机场的飞机票价格为890元。当我购买上海到的飞机票时，选择了兑换1000积分，那么我应该支付的人民币是790元。
梳理出用户故事的使用场景后，根据用户场景我们就可以开始用户故事自动化验收测试的工作了。我们这里引入 BDD（Behavior Driven Development）自动化测试的框架 Cucumber。Cucumber 中使用关键字把自然原因描述的用户故事场景自动为计算机编程语言，例如 Java、JavaScript、Ruby 等。Cucumber 常用关键字如图4所示：
Cucumber 支持中文关键字，因此可以根据团队的喜好，选择使用中文关键字，或使用英文关键字。在用户故事梳理中描述的测试场景写在 Cucumber 的特性文件中就形成了验收测试的测试用例。例如小明童鞋团队的常旅客使用积分购票用户场景的测试用例格式描述如图5所示：
使用 Cucumber 自动化转换为 Java 自动化测试框架，提高自动化测试代码的编写效率。常旅客购买打折机票的测试用例代码如图6所示：
如果我们验收测试时用户界面是网页，我们可以使用 Selenium 实现对网页的交互测试，如果是移动 App 应用我们可以选择 Appium 实现对 Android 或 iOS 移动应用的操作。具体 UI 自动化测试的实现细节我们在技术篇中接着聊。
本文由 325游戏（m.325games.com）整理发布