三、 软件测试的概述

1、软件测试的发展

软件测试的发展也经历了一个漫长的过程，其发展过程可用下图表示：

2、软件测试的定义

（1）1983年，IEEE给软件测试的定义：

使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。

（2）1990年，IEEE再次给出软件测试的定义：

①在特定的条件下运行系统或构件，观察或记录结果，对系统的某个方面做出评价；

②分析某个软件项以发现现存的和要求的条件之差别并评价此软件项的特性。

总结：

• 以上的定义都有一定的片面性。不能只对系统程序进行测试，找出系统程序中的错误，而对分析、设计等过程发生的错误视而不见。
• 软件产品由文档、数据和程序组成，那么软件测试就是对软件开发过程中形成的文档、数据以及程序进行相关的测试。

3、软件测试的目的

• 对于软件开发来说，软件测试通过找到的问题缺陷帮助开发人员找到开发过程中存在的问题，包括软件开发的模式、工具、技术等方面存在的问题与不足，预防下次缺陷的产生。
• 对于软件测试来说，使用最少的人力、物力、时间等找到软件中隐藏的缺陷，保证软件的质量，也为以后软件测试积累丰富的经验。
• 对于客户需求来说，软件测试能够检验软件是否符合客户需求，对软件质量进行评估和度量，为客户评审软件提供有力的依据。

4、软件测试的分类

（1）按照测试阶段分类

• 单元测试：验证软件单元是否符合软件需求与设计，开发人员自测。
• 集成测试：将已经测试过的软件单元组合在一起测试它们之间的接口，用于验证软件是否满足设计需求。
• 系统测试：将经过测试的软件在实际环境中运行，并与其他系统的成分（如数据库、硬件和操作人员等）组合在一起进行测试。
• 验收测试：主要是对软件产品说明进行验证，逐行逐字的按照说明书的描述对软件产品进行测试，确保其符合客户的各项要求。

（2）按照测试技术分类

• 黑盒测试：把软件（程序）当作一个有输入与输出的黑匣子，它把程序当作一个输入域到输出域的映射，只要输入的数据能输出预期的结果即可，不必关心程序内部是怎么样实现的。

• 白盒测试：测试人员了解软件程序的逻辑结构、路径与运行过程，在测试时，按照程序的执行路径得出结果。白盒测试就是把软件（程序）当作一个透明的盒子，测试人员清楚的知道从输入到输出的每一步过程。

总结：

相对于黑盒测试来说，白盒测试对测试人员的要求会更高一点，它要求测试人员具有一定的编程能力，而且要熟悉各种脚本语言。但是在软件公司里，黑盒测试与白盒测试并不是界限分明的，在测试一款软件时往往是黑盒测试与白盒测试相结合对软件进行完整全面的测试。

（3）按照软件质量特性分类

• 功能测试：测试软件的功能是否满足客户的需求，包括准确性、易用性、适合性、互操作性等。
• 性能测试：测试软件的性能是否满足客户的需求，性能测试包括负载测试、压力测试、兼容性测试、可移植性测试和健壮性测试等。

（4）按照自动化程度分类

• 手工测试：测试人员一条一条的执行代码完成测试工作。费时费力且很难保证测试效果。
• 自动化测试：借助脚本、自动化测试工具等完成相应的测试工作，它也需要人工的参与，但是它可以将要执行的测试代码或流程写成脚本，执行脚本完成整个测试工作。

（5）按照测试项目分类

• 界面类测试：验证软件界面是否符合客户需求。
• 安全性测试：软件遭受到没有授权的内部或外部用户的攻击或恶意破坏时如何进行处理，是否能保证软件与数据的安全。
• 文档测试：以需求分析、软件设计、用户手册、安装手册为主，主要验证文档说明与实际软件之间是否存在差异。

（6）其他分类

• α测试：软件上线之前进行的版本测试。由开发人员和测试人员或者用户协助进行测试。测试人员记录使用过程中出现的错误与问题，整个测试过程是可控的。
• β测试：软件上线之后进行的版本测试。由用户在使用过程中发现错误与问题并进行记录，然后反馈给开发人员进行修复。
• 回归测试：对修改后的程序重新进行测试，确认原有的缺陷已经消除并且没有引入新的缺陷，这个重新测试的过程就叫作回归测试。
• 随机测试：没有测试用例、检查列表、脚本或指令的测试，它主要是根据测试人员的经验对软件进行功能和性能抽查。

四、 软件测试与软件开发的关系

软件测试在软件开发过程中占有重要的地位，在传统的瀑布模型中，软件测试只成为其阶段性的一段工作——进行代码的测试。而现代软件工程思想将软件测试认为是贯穿整个软件生命周期，并且是保证软件质量的重要手段之一。

