软件测试复习要点

1. 第1章《软件测试概述》

 

软件过程模型：

瀑布过程模型（是一种线性思维的体现）

螺旋过程模型（依据前一个版本的结果构造新的版本）

增量过程模型（用一种几乎连续的过程小幅度推进项目）

快速原型过程模型（在设计人员和用户的紧密配合下，快速确定软件系统的基本要求，尽快实现一个可运行、功能简单的原型系统，然后不断扩充完善得到最终的软件系统）

敏捷过程模型（迭代式增量软件开发；把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，并且过程中软件一直处于可用状态）

 

软件缺陷与软件故障定义：

软件缺陷：是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差。

软件缺陷的结果：软件运行于某一特定条件时出现软件故障，此时称软件缺陷被激活。

软件故障：是指软件运行过程中出现的一种不希望或不可接受的内部故障，此时若无适当措施加以及时处理，便产生软件失效。

 

1. 第2章《软件测试计划》

 

软件测试计划的作用：

        1、是软件测试工作进行更顺利；

        2、增进项目参加人员之间的沟通；

        3、及早发现和修正软件规格说明书的问题；

        4、使软件测试工作更易于管理

 

软件测试计划的组成部分：

测试计划标识符、简要介绍、测试项目、测试对象、不需要测试的对象、测试方法（策略）、测试项通过/失败的标准、中断测试和回复测试的判断准则、测试完成所提交的材料、测试任务、测试所需要的资源、测试人员的工作职责、人员安排与培训需求、测试进度表、风险及应急措施、审批

 

1. 第3章《软件测试基本技术》

 

测试用例的定义：

测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。测试用例是执行的最小实体。简单地说，测试用例就是设计一个场景，使软件程序在这种场景下，必须能够正常运行并且达到程序所设计的执行结果。

 

静态测试与动态测试区别：

静态测试是一种不通过执行程序而进行测试的技术，其关键功能是检查软件的表示和描述是否一致，没有冲突或者没有歧义。它瞄准的是纠正软件系统在描述、表示和规格上的错误，是任何进一步测试的前提。

而动态测试需要软件的执行，当软件系统在模拟的或真实的环境中执行之前、之中和之后，对软件系统行为的分析是动态测试的主要特点。它显示了一个系统在检查状态下是正确还是不正确。

 

黑盒测试和白盒测试为本课程重点，一定要重点理解并全部掌握；

黑盒测试：（又叫功能测试或数据驱动测试）已知产品的功能设计规格和用户手册，可以进行测试证明每个功能是否实现、每个实现了的功能是否符合要求，以及产品的性能是否满足用户的要求。 

软件的黑盒测试意味着测试要在软件的接口处进行

测试人员完全不考虑程序内部的逻辑结构和内部特性，

只依据程序的需求规格说明书和用户手册

检查程序的功能是否符合它的功能说明，以及性能是否满足用户的要求。

 

黑盒测试主要为了发现以下错误：

    1. 是否有不正确或遗漏的功能？
    2. 在接口上，输入是否能正确的接受？能否输出正确的结果？
    3. 是否有数据结构错误或外部信息（例如数据文件）访问错误？
    4. 性能上是否能够满足要求？
    5. 是否有初始化或终止性错误？

 

 

 

白盒测试：（又叫结构测试或逻辑驱动测试）已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。

白盒测试是对软件的过程性细节做细致的检查

白盒测试允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例

对程序所有逻辑路径进行测试，通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。

 

白盒测试须对程序模块进行如下检查：

     1. 保证一个模块中的所有独立路径至少被使用一次

     2. 对所有逻辑值均测试true和false。

     3. 在循环的边界和运行的界限内执行循环体。
     4. 检查内部数据结构以确定其有效性。

 

 

黑盒测试里的等价类划分法重点掌握；

等价类：指某个输入域的子集。

使用等价类划分方法时，是把所有有可能的输入数据，即程序的输入域划分为若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。

有效等价类：是指对于程序规格说明来说，是合理的、有意义的输入数据构成的集合。利用它可以检验程序是否实现了规格说明预先规定的功能和性能。

 

