通常情况下，你排查了良久，也无法判断为何某些case失败，郁闷的心情可想而知，这个时候你可能会想，如果只是回归当前提测的功能该是多么幸福的一件事。在经历了多次这种事情后，慢慢的也察觉了一些规律，以及排除某些错误case的方法。就像电视上或者生活中没有无缘无故的爱，也没有无缘无故的恨一样，在自动化case的回归的世界中，也没有无缘无故就失败的case，每一个失败的case都有其失败的原因。

       当错误的case发生时，需要排查代码的上一个版本中该case是不是失败。一般情况下，上一个版本的case应该都是全部通过的，因为如果case不通过肯定无法上线嘛。这个时候你就对比当前代码的版本和上一个代码版本，看看究竟是修改了那些内容使得case失败了。通过代码文件静态对比，以及运行期间的gdb单步调试，我想找出失败case的原因不是难事。

       经历过多次这样的事情后，就看的比较开了，出现失败的case也会慢慢的去分析原因，不用一出现问题就去喊开发。在这里多说一句，测试人员和开发人员应该保持相对的独立性，不要什么都依靠着开发，如果真的需要找开发来解决某些问题，你应该能大致知道问题出错可能的原因在什么地方。

Part.3

如何高效的写自动化case
 

       谈到写自动化case，很多同学就说，这个很简单，按照EXCEL表中或者xmind图中功能测试的用例，把所有的case都写上就好了。当然这个情况下是最理想的，把所有可能的情况都覆盖掉，但是现实情况下，你可能根本没有时间将所有的case全部写完，这个时候你就要在规定的时间内，用最少量的case完成最大的代码覆盖，拒绝重复的case，以及一些非常简单的case。

       重复的case这个比较好理解，比如某项功能在某个测试用例中已经验证过一次了，那么就没有必要在其他的case中再验证一遍。那么什么是简单的case呢？说到简单的case，就要提及代码review了，现在很多测试不参加开发的代码review，当然各种原因都有，比如时间紧、任务重啊，或者没有这样的惯例啊等等。