软件自动化测试技术教案

《软件自动化测试技术教案》由会员分享，可在线阅读，更多相关《软件自动化测试技术教案（60页珍藏版）》请在金锄头文库上搜索。

1、软件测试自动化概述如何理解软件测试请三位同学谈谈对软件测试的理解大家一起来找碴游戏告诉我们什么软件测试是发现结果（软件的实际输出或行为）与目标（预期）差距的过程为什么进行测试演示图 0-1演示告诉我们世上不存在没有缺陷的软件修复缺陷能够提高软件质量关于软件测试的常见误区测试保证质量测试能够提高质量，质量受很多因素影响测试通过了，软件没有缺陷测试只能证明缺陷的存在，而非不存在做测试很容易入门的容易只是冰山一角周峰之前是华为的资深软件测试工程师，目前是上海博为峰软件技术有限公司、无忧测试网（51testing）的创始人之一，他的工作，就是培训一批又一批的软件测试员。 他表示，很多人认为软件测试只是

2、在软件编写完成以后通过简单使用发现 Bug，没有什么技术含量，甚至临时从车间厂房里拉出来的女工也可以承担。 而事实上，在国外许多国家的软件公司，软件测试工作已经逐渐演变成一门独立的科学，包括了配置方案、测试机制、跨平台策略和产品性能、稳定性等独立区域的知识模块。 同时，软件测试员需要参与包括需求分析设计编码等所有软件开发环节，尽可能地发现每个环节可能存在的 Bug。 “这是一个要求非常高的职业。 ”软件测试的最佳实践尽早测试80-20 原则80的缺陷聚集在 20的模块中，经常出错的模块改错后还会经常出错测试应当循序渐进，不要企图一次性干完，注意“欲速则不达”软件测试的职业发展质量之路，势在必行

3、91%的国内软件企业配备了测试队伍 69%的企业认为通过测试后软件质量得到很好提高 CMM/CMMI 认证已经成为欧美国家寻求合适软件企业的一个重要的评判标准 企业软件测试人员现状微软公司是 1：2windows2000 操作系统在研发过程中甚至使用了 250 名项目经理、1700 名软件开发工程师、3200 名软件测试工程师测试职业素质需求沟通能力技术能力怀疑精神洞察力软件测试职业发展回顾如何理解软件测试软件测试的职业发展课外参考软件测试的艺术，机械工业出版社软件测试自动化的价值和可行性关于自动化价值的观点Ed Kit 认为测试自动化输出的制品需重用 17 次才能抵消之前投入的成本Hanco

4、ck 认为是 15 次Dan 认为在持续集成的冒烟测试当中，自动化测试会非常的有价值dan 列举了数据说明：每周需要对 100 个交易界面，运行 7000 个数据驱动测试，每次运行需要 12 小时；而前期的投入是 35 天作者基于 Hancock 和 Dan 的观点，总结出在单元测试（JUnit）和集成测试（冒烟测试）中应用自动化是非常有价值的自动化谁说了算时间就是 BOSS自动化要更耗时自动化依赖稳定的特征时间紧，就 Say No自动化的建立时间消耗是比手工多的，因为自动化必须经历手工的步骤自动化需要基于稳定的应用特征（需求） ，一旦特征变化，自动化测试的制品可能无效，也就意味着前期的投入是

5、无效的除非为自动化测试独立计划了时间，像进度很紧的项目可以不用考虑使用自动化了RIO 分析规模与复杂度版本构建次数特征的有效性自动化的准确率AUT 不复杂不大，则否少于 3 个构建版本，则否特征不是 100有效，则否时间表紧，且交付间隔很短，则否特征不能通过自动化测试 100准确测试（随机值或稳定性） ，则否一个定量的例子手工执行耗时 6 小时自动前期投入 18 小时自动执行耗时 36 分钟对什么自动化Where单元测试冒烟测试集成测试系统测试回归测试性能测试1 2 34 5 自 动手 动024681012141618测试自动化的成熟度级别 1 捕获和回放好处 自动化的测试脚本能够被自动的生成

