1.EOS6中studio自动化做的工作.doc

HYPERLINK // Page  PAGE 7 of  NUMPAGES 7 Studio自动化的总结和新项目开展的建议 EOS6中studio自动化做的工作 1.1完成部分模块自动用例 目前共完成了685个自动用例，占总用例数的12% ，大大提高了验证版本和执行的效率。 其中包括数据实体，组合向导的90%的自动用例，资源管理器，导出部署包，逻辑流编辑器的部分用例。 目前的自动化用例是根据经过评审和执行过的手工测试用例来写的，手工用例基本上是都可以转换成自动用例的。 1.2完成RFT定制报告 在RFT的基础上做了自己定制的报告，可以整体脚本执行，也可以单独脚本执行。 主要增加了用例注释，验证点注释，捕获异常，整体报告的成功失败的统计功能，发邮件功能。保证方便的执行用例，查看结果和查找问题。 1.3建立公共类库 公共类库的主要内容是： 1.录制方式难以识别和容易混淆的对象，用其它方式实现 2.RFT的扩展校验点 3.每个模块都会用到的初始化环境之类的测试过程脚本 公共类库的主要目的是保证用例的覆盖率，脚本的执行顺畅和脚本的可维护性。 1.4建立了RFT代码规范 为保证所有模块的用例集成后可以完整的运行，同时保证用例的可读性和可维护性，制定的规范，主要包括： 用例命名规范，用例组织规范，用例编写规范，验证点添加及命名规范，测试对象命名规范。这些内容基本也都是在实践中总结出来的。现在的脚本大部分是遵循的。 目前使用的优点和问题 2.1优点： 大大提高了整体效率 原来验证新版本要手工执行4小时，126个用例，现在验证新版本2小时，685个自动用例，效率提高了百倍。 已经有90%用例的数据实体和功能向导，原来一个很熟悉的测试人员执行完都需要四天的时间，现在只需要半天到1天把手工用例执行完就可以了。效率也提高了几倍。 统计用例和查找问题较方便 统计报告中会把整体成功和失败的用例情况统计出结果，方便出最终报告。也会列出失败的用例的描述信息，可以很方便寻找问题。 用例覆盖的模块有改动会很清楚 因为自动化用例的执行不会有遗漏的地方，写了多少执行了就有多少，所以一旦界面上有变化，如果测试人员不知道，还没有改用例，用例执行会比较快的反应出问题。这样测试人员就不会有遗漏的问题。 规范的初步效果 规范中定义过用例脚本的名称规范，规定一个小的文件夹级应该保持独立性等等很多。当时我们要求最高的就是脚本的独立性。这在后续的执行过程中发挥了比较大的作用。比如因为有bug某个小模块用例无法执行下去，还可以把后面的独立用例继续执行。或者有用例结果失败，还可以通过回放的过程中来定位。 问题和改进： 用例还不够多，覆盖面还不够广 目前的用例覆盖还比较少，模块覆盖率也不够高。后续在有时间情况下需要尽量补充，原则上是至少每个模块的基本用例都补上。 可维护性不够强 因为当时优先考虑执行的顺畅，如何识别难辨识对象，和如何有效的对多个模块的用例进行组织，对象和用例分离的方法研究的较晚，所以很多用例还是对象和用例在一起的。若数据实体这样已完成自动用例的模块的功能有大的改动，修改量会相对来说大一些。同时很多脚本中注释较少，对象名称还是通用的很难识别具体对象。阅读起来不是很清楚。 我们后面的用例会要求采用对象和用例分离的三层组织结构来编写脚本，同时要求注释的内容尽量多些。 健壮性不够 在我们近期执行的过程中，发现若有我们未知的提示框或者未知的错误，很可能会导致后续的用例执行不下去，这就需要我们进一步改进脚本，加强异常处理。 在新项目中的问题 3.1：需求变化大，用例改动大 现阶段EOS6的需求基本上变化不大了，改动的地方也不会影响很大，所以用例的修改也是相对较小范围的改动。但是对于新项目来说，在完成用例后，需求再变化的可能性仍然很大，特别是在项目初期，用例刚使用的阶段。 3.2：对象变化大，使得改动脚本较多 RFT脚本都是对界面上对象的操作，一个对象一般都会在很多脚本中使用。。从开发结束到测试阶段，对象的变动也是很正常的，有些可能只是变了对象的名称，有些可能对象的类型都变了，而识别对象是树型的从根识别的。这样要改动的脚本就会很多。 3.3：手工用例不能完全对应自动化脚本 我们在上两个月在做手工和自动用例转换的过程中感觉基本上要对手工用例的结构进行重新组织才能适应自动用例的内容。 因为自动化脚本有有可读性可维护性的要求，所以要求脚本的独立性。因为可以用数据池来造数据，对测试数据也要求比较清晰。因为自动化脚本的验证点很多都是取的对象的值或者直接比对，也和习惯上的手工用例的写法有差别。 给新项目的建议 4.1从用例设计开始考虑自动化的