巧用自动化测试组合拳保证产品质量

“如何保证质量”一直是产品或项目过程中关注的焦点,而测试是产品质量把控环节中非常关键的部分。本文结合我们的实践经验,总结出一套有效的自动化测试组合拳。

一、背景

我们的测试工作经历了以下四个阶段。

第一阶段,产品需求评审完成,开发团队实现功能开发,然后草草提测,不写单元测试。测试人员进行人工测试,没有工具或系统做辅助,测试用例编写是在excel或脑图中呈现。这个阶段只对业务熟悉,开发只关注功能实现。

第二阶段,产品需求评审完成,开发团队实现功能开发,写自身功能相关的单元测试,组长review组内代码。测试方面,依然处于人工检测功能测试阶段,但开始有一些相关的小工具辅助测试。在两轮或多轮测试情况下,回归一直是一个问题,还有分支测试完成,主干回归的过程,测试环境、预发布环境、灰度环境、线上环境等测试回归效率很低,人工测试在这方面的不足格外明显。

第三阶段,随着业务的发展产品功能需要快速上线,同时系统技术不断迭代,质量也面临着从未有过的挑战,人肉战术不是长久之计。在此阶段部门做了很多改进,引入和开发了很多测试辅助工具,如项目管理工具、测试用例管理工具、BUG管理工具、自动发布系统、自动打包等。

  • 搭建测试用例管理工具,方便编写及后期跟踪用例。一轮二轮测试人员如何分配;用例状态的管理是通过、挂起还是失败,一目了然。
  • BUG管理工具,主要是给开发和测试人员使用,通过文字和图片结合的方式描述功能问题,减少了开发和测试的沟通成本。
  • 项目方面也开发出项目管理工具,方便查看项目状态和人力资源情况,在项目中做到很好的呈现。
  • 在此阶段我们开始研发UI自动化测试工具,直观的想法是减少人工测试成本,提高测试效率。
  • 自动化部署系统让开发环境、测试环境、灰度环境和线上环境做到很好的隔离,每个阶段更清晰,避免相互干扰引起的问题。
  • APP方面结合Jenkins可以实现自动打包,测试起来做到了开发和测试都以版本控制系统为主。

第四阶段,因为测试往往是最后一个环节,风险较大,“怎么实现降低风险提高人效,测试用例可以复用”变成了我们这个阶段的主要工作。之前的流程是开发完成提测,做一次冒烟。因为我们的产品是互联网金融APP,APP有服务端开发和前端开发,像web、wap、anroid、IOS等渠道,在研发过程中经常会出现以下场景:

  • 需求只是项目中的一小部分,测试问产品要不要全量测?产品担心这次需求的研发会影响到其他部分,就要求全量测试,于是测试的工期会拉得很长,拉长了需求的整个工期。
  • 测试抱怨开发的BUG多,还有阻塞流程的BUG,需要等待开发解决BUG后才能继续测试,导致整个测试工期加长。
  • 手工测试偶有疏忽造成漏测试的点,需求上线后,客户反馈BUG。

产品上线时间有deadline;测试时间长,挤占开发时间;测试人手不够;测试的准确性达不到要求…要解决这些问题,必然要做自动化测试方案。

针对业务和测试开发同事的特点,我们从单元测试、接口测试、UI自动化测试三个方面做了有效衔接和可持续使用的自动化测试方案。

服务端开发完成,接口测试开始介入。接口测试前期使用一些小工具,会在小工具里写一些脚本,来方便测试过程中的功能多次回归检验,是否有更好的方式来做这件事,于是我们搭建了接口自动化系统。之前测试是只对UI界面做功能测试,我们现在还实现了单元测试、UI自动化测试、接口自动化测试。

第五阶段,测试团队全部人员转型测开,部分成员处在人工测试和自动化测试的边界上,实际上我们一直在做内训,让团队整体能更快地转型成为一个测试开发团队。这个阶段对成员要求相对较高,主要技术语言是python,还要对基础的系统架构及运维知识有更多了解,团队内部正在开发测试项目看板、重写用例管理工具、升级接口自动化工具等,后期计划实现APP多设备管理及测试。还有一些测试没有提到,但也包括在主流程中,比如安全测试、兼容性测试、分辩率测试等。

目前项目的整体流程是这样的:

  • 产品通过DM上传PRD,参与人员熟悉需求。
  • 开需求分析会议,确定需求最终版。
  • 需求定稿后,开发人员抽象基础功能、编写UI部分,测试人员通过testlink写测试用例。
  • 测试用例编写完需要产品、开发、测试人员做测试用例评审。
  • 开发人员根据测试用例,编写自己具体业务的单元测试用例。前端人员和自动化测试人员制定UI自动化测试点,定义好断言字典和模拟用户行为的方法名称,自动化测试人员编写自动化测试case。
  • 开发人员开发的同时,接口测试人员根据接口文档,编写接口测试用例。
  • 所有编码工作完成,开发人员单元测试通过后,进行接口测试验证,再进行UI自动化测试验证。UI自动化测试既要测试当前需求点,也要回归以往的case。
  • 验证都通过后,手工测试人员介入。
  • 手工测试完毕,自动化CASE反复测试通过的情况下,进行上线。

接下来分别介绍团队在单元测试、服务层自动化测试、UI层自动化测试的具体技术实现。

二、单元测试

单元测试是对代码实现逻辑做测试,整体项目环节比较靠前,所以成本最小也最有效,但对开发人员的综合能力要求较高。

前端代码中,用户交互的部分交给UI自动化测试,而作为业务基础的类和方法,适用单元测试,我们项目使用测试库mocha和断言库chai,配合开发工具WEBST

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值