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

　　经过几次的计划->实施->修正计划，对每周的工作进度就会比较了解，从而有利于对整理项目进度的预估。

　　c. 问：如何验收我们的项目成果?

　　答：每个人对“完成”这个概念的理解不同，有的人认为Complete即可，有的人认为Good，而有的人追求的是Perfect。为了保证我们的项目完成之后的一致性，可以建立一个完成的CheckList，将“完成”的概念量化，如验收test case script的完成，我们可以定制如下的CheckList验收。

　　4)检讨审查

　　也就是在项目结束之后，对项目进行总结，调节。并通过事后诸葛亮式的检讨分析，找出改进的方案，对下一个项目的进展是很有帮助的。

　　经过了两轮的开发，到了代码维护阶段。以前觉得“需求->开发->维护”三步骤中维护是最容易的，但是现在却让我们最挠头。

　　这几次Run出结果之后，所有的人见面第一句话都是：“呃，在我电脑上是Pass的，怎么现在就Failed了?”

　　静下心来检查代码，总有一些让我们忽略的问题被查到，但还是有许多顽疾存在着，尤其是界面刷新不及时或者莫名其妙的问题真的让我们很恼火。开发是一件创造性的事情，测试是一件破坏性的事情，无论二者都有成就感可言，但是维护或者说是擦屁股的事情搞得我们每个人都心烦意乱。总结我们的需求，开发，及运行经验，还有最近维护时遇到的问题，总结一下：

　　1、需求分析阶段，编写AutoTest Case时，步骤详略得当，不可以太简单，也不必太过繁复，多用项目的专业用语(阅读此文件的人都是对项目有一定熟悉度的人)，这样有利于维护人员，或者后期手动测试人员了解Case的测试内容。

　　2、开发代码时：

　　1)脚本内的注释写清楚

　　2)对象库及对象命名尽量有意义

　　3)中间步骤(如页面的跳转，某些重要的Button或Link)要写清楚，最好写到Report中

　　4)检查点的判断，要直观，并且写清楚输入，输出的值，及期望的输出，如，查询功能失败，要写明输入什么样的条件使得查询失败，否则QA可能输入另一组数据查询，结果为成功

　　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放到最后一个执行，降低对其他代码的影响几率。

原文转自：http://www.ltesting.net