软件测试的流程

软件测试的各个阶段 测试过程

PDCA戴明循环

检查需求

确定测试需求

测试需求的依据与收集 测试需求的分析 形成测试需求分析 测试需求的优先级

测试需求的覆盖率和覆盖程度 软件测试流程（需求阶段）

l需求分析阶段测试人员需要做哪些工作？ 参与需求调研

测试计划定义 l定义

ü《ANSI/IEEE软件测试文档标准829-1983》将测试计划定义为：¡°一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。¡± l注意：

ü重要的是计划过程，而不是产生的文档。

ü在工作过程中，如果无法按照自己预定的进度完成，也不要害怕或者沮丧，进度的作用就像一把尺子，而不是鞭子。你在工作中不断的用这把尺子来衡量自己，那些地方需要调整。 ü测试计划由谁来写？ ü测试计划根据什么写？

撰写测试计划

l重要的是计划过程，而不是产生的文档。

l你在工作中不断来衡量测试工作中的哪些地方需要调整。 l测试计划的内部作用

ü作为测试计划的结果，让相关人员人员来评审

ü存储计划执行的细节，让测试人员来进行同行评审 ü存储计划进度表、测试环境等更多的信息。 l测试计划的外部作用 ü为客户提供一种信心

ü向客户提供有关测试过程、人员的技能、资源、使用工具等信息。

经典面试问题

l测试计划的内容？ 答：

一个计划包括： 1）需要做什么 2）怎么去做

3）需要花费多长时间

4）需要的资源（人力、测试环境和工具） 5）成本

6）如果不能完成计划会造成的影响 7）测试的优先级

8）每一部分的测试由谁来负责 经典面试问题

9) 计划中每一部分相互之间联系的风险 10）关键的检查点数据

11）测试的入口和退出的标准

12）对测试过程的主要执行者和贡献者 13）如果项目能提前完成将有的潜在利益

测试计划要尽早开始。可以在需求定义过程开始时就开始测试计划。

测试计划的目的

l测试计划的目的是处理以下重要的问题： ü 测试策略 ü 资源利用 ü 风险 ü 优先级 风险评估

l一个测试计划成功的关键的一点就是去识别和评估项目风险。

l风险就是那些会出错从而影响项目造价和进程的概率。在测试中，风险既包括那些项目的失败的可能性也包括由失败造成的影响。它具有不确定性和代价巨大的特征。

l风险评估就是估计项目障碍发生的可能性和潜在影响。在一个风险分析活动中，对于一个项目管理者来说，就是通过输入或是输出提高风险鉴别能力。

风险评估

l风险有很多种形式，以下是两种主要的分类：

ü应用软件程序不能满足最终用户的期望（说明的或是未说明的）；

ü应用软件程序不能按时（可以是合同约定的时间也可以是市场上投资后得不到预期回报）交给客户。

不能管理的风险能导致很多问题，包括： ü增加测试成本 ü测试周期延长 ü服务停止

ü矫正维护费用过多 测试策略

l当需求和项目的风险被充分理解后， 测试计划的下一步是确定测试策略。

测试策略回答了以下问题： ü我们为什么测试？

ü我们计划做什么以及不做什么？ ü我们将如何做测试？ 测试计划注意事项

l增强测试计划的实用性

ü计划是作为动词而不是名词使用的，或者应该叫做¡°计划测试¡±更恰当一些，重点在于对整个测试项目工作的计划

ü而《测试计划》只是用来记录最终结果的那份文档而已。再说得明确一点，是¡°计划测试工作¡±，而不是¡°编制测试计划¡±。 ü一切从实际出发，千万不要流于形式！ l坚持“5W1H”规则，明确内容与过程

üWHAT、WHY、WHEN、WHERE、WHO、HOW

测试计划注意事项 测试计划注意事项

l分别创建测试计划与测试策略

ü编写软件测试计划要避免一种不良倾向是测试计划的¡°大而全¡±，长篇大论，重点不突出。

测试计划案例

l案例：中国证券业2000年问题第二次测试计划 ü上海证券交易所.深圳证券交易所 l参加单位

ü沪深证券交易所与证券结算公司 ü沪深证券卫星通信公司

ü所有会员公司至少两家营业部参测，其中至少一家是不发达地区（深、沪、省会城市和计划单列市以外），各会员公司按表（一）填写，务必于11月26日前将参测营业部名单（即填写后续表一）用电子邮件报至两证券交易所 测试计划的内容 l1.简介 ü 1.1目的 ü 1.2背景 ü 1.3范围