有些研究数据显示，在国外软件开发的工作量中，软件测试的工作量占有总工作量的40%左右；软件开发的总费用中软件测试占有30%-50%。对于一些高科技开发系统，软件测试占有的时间和费用可能更多更高。

1、软件测试与软件开发

软件测试在项目各个阶段的作用如下：

• 项目规划阶段：负责从单元测试到系统测试的整个测试阶段的监控。
• 需求分析阶段：确定测试需求分析，即确定在项目中需要测试什么，同时制定系统测试计划。
• 概要设计与详细设计阶段：制定单元测试计划和集成测试计划。
• 编码阶段：编写相应的测试代码和测试脚本。
• 测试阶段：执行测试并提交相应的测试报告。

软件测试与软件开发的关系如下图所示：

2、常见软件测试模型

（1）V模型

• 优点：将复杂的测试工作分成了目标明确的小阶段完成，具有阶段性、顺序性和依赖性，它既包含了对于源代码的底层测试也包含了对于软件需求的高层测试。
• 缺点：只能在编码之后才能开始测试，早期的需求分析等前期工作没有涵盖其中，因此它不能发现需求分析等早期的错误，这为后期的系统测试、验收测试埋下了隐患。

V模型流程图如下：

（2）W模型

• 优点：测试范围不仅包括程序，还包括需求分析、软件设计等前期工作，这样有利于尽早全面的发现问题。
• 缺点：它将软件开发过程分成需求、设计、编码、集成等一系列的串行活动，无法支持迭代、自发性等需要变更调整的项目。

W模型流程图如下：

（3）H模型

• 设计原理：H模型的设计原理是将测试活动完全独立了出来，形成一个完全独立的流程，这个流程将测试准备活动和测试执行活动清晰的体现出来。测试流程和其他工作流程是并发执行的，只要某一个工作流程的条件成熟就可以开始进行测试。
  
• 优点：

• 开发的H模型揭示了软件测试除测试执行外，还有很多工作；
• 软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行；
• 软件测试活动可以尽早准备、尽早执行，具有很强的灵活性；
• 软件测试可以根据被测物的不同而分层次、分阶段、分次序的执行，同时也是可以被迭代的。

• 缺点：

• 管理型要求高：由于模型很灵活，必须要定义清晰的规则和管理制度，否则测试过程将非常难以管理和控制；
• 技能要求高：H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小；
• 测试就绪点分析困难：测试很多的时候，你并不知道测试准备到什么时候是合适的，就绪点在哪里，就绪点的标准是什么，这就对后续的测试执行的启动带来很大困难；
• 对于整个项目组的人员要求非常高：在很好的规范制度下，大家都能高效的工作，否则容易混乱。例如：你分了一个小的迭代，但是因为人员技能不足，使得无法有效完成，那么整个项目就会受到很大的干扰。

H模型流程图如下：

（4）X模型

• 设计原理：X模型的设计原理是将程序分成多个片段反复迭代测试，然后将多个片段集成再进行迭代测试。
• 优点：对单独程序片段进行的相互分离的编码和测试，保证了测试效果。增加了探索测试，可以帮助测试人员发现计划之外的软件错误。
• 缺点：频繁的集成会增加测试成本；探索测试对测试人员要求更高。

X模型流程图如下：

经验小结：

• v模型适用于中小企业，w模型适用于中大型企业（因为人员要求高），h模型人员要求非常高，很少有公司使用；
• 结合W模型与H模型进行工作，软件各方面的测试内容是以W模型为准，而测试周期、测试计划和进度是以H模型为指导。X模型更多是作为最终测试、熟练性测试的模板，例如，对一个业务的测试已经有2年时间，则可以使用X模型进行模块化的、探索性的方向测试。

五、 软件测试的原则

1、软件测试的原则

（1）测试应基于客户需求

所有的测试工作都应该建立在满足客户需求的基础上，从客户角度来看，最严重的错误就是软件无法满足要求。有时候，软件产品的测试结果非常完美，但却不是客户最终想要的产品，那么软件产品的开发就是失败的，而测试工作也是没有任何意义的。因此测试应依照客户的需求配置环境并且按照客户的使用习惯进行测试并评价结果。

（2）测试要尽早进行和不断进行

软件的错误存在于软件生命周期的各个阶段，因此应该尽早开展测试工作，把软件测试贯穿到软件生命周期的各个阶段中，这样测试人员能够尽早地发现和预防错误，降低错误修复的成本。尽早的开展测试工作有利于帮助测试人员了解软件产品的需求和设计，从而预测测试的难度和风险，制定出完善的计划和方案，提高测试的效率。

（3）穷举测试是不可能的

由于时间和资源的限制，进行完全（各种输入和输出的全部组合）的测试是不可能的，测试人员可以根据测试的风险和优先级等确定测试的关注点，从而控制测试的工作量，在测试成本、风险和收益之间求得平衡。

