测试总结

• 1. 测试用例
• • 1.1 测试用例前提
  • 1.2 测试用例定义
  • 1.3 目的和意义
  • 1.4 测试分类
  • 1.5 测试原则
  • 1.6 测试策略
  • 1.7 测试用例编写模板
• 2. 缺陷管理
• • 2.1 缺陷的定义
  • 2.2 缺陷的状态
  • 2.3 缺陷的生命周期
  • 2.4 缺陷的优先级
  • 2.5 缺陷的严重程度
  • 2.6 缺陷的类型
  • 2.7 缺陷（bug）不修复的原因
  • 2.8 缺陷（bug）管理工具
• 3. 测试流程
• • 3.1 瀑布模型
  • 3.2 V 模型
  • 3.3 W 模型
  • 3.4 H 模型
  • 3.5 敏捷开发模型
• 4. 测试方法
• • 4.1 黑盒测试
  • • 4.1.1等价类划分
    • 4.1.2 边界值分析法
    • 4.1.3 因果图法
    • 4.1.4 决策表法
    • 4.1.5 错误推测法
  • 4.2 白盒测试法
  • • 4.2.1 白盒测试各方法

1. 测试用例

1.1 测试用例前提

• 什么是测试用例strong>
  一组由前提条件、测试输入、执行条件以及预期结果等组成，以完成对某个特定需求或者目标测试的数据，体现测试方案、方法、技术和策略的文档。
• 为什么编写测试用例
  （1）深入了解需求的过程：一个项目立项开始，测试就开始介入，我们从产品的需求文档、原型图，效果图等相关文档去熟悉产品的各个模块，各个业务流程。或者在产品规划和设计阶段，测试开始熟悉产品。而编写用例的过程中，会充分的思考产品需求的细枝末节，需求的不合理、有矛盾、不明确的地方，还能对产品提出更好的建议，监督产品对需求做出更加详细的设计。整个过程是对需求深入了解的过程，产品的整个印象都在测试脑海里。
  （2）测试执行的指导：用例编写是把产品需求转换为一种可操作步骤的行为，方便以后作为测试的标准，有步骤有计划的进行测试。如果没有这个标准，会使你的测试过程无计划，无目标，变成一个放任主流的状态，完全没有受控性。这样的产品质量保证显然是空谈。
  （3）规划测试数据的准备：在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其象测试 表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。
  （4）反应测试进度：测试人员开始按照测试用例的描述测试，每过完一个用例标记完成；这样测试也知道自己做过哪些操作，避免没有目的随机测试。并且通过测试用例的执行条数，大致了解该模块的测试进度。
  （5）举一反三发现潜藏缺陷：测试人员开始按照测试用例的描述测试，每过完一个用例标记完成；这样测试也知道自己做过哪些操作，避免没有目的随机测试。并且通过测试用例的执行条数，大致了解该模块的测试进度。
  （5）分析缺陷的标准*：通过收集缺陷，对比测试用例和缺陷数据库，分析确认是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。

1.2 测试用例定义

• IEEE 标准的定义:使用人工或自动的手段来运行或测定某个系统的过程，其目的在于检验;它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。
• G.J.Myers给出的定义:“程序测试是为了发现错误而执行程序的过程”。这个定义被软件测试业界所认可，并经常被引用。

1.3 目的和意义

（1）测试是完善程序的过程，目的在于使系统更加符合用户的使用习惯，让系统在上线后带给客户极高的用户体验；
（2）测试应致力于发现至今为止未发现的错误
（3）以最少的时间和人力，系统地找出软件中潜在的各种错误和缺陷；
（4）证明软件的功能和性能与需求说明项符合；
（5）通过测试的结果数据为软件的可靠性分析提供分析

1.4 测试分类

1.5 测试原则

• 所有软件测试都应追溯到用户需求。
• 应当把“尽早地和不断地进行软件测试”作为软件测试人员的座右铭。
• 完全测试是不可能的，测试需要终止，原因数据输入量太对、路径组合太多、输出结果太多。
• 程序员应避免检查自己的程序，测试无法显示软件潜在的缺陷，进行测试以查找缺陷，但不能保证所有的缺陷都被找到。
• 充分注意测试中的群集现象，在所测程序中，若发现错误数目多，则残存误数目也比较多，这种就是错误集群现象。
• 软件测试是有计划的，严格执行测试计划，排除测试的随意性。
• 应当对每一个测试结果做全面检查，妥善保存测试计划，测试用例，缺陷统计和最终测试分析 告，为维护提供方便。

1.6 测试策略

• 测试阶段：单元测试、集成测试、系统测试、回归测试
• 测试范围：单元测试中的测试模块实现基本的逻辑功能，没有重大逻辑错误；集成测试接口实现联调完成，接口数据流是通的；系统测试完成功能点的测试，功能是否满足需求；回归测试在漏洞修复完成是否产生其他新问题，功能需要重新覆盖完成。
• 测试方法：使用自动化测试还是手动测试，是否考虑性能或兼容性测试等
• 测试环境：环境解决方案、操作系统、软硬件
• 完成标准：需求文档上的功能是否完全实现，漏洞是否完全修复等
• 测试重点和优先级：按照系统中模块的重要性定优先级
• 络环境：需要考虑弱 测试
• 风险管理：项目存在风险时，测试在控制质量和时间需要把控。