无效等价类： 是指对于程序规格说明来说，是不合理的、无意义的输入数据构成的集合。利用它，可以检查程序中功能和性能的实现是否有不符合规格说明要求的地方。

等价类划分方法：

① 按区间划分

② 按数值划分

③ 按数值集合划分

④ 按限制条件划分

⑤ 按限制规则划分

⑥ 按处理方式划分

 

黑盒测试中的边界值分析法：

边界值分析法是通过选择等价类边界的测试用例进行测试

边界值分析法与等价类划分法的区别是边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。

另外，边界值分析不仅考虑输入条件边界，还要考虑输出域边界产生的测试情况。

 

白盒测试中的逻辑覆盖、条件覆盖需要重点理解；

逻辑覆盖：

白盒测试主要的动态测试方法之一；

是以程序内部的逻辑结构为基础的测试技术；

是通过对程序逻辑结构的遍历实现程序的覆盖；

这一方法要求测试人员对程序的逻辑结构有清楚的了解。

逻辑覆盖中包含语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖

条件覆盖：构造一组测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次。

 

灰盒测试与黑盒测试及白盒测试的区别：

灰盒与黑盒：

黑盒测试关心的是整个软件系统的边界，无需关心软件系统内部各个模块之间如何协作；

灰盒测试关心模块与模块之间的交互。

灰盒与白盒：

灰盒测试中，还是无需关心模块内部的实现细节。对于软件系统的内部模块，灰盒测试依然把它当成一个黑盒来看待；

而白盒测试则不同，还需要再深入地了解内部模块的实现细节。

 

1. 第4章《软件测试过程》

 

单元测试->集成测试->系统测试->验收测试->回归测试

单元测试：

对软件设计中的最小单元——模块进行正确性检验的测试工作，主要测试模块在语法、格式和逻辑上的错误，一般由开发设计人员本身完成，一般由开发组在组长的监督下进行，由编写该单元的开发设计者设计所需的测试用例和测试数据，来测试该单元并修改缺陷。

 

单元测试的重要性体现在下面几个方面：

(1) 时间方面

(2) 测试效果方面

(3) 测试成本方面

(4) 产品质量方面

 

单元测试的原则：

(1) 单元测试越早进行越好

(2) 单元测试应该依据《软件详细设计规格说明》进行

(3) 修改过的代码应重做单元测试，保证对已发现错误的修改没有引入新的错误；

        (4) 测试人员应如实记录实际的测试结果

(5) 单元测试应注意选择好被测软件单元的大小

(6) 一个完整的单元测试说明应该包含正面测试和负面的测试

(7) 注意使用单元测试工具

 

单元测试的主要任务：

1.模块接口测试

2.模块局部数据结构测试

3.模块中所有独立执行路径测试

4.各种错误处理测试

5.模块边界条件测试

 

在进行单元测试时，需设置若干辅助测试模块。辅助模块有两种：驱动模块（Driver），用以模拟被测试模块的上级模块；被调用模拟子模块（Sub），用以模拟被测模块工作过程中所调用的模块。

 

用于单元测试的主要技术：

  1.静态测试

  2.动态执行测试

  3.状态转换测试

 

 

集成测试：

将经过单元测试的模块按设计要求连接起来，组成所规定的软件系统的过程称为“集成”。

 

 

集成测试的主要任务：

① 将各模块连接起来，检查模块相互调用时，数据经过接口是否丢失。

② 将各个子功能组合起来，检查能否达到预期要求的各项功能。

③ 一个模块的功能是否会对另一个模块的功能产生不利的影响。

④ 全局数据结构是否有问题，会不会被异常修改。

⑤ 单个模块的误差积累起来，是否被放大，从而达到不可接受的程度。

 

       集成测试的具体内容：

(1)功能性测试

(2)可靠性测试

(3)易用性测试

(4)性能测试

(5)维护性测试

       集成测试的人员：

              一般从开发组中选出，在开发组长的监督下进行，在集成测试的过程中，测试过程

