自动化认识(三)

产品稳定期自动化测试方案

 

一、概述

移动App产品更新速度太快,尤其是产品前期阶段,UI及逻辑功能调整频繁,自动化测试很难跟上测试要求,将大量精力用于手动用例自动化并不太现实,于是自动化测试本身定位于少量用例自动化满足主要功能覆盖,性能测试,压力测试,稳定性测试等;但随着产品进入稳定期,产品功能趋于完善,UI及逻辑功能调整幅度变小,可以适时调整思路着眼于将手动用例自动化,以降低手动测试成本,加快测试速度。

整个思路如下:整理现有手动用例库,筛选可被自动化用例组建自动化用例库,编码完成这些用例,以降低每次测试迭代中手动用例数量。就目前我们组流程而言,每次发版都在下班时间点,晚上这段时间可以批量运行自动化用例,如果单个用例成功率超过80%,则可视为该用例成功,否则判定失败,第二天上班后自动化人员查看失败用例,对失败用例进行手动验证,并根据失败情况修复完善测试代码,以此为一个自动化迭代周期。假设一共有1000条用例,400条可用于自动化,即使自动化用例成功率在80%,也可以为每轮测试减少320条的量,每次测试迭代中减少了32%的量,这是非常可观的。

 
   

 

 

 自动化认识(三)_第1张图片

      就一个版本内测试周期准备期而言,一旦产品文档定版,就开始进入用例设计,筛选修改老测试用例,组建新版本测试用例计划,与此同时自动化可以针对产品文档着手准备控件定义层(POM层)伪实现,调整公用方法逻辑层(LFM层)和用例层代码,并对新版本测试用例计划进行筛选,着手新一轮自动化测试用例代码编写和维护工作,一旦新版开发完毕,可以迅速实现POM层,调试测试代码逻辑,完成上述自动化测试迭代。

 自动化认识(三)_第2张图片

二、项目要求

实施上述流程对项目管理,用例管理,自动化测试人员和框架工具提出了更高的要求:

  • 项目管理,整个流程对时间要求和团队沟通配合要求十分严格,尤其是准备期阶段,这就要求测试管理人员针对流程各个阶段在项目管理更加精细,把控能力更强;
  • 用例管理是整个流程实施的基础,我们有两个用例库需要维护,总的测试计划库和自动化测试计划库(子库),不仅要求库里每个用例步骤和验证点写得更加详尽,还要求每次制定测试计划时针对版本修正即使对库里用例进行维护,这对用例管理也提出了更高的要求;
  • 另外我们还要保证自动化用例执行的成功率以及验证点的正确性,要满足代码持续集成迭代的要求,这对自动化人员编码能力提出了更高的要求,有条件的话必须引入code review;
  • 整个流程中要用到测试用例管理,自动化代码持续集成,自动化框架和自动化执行框架等各种辅助工具,市面上的一些工具并不能完全满足需求,要自主研发和进行二次开发。

三、风险及限制

  • 这一切流程都基于每个版本迭代尽可能小,尤其是UI及页面跳转逻辑,至少得保证每次小幅改动页面(逻辑基本不变,UI变动少于3处)不超过5个,大幅改动页面不能超过2个,新增页面虽然对原有测试代码影响较小,但最好不能超过4个。
  • 自动化最难的点仍然在于结果验证,其不可能做到人眼验证那么准确,这对自动化覆盖率有直接的影响,也要求用例描述更加详尽。
  • 要统计详尽的自动化通过率,需要批量多次执行用例,这就对设备个数提出了要求

 

 

 

你可能感兴趣的:(自动化)