首先在我看来，自动化是必定会提升工作效率的。之前其实我也认为自动化是没有用的，现在想想，只是无知限制了我的思路

 

总结下我经常遇到的场景吧~

1.重复工作较多

.之前和同事工作中扯淡，他在做一个功能测试，但是仅仅是因为加了一个功能点却要回归下之前不少测试用例，回归可能还好说，但是测试流程比较复杂，然后就聊到了自动化实现，这样重复工作很多，我和他聊到和自动化可以实现，作为业务测试的他对自动化可能不是很清楚，他说不是很清楚是否能实现。其实我想表达的是团队的磨合，如果真的日常工作重复工作很多，我觉得有必要和测试负责人聊下，看是否能解决，这是单方面，测试经理也应该经常和组员聊下日常工作遇到的问题，答疑解惑。若这样的重复工作太多，没人去解决问题。需求经常延期，我觉得因为这个原因加班并非需求多，而是因为管理层能力不足而加班的。

 

2.录制性自动化繁琐

   通过录制做自动化其实我是接触不多的，在我刚干测试时团队就是直接写脚本实现关键字驱动,这样只要按照测试模板填写关键字即可的，今年碰到了现有公司用的是selenium自带的录制工作，但是看了他们的实现方式，得先录制再概改脚本这样实现，不是很灵活，如果用脚本封装selenium库只要填参数，对比下，方便很多又省事了一些，所以这点我觉得是公司在这个领域还是稍有写薄落，导致功能测试人员写自动化用例繁琐了一些，那么怎么还能让功能测试依赖这套东西提高效率呢？

 

3.管理层不注重自动化

这个点其实没什么好说的，靠的是测试负责人的个人魅力和说服力，以及能够利用自动化提高效率，这样有产出，管理层正常对高效率和质量保证还是比较看重的，如果拿出产出，管理层还是不支持，那么对技术有所追求的我觉得在该公司个人能力到达瓶颈后，有必要重新找个管理方面还算可以的公司。

 

扯了不少，现在我以我的认知设计了自动化怎么嵌入到测试流程提高效率吧~~

1.自动化属于测试策略的一种，是否要开展自动化决定于公司是否存在自动化需求，比如：

这样，业务上存在了自动化的需求了，测试开发人员直接写脚本吗？？？还不至于，脚本是给所有业务测试包括自己使用的，应该更让别人知道怎么实现或者逻辑怎么窜通的，这个需要和当时人(业务测试人员)讨论的，例如：

 

 

1.框架选择，首先目前还是开源框架用的比较多，单元测试框架: python的unittest\pytest或者java的juint\testng  GUI开源工具 robot都可以根据现有团队的认知选择

2.用例模板设计，目前我的实现还是通过excel去实现关键字驱动的，这个可以和业务测试人员定义一下关键字命名和传参

3.收集场景关键字，如果脚本开发的测试只在测试某个系统，但是公司业务系统较多，这样业务测试可以和说下负责的系统有什么特殊的控件（其实就是，点击，输入，js弹窗，悬浮。iframe的切换，下拉框，时间控件不可输入等）以及每个系统用的什么数据库mysql,oracle.mongodb这样脚本开发人员可以提前写好这些方法，这样就减少了后期遇到再修改脚本的可能性，

4.定义建议至少两位脚本开发的人员，这样至少在遇到问题可以讨论以及在前期解决业务测试人员不可避免遇到的一些问题，这样业务测试会明确出了问题可以找谁

基本脚本设计需求已经定义好了，这样脚本可以开发了

 

当脚本写完后，需要定义自动化如何嵌入到测试流程，提高效率

1.首先自动化用例的编写必然会占用工作，排期必须要让出时间，前期会占时间比较多，其实前期工作量只是在补现有功能之前一直没有做的东西，往后自动化用例会少了很多，占排期也会越来越少

2.依赖自动化成为工作的一部分，例如这周一到周四测的功能，把一轮测试完的功能自动化用例写起来，一轮测完，开发必然会改bug再发个版本，无bug也没关系，不影响流程，这时候，执行写好的自动化测试用例回归二轮，二轮无bug，待发生产即可，既然说了把自动化当作工作的一部分，那么过程必然磕磕绊绊会有些问题，自己定义一个解决问题的时间，10分子或5分钟未解决，找脚本开发人员解决，这一个过程其实就是不停的提升脚本的健壮性，时间越长，健壮性越强，这样在后面的工作中，有了前期的铺垫，后面有相应的功能就可以省了不少时间

3.还有个问题是前端元素会经常改动，这个确实是个问题，先说下两个解决方式吧，第一个是在编写测试用例的时候，不同的用例前期必然会出现重复步骤的，这样单独写个用例出来，让主要的业务逻辑的用例继承这个重复步骤的用例，这样目的可以减少用例的修改数，还有一个是定期维护，在下次版本编写用例时维护好报错的用例，注意这个定义维护只放在下次用例编写自动化用例的排期中，定义时间是因为这次版本是运行没问题的，那么投产后验证也没有问题，之后测试环境新增功能迫害了元素，不用管，虽然失败但是流程不能乱，放在下次自动化用例编写还有个原因是之前已经做了自动化铺垫，那么这次版本必然会少工作量，加上维护失败的用例，这样工作量饱和了，当然我觉得元素改动没那么夸张到大批量都死掉，这只能说明元素定位方式需要改进，不增加开发很多工作量的情况下或与开发配合

 

4. 还有一点，前期自最好不要让加班写自动化用例，这样会给测试某种程度带来负面情绪，前期还得给出排期，不给排期做自动化，我觉得测试很难把自动化当做工作的一部分，

自动化就像一个投资，虽然有风险但是收益是客观的，当然是在理智的前提投资，自动化流程的设计就是一个理智的分析再投入实践。

 

5.再插一点吧，有些公司测试是各干各的情况，就是一个人负责某个系统，那么功能和自动化都是这个人负责，自己的工作量自己想办法解决还是不错的，效果好，其他测试必然效仿，这种方式我觉得还是不错的，但是现况普遍有岗位是没有稳定单干某个系统的吧 所以还是得全局考虑...

 

不知不觉扯到现在，算是接触了一年自动化的一些感受吧