之前在某测试论坛中，吐槽自己公司自动化测试项目失败，大概过程是自己所在部门的自动化测试经历了几次步进式的建设，都具有阶段性的成果，但是总的看来却不是一个成功的案例。因为赶进度，仓促的投入让一大堆的脚本质量比较低下，有几个测试组由于没有人力投入自动化开发而又不得不完成自动化的KPI，只好聘请外包来帮忙完成自动化。理智地想一想，咱们花的那点钱请到过真正精通自动化技术又肯主动深入考察我们公司业务系统特征的外包么？况且外包终究还是要离开的，所以我们不得不接收一堆没有经过精心设计、没有组织性的脚本——尤其是在没有通用测试框架的情况下。且不说UI测试的自动化脚本本身就运行不了多久就会面临界面变更，单单是要让我们接收别人迥然不同的设计风格就是一件很难的事情。结果呢？要么延续这种无组织性，让脚本数量更加庞大、更加杂乱无章，要么就是放弃对这些脚本的维护，任其自生自灭，最终变成一堆废材。
以上只是说了失败过程，我们回头仔细想一想，到底是什么导致失败，绝对不是一条两条的原因，多方面因素，主要原因5大点，具体如下：
没有选择正确的工具来满足自动化测试的需求。在选择自动化测试工具时，了解工具的范围以及它提供的功能是否与团队的优先事项兼容很重要，建议选择商业工具，次之开源。
2. 过高期望测试自动化
一些测试任务不应将其自动化，尽管测试自动化有助于跟上发布周期，但自动化并不是解决软件测试问题的万能解决方案。实现100％的测试自动化是高度不切实际的期望，而尝试这样做的公司最终将面临更大的成本和一系列难题。
3. 业务逻辑更改
自动化测试对于重复性测试特别有用，但前期会占用大量时间和资源投入。无论是像测试登录过程一样简单，还是测试系统核心功能一样复杂，这些都是可以从自动化中受益的出色测试示例。
但是，当要更改网站用户界面时会发生什么？例如，当调整登录按钮以使站更加人性化时会发生什么？有解决这些问题的简单解决方案。
4. 及时更新流程
正确实施后，您可以快速掌握可以节省多少时间，以及它如何帮助QA团队更加融入软件开发流程。但是，长期采用自动化技术的公司有时可能会因需要定期进行的大量自动化测试方案而感到困惑。质量检查测试人员可能有一些自动化测试，在测试新功能时会经常使用这些测试，但随着时间的推移，其他测试可能会过时且麻烦。为确保测试自动化工作继续团队受益，重要的是要花时间优化现有的测试自动化套件。尤其是当测试自动化操作更加成熟时，重要的是要回过头来确保旧测试用例仍然有用，而不是仅仅专注于自动化新领域。这将使测试操作保持精简，并使团队更容易扩展测试自动化。
5. 不能完全放弃手动测试
测试团队可能没有在自动化与手动测试之间取得平衡，测试自动化并不能摆脱手动测试。相反，质量保障团队应该提供了更多时间和精力专注于仍需要人为操作的测试。
sales@spasvo.com
