淘宝应用程序的技术架构
可测试性分析
• Notify:
一种消息服务器，类似于JMS，可以采用测试JMS的方法去测试，细节正 与开发人员研究中。
• Payway: 与支付宝的通路，以及调用外部系统的接口抽象，开发那边已 经有一部分测试，以后可以纳入我们的测试体系。 • Application: 这个包含淘宝所有的业务系统，也是测试的重点，也是
测试的补充
• 根据最终的接口说明复查测试用例 • 根据覆盖率统计报表复查未覆盖到的代码， 并且针对性地补充测试
覆盖标准
• 对于单个接口，已代码覆盖为标准 • 对于流程引擎，以路径覆盖为标准
通过流程设计图抽取出每个完成的流程，然后以 每个完整的流程为一个用例进行测试
Q&A
涉及到的技术
• • • • • • • • • J2EE系列(java, jdbc, jms等) JUNIT或TESTNG(测试框架) SPRING(架构级框架) Ibatis(持久层框架) JBPM(流程引擎) 远程服务 CruiseControl(持续集成服务器) Jclover(基于Java的覆盖率检查工具) Mock技术
测试准备
• 阅读、理解PRD和系统UC • 评审系统设计文档，确保系统的可测试性，接口 定义的合理性 • 编写本地数据源以实现与数据库的直接交互 • 查阅有代码，确定接口的依赖关系，编写相应 spring配置文件组织此依赖关系 • 分析现有资源，以确定测试类层次以及目录结构 • 编写基类，实例化所有需要的接口 • 和测试人员约定脚本规范
用例的编写和管理
• • • • • 目的：保证代码质量 内容：场景，接口输入，期望返回值或异常 形式：JavaD、构建脚本或IDE生成标 准的API文档(HTML格式)
测试用例结构
对单个接口的用例说明
测试用例结构
对单个测试方法的说明
测试脚本结构
• 定义一个或多个基类，视测试复杂度而定
包括处理一个或多个数据源，远程调用，数据解析，文本解析等等
• 所有的测试类继承最后的基类
让测试类使用预先定义的一切功能
• 每个接口一个测试脚本文件 • 对于一个接口，每个用例一个测试函数
创建场景，准备数据，销毁数据采用junit标签技术完成
• 测试集的编写
分层测试
白盒和灰盒
基本概念
• 应用程序分层 1. DAO, Service, Manager, AO, Screen, UI • 分层测试 对应用程序的每一次层都有相应的回归测 试代码与之对应
主要目标
• • • • • 使质量保证体系更加完善 使自动化回归测试效率更高 缩短软件开发周期 提高相关人员查错排错效率 最终提高软件质量
可以根据不同的需要划分测试集
脚本运行
• IDE中直接运行 • MAVEN命令运行(ant也可以，antx据说也可) • CruiseControl持续集成
回归模式
• 手动回归 • 自动回归
让持续集成服务器，按照特定的频率构建项目执行测试， 同时在构建失败时发送失败信息给指定的人，同时可以在 任何时候在服务器上查看构建结果和回归测试结果，整个 过程不需要人工干预 关于持续集成服务器，将在下次分享当中介绍，其中包括 linux使用，数据源的配置，svn的使用，服务器的配置等 等知识
分层测试的终极对象。 目前已经做：DAO, Service, Manager 正在探索：AO 未做：Screen 持续集成：DAO, Service已经纳入，Manager技术障碍需要解决
测试前提
• UC评审完毕 • 系统设计文档评审完毕 • 如果涉及到流程引擎，需要有完整的JBPM 设计图 • 项目源代码工程建立完毕 • 接口文件(Java文件)建立完毕 • 同时有明确的接口说明