回忆刚进公司的时候就被安排在了自动化组，以至于没有经过手工测试的阶段，上来就直接用工具了（RFT），因为有编码基础，所以上手还比较快。工作半年了，又回过头去根据已经写好的用例来学习业务。
那段时间比较郁闷，因为发现自己只是一个自动化的执行者：写用例，执行，调试，输出报告，那些测试理论好像很少用到实际工作之中，我想以后可能会承担更多的任务的。
关于自动化测试这一块，以下是个人的几点看法，希望和大家分享一下。
1.用例设计的过于传统，都是按照最常规的操作路径去执行，发现问题的效率没有手工测试高。手工测试中虽然也是按照测试用例中的环境准备以及操作步骤进行执行，但是因为人和人的具体执行方式的略微差异（比如随手点到了另外一个按钮上面），可能会以非常匪夷所思的方式发现问题。可能就连用户也很少有机会可以进行这样的操作，但是这并不意味着这样的情况可以完全被排除。曾经在对别人写的一个网站做测试的时候，点来点去就点出Bug了，我们当然不希望用户在使用产品的过程中出现任何问题，真正对质量有信心的产品应该在交付给用户的同时附上一句：随便点，玩儿不坏的。
2.自动化的程度不高。这一点可能各个公司会有不一样的地方，但至少在我目前所处的工作环境中，自动化还是大部分依赖于RFT这一测试工具，框架也是在它的基础之上开发的。然后看了一篇关于QSIC的报道，至少我认为这汇聚了软件测试这一分支目前比较前端的技术。测试数据，测试设计，测试执行，测试环境一键搭建，测试评估，甚至测试标准也可以自动化了，想一想自己那时的工作，无非就是在测试执行这个环节比手工测试要智能一些，而且是在大量用例执行的时候优势才体现的比较明显。有时候自己有一些想法，却好像总是受到工具的制约而没有去打破这个束缚。当别人已经在考虑low-cost的时候，自己所停留在的层面确实值得反思。（如果对软件测试、接口测试、自动化测试、面试经验交流。感兴趣可以加软件测试交流：1085991341，还会有同行一起技术交流。）
3.无效率的重复性工作太多。那段时间写用例，也就是写自动化的脚本。前面几个写着还好，但是到后面发现在做的只是重复性的工作之后，心里就有抵触情绪了。原谅我的没耐心，这一点我知道不好，我明白测试确实是要做很多重复的工作的，但是让我郁闷的是这种重复性的工作我认为是可以通过工具的改善来避免的，肯定会有工具解决了这一问题，但是自己还是要一个一个用例的Ctrl+V。这些是可以通过自己写的工具来改变的，以后也会想办法慢慢挣脱自动化工具的限制，达到更高的效率。
暂时只想到了了这些点，刚接触自动化半年时，我相信随着工作的深入还会有很多体会。也欢迎各位自动化测试的同行们交流更多的经验。以上内容希望对你有帮助，有被帮助到的朋友欢迎点赞，评论。
网友评论