这段时间正在为这个架构申请公司的一个创新大奖，也准备了一下PPT介绍，我把其中的几页摘下来供大家参考。有同事推荐这个创新大奖完了之后，我将有可能会去申请一下专利。

　　下面是对该架构技术的一些重点：

　　我还想谈一下测试与开发的关系，因为这个架构在测试公司的新项目(Web service类的BOSS业务)中发现了大量的问题，这个新项目设计到的SOAP接口也是20几个新接口，但是通过ROBOT架构自动产生了超过 5000个CASE(其中包括了枚举值，边界值，异常数据，各类自定制的参数组合)，自动产生200000的数据库检查点，完全通过自动化回归的方式进行 CASE执行和结果点检查，结果短短几个星期内发现了超过一百个问题，而且很多是严重问题。在刚支持的IPTV业务上，也只是花了几天时间支持了其中一个应用的自动化测试，结果也发现了几个严重问题，这种成果是以前任何一种架构的自动化所无法比拟的。开发部门也对这个架构刮目相看，专门组织了几次培训来学习这个架构，因此我这段时间也在帮开发建立他们内部的单元测试体系，开发也认真的投入到了测试当中，和我们一起为提高测试质量而共同探讨测试技术，我们也向开发提出了各种要求来配合我们自动化CASE的产生，从这点来看，开发与测试的关系并不一定是对立的，当我们的创新给开发带来了软件质量水平的提高，他们反过来会更加尊敬测试团队。

　　这几天有点忙，我们的BOSS系统已经比较稳定，但是近根据某个运营商提的需求对系统的框架进行了比较大的改动，安排了几个同事进行新接口的测试，从上星期开始，一切似乎比较正常，没有发现一些大的问题。但是，做测试的人一般都会有这种直觉，没有发现问题才是大的问题!而且与开发沟通知道改动量并不少，所以有抱着比较怀疑的态度，本来想着在测试的后期再安排回归的，在这种状况下要把回归提前了。

　　因为改动的主要是业务受理接口，主要是对这块的CASE进行回归，CASE大概是2000个，结果检查点有200000。于是运用了UT ROBOT框架做了一次回归测试，运行到差不多第100个CASE的时候，以前正常的一个CASE报错，于是查了一下错误的代码，将测试结果交给开发分析，发现对某个表的status字段处理上，对于status=00001与status=000001出了问题，再一细查所有的代码，发现竟然有30多处的判断处理中存在这个问题;而同时进行的手工测试没有发现这个重大问题，与开发沟通知道，这次的改动主要包括出错的地方。ROBOT再次立功!除此以外，ROBOT也还发现了其它几个重要问题。

　　回归迭代测试不可少，有效的框架是解决回归迭代测试的有效途径!

　　另外，这几天也在忙于IPTV业务的Web Service的自动化支持模板改造，可能要几天之后才能完成，到时再给大家报告新动向。

　　多谢大家的捧场!刚过去的一周事情比较多，除了培训，日程项目安排管理，为下周的客户来公司参观准备DEMO环境之外，也刚刚参加完公司的一个比赛。

　　这个比赛的目的是提升公司各个环节的持续改进能力，终达到提高质量，降低成本，缩短周期的目标。ROBOT作为参赛项目之一，一共有18只队伍参加，参赛队伍覆盖了从生产线、质量部、客服部、技术支持部、研发部等各个环节的部门;大部分的队伍都是与生产线有关，因为生产线是好量化及体现成本节约成果的。我们的队伍是两只与软件测试相关的队伍之一。比赛在杭州与深圳通过视频会议两地同步进行，总体感觉演讲的效果还不错，赢得了不少的掌声。有幸的 ROBOT项目进入了8强，下周要参加在杭州的总决赛。

　　言归正传，我们还是来讨论自动化技术方案。上参加了IBM举办的技术加油站，主要是以介绍工具为主，感觉IBM的测试工具是进行界面的自动化录制等等，与行业的LR，QTP没有太本质的区别，对于接口测试，举了SOA应用的例子，感觉也是简单的手工接口测试，要想实现大规模的接口回归测试还有很大的差距，如果要想支持不同特点的应用的测试更加不可能。

　　我一直提倡用有效性来衡量一项创新的用途，包括自动化测试也一样，如果自动化测试单纯停留在宣传上说又多么多么的重要，多么多么的节省人力，另外一方面却发现不了问题，没有数据的支撑的话，是经不起时间考验的，更不能说服别人心甘情愿的学习和推行自动化。另外一方面，如果自动化很有效果，但要花很多时间去写自动化脚本的话，其维护量是惊人的，这条路走起来代价非常大，测试人员根本享受不到自动化带来的便捷，因为我们以前是走过弯路的，所以感受特别深;试想，当你开发了一万个CASE，但是一旦系统修改了设计，要去修改一半的CASE，即使你再有耐心，也会被这种修改脚本的无意义劳动所打倒。

　　如果想当然的认为一个软件版本到一定程度能稳定，那是理想的状况，一般情况下除非小软件或者软件被废弃了才会有这种情况，实际情况下，对于有一定规模的软件公司，其软件版本的代码超过千万行是很普遍的，而且系统会随着不同客户的需求不断的增加修改和删除，这是软件缺陷的来源。UT ROBOT是在这种背景下产生的，把ROBOT比喻为一条生产线的话，解析引擎是核心，抽象的模板的机器运转的传输带，数据是原料，数据整合部分一个过滤器，分离的结果检查点则是自动质检系统，每一部分看似都是独立的部分，因为独立也意味着低耦合，这也是ROBOT能实现不同类型的软件自动化测试的原因。

　　有很多人发邮件问我ROBOT怎么可能不需要编写脚本，其实大家有所误解，ROBOT与业务无关，但是对于数据模板的解析还是要根据不同的应用进行模块化扩充的，实际的扩充代价是比较少，因为我把模板中的标签进行了自动解析识别，增加模板中的元素只需要配置解析的规则可以轻易支持新的模板。另外如果有新的传输协议，还是要增加底层支持的。一旦新的模板加入，测试人员只需要根据接口文档进行业务数据接口配置，再通过ROBOT的编译引擎产生大量的自动化可执行CASE，一定业务逻辑发生了变化，只需要在数据配置文档进行数据的修改，重新编译数据文档可以重新生成自动化CASE，维护代价是非常低的。

　　我认为如果要推行自动化测试，不要盲目的使用商业测试工具，从长远来讲，要根据各行业各公司的特点去开发符合自己需求的的自动化框架。测试无止境，需要我们在平时的工作中敢于发现问题、多从不同的角度去思考，才能真正开发出有效的自动化测试软件，技术不是自动化重要的因素，好的想法才是王道。