原文地址

软件测试复习

对大三下学期的软件测试课程进行复习

第一章

计算机软件体系结构

软件体系结构是软件系统的结构、行为和属性的高级抽象，给出系统的组织结构和拓扑结构，规定系统需求和构成系统的元素之间的对应关系。

• Layered Architecture：n层模型，比如TCP\IP使用的那种。例子：Presentation Layer->Business Layer-> Persistent Layer-> Database Layer。核心思想是组件间的分离与功能上的聚合。
• Event-Driven Architecture：常用于异步通信架构，由高度解耦合且单一目的的事件处理组件所构成。
• MicroKernal Architecture：用于实现基于产品的应用的自然表示，即将大量第三方库插入进核心代码中。Core system提供了核心功能，plug-in module则可以是第三方库等能够轻松调换的代码。通过分离可以实现应用特性和具体实现的分离。
• Microservices Architecture：微服务架构，面向服务的架构。按照单元分解，采用分布式架构，一般具有统一的用户交互层。
• Space-Based Architecture：特定于解决扩展与并发问题。应用数据统一存储于内存中，同时通过扩展处理单元的方式实现应用处理能力的增加。

软件=程序+数据+文档+服务、 是能够完成预定性能和功能的、可执行的计算机指令。 软件需要有描述程序的操作和使用的文档。 1976: Algorithm+Data Structure = Programs

生产软件产品的基本步骤：软件规格说明、设计与实现、确认、演进。

软件开发方法：

• 面向数据流的结构化程序开发方法。指导思想是自顶向下，逐步求精；基本原则是功能的分解与抽象。很适合数据处理领域的问题。
• 面向数据结构的开发方法(Jackson方法)：描述问题的输入、输出数据结构，分析其对应性，设计相应的程序结构，从而给出问题的软件过程描述。以数据结构为驱动。
• 基于模型的方法，支持程序开发的形式化方法，把软件系统当作模型来给予描述，把软件的输入、输出看作模型对象，把这些对象在计算机内的状态看作该模型在对象上的操作。
• 面向对象的开发方法：指导思想是尽量按照人类认识世界的方法和思维方式来分析和解决问题。

第一章 1.2 软件工程生命周期

软件生命周期的6个阶段：

1. 可行性分析与计划阶段：确认软件开发的总体目标、估计可利用的开发资源，最后提交可行性分析报告。
2. 需求分析阶段：分析用户提出的要求
3. 设计阶段：概要设计/逻辑设计（把各项软件需求转换成软件的体系结构）、详细设计/物理设计（按照概要设计分解的每个模块所要完成的工作进行具体的描述）、提交概要结构设计说明书等文档
4. 实现阶段：完成源程序的编码、编译和运行调试、编写进度日报周报、测试计划、提交用户手册等
5. 测试阶段：全面测试目标软件系统，并检查审阅已编制的文档。
6. 运行与维护阶段：软件提交给用户后，在运行使用中得到持续的维护；改正性维护、适应性维护和完善性维护。

前五个阶段合称开发阶段。

软件生命周期模型

包括瀑布模型、VW模型、快速应用开发模型、原型模型、迭代模型、螺旋模型、喷泉模型、基于构建的开发模型、Rational统一过程模型、敏捷开发模型与极限编程。

瀑布模型

特征：

1. 本阶段活动的工作对象来自于上一项活动的输出。输出一般代表本阶段活动结束的里程碑文档。
2. 根据本阶段的活动规程执行相应的任务
3. 本阶段活动产出的相关的软件工件，作为下一阶段活动的输入。
4. 对本阶段活动执行情况进行评审。 优点：
5. 降低软件开发的复杂程度
6. 推迟软件实现，强调在软件实现前必须分析和设计工作
7. 以项目的阶段评审和文档控制为手段，有效对整个开发过程进行指导，保证阶段之间的正确衔接。 缺点：
8. 过于强调活动的线性顺序。
9. 缺乏灵活性，无法解决软件需求不明确或不准确地问题。
10. 风险控制能力较弱
11. 瀑布模型中的软件活动是文档驱动的，当阶段之间规定过多的文档时，会极大地增加系统的工作量。
12. 管理人员仅以文档的完成情况来评估项目完成进度，容易产生误判。

V模型

主要贡献：以测试为中心，明确标明了测试过程中存在的不同级别，并清楚地描述了这些测试级别与软件生命周期各阶段的对应关系。 局限性： 把测试作为编码之后的最后一个活动，会导致需求分析等前期阶段产生的错误直到后期的验收测试才能被发现，无法体现”尽早地和不断地进行软件测试“的原则。这会大幅地提高修补需求缺陷的成本。

W模型

