软件测试基础知识

第一章

1.1 软件测试背景知识和发展史

1. 互联网公司职位架构：产品 运营 技术 市场 行政
2. 软件测试：使用人工或自动化手段，来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别（IEEE）。
3. 测试结果：1）找出缺陷和故障    2）显示软件执行正确

1.3测试的必要性

测试的必要性：1）避免金钱、名誉甚至生命损失 2）提高软件质量

软件测试开始时间：贯穿于软件生命周期始终，越早开始越好。

出现软件缺陷的时间：说明书，设计，编码，其他

软件缺陷修复费用，越晚费用越高。

1.4软件测试的目的和对象

软件测试目的：

1）测试者：通过软件测试暴露软件中隐藏的错误     和缺陷，以考虑用户是否可接受该产品。

2）开发者：希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的要求，确立人们对软件质量的信心。

软件测试的根本目的：1)发现\修改缺陷 2)满足需求提高用户满意程度 3)优化软件品质

软件测试对象：不是程序测试。需求规格说明、概要设计规格说明、详细                              设计规格说明以及源程序、用户文档。（程序、文档、数据）

1.8软件测试的原则

1. 测试原则：

1）尽早地和及时地进行测试

2）测试前应准备好测试数据和与之对应的预期结果

3）测试输入数据应包括合理是输入条件和不合理的输入条件

4）程序提交测试后，应当由专门的测试人员进行测试

5）严格执行测试计划，排除测试的随意性

6）测试用例的所有相关预期结果做全面的检查

7）充分注意测试当中的群集现象

8）保存测试计划、测试用例、出错统计和最终分析报告，为维         护工作提供充分的资料。

测试的补充原则：优化测试量

缺陷具有免疫性：每修补3-4 个bug，一般就会产生一个新的缺陷。

1.9软件测试误区

1. 误区一：软件测试技术比编程容易
2. 误区二：若发布的软件有质量问题，那是软件测试人员的错
3. 误区三：软件测试是测试人员的事，与开发人员无关
4. 误区四：根据软件开发瀑布模型，软件测试是开发后期的一个阶段
5. 误区五：有时间就多测试一些，来不及就少测试一些
6. 误区六：软件测试是非建设性的工作，甚至是破坏性的，测试中发现错误是对负责人工作的一种否定。

1.10软件开发过程及项目成员

软件开发项目过程：

（生命周期）：需求分析，系统设计，编码，实施，交付。

软件项目开发过程分解

1. 需求分析：深入了解客户需求，根据用户需要、个人经验及需求编写规范制定出《需求文档》， 需求文档需要经过评审，充分获取软件开发的范围、边界等具体问题的确认，且经相关部门评审合格即付诸后续工作
2. 系统设计：需求评审通过后，开发部组织人员根据《需求分析书》并结合编写规范进行系统设计（概要设计+详细设计），制定出详细设计方案。概要设计：系统的基本流程，系统结构，模块划分，功能分配，接口设计等； 详细设计：设计每个模块的实现算法、所需的局部数据结构，类的层次结构及调用关系。
3. 编码：系统设计完成后并经过评审通过后，开发人员依据《系统设计方案》并依据《代码编写规范》进行代码编制，实现各模块功能、性能、接口、界面等方面的需求。
4. 实施：软件编码完成后，并经过内部人员测试，由开发部组织人员依据测试完成的系统软件并结合软件系统实施规范进行软件实施，即正式部署到用户的生产运行环境上。
5. 交付及验收： 实施完成并经用户确认后，由质量保证部协助用户根据验收计划和验收规范来进行验收，验收完成后，提交验收报告，软件开发及实施全部完成，标志该项目完成。

软件项目成员及角色：项目经理、产品经理（专员）、软件开发人员、软件测试人员/QA、文档编写人员、配置管理人员。

1.11软件开发模型

1. 软件开发模型概述：软件开发的全部过程、活动、任务和管理的结构框架。它给出了软件开发活动各阶段之间的关系。
2. 开发模型分析

