经过了两轮的开发，到了代码维护阶段。以前觉得“需求->开发->维护”三步骤中维护是最容易的，但是现在却让我们最挠头。
这几次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放到最后一个执行，降低对其他代码的影响几率。
我们最后的测试报告都会由手动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
原创作品，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明，否则将追究法律责任。