6、，而不需要有任何的编程知识。缺点 你会拥有大量的测试脚本，同时当需求和应用发生变化时相应的测试脚本也必须被重新录制。用法 当测试的系统不会发生变化时 小规模的自动化。这是使用自动化测试的最低的级别，同时这并不是自动化测试最有用的使用方式。好处 自动化的测试脚本能够被自动的生成，而不需要有任何的编程知识。缺点 你会拥有大量的测试脚本，同时当需求胡子和应用发生变化时相应的测试脚本也必须被重新录制。用法 当测试的系统不会发生变化时 小规模的自动化。级别 2 捕获、编辑和回放好处 测试脚本开始变得更加的完善和灵活，并且可以大大的减少脚本的数量和维护的工作。缺点 需要一定的编知识。频繁的变化可能会引起变

7、更和维护几乎是不可能的。 用法 当进行回归测试时，被测试的应用有很小的变化，比如仅仅是针对计算的代码变化，但是没有关于 GUI 界面的变化。 你能够使用这种技术通过快速的编制一些测试脚本以检验你的想法来探索你的预定的测试设计。当我在没有任何象需求或者设计模型这样的文档的情况下第一次操作一个产品时和我需要获得一系列内部构建版本的稳定性的第一印象时，我使用过这种技术。通常如果适当的软件配置管理（SCM）与良好的内建设计相结合时，使用级别 2 的技术已经足够了。级别 3 编程和回放 好处 更早、灵活、组件复用。 缺点 要求测试人员具有很好的软件技能，包括设计、开发等。 用法 大规模的测试套件被开发、

8、执行和维护的专业自动化测试。级别 3 使你能够使用自动化测试并构建不同的回归测试（重用已有的自动化测试用例）。根据我的经验在看到更多切实的回报之前，为了达到这个级别，有大量的工作和影响项目的活动必须被做。因此快速的建立和证明自动化测试的价值是至关重要的。找到乏味的测试（例如，边缘测试和特定的功能测试用例是首先进行自动化测试的良好候选者） 。首先创建少量的能够测试一些基本功能（比如，登陆和创建用户等）的测自动化测试用例。级别 4 数据驱动的测试 好处 更专注测试数据，维护更容易。 缺点 软件开发的技能是基础，并且需要访问相关的测试数据。 用法 大规模的测试套件被开发、执行和维护的专业自动化测试。

9、要求一些非常良好的测试数据。一个测试人员必须要花费一些时间来识别在哪里收集数据和收集哪些数据。使用现实生活中的数据是最基本的以从测试中得到完全的回报。使用适当的数据将为你提供通常仅仅在项目的后期才会发现的或者是有客户发现的错误的能力。现在你能够通过使用现实的数据开运行大量的测试。级别 5 使用动作词的测试自动化 好处 测试用例的设计被从测试工具中分离了出来 关注在设计良好的测试用例上。允许快速的测试用例的执行和基于用例的更好的估计。 缺点 需要一个具有工具技能和开发技能的测试团队，以提供并维护测试工程（框架） 。 用法 专业的测试自动化将技能的使用最优化的结合起来 回顾 关于自动化价值的观点

10、自动化谁说了算 对什么自动化 测试自动化的成熟度实战单元测试单元测试概述单元测试的效益 尽早发现缺陷 质量提高了 成本降低了 提升程序员的能力 适应变化 改良代码的整体结构 重构代码错误的分类 本质 功能错误 性能问题 表象 有特征错误 类型转换，运算符 无特征错误 资源释放有特征错误具有如下特点：容易自我暴露：现代的编译器通常会对具有语法特征错误的代码发出警告，行为特征错误通常会导致程序崩溃，从而将错误暴露出来。易于定位和调试：语法特征错误一般是很容易定位和修正的，行为特征错误也比较容易定位，根据程序的崩溃地址一般就能定位到源代码，错误源与错误暴露的位置相隔一般也不太远。数量较少：有特征错误

