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

发表于:2017-04-11来源:gitbook作者:梅子点击数: 标签:
在我感到自动测试可能就是在金子塔尖徘徊徘徊的时候,又发生了一件事情打破了我之前对自动化的认识。公司的大领导突然非常重视自动化,整体上加强

在我感到自动测试可能就是在金子塔尖徘徊徘徊的时候,又发生了一件事情打破了我之前对自动化的认识。公司的大领导突然非常重视自动化,整体上加强了对自动化的投入,成立的专门的自动化小组。大领导直接拍了一个很高的自动化目标,自动率要达到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