（4）遵循GoodEnough原则

GoodEnough原则是指测试的投入与产出要适当权衡，形成充分的质量评估过程，这个过程建立在测试花费的代价之上。测试不充分无法保证软件产品的质量，但测试投入过多会造成资源的浪费。随着测试资源投入的增加，测试的产出也是增加的，但当投入达到一定的比例后，测试的效果就不会明显增强了。因此在测试时要根据实际要求和产品质量考虑测试的投入，最好使测试投入与产出达到一个GoodEnough状态。

（5）测试缺陷要符合“二八”定理

一般情况下，软件80%的缺陷会集中在20%的模块中，缺陷并不是平均分布的。因此在测试时，要抓住主要矛盾，如果发现某些模块比其他模块具有更多的缺陷，则要投入更多的人力、精力重点测试这些模块以提高测试效率。

（6）避免缺陷免疫

测试用例被反复使用，发现缺陷的能力就会越来越差；测试人员对软件越熟悉越会忽略一些看起来比较小的问题，发现缺陷的能力也越差，这种现象被称为软件测试的“杀虫剂”现象。它主要是由于测试人员没有及时更新测试用例或者是对测试用例和测试对象过于熟悉，形成了思维定势。

六、 软件测试的流程

1、软件测试的基本流程

不同类型的软件产品测试的方式和重点不一样，测试流程也会不一样。同样类型的软件产品，不同的公司所制定的测试流程也会不一样。虽然不同软件的详细测试步骤不同，但它们所遵循的最基本的测试流程是一样的。

（1）分析测试需求

测试人员在制定测试计划之前需要先对软件需求进行分析，以便对要开发的软件产品有一个清晰的认识，从而明确测试对象及测试工作的范围和测试重点。在分析需求时还可以获取一些测试数据，作为测试计划的基本依据，为后续的测试打好基础。

此外，分析测试需求也是对软件需求进行测试，以发现软件需求中不合理的地方。

被确定的测试需求必须是可核实的，测试需求必须有一个可观察、可评测的结果。无法核实的需求就不是测试需求。测试需求分析还要与客户进行交流，以澄清某些混淆，确保测试人员与客户尽早地对项目达成共识。

（2）制定测试计划

测试计划一般要做好以下工作安排。

• 确定测试范围：明确哪些对象是需要测试的，哪些对象不是需要测试的。
• 制定测试策略：测试策略是测试计划中最重要的部分，它将要测试的内容划分出不同的优先级，并确定测试重点。根据测试模块的特点和测试类型（如功能测试、性能测试）选定测试环境和测试方法（如人工测试、自动化测试）。
• 安排测试资源：通过对测试难度、时间、工作量等因素对测试资源合理安排，包括人员分配、工具配置等。
• 安排测试进度：根据软件开发计划、产品的整体计划来安排测试工作的进度，同时还要考虑各部分工作的变化。在安排工作进度时，最好在各项测试工作之间预留一个缓冲时间以应对计划变更。
• 预估测试风险：罗列出测试工作过程中可能会出现的不确定因素，并制定应对策略。

（3）设计测试用例

• 测试用例（Test Case）指的是一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。不同的公司会有不同的测试用例模板，虽然它们在风格和样式上有所不同，但本质上是一样的，都包括了测试用例的基本要素。
• 测试用例编写的原则是尽量以最少的测试用例达到最大测试覆盖率。

（4）执行测试

• 测试执行就是按照测试用例执行测试的过程，这是测试人员最主要的活动阶段。
• 在执行测试时要根据测试用例的优先级进行。
• 在执行测试过程中，测试人员要密切跟踪测试过程，记录缺陷、形成报告等，这一阶段是测试人员最重要的工作阶段。

（5）编写测试报告

一份完整的测试报告必须要包含以下几个要点。

• 引言：测试报告编写目的、报告中出现的专业术语解释及参考资料等。
• 测试概要：介绍项目背景、测试时间、测试地点及测试人员等信息。
• 测试内容及执行情况：描述本次测试模块的版本、测试类型，使用的测试用例设计方法及测试通过覆盖率，依据测试的通过情况提供对测试执行过程的评估结论，并给出测试执行活动的改进建议，以供后续测试执行活动借鉴参考。
• 缺陷统计与分析：统计本次测试所发现的缺陷数目、类型等，分析缺陷产生的原因给出规避措施等建议，同时还要记录残留缺陷与未解决问题。
• 测试结论与建议：从需求符合度、功能正确性、性能指标等多个维度对版本质量进行总体评价，给出具体明确的结论。

总结：测试报告的数据是真实的，每一条结论的得出都要有评价依据，不能是主观臆断的。

七、结束语

下一篇文章讲解黑盒测试和测试用例的基础知识。