作者 @散步的SUN

    序言：测试开发部门做自动化测试很容易脱离测试项目去做，仅仅为了做自动化测试而做。开发部门做自动化测试很容易考虑不够全面，但是在自动化测试开发、维护性和复用性以及可测性上结合比较好。测试部门去做自动化测试，对测试项目理解比较深，对自动化测试的应用也比较能理解，但是却无法开发应用比较好的自动化测试系统与框架为之服务，自动化测试只是作为测试的一种辅助手段，而每个人都术业有专攻，我们需要的是理性认识到自动化测试，不能本末倒置，以项目为驱动，将自动化测试与项目结合，真正将自动化测试在整个项目环节中应用起来。

     一、自动化测试开展在整个项目中存在的一些问题

    上一年度，总结和与各个产品和维护测试组的技术组长进行面对面交流，总结出来在项目测试中，自动化测试存在的几个问题和一些他们的想法。

     1、 产品测试组认为自动化测试开发效率过慢，新的产品开始进行测试时开始开发自动化测试脚本，赶不上测试项目的进度，有可能版本都迭代完了，自动化测试脚本还没有稳定下来，根本就指望不上。

     2、 维护测试组之前将自动化例行测试应用于维护测试项目中，之前耗费大量精力开发了大量的模块，后来却发现在版本迭代过程中，这些模块之中大多数都没有应用上，而开发关注的往往都是那些非常基本的功能模块。

      3、 产品测试组和维护测试组之前没有配合，各个组开发的业务测试脚本互相不知道，也很大程度导致了重复开发，并且开发出来的脚本不具有很好的迁移性，也间接到导致了自动化测试资源的浪费。

      4、 自动化测试度量不够量化，虽然年末也做了自动化测试指标度量，但是很多数据都是测试人员拍拍脑袋想出来，数据都不够量化，因此也不具有太多的说服力，而且在项目上的作用也不够突显。

    二、自动化测试与项目结合之路

    针对以上问题，如何改善，总结几点

    1、 将自动化测试真正融于到测试项目中去的方法就是在项目前期就要开始考虑自动化测试，而不是等到项目中或者项目后，这样就能保证自动化测试能够快速应用在测试项目中，具体方法如下：(当然，需要注意的是不推荐产品测试的前几个版本应用自动化测试)

     1） 分析测试项目周期，选择需求要自动化测试的模块

     2） 在项目前期加入自动化测试考虑和评审

     3） 在项目开始前，便开始对新的模块，基于测试点撰写关键字驱动测试方案，并生成关键字接口库，这里特别注意的是，在关键字驱动测试方案中要指明测试用例中还需要手工测试的比率和部分。

     4） 在测试用例完成的同时，基于测试用例组装开发业务脚本

     5） 在产品接口确定的同时，撰写关键字接口实现库，调试通过

     6） 自动化开始应用于项目，部署在测试系统上，实时统计与跟踪

     7） 项目完成，对项目中的自动化测试项目进行度量与分析(单个模块覆盖率、产品特性覆盖率、产品CBB率)

     8） 将项目完成的模块按需添加到例行测试环境

    2、 宁缺勿滥，精做与迭代式。制定自动化测试模块策略，以相应的几个维度去分析此模块是否优先自动化，CBB>基本功能>产品特性

    3、 建立统一管理的自动化测试功能模块库，各个测试组都能够通过此系统库查看到已经自动化测试覆盖的模块和应用的产品线，而且基于关键字测试驱动开发，统一标准，迁移性好，产品测试组在项目中开发后的模块可以快速迁移到维护测试组。

    4、 CBB，统一标准，统一度量，手工测试用例和自动化测试用例都是基于一个模块测试点标准，方便细化和统计。

    三、自动化测试平台之项目系统建设

    基于以上想法，在自动化测试平台已实现如下:

    1、 在测试平台上加入项目管理机制，基于项目建立自动化测试任务并运行。

    2、 模块管理机制，自动化测试任务基于模型运行。

    3、 Master-slave机制，每个slave对应相应的测试模块。

    4、 结果分析和报表管理机制，能够基于产品线和项目维度去查看自动化测试指标，方便阶段性分析。

    总结：有人说测试没有技术能力，但是我觉得测试很需要有技术能力，虽然测试与开发关注的角色不一样，前者关注于测试设计与质量保证，后者关注与软件设计与编码，但是大家都是基于软件工程和项目管理，因此在基础上大家都是站在一个起点上，前者如果忽略基础，很容易变成纯手工或者过于追求具有技术含量的东西。后者如果忽略基础，很容易变成无意识的”码农”。所以，如何学好基础，就需要我们在工作中好好去学，多发现问题和本质，提出有效方法。           —散步的SUN