自动化测试详解（1）

自动化测试

什么是自动化测试？

这个没什么好讲的，就是使用工具代替人工

为什么要自动化测试？

优势：

• 减少成本(时间成本+人工成本)
• 先天具有可追溯性
• 提高回归效率
• 其他好处(定时执行、手工无法执行的用例，如稳定性)

劣势：

• 不要奢望所有的测试都自动化，否则一定会得不偿失
  • 曾经维护过一个稳定性巨差的自动化，简直是要崩溃，影响用例结果的因素太多了,外部环境也会影响结果。很痛苦
• “开发手一抖，自动化测试忙一宿” ，维护成本高
  • 要想做自动化，一定要和开发人员配合好，约定哪些东西能动，哪些不能动，特别是基于ui的web自动化测试。
• 自动化测试用例的开发工作量远大于单次的手工测试，只有执行次数大于等于5次时，才能收回成本。
• 自动化测试仅仅能发现回归测试范围的缺陷
  • 一般都会采用手工(新功能) + 自动化回归 做新版本，之后在将新的手工用例纳入到自动化用例集里
• 不稳定的自动化测试用例实现比没有自动化更糟糕
• 要想有完美的自动化用例，需要业务测试专家和自动化测试专家相互配合(或者你即懂业务，也懂自动化)
• 自动化测试开发人员必须具备一定的编程能力

如何才能知道该用例是否可以被自动化呢？

当你发现自动化测试用例的维护成本高于其节省的测试成本时，自动化测试就失去了价值与意义，你也就需要在是否使用自动化测试上权衡取舍了。

哪些项目适合自动化？

可能刚工作，哪个项目要不要自动化，不是咱们说了算，但是我们也要有个全局的认知，站在更高角度看问题，不要局限在埋头工作，多抬头看看脚下的路。

1. 稳定的需求，不会频繁变更需求
2. 研发和维护周期长，需要频繁进行回归测试
   1. 对产品进行自动化，而非对项目
   2. 如果对项目继续自动化(需要频繁的进行回归测试)
      1. (对稳定的中长期的产品进行自动化，变动较大或者需求不明确的功能，20%的精力去覆盖80%的回归测试)
3. 需要在多平台进行重复运行相同场景的测试
4. 某些特殊的测试，手工无法完成。如性能和压力测试
5. 规范的开发+可测试性的接口，否则后续的自动化很难开展
6. 测试人员编程能力
   1. 测试工程师通常会非常热衷于学习使用自动化测试技术，以至于他们的工作重点会发生错误的偏移，把大量的精力放在自动化测试技术的学习与实践上，而忽略了测试用例的设计，这将直接降低软件整体的质量

个人感悟

以缺陷数量来衡量测试的绩效是不可取的，会激化测试和开发之间的矛盾，个人觉得缺陷数量应该来衡量开发的绩效，因为 开发需要对测试负责，测试需要对用户负责。

业务测试和测试开发一般公司都分离开，我做过2年的业务测试，1年的测试开发(完全不碰业务)。其实个人挺不太喜欢这种完全剥离的感觉，就会陷入一种误区，测开就在写内部公司代码，开发工具，并且由于测开完全不懂业务，就会需要一个更“高级”的工程师(也有可能是PM)来协调写出什么样的工具，最后的结果往往是需求不断更改，改了又改，业务测试人员还用的不爽。双方效率都很低下

最开心的就是我在做业务测试时候，自己写的测试工具，那是完完全全的“自我定制”，效率提升的很高，成就感也很足