单元测试 软件测试
一、单元测试的方法
单元测试也称为模块测试，在模块编写完成且无编译错误后就可以进行。如果选用机器测试，一般用白盒测试法；多个模块可以同时进行。
单元测试主要从模块的以下5个特征着手进行检查。
(1)模块接口。模块的接口保证了测试模块的数据流可以正确地流人、流出。在测试中应检查以下要点：
．测试模块的输入参数和形式参数在个数、属性、单位上是否一致。
·调用其他模块时所给出的实际参数和被调用模块的形式参数在个数、属性、单位上是否一致。
·调用标准函数时所用的参数在属性、数目和顺序上是否正确。
·全局变量在各模块中的定义和用法是否一致。
．输入是否仅改变了形式参数。
·开／关的语句是否正确。
·规定的I／O格式是否与输入输出语句一致。
。在使用文件之前是否已经打开文件或是使用文件之后是否已经关闭文件。
(2)局部数据结构。在单元测试中，局部数据结构出错是比较常见的错误，在测试刚应重点考虑以下因素：
·变量的说明是否合适。
·是否使用了尚未赋值或尚未初始化的变量。
·变量的初始值或默认值是否正确。
·变量名是否有错(例如拼写错)。
(3)重要的执行路径。在单元测试中，．对路径的测试是最基本的任务。由于不能进行穷举测试，需要精心设计测试用例来发现是否有计算、比较或控制流等方面的错误。
·计算方面的错误：算术运算的优先次序不正确或理解错误；精度不够；运算对象的类型不匹配；算法错；表达式的符号表示不正确等。
·比较和控制流的错误：本应相等的量由于精度造成不相等；不同类型进行比较逻辑运算符不正确或优先次序错误；循环终止不正确(如多循环一次或少循环一次)、死循环；不恰当地修改循环变量；当遇到分支循环时，出口错误等。
(4)出错处理。好的设计应该能预测到出错的条件并且有出错处理的途径。虽然计算机机可以显示出错信息的内容，但仍需要程序员对出错进行处理，保证其逻辑的正确性以便于用户维护。
(5)边界条件。边界条件的测试是单元测试的最后工作，也是非常重要的工作。毫件容易在边界出现错误。块进行测试时，需要开发两种模块：
·驱动模块，相当于一个主程序，接收测试用例的数据，将这些数据送到测试椁
输出测试结果。
·桩模块，也称为存根模块。桩模块用来代替测试模块中所调用的子模块，其进行少量的数据处理，目的是为了检验人口，输出调用和返回的信息。 提高模块的内聚度可以简化单元测试。如果每个模块只完成一种功能，对于具一块来讲，所需的测试方案数据就会显著减少，而且更容易发现和预测模块中的错误。
2)组装测试 ． [Page]
组装测试也称为集成测试，就是把模块按系统设计说明书的要求组合起来进行即使所有模块都通过了测试，但在组装之后，仍可能会出现下列问题：
·穿过模块的数据丢失；
·一个模块的功能对其他模块造成有害的影响；
·各个模块组装起来没有达到预期的功能；
·全局数据结构出现问题； ．
·单个模块的误差可以接受，但模块组合后，可能会出现误差累积，最后到不能壬的程度，所以需要组装测试 。
通常组装测试有两种方法：一种是分别测试各个模块，再把这些模块组合起来主整体测试，即非增量式集成。另一种是把下一个要测试的模块组合到已测试好的模块测试完后再将下一个需要测试的模块组合起来，进行测试，逐步把所有模块组合在一并完成测试，即增量式集成。非增量式集成可以对模块进行并行测试，能充分利用人并加快测试进度。但这种方法容易造成混乱，出现错误不容易查找和定位。增量的范围一步步扩大，错误容易定位，而且已测试的模块可在新的条件下再测试，测由彻底。
3)确认测试
经过组装测试之后，软件就被集成起来，接口方面的问题已经解决，将进人软件的最后一个环节一确认测试。确认测试的任务就是进一步检查软件的功能和性能是军用户要求的一样。系统方案说明书描述了用户对软件的要求，所以是软件有效性验证标准，也是确认测试的基础。
确认测试，首先要进行有效性测试以及软件配置审查，然后进行验收测试和安装试，经过管理部门的认可和专家的鉴定后，软件即可以交给用户使用。
·有效性测试，就是在模拟环境下，通过黑盒测试检验所开发的软件是否与需习格说明书一致。在设计测试用例时，除了检测软件的功能和性能之外，还需要 成，但最好是没有参加该项目的有经验的软件设计人员。在所有测试用例完成二后，若发现测试结果与预期的不符，这时要列出缺陷清单。在这个阶段才发现白严重错误，一般很难在预定的时间内纠正，需要与用户协商，寻找妥善解决问题的办法。
·软件配置审查，主要是检查软件(源程序、目标程序)和文档(包括面向开发人员习用户的文档)是否齐全以及分类是否有序。确保文档、资料的正确和完善，以便护阶段使用。
·验收测试，是以用户为主的测试。软件开发人员和质量保证人员也应该参加。验收测试之前，需要对用户进行培训，以便熟悉该系统。验收测试的测试用例用户参与设计，主要验证软件的功能、性能、可移植性、兼容性、容错性等，测试扫描一般采用实际数据。
二、单元测试方法之黑盒测试与白盒测试
单元测试的测试数据可以用两个基本的方法系统地构建。第一个是规格说明测试，这个技术也称为黑盒测试，行为测试，数据驱动测试，功能测试以及输入/输出驱动测试。在这个方法中，不考虑代码本身，在拟制测试用例中使用的仅有的信息是规格说明文档。另一个极端是代码测试，它在选择测试用例时不理会规格说明文档。这个技术也称为玻璃盒测试，白盒测试，结构测试，逻辑驱动测试以及面向路径测试。
规格说明测试的可行性：
考虑下面的例子。假定某个数据处理产品的规格说明指出，必须包含5类佣金和7类折扣。仅测试佣金和折扣的每个可能的组合就需要35个测试用例，说佣金和折扣是在两个完全独立的模块中，因而可以独立测试是没有用的，因为在黑盒测试中将产品当作黑盒对待，它的内部结构因此是完全无关的。因此，彻底的规格说明测试在实际中是不可能的，因为它的组合方式会爆炸式的增长。
代码测试的可行性：
代码测试最常见的形式要求对模块通过的每条路径最少执行一次。试验产品中全部路径是不可靠的，因为存在这样的产品，某些数据试验一个给定路径将检测到错误，而不同的数据试验同一个路径将不会检出错误。然而，面向路径的测试是有效的，因为它没有固有地将可能揭示错误的测试数据的选择排除在外。
因为组合爆炸，彻底的规格说明测试或彻底的代码测试都是不可行的。为此，在使用将尽可能多揭示错误的技术的同时，也承认没有方法保证已经检测出全部错误，一个继续下去的合理的办法是首先使用黑盒测试用例，然后使用玻璃盒测试开发额外的测试用例。
黑盒单元测试技术：
彻底的黑盒测试通常要求成百上千亿的测试用例，因此测试的技巧是设计一个较小，可管理的测试用例集，是检测出一个错误的机会最大，同时通过让相同的错误由多个测试用例检出从而使浪费一个测试用例的机会最小。一个这样的黑盒技术是结合了边界值分析的等价测试。
1. 等价测试和边界值测试
假定一个数据库产品的规格说明指出，该产品必须能够处理任何从1到16383个记录，如果该产品能够处理34个记录和14870个记录，那么它在比如说 8252个记录时工作良好的可能性很大。因此，该产品能够处理的记录数的规定范围可以定义三个等价类：比1个记录小，从1到16383个记录和多于 16383个记录。
一个成功的测试用例能检测出先前未检测到的错误，为了使发现这一的错误的机会最大，一个高效的技术是边界值分析。
综上，因此，测试这个数据库产品的时候，应选择7个测试用例：
1> 0个记录：等价类1的成员，临近边界值。
2> 1个记录：边界值。
3> 2个记录：临近边界值。
4> 723个记录：等价类2的成员。
5> 16382个记录：临近边界值。
6> 16383个记录：边界值。
7> 16384个记录：等价类3的成员，临近边界值。
等价测试的过程概括如下：
对于输入和输出规格说明
对于每个范围（L，U）：
选择5个测试用例：小于L，等于L，比L大但比U小，等于U以及大于U。
对于每个集合S：
选择2个测试用例：一个S的元素和一个非S的元素。 [Page]
对于每个精确值P：
选择2个测试用例：P和其他任何值。
2. 功能测试
一个可选的黑盒测试形式是根据模块的功能选择测试数据。在功能测试中，要区别每个功能项或在模块中实现的功能。
玻璃盒单元测试技术：
在玻璃盒测试技术中，基于代码的检查，而不是规格说明的检查来选择测试用例。有一些不同形式的玻璃盒测试，包括语句，分支以及路径覆盖。
1. 结构测试：语句，分支和路径覆盖
最简单形式的玻璃盒测试是语句覆盖，即运行一系列测试用例，在运行期间每个语句最少执行一次。这个方法的缺点是不能保证对分支的所有输出都充分地测试。
语句覆盖的一个改进是分支覆盖，即运行一系列，确保所有的分支最少测试一次。
像语句或分支覆盖的技术成为结构测试。
功能最强大的结构测试的形式是路径覆盖，即测试所有的路径。
2. 复杂性度量
质量保证观点提供另一个玻璃盒单元测试的方法。假定一个管理者被告知代码模块m1比代码模块m2更复杂，且不管术语复杂是如何准确定义的，管理者直觉上相信m1可能比m2有更多的错误。沿着这条思路，计算机科学家已经开发出一些软件复杂性度量，以帮助确定哪个代码模块更可能有错误。如果发现一个代码模块的复杂度不合理的高，管理者可能直接要求对它重新设计和重新实现，与试图调试一个有错的代码模块相比，可能从头开始的代价更小，速度更快。
文章来源于领测软件测试网 https://www.ltesting.net/
