软件工程之软件测试（考试复习篇）

• 软件测试概述

1. 理解软件危机，及其产生的原因。

软件危机：落后的软件生产技术难以满足增长的计算机需求。开发过程碰到的一系列问题。

产生原因：预算、速度、质量低、不能满足需求，混乱杂乱的，维护困难。

（2）软件测试定义：为了发现错误。

（3）软件质量属性，ISO9126。

功能性，可靠性，操作性，有效性，可维护性，移植性。

（4）软件缺陷、故障、失效？软件故障的十大类型

错误：开发人员生成的，主观的，导致软件一个或多个故障。

故障：源代码中存在的，可能是产品的一个或多个错误，会导致程序执行的失效。

失效：故障的症状，不正确的，软件规范外的行为，故障可能隐藏直到条件满足时，软件执行失效表示出来。

故障十大类型：算法、语法、计算与精度、文档、压力和负荷、容量和边界、时序统筹协调、处理能力、恢复能力。

（5）故障率，不同阶段的分析

不同于硬件的浴盆曲线（早期死亡—正常使用—固有磨损期）

受制于软件的升级更新带来故障，外部软件环境变化带来故障，如操作系统的更新、直到修改再升级，而且是循环往复。

软件不再支持，软件离开市场故障率稳定下来。

（6）测试的理由need for testing

需求：用户需求；软件行为描述；设计难度；实现难度；修改、维护难度。

（7）软件验证与确认，V&V？

验证：我们正确的构造产品了吗？是否正确的做事，验证开发过程是否遵守一定义好的内容，验证产品满足规格设计说明书的一致性。
确认：我们构造了正确的产品吗？是否在做正确的事，验证产品所实现的功能是否满足用户的需求。

（8）测试的四个阶段：单元、集成、系统、验收。

（9）穷尽测试的不可能性

long bound(int lower, int x, int upper){

// return a value of x bounded by the upper and lower values

// return lower if x<=lower

// return upper if x>=upper

// return x if lower<x<upper

}

（10） When to finish testing

1）预算角度：时间，成本；2）活动角度：软件通过了所有的计划的阶段；3）风险管理角度：故障率达到质量标准。

第二章、软件测试原理principles of software testing

（1）动态与静态测试的主要区别：是否执行代码。

（2）测试用例，测试用例的三要素（ID，input，expected output）

（3）黑盒、白盒测试的测试用例和测试数据只能来自规范，白盒测试的测试用例来自于代码，测试数据来自于代码和规范。

（4） Errors of “Omission”and “Commission"，两种错误：一种是委托错误，对不该回应的进行回应或给出/产生错误；一种是遗漏错误，应该回应的时候没有回应。

（5）测试方法/途径（黑盒测试、白盒测试、变异测试）

（6）测试活动Test Activities

输入（选择测试技术、分析规范和代码、确认测试用例、详述测试数据）

输出（输出分析、测试用例、测试数据、测试代码）

（7）软件规范分析（黑盒）

1、等价类分析（原则），参数的每个值在一个等价类中； 一个值不能在两个等价类中； 参数范围指定了等价类的上下限。

2、边界值（每个等价类分区有上下两个边界值）

3、值组合： 程序处理基于输入值或输入的组合值，复杂组合的处理很可能导致故障，需要分析用于生成测试用例。因果图、决策表。组合的分包括：标识不同输入组合（因）和关联的输出（果），基于软件程序规范，因果使用布尔表达式（谓词，∀xP(x)，∃xS(x)）描述。创建真值表，标识可能组合的最小集，用于测试程序的不同行为。布尔表达式（谓词逻辑）描述“因、果”，因的组合是程序的输入，程序会产生特定的输出。 因果组合用二进制图或真值表描述了相互关系，并创建测试用例覆盖所有的因果组合。

（8）软件组件分析（白盒测试）

1、CFG，控制流图（顺序，选择，循环）

2、判定和条件，判定是布尔表达式的组合，条件是单一的布尔表达式。多个条件组成了一个判定。例如，flag && (x<0)，是一个判定，它包含了两个条件：flag 和(x<0)。

（9）错误植入

（10）测试的产出结果

第三、四章、测试

（1）黑盒。等价类，边界值，组合测试，输入序列测试，随机数据生成，错误推测。

描述、测试用例、测试数据、说明、优缺点。

第五章、静态验证

5.1****设计评审

A design review provides the opportunity to verify that the design for software is correct before it is implemented. The design may be at a high/architectural level, or at a detailed level. The purpose of the review is to ensure that the design allows the software to fulfill its goals.

