软件自动化测试技术教案.doc

软件测试自动化概述如何理解软件测试请三位同学谈谈对软件测试的理解大家一起来找碴游戏告诉我们什么软件测试是发现结果（软件的实际输出或行为）与目标（预期）差距的过程为什么进行测试演示图 01演示告诉我们世上不存在没有缺陷的软件修复缺陷能够提高软件质量关于软件测试的常见误区测试保证质量测试能够提高质量，质量受很多因素影响测试通过了，软件没有缺陷测试只能证明缺陷的存在，而非不存在做测试很容易入门的容易只是冰山一角周峰之前是华为的资深软件测试工程师，目前是上海博为峰软件技术有限公司、无忧测试网（51testing）的创始人之一，他的工作，就是培训一批又一批的软件测试员。 他表示，很多人认为软件测试只是在软件编写完成以后通过简单使用发现Bug，没有什么技术含量，甚至临时从车间厂房里拉出来的女工也可以承担。 而事实上，在国外许多国家的软件公司，软件测试工作已经逐渐演变成一门独立的科学，包括了配置方案、测试机制、跨平台策略和产品性能、稳定性等独立区域的知识模块。 同时，软件测试员需要参与包括需求分析设计编码等所有软件开发环节，尽可能地发现每个环节可能存在的Bug。“这是一个要求非常高的职业。”软件测试的最佳实践尽早测试80-20原则80的缺陷聚集在20的模块中，经常出错的模块改错后还会经常出错测试应当循序渐进，不要企图一次性干完，注意“欲速则不达”软件测试的职业发展质量之路，势在必行91%的国内软件企业配备了测试队伍 69%的企业认为通过测试后软件质量得到很好提高 CMM/CMMI认证已经成为欧美国家寻求合适软件企业的一个重要的评判标准 企业软件测试人员现状微软公司是1：2 windows2000 操作系统在研发过程中甚至使用了250名项目经理、1700名软件开发工程师、3200名软件测试工程师测试职业素质需求沟通能力技术能力怀疑精神洞察力软件测试职业发展回顾如何理解软件测试软件测试的职业发展课外参考软件测试的艺术，机械工业出版社软件测试自动化的价值和可行性关于自动化价值的观点Ed Kit认为测试自动化输出的制品需重用17次才能抵消之前投入的成本Hancock认为是15次Dan认为在持续集成的冒烟测试当中，自动化测试会非常的有价值dan列举了数据说明：每周需要对100个交易界面，运行7000个数据驱动测试，每次运行需要12小时；而前期的投入是35天作者基于Hancock和Dan的观点，总结出在单元测试（JUnit）和集成测试（冒烟测试）中应用自动化是非常有价值的自动化谁说了算时间就是BOSS自动化要更耗时自动化依赖稳定的特征时间紧，就Say No自动化的建立时间消耗是比手工多的，因为自动化必须经历手工的步骤自动化需要基于稳定的应用特征（需求），一旦特征变化，自动化测试的制品可能无效，也就意味着前期的投入是无效的除非为自动化测试独立计划了时间，像进度很紧的项目可以不用考虑使用自动化了RIO分析规模与复杂度版本构建次数特征的有效性自动化的准确率AUT不复杂不大，则否少于3个构建版本，则否特征不是100有效，则否时间表紧，且交付间隔很短，则否特征不能通过自动化测试100准确测试（随机值或稳定性），则否一个定量的例子手工执行耗时6小时自动前期投入18小时自动执行耗时36分钟对什么自动化Where单元测试冒烟测试集成测试系统测试回归测试性能测试测试自动化的成熟度级别1 捕获和回放好处自动化的测试脚本能够被自动的生成，而不需要有任何的编程知识。缺点你会拥有大量的测试脚本，同时当需求和应用发生变化时相应的测试脚本也必须被重新录制。用法当测试的系统不会发生变化时 小规模的自动化。这是使用自动化测试的最低的级别，同时这并不是自动化测试最有用的使用方式。好处自动化的测试脚本能够被自动的生成，而不需要有任何的编程知识。缺点你会拥有大量的测试脚本，同时当需求胡子和应用发生变化时相应的测试脚本也必须被重新录制。用法当测试的系统不会发生变化时 小规模的自动化。级别2 捕获、编辑和回放好处 测试脚本开始变得更加的完善和灵活，并且可以大大的减少脚本的数量和维护的工作。 缺点 需要一定的编知识。频繁的变化可能会引起变更和维护几乎是不可能的。 用法 当进行回归测试时，被测试的应用有很小的变化，比如仅仅是针对计算的代码变化，但是没有关于 GUI 界面的变化。 你能够使用这种技术通过快速的编制一些测试脚本以检验你的想法来探索你的预定的测试设计。当我在没有任何象需求或者设计模型这样的文档的情况下第一次操作一个产品时和我需要获得一系列内部构建版本的稳定性的第一印象时，我使用过这种技术。通常如果适当的软件配置管理（SCM）与良好的内建设计相结合时，使用级别 2 的技术已经足够了。级别3 编程和回放 好处 更早、灵活、组件复用。 缺点 要求测试人员具有很好的软件技能，包括设计、开发等。 用法 大规模的测试套件被开发、执行和维护的专业自动化测试。级别 3 使你能够使用自动化测试并构建不同的回归测试（重用已有的自动化测试用例）。根据我的经验在看到更多切实的回报之前，为了达到这个级别，有大量的工作和影响项目的活动必须被做。因此快速的建立和证明自动化测试的价值是至关重要的。找到乏味的测试（例如，边缘测试和特定的功能测试用例是首先进行自动化测试的良好候选者）。首先创建少量的能够测试一些基本功能（比如，登陆和创建用户等）的测自动化测试用例。级别4 数据驱动的测试 好处 更专注测试数据，维护更容易。 缺点 软件开发的技能是基础，并且需要访问相关的测试数据。 用法 大规模的测试套件被开发、执行和维护的专业自动化测试。要求一些非常良好的测试数据。一个测试人员必须要花费一些时间来识别在哪里收集数据和收集哪些数据。使用现实生活中的数据是最基本的以从测试中得到完全的回报。使用适当的数据将为你提供通常仅仅在项目的后期才会发现的或者是有客户发现的错误的能力。现在你能够通过使用现实的数据开运行大量的测试。级别5 使用动作词的测试自动化 好处 测试用例的设计被从测试工具中分离了出来 关注在设计良好的测试用例上。允许快速的测试用例的执行和基于用例的更好的估计。 缺点 需要一个具有工具技能和开发技能的测试团队，以提供并维护测试工程（框架）。 用法 专业的测试自动化将技能的使用最优化的结合起来 回顾 关于自动化价值的观点 自动化谁说了算 对什么自动化 测试自动化的成熟度实战单元测试单元测试概述单元测试的效益 尽早发现缺陷 质量提高了 成本降低了 提升程序员的能力 适应变化 改良代码的整体结构 重构代码错误的分类 本质 功能错误 性能问题 表象 有特征错误 类型转换，运算符 无特征错误 资源释放有特征错误具有如下特点： 容易自我暴露：现代的编译器通常会对具有语法特征错误的代码发出警告，行为特征错误通常会导致程序崩溃，从而将错误暴露出来。 易于定位和调试：语法特征错误一般是很容易定位和修正的，行为特征错误也比较容易定位，根据程序的崩溃地址一般就能定位到源代码，错误源与错误暴露的位置相隔一般也不太远。 数量较少：有特征错误和无特征错误各占多少比例呢？很难有一个准确的数据，不同的团队，不同的开发人员，比例会有所不同，一般来说有特征错误不会超过百分之二十，读者可以根据自己的经验评估一下。 可能被自动测试工具发现：有特征错误具有可识别的语法特征或可捕捉的行为特征，因此可能被自动测试工具发现。 总之，有特征错误对于用户来说，当然是不可接受的，但对于开发商来说，发现并消除有特征错误的成本相对较低四种行为方法 人工静态分析 代码走查 自动静态分析 pclint、checkstyle 自动动态测试 VU、C+ test、Jtest 人工动态测试 手工设计测试用例人工静态分析：通过人工阅读代码来查找错误，一般是程序员交叉查看对方的代码，可能发现有特征错误和无特征错误。 自动静态分析：使用工具扫描代码，根据某些预先设定的错误特征，发现并报告代码中的可能错误，自动静态分析只能发现语法特征错误。 自动动态测试：使用工具自动生成测试用例并执行被测试程序，通过捕捉某些行为特征（如产生异常/程序崩溃等）来发现并报告错误，自动动态测试只能发现行为特征错误，对无特征错误完全无能为力，例如，前面所说的加法函数，代码可以说是最简单的，错误也是最简单的，但是自动动态测试仍然无法发现，因为测试工具不可能自动了解代码的功能。 人工动态测试：人工设定程序的输入和预期的正确输出，执行程序，并判断实际输出是否符合预期，如果不符合预期，自动报告错误。这里所说的人工，仅指测试用例的输入和预期输出是人工设定的，其他工作可以由人工完成，也可以借助工具自动完成。人工动态测试可以发现有特征错误和无特征错误，例如，前面所说的加法函数，只要人工建立一个测试用例，输入两个1，并判断输出是否等于2，运行测试，就可以发现代码中含有错误。 测试能否彻底？ 理想的彻底与理论的彻底 等价划分的通常途径 正常输入，边界输入，非法输入 彻底的“三步法” 人工设计测试用例进行基本功能测试 统计白盒覆盖率，针对不足设计用例 实现100%语句、条件、分支、路径覆盖 自动生成大量的测试用例，捕捉程序员未处理某些特殊输入形成的错误 实战单元测试JUnitJUnit是由 Erich Gamma 和 Kent Beck 编写的一个回归测试框架（regression testing framework）。 JUnit 报告JUnit 应用评价 优点： 优秀的单元测试框架 成熟的辅助工具支撑 成熟的开发方法论体系 不足： 依赖性 测试数据“硬编码”JTestcase JTestCase 使用XML文件来组织多测试案例数据，声明条件（操作和期望的结果），提供了一套易于使用的方法来检索XML中的测试案例，按照数据文件的定义来声明结果 JetifJetif是一个用纯Java实现的回归测试框架。它为Java程序单元测试以及功能测试提供了一个简单而且可 伸缩的架构，可以用于个人开发或企业级开发的测试。它容易使用，功能强大，而且拥有一些企业级测试的 重要功能。 演示参考资料 JUnit In Action JUnit Recipes回顾 单元测试概述 实战单元测试 JUnit JTestcase + JUnit Jetif持续集成持续集成持续集成部署持续集成周期持续集成的益处 能最小化集成风险 能减小产品低质量的风险 能简单化错误诊断 能极大鼓舞项目组的士气 No more “But it works on my machine!”1、能最小化集成风险 项目组可能遇到的一个很大的风险是，项目组成员根据不同的系统功能各自开发不同的代码，但是当这些代码集成为一个系统的时候，也许系统完成不了预期的功能。这种风险的发生取决于项目中的这种不兼容性多久才被发现，由于程序界面已经发生了变化，或者系统的主要部分已经被重新设计和重新实现了，相应的排错工作将非常困难和耗时。极端情况下，集成的错误可能回导致项目被取消掉。每日构造和冒烟测试可以使这种集成错误变得非常小，而且便于解决，防止了很多集成问题的产生。2、能减小产品低质量的风险 这种风险是和集成不成功、集成出错相关联的。每天对集成的代码做一些少量的冒烟测试，即可杜绝项目中那些基本的质量问题。通过这种方式，使系统达到一种周知的良好状态，维护这样的系统可以防止系统逐步恶化到耗费大量时间排查质量问题的地步。3、能简单化错误诊断当系统每天都进行build和测试时，系统任何一天发生的错误都能够变得十分精细，便于排查。比如在17日系统还运行正常，18日就出错了，那么只需要检查这两次build之间的代码变化就可以了。4、能极大鼓舞项目组的士气 看到产品的不断成长，能够极大的鼓舞项目组的士气，有时甚至不管这个产品到底用来做什么。开发人员可能会为系统显示了一个矩形而感到激动。通过每日构造，产品每天进步一点,保证项目士气的持续高涨。必要的东西 版本控制 同步工作内容 自动化测试套件 增强信心 自动化构建套件 告诉计算机怎么做构建版本目录结构ANT构建配置路径与环境变量任务目标自动化测试CruiseControl托管构建文件配置文件报告网站邮件报告 失败邮件报告 成功演示数据驱动测试框架数据驱动的方法自动化发展的三个阶段 基本的GUI测试 捕获、编辑和回放 脚本编制 工程化，可复用 资源控制 通用脚本 设计与自动化分离什么是数据驱动测试（DDT） 数据驱动测试就是一种数据被包含在输入测试数据文件中，并且数据控制自动化测试脚本执行的流程和动作的测试。 数据文件独立于测试脚本程序的开发数据文件 测试数据 输入和预期输出 控制数据 引导测试脚本到达应用程序中合适的位置执行测试和通过指示要执行的测试或动作的类型来驱动测试脚本。 CSV？数据驱动测试的脚本特征 使用简单的输入文本文件 有很高的可维护性 容易被非编程人员使用 存档正在执行的测试 借助占位符允许动态数据输 用输入数据控制测试的执行数据驱动测试的内容 能输入到程序中的参数 用来使程序运行的操作或命令序列。 驱动程序的测试数据序列。 触发测试脚本在运行的时候产生动态数据值的占位符 程序读和处理的文档。数据驱动测试的好处 当增加额外的测试数据时不必修改测试脚本因为测试数据会被追加到现有的文本文件中。 很容易修改数据记录。 多个测试数据记录可以开发成为函数变量。 需要时可以创建和使用多个输人数据文件Archer Group框架框架驱动测试脚本 是测试工具编程语言中的基本命令 可独立于UI进行编程 脚本级别 菜单/命令 对象 任务对象命令任务Archer Group框架CSDDT Control Synchronize Data-Driven Testing CSDDT规定了 在AUT中应该何去何从；窗口、标签页、对话框等的导航；测试活动的目标。 每一步要干什么，要执行的动作。 动作执行后期望得到的结果 是否希望错误出现或正常状态。 用于输入或标准选择的数据。记录类型 好的 G 跳过 H 记录是坏的或不完成的或者是用来注释下面记录的。 断点 B 调试 特殊 K 如关键字替换。 EOF X 终止测试测试类型 GUI测试 属性测试 特定特征测试 数据库内容初始化测试程序 业务规则测试 性能和/或负载测试CSDDT测试脚本组件测试脚本组件 外壳(Shell)脚本 主(Main)脚本脂序 窗口选择(Window selection)脚本程序 标签页选择(Tab selection)脚本程序 动作选择(Action selection)脚本程序 错误检测(Error selection)脚本程序 其他支持函数和包含文件主程序的步骤 打开文件。 输入主过程循环。 读取数据记录的前七个字段。 识别Rec_Type 读取数据，执行行为 循环读取下一条记录，或结束。控制码的秘密场景实战 自动化过程演示 单步调试脚本，演示细节实现课堂实践 设计一个特征的测试用例 构思测试脚本的运行思路 编制一条测试数据记录剖析框架形成可维护性QQ的好友列表一望无际的“乱” 面对一个1000行代码文件 难理解 难查找 多点变化 “错误是在所难免的！”没有框架的年代 案例 计算器 测试加法和减法 思考 测试脚本伪代码测试脚本模块化框架测试加法的脚本case测试减法的脚本case套件脚本suite顶层脚本suite框架 组织结构 ？顶层套件套件套件用例用例用例用例用例模块化框架小结 分类组织 隔离依赖 变化限于局部测试库构架框架头文件库文件测试脚本抽象 发现重复 点击按钮 如何复用 建立映射映射库构架框架小结 高度抽象 高度复用 单点变化驱动测试框架一个表数据关键字驱动表数据的映射关系框架脚本的模版驱动测试框架小结 数据与脚本分离 设计与脚本开发