软件测试阶段复习

绪论

1.软件测试：软件测试是软件生命周期的一个独立阶段，在每个阶段都有相关的测试活动

第一章 软件测试基础

1.早期软件测试相当于调试

2.测试不单是一个发现错误的过程，而是软件质量保证的主要职能

3.测试是以评价一个程序或者系统属性为目标的任何一种活动。测试是对软件质量的度量

4.IEEE给出两个规范、约束的测试定义：

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

②分析某软件已发现和现存的，以及要求的条件之别（即错误）并评价此软件项的特性

5.软件测试的目的（3点）：

①最少人力、物力、时间找错

②分析测试发现的问题来发现软件过程缺陷从而改进。整理测试结果，修正软件开发规则，并为软件可靠性分析提供相关依据③对软件质量度量和评估

6.软件质量保证是贯穿软件项目整个生命周期的有计划和有系统的活动

7.软件测试是获取度量值的一种重要手段

8.确保软件项目过程遵循了对应的标准及规范要求且产生了合适文档和精确报告，目的是通过评价项目质量建立项目达到质量要求的信心

9.在执行软件产品评价时，确立评价需求的质量模型就是采用度量

10.评价依据/指导度量，度量依据/指导测试

11.软件质量保证和软件测试二者之间既存在包含有存在交叉关系

共同点：①尽力确保软件满足需求②都贯穿软件开发生命周期

不同点：①软件质量保证：测试避免错误以要求高质量并且还有其他方面保证软件质量

②软件测试：查找错误并改之，从而提供软件质量，关键是如何选择测试用例

二者包含内容区别：

12.软件测试分类

1）.按测试阶段或测试步骤划分（4类）：①单元测试②集成测试③确认测试④系统测试

注：确认测试又分为：alpha测试和beta测试

①单元测试：在软件测试完成编码后，首先进行单元测试：验证软件单元是否正确实现了规定的功能和接口等要求

②集成测试：在确认没有问题后，将软件单元组装在一起进行集成测试，验证软件是否满足设计要求

③确认测试（有效性，合格性）：按照测试方式又有alpha和beta测试

alpha测试：在开发方的场所，用户在开发人员的指导下对软件进行测试

测试是受控的，开发人员负责记录错误和使用中出现的问题（开发人员为主）

beta测试：测试是由软件的最终用户在一个或多个用户场所来进行的，开发人员通常不在现场，整个测试不被控制，用户记录下所有问题（用户为主）

④系统测试：最后使通过确认测试的软件与其他系统成分组合在一起，并使其在实际运行环境中运行，进行系统测试

2）按测试对象划分：①单元测试②部件测试③配置测试④系统测试

软件配置项是为配置管理而设计的并且能够满足最终用户功能的软件，在配置管理过程中作为单个实体对待

软件部件是构成软件配置项或系统的部分之一，在功能上或逻辑上具有一定的独立性，且可以进一步划分为其它部件

在设计人机界面时，应主要考虑因素：①响应时间②错误处理③用户求助机制

3）按测试技术划分：①静态测试②动态测试

②动态测试又分为：白盒测试和黑盒测试

白盒测试（5类）：覆盖测试，域测试，程序变异测试，路径测试，符号测试

黑盒测试（4类）：功能测试，强度测试，边界测试，随机测试

 

 在不同的阶段对不同对象的测试包含不同的测试项目，对各阶段和对象的测试完整性要求也不同

13.ISO对质量的定义：一个实体的所有特性，基于这些特性可以满足明显或隐含的需求。就是实体基于这些特性满足需要的程度。

质量定义包含要素：实体+特性集合+需求

软件质量就是：软件与明确地和隐含地定义的需求相一致的程度（无论明确还是隐含的定义软件都要与之一致）

14.如何评价软件质量（两方面）：①静态质量特性②动态质量特性

①静态质量特性：结构化，可维护，可测试代码，正确完整的文档

②动态质量特性：正确性，可靠性，完整性，一致性，易用性，性能

15.影响软件质量的要素：①流程、②技术、③组织。还要兼顾成本和进度

①流程：来源于成功的经验，减少弯路，提高软件质量。还对项目成本和进度控制有很大帮助

②技术：编码技术产生正确高效的代码，测试是保证软件的最后一道防线

③组织：技术载体

需求是项目的灵魂

软件质量是设计出来的

16.软件质量是软件的生命

17.评价软件质量：①软件需求符合②软件结构好③软件系统有友好的用户界面，软件生命周期各阶段文档齐全规范

18.软件质量模型中内部模型和外部模型的含义：

