5)写完整个Case之后，需要察看整体的Report，是否容易看懂，整个Report就需要象一个故事一样，上下文连贯。
6)在开发的尾声，需要安排时间互相Review代码，按照1)~5)去审查别人的代码，这样也会发现一些问题的。不仅如此，互相察看代码有益于我们发现别人的长处，和一些自己没有注意到的知识点。
7)代码完成之后，切忌不可束之高阁，而要多运行几次，并且在不同的电脑上运行，可以利用晚上的时间，相互运行代码。
我觉得，6)和7)在开发阶段是不可省略的步骤，我们之前总是说开发时间紧，就缩短或者省略这两个步骤，导致我们正式运行时错误百出。
3、维护阶段
总结我们经常出现的错误，有如下几类：
1)环境问题 (如界面刷新，异常中止)
这些问题我们只能自认倒霉，但是总觉得可以再次优化，就是还没有想到好办法。会继续摸索
2)QTP与IE冲突
由于QTP的某种操作，会导致IE的异常中止;或者由于IE的设置，导致QTP无法反映。此类问题出现的频率不高，但是一旦出现会导致一连串的错误出现。
3)对象异常
有如下情况：
第一种是由于站点本身的升级导致对象的变更或逻辑的改变，此时需要修改代码;
第二种情况，由于界面跳转异常导致对象无法识别，在捕获的图片中可以看到。
还有一种情况，针对我们的框架下，对对象库的加载，会有对象重复的现象，导致对象无法被识别。此时就需要对重复的对象进行处理，保证其唯一性。
最常见的是对象不唯一导致的无法识别，多出现在WebElement中，我们往往通过对某个WebElement的value值判断其成功与否，但是有时界面中会有许多隐藏的Webelement存在，如果恰巧WebElement的识别属性用描述性编程，或者是正则表达式的话，就容易识别不到。需要加入 Index属性去识别。
4)脏数据的存在
举个例子，某个Case为：添加->查询->删除操作，如果第一次运行没有执行到删除就错误中止了，第二次运行时，之前添加的代码就会存在，影响添加或查询，我们可以这样设计Case：删除->添加->查询->删除
再如，A操作的前提需要B操作设置，但是B的设置会影响到A相关的其他操作，我们设置Case：B config1 -> A Operate -> B config2，但是，如果该Case在B config2前异常中止了，则B的config1将被带入到下一个Case中。针对这样的Case，可以将Case放到最后一个执行，降低对其他代码的影响几率。
我们最后的测试报告都会由手动QA人员确认，并且察看Bug是否为系统的Bug，并且统计Bug发现的比率，
1)查看遗漏率 自动化发现的Bug / QA发现的Bug
这个需要察看QA发现的Bug是否在我们自动化测试的Case中，如果在，那是我们的问题，如果不在，我们就需要添加到Case中，这就可见在需求阶段与QA确认的重要性，否则，人家不认可你的检查点或者说你的Case 有遗漏，我们就很郁闷了
2)准确率 QA确认的Bug / 自动化发现的所有Bug
这个好有压力阿，如果自动化发现10个Bug，结果有九个是脚本或者环境的问题，只有一个是真正的Bug， 我们自动化的效率就可想而知了。
文章来源于领测软件测试网 https://www.ltesting.net/
