基于迭代开发的自动化测试脚本开发流程2

接上文
[b]八.脚本的Promotion[/b]

[*]Peer Review
在每个Iteration的第二周,周中,都进行Peer Review,主要评审测试脚本是否都遵循测试用例中的描述,是否有功能点没有被验证到,Peer Review的内容,是事先定义好的.

[*]Check-In

[*]Formal Review
使用Atlassian Crucible作为Formal Review的工具,内容是一部分据有代表性的脚本,评审者为客户方的Developer已经本公司的Senior及以上的Developer,评审的过程,应该遵循Formal Review的Process

[*]Promotion
1.在项目的CVS repository 上创建Branch,已经Iteration号码来命名.
2.下一个Iteration开始,QC可以使用上个Iteration开发好的代码进行回归测试
3.QC可以在脚本发生问题的时候想ART提供反馈
4.merges the branch to head in CVS server at end of the second week of the iteration.

[b]九.脚本的执行[/b]
[*]测试执行进入准则
1.脚本已经被Check-in到CVS server
2.被测试程序已经通过冒烟测试
3.执行测试的环境已经准备好(JDK,Maven等)

[*]测试执行过程
省略....

[*]脚本缺陷管理
测试脚本有会有缺陷,引起测试脚本缺陷的主要原因有:
1.脚本是在中国的网络环境下调试通过的,但是在美国的网络环境下运行
2.ART Team没有完全理解测试用例,导致测试脚本不完全符合测试用例
3.UI元素在上一个Iteration的开发中,发生了变化,导致bug
ART Team将在下一个Iteration去Fix脚本的bug,所有的bug应该写入bug管理系统

[*]测试报告
可以使用TestNG产生的测试报告

[b]十.Best Practices[/b]
1.被测试程序的功能最好相对稳定
2.在测试代码中使用注释
3.页面元素和布局的少改变,这样维护测试脚本的成本较低
4.功能过于复杂的测试用例,不适应做自动化测试
5.不要企图去自动化所有的测试用例

[b]十一.Reference[/b]
1.ART Formal Review Process Pattern.doc
2.Test script check list.doc(For peer review)