1. 大棒开发法 优点：思路简单，突发奇想 缺点：非工程化，随意性大，结果不可预知 测试：开发任务完成后，修复较困难。
2. 边写边改法 优点：简单考虑到软件需求，产品周期短 缺点：没有计划和文档的编制，后续维护难度大 测试：新版本不断产生，测试工作长期循环。
3. 快速原型法 根据客户需求在较短的时间内解决用户最迫切的问题，完成可演示的产品。这个产品只实现最重要功能，在得到用户的更加明确的需求之后，原型将丢弃。
4. 瀑布模型 特点：逐级下落 将软件生存周期各活动规定为依线性顺序连接的若干阶段的模型，包括需求分析、概要设计，详细设计、编码、测试和维护等阶段。 优点：易理解，阶段性，强调需求分析，明确测试阶段，提供了一套模版

5）螺旋模型法：

当前阶段开发和测试，明确并化解风险，确定目标、可选方案和限制条件，确定下一阶段方法，计划下一阶段，评估可选方案

优点：严格的全过程风险管理；强调各开发阶段的质量；提供机会评估项目是否有价值继续下去（发现问题早）

1.12软件测试模型

V模型

特点：瀑布模型的变种，反映了测试活动与分析、设计的关系。是最具有代表意义的测试模型。

优点：开发级别清晰，测试阶段对应。底层：单元测试。高层：系统测试。

缺点：线性执行——测试滞后编码

  关注程序——忽略需求、设计

  需求变更——实用性差

W模型=V模型+各阶段同步测试 （体现了尽早地和不断地进行软件测试原则）优点：W模型可以说是V模型自然而然的发展。它强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能、设计同样要测试。

缺点：在小的项目里面，W模型不适用，不支持迭代，应对需求变化方面不适用。

H模型 揭示出软件测试应尽早准备尽早执行。是一个独立的流程，贯穿于整个产品周期，与开发并行。

1.20软件测试流程

测试过程中基本测试活动

1. 拟定软件测试计划
2. 设计和生成测试用例（格式还是测试点）
3. 搭建测试环境
4. 实施测试
5. 测试评估
6. 测试总结

测试计划：阶段主要处于测试的前期准备工作阶段，在该阶段中主要是对将要进行的测试工作做整体计划安排。

测试计划制定：对需求规格说明书的仔细研究，将要测试的产品分解成可独立测试的单元，为每个测试单元确定采用的测试技术，为测试的下一个阶段及其活动制定计划。

测试开发与设计：开发：测试数据准备，测试脚本准备

设计：熟悉需求分析的基础上，测试用例

1. 测试用例文档：软件测试的依据，包括测试输入、测试步骤、预期结果等内容。本质：从测试的角度对被测对象的功能和各种特性的细化和展开。好处：（1）保证测试功能不被遗漏，也不重复（2）合理安排测试人员（3）使得软件测试不依赖于个人
2. 实施测试：执行用例脚本-记录测试结果-缺陷提交、跟踪及管理-回归
3. 初测期：测试主要功能和关键的执行路径，排除主要障碍。
4. 细测期：依据测试计划和测试用例、逐一测试大小功能、各方面特性、性能、用户界面呢、兼容性、可用性等等；预期可发现大量不同性质、不同严重程度的错误和问题。
5. 回归测试期：系统已达到稳定，在议论测试中发现的错误已十分有限；复查已知正情况，确认未引发任何新的错误。
6. 评估：测试过程、产品。评估-总结-测试总结报告。
7. 测试流程与测试文档 拟定测试计划：测试计划方案 评审测试计划

设计与开发：测试用例 测试脚本

实施测试：缺陷报告 测试记录 用户文档

测试评估：测试总结报告

1.21软件测试计划

