谈谈我在自动化测试中遇到的坑(8)

在我感到自动测试可能就是在金子塔尖徘徊徘徊的时候，又发生了一件事情打破了我之前对自动化的认识。公司的大领导突然非常重视自动化，整体上加强了对自动化的投入，成立的专门的自动化小组。大领导直接拍了一个很高的自动化目标，自动率要达到30%，不到一个月又更新为要达到40%，然后要达到60%.....

这就意味着自动化测试不仅仅是做回归测试，还要做新功能的测试。要做新功能的测试，并且还要让脚本在新功能提交的时候就可以测试，就需要提前把脚本写好，而且界面、CLI都要尽量没有变化，当时我觉得是不可能做到的，觉得领导就是在那里拍脑袋瞎指挥。而且Martin这样的大师都说了，自动化测试要做成金字塔的样子，我们去把金字塔的塔尖做大做平，真的有意义吗？

事实时，自动化测试组的leader在老板的支持下，真的做到了。在老板的支持下，他把流程改了，他把自动化测试明确的放在了流程中进行考虑。我们的产品是有CLI和UI的。以前CLI和UI是功能设计后期才输出，现在改为了在需求确定后就要输出相关的设计。对CLI要输出确定的界面回显。而且一旦评审通过，不允许随便修改。如果要修改，必须要通知自动化团队。自动化团队在CLI接口设计完成后，就会立即封装自动化的函数（我们内部叫AW，action word），自动化团队基本能够在用例输出的时候就可以完成所有的AW封装。产品团队可以在用例设计完就投入脚本的编写。然后我们真的做到了用脚本来做新功能的接收测试，功能测试！

由于这个自动化团队是一个拉通了所有产品的资源部门，他们还尽量考虑了AW在不同产品的复用（在AW复用之前，我们的测试用例就已经复用了），后来进化为了脚本的复用。比如A产品有“扫描”这个功能并且已经做了自动化了，B产品也准备做“扫描”这个功能，B产品不仅可以直接用A产品需求相同部分的用例，还可以直接用A产品的脚本！脚本让原本分散在不同产品不同版本中的测试人员，形成了一种合力，大大提升了测试效率。我感到这时的自动化，才是真正可以替代手工执行的自动化，我第一次真真实实的感到了自动化测试的好处。

这段经历给我的触动是巨大的。

• 我感到自动化测试，不是测试单方面能够搞定的事情，需要开发的理解和配合，更需要领导的支持

  原文转自：http://gitbook.cn/books/58d23ddcfa7558521a30277a/index.html

  • 共12页:
  • 上一页
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 下一页