19.软件质量子特性：①功能性②可靠性③易用性④效率⑤维护性⑥可移植性

20.CMM认证：精髓在于，过程决定质量

21.CMMI：能力成熟度模型。有两个功能。第一，软件获取方法的改革。第二，建立一种从集成产品与过程发展出发、包含健全系统开发原则进行过程改进。

过程能力等级：1.初始级（不可控）2.可重复级（可以重复以前的过程）3.已定义级（标准化）4.已管理级（定量）5.优化级（改进）

22.软件质量管理体系：6Sigma（六西格玛）：强调制定极高的目标，收集数据以及分析结果

23.

24.软件质量活动：软件质量保证（SQA）、度量和测试

25.SQA与测试的关系：

SQA从流程方面保证软件质量

测试从技术方面保证软件质量

只进行二者其一不一定产生好的软件质量

26.度量：对事物属性量化表示

软件度量：对软件开发项目，过程及其产品进行数据定义，收集以分析的持续性定量化过程

度量的目的：

①提高生产率，缩短研发期，降低成本

②提高软件质量，提高满意度

③为持续改进提供量化指标和反馈

度量的作用：

①理解②预测③评估④改进

度量的过程：

①识别目标

②定义度量过程

③数据收集

④数据分析反馈

⑤过程改进

27.程序测试只能证明错误的存在，不能证明错误不存在

28.测试的复杂性：容易顾此失彼

①完全测试不现实

②软件测试有风险

③杀虫剂现象

④缺陷不确定性

29.测试的经济性的体现：①体现测试的重要地位②体系按照什么原则进行测试，以实现测试成本与测试效果的统一

影响测试费用因素：

①软件面向的目标用户②可能出现的用户数量③潜在缺陷造成的影响④开发机构的业务能力

30.黑盒测试的复杂性：黑盒测试—测试人员不考虑程序内部结构和内部特性，只根据规格说明书，设计用例，检查程序功。黑盒测试查出软件所有缺陷，只能采用穷举输入测试，有以下问题：①输入量太大②输出结果太多③软件实现途径太多

31.白盒测试的复杂性：允许人们检查内部结构，测试人员根据程序内部的结构特性，设计和选择用例。

32.白盒穷举弊端：

①即使每条路径测试都通过了，人不能保障没有故障。

②不能保证程序实现符合规格说明要求

③不可能查出因遗漏路径而出现的错误

④可能发现不了有关数据的故障

33.软件测试总目标：充分利用有限人力和物力，高效率、高质量地完成测试

34.测试的经济性原则：

①根据程序重要性和一旦发生故障造成的损失来确定它的测试等级

②认真研究测试策略，以便能开发出尽可能少的测试用例，发现尽可能多的软件故障

35.成功测试（2点）：①软件在所有（或足够多）测试数据上是正确的②数据是充分的，能够反应软件总体表现

36.先知者问题：检查软件在测试数据上行为的正确性

37.充分性问题：判断一个测试数据集和是否充分。在有限的测试输入数据空间来判断无限的软件运行空间行为。

38.软件测试使用经过设计的有限数据来测试软件

39.测试充分性准则：①谓词：用以判断一个测试数据是否充分②度量函数：赋予测试数据一个充分度

40.测试充分性准则是在测试之前，具有一下基本性质：

①空测试对任何软件测试都是不充分的

②有限性

③如果一个测试数据集对一个软件系统的测试是充分的，那么在增加一些测试用例也是充分的，这一特性为单调性

④复杂性：越复杂测试用例越多

⑤回报递减率：测试得越多，进一步测试所得的充分性增长越少

41.充分性公理：①非外延公理②多重修改公理③不可分解公理④非复合性公理

42.语句覆盖应用：在被测试后，程序中被执行到的可执行语句的比例

43.软件测试七原则：

①测试显示软件存在缺陷

②穷尽测试不可能

③测试尽早介入

④缺陷集群性（2/8原则）

⑤杀虫剂悖论：软件测试进行的越多，其程序免疫力越强

⑥测试活动依赖于测试内容

⑦没有错误是好是谬论

44.测试停止准则（5类）：

 第二章 软件测试策略

1.软件开发过程：软件开发与维护的工作流程和工艺流程

2.概念化阶段：愿景（规划）文档

愿景文档：项目的起源，项目目标，主要特性，功能范围，成功要素

3.需求分析：做什么。系统分析：怎么做

需求捕获的成果：需求采集卡

需求分析的成果：软件需求规格说明书

系统分析的成果：分析类图，鲁棒图，序列图（数据流图）

4.软件需求类型（2类）：功能需求和非功能需求（质量属性，约束）