11、和无特征错误各占多少比例呢？很难有一个准确的数据，不同的团队，不同的开发人员，比例会有所不同，一般来说有特征错误不会超过百分之二十，读者可以根据自己的经验评估一下。可能被自动测试工具发现：有特征错误具有可识别的语法特征或可捕捉的行为特征，因此可能被自动测试工具发现。总之，有特征错误对于用户来说，当然是不可接受的，但对于开发商来说，发现并消除有特征错误的成本相对较低四种行为方法 人工静态分析 代码走查 自动静态分析 pclint、checkstyle 自动动态测试 VU、C+ test、Jtest 人工动态测试 手工设计测试用例人工静态分析：通过人工阅读代码来查找错误，一般是程序员交叉查看对方的

12、代码，可能发现有特征错误和无特征错误。自动静态分析：使用工具扫描代码，根据某些预先设定的错误特征，发现并报告代码中的可能错误，自动静态分析只能发现语法特征错误。自动动态测试：使用工具自动生成测试用例并执行被测试程序，通过捕捉某些行为特征（如产生异常/程序崩溃等）来发现并报告错误，自动动态测试只能发现行为特征错误，对无特征错误完全无能为力，例如，前面所说的加法函数，代码可以说是最简单的，错误也是最简单的，但是自动动态测试仍然无法发现，因为测试工具不可能自动了解代码的功能。人工动态测试：人工设定程序的输入和预期的正确输出，执行程序，并判断实际输出是否符合预期，如果不符合预期，自动报告错误。这里所说

13、的人工 ，仅指测试用例的输入和预期输出是人工设定的，其他工作可以由人工完成，也可以借助工具自动完成。人工动态测试可以发现有特征错误和无特征错误，例如，前面所说的加法函数，只要人工建立一个测试用例，输入两个 1，并判断输出是否等于 2，运行测试，就可以发现代码中含有错误。 测试能否彻底？ 理想的彻底与理论的彻底 等价划分的通常途径 正常输入，边界输入，非法输入 彻底的“三步法” 人工设计测试用例进行基本功能测试 统计白盒覆盖率，针对不足设计用例 实现 100%语句、条件、分支、路径覆盖 自动生成大量的测试用例，捕捉程序员未处理某些特殊输入 形成的错误 实战单元测试JUnitJUnit 是由 Er

14、ich Gamma 和 Kent Beck 编写的一个回归测试框架（regression testing framework） 。 JUnit 报告JUnit 应用评价 优点： 优秀的单元测试框架 成熟的辅助工具支撑 成熟的开发方法论体系 不足： 依赖性 测试数据“硬编码”JTestcase JTestCase 使用 XML 文件来组织多测试案例数据，声明条件（操作和期望的结果） ，提供了一套易于使用的方法来检索 XML 中的测试案例，按照数据文件的定义来声明结果 JetifJetif 是一个用纯 Java 实现的回归测试框架。它为 Java 程序单元测试以及功能测试提供了一个简单而且可 伸缩

15、的架构，可以用于个人开发或企业级开发的测试。它容易使用，功能强大，而且拥有一些企业级测试的 重要功能。 演示参考资料 JUnit In Action JUnit Recipes回顾 单元测试概述 实战单元测试 JUnit JTestcase + JUnit Jetif持续集成持续集成持续集成部署持续集成周期持续集成的益处 能最小化集成风险 能减小产品低质量的风险 能简单化错误诊断 能极大鼓舞项目组的士气 No more “But it works on my machine!”1、能最小化集成风险 项目组可能遇到的一个很大的风险是，项目组成员根据不同的系统功能各自开发不同的代码，但是当这些代码集成为一个系统的时候，也许系统完成不了预期的功能。这种风险的发生取决于项目中的这种不兼容性多久才被发现，由于程序界面已经发生了变化，或者系统的主要部分已经被重新设计和重新实现了，相应的排错工作将非常困难和耗时。极端情况下，集成的错误可能回导致项目被取消掉。每日构造和冒烟测试可以使这种集成错误变得非常小，而且便于解决，防止了很多集成问题的产生。2、能减小产品低质量的风险 这种风险是和集成不成功、集成出错相关联的。每天对集成的代码做一些少量的冒烟测试，即可杜绝项目中那些基本的质量问题