过度依赖基于UI的自动化测试背后的隐忧

过度依赖基于UI的自动化测试背后的隐忧

今天在看到Michael Bolton的“The secret life of automation”的文挡时，对这一页特别有感觉，停在这里想了很久。

想得最多的是最后这条”The belief that you MUST automate user-level checks suggests problems in your development process. Fix THEM." 自从我们测试团队这两年大力推行基于UI的自动化测试，并且取得了一定的效果后，我们的确有这种倾向“必须更多地引入基于UI的自动化测试” 。今天一个产品负责人在和我谈起昨天产品环境发现的一个缺陷的时候，还提了一句“这个能通过自动化测试发现吗？” 可是，自动化测试不是银弹。对基于UI的自动化测试过度依赖的背后隐藏着一些什么问题呢？

问题1:人的问题。团队成员中新人多，有段时间甚至批量进驻大量新人。新开发人员可能2周内就开始要动产品环境的代码了。这给测试带来巨大的压力。因为没有经验的开发人员更容易不小心改坏了别的代码。更雪上加霜的是，我们还缺少单元测试和及时细致的代码审查。每天都在动荡的代码运行起来简直像是裸奔，好多非预期的问题四处炸雷。不知道哪里会出问题，是最可怕的一个问题。所以，覆盖率较高的基于界面的自动化测试就成了所有人的救生圈。大家都指望着它能大一点再大一点。但是，自动化测试脚本只能作为回归测试的辅助，确认一些老的流程没有被破坏，并不能发现没有定义过的问题。我们大家都必须意识到：人的问题，知识传递的问题，潜在的风险，都不是自动化测试能改善的。

问题2: 方法的问题。我感觉目前我们的团队缺少多样的保障质量的手段。大量的质量压力倾斜在测试人员身上。需求复杂，开发时间紧，提交测试晚，上线时间不容推迟，这些重重困难之下，很多可以被压缩的质量保证手段都被无形中压缩了，除了还在CI中坚持着运行的自动化测试。令人欣慰的是最近开发团队的代码审查，某些新模块的单元测试，有组织的技术书籍学习和分享。。。正在展开。质量保证如同织网，测试只是经线，没有其它维度的纬线，经线再密，也终是脆弱的。

所以，我希望今年基于UI的自动化测试不再追求大的覆盖率的提升，而希望整个团队将目光投向其它的改进质量的方向。