5.软件开发过程模型：略（重复太多次了，软工的每个课都有）

6.单元测试：对软件基本组成单元测试，一般在代码完成后由开发人员完成，QA（质量保证）人员辅助。对象是：类、模块、组件、单元

7.多个被测模块之间的单元测试可以同时进行，提高效率。

8.单元测试的依据是软件的详细设计描述、源程序清单、编码标准等

9.单元测试目的：

①验证代码是否达到详细设计的预期要求

②发现代码中不符合编码规范的地方

③准确定位错误，以便排除错误

10.单元测试优点：在编码过程中进行（在所有测试之前），成本远小于集成测试and系统测试，效益更优

11.单元测试有一定的步骤，力争做到有计划、可重用

12.单元测试基本步骤：计划-＞设计-＞实现-＞执行-＞单元测试结果并提交测试报告

13.单元测试的环境构成：单元测试为编码步骤的附属成分，模块不是独立程序，自己不能运行，要靠其他部分调用和驱动，要为每个单元测试开发两个软件：①驱动模块②桩模块。

①驱动模块：代替被测单元上层模块。驱动模块接收测试数据，调用被测单元，就是将数据传递给被测单元。可将驱动模块理解为被测单元的主程序

②桩模块：存根模块，代替被测单元的子模块。设计桩模块的目的是实现被测单元的接口

 注：①进行单元测试，尽量避免开发驱动模块和桩模块。

②采用自底向上的方式开发可以避免开发桩模块，但当下层单元被改动后，则需要执行回归测试判断其上层单元是否需要修改

③对被测单元的彻底测试有时会被推迟到集成测试阶段完成。

14.如何构建单元测试的环境：

①构造最小运行调度系统，即构建被测单元的驱动模块

②模拟被测单元接口，即构建被测单元的桩模块

③模拟生成测试数据及状态，为被测单元运行准备动态环境

15.单元测试的对象是软件设计的最小单位--模块或函数，测试的依据是详细设计描述

16.单元测试的内容：①模块接口②局部数据结构测试③路径测试④错误处理测试（容错）⑤边界测试

17.边界测试：

①在n次循环的第0次、1次、n次是否有错误

②运算或判断最大最小值时是否有错误

③数据流、控制流中刚好等于、大于、小于确定的比较值时是否出现错误

18.单元测试类型（3类）：

①逻辑单元测试②集成单元测试③功能单元测试

19.单元测试应式应从各个层次来对单元内部算法、外部功能实现进行检验，包括对程序代码的评审和通过运行单元程序来验证其功能特性等内容。在测试用例的同时，应给出期望结果

20.在进行单元测试，常用的方法是采用白盒测试，辅之以黑盒测试。

21.由小到大、由简单到复杂排序：逻辑单元测试、集成单元测试、功能单元测试

22.断言：

①定义：简单的单元测试，判断一个语句、一个函数或对象的一个方法所产生的结果是否符合预期（是否为真）

②时机：错误处理代码——预期发生状况，断言——处理绝不应该发生的状况

               用断言来注解并验证前置条件和后置条件

               对于高健壮性代码，应先断言再处理错误

③应用场景：在功能代码开发阶段，逐步添加断言来判断是否获取自己想要的数据结果

                      在单元测试：测试这个功能片段的代码是否返回预期结果

                      自己提供接口供他人使用时：先断言使用者传递过来的参数是否符合要求，如果不符合要求，将以AssertionError的方式告知使用者

23.assertion（断言）就是程序中的一条语句，对一个布尔表达式进行检查，必须保证这个表达式是true，如果false，系统将给出警告或退出

assertion用于保证程序最基本、关键的正确性

assertion通常在开发和测试时开启。在软件发布后为了提高性能，assertion通常是关闭的

24.按阶段进行测试是一种基本的测试策略

25.集成测试的时机：单元测试完成后便进入集成测试

26.集成测试的对象：模块间的接口，接口之间的关系

27.集成特色的特点：

①单元测试具有不彻底性，对模块接口信息难以把控，只能依靠集成测试

②与系统测试相比，集成测试从程序结构出发，目的性、针对性更强，测试项发现问题的效率更高，定位问题的效率也更高

③集成测试能够模拟所有实际情况

④定位问题较快

28.集成测试关注点：

①模块连接，穿越模块接口数据是否丢失

②各子功能组合是否达到预期功能

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

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

⑤单个模块误差记类，是否会放大

29.

30.集成测试层次：

①子系统内集成测试（模块）②子系统间集成测试（可执行程序）

31.集成测试策略（关注的核心）：

