软件测试培训

1. 软件测试培训 贺炘 hcat@163.net

2. 培训列表 • 软件测试的目的和策略 • 测试方法学 • 测试的技巧 • 测试工具的选择 • 软件开发中的测试过程 • 实例讲解测试活动在软件工程中的应用

3. 软件测试的目的和策略

4. 典型测试步骤 1.计划： 定义目标 确定策略 确定方法 2.执行： 建立环境 执行计划 3.检查： 一步步验证 执行完毕？ 4.循环： 没有改正 继续执行

5. 谁参与测试？ • 用户方代表 • 软件最终使用者 • 软件开发人员 • 软件测试人员 • 高层经理的支持 • 过程保证人员（SQA）

6. 什么试缺陷？ • 缺陷：最终产品同用户的期望不一致 • 缺陷的分类 • 错误 • 遗漏 • 超出需求的部分 • 缺陷（未触发）VS.错误（应首先解决）

7. 测试的商业意义 • 降低风险（风险：就是不希望发生的事情的可能性） • 测试计划中必须标明商业上的风险。 • 测试人员职责： • 评估商业上的风险 • 如实的向管理层汇报项目情况

8. 目前公司内测试组织的等级 • 测试是一件艺术品，很难掌握。 • 测试是一门手艺，精通很困难。 • 测试使用的是已定义好的测试流程，有规则可寻。 • 测试有较高级的组织形式。 • 世界级的测试组织。

9. 测试的职责 • 验证在整个软件开发周期中，各个阶段的软件质量是否合格。 • 验证最终交付给用户的系统是否满足用户的需要，是否符合需求。 • 通过样本测试数据，检查系统在运行过程中的情况。

10. 对待可能产生的风险的策略 • 我们无法消除风险，但是我们可以降低在风险发生时的损失。 • 降低系统风险的最有效的办法就是对其进行有针对性的测试。

11. 系统风险列举 • 如果某部分产生了错误会导致的结果？ • 未被验证的数据交换如果被接受 • 如果文件的完整性被破坏 • 系统是否能被安全恢复（完全恢复成备份时的状态） • 是否能暂停系统的运行 • 进行维护工作时，系统性能是否会下降到不能接受的水平。 • 系统的安全性是否有保证

12. 系统风险列举（继续……） • 系统的操作流程是否符合用户的组织策略和长远规划 • 系统是否可靠，稳定 • 系统是否易于使用 • 系统是否便于维护 • 是否易于与其它系统相连

13. 测试工作量 • 太少的测试是不负责任，过多的测试是一种犯罪。 • 100％的测试是不可能的，不同的用户采用的测试策略是不同的。

14. 缺陷产生的原因 • 测试原因导致的缺陷： • 测试目标定义错误 • 在开发生命周期中，错误的选择了测试介入时期 • 选择了低效的测试技术 • 测试人员专业知识培训不够，工作低效 • 计划不够详细，测试的随意性很大 • 测试人员同开发人员沟通困难

15. 续…… • 软件方面 • 使用了不完全的或者不正确的判定标准来设计软件。 • 错误的处理了用户的非法操作 • 忽略了对关键数据的输出检查 • 数据问题 • 出现了不完整的数据，不正确的数据，过期的数据

16. 测试效果的好坏是组织级的问题 • 有效的测试最好由一个独立的团队来实施。 • 便于确定工作目标 • 便于人员的培养与升迁 • 利于团队建设 • 对质量的忠诚度高 • 利于新技术，新方法的产生和推广 • 工作职责明确

17. 测试规划 • 好的测试不是碰巧发生的，而是规划出来的。 • 时间上 • 人员上 • 环境上 • 技术上 • 关系上 • 组织能力上 • 资金上

18. 结构化测试方法 • 传统的软件开发生命周期： • 需求，设计，编码，测试，系统维护 经验： • 测试不应该被局限在单一的阶段 • 大量的系统问题产生在软件开发前期 • 越早进行测试越有效，投入产出比越高

