如何看待软件测试在保证产品质量中所起的作用？

1. 软件测试基础（P1-3）

测试基础知识的学习目标

本章的学习目标：完成下面模块(module)的学习后，将明确能做什么。

1.1测试的必要性

通过具体的例子，来描述软件中的缺陷(defect)会以什么样的方式损害个人、损害环境或者损害公司利益。

区分引起缺陷的根本原因及其影响之间的区别。

通过举例的方式说明为什么需要测试。

描述为什么测试是质量保证(quality assurance)的一部分，通过举例说明测试是如何来提高软件质量的。

理解术语错误(mistake)、缺陷、失效(failure)以及相应的术语错误(error)和bug之间的区别。

1.2 什么是测试 (K2)

认识测试的共同目标。

描述测试作为发现缺陷的一种手段，测试在软件开发、维护和运行中的目的，同时通过测试，可以增强对被测软件的信心并获得一些相关的信息，从而用来预防缺陷。

1.3 测试的基本原则

说明测试的基本原则。

1.4 基本的测试过程

再次认识从计划到测试结束过程中测试的基本活动，以及在每个活动中的主要任务（K1）。

1.5 测试的心理学

认识测试的成功与否，会受测试心理因素的影响：

清楚的目标；

自己测试和独立测试之间的平衡；

认识到谦恭的沟通和缺陷反馈在测试中的作用。

对比测试员(tester)和开发员(developer)的心理差异。

1.1 为什么需要测试 （P4-5）

术语

缺陷(bug)、缺陷(defect)、错误(error)、失效(failure)、故障（fault）、错误(mistake)、质量（quality）、风险(risk)、软件(software)、测试(testing)。

1.1.1 软件系统的状况

在当今社会，软件系统(system)越来越成为生活中不可或缺的一部分，包括从商业应用（比如银行系统）到消费产品（比如汽车）各个领域。然而，很多人都有这样的经历：软件并没有按照预期进行工作。软件的不正确执行可能会导致许多问题，包括经济的损失、时间的浪费和商业信誉的丢失等等，甚至导致人身伤害和死亡。

1.1.2 引起软件缺陷的原因

所有的人都会犯错误。该错误error会成为设计的代码、软件、系统和文档中的缺陷。当存在缺陷的代码被执行时，系统就可能无法执行期望的指令（或者做了不应该执行的指令），从而引起软件失效（故障）。虽然软件、系统和文档中的缺陷可能会引起失效，但并不是所有的缺陷都会这样。

产生缺陷的原因是多种多样的：人们本身容易犯错误、时间的压力、复杂的代码、复杂的系统架构、技术的革新、或者系统之间的配合工作等。

失效也可能是由于环境条件引起的：放射、电磁辐射和污染等都有可能引起硬件的故障，或者由于硬件条件的改变而影响软件的执行。

※ error（错误） → 缺陷（fault，bug） → 故障

1.1.3 在软件开发、维护和运行中测试的角色

对软件系统和文档进行严格的测试,可以减少软件系统在运行环境中的风险，假如在软件正式发布之前发现和修正了缺陷，就可以提高软件系统的质量。

进行软件测试也可能是为了满足合同和法律法规的需求，或者是为了满足行业标准。

1.1.4 测试和质量