①哪些模块是集成测试的重点

②模块接口进行检测的顺序

③应该使用哪种技术检测每个接口

32.集成测试就是在测试对象分析的基础上，描述软件模块集成（组装）的方式、方法。

33.集成测试方法（2种）：

①非增（值）式测试②增（值）式测试

①非增式测试：

定义：分别测试每个模块，再把所有模块设计要求放在一起结合成所要的程序

优点：简单，多个测试人员并行工作，对人物力利用率较高

缺点：必须为每个模块准备相应的驱动模块和辅助桩模块，成本高，一旦发现错误，难以定位和纠正

非增值式测试--大爆炸集成测试：

一种非增值式集成的一种方法，他把所有的系统组件一次性集合到被测系统中，不考虑组件之间的相互依赖或者可能存在的风险

优点：1）可以迅速完成集成测试，并且只要极少数的驱动和桩模块

2）多个测试人员可以并行工作，对人力、物力资源利用率较高

缺点：1）发现错误时，定位和修改比较困难

2）许多接口错误很容易躲过测试而进入系统测试

②增值式测试：

定义：又称渐增式组装。首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装过程中边连接边测试，以发现连接过程中产生的问题。通过增值逐步组装成为要求的软件系统。

优点：相对非渐增，可以较早发现模块间的接口错误；发现问题也较容易定位

缺点：测试周期较长，同时投入的人力、物力受限

自顶向下：

特点：①从主控制模块（主程序）开始，沿软件控制层向下移动，从而逐渐把各个模块结合起来

②不需要驱动模块

③可以使用深度优先或宽度（广度）优先来组装

自顶向下适应范围：产品控制结构比较清晰稳定，产品高层接口变换比较小，产品底层接口未定义或经常可能被修改，产品控制模块有较大技术风险，需要尽早被验证

自底向上适用范围：底层接口较稳定，高层接口变换比较频繁

对软件结构中较上层：自顶向下；对软件结构中较下层：自底向上。两者相结合

34.软件开发是一个自顶向下，逐步细化的过程。软件计划阶段定义软件作用域；而测试过程是依相反顺序自底向上，逐步集成的过程。

35.软件测试和软件开发过程和软件质量保证（QA）密切相关

36.软件开发过程：生产软件产品所用的工具、方法和实践过程的集合

37.软件产品的组成（7个）：投入，客户需求，产品说明，设计文档，测试文档，开发进度，软件产品的其他组成部分

38.全新的软件开发模式：以测试驱动软件开发。这种思想与软件质量保证的出发点是一致的

39.资源规划阶段需求：产品阶段，需求分析

40.软件设计阶段测试：

将软件需求转化为语言文字和图表。设计分为外部设计和内部设计。或高层设计（概要设计）和低层设计（详细设计）

外部设计：用户角度描述；内部设计：产品内部机制。二者并行展开，相互制约要求，

概要设计：总体包含的组成元素，各模块的关联

详细设计：各模块如何实现以及算法和数据结构

对象：需求规格文档

内容：审核通过，编写测试文档

设计阶段要对软件的需求深化理解和完善

41.软件开发阶段测试：

42.软件需求与建模阶段：测试相关文档资料

     概要设计与详细设计阶段：用静态测试方法，对文字、图表测试

     在编码工作阶段：静态与动态相结合，采用各种覆盖方法测试

     在测试阶段：集成测试采用灰盒测试（接口，各模块间关系），系统测试采用黑盒测试（功能、性能）

     在检验交付与维护阶段：自动化测试工具（包括功能、性能、回归、发布）

43.螺旋模型与测试：第n+3步为测试

44.V模型的软件测试策略（2种）：低层测试，为了源代码的正确性；高层测试，为了整个系统满足用户。反映了测试活动与分析设计的关系。

45.W模型：不支持迭代

46.H模型：测试活动完全独立

47.P模型：反复交替，验收测试和技术测试保持独立

48.模型总结：

V模型：强调级别。每一个级别都与一个开发级别对应

W模型：强调测试计划的先行核对系统需求和系统设计的测试

H模型：强调测试独立

X模型和P模型：在此基础上增加了许多不确定因素处理情况

49.测试用例的规格说明（2步）：

定义逻辑测试用例

选择实际输入，将逻辑测试用例转化为具体测试用例

50.测试执行的包括：①手动测试②自动化测试

①手动测试优点：比较实际结果和测试用例的期望结果

②自动化测试优点：管理较容易，测试工具会完整执行脚本，可以自动记录下测试结果

51.执行测试流程：完整性测试-＞主要功能运行测试-＞其他测试