19. 开发生命周期中的验证活动

20. 测试策略 • 在测试策略中必须标明可能存在的风险，这样在测试后的系统中可以有效的降低被标明的风险发生的可能性。 • 测试要素：需要被标明的风险也是我们测试的重点。 • 测试阶段：在整个开发生命周期中，测试工作介入的时期。

21. 测试要素 • 正确性：数据输入，过程处理和输出的正确性（IPO）。 • 文件完整性：文件被正确使用，恢复和存储的数据正确。 • 授权：特殊的授权可以执行一个特殊的操作。 • 进程追踪：当进程运行中，程序有能力证实进程在正常工作。 • 系统运行的连续性：当有非致命性问题发生后，系统有能力继续运行关键的任务。 • 服务水平：系统有紧急情况发生时，要求程序的输出结果不经或进行简单的处理后就可以直接使用。 • 权限控制：防止系统被误用（意外或者有意的）

22. 测试要素(续……) • 一致性：确保最终设计和用户需求完全一致 • 可靠性：在规定的时间内都可以正常运转。 • 易于使用：多数人均感觉易于使用。 • 可维护性：可以很容易的定位问题，并且进行修改。 • 可移植性：数据或者程序易于移至到其它系统上。 • 耦合性：系统中的组件可以很容易的联接。 • 性能：系统资源的占用率，响应时间，并发处理 • 操作性：易于操作（Operator）

23. 确定测试策略 • 选择并确定测试要素的等级 • 多数情况下选择3～7个 • 确定开发阶段 • 明确商业风险 • 开发人员，重要用户和测试人员通过评审的方式对这些风险达成一致的意见。 • 把风险列表存放在需求矩阵中 • 矩阵中可以将风险同测试用例对应起来。

24. 测试方法学

25. 测试方法 • 测试策略 • 测试要素 • 测试阶段 • 测试战略 • 简要描述如何在以后的测试活动中实现测试策略

26. 确定测试战略 • 流水线的概念 • 输入：标准的入口或者是个可执行的程序 • 执行过程：按照工作分配执行 • 检查过程：确定输出符合预定义的标准 • 输出：符合现存的标准或者是认可的可交付的版本

27. QC和QA • 质量控制 • 验证产品的正确性，当发现与设计不一致的时候进行纠正。 • 质量保证 • 充当支持执行全面质量管理的角色

28. 测试涉及的定义和概念 • 缺陷 • 与需求规格说明书不一致的地方。 • 静态检查 • 确保系统按照组织的标准和过程运行，主要依赖于评审和非运行的手段来检查。 • 动态检查 • 在生命周期中进行测试（运行）

29. 续…… • 静态测试 • 在不运行程序的情况下检查程序的运行情况。 • 动态测试 • 运行程序代码 • 测试分类 • 单元测试 • 集成测试（组装测试） • 系统测试 • 验收测试 • 回归测试

30. 续…… • 功能测试 • 测试功能需求 • 结构测试 • 验证系统架构 • 黑盒测试 • 在不了解系统结构的情况下以说明书作为基础进行测试。 • 白盒测试 • 以系统内部结构和相关知识为基础进行测试。

31. 为什么缺陷很难被找出？ • 看不到 • 看到但是抓不到 • 典型的缺陷类型 • 需求解释有错误 • 用户定义错了需求 • 需求记录错误 • 设计说明有误 • 编码说明有误 • 程序代码有误 • 数据输入有误 • 测试错误 • 问题修改不正确 • 正确的结果是由于其它的缺陷产生的

32. 静态测试 • 需求评审 • 设计评审 • 代码走查 • 代码检查

33. 动态测试 • 单元测试 • 集成测试 • 系统测试 • 用户的验收测试 • 回归测试

34. 使用静态和动态测试来进行结构和功能测试