1. 软件测试计划（定义）：软件测试正式实施之前明确测试对象，并通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划。意义：保证有效的实施软件测试。
2. 目的：把知识和经验直接转化为执行任务的具体方法 为组织、安排和管理测试项目提供一个整体框架促进团队间关于测试任务和过程的交流 分析项目执行过程中的风险，并制定应对策略
3. 时间：需求说明书确定之后（尽早）
4. 测试计划在测试活动中处于中心位置，它设定了测试准备工作和执行测试的必备的条件，同时形成了测试过程质量保证的基础。
5. 使用和维护：使用过程中必要的检测，经评审，是否需要调整和修改，项目是否按照计划执行
6. 基本结构：简介，项目说明，范围，手段和策略，标准，原则，可交付性，任务分配，环境需求，职责，人员和培训需求，进度表，风险及偶然事故的预测。
7. 要求：指导测试工作，用户是特殊用户：按用户要求填写。

第二章

2.1软件测试环境搭建

1. 为何搭建测试环境：对线上环境产生影响。（生产环境【也包括测试生产环境】 预发布环境 正式环境）
2. 搭建测试环境原则：真实：项目软件（针对性） 产品软件（普遍性）

   干净：除去多余的

   独立：开发环境与测试环境 测试环境与测试数据库

   无毒：各种杀毒软件

1. 环境介绍：B/S结构 C/S结构 移动端 APP 嵌入式设备

2.2测试用例相关

• 测试用例：为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果等信息的一个特定集合。
• 解决的问题：测什么，怎么测，如何衡量
• 时间：测试计划评审通过后开始进行，正式执行测试前完成。
• 好处：理清思路，避免遗漏，跟踪测试进展，历史参考，重复性
• 作用：实施测试指导，指导脚本编写，出具测试报告，分析缺陷的基准依据。（以测试用例为依据，测试结束后，总结出：bug数量，有效bug，无效bug）
• 内容：参考需求文档，编号（拼音缩写+数字）

– 测试步骤：操作描述

– 输入数据：测试数据

– 期望结果：程序应该输出的结果

– 测试结果：程序实际输出的结果（yes/no）

• 测试用例管理工具：BugFree，QC，TD禅道，Redmine
• 测试用例更新和维护的原因： 需求变更、功能变化，测试用例也需要更新，测试用例需要细化和不断完善，是个循序渐进的过程。
• 测试用例要经过正式、有效的评审：集众人的经验及认识于一体，对测试用例进行查漏补缺，使得测试用例的有效性进一步提升。
• 黑盒测试用例设计方法：等价类划分法、边界值分析法、因果图法
• 白盒测试用例设计方法：语句覆盖，逻辑覆盖，条件覆盖
• 黑盒测试：在完全不考虑程序内部结构和内部特性的情况下检测每个功能是否正常使用。
• 白盒测试：结构测试，透明盒测试，逻辑驱动测试或基于代码的测试
• 静态测试：不运行程序，只对程序进行检查和审核
• 动态测试：使用和运行程序进行检查

2.3等价类划分法

1. 定义：依据需求对输入的范围进行细分，然后再分出的每一个区域内选取一个有代表性的测试数据开展测试。
2. 有效等价类：符合需求说明，合理地输入数据集合
3. 无效等价类：不符合需求说明，无意义地输入数据的集合
4. 步骤总结：划分等价类，编号，覆盖有效等价类，覆盖无效等价类

2.4边界值分析法

1. 定义：对输入或输出的边界值进行测试的一种测试方法。（通常作为对等价类划分法的补充。）
2. 选取三种情况，=  <  >
3. 情况：被测对象跟数量有关系

2.5黑盒测试——常用控件测试方法

• 文本框测试

数据内容、长度、类型（注：大小写）、格式（行、日期）、唯一性、空、空格、复制/粘贴+手动、特殊字符、功能键等。

步骤

按钮测试 – 按钮功能是否实现（关联）

– 提示信息是否正确（正确、友好、无法恢复时）

黑盒测试——错误推测法

1. 定义：借助测试经验开展测试的一种方法，基于经验和直觉推测软件中容易产生缺陷的功能、模块，及各种业务场景等，并依据推测逐一进行列举，从而更有针对性的设计测试用例。
2. 前提：深度熟悉被测系统，系统的分析过已有的缺陷
3. 经验分享：时间性测试 密码输入框缺陷 配置文件安全性 同时操作问题