W模型是V模型的演进，在开发中是一个V，在测试中是另外一个并行的V。基于”尽早地和不断地进行软件测试“的原则。 W模型强调测试是伴随着整个软件开发周期，而且测试的对象不仅仅是程序，同样也需要测试需求、功能和设计。 局限性： 将软件的开发视为需求、设计、编码等一系列按时间顺序串行的活动。无法支持迭代、自发性以及需求功能的变更调整。

快速应用开发模型

Rapid Application Development，能够使得开发小组在很短时间内创建出一个功能完善的系统。 优点：

1. 开发速度快，同时质量有一定保证。
2. 对管理信息系统的开发特别有效。 缺点：
3. 应用局限性：主要用于管理信息系统开发
4. 开发者和用户都需要在短时间内去完成一系列的需求分析，任何一方配合不当都会导致RAD项目失败。
5. 对模块化要求较高，如果存在不能被模块化的功能，那么构件会存在问题。
6. 技术风险很高的情况下，不能够使用RAD模型。

原型模型

线性顺序方法的局限：如果前一个阶段的工作无法完成，则后一个阶段的任务无法开始。而很多时候，开发者难以获得完成的系统需求规格说明。 原型方法：在获得一组基本需求后，通过快速分析构建出一个小型的软件系统原型，满足用户的基本要求。 这样，用户通过使用原型系统提出修改意见，从而减少用户与开发人员关于系统需求的误解，使需求尽可能的准确。 优点：符合人们认知事物的一般规律 缺点：大型系统难以使用。而且容易忽略文档工作，带来资源浪费、项目规划和管理困难等问题。

演化模型

两次开发。第一次试验开发，得到试验性的原型产品，目标在于探索可行性，确定软件需求。第二次产品开发，在原型产品的基础上获得最终软件产品。

迭代和增量模型

迭代开发是事前确定好要开发什么，然后一步步将其完成。 增量开发是事前并不确定开发出的制成品，一步步实现后补齐。 优点：降低失败风险、提高系统可靠性 缺点：建立初始模型的时候，需要确定基本业务服务。而且增量粒度难以确定。

螺旋模型

计划->风险分析->实现与测试->评估，如此反复。 主要针对大型软件项目的开发。 四个象限：

1. 确定目标：确定软件项目目标；明确对软件开发过程和软件产品的约束；制定详细的项目管理计划；根据当前的需求和风险因素制定实施方案，并进行可行性分析，选定一个实施方案，并对其进行规划。
2. 识别和解决风险：明确每一个项目风险，估计风险发生的可能性、频率、损害程度，并指定风险管理措施来规避这些风险。
3. 工程实现：针对每一个阶段的任务要求执行开发和测试活动。
4. 准备下一轮迭代：客户使用原型，反馈修改意见；根据客户的反馈，对产品及其开发过程进行评审，决定是否进入螺旋线的下一个回路。 优点：螺旋模型是风险驱动的迭代过程，结合了瀑布模型和快速原型方法，将项目的风险降低。同时每一次迭代只包含了瀑布模型中的某一个或两个阶段。

但是有一定的限制条件：

• 强调风险分析，但是外部客户并不一定接受风险，所以一般用于内部大型项目
• 风险分析需要额外的成本
• 失误的风险分析可能问题更加严重。

喷泉模型

喷泉模型是一个迭代模型。软件开发的各个极端是相互重叠和多次反复的，就像喷泉一样，水喷上去又可以落下去，既可以落在中间，又可以落到底部。 优点是可以提高开发效率、缩短开发周期 缺点是管理有一定的难度

构建组装模型

利用模块化思想讲整个系统模块化，并在一定构建模型的支持下复用构建库中的一个或多个软件构件，并通过组装过程高效率、高质量地构造软件系统。 优点是允许软件复用从而提高软件开发效率，同时允许多个项目同时开发，降低费用、提高可维护性，可实现分布提交软件产品。 缺点：缺乏通用的构建组装结构标准，带来较大的开发风险。构建可重用性和系统高效性之间不易协调；由于过分依赖构件，构件的质量影响着最终产品的质量。

RUP统一过程模型

Rational Unified Process，是一种基于UML的、以构架为中心、用例驱动与风险驱动相结合的迭代增量过程。 基本结构： 传统的瀑布模型是一个单维的时间顺序模型，开发工作被划分为多个连续的阶段。在一个时间段内，只能实施某一个阶段的工作比如分析、设计或实现。

• RUP是一个二维空间。时间维度从组织管理的角度描述整个软件开发生命周期，是RUP的动态组成部分，它可以进一步描述为周期cycle、阶段phase和迭代iteration
• 核心工作流程维度是从技术角度描述RUP的静态组成部分，它可以进一步描述为工作流workflow、角色worker、行为activities和产品/工件artifact。

