|
经过一个月的努力，实现一个不熟悉的项目的自动化终于快接近尾声了。之前知道什么样的产品或项目适合做自动化，什么样的产品或项目不适合做自动化；而且由于自己设计过一个给人感觉很高大上的工具，自认为对自动化比较了解。可这一年来经历过两个设计不算成功的工具，最近不断反思，对如何更好的做自动化测试有了点新的感悟： 1. 能用现有的开源工具不要自己从头开发一套工具。因为开源的工具是经过很多人反复推敲，反复调整过的，无论从稳定性、易用性、还是设计理念上，都会比自己从零开始要优势得多。 2. 对于不是特别紧急的项目或产品，要对其有一定的了解之后再做自动化，需求不了解是做不出好的自动化工具的。这一年，有两个自动化测试工具的任务，两个任务都有一个相同的特点：我对Business不了解。这种情况下做自动化就会有以下几个问题： 首先，要了解Business，会花费很多时间； 其次，列出功能点，需要做多少功能，担心做出来的不全，所以把能列出来的都列出来。但是，如果全做了，那这个工具就注定是个失败的工具。软件测试中一直遵循着80-20原则，个人认为这个理论也同样适用于自动化测试，即20%的功能会有80%的人使用的，所以自动化设计时，首先要考虑的是这20%的功能如何先做出来，以及如何让这20%的功能易用。 第三，即使做出来了，易用性不好。因为使用者的习惯与设计者的习惯往往不同，尤其在设计者对业务和使用者的习惯都不熟的情况下。 3.对于时间要求紧的项目，切记大而全，尤其对项目不了解的情况下。Design会随着对产品的了解而逐渐改变，逐渐优化的，如果刚开始就大而全，一是无法按时完成；二是后期维护的cost比较高 举例：这一年来我设计的第一个自动化工具就是UI测试，因为之前的工作经验，所以我想设计一个比较全面的，一次到位的工具，但其实对于不熟悉的产品，这种想法本身就是错的；而且自认为当时把验证结果都整合在一起挺有成就感的，但现在又想做到case，工具与verifyresult分离，之前花了很多时间整合验证结果做的工作就白做了。 4. 要做到数据，case（尤其case模板化），测试工具、结果验证的分离，便于后期维护。现在想想，之前的公司其实也是这么做的，但当时只知道效率比较高，还没理解到这个高度。 5.整合成一个工具虽然重要，但是投入产出比也不容小觑。如果整合的工作量很大，那么不整合也许是最好的选择，凡事有度，中庸之道值得推荐。 6.个人认为自动化测试最重要的核心是：设计一个高效的自动化框架的能力；开发能力；设计case的能力 |
本文出自 “Sunny” 博客，请务必保留此出处http://1994520.blog.51cto.com/1984520/1963952