2.7测试数据准备

1. 测试数据影响测试质量，影响测试环境。
2. 来源：录入数据，已有系统数据
3. 要求

1. 功能测试不需要大量数据
2. 功能测试覆盖率高
3. 功能测试尽量真实
4. 性能测试需要大量数据
5. 性能测试尽可能的达到符合实际的数据分配

2.8白盒测试——静态测试

1. 白盒测试又称结构测试，逻辑驱动测试，基于代码的测试。
2. 静态测试

• 代码检查法（变量，子程序、宏、函数，等价性，常量，风格，补充文档）

内容：

i.代码和设计的一致性

ii.代码对标准的遵循、可读性

iii.代码逻辑表达的正确性

iv.代码结构的合理性等方面

方法

i.桌面检查：自己检查代码，编译、分析、检验、补充文档（目的：发现程序中的错误）

ii.代码走查：发资料、开会运行

Iii.代码审查：发材料、开会讲解

• 静态结构分析法

I.定义：静态结构分析工具分析程序源代码的内部结构

i.系统结构，数据结构，数据接口，内部控制逻辑

ii.可生成的分析文档 函数调用关系图，模块控制流程图，内部文件调用关系图，子程序图，宏和函数参数表

• 代码质量度量

i.ISO 9126国际标准定义：功能性，可靠性，易用性，效率，可维护性，可移植性

ii.代码行度量法 代码行数 bug率（千行代码内bug的数量）

iii.McCabe度量法 （V(G)＝m－n＋2 弧-结点+2 控制流程画对）

iv.Halstead软件科学法（程序=运算符号 + 运算对象结构度量）

v.结构度量

 

n1=不同运算符的个数  – + - * / = if else for ……

n2=不同运算对象的个数

• 扇入：调用该模块的模块计数；

• 扇出：该模块所调用的模块计数；

• 使用扇入、扇出来评价软件设计

– 具有大扇入和大扇出的模块可能是不良设计。

这种模块可能未能正确分解并需要重新设计。

– 程序复杂性与扇出的平方成正比

动态白盒测试

静态检查

1. 代码检查法
2. 静态结构分析法
3. 静态质量度量法

动态检查——逻辑覆盖

1. 语句覆盖
2. 判定覆盖
3. 条件覆盖

1.逻辑覆盖：通过程序逻辑结构的遍历实现程序的覆盖

2.语句覆盖：一个比较弱的测试标准，设计若干测试用例，使得程序中每个可执行语句至少都能被执行一次。

3.判定覆盖(分支覆盖)：每个分支至少获得一次“真值”或“假植”，比语句封盖稍强的测试标准

4.条件覆盖：每个条件的可能取值至少满足一次。每个条件都真一次假一次。

5.判定-条件覆盖：使得判定中所有条件至少执行一次取值，同时，使得所有判定的可能至少执行一次。（全部真全部假）

6.条件组合测试：使得判定中条件的各种组合都至少执行一次。（如图都试一遍）

7.路径测试：相当强的覆盖标准，足够多的测试用例，覆盖程序中所有可能的路径。（每一条路都试过 三个字母涵盖每条路径）

第三章

3.1软件缺陷相关

1. 定义：产品内部：产品开发或维护过程中所存在的错误、毛病等各种问题。产品外部：系统所需要实现的某种功能的失效或违背。
2. 满足以下规则之一称发生一个缺陷：

1. 为实现产品说明说要求的功能
2. 出现产品说明书指明不该出现的错误
3. 实现产品说明书未提到的功能
4. 为实现产品说明书虽未明确提及但应该实现的目标
5. 软件难以理解，不易使用，运行缓慢或者用户认为不好

1. 产生原因及修复成本

1. 解决问题想法 沟通 需求评审 设计评审 文档更新即使 开发测试

1. 缺陷报告

1. 用途：记录缺陷，缺陷分类（为解决缺陷分配资源）缺陷跟踪
2. 编写：使非缺陷报告撰写者依据缺陷报告（简单、迅速）重现缺陷。包括重现缺陷的必要步骤。一个缺陷一个报告。