1.7 测试用例编写模板

2.4 缺陷的优先级

• 立即解决(Resolve immediately)：缺陷导致系统几乎不能使用或者测试不能继续。——P1
• 高优先级（high?priority)：缺陷严重，影响测试，需要优先考虑；软件未达到产品说明书虽未指出但应达到的目标。——P2
• 正常排队(Normal?Priority)?：缺陷需要正常排队等待修复。——P3
• 低优先级(Low?priority)?：缺陷可以再开发人员有时间的时候被纠正。——P4

2.5 缺陷的严重程度

• 致命性（Fatal）：阻碍流程、系统崩溃导致重大任务不能正常进行的缺陷，比如数据库死锁、死机、非法退出、严重计算错误等
• 严重（Critical）：系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失;如开发人员修复后的状态。系统响应时间过长、核心功能缺失等
• 一般(minor)：操作性错误、错误结果、遗漏功能等影响系统要求或基本功能的实现；比如界面错误、打印内容格式错误、数据输入没有边界值等。
• 轻微（Slight）：操作性错误、错误结果、遗漏功能等影响系统要求或基本功能的实现，界面设计存在缺陷、提示不正确、整体风格不一致
• 建议性：不影响使用的瑕疵或更好的实现等对软件各方面提出的更好的改进性的意见。

2.6 缺陷的类型

• 功能缺陷
• 性能缺陷
• 兼容性缺陷
• 安全性缺陷
• 易用性缺陷
• 用户界面缺陷
• 设计文档缺陷
• 安装/卸载缺陷等等

2.7 缺陷（bug）不修复的原因

• 时间：没有足够的时间. (Postpone)
• 需求：不是我们产品的问题 (External)
• 重复：已经有一个同样的Bug了(Duplicated)
• 风险：修复这个bug会带来更大的风险. (Won’t fix)
• 代价：不值得花费大量的时间去修复小bug (Won’t fix)
• 环境：在我环境上是好的，不能重现你的bug. (Not Repro)
• 设计：这不是一个bug, 这是一个设计. (Not Repro, By Design)

2.8 缺陷（bug）管理工具

• Bugzilla
• 禅道
• Jira

3. 测试流程

3.1 瀑布模型

优点：在V模型里，强调软件开发的协作和速度，反应测试活动和分析测试的关系，并且将软件的实现和验证有机的结合了起来，V模型，明确的界定测试过程是存在不同阶段的。
缺点：但是V模型也有一定的局限性,它仅仅把测试过程放在需求分析、系统设计、编码之后的一个阶段，忽视了测试对于需求的分析和验证。我们对需求的验证，对系统设计的验证，到后期的验收测试才有可能被发现，对于我们测试当中的测试需要尽早进行的原则在V模型中没有体现，这是V模型的局限。

3.3 W 模型

3.5 敏捷开发模型

4.1.4 决策表法

定义：是把作为条件的所有输入的各种组合值以及对应输出值都罗列出而形成的表格。
例：参考4.1.3因果图例

4.1.5 错误推测法

（1）定义：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。
（2）基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。例如：

• 在单元测试时曾列出的许多在模块中常见的错误、以前产品测试中曾经发现的错误等，这些就是经验的总结。
• 输入数据和输出数据为0的情况、输入表格为空格或输入表格只有一行等。这些都是容易发生错误的情况，可选择这些情况下的例子作为测试用例。

4.2 白盒测试法

定义：白盒测试也称结构测试或逻辑驱动测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例。

目的：

• 保证一个模块中的所有独立路径至少被执行一次；
• 对所有的逻辑值均需要测试真、假两个分支；
• 在上下边界及可操作范围内运行所有循环；
• 检查内部数据结构以确保其有效性。

覆盖标准：白盒法考虑的是测试用例对程序内部逻辑的覆盖程度。最彻底的白盒法是覆盖程序中的每一条路径，但是由于程序中一般含有循环，所以路径的数目极大，要执行每一条路径是不可能的，只能希望覆盖的程度尽可能高些。

4.2.1 白盒测试各方法

在逻辑覆盖测试中，按照覆盖策略由弱到强的严格程度：
（1）语句覆盖：每个语句至少执行一次。
（2）判定覆盖：在语句覆盖的基础上，每个判定的每个分支至少执行一次。
（3）条件覆盖：在语句覆盖的基础上，使每个判定表达式的每个条件都取到各种可能的结果。
（4）判定/条件覆盖：即判定覆盖和条件覆盖的交集。
（5）条件组合覆盖：每个判定表达式中条件的各种可能组合都至少出现一次。
（6）路径覆盖：每条可能的路径都至少执行一次，若图中有环，则每个环至少经过一次