十招玩转敏捷测试之第03课:设计篇——验收测试设计及 UI 自动化测试

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

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

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

验收测试指导思想:

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

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

  • 测试的关键,就是测试的覆盖。

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

图4-1 测试覆盖模型


图1 测试覆盖模型


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

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

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

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

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

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

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

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

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

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

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

敏捷软件测试设计实践

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

继续小明童鞋的故事:

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

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

需求分析


图2 需求分析(WBS)


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

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

图4-3 用户故事梳理图


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


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

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

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

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

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

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

图4-4 Cucumber常用关键字


图4 Cucumber 常用关键字


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

图4-5 验收测试用例描述


图5 验收测试用例描述


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

图4-5 验收测试用例-常旅客购买打折机票


图6 常旅客购买打折机票


如果我们验收测试时用户界面是网页,我们可以使用 Selenium 实现对网页的交互测试,如果是移动 App 应用我们可以选择 Appium 实现对 Android 或 iOS 移动应用的操作。具体 UI 自动化测试的实现细节我们在技术篇中接着聊。


GitBook达人课:十招玩转敏捷测试


敏捷社区微信公众号:

微信.jpg

敏捷测试微信公众号:

qrcode_for_gh_2d53be29b2f6_258.jpg

猜你喜欢

转载自blog.csdn.net/winteroak/article/details/80604935