1. 严重性和优先级

– Fatal：致命的错误，造成系统或应用程序崩溃、死机、系统悬挂，或造成数据丢失、主要功能完全丧失等。

– Critical：严重错误，主要指功能或特性没有实现，主要功能部分丧失，次要功能完全丧失，或致命的错误声明。

– Major：主要错误，这样的缺陷虽然不影响系统的使用，但没有很好地实现功能，没达到预期效果。如提示信息不太准确，或用户界面差，操作时间长等。

– Minor：一些小问题，对功能几乎没有影响，产品及属性仍可使用。

– Suggestion：一些友好的建议。

1. 缺陷状态及周期性

1. 定义：缺陷通过一个跟踪修复过程的进展情况，也就是在缺陷生命周期中的状态基本定义。
2. 状态：激活或打开、已修正、关闭或非激活、重新打开、推迟、保留、不能重现、需要更多信息、重复、不是缺陷、需要修改软件规格说明书。
3. 周期

 

第四章

4.1单元与单元测试概念

1. 单元：一个最小的单元应有明确的功能、性能定义、接口定义而且可以清晰地与其他单元区分开来。例如：面向过程语言（C、VB单元）一个或若干个函数或过程 面向对象（JAVA、C++、C#）一个类或类的实例，或者由方法来实现的功能 网页或用户窗口界面单元 一文字输入窗口或一个按钮
2. 单元测试（Unit Testing模块测试）：针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用最小可测试部件。
3. 单元测试关注点

1. 目标：确保每个模块能正常工作
2. 时间：编码——编译——单元测试
3. 注意：前期完成单元测试计划、设计好用例
4. 依据：详细设计说明
5. 执行者：程序开发者或白盒测试人员
6. 操作：以白盒测试法为主，先静态检查分析（检查编码规范）代码是否符合规范，再动态（边界值，非法数据容错性）运行代码（编译，语法问题；运行，测试数据；输出结果比较），检查结果。

4.3单元测试的执行过程

1. 单元测试时，若模块不是独立的程序，需要设置一些辅助测试模块。

1. 驱动模块（Drive）：模拟被测试模块的上一级模块，相当于被测模块的主程序。它接收数据，将相关数据传送给被测模块，启动被测模块，并打印出相应的结果。
2. 桩模块（Stub）：测试被测模块工作过程中所调用的模块。一般只进行很少的数据处理。

单元测试工具

1. 常用 main函数、C++ Test、JUnit、NUnit
2. 实施测试：单元测试，集成测试，系统测试，验收测试

4.5集成测试

1. 集成测试（integration test）：是每个模块完成单元测试后，按照设计时确定的结构图，将它们连接起来进行测试。（综合测试、组装测试、联合测试）
2. 时间：单元—集成（理论）同步进行（真实工作中）
3. 注意：前期完成继承测试计划，设计好用例。
4. 依据：概要设计说明书。
5. 内容：
6. 
7. 方法：非增量：一步到位的方法构造测试。优点：节省时间。缺点：新旧故障混杂，一次集成的模块较多时，容易出现混乱。故障定位和纠正比较困难。增量式：逐步集成方式实现测试。方式：自底向上，自顶向下，混合增量。

自顶向下：深度、广度优先，逐步集成、测试。

主控模块：关键模块。

主控模块特征：满足某些软件的主要需求；在程序的模块结构中位于较高层次（高层控制模块）；较复杂、交易发生错误；有明确定义的性能要求。

测试过程：主控模块作为测试驱动器；根据集成方式，下层桩模块一次次被替换为真正的模块；每个模块被2集成时，都必须进行单元测试。

测试方式：深度优先方式集成（集成在结构中的一个任意主控路径下的所有模块）；

广度优先方式的集成：沿水平方向，把每一层所有直接隶属于上一层的模块集成起来，知道底层。

b)自底向上：逐步集成、测试

 

c)混合增量式：自顶向下+自底向上=兼具优点，摒弃缺点。

