[开发测试]团队中如何进行开展自动化测试的？

引言

反正根据他的描述，他们公司各种流程不规划、测试质量比较差、上线之后也暴露出很多问题，所以他们领导说，做一些自动化来进行提升他们的产品质量。

接下来就从以下几个方面说说明引入自动化测试需要注意哪些

自动化测试的目标是什么

以个人的角度来说，团队中通过引入自动化测试后，我们能够解决下面几个方面中的一些问题：

• 目前的测试效率无法在提升，需要找到其他突破点，即需要提升测试效能
• 降低人力成本，通过自动化测试帮助团队完整更多的事情
• 减少人为错误，主要是人在长期重复工作和一些惯性思维导致的错误
• 提升执行效率，对于一些长期重复的操作
• 增加软件测试的信任程度，因为程序执行具有很强的一致性和可重复性
• 提高测试的覆盖率，主要针对于老功能的回归测试方面

开展自动化测试的时机

• 团队测试流程、研发架构设计、接口文档都已经走入正规化，提测质量也比较高

  这是 自动化测试开展核心前提条件 ，如果测试流程混乱，接口文档提供不上，提测质量差等，这时我们优先做的事情是把所有测试流程，测试规范落地才是真正要做的

• 团队测试效率遇见瓶颈，可以通过一些自动化测试工具提升效率

  在团队测试过程中，发现一些重复的功能经常需要进行测试，操作复杂、操作时间长时，这时候就可以引入一些自动化来帮助我们完成这些工作，释放人力，将人力放在其他更有价值的测试上。

• 团队中有合适的人员可以承担相关的自动化测试工作

  自动化测试的开展需要一定的技术基础，如何团队里面完全没有成员能力能够承担这个工作时，开展自动化反而是浪费测试人力，做出的成果出现各种问题，收益率太低，最后领导们觉得自动化测试就是烟雾弹了，没什么用处。

• 需要展现测试团队的技术能力时候

  在公司甚至产品、研发团队里面，大家都觉得测试就是点点点的工作，没什么技术含量，做一些合适的自动化测试并且达到效果，可以改变其他人员对我们部门的看法，适当的展现技术能力不能缺少的

自动化测试成本问题

• 执行性

  • 被测系统、业务需求比较稳定，如果系统不稳定、需求多变情况下这样我们将一直在自动化测试用例的更新、维护、调试和测试报告的分析中，得不偿失
  • 项目测试时间比较宽松，如果项目时间紧张，搭建自动化测试框架，开发测试脚本非常需要时间，对时间比较短的项目可以先不考虑自动化
  • 项目周期比较长，项目周期短的项目，不值得花精力去进行自动化测试，好不容易编写好的测试脚本，不能得到重复的利用
  • 业务规则相对简单，如果业务规则很复杂，有很多的逻辑关系、运算关系，工具就很难判断得到的结果是异常还是正常

• 成本

  • 团队技术储备成本：如果要引入自动化测试，那测试人员的能力要求也会相对高一些，需要一定的编码、网络协议等。这类人员的成本也会相对高些。
  • 其他团队配合成本：想要做好自动化，前提得是有标准化的东西，特别是需要研发的配合，所以我们能够改变的东西很少，只能去尝试、推动开发人员做一些改变，但是实际上往往比较困难。
  • 时间投入的成本：不管是开发脚本还是维护脚本，都是需要时间投入，现在大部分团队都是业务测试完成之后，抽空一些时间进行自动化相关的脚本编写，这样往往长时间看不到产生，导致领导对于自动化产生怀疑。

• 效率

  • 用户影响力的自动化测试：我们应该选择产品的核心流程、功能优先进行执行，如果发生失败，这些功能也会带来最大的影响后果，尽量多覆盖用户反馈问题比较多的功能模块
  • ROI的自动化测试：我们大家都清楚根据金字塔模型，基于BUG的修复成本，越底层的自动化测试越能产生高价值。理论上来说，我们应该优先引入单元测试，来保障代码质量。但现实是怎么样的，大家都非常清楚。所以我们经常都是建议优先引入接口/集成自动化测试，相对来说接口自动化测试收益率较高

自动化测试常见误区

• 为了做自动化测试而做自动化测试

  开始之前没有做好规划，设定好引入自动化测试的目标和期望值，看见别人都在做，而我们没有，是不是代表我们团队low了，被淘汰了，特别是上面领导交代要做自动化，这时真是迫于压力，如所谓的 “人云亦云、病急乱投医” ，看见其他公司或者团队在搞接口时，赶紧跟风去做接口自动化，发现效果不太好，又看见其他人做了UI自动化，又盲目去去UI自动化，导致做的一地鸡毛，这些都是盲目幻想，认为自动化测试能够节省成本，想着搞起来自动化，省掉多少多少人力成本

• 自动化测试能发现大量新缺陷

  发现更多的新缺陷应该是手工测试的主要目的，不能期望自动化测试去发现更多新缺陷。事实上，自动化测试主要用于发现原来的缺陷。自动化测试用于回归测试，而大量的新业务测试更多地还是依赖手工测试。如果没有建立一个正确的软件测试自动化的观念，认为测试自动化可以完全代替手工测试，或者认为测试自动化可以发现大量新缺陷，或者不愿在初期投入比较大的开支等，则自动化测试一定会让我们大失所望。

• 自动化测试工具是"万能"的

  在很多情况下，需要利用多种测试工具或者开发自动化测试框架才能达到自动化测试的目的。商业和开源的测试工具能够用来进行自动化测试，但是我们需要根据自身产品的特点，开发自动化测试框架，在框架中提供常用的测试用例，加快测试速度，达到测试用例复用。

• 所有测试用例都可以自动化

  不是所有的测试用例和测试步骤都可以转化为自动化测试。在自动化测试投入较多的行业，领先企业的自动化测试率有的能达到80%左右就已经非常不错了，但仍有20%左右的测试用例需要手工来进行。

• 自动化能百分百的测试覆盖率

  自动化测试可以增加测试的广度和深度，但是仍然无法达到100%的测试覆盖率，因为没有足够的时间或资源，不可能覆盖所有可能的输入，所有可能的组合和路径。

• 能录制回放的自动化工具是最好的

  很多领导感觉测试工具能够录制后直接回放，不是非常简单么。而事实上，录制得到的脚本通常是不可重用的脚本，脚本中充满了硬编码的值，这些值应该被参数化，否则脚本仅仅适用于一个测试情况，脚本还应该加入条件判断、循环等结构，以便增强测试脚本的灵活性。

总结

• 简而言之，混乱时期不适合自动化，将各个流程捋顺规范起来后，洞察团队痛点，选择合适的工具、框架、平台，最后可以测试左移、右移完成自己测试团队的技术闭环；基于业务自动化需求，才是有效果、有用的。自动化不是测试的事，是整个项目组协作的事；自动化不是一蹴而就的事情，需要时间沉淀，可能短期看不见收益，长期来看自动化测试如果做得成功的话，是可以节省成本和提高产品质量。
• 只有当我们正确认认识到自动化测试能给我们带来的预期收益和目标后，结合团队的具体情况，避免对自动化测试有过高的预期，避开一些常见的误区，根据团队痛点逐步的引入自动化测试，给予一定的时间，慢慢沉淀和发展，才有可能真正实现自动化测试的价值。

以上为内容如有疑问或者问题，欢迎各位大神指正，转载请注明出处!

如果觉得文章不错，欢迎关注微信公众号，微信公众号不定期推送相关测试技术文章