通过测试，根据发现的缺陷，就可能发现软件系统在功能(functional)和非功能(non-functional)需求方面的缺陷，对软件质量(software quality)进行评判。飞功能需求包括：可靠性(reliability)、可用性(usability）、效率(efficiency)和可维护性(maintainability)等方面，关于非功能测试方面的更多信息，可以参考第二章。更多关于软件特征的信息，可以参考[ Software Engineering - Software Product Quality (ISO9126) ]。※ISO9126对应与国内规格：JIS-X0129。

当测试发现很少或者没有发现缺陷的时候，就会对软件的质量充满信心。一个设计正确、合理的测试过程完成并顺利通过，可以降低整个系统存在问题的风险。而对测试过程中发现的缺陷进行了修正，则软件系统的质量就会提高。

我们应该从以前的项目中总结经验教训。通过分析在其他项目中发现的缺陷和引起缺陷的根本原因，我们就可以改进测试过程(process)。相继地，过程的改进又可以预防相同的缺陷再次发生，从而提高以后系统的质量。

测试应该作为质量保证的各种作业中（例如：开发标准、教育、缺陷分析）的不可或缺的一部分。

1.1.5 测试是否充分

测试应该进行到哪种程度，取决于技术、产品、项目风险的水平，以及在时间和预算等方面项目上的限制。 （风险将在第5章进行详细描述）

测试需要给利益相关者提供足够的信息，帮助他们决定是否发布被测的软件或系统，是否继续进行下阶段的开发或直接将产品交给用户。

追求完全的品质，从成本的角度来看没有效果

缺陷成本：为了修正而产生的成本、产生不良结果的成本

Joseph M. Juran 1.テストの必要性（3/3

1.2 什么是测试（P7-8）

术语

代码(code)、调试(debugging)、（软件）开发(development)、需求(requirement)、评审(review)、测试依据(test basis)、测试用例(test case)、测试(testing)、测试目标(test objectives)。

背景

在一般人的理解当中，测试活动只包含了运行测试，也就是执行软件。但实际上这只是测试的一部分，而不是测试的所有活动。

测试的活动包含了测试执行之前和之后的一些活动，包括计划(planning)和控制(control)、选择测试条件(test condition)、设计测试用例(test case)、检查测试结果(result)、评估完成准则(completion criteria)、报告测试过程(test process)及被测系统、测试结束或总结。测试同时也包括文档的评审(review)（包括代码）和静态分析(static analysis)。

动态测试(dynamic testing)和静态测试这两种手段都可以达到相似的目标，即以提供信息来改进被测试软件系统的质量，以及改善开发和测试的过程。

测试执行前的作业

- 计划、测试条件、测试用例设计

测试执行时的作业

- 执行结果的Check、完了基准的验证、测试结果报告

测试执行后的作业

- 软件的整理

通过整体的作业

- 项目控制、评审

※ 在下一节的《基本的测试流程》中，会将测试执行前的作业分为计划和设计，当作5个流程来定义。

不同的测试具有不同的测试目标：

发现缺陷；

获取对产品质量的信心，以及提供信息；

预防缺陷。

在软件生命周期早期进行测试用例的设计，可以帮助避免将缺陷引入代码中。同时文档的评审（例如需求文档）也可以预防将缺陷引入代码。

不同的测试阶段，需要考虑不同的测试目标。比如，在开发中的测试里，如单元测试(unit testing)、集成测试(integration testing)和系统测试(system testing)等，测试的主要目标是尽可能的发现失效，从而识别和修正尽可能多的缺陷。在验收测试（acceptance testing）中，测试的主要目标是用来确认系统是否按照预期工作，从而在系统是否满足需求方面获取信心。而在有些情况下，测试的主要目标是对软件的质量进行评估（不是为了修正缺陷），从而为利益相关人提供这样的信息：在给定时间内发布的系统版本所存在的风险。而保守测试 (维护测试maintenance testing)通常是为了验证在开发过程中的变更是否引入新的缺陷。在运行测试阶段，测试的主要目标是为了评估系统的特征，比如可靠性或可用性等。

必须明确，调试和测试是两个不同的概念。测试可以发现由于软件存在的缺陷引起的失效。而调试是一种开发活动，用来识别引起缺陷的原因，修改代码以及验证是否正确的修改了软件的缺陷。随后由测试员进行的确认测试(confirmation testing)是为了确认修改的代码已经解决了失效问题。每个活动的职责是截然不同的，即测试员进行测试，开发人员进行调试。

1.3 测试的基本原则

术语

穷尽测试(exhaustive testing)。

原则

在过去40年中，软件测试界提出了很多的测试原则，并且提供了适合所有测试的一些共同的测试指南。

原则1 － 测试显示缺陷的存在

测试可以显示缺陷(defect)的存在，但不能证明系统不存在缺陷。测试可以减少软件中存在缺陷的可能性，但即使测试没有发现任何缺陷，也不能证明软件或系统是完全正确的。

原则2 － 穷尽测试是不可能的

除了小型项目，进行完全（各种输入和前提条件的组合）的测试是不现实的。通过运用风险管理(risk management)和不同系统功能的测试优先级，来确定测试的关注点，从而替代穷尽测试。

原则3 － 测试尽早介入

在软件或系统开发生命周期中，测试活动应该尽可能早的介入，并且应该将关注点放在已经定义的测试目标(test objective)上。

原则4 － 缺陷集群性

版本发布前进行的测试所发现的大部分缺陷和软件运行失效是由于少数软件模块引起的。

原则5 － 杀虫剂悖论

同样的测试用例一遍一遍重复进行测试，最后将不再能够发现新的缺陷。为了克服这种杀虫剂悖论，测试用例需要经常性的评审和修改，同时需要不断增加新的不同的测试用例来测试软件或系统的不同部分，从而发现潜在的更多的缺陷。

原则6 － 测试活动依赖于测试内容

针对不同的测试内容，进行的测试活动也是不同的。比如，对关注安全的软件进行测试，与一般的商业软件测试的重点是不一样的。

原则7 － 0缺陷的谬论

假如系统无法使用，或者系统不能完成客户的需求和期望，发现和修改缺陷是没有任何帮助的。

「所有的模式都是错误的。但是，有的模式能够起到作用」

原则上，是将现实世界抽象化、故意让很多信息欠缺。

欲将软件开发和测试这种极富多样性的活动，用几个原则来进行说明，

本身就不太可能。但是，这种原则对于理解测试的重要一面，确实有着

非常重要的作用。总而言之，工具是可以使用的。

1.4 基本的测试过程

术语

确认测试(confirmation testing)、出口准则(exit criteria)、事件(incident)、回归测试(regression testing)、测试依据(test basis)、测试条件(test condition)、测试覆盖(test coverage)、测试数据(test data)、测试执行(test execution)、测试日志(test log)、测试计划(test plan)、测试策略(test strategy)、测试总结报告(test summary report)、测试件(testware)。

背景

测试最显而易见的活动是测试的执行。但是为了提高效率，在测试计划中，同样需要保留比较多的时间用于计划测试活动、设计测试用例、准备测试的执行和评估测试的状态。

基本的测试过程主要由下面一些活动组成：

1 计划和控制；

2 分析和设计；

3 实现和执行；

4 评估出口准则和测试报告；

5 测试结束活动。

虽然上面这些活动在逻辑上是有连续的，但在整个测试过程中它们可能会重叠或同时进行。

1.4.1 测试计划和控制阶段

测试计划的主要活动是：识别测试的任务、定义测试的目的；以及为实现测试目的而决定测试作业的式样。

测试控制是持续进行的活动：通过对测试进展和测试计划之间的比较，报告测试的状态，包括与计划之间存在的偏差。测试控制包括在必要的时候采取必要的措施来满足测试的任务和目标。需要在项目的整个生命周期中对测试活动进行监控，以达到控制测试过程的目的。同时，测试计划的制定也需要借鉴以前项目测试监控活动的经验和有用信息。

测试计划阶段主要任务：

确定测试的范围和风险，识别测试的目的；

确定测试方法:测试技术、测试项(test item)、测试覆盖(test coverage)、识别和联系相关的测试团队和测试件；

确定测试需要的资源:人员、测试环境(test environment)和计算机等；

贯彻测试方针和策略；

计划测试分析和测试设计任务的时间进度；

计划测试作成、执行和验证的时间进度；

确定测试的结束（出口）准则。

测试控制阶段主要任务：

测量和分析结果；

监控和记录测试进展、测试覆盖和测试出口准则的文档化；

修改软件的缺陷；

做出决定。

1.4.2 测试分析和设计阶段

测试分析和设计是将抽象的测试目标转化为实实在在的测试条件和测试设计的一系列活动。

测试分析和设计阶段的主要任务：

1. 评审测试依据（比如需求、系统架构、设计和接口说明等）。

2. 识别测试条件或测试需求(test requirement)，根据测试项、详细规格说明、系统行为和结构分析得到必要的测试条件和数据。

3. 设计测试用例。

4. 评估系统和需求的可测试性(testability)。

5. 规划测试环境的搭建和确定测试需要的基础设施（infrastructure）和工具。

1.4.3 测试实现和执行阶段

测试实现和执行是将测试条件转化为测试用例、测试件的一系列活动，并进行测试环境的搭建。

测试实现和执行阶段的主要任务：

1. 测试用例的开发和确定它们的优先级，创建测试数据，描述测试的具体步骤，同时也可以准备测试用具(test harnesses)和设计测试脚本(test script)。

2. 根据测试用例建立测试套件(test suite)，以提高测试执行的效率。

3. 确认已经正确搭建了的测试环境。

4. 根据计划的执行顺序，通过手工或使用测试执行工具(test execution tool)来执行测试用例。

5. 记录测试执行的结果，以及被测软件的标识和版本、使用的测试工具和测试件。

6. 将实际结果和预期结果进行比较。

7. 对实际结果和预期结果之间的差异，作为缺陷上报，并且分析这些缺陷以确定引起缺陷的原因（代码缺陷、具体测试数据缺陷、测试文档缺陷、或测试执行的方法有错误等）。

8. 缺陷修正后，重新进行测试活动。比如通过再次执行在上个版本中失败的用例来确认缺陷是否已经被修正（确认测试）。执行修正后的测试用例或执行一些测试用例来确保缺陷的修正没有在软件中引入新的问题后或没有引起其他的缺陷（回归测试）。

テストベース、テストスイート、テストケース、テストプロシージャ：

1.4.4 评估出口准则和测试报告阶段

评估出口准则阶段是将测试的执行结果和已经定义的测试目标进行比较的活动。这个活动在各个测试级别(test level)上都需要进行。

评估测试出口准则的主要任务：

1. 将测试结果记录与测试计划作业中定义的终了基准相对比。

2. 判断是否需要进行更多的测试，或是否需要更改测试的出口准则。

3. 为利益相关者提供一个测试总结报告。

Bug管理图

1.4.5 测试结束阶段

测试结束阶段从完成的测试活动中收集资料来巩固测试经验，收集测试件、影响测试的因素和其他数据。比如什么时候软件系统可以发布？什么时候项目测试结束或取消？什么时候达到里程碑？或者何时可以发布一个维护版本等？

测试结束阶段的主要任务：

检查提交了哪些计划的交付物(deliverable)、缺陷报告是否关闭、提交的变更记录是否仍处于开放状态、以及系统的验收文档状态等等。

归档测试件(testware)、测试环境和测试基础设备(test infrastructure)，以备将来的项目使用。

移交测试件到维护部门。

分析学到的经验教训，作为将来项目和版本的参考及用来改进测试成熟度(test maturity)。

1.5 测试的心理学

术语

独立测试(independent testing)。

背景

在测试和评审中使用的思想方法，与在项目分析和开发中使用的方法不同。开发员可以测试他们自己写的代码，但这与测试员职责之间是存在区别的，明白这一点，测试员的独立测试需要提供专门的工作量，并且具有以下优点：通过专业的培训和利用专业的测试资源，实现独立的测试；独立测试可以应用于任何测试级别。

一定程度的独立测试（可以避免开发人员对自己代码的偏爱），可以更加高效的发现软件缺陷和软件存在的失效。但独立测试不是完全的替代物，因为开发人员也可以高效的在他们的代码中找出很多缺陷。可以定义不同级别的独立测试：

测试用例由软件本身编写的人员来设计（低级别的独立测试）。

测试用例由开发小组中的其他成员来设计。

测试用例由组织内的其他小组成员来设计（独立的测试小组）。

测试用例由来自其他组织或其他公司的成员来设计（测试外包）。

测试的目标驱使着小组成员和项目的活动。小组成员将根据管理层或其他利益相关者设定的目标对他们的计划进行调整，比如需要发现更多的缺陷，或确认软件是否可以正常工作。因此，对测试的目标进行清晰的设定是非常重要的。

测试过程中发现的失效，可能会被看成是测试员对产品的责难或对产品开发者的不恭。因此，测试通常被认为是破坏性的活动，即使它对于管理产品风险是非常有建设性作用的。在系统中发现失效需要测试员具有一颗好奇的心、专业的怀疑态度、一双挑剔的眼睛、探究根底的精神、与开发人员良好的沟通能力以及对常见的错误进行判断的经验。

假如可以用建设性的态度对发现的缺陷或失效进行沟通，就可以避免测试员、分析人员和开发设计者之间的不愉快。这个道理同样适用于文档的评审过程。

在以建设性的方式讨论缺陷、进度和风险时，测试员和测试的负责人都需要具有良好的人与人之间沟通的能力。通过良好的沟通，要让软件代码或文档的作者明白，发现缺陷的信息可以帮助他们来提高他们的技术水平。在测试阶段发现和修复缺陷可以在项目后期节省时间和金钱，而且可以减少项目的风险。

沟通方面的问题经常会发生，特别是当测试员只是作为不受欢迎的缺陷消息的传递者的时候。然而可以使用下面的一些建议和方法来改善测试员和其他小组成员之间的沟通和相互关系：以合作而不是争斗的方式开始项目，时时提醒项目的每位成员：共同目标是追求高质量的产品。

对产品中发现的问题以中性的和以事实为依据的方式来沟通，而不要嘲笑引入这个问题的小组成员或个儿。比如，客观而实际的描写缺陷报告和评审(review)发现的问题。

尽量理解其他成员的感受，以及他们为什么会有这种反应。

确信其他成员已经理解你的描述，反之亦然。

1. 遵守规范：项目各阶段包括PRD、Coding 、UC、TC及发布严格遵守规范，如开发、测试及配置资源安排、进度计划、配置管理、项目管理、发布流程，严格遵守规范并不等于缺乏创新，而是在按照规范办事的前提下，过程中发现风险及问题，鼓励使用创新的方法解决问题并总结归纳出解决方案。

2. 风险评估：这个能力非常重要，项目的每个阶段都可能存在风险：需求不明确、系统设计或测试设计不完善、代码编写不安全、测试用例不充足、测试人员未完全测试、测试资源不足、回归工作量估计不当、项目进度安排不妥、其他项目对本项目的影响等等，所以项目过程中要具有高度警惕性，尤其要做到开发和测试善始善终。

3. 缺陷预防：个人认为做到很好的缺陷预防是需要综合素质的，如熟练的业务能力，最好能够熟知各产品间的关联，如果能够知道产品实现方法及过程最好不过。能够及时根据当前其他产品发布出现的问题预测对本项目的影响度并做好相关缺陷分析。

4. 沟通能力：往往测试和开发容易处于对立面，不和谐的团队对项目的质量必然带来一定的负面影响，毕竟人的情绪在工作中对工作效率的影响力是非常大的，软件质量是靠开发测试一起保证的，记得在测试技术交流大会中郭芙老大说过开发人员的测试意识不是天生具有的，当遇到开发人员测试观念不足时需要测试人员去指导开发人员，提高开发人员的测试意识。不能把开发人员测试意识不足当作产品质量不好的理由，所以在这个过程中沟通能力是一个很好的体现。