【原】一文搞懂软件测试，完整总结软件测试基础知识

一、软件测试的基本概念

1.测试是软件生存周期中十分重要的一个过程，是产品发布、提交给最终用户前的稳定化阶段。

2.软件测试是为了发现错误而执行程序的过程。或者说，软件测试是根据软件开发各阶段的规格说明和程序内部结构而精心设计的一批

二、软件测试的目的

1.基于不同的立场，存在着两种完全不同的测试目的。

2.从用户的角度出发，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可接受该产品。

3.从软件开发者的角度出发，则希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的要求，确立人们对软件质量的信心。
换言之，测试的目的是想以最少的时间和人力，系统地找出软件中潜在的各种错误和缺陷。

4.测试的目标是能够以耗费最少时间与最小工作量找出软件系统中潜在的各种错误与缺陷。另外，我们应该认识到：测试只能证明程序中错误的存在，但不能证明程序中没有错误。因为即使实施了最严格的测试，仍然可能还有尚未被发现的错误或缺陷存在于程序当中，因而测试不能证明程序没有错误，但可能查出程序中的错误。

三、软件测试的原则

1.尽早地并不断地进行软件测试。

2.程序员或程序设计机构应避免测试自己设计的程序。

3.测试用例中不仅要有输入数据，还要有与之对应的预期结果。

4.测试用例的设计不仅要有合法的输入数据，还要有非法的输入数据。

5.在对程序修改之后要进行回归测试。

6.程序中尚未发现的错误的数量通常与该程序中已发现的错误的数量成正比。

7.妥善保留测试计划、全部测试用例、出错统计和最终分析报告，并把它们作为软件的组成部分之一，为维护提供方便。

8.应当对每一个测试结果做全面检查。

9.严格执行测试计划，排除测试的随意性。测试计划内容应包括：所测软件的功能、输入和输出、测试内容、各项测试的进度安排、资源要求、测试资料、测试工具、测试用例的选择、测试的控制方式和过程、系统组装方式、跟踪规程、调试规程、回归测试的规定以及评价标准等。

三、软件测试的对象

1.软件测试并不等于程序测试。软件测试应贯穿于软件定义与开发的整个期间。

2.需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为软件测试的对象。

四、软件测试的对象

1.从测试方法的角度可以分为手工测试和自动化测试：
1）手工测试：不使用任何测试工具，根据事先设计好的测试用例来运行系统，测试各功能模块。
2）自动化测试：利用测试工具，通过编写测试脚本和输入测试数据，自动运行测试程序。

2.两种常用的测试方法：黑盒测试、白盒测试

五、黑盒测试

1.这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。

2.黑盒测试法是根据被测程序功能来进行测试，所以通常又叫做功能测试或数据驱动测试

3.黑盒测试方法是在程序接口上进行测试，主要是为了发现以下错误:
1）是否有不正确或遗漏了的功能
2）在接口上，输入能否正确地接受？能否输出正确的结果？
3）是否有数据结构错误或外部信息(例如数据文件)访问错误？
4）性能上是否能够满足要求？
5）是否有初始化或终止性错误？
6）用黑盒测试发现程序中的错误，必须在所有可能的输入条件和输出条件中确定测试数据，来检查程序是否都能产生正确的输出。
但这是不可能的。

六、黑盒测试的测试用例设计

1.等价类划分

等价类划分是一种典型的黑盒测试方法，使用这一方法时， 完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。
等价类划分方法把所有可能的输入数据，即程序的输入域 ，划分成若干部分，然后从每一部分中选取少数有代表性的数据做为测试用例。
使用这一方法设计测试用例要经历划分等价类（列出等价类表）和选取测试用例两步。

等价类是指某个输入域的子集合。在该子集合中， 各个输入数据对于揭露程序中的错误都是等效的。测试某等价类的代表值就等价于对这一类其它值的测试。
等价类的划分有两种不同的情况：
①有效等价类：是指对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合。
②无效等价类：是指对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合。
在设计测试用例时，要同时考虑有效等价类和无效等价类的设计。

2.边界值分析

1.边界值分析也是一种黑盒测试方法，是对等价类划分方法的补充。

2，从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。

3.比如，在做三角形计算时，要输入三角形的三个边长：A、B和C。 我们应注意到这三个数值应当满足A＞0、B＞0、C＞0、 A＋B＞C、A＋C＞B、B＋C＞A，才能构成三角形。但如果把六个不等式中的任何一个大于号“＞”错写成大于等于号“≥”，那就不能构成 三角形。问题恰出现在容易被疏忽的边界附近。

4.这里所说的边界是指，相当于输入等价类和输出等价类而言，稍高于其边界值及稍低于其边界值的一些特定情况。

5.使用边界值分析方法设计测试用例，首先应确定边界情况。 应当大于等于最大值，小于等于最小值作为边界值进行测试。

3.错误推测法

1.人们也可以靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子。这就是错误推测法。

2.错误推测法的基本想法是： 列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。

4,因果图

1.因果图的适用范围
1）如果在测试时必须考虑输入条件的各种组合，可使用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来设计测试用例，这就需要利用因果图。
2）因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。

七、软件测试的策略

1.大型软件系统通常由若干个子系统组成，每个子系统又由许多模块组成。大型软件系统的测试步骤基本由以下四个步骤组成：单元测试、集成测试(组装测试)、确认测试和系统测试。

2.开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。
组装测试把已测试过的模块组装起 ，主要对与设计相关的软件体系结构的构造进行测试。

3.确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。

4.系统测试 把已经经过确认的软件纳入实际运行环境中，与其它系统成份组合在一起进行测试。

七、测试策略详解

1.单元测试 (Unit Testing)

1）单元测试又称模块测试， 是针对软件设计的最小单位 ── 程序模块 ，进行正确性检验的测试工作。

