2.1 测试原理
在企业级的测试中，根据权威的就是 IEEE 提出的「软件测试是使用人工或自动化手段运行或测定某个系统的过程，其目的在于检验它是否满足规定的某个需求或是发现预期结果与实际结果之间的差别」。
软件测试是为了发现错误而执行程序的过程，它是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例，并利用这些测试用例运行程序以及发现错误的过程，即执行测试步骤的过程。
2.1.1 软件测试概述
在认知上，通常认为软件测试就是利用各种手段来发现产品的缺陷，然后将问题转给研发部门解决，以此往复，最终的目的就是确保产品是符合预期需求的。在此期间，可能不会一次性就完成某一产品的测试任务，通常的做法就是对产品进行及时地、有效地测试。
软件在生存周期的各个阶段都是有可能产生错误的，测试在软件生存周期中占据着重要的地位。从软件的整个生存周期来看，测试通常被理解为对程序的测试，而且测试的依据是产品使用说明书、设计的文档和规格说明书等，一旦设计的相关文档产生错误，那么测试的质量自然就难以保证了。
2.1.2 软件测试的分类
按测试技术分类，软件测试可分为白盒测试与黑盒测试两种。
（1）白盒测试
白盒测试通常也称 逻辑驱动的测试，做白盒测试就像做解剖生物实验一样，可以一边解剖一边看被解剖的「器官」是否是正常的逻辑过程；表现在程序上就是将程序内部的结构测试程序理清楚，通常是通过测试检查程序的内部动作是否符合设计规格说明书要求，检验每一个逻辑模块涉及到的通路是否都能够按照既定设计去工作。
（2）黑盒测试
黑盒测试，通常也将它称为产品功能测试，它好比通常所说的「以貌取人」，只看它的表面——功能；黑盒测试就是为了检验产品的每个功能是否都能正常运行，而且测试主要针对软件产品的使用和界面的交互，以及软件与使用者交互的功能的测试。
按阶段划分测试类型可分为单元测试、集成测试、系统测试、验收测试和回归测试 5 种。
（1）单元测试
单元测试指软件开发过程中第一次接触代码的测试，其所进行的是测试阶段及任务中级别和规模最小的测试。进行单元测试时，需要在软件的每一个功能单元都独立分开的情况下开始。单元测试的主要方法有数据流、控制流、排错、分域等。
（2）集成测试
集成测试又叫组装测试，是第一次看到软件产品全貌的测试。集成就是将所有的单元按照相应的要求组合起来，所以该方法是建立在单元测试基础上的一种测试。
（3）系统测试
系统测试是将软件、网络、外设、硬件等一切与产品使用相关的元素结合在一起而进行的综合测试，在此期间不仅要进行信息系统的各种组装、确认、测试，而且还要对整个产品系统进行测试。本阶段的测试目的是验证系统产品是否能满足最终的需求规格，不但要找出与需求规格不符的地方，而且还要提出更为完善的测试方案。
（4）验收测试
验收测试是通过用户和产品的开发方共同指定的测试方对产品进行测试，测试的结果不仅影响用户对产品的看法，重点是决定了产品是否被最终用户所接受，是一种基于用户观点的验证性测试。
（5）回归测试
回归测试是指旧代码修改后，需要重新对其进行测试，以确认修改没有引入新的错误。该阶段的工作在整个软件测试过程中占了很大的比重，因为软件产品在开发的各个阶段都可能会进行多次回归。尤其在目前常用的快速迭代和渐进开发中，当有多个新版本的软件产品连续发布时，回归测试将会更加频繁，而且在要求更为严格的软件开发中，可能每天都要进行若干次回归。
2.2 黑盒测试技术
众所周知，黑盒测试按照定义的要求，重点着眼于程序外部结构和功能，多数情况不会涉及产品的内部逻辑结构是否合理，其主要针对的是界面或软件产品的功能是否全面。而场景法、等价类划分法、边界值分析法、错误猜测法等则是 4 种主要的黑盒测试方法。
2.2.1 场景法
场景法，就是把产品的各种功能以某种方式实体化或具体化，以此来设计测试用例，把产品的某些操作以场景的模式表现出来，以此简化被测系统的功能点或业务流程，从而提高相关的测试效率及效果。场景法类似程序中的二叉树的遍历方式，一般的方式按照逻辑从软件程序入口开始，按照给定的路径遍历所有的基本流和备用流来完成整个场景。图 2-1 所示为场景法基本情况的一个实例。
图 2-1 基本流与备选流
如图 2-1 所示的场景包括了一个基本流和相关的其他 4 个备选流，而且通过场景法可以把每一种可能经过的路径组成不同的用例。表 2-1 从基本流开始，阐述了基本流和相应的备选流结合起来形成测试用例的过程。
表 2-1 备选流
场景法不但为如何处理事务流提供了基本的方法指导，而且能全面地分析测试流，从而使测试更为全面地覆盖产品或软件的功能，由此可见，备选流在测试用例设计时起了至关重要的作用。
2.2.2 等价类划分法
等价类划分法是典型的黑盒测试用例设计方法之一。在软件的输入或输出域中，把它们其中用于相同特征的数据归纳为有效或无效两个方面，同时又因为有效或无效的测试集非常庞大，通常无法穷举，所以在设计测试用例时只能从有效或无效的数据中选取一些代表来参加测试，这样就得到了等价类（相同集合的部分代表），所以说等价类是输入域的集合。等价类划分为以下两种。
（1）有效等价类划分
有效等价类是指对于被测程序规格说明来说是合理的、有意义的可能输入数据所构成的集合。
（2）无效等价类划分
无效等价类是指那些和有效等价类相反，对于软件规格说明来说没有任何实际意义的、不合理的输入数据的集合。
综上所述，等价类划分的办法就是把程序的输入集合域等价地划分成若干个部分子集，然后再从每个部分集合之中选取少量的具有代表性的数据当作测试用例。每一类的代表性数据在测试中的作用等价于这一类数据中的其他值，也就是说，如果其中某类中的测试用例或者数据的某一个例子发现了错误，这一等价类中的其他测试数据和案例也有可能会出现同样的错误。
2.2.3 边界值分析法
边界分析是指利用测试数据域的边界值进行测试的一种测试方法。较多的测试经验表明，很多程序错误都是发生在输入或者输出范围边界上，而不是发生在输入与输出集合许可接受的范围内。如果针对被测试产品的各类边界情况来设计测试用例，则可能查出更多的软件错误或缺陷。
基于边界值分析方法的几种可供选择的原则如下。
（1）想象值：取刚刚达到这个范围边界的值（边界点），或刚刚超过这个范围边界的值点（B）作为测试输入数据，如图 2-2 所示。
（2）如果规定了值的个数（如 5 个）边界，那么用最大个数（5）、最小个数（1）、比最小个数少 1（0）、比最小个数多 1（2）、比最大个数少 1（4）、比最大个数多 1（6）这 6 个数作为选择测试数据（5，1，0，2，4，6）。
（3）如果某一程序的规格说明给出了某一功能的输入域（−1，0，1，2，3，…，98，99，100）或输出域（0，1，4，9，…，9 604，9 801，10 000）是有序集合，则应选取集合的第一个（1）或前几个元素（1，2，3）和最后一个（100）或最后几个（98，99，100）元素作为测试用例。
（4）如果被测试的程序中使用了这样的一个内部数据结构（如数组 a[10]），那么则应选择这个内部数据结构边界上的值（a[0]或 a[9]）作为测试用例。
2.2.4 错误猜测法
错误猜测法可以理解为是以测试经验或测试直觉来推测程序中所有可能存在的各种错误的一种测试方法。在测试之前，应该先列举出程序中有可能发生的错误或者较为容易发生错误的地方或情况，以此来设计相应的测试用例。例如，在测试过程中发现在某一单元的测试时，曾出现过许多在模块中常见的错误，或是以前产品测试中曾经发现的类似错误等，这些就是测试者经验的总结。
以上介绍了黑盒测试常用的几种方法，但是这并不是黑盒测试的全部方法，黑盒测试还包括决策表法、正交表法、随机测试及特殊值测试等。根据不同的测试项目，可以灵活地选择其中一种或者是多种的组合来实施测试。
2.3 测试需求覆盖和测试覆盖
测试需求覆盖用来衡量测试用例满足测试需求，具体的公式如下
测试设计覆盖是针对测试完全程度的评测，通常用一个比例表示，具体的公式如下
众所周知，需求的测试覆盖是在相应的测试生命周期中都将可能要进行多次的评测，并且会在产品测试生命周期的里程碑处提供产品相应的测试覆盖的标识来标定测试覆盖。测试覆盖公式计算如下
其中，T 表示产品测试数，RFT 是产品测试的需求总数。
一般来讲，测试需求覆盖和测试覆盖都是要求覆盖率越大越好，但是通常在执行过程中，会根据测试产品以及测试任务的时间等进行适当的调整。
2.4 软件缺陷
软件缺陷又被称为软件 Bug，即计算机软件或程序中存在的影响正常运行的问题、错误，或隐藏的某些功能缺陷等。
IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，产品缺陷就是软件产品在开发或维护过程中存在的错误、缺陷或不足等各种问题；从产品外部看，产品缺陷就是产品系统所需要实现的某种功能的失效或违背。
对于每个测试项目，缺陷的定义会有所不同，使用上面的规则，则有助于在测试中区分不同的问题，定义出项目达成一致意见的软件缺陷。
2.4.1 软件缺陷的级别
不同等级的缺陷所造成的后果是不一样的，有的是灾难性的，而有的却仅仅是微不足道的小问题。通常来讲，问题越严重，其处理优先级就应该越高，目前，较为常用的级别可概括为 4 种级别，如表 2-2 所示。
2.4.2 导致软件缺陷的原因
有以下几种原因可以引入软件缺陷：
（1）产品规格说明书；
（2）产品设计方案；
（3）产品编写代码；
（4）其他。
以上 4 种原因引入缺陷的数量依次递减。
5.2.1程序编写错误
5.2.2编写程序未按照规定
5.2.3软件越来越复杂
5.2.4开发人员的态度
5.2.5测试人员的经验与技巧不足
5.2.6沟通上的问题
5.2.7需求变更太过频繁
5.2.8进度上的压力
5.2.9管理上的缺失
2.4.3 Bug 缺陷分类和分级
佳讯公司根据相关的行业法规及标准、指挥调度系统的相关特性要求以及 Bug 在调度系统中的影响程度将 Bug 缺陷进行分类和分级。
表 2-4 佳讯公司产品缺陷分级
佳讯公司对产品 Bug 类型进行分类，针对指挥调度产品的特点制定了与之相适应的 Bug 类型，以便更好地了解和把握系统的质量。主要的类型如表 2-5 所示。
表 2-5 佳讯公司 Bug 类型分类
5.3.1 功能不正常
5.3.2 难以使用的软件
5.3.3 未做良好规划的软件
5.3.4 所提供的功能不足
5.3.5 与使用者的互动
5.3.6 使用性能太差
5.3.7 未做好错误处理
5.3.8 边界错误
5.3.9 计算错误
5.3.10 使用一段时间所产生的错误
5.3.11 控制流程的错误
5.3.12 在压力之下所产生的错误
5.3.13 不同硬件设备所产生的错误
5.3.14 版本控制不良所产生的错误
5.3.15 文件的错误（软件所附带的说明文档）