BPS6.0Studio自动化测试预研.doc

BPS6.0Studio自动化测试预研 背景介绍 BPS6.0开发版测试用例目前已经达到1300条，手工执行耗时较久，打补丁时版本回归效率不高，所以考虑采用RFT工具，对其中大部分用例采用自动化测试，提高版本回归效率和验证质量。 预研目标 研究通过目前主流的功能测试工具RFT实现BPS6.0Studio自动化测试的可行性，并设计出可行的实施方案。 读者对象 项目经理 测试经理 测试设计人员和执行人员 参考资料 EOS6.0 Studio自动化测试项目 EOS6.0 Studio 实现自动化的相关知识点 预研成果 BPS6.0 Studio自动化测试可行性分析 BPS6.0 Studio自动化测试代码框架及示例项目 BPS6.0 Studio自动化测试实施方案 预研报告 本次技术可行性预研主要针对BPS6.0 开发版Studio部分进行自动化测试，测试工具采用RFT，实现从版本安装、studio启动、用例自动执行到测试报告自动生成的自动化过程。 测试环境: 测试工具：RFT（Rational Functional Tester 7.0.0）试用版 版本控制工具：CVS 测试机：实体PC（192.168.0.21） 测试项目 本次预研定义了BPS6.0自动化测试项目的代码框架雏形,并设计了一个示例项目,存放在在CVS中,地址为: :pserver:lilb@192.168.2.25:/cvsroot/BPS6/develop/test/stest/studio/bps6 项目名称为bps6，目前存在四个文件夹,对应的资源存放介绍: com:生成测试报告对应的java文件。 lib:存放脚本编译和运行依赖的jar包。 util:公共类库，包括在EOS6自动化测试中提炼出来的TreeUtil，OpenFile等公共类，以及存放后期在BPS6.0 Studio测试中提炼出来的公共类。 preresearch:可执行的测试代码.包括入口脚本和测试脚本. 测试脚本 测试脚本目前阶段采用录制的形式生成,辅以手工修改.其中代码为java语言编写,符合我们的开发习惯和知识结构,很快就上手. 测试脚本分为入口脚本和用例脚本, 入口脚本以“_Auto”结尾,作用是调用该目录下的用例,并被上级入口脚本调用,在测试报告中不予统计. 下为入口脚本中代码示例,通过callScript()方法调用其他用例脚本. 理论上来讲,一个用例脚本应该对应一条用例,通过在脚本中添加验证点的方式,验证用例中的预期结果.但由于用例数目庞大,按照这种方式实现有些困难,必要时可以采用在一个测试脚本中添加多条用例. 验证点添加： ???本中对预期结果通过验证点的方式来验证,验证点可以在录制过程中添加,也可以在录制完修改时添加. 添加的验证点代码如下: text().performTest(项目名称默认为空VP()); 因需要在测试报告中显示验证点信息,需要做以下修改: casebean.status = casebean.status text().performTest(项目名称默认为空VP()); vpointList.add(new CaseVerifyPoint(项目名称默认为空VP().getVPName(), casebean.status)); 日志报告： 用例脚本头加入用例描述信息,在测试报告中显示为标题: casebean.setInfo（该脚本的测试点等信息）；,并且该报告可以以邮件的形式通知相关责任人. 异常处理： 为了增强测试代码的健壮性和容错性,代码块加入到try…catch语句,即使测试中出现错误,也可以保证测试代码运行完 try { // Frame: BPS 开发 － BPS Studio menu().click(atPath(文件(F))); menu().click(atPath(文件(F)-新建(N))); menu().click(atPath(文件(F)-新建(N)-项目(R)...)); } catch (Throwable e) { e.printStackTrace(); casebean.status = false; casebean.exception = e.toString(); } finally { callScript(util.ResetPerspective); } 风险及难点分析: 流程Schema文件验证 流程的正确性校验,理论上应该在Server启动后客户端进行检查,但这样会占用较多测试资源,加大出错几率.所以考虑预先定义好正确的流程Schema模板,再将测试代码生成的流程文件与后用预先定义的模板进行对比.模板的准备过程会存在较大