测试方式：对输入输出模块和引入新算法模块的测试。调用模块多：自底向上。被调用模块多：自顶向下。

• 测试方法比较

1. 非增量式：先分散再集中，若在模块接口处存在错误，只在最后的集成测试时暴露，修改难度大。
2. 增量式：逐步集成和测试，差错分散暴露，一些模块得到较多次的考验。
3. 自顶向下 优点：逐步求精，开始就能看到系统的框架，发现上层接口不需要驱动模块。缺点：需要提供桩模块，底层关键模块中错误发现较晚。在输入/输出模块加入系统以前，在桩模块中表示测试数据有一定困难。
4. 自底向上 优点：最常用，可发现底层模块错误，由于驱动模块模拟了所有调用参数，即使数据流并未构成有向的非环状图，容易生成测试数据。缺点：直到最后一模块被加进去之后才能看到整个程序（系统）的框架。

系统测试

1定义：将软件系统看作一个整体急性测试，包括对功能性能等，以及将计算机硬件、某些支持软件、数据和人员等系统元素结合起来，在实际运行环境下对软件进行测试。

系统测试——功能测试

1. 定义：对产品各功能点进行验证。根据需求规格说明书和功能测试用例，逐项测试以检查产品是否到达用户的要求。
2. 方法：（1）分析产品/产品所有功能。

1. 逐个功能分析测试点
   1. 等价类划分
   2. 对每个定价类进行边界值分析
   3. 对子功能使用错误推测法分析

4.8系统测试——易用性测试

• 定义：交互的适应性、功能性和有效性的集中体现。
• 内容 （1）UI测试（页面、遥控器按键）
• 易用性功能
  1. 标准和规范：风格，错别字
  2. 直观：洁净，合理，清晰
  3. 一致：遵循标准 例：快捷键和菜单选项（赋值，粘贴）
  4. 灵活：状态终止和跳转，数据输入输出。
  5. 舒适
  6. 正确：语言拼写，文件和屏幕一致。
  7. 实用：是否有实际价值。
  8. 辅助选项测试：残疾障碍测试。
• 辅助特性 提供辅助方式：操作系统内置，平台 遵守启用辅助选项：键盘、鼠标、声卡。若被测软件本身就是平台，就需要定义、编制和测试自己的辅助选项。
• Windows提供的辅助选项粘贴键• 筛选键• 切换键• 声音卫士（每当系统发出声音时，给出警告）• 声音显示（让程序显示其声音或讲话的标题，需要在软件中编制）等等。

4.9系统测试——兼容性测试

• 定义：检查软件之间是否能够正确地交互信息和共享信息。
• 原因：软件越来越多，保证这些通用软件支持跨平台、跨支撑软件运行
• 标准

1. 向后兼容：可以使用软件的以前版本
2. 向前兼容：可以使用软件以后的版本
3. 高级标准和规范：遵守平台（操作系统）的标准
4. 低级标准和规范：产品本身的标准

• 内容：操作系统，应用软件之间，数据库，软硬件配合。
• 平台兼容性应用软件选择 （利用等价类划分，使验证软件之间正确交互的最小有效集合）

1. 流行程度：销售记录前100前1000个最流行的程序。
2. 年份：近三年以内的程序和版本）。
3. 类型：文字编辑，图形，音频，视频，财务，数据库等。
4. 生产厂商：根据制作软件的公司才选择软件。

• 数据兼容性

1. 应用程序间共享数据，要求支持并遵守公开的标准，允许用户与其他软件无障碍的传输数据。
2. 文件保存和读取，只有符合标准才能在两台计算机上保持兼容。
3. 文件导出和导入是许多程序与自身以前版本、其他程序保持兼容的方式。
4. 数据被复制、剪切，当进行粘贴时，一些应用程序只接受特定数据类型和格式。

• 软硬件配合兼容

1. 新操作系统对于主流硬件型号上进行兼容性测试
2. 新应用软件对于主流硬件型号及主流操作系统的兼容性测试
3. B/S 架构的软件，必须考虑浏览器的兼容性
4. 移动端的软件，必须考虑主流移动设备厂商的设备，主流平台（Android,IOS等），主流屏幕大小等等