由一个独立测试观察员来监控测试工作，并应考虑邀请一个客户代表非正式观看集

成测试。

       集成测试的原则：

① 所有公共接口都要被测试到。

② 关键模块必须进行充分的测试。

③ 集成测试应当按一定的层次进行。

    ④ 集成测试的策略选择应当综合考虑质量、成本和进度之间的关系。

    ⑤ 集成测试应当尽早开始，并以总体设计为基础。

    ⑥ 在模块与接口的划分上，测试人员应当和开发人员进行充分的沟通。

⑦ 当接口发生修改时，涉及的相关接口必须进行再测试

⑧ 测试执行结果应当如实记录。

 

非增量式集成测试：

采用一步到位的方法来进行测试，即对所有模块进行个别的单元测试后，按程序结构图将各模块连接起来，把连接后的程序当做一个整体进行测试

 

增量式集成测试方法：

1.自顶向下

自顶向下测试表示逐步集成和逐步测试是按结构图自上而下进行的。即模块集成的顺序是首先集成主控模块（主程序），然后按照软件控制层次结构向下进行集成。

2.自底向上

自底向上增式测试是从最底层的模块开始，按结构图自下而上逐步进行集成和测试。

 

系统测试：

集成测试通过后，软件已经组装成一个完整的软件包，这时要进行系统测试。

系统测试完全采用黑盒测试技术，因为这时已不需要考虑组件模块的实现细节，而主要是根据需求分析时确定的标准检验软件是否满足功能、行为、性能和系统协调性等方面的要求。

系统测试一般要完成的测试：

1.功能测试                                          2.性能测试

3.系统可靠性、稳定性测试                  4.系统兼容性测试

5.恢复测试                                          6.安全测试

7.强度测试                                          8.面向用户支持方面的测试

9.其他限制条件的测试

 

       系统测试的人员：

系统测试由独立的测试小组在测试组长的监督下进行，测试组长负责保证在合理的质量控制和监督下使用合适的测试技术执行充分的系统测试。

在系统测试过程中，测试过程由一个独立测试观察员来监控测试工作。

系统测试过程也应考虑邀请一个用户代表非正式地观看测试，同时得到用户反馈意见并在正式验收测试之前尽量满足用户的要求。

验收测试

验收测试是软件开发结束后，用户对软件产品投入实际应用前，进行的最后一次质量检验活动。它要回答开发的软件产品是否符合预期的各项要求，以及用户能否接受的问题。

验收测试主要是验证软件功能的正确性和需求的符合性。

验收测试完全采用黑盒测试

验收测试完成的主要测试工作：

1. 配置复审

      2. 合法性检查

      3. 软件文档检查

      4. 软件代码测试

        5. 软件功能和性能测试

      6. 测试结果交付内容

 

验收测试中的α测试及β测试

α测试是在软件开发公司内模拟软件系统的运行环境下的一种验收测试，即软件开发公司组织内部人员，模拟各类用户行为对即将面市的软件产品（称为α版本）进行测试，试图发现并修改错误。

经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况，提出批评意见。然后软件开发公司再对β版本进行改错和完善。

所以，一些软件开发公司把α测试看成是对一个早期的、不稳定的软件版本所进行的验收测试，而把β测试看成是对一个晚期的、更加稳定的软件版本所进行的验收测试。

       验收测试的人员：     

验收测试一般在测试组的协助下，由用户代表执行。

测试组长负责保证在合理的质量控制和监督下使用合适的测试技术执行充分测试。

测试人员在验收测试工作中将协助用户代表执行测试，并和测试观察员一起向用户解释测试用例的结果。

 

       回归测试：

回归测试是指软件系统被修改或扩充（如系统功能增强或升级）后重新进行的

测试，是为了保证对软件所做的修改没有引入新的错误而重复进行的测试。

回归测试一般使用黑盒测试进行。

为了防止软件的变更产生无法预料的副作用，不仅要对内容进行测试，还要重复进行过去已经进行过的测试，以证明修改没有引起未曾预料的后果，或证明修改后的软件仍能满足具体的需求。

