杂谈测试那些事解读.ppt

a）第一代自动化测试，即自动化测试思想刚开始诞生时，依靠的是传统的“录制-回放”技术，这种技术与现在的工具的“录制-回放”思想不一样，其其实就是一个“模拟”的过程，即模拟你对PC的操作而形成的，其基于你对键盘的输入与对鼠标的操作，原理与按键精灵等类似，这种机制对环境的依赖性太强，对变化性太过于敏感，因此不可能发展成一种规模。 b）第二代自动化测试，即脚本化的自动化测试，利用脚本进行结构化的自动化测试，开始集成了模块化与库思想。 c）第三代自动化测试，开始产生了各种自动化测试思想，包括数据驱动与关键字驱动思想，其伴随着对象化思想的产生，而且也造就了现在一系列的自动化测试软件，其实其中都集成了这些思想，从这时候开始，自动化就开始实现了一定的规模，开始运用在各个行业，并且发展趋势越来越快。 ??数据驱动测试框架（The Data-Driven Testing Framework） 说明： 仅仅是将测试数据从测试脚本中分离出来，开始了非混沌状态的第一步，这也是所有测试架构中最简单的一种 ? 优点： 至少测试数据可以单独维护了 ? 缺点： 任何被测试程序的变更所导致的工作量是所有架构中最多的，因此维护成本非常高 试脚本模块化框架（The Test Script Modularity Framework） ??? 说明： 箭头方向代表的是被调用和调用关系 测试脚本中包含了各功能点中涉及到的控件识别和业务逻辑操作，其中包含了外部测试数据的调用 测试脚本的维护由自动化测试开发工程师负责，要求必须懂自动化编程和业务逻辑 测试数据的维护由测试工程师负责 ? 优点： 控件和业务逻辑一旦发生变化，要进行修改和维护的是底层的测试脚本（比无任何抽象封装的自动化测试程序稍好一些） ? 缺点： l??几乎所有大的变更引起的工作量都由自动化测试开发工程师完成 l??控件识别和业务逻辑本身属于不同的领域，没有很好进行抽象封装 ? ? 测试库构架框架（The Test Library Architecture Framework） 说明： 箭头方向代表的是被调用和调用关系 将所有的针对测试系统本身的控件识别和控件支持的操作封装在测试库中 测试脚本调用测试库的同时传递外部的测试数据 测试库的编写由自动化测试开发工程编写（可以不懂业务），负责控件的变更和维护 测试脚本的编写可由对业务比较掌握的自动化测试开发工程编写，负责业务逻辑的变更和维护 测试数据由测试工程师维护（可以不懂自动化开发） 优点： 被测试系统无论是哪层发生变化，只需要相应的人员进行变更维护即可 完成了控件识别操作和业务逻辑的抽象分离 缺点：变更引起的工作量还是附加在自动化测试开发工程师身上 关键字驱动或表驱动测试框架（The Keyword-Driven or Table-Driven Testing Framework） 优点： 极大的减少了自动化开发工程师维护量，毕竟在测试团队中，自动化开发工程师占的比较少 普通测试工程师，可以很好的维护自身负责的模块中涉及的测试case和测试数据 ? 缺点： 框架的抽象程度比较高，对自动化测试工程师的开发能力比较高 简单操作 简单维护 简单拓展 * 谢 谢 SRS：《需求说明书》 * * 软件测试按测试阶段划分 单元测试-集成测试-系统测试-验收（用户）测试 Sit（系统集成测试）-Uat（用户测试）-回归测试（可能出现在任何测试阶段） * 单元测试属白盒测试 单元测试就是对软件基本组成单元进行测试，单元测试的对象是函数或一个类的方法 单元测试的目的是发现各模块内部可能存在的各种错误， 其关注的重点是：单元接口，局部数据结构，边界条件，独立路径，出错处理 单元测试的过程：单元测试计划阶段、单元测试设计阶段、单元测试实现阶段、单元测试执行阶段 * * * * 集成测试属灰盒测试 * 系统测试属于黑盒测试 * * * * 软件的特性是否与需求相符； 所有的文档都是正确且便于使用； 同时，对其它软件需求，例如可移植性、兼容性、出错自动恢复、可维护性等，也都要进行测试 单元、集成、系统测试之间比较 测试方法不同：分别属于白盒测试、灰盒测试、黑盒测试 测试范围不同： 单元测试主要检查单元内部的数据结构、逻辑控制、异常处理等 集成测试主要测试模块之间的接口和接口数据传递关系，以及模块组合的整体功能 系统测试主要测试整个系统相对于需求的符合度 评估基准不同：分别是检查逻辑覆盖率、接口覆盖率、测试用例对需求规格的覆盖率 * 验收测试 在通过了内部系统测试及软件配置审查之后，就可以开始验收测试。 验收测试是以用户为主的测试，验收组应该由项目组成员、用户代表等组成。 验收测试根据合同、《需求规格说明书》或《验收测试计划》对成品进行验收测