软件测试培训之自动化测试的需求

软件测试培训之自动化测试的需求

1 让“自动化”代替“手动”

在我看来，初期的自动化测试，我的目标很明确，我就是要让“自动化”代替“手动”，让自动化真正地跑起来，凡是“自动化”跑过的内容，我绝不再去手工重复执行一遍。这样至少我有一个很明确的收益：每完成一条自动化用例，我减少了一条手工用例的执行时间。

必须要提醒的是，让“自动化”完全替代“手动”，其实对自动化用例的稳定性、容错都有一定的要求。你要花一定时间去思考用例执行过程中的异常场景，是否足以充分替代手工测试。因此，我在增加用例的时候都会非常谨慎，确保用例集是稳定100%通过的前提下才会增加新的用例。

对于正常情况下(排除环境、开发代码的问题)有时100%通过，有时90%通过的自动化用例集，我觉得它的作用和参考价值为0。正常的用例集就应该是100%通过的。

2 让“回归”自动化

上节说了让“自动化”替代“手动”，每完成一条自动化用例都是有明显收益的。那如何让收益最大化呢，当然是让每次回归或上线验证“不得不”执行的用例优先自动化。如果完成了回归用例集的全部自动化，那我就可以用它来替代我的日常回归，和上线回归工作，极大地释放我的手工验证时间。

这里必须要指出的是，我跟的项目其实是一个对系统稳定性的要求要高于新功能的引入的一个后台项目，所以它的核心功能是比较固定的，其实大多数后台项目也是类似的，核心功能聚合、对系统的稳定性要求高。这就需要保障系统的核心功能完善。所以我们可以先将“核心功能”的验证完成自动化。

3 不要让环境成为瓶颈

前面说了，旧的用例集在维护的过程中给测试人员增加了很多额外的负担，到最后发现很多都是环境的问题。当时的情形就是专门搭建了另一套测试环境专门用于自动化测试，而大数据的后台环境搭建和维护非常的复杂，如果同时维护多套环境，难免会在一些组件升级的过程中出现遗漏，导致环境不同步。因此，我们的自动化测试用例前期完全可以直接在功能测试环境执行，因为功能测试环境肯定是会一直随着版本的迭代向前不断更新的。