Using UML, there are two similar approaches to this, both based on following the trail of execution for each use scenario.

设计评审提供了在软件设计实施之前验证其正确性的机会。设计可以是高/建筑级别，也可以是详细级别。评审的目的是确保设计允许软件实现其目标。

使用UML，有两种类似的方法，都是基于跟踪每个使用场景的执行轨迹。

5.1.1 Informal Walk-through(informal，走查) 第一种是走查，团队成员在其中扮演不同对象的角色，执行的轨迹是从输入刺激到输出响应。重点是确保所有正确的对象和关系都到位，以便完成场景。这通常是一项非正式活动，只记录所需的更改以供将来采取行动。重点是尝试发现故障，而不是验证简单场景是否有效。

5.1.2 Formal Design Review(formal，评审)

正式审查的好处是，记录执行跟踪通常会导致在审查之前发现并修复大多数问题，并且有书面审查记录，这两种记录都会导致更高质量的产品。

缺点在于准备和运行审查所需的时间和精力。

此表单更适用于具有高质量要求的软件，如任务关键型、生命关键型系统。

*5.2***静态代码分析 **

5.2.1Walk-throughs****走查

出席走查的人员包括：发言人（一般是代码编写者，也可以不是）、QA的检查询问人员、或项目管理人员。

实际的走查两种形式：

1）启动会议，检查人员提问发言人代码中不清晰不正确项，发言人应清晰回复；2）发言人应指导检查人员阅读文档，检查者可以因注释问题打断发言人。记录的错误等待后边修正，不必立即修改。

5.2.2Code Inspections

The Inspection has five formal stages:

• Stage 1 - Overview An overview document that details the product specifications/ design/code/plan is prepared by the person responsible for producing the product, the Designer. The document is distributed to participants.
• Stage 2 - Preparation The Tester must understand the document in detail. A checklist of fault types generally found in inspections ranked by frequency should be available to help concentrate their efforts.
• Stage 3 - Inspection At the meeting there is a walk-through of the document to ensure that each item in the checklist is covered. Figure 5.1 gives an example of a checklist (based on the Ganssle Group, Guide to Code Inspections, 2001). Any faults found are simply documented for later correction.
• Stage 4 - Rework After the meeting all faults and issues are resolved.
• Stage 5 - Follow-up The leader of the code inspection group must finally ensure that every issue has been resolved, and should produce a final report.
• 检查分为五个正式阶段：
• •第1阶段-概述由负责生产产品的人员（设计师）编制一份概述文件，详细说明产品规范/设计/代码/计划。该文件将分发给参与者。
• •第2阶段-准备测试人员必须详细了解文档。应提供按频率排序的检查中通常发现的故障类型清单，以帮助集中精力。
• •第3阶段-在会议上检查文件，以确保涵盖检查表中的每个项目。图5.1给出了一个清单示例（基于Gansle小组，《代码检查指南》，2001年）。任何发现的故障都会简单地记录下来，以便以后纠正。
• •第4阶段-会后返工，解决所有故障和问题。
• •第5阶段-跟进代码检查组组长必须最终确保每个问题都已得到解决，并应编制最终报告。
• 可重入代码(Reentry code)也叫纯代码(Pure code)是一种允许多个进程同时访问的代码。为了使各进程所执行的代码完全相同，故不允许任何进程对其进行修改。程序在运行过程中可以被打断，并由开始处再次执行，并且在合理的范围内（多次重入，而不造成堆栈溢出等其他问题），程序可以在被打断处继续执行，且执行结果不受影响。

第六章 面向对象测试

Encapsulation封装: encapsulation is an obstacle to testing封装是测试的障碍

Inheritance继承:构造函数很难测试，测试一个过度使用的方法可能很困难

继承：子类继承类的能力（属性和方法）和职责（规范），提供了一种定义良好的测试继承的方法。构造函数很难测试，但测试人员需要确保子类正确初始化继承的属性。此外，测试一个过度使用的方法可能很困难：因为它代表了对原始算法或功能的更改，所以可能无法重用超类测试。

Polymorphism多态性:使测试变困难，测试人员需确保所有可能的多态对象调用正确的方法。多态性：这可能导致代码难以理解，从而使测试变得困难。例如，超类中的微小更改可能会导致子类失败。或者，更难发现的是，子类中的微小更改可能会导致超类失败。此外，测试人员需要确保为所有可能的多态对象调用了正确的方法。

Message Sequence And State : Object state is changed by messages, which provides many possibilities for faults (corrupted state, an object in an incompatible state for a message) which need to be tested. However, state faults are hard to observe, and message sequences are not easy to track.

