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

接上文
八.脚本的Promotion
  • 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.

    九.脚本的执行
  • 测试执行进入准则
  • 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产生的测试报告

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

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

    你可能感兴趣的:(maven,UI,脚本,项目管理,cvs)