时间维度： RUP中的软件生命周期在时间维度上被分解为四个顺序的阶段：初始阶段Inception、精化阶段Elaboration、构建阶段Construction和产品交付阶段Transition。每个阶段结束于一个主要的里程碑，并在阶段结尾执行一次评估以确定这个阶段的目标是否已经满足。

• 初始阶段：目标是为系统建立业务案例并确定项目的边界。确定项目边界需要识别所有与系统交互的外部实体，并在较高层次上定义外部实体与系统交互的特性，主要包括识别外部角色、识别所有用例并详细描述一些用例。
• 精细阶段：分析问题领域，建立健全的体系结构基础，编制项目计划，完成项目中高风险需求部分的开发。
• 构建阶段：完成所有剩余的技术构件和稳定业务需求功能的开发，并集成为产品，详细测试所有的功能。只是一个过程，重点放在管理资源以及控制开发过程以优化成本、进度和质量
• 产品化阶段/移交阶段：确保软件对最终用户是可用的。产品化阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量调整。

核心工作流程维度结构：

• 业务建模
• 需求
• 分析与设计
• 实施
• 测试
• 部署

RUP的迭代增量开发思想

软件复杂度分析

1. 规模：通常由总共指令数，或源程序行数表示。例如line count复杂度。基本的思想是统计一个程序模块的源代码行数。
2. 难度：通常由程序中出现的操作数的数据所决定的量表示。例如Halstead复杂度，使用操作符和操作数的量来衡量。设n1表示程序中不同的操作符个数，n2表示程序中不同的操作数个数，N1表示程序中操作符总数，N2表示程序中的操作数总数。可以计算出各种参数。
3. 结构：通常由与程序结构有关的度量表示。例如McCabe复杂度，包括环路复杂度、基本复杂度等。McCabe环路复杂度，数量上可以表现为程序控制流图，V(G)=m-n+2p，m是G的边数，n个G的点数，p是G的连通分支数。
4. 智能度：算法的难易程度。

白盒测试

定义：白盒测试按照程序内部逻辑结构和编码结构来设计测试数据并完成测试，是一种动态测试方法。

逻辑覆盖：以程序内部的逻辑结构为基础的一种白盒测试方法，建立在测试人员对程序的逻辑结构清晰了解的基础上，是一大类测试过程的总称。包括语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖、路径覆盖等。 DD-路径测试：Decision-to-Decision path，要求测试所有的路径。 路径测试：设计出足够多的测试用例，覆盖被测试对象中所有可能执行路径。

基本路径测试：在实际的应用中，即使是不大的应用，想要测试所有路径也是不现实的。在不能做到覆盖程序所有路径的情况下，如果能够对程序的每一个独立路径进行测试，那么可以认为程序中的每个语句都已经检验过或覆盖到。 基本路径测试在程序控制流图的基础上，通过分析McCabe环路复杂性，导出基本可执行路径集合，据此设计测试用例，保证在测试中程序的每一个可执行语句至少执行一次。 独立路径：至少沿一条新的边移动的路径。

黑盒测试

黑盒测试不考虑测试程序内部结构和处理过程，仅仅依据程序功能的需求规格设计测试用例，并推断测试结果的正确性。 黑河测试要求被测程序的特性或功能必须被一个测试用例或一个被认可的异常所覆盖，既要考察”程序是否做了应该做的“，也要考察”程序是否没有做不应该做的“。

方法： 一是等价类划分：完全不考虑被测程序的内部结构，只依据程序的规格说明来设计测试用例。会将所有可能的输入数据划分成若干部分，然后从每一部分中选取少数具有代表性的数据作为测试用例。 输入等价类即程序输入域的某个子集，该子集中，各个输入数据对揭露程序中的错误是等效的。 两种情况：

1. 有效等价类：对于程序规格说明来说是合理的、有意义的输入数据组成的集合。
2. 无效等价类：对于程序规格说明来说是不合理饿、无意义的输入数据组成的集合。

二是边界值分析法。先确定边界值情况，然后在正好等于、刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

三是错误推测法，依靠测试人员的经验和直觉对被测程序中可能存在的各种错误进行推测，从而有针对性地编写测试用例。

四是随机测试法，即从被测程序中所有可能输入值中随机选取，基本的黑盒测试方法。

五是判定表法，要使得各个条件都能充分满足。 六是因果图法，考虑被测程序输入条件之间的联系和组合关系。

灰盒测试

结合黑盒测试、白盒测试、回归测试和变异测试，是一种软件全生命周期测试方法。