消息序列和状态：对象状态由消息更改，这为需要测试的故障（损坏状态、对象处于与消息不兼容的状态）提供了许多可能性。然而，状态故障很难观察到，消息序列也不容易跟踪。

6.3 Object Oriented Testing Models

Testing object-oriented software can be approached at five different levels, each with its own test “model".五个不同层次

6.3.1 Conventional Models（传统模型）方法在“类上下文”中进行测试。这意味着，除了向方法传递参数并检查返回值之外，可能还需要调用不同的方法来设置和获取属性，这些属性用作被测试方法的输入和输出。前面讨论过的白盒和黑盒单元测试技术可以应用于这些测试。

此外，许多白盒原则可以扩展到面向对象的环境中。例如，d-u对可用于派生方法内的测试用例、行级别的方法之间的测试用例（考虑属性的每个单独的d和u用法），或方法级别的方法之间的测试用例（每个方法都被视为d和/或u用法）。

6.3.2 Combinational Models（组合模型）

其中，一个类（即一个类中的方法）的响应不同，这取决于输入值的组合，而不是方法调用的顺序。这意味着要测试输入参数值的不同组合对类的影响。类的总体响应可以通过真值表来描述。“原因”将基于“setter”和“action”方法的输入参数值；影响将基于“getter”方法的返回值。然后，测试用例将基于规则。

使用组合模型的目的是确保类在不同的输入组合下正常工作

6.3.3 State Machine Models确保通过状态机的软件转换正常工作。并不是要确保每种方法在每种状态下都能正确工作，这是不同形式测试的主题。

6.3.4 Specification & Design Models通过一种语言来指定的，代表了系统的一个可测试属性。

6.3.5 Built-In-Test内部测试：封装会阻止外部测试软件访问内部状态或属性，因此将代码放置类中对面向对象软件有特殊好处。在（Java）提供支持时运行中打开或关闭检查。

第七章 集成测试、系统测试 测试用例是确保系统满足其规范。

1、集成测试：“Top-Down Integration Testing", ”Bottom-Up Integration Testing", or “Sandwich Testing".自上向下，自下而上，三明治测试。

1. TOP-DOWN:自下而上

优点：提供计划大纲，有助于尽早发现错误，让团队相信策划的正确性。】

缺点：很难模拟不同级别之间的交互，最后添加下层时可能需要重新测试上层。

2.BUTTOM-UP：自底向上，从终端开始。

优点：更了解底层模块的功能，对创建上层模块有更好的想法。

缺点：上层模块完成前很难想象工作系统，必须制作驱动程序，重要的用户交互模块在最后测试。

3.三明治集成：是上面两者的混合。

优点：顶层和底层可以并行测试，且减少对存根和驱动程序的需求；允许最终客户端在开发软件时查看和测试软件；可以更早发现需求误解。

缺点：规划更复杂达到最佳目标层较困难

4、系统测试，满足需求，规范

System Test Categories****：系统测试

Conformance Testing一致性:验证是否符合一组已发布的标准。

Documentation Testing文档测试:是否足以有效安装和运行软件。以打印形式、提示。

Ergonomic Testin人体工程学测试:验证系统的易用性。 自动验证字体大小等，也可手动。

Functional Testing功能测试: 验证系统的行为是否符合规定。测试的接口是系统接口，包括一个或多个：用户接口、网络接口、专用硬件接口等。

Interoperability Testing互操作性：验证是否可与其他软件产品交换和共享信息。

Performance/Load Testing性能/负载：验证软件的性能目标是否已达到。

Portability Testing 可移植性：是否可移植到其他操作环境。

Regression Testing回归：软件的修改有无与之前工作的软件带来新故障。

Release Testing发布：发布前是否正常运行不会干扰其他app或硬件。

Stress Testing超载：验证失效行为和暴露陷阱的应力测试。

Security Testing安全功能：故意破坏安全措施。

Safety Testing安全：故意在受控条件下易发问题，验证系统的响应。

5、现场测试，验收测试：

α测试，β测试：谁做？什么地点做，使用技术？做完后如何处理？

Alpha测试，是一种在组织内部由开发人员自己在开发站点内执行的验收测试。Alpha测试需要白盒和黑盒技术来进行测试Alpha测试是一种封闭测试，不向公众开放。测试后开发人员修改错误。 用户或第三方公司到开发现场模拟用户环境的测试

