本篇文章主要讲述软件测试技术之敏捷测试-验收测试及自动化测试，希望阅读本篇文章以后大家有所收获，帮助大家对相关内容的理解更加深入。

　　引言：在软件测试中，验收测试是针对很多项目进行的一个过程，在这个过程中涉及到很多，其中包括敏捷项目，下面就来介绍一下敏捷项目中的验收测试设计是如何运作的。

　　验收测试在传统的软件产品开发中由业务部门代表或客户代表进行，一般情况验收测试的设计和案例编写也是由业务部门代表或客户来完成的。通俗的讲，在研发团队中一般称呼业务代表或客户代表为业务老师。在敏捷项目中，产品负责人对应为传统项目中的业务老师。验收设计和验收案例一般由产品负责人和敏捷研发团队一起确定，产品负责人给出验收测试的用户使用场景，敏捷研发团队负责把场景传化为测试案例和对应的自动化测试代码。

　　我们首先介绍在传统项目中验收测试设计是如何进行的。我们之所以要讲传统项目中的验收测试，是因为根据以往的敏捷项目经验，有很多在传统项目中的测试技巧在敏捷项目中还是可以使用的，并且也是敏捷项目测试获得成功的基石。敏捷项目中的很多技术和技巧来源于传统项目，敏捷管理方法不是凭空产生的，除了项目管理思想与传统项目差别较大之外。敏捷项目中的技能和技术需要从传统项目中继承过来。这样才能保证从传统项目到敏捷项目管理方法的转型过程中项目成功的可靠性。

　　我们首先确定一下验收测试的设计思想，作为我们的的验收测试指导原则。这个原则同样适用于接口测试、单元测试等其他类型的测试。

　　验收测试指导思想：

　　在当前大规模的软件系统生产过程中，软件测试是无法找到全部缺陷的。

　　发现大规模系统中的所有缺陷是一个无限期的工作。

　　测试的关键，就是测试的覆盖。

　　测试覆盖模型如图1所示。

　　图1 测试覆盖模型

　　从图1可以看出，如果想在测试中发现全部缺陷，将是一个无穷无尽的工作，在现实情况下时间、投资、人员等都是有限的，不可能毫无规则和目的的一直测下去。验收测试应该有验收的目标，为达到目标应该有规划，设计和计划。验收测试目标应该根据被验收系统的特性来确定，目标最终转化为可以衡量和检验的指标。例如业务场景覆盖率、功能覆盖率、缺陷率、允许遗留各等级的缺陷数。

　　举例来说，作为一个银行软件的验收，因为涉及客户资产的安全，高等级缺陷不允许带入生成环境，只能允许少许的建议类缺陷，这些被允许遗留的缺陷当然是应该经过相关需求负责人和专业人员评估后才能被允许遗留的。每个机构对缺陷等级的表示可能不一致，例如有的机构使用 A/B/C/D/E 等字母表示五个缺陷等级。有的机构也许划分为4个缺陷等级，也许用数字 1/2/3/4 等表述。每个缺陷等级应该是所有相关利益相关者都容易理解的描述。

　　为了确保验收测试的质量，验收测试的测试案例应该覆盖用户可能使用的场景，保证验收测试案例对于功能点的覆盖。下面是根据工作经验总结出的测试案例设计指导思想。

　　传统测试案例设计指导思想

　　使用 WBS 方法编写测试大纲，保证测试的骨干范围。

　　使用用户场景描述，保证测试覆盖的重心不偏离。

　　对业务流程和数据流程进行分析，保证测试数据的全面性。

　　依据被测试部分的关键性和复杂度，选择不同的测试设计方法。

　　对用户的业务特征、数据特征和角色权限进行流程设计，保证测试与实际应用一致。

　　根据用户需求、被测功能的重要性、复杂性和测试执行的要求，对测试案例按优先级进行分类，不同阶段执行不同用例。

　　执行质量评审活动，保证测试案例设计准确性。

　　敏捷软件测试设计实践

　　敏捷项目中可以首先使用 WBS（工作分解）的思路和方法，把较大的产品特性、用户故事拆分为可以用来指导验收测试的用户场景描述，如图2所示。

　　继续小明童鞋的故事：

　　小明童鞋的敏捷团队收到了一个用户需求：增加常旅客积分积累和使用功能，通过我们公司电子商务网站或相关渠道购买机票的旅客可以积累里程积分。这些积分可以在下次购买机票时使用积分购买机票，也可以设置积分共享，让他（她）的亲友使用自己的积分购买机票。

　　这段需求描述可以分为多个用户故事，例如常旅客购票累积积分、常旅客使用积分购票、常旅客设置积分共享、常旅客亲友使用其积分购票等等。

　　图2 需求分析（WBS)

　　引入用户故事场景描述，在具体测试用例设计前，有效地加强了对用户业务的理解，并使得测试用例评审具有较好的效果（提示：这也是敏捷项目中用户故事描述的重要思想）。

　　产品负责人和敏捷团队约定上午10:00在“笑傲江湖”会议室召开用户故事梳理会议，讨论用户故事和验收测试，见图3所示的用户故事梳理图。

　　图3 所示的用户故事梳理图

　　用户故事梳理会上，产品负责人和敏捷团队一起对用户故事进行了分析，并针对每个用户故事描述了用户可能使用的场景。用户故事场景按照敏捷项目约定的格式进行描述，例如常旅客使用积分购票这个用户故事。场景描述如下：

　　功能：常旅客使用积分购票。

　　背景：常旅客可以使用已有的积分购买机票，可以为常旅客提供购票优惠。

　　场景：常旅客购买打折机票。

　　假如：我的账号积分中有累积积分10000分，积分兑换比为10个积分等于1元人民币，电子商务网站从上海虹桥到北京首都国际机场的飞机票价格为890元。当我购买上海到北京的飞机票时，选择了兑换1000积分，那么我应该支付的人民币是790元。

　　梳理出用户故事的使用场景后，根据用户场景我们就可以开始用户故事自动化验收测试的工作了。我们这里引入 BDD（Behavior Driven Development）自动化测试的框架 Cucumber。Cucumber 中使用关键字把自然原因描述的用户故事场景自动转化为计算机编程语言，例如 Java、JavaScript、Ruby 等。Cucumber 常用关键字如图4所示：

　　图4 Cucumber 常用关键字

　　Cucumber 支持中文关键字，因此可以根据团队的喜好，选择使用中文关键字，或使用英文关键字。在用户故事梳理中描述的测试场景写在 Cucumber 的特性文件中就形成了验收测试的测试用例。例如小明童鞋团队的常旅客使用积分购票用户场景的测试用例格式描述如图5所示：

　　图5 验收测试用例描述

　　使用 Cucumber 自动化转换为 Java 自动化测试框架，提高自动化测试代码的编写效率。常旅客购买打折机票的测试用例代码如图6所示：

　　图6 常旅客购买打折机票

　　如果我们验收测试时用户界面是网页，我们可以使用 Selenium 实现对网页的交互测试，如果是移动 App 应用我们可以选择 Appium 实现对 Android 或 iOS 移动应用的操作。

　　上面是我介绍的关于敏捷测试中的验收测试，相信大家也都有一定的了解，如果童鞋们对这个感兴趣，除了在网站和书籍方面查找外，还有一种途径，就是考取一个证书，这个证书叫ISTQB，它是一个含金量高的证书，敏捷测试工程师可以考取它来提升自己的含金量，想必对于童鞋们来说也是非常不错的选择！

本文由职坐标整理发布，学习更多的相关知识，请关注职坐标IT知识库！