过度回归测试会导致测试周期延长

　　什么叫过度回归测试呢？我总结成两点：

　　1、测试过程中环境的不稳定性导致之前测试结果的不可信赖，刚刚还好好的地方又出现问题了，又得回过头来跑一遍原来的用例，这样反复何时才是个头啊？！

　　2、回归测试时我们总是要善于判断哪些功能需要回归，如果不想漏掉任何一个功能会导致测试周期严重延长，也就需要全部回归。

　　第一点解决好了测试环境的稳定性就可以避免，在测试每一轮次过程中保持代码不随意更新，数据库不任意更改不删除插入数据，各种服务不任意重启，让每个case运行结果都是可信的，那么会节省我们很多时间。

　　而回归测试时，我们只要判断好软件功能间是否有依赖，内容就明确了。

　　1、有关输入：这些功能会不会处理同样的输入？？

　　2、有关输出：这些功能会不会在用于界面上显示在同一个区域？会产生同一个输出吗？

　　3、有关数据：是否会操作同样的数据？是读取还是修改？

　　以上只要有一个答案是肯定的，那必然有依赖，就需要回归一下。

　　过度自动化会让我们力不从心

　　我经历过以下两种情况：

　　1、我们有时候为了盲目追求覆盖率，会对一些简单的基于页面层面的case实现自动化，而这些内容适合自动化吗？

　　2、有些自动化case种都是基于某个前提下完成的（比如登陆），而为了追求case间独立性，每一条都实现了该前提（登陆），是否属于过度自动化呢？

　　如果页面改版，登陆功能重设计，对于代码的改动量可想而知，我们需要找出那些频繁地被拿来手动执行的用例，属于业务核心的用例进行自动化开发，而且我们完全可以在测试方法之外额外实现一个方法来实现登陆，只需要以下的所有测试方法都有异常捕获并且在该方法运行成功之后才执行。

版权声明：本文出自 zzzmmmkkk 的51Testing软件测试博客：http://www.51testing.com/?258885

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。