l2.测试参考文档和提交文档 ü 2.1测试参考文档 ü 2.2测试提交文档 l3.术语和定义 l4.测试策略 ü 4.1测试策略 ü 4.2测试工具

简介—目的（Why） l1.1目的

ü做事方法:确认目标¡ª做什么¡ª怎么做

l可包含：

ü撰写软件测试计划的目的？--明确目标和方法，便于团队交流 ü通过测试希望达到的目标？--功能，性能，界面 简介—背景和范围（What） l1.2 背景

ü测什么产品（参考需求说明书） •产品规格

n产品名称、制造商和产品版本号的说明 •产品信息

n产品的用户、开发该产品的背景 •技术结构

n介绍产品的主要功能，可以借助图表的格式表述 l1.3 范围

ü测试流程的各个阶段要测什么

ü分别简要列出要测试和不进行测试的性能指标和功能点 测试计划的内容 l1.简介 ü 1.1目的 ü 1.2背景 ü 1.3范围

l2.测试参考文档和提交文档 ü 2.1测试参考文档 ü 2.2测试提交文档 l3.术语和定义 l4.测试策略 ü 4.1测试策略 ü 4.2测试工具 2测试参考文档 l2.1测试参考文档

测试计划中引用的文档或书籍

2测试参考文档 l2.2测试提交文档 测试计划的内容 l1.简介 ü 1.1目的 ü 1.2背景 ü 1.3范围

l2.测试参考文档和提交文档 ü 2.1测试参考文档 ü 2.2测试提交文档 l3.术语和定义 l4.测试策略 ü 4.1测试策略

ü 4.2测试工具 测试计划的内容

l3术语定义（可选）

ü定义了开发产品或测试过程中常用术语的含义，开发和测试人员常常因为对一个术语的理解不同产生争议

l4.1测试策略（How）

ü测试策略描述测试小组用于测试整体和每个阶段的方法。

ü确定测试策略要从模块、功能、整体、系统、版本、压力、性能、配置和安装等各个方面来考虑

4测试策略—测试工具 l4.2测试工具

ü此项目将使用以下工具：

测试计划的内容 l1.简介 ü 1.1目的 ü 1.2背景 ü 1.3范围

l2.测试参考文档和提交文档 ü 2.1测试参考文档 ü 2.2测试提交文档 l3.术语和定义 l4.测试策略 ü 4.1测试策略 ü 4.2测试工具 测试计划的内容

l5确定测试内容(What) ü功能的测试

•理论上测试要覆盖所有的功能项 ü整体考虑

•要考虑到数据流从软件中的一个模块流到另一个模块的过程中的正确性 确定测试内容 资源

l人力资源

ü这里的人力资源包括测试人员，开发人员，项目负责人，客户代表所有与项目有关的人员，即项目接口人 资源

l系统资源(Where)

ü需要使用的软件在哪里可以下载，测试工具放在哪里？ ü需要的硬件怎么解决？ ü文档在哪里？ 测试计划的内容

l7.测试进度（When）

ü各测试阶段资源要求及时间安排

ü项目里程碑

l可以参考一下项目经理的项目开发进度

ü可以使用相对日期：比如XXX工作开始于XXX部门XXXX工作的结束并提交XXXX ü也可以加注总的测试工作量预期，用¡°人/月¡±、¡°人/日¡±等描述。 7.测试进度

测试计划的内容

l8.测试人员的任务分配 l9.风险和问题

设计阶段的测试 测试设计

分析测试要素 对设计进行评审 l选择评审组成员 l对评审组进行培训 l通报项目组

l分配足够的时间

l只对文档化的事实进行评审 l和项目组一起进行评审 l对评审形成建议

l和项目组对建议一起进行评审 l准备正式的报告

测试的执行

测试执行中的主要工作 测试用例的合理选择 BVT测试与冒烟测试

测试的记录与跟踪 bug的定义

lbug：在软件使用过程中所出现的问题，或者导致软件不能符合设计要求或满足消费者需求的问题

ü未实现产品说明书要求能更改的功能

ü软件出现了产品说明书指明不应该出现的错误 ü软件实现了产品说明书未提到的功能

ü软件未实现产品说明书虽未明确提及但应该实现的目标

ü软件难以理解、不易使用、运行缓慢或者最终用户认为不好用

l简单地说，bug就是软件做了没有期望它去做的事（或者相反，软件没有做到所期望它去做的事） bug的识别