在理想的测试环境中，程序每改变一次，测试人员都重新执行回归测试，一方面来验证新增加或修改功能的正确性，另一方面测试人员还要从以前的测试中选取大量的测试以确定是否在实现新功能的过程中引入了缺陷。

 

回归测试的范围（测试用例的选择方法）：

（1）局限在修改范围内的测试

（2）在受影响功能范围内回归

（3）根据一定的覆盖率指标选择回归测试

 

              回归测试的人员：

由于回归测试一般与系统测试和验收测试相关，所以要由测试组长负责，确保选择使用合适的技术和在合理的质量控制中执行充分的回归测试。

测试人员在回归测试工作中将设计并实现测试新的扩展或增强部分所需的新测试用例，并使用正规的设计技术创建或修改已有的测试数据。

 

 

1. 第5章《测试用例设计》

 

测试用例的基本概念

测试用例是执行测试的最小实体，是为特定的目的而设计的一组测试输入、执行条件和预期结果。

简单地说，测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作，并且达到程序所设计的结果。

测试用例的作用

1. 有效性

2. 避免测试的盲目性

3. 可维护性

4. 可复用性

5. 可评估性

6. 可管理性

测试用例设计的基本原则

(1) 用成熟测试用例设计方法来指导设计

(2) 测试用例的正确性

(3) 测试用例的代表性

(4) 测试结果的可判定性

(5) 测试结果的可再现性

(6) 足够详细、准确和清晰的步骤

设计测试用例应注意的问题

（这里应该是注意不要出现以下问题）

(1) 把测试用例设计等同于测试输入数据的设计

(2) 强调测试用例设计得越详细越好

(3) 追求测试用例设计“一步到位”

(4) 将多个测试用例混在一个用例中

(5) 让没有测试经验的人员设计测试用例

 

测试用例的分类

白盒测试用例

软件各项功能的测试用例

用户界面测试用例

软件的各项非功能测试用例

对软件缺陷修正所确认的测试用例

测试阶段与测试用例关系列表

测 试 阶 段	测 试 类 型	执 行 人 员
单元测试	模块功能测试，包含部分接口测试、路径测试	开发人员
集成测试	接口测试、路径测试，含部分功能测试	开发人员，如果测试人员水平较高可以由测试人员执行
系统测试	功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试	测试人员
验收测试	对于实际项目基本同上，并包含文档测试；对于软件产品主要测试相关技术文档	测试人员，可能包含用户

 

 

与软件本身的生命周期一样，测试用例也需经过“设计”、“评审”、“修改”、“执行”、“版本管理”、“发布”、“维护”等一系列阶段。

 

1. 第6章《测试报告与测试评测》

 

软件缺陷：简单说就是存在于软件（文档、数据、程序）之中的那些不希望，或不可接受的偏差，而导致软件产生的质量问题。

 

一般只要符合下面条件之一的就叫软件缺陷：

软件未达到软件规格说明书中规定的功能；

软件超出软件规格说明书中指明的范围；

软件未达到软件规格说明书中指出的应达到的目标；

软件运行出现错误；

软件测试人员认为软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。

 

软件缺陷的种类：

（1）功能不正常

（2）软件在使用上不方便

（3）软件的结构未做良好规划

（4）功能不充分

（5）与软件操作者的互动不良

（6）使用性能不佳

（7）未做好错误处理

（8）边界错误

（9）计算错误

（10）使用一段时间所产生的错误

（11）控制流程的错误

（12）在大数据量压力之下所产生的错误

（13）在不同硬件环境下产生的错误

（14）版本控制不良所产生的错误

（15）软件文档的错误

 

软件缺陷的生命周期：

（1）测试人员找到并登记软件缺陷，软件缺陷被移交到程序修复人员。

（2）程序修复人员修复软件中的软件缺陷，然后移交到测试人员。

（3）测试人员确认软件缺陷被修复，关闭软件缺陷。

复杂的软件缺陷生命周期：