52.测试出口准则的评估：检验测试对象是否符合预定义的一组测试目标和出口准则的活动

 测试出口准测包括：测试覆盖率，失效发现率（缺陷发现百分比）

53.开销因素：时间+成本

54.测试活动结束：测试全部结束，并不意味着测试项目结束。测试的全部完成以后需要做的工作：①处理遗留活动②编写测试报告或质量报告③检查分析测试计划、测试设计和测试执行，完成项目总结，编写总结报告。

第三章 黑盒测试与测试用例设计

1.测试用例（TC）：通过软件用例测试可以将软件的测试行为转换为可管理的、具体量化的模式，是的软件测试是有组织性、步骤性和计划性的。

2.测试用例构成设计和制定设计的基础

3.判断测试是否完全：主要评测方式是基于需求的覆盖

4.影响软件测试的要素：过程，对象

5.测试用例：在测试执行之前设计的一套详细设计方案：包括测试环境、步骤、数据和预期的结果.测试用例是执行的最小实体。软件测试的关键步骤是设计有效测试用例

6.测试用例的作用：

①估算测试工作量

②减少回归测试复杂度

③软件更新后，只需修正少量的测试用例便可开始测试工作，降低工作强度，缩短项目周期

④方便书写软件测试缺陷报告

⑤可以根据测试用例执行等级，实施不同等级的测试

7.好的测试用例：

8.软件测试用例的特性：

①有效性②有代表性③可复用性④易组织性⑤可评估性⑥可管理性

9.影响软件测试用例要素：

①需求目标②用户实际使用场景③软件规格需求说明④测试方法对测试用例的设计影响很大⑤测试对象

10.实际软件测试用例原则：保证测试用例明确性、代表性、简洁性

11.设计软件测试用例的原则（指导）

12.软件测试用例设计指导思想：

13.测试用例的组成元素：

①用例编号：每个测试用例有唯一编号：项目名称+测试阶段类型（系统测试阶段）+编号：PROJECT1-ST-001

②测试标题：测试用例用途

③测试模块：指明测试用例用来测试哪些项目、子项目或软件特性

④用例级别：与软件需求级别一致

⑤测试环境：执行测试用例所需的硬软件环境

⑥测试输入：用来执行测试用例的输入要求

⑦执行操作：执行测试用例所需的每一步操作

14.测试需求的特点：包含软件需求，具有可测试性。测试用例中的测试集与测试需求是多对一的关系，即一个或多个测试用例对应一个测试需求

15.设计测试用例的关键点：确定测试套件；对每一个测试套件确定一个或多个基本流程和可选流程；针对每一个测试场景，确定一个或多个测试用例；增加测试数据，完成测试用例

16.测试用例是“活”的，在软件的生命周期中不断更新和完善。

17.黑盒测试：功能测试或数据驱动测试。在完全不考虑内部结构和内部特性的情况下进行

18.许多高层测试如确认测试、系统测试、验收测试都采用黑盒测试

19.黑盒测试优缺点：

优点：①针对性找问题，定位问题准确

②可证明产品是否达到用户功能与需求

③能重复执行操作

缺点：①需要充分了解技术，测试人员要有较多经验

②有很多手工操作

③测试人员需处理大量文档

20.黑盒测试用例设计的方法

21.等价类是指某个输入域的自己和。在这个集合中，各个输入数据对于解释程序中的错误都是等效的，或进行相同处理。

22.等价类划分定义：

将程序的输入域划分为若干给部分，然后从每个部分选取少数代表型数据当作测试用例。

23.等价类划分：①有效等价类②无效等价类

24.划分等价类标准：①完备测试、避免冗余②同一类标识（选择）一个测试用例

25.划分等价类步骤：先类型，再范围

26.等价类划分的原则：

①按照区间划分（一般有一个有效等价类和两个无效等价类）

②按照数值划分（一般有n个有效等价类和1个无效等价类）

③按照数值集合划分（一个有效一个无效）

④按照限制条件或规则划分（1个有效等价类，若干个无效等价类）

⑤细化等价类

27.等价类划分设计的步骤：

28.针对是否对无效数据测试等价类测试分为（2类）：①标准等价类测试（一般等价类测试），②健壮等价类测试

①一般等价类测试：1）不考虑无效数据值，测试用例使用每个等价类中的一个值

2）通常，标准等价类测试用例的数量和最大等价类中元素的数目相等

②健壮等价类测试：

29.弱等价类与强等价类：根据测试用例的完整性，分为：弱等价类测试、强等价类测试（是否对无效等价数据进行测试——）