l有些问题看似错误但不是缺陷

l有些问题看似正确但却是缺陷

l同一现象的既可能是bug，也可能不是 看似错误但不是错误 看似正确但却是错误

l安装某个软件成功，但它破坏了操作系统的功能或其他软件。

l软件卸载过程中没有完全卸掉它的组件，有些会降低系统运行的效率，有些会导致升级版本无法安装。

l软件需要支持大多数的硬件配置，例如迪斯尼狮子王游戏的教训，虽然软件本身没有错误，但是却影响了多数用户的使用。

同一现象的2种可能

l同一种现象在不同的环境和系统中，可能是缺陷也可能不是

l在性能和精度等方面的要求上，民用产品与军用产品有很大的区别 l在系统易用性方面，普通用户与专业用户对产品的要求存在很大的差异 bug与“软件缺陷”的关系

l“软件缺陷”是一个软件系统中的需求、体系结构、设计和应用上的错误。而“bug”是软件缺陷的实际证明。

l软件缺陷有可能成为bug，但并非所有的软件缺陷都产生bug。 判断bug的方法 *bug的分类

Bug的严重程度和优先级 Bug的严重程度和优先级

l严重程度高优先级不一定高：

ü如果某个严重的软件缺陷只在非常极端的条件下产生，则没有必要马上解决。

ü如果修正一个软件缺陷，需要重新修改软件的整体架构，可能会产生更多潜在的缺陷，而且软件由于市场的压力必须尽快发布，此时即使缺陷的严重性很高，是否需要修正，需要全盘考虑。

l严重程度低优先级不一定低：

ü如果是软件名称或公司名称的拼写错误，则必须尽快修正，因为这关系到软件和公司的市场形象。 bug的识别 再现bug

怎样有效记录bug

lBUG报告—项目组就正在测试中的软件质量问题的一种书面沟通方式 l读者：

ü开发人员（关注重现步骤）、

ü项目管理者（关注概述和严重程度）、

ü后续版本的测试人员（关注问题集中的模块和测试方法）

ü运行维护人员（关注用户使用中系统是否出现遗留问题、系统薄弱模块等） 怎样有效记录bug

l保证重现bug(Reproduce )

l分析故障——使用最少步骤复现故障

l包含所有重现bug的必要步骤 l方便阅读

l尽量简单——一个bug一个报告 l注意自己的语气 l值得注意的经验 怎样有效记录bug

l保证重现bug(Reproduce )

ü对于严重程度较高的bug，一般要重复测试2次以上 ü对于随机产生的bug，要在其他机器上测试一下 ü不可重现的bug也要报告

ü详细记录出现bug的测试点的测试步骤及相关截图、日志、开发人员定位信息等，尤其对于暂时不能复现的问题。

缺陷报告几个关键点

l一位IBM前辈总结的缺陷报告几个关键点：猪能骑 lCan pig ride

ü Condense－精简，清晰而简短

ü Accurate－准确，这到底是不是一个bug？还是用户操作错误，或者是理解错了，等等？ ü Neutralize－用中性的语言描述事实，不带偏见，不用幽默或者情绪化的语言。 ü Precise－精确，这到底是什么问题？

ü Isolate－定位，这到底是个什么样的问题？尽量缩小这个问题的范围。 缺陷报告几个关键点

ü Generalize－还有没有其他的某些地方存在这样的问题？

ü Re-Create－如何引发和重现这个bug？（环境，步骤，前提条件） ü Impact－影响，这个缺陷对客户有何影响？对测试有什么影响？

ü Debug－怎么做才可以让开发更容易来修改这个bug？（跟踪，截图，日志，直接访问等等）

ü Evidence－证据，如何证明确实存在这个bug？ 问题单模板举例 怎样有效记录缺陷

l包含所有重现缺陷的必要步骤

怎样有效记录缺陷 l方便阅读

站在开发人员的角度考虑问题

ü1.概述（Summary ） ：简洁、准确，完整，揭示错误实质

ü2.步骤（Steps ）：完整，准确，简短，保证快速准确的重复错误， •“完整”即没有缺漏，“准确”即

•步骤正确，“简短”即没有多余的步骤。

ü3.尽量使用业界惯用的表达术语和表达方法（term） ü4.检查拼写和语法错误

怎样有效记录缺陷

l尽量简单——一个缺陷一个报告 ü便于分配问题

ü便于回归测试，关闭bug

怎样有效记录缺陷 l注意自己的语气