Beta测试，通常通常由客户或位于客户所在地(而不是组织内)的最终用户在实时环境中进行。 Beta测试仅需要黑盒测试技术甚至功能技术Beta测试也是针对公共测试的开放测试。 这也称为现场测试。测试后，提交测试报告。

对α版本进行α测试，生成β版本， 对β版本进行 β测试。

第八章 测试自动化

Some of the testing tasks that can be automated relatively easily are:

• Automated execution of tests, or collections of tests自动执行或收集测试

• Automated collection of results自动收集结果

• Automated evaluation of results自动评估结果

• Automated reports自动报告

• Automated measurement of test coverage测试覆盖率的自动测量

There are essentially two types of test that can be easily automated: unit tests, and system tests基本上有两种类型的测试可以很容易地自动化：单元测试和系统****测试。

第9章 软件过程的测试

软件过程：软件过程为一个为建造高质量软件所需完成的任务的框架，即形成软件产品的一系列步骤，包括中间产品、资源、角色及过程中采取的方法、工具等范畴。

软件生存周期：指软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到弃等阶段

软件过程模型：是一种开发策略，该策略针对软件工程的各个阶段提供了一套范形，使工程的进展达到预期的目的。

1、瀑布模型，原型化模型，增量模型，螺旋模型

2、面向对象模型：

3、敏捷过程模型：(1) XP模型。(2) 自适应软件开发。(3) 动态系统开发。(4) Scrum模型。(5) Crystal模型。(6) 特征驱动开发

极限编程方法的基本特征是：

1、增量和反复式的开发----一次小的改进跟着一个小的改进。

2、反复性，通常是自动重复的单元测试，回归测试。

3、结对程序设计

4、在程序设计团队中的用户交互（在场的客户）

5、软件重构

6、共享的代码所有权

7、简单

8、反馈

9、用隐喻来组织系统

10、可以忍受的速度

9.5.3 SCRUM

SCRUM is a process for managing complex software projects and is a technique of Agile software development. It is similar to XP but there are a number of differences:

Sprint 是 Scrum 的核心，其长度（持续时间）为一个月或更短的限时，这段时间内构建一个“完成”、可用的和潜在可发布的产品增量。在整个开发过程期间，Sprint 的长度保持一致。前一个 Sprint 结束后，新的下一个 Sprint 紧接着立即开始。

Sprint 由 Sprint 计划会议(8h)、每日 Scrum 站会(15min)、开发工作、Sprint 评审会议(4h)和 Sprint 回顾会议(3h)构成。

在 Sprint 期间：不能做出有害于 Sprint 目标的改变；不能降低质量的目标；以及，随着对信息掌握的增加，产品负责人与开发团队之间对范围内要做的事可能会澄清和重新协商。

补充部分：

1. 如何确定系统容量？软件测试中V&V是什么？
2. 
3. 优秀测试工程师应具备哪些素质？责任感，沟通能力，技术能力，自信心，洞察力。
4. 
5. 737MAX8事故推测如下，作为软件工程师和软件测试工程师，如何解释事故原因？737MAX机动特性增强系统MCAS，系统在飞机仰角过高时开始工作，压低机头防止飞机失速。737的仰角传感（AOA）数据有两个通道，任意一侧仰角数据大于失速临界仰角时系统就开始配平，系统自动启动，使飞机俯冲。此时飞行员发现后手动配平可以缓解，但是如果没有切断MCAS，那么当飞行员干预停止后5秒系统会再次接通，如此反复俯冲。简单来说，当AOA探测失误且MCAS系统开启时，飞机就可能会和飞行员“抢夺”飞机控制权。
6. 为提高系统的可靠性，一系统有2个相同的子系统并联构成，各子系统寿命服从指数分布，可靠度R为0.99，平均故障间隔时间MTBF为10万小时，求系统的可靠度R、失效率λ、MTBF。
7. 
8. 给定三角形问题的程序代码，（1）画出DD-路径图，计算复杂度V（G）；（2）使用边界值分析和最坏情况测试，分别分析漏洞和冗余；（3）假设s个元素的结构性测试，当执行m个测试用例时，会经过n个结构性测试元素，覆盖指标C=n/s，冗余指标R=m/s，纯冗余指标NR=m/n。分别计算边界值和最坏情况测试的C、R和NR。1： int a,b,c2： input(a,b,c)3： if (a<(b+c)) and (b<(a+c)) and (c<(a+b))4： if (a= =b) and (b= = c)5： outpur (“等边三角形”)6： else if (a= =b) or (b= =c) or (a= = c)7： output (“等腰三角形”)8： else output (“一般三角形”)9： else10： output (“不构成三角形”)
9. 
10.