35. 确定测试战术的八个步骤 • 确定并且学习测试策略 • 确定项目开发类型 • 确定软件系统类型 • 确定项目范围 • 鉴别战术风险 • 确定开始测试时会遇到的问题 • 建立系统测试计划 • 建立单元测试计划

36. 确定并学习测试策略 • 在众多的测试策略中那些是重要的 • 那些风险是最重要的 • 如果软件不能正常运行时，商业上会有什么损失 • 如果软件不能及时完成，商业上会有什么损失 • 谁是最清楚风险影响的人

37. 确定项目开发类型 • 传统的系统开发 • 交互式开发/原型法 • 系统维护 • 购买/签约/合同软件项目

38. 确定软件系统类型 模拟 数据采集 数据显示 流程控制 决策&辅助协助 图形&图象处理 数据库管理 诊断软件 计算机操作系统 传感器和信号处理 软件开发工具

39. 确定项目范围 • 新系统的开发 • 会影响那一个商业领域 • 与现有系统的接口 • 在现有的系统上开发 • 只是修正Bug？ • 重新设计维护？ • 增加新的功能？ • 对其它系统有无影响？ • 为了减小商业上的风险？

40. 识别在战术上的风险 • 将策略风险分解成战术风险 • 建立测试计划，定位这些风险 • 将风险分布于各个阶段的测试计划中 • 战术风险的种类 • 结构风险 • 技术风险 • 工作量的风险

41. 测试开始时应确定的工作 • 需求阶段 • 确定测试策略 • 确定收集了足够的需求 • 产生功能性的测试用例 • 设计阶段 • 确定设计和需求之间的联系 • 确定进行了足够的设计 • 产生结构和功能的测试用例 • 编码阶段 • 确定和设计之间的联系 • 确定拥有执行的足够条件 • 产生结构和功能的测试用例

42. 续…… • 测试阶段 • 确定设计了足够的测试用例 • 测试应用系统已经完成 • 关键资源已经到位 • 安装阶段 • 将测试完成的系统变为产品 • 维护阶段 • 修改和重新测试

43. 建立计划 • 建立系统测试计划 • 建立单元测试计划 • 在测试战术上我们要花多长时间？ • “如果计划作失败了，那就在计划失败” • 时间花在计划上要比花在重复的测试上有效

44. 测试的技巧

45. 测试技巧分类 • 结构测试相对于功能测试 • 动态测试相对于静态测试 • 手工测试相对于自动测试

46. 结构测试技巧 • 压力测试 • 执行测试 • 恢复测试 • 操作测试 • 复合性测试（与过程的复合性) • 安全测试

47. 压力测试 • 目标 • 模拟出实际用户环境 • 怎么用 • 产生测试数据 • 测试组模拟用户处理被创建的数据 • 例子 • 确定是否分配了足够的磁盘空间 • 通讯的容量是否足够 • 测试系统过载的情况 • 什么时间使用 • 当关于容量的信息不确定的时候

48. 性能测试技巧 • 目标 • 确定系统达到了希望达到的性能水平 • 如何使用 • 使用软件和硬件的监视器 • 使用模拟的监控模型，对关心的性能指标进行监控 • 创建一个小程序 • 例子 • 计算通信的时间 • 单位时间处理的信息量 • 什么时候使用 － 在程序开发的早期进行

49. 恢复测试 • 目标 • 当在进行安装或组装操作过程中，文件丢失时或发生意外后系统有能力重新进行操作 • 如何使用 • 程序的安装，运行方式，工具的使用和关键技术经过足够的评估 • 系统开发完毕后，介绍一下发生失败后的处理过程 • 例子 • 人为的使一个系统在安装或者组装过程中产生错误 • 什么时间去使用 • 当操作的连续性是个重点的时候

50. 操作测试 • 目标 • 确定计算机的操作文档已经完整 • 如何使用 • 作为计算机正常操作的一部分来执行测试 • 例子 • 操作的介绍被文档化，操作者被培训 • 什么时候使用 • 预先将程序进行产品化。操作性是系统的一个重要指标的时候。