l换位思考,保持中立（Neutralize ）

ü要站在客观中立的立场上，不能参杂主观感情 ü例如：

ü¡°这个问题在上一个版本中已经修复了，怎么这次又出现了呢？¡± ü¡°这个错误太低级了！¡± ü¡°我觉得这样不行！¡±

怎样有效记录缺陷 l值得注意的经验

1） 报告不能重现的缺陷 2） 不能夸大缺陷

3） 小缺陷（甚至建议）也要报告

4) 引用别人的报告时，不能修改，可以添加批注之类的补充评论 5）概述最好用陈述句，不超过15个字

缺陷报告案例分析 缺陷报告案例分析 缺陷报告案例分析 bug的生命周期

lNew:新发现的bug，未经过评审决定是否派给开发人员进行修改

lOpen：确认是bug，并且认为需要进行修改，指派给相应的开发人员修改 lFixed：开发人员进行修改后标识成修改状态，待测试人员验证确认

bug的生命周期

lRejected：如果认为不是bug，则拒绝修改

lDelay：如果认为暂时不需要修改或暂时不能修改，则延后修改。 lClosed：修改状态的bug经过测试人员的测试验证通过

lReopen：经过验证bug仍然存在，则需要重新打开bug，开发人员重新修改

跟踪一个bug的生命周期 跟踪一个bug的生命周期

lNew:新发现的bug，未经过评审决定是否派给开发人员进行修改

lOpen：确认是bug，并且认为需要进行修改，指派给相应的开发人员修改 lFixed：开发人员进行修改后标识成修改状态，待测试人员验证确认 lRejected：如果认为不是bug，则拒绝修改

lDelay：如果认为暂时不需要修改或暂时不能修改，则延后修改。 lClosed：修改状态的bug经过测试人员的测试验证通过

lReopen：经过验证bug仍然存在，则需要重新打开bug，开发人员重新修改 Bug评审应该注意的问题

回归测试

回归测试的过程 回归测试的策略

测试报告

测试报告的编写 测试报告的编写 测试报告的编写 测试报告的编写

软件质量评估

l覆盖---专注于过程 ü需求覆盖 ü代码覆盖

l质量---专注于结果 ü缺陷报告 ü性能评测 软件测试评估

l软件测试评估，也就是测试总结，是软件测试生命周期的最后一个环节。 l测试评估主要分为两种：对覆盖（过程）的评估和对缺陷（结果）的评测。 l两种覆盖：对源代码的覆盖和对需求的覆盖。

l对源代码的覆盖：

ü指的是在单元测试过程中所测试到的源代码占代码总数的百分比，一般有语句覆盖、分支覆盖、条件覆盖、路径覆盖等。

ü一个通用的标准是：关键模块的语句覆盖率为100%，分支达到85%以上。 l对需求的覆盖

ü指的是在测试过程中，所测试到的功能和非功能需求占到需求总数的百分比。 ü一个通用标准是：

•TESTcase的执行率为100% •Testcase的通过率为95%以上

覆盖评测算法

lRFT: requirement for test 测试需求总数

lTx：测试过程或测试用例表示的已执行的测试数。

lTs：是用完全成功、没有缺陷的测试过程或测试用例表示的已执行的测试数

lTc：用代码语句、代码分支、代码路径、数据状态判定点或数据元素名表示已执行的项目数

lTiic：total number of item in the code 代码中的项目总数

l覆盖评测

ü基于需求的测试覆盖 ---用例覆盖率 ü 测试覆盖（已执行的）＝Tx/RfT

ü 成功的测试覆盖（已执行的）＝Ts/RfT ü基于代码的测试覆盖（利用工具）--代码覆盖率 ü 测试覆盖＝Tc/Tiic 质量评测

缺陷统计—表格 缺陷统计—图表 性能评测 其他图表

性能评测--百分位报告

l以身高为例：第5百分位的尺寸表示有5％的人身高等于或小于这个尺寸。换句话说就是有95％的人身高高于这个尺寸。第50百分位为中点，表示把一组数平分成两组，较大的50％，较小的50％。第50百分位的数值可以说接均值，但决不能说它就是平均身高。 测试总结报告 l测试总结

ü测试总结的作用

ü 总结测试活动的结果，并进行评测；在测试的各个阶段完成后，我们都可以提供测试总结报告，总结上一阶段测试中产品存在的缺陷，决定是否可以进入下一阶段的测试 ü测试总结的模板 l测试总结案例分析