2）其目的在于发现各模块内部可能存在的各种差错。

3）单元测试需要从程序的内部结构出发设计测试用例 。

4）多个模块可以平行地独立进行单元测试。

2.组装测试（ Integrated Testing）

1）组装测试(集成测试、联合测试）

2）通常，在单元测试的基础上，需要将所有模块按照设计要求组装成为系统。这时需要考虑的问题是： 在把各个模块连接起来的时侯，穿越模块接口的数据是否会丢失；

3）一个模块的功能是否会对另一个模块的功能产生不利的影响；

4）各个子功能组合起来，能否达到预期要求的父功能；

5）全局数据结构是否有问题；

6）单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。

7）在单元测试的同时可进行组装测，发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统。

3.确认测试（ Validation Testing）

1）确认测试又称有效性测试

2）任务是验证软件的功能和性能及其它特性是否与用户的要求一致。

3）对软件的功能和性能要求在软件需求规格说明书中已经明确规定。它包含的信息就是软件确认测试的基础。

4）主要由使用用户参加测试，检验软件规格说明的技术标准的符合程度，是保证软件质量的最后关键环节.

5)进行有效性测试（黑盒测试）
有效性测试是在模拟的环境(可能就是开发的环境) 下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。
首先制定测试计划，规定要做测试的种类。还需要制定一组测试步骤，描述具体的测试用例。
通过实施预定的测试计划和测试步骤，确定
软件的特性是否与需求相符；
所有的文档都是正确且便于使用；
‹同时，对其它软件需求，例如可移植性、兼容性、出错自动恢复、可维护 性等，也都要进行测试
在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类：
①测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合，从而这部分程序被接受。
②测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致，因此要为它提交一份问题报告。

6)软件配置复查
软件配置复查的目的是保证：
1.软件配置的所有成分都齐全；
2.各方面的质量都符合要求；
具有维护阶段所必需的细节；
而且已经编排好分类的目录。
应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查这些文档资料的完整性和正确性。

4.系统测试（System Testing）

1.系统测试，是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起， 在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。

2.系统测试的目的在于通过与系统的需求定义作比较, 发现软件与系统的定义不符合或与之矛盾的地方。

3.在系统测试实施之前，软件工程师应完成以下工作：
为测试软件系统的输入信息设计出错处理通路；设计测试用例，模拟错误数据和软件界面可能发生的错误，记录测试结果，为系统测试提供经验和帮助；参与系统测试的规划和设计，保证软件测试的合理性。

5.验收测试（ Acceptance Testing）

1.在通过了系统的有效性测试及软件配置审查之后，就应开始系统的验收测试。

2.验收测试是以用户为主的测试。软件开发人员和QA（质量保证）人员也应参加。

3.由用户参加设计测试用例，使用生产中的实际数据进行测试。

4.在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。

5.确认测试应交付的文档有：确认测试分析报告、最终的用户手册和操作手册
、项目开发总结报告。

八、软件测试的过程

1.测试过程说明：

(1) 软件配置：指被测试软件的文件，如软件需求规格说明书、软件设计说明书和源程序清单等文档。

(2) 测试配置：指测试方案、测试计划、测试用例、测试驱动程序等文档。

(3) 测试工具：是为了提高测试效率而设计的支持软件测试的软件。例如，测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序以及驱动测试的测试数据库等。

(4) 测试评价：由测试出的错误迹象，分析、找出错误的原因和位置，以便纠正和积累软件设计的经验。

(5) 纠错(调试)：是指找到出错的原因与位置并纠错，包括修正文件直到软件正确为止。纠错本身所具有的不确定性，常常难以准确地安排测试日程表。

(6) 可靠性模型：通过对测试出的软件出错率的分析，建立模型，得出可靠的数据，指导软件的设计与维护。

九、项目测试的基本流程

1.项目测试启动：项目立项后，在测试配置库中创建项目。

2.测试计划：系统详细设计后，制定测试计划，准备测试资源。

3.设计测试用例，主要是与业务相关的测试用例。

4.实施功能模块测试，搭建运行或开发环境，采用功能模块测试表的方式，开发人员在功能模块测试表中更新进度状态，测试人员在该表中描述测试进度。形成测试错误列表，该表对每个错误都有相应的测试记录与之链接，在测试记录中，详细描述错误的情况。在测试记录中还要包括修正信息和验证信息。

5.错误关闭后，测试人员维护测试记录表和更新测试用例库和问题库，作为经验积累。

6.项目在结项时，测试人员进行项目完工验收测试，填写项目测试报告。该测试报告可作为用户验收的输入工件。

十、测试过程管理

十一、测试用例的设计

1.在编写测试用例之前需要准备以下几个编写的依据：
①需求说明以及相关文档；
②相关的设计说明（概要设计，详细设计等）；
③与开发组交流对需求理解的记录（可以是开发人员的一个解释）；
④已经基本成型的UI（可以有针对性地补充一些用例）。
⑤编写测试用例文档应有文档模板，须符合内部的规范要求。

2.测试用例可以分为基本事件、备选事件和异常事件。

3.软件测试常用的设计测试用例的基本方法有：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等。视软件的不同性质采用不同的方法。如何灵活运用各种基本方法来设计完整的测试用例，并最终实现暴露隐藏的缺陷，则要凭测试设计人员的丰富经验和精心设计。

4.测试用例的评审
由开发人员和测试人员共同进行评审，目的是审查编写的测试用例是否覆盖了整个项目的需求点。

5.测试用例的修改更新

6.测试用例的管理
测试管理软件的主要功能有三个：
①能将测试用例文档的关键内容；
②可供测试实施时及时输入测试情况；
③最终实现自动生成测试结果文档。