系统测试—安全性测试

1. 定义：检查系统对非法入侵的防范能力。
2. 目的：验证安装在系统内的保护机制能否在实际中保护系统且不受非法入侵，不受非法干扰。（应对入侵）
3. 方式：分析黑客攻击系统的动机和角度。
4. 常见安全问题：安全性威胁、跨站脚本攻击、缓冲区溢出、SQL注入（穿过防火墙，入侵检测系统，执行增、删、改、查脚本，尝试输入特殊字符）、命令注入、格式化字符串、整数溢出。

4.11 回归测试

1. 定义：对软件的新的版本测试时，对新版本进行重新测试，这时的测试不仅是验证被修复的软件缺陷是否被解决了，且要保证以前所有运行正常的功能依旧保持正常，而不要受到这次修改的影响。（为了修复一些问题而进行的版本升级）
2. 测试用例选择 再测试全部用例，基于风险选择测试（最重要的、关键的和可疑的测试），基于操作剖面选择测试（最重要或最频繁使用功能），测试修改的部分（被改变的模块和它的接口上）。
3. 过程

1. 识别被修改的部分
2. 排除不适用用例，确定有效用例，建立新测试用例库T0
3. 从T0中选择用例测试被修改的软件
4. 如有必要，生成T1，补充T0
5. 用T1执行修改后的软件

注意：（2）（3）验证是否破坏现有的功能，（4）（5）验证修改工作本身

4.12验收测试

• 定义：对新版本重新测试，验证被修复的软件缺陷是否诶解决，保证以前所有运行正常的功能依旧正常，且不受的这次修改的影响。（为了修复一些问题而进行的版本升级）
• 时间人员：系统测试之后，用户测试稳住，有时人员等质量保障人员共同参与的测试，是检验软件产品质量正式交给用户使用的最后一道工序。
• 内容

1. 明确验收项目，规定验收测试通过的标准
2. 确定测试方法
3. 决定验收测试的组织机构和可利用的资源。
4. 选定测试结果分析方法。
5. 指定验收测试计划并进行评审。
6. 设计验收测试所用的测试用例。
7. 审查验收测试准备工作。
8. 执行验收测试。
9. 分析测试结果。
10. 做出验收结论，明确通过验收或不通过验收。

• 测试计划内容：功能测试，逆向测试，特殊情况，文档检查，强度检查，回复测试，可维护性，用户操作，友好性，安全测试。
• 步骤：测试计划-测试用例-执行用例记录结果-分析测试结果-提交测试报告
• 实施策略：项目软件验收，产品软件验收。（选人，备材料，搭现场，讨论过程，测试辅助，总结）
• 实施

1. Alpha测试(α测试内部测试)：软件开发公司组织内部人员（用户、测试人员、开发人员）模拟用户测试。关键：逼真模拟运行环境和用户操作，尽力涵盖所有用户操作。
2. Beta测试：公测。软件开发公司组织各方面的典型用户，实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。

• 技术

1. 黑盒测试：执行用户确认测试报告或需求规格说明，逐步进行至整个运作过程结束，并分析执行结果是否符合要求。
2. 易用性测试：检验测试过程中对软件的操作及反应的满意程度，是否快捷、符合使用习惯，提出见解。
3. 静态测试：检验用户手册或相关文件，保证描述正确。

第五章

5.1软件质量相关

• 质量范围-3A

1. 可说明性（acountability）：用户可以基于产品或服务的描述和定义进行使用。
2. 有效性（Availability）：产品或服务对于99.999%的客户总是有效的
3. 易用性（Accessibility）：对于用户，产品或服务非常容易使用并且一定是非常有用的功能

• 质量视角：用户，开发者
• 质量标准：产品质量（McCall ISO9126 Boehm），过程质量（CMM ISO9000）。
• CMM五级模型

1. 初始级
2. 可重复级
3. 定义级
4. 定量管理级
5. （不断）优化级