QTP自动化测试过程随想(3)

　　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， 我们自动化的效率就可想而知了。

　　版权声明：本文为51Testing论坛会员1316016原创，http://bbs.51testing.com

原文转自：http://www.uml.org.cn/Test/200912176.asp