第一章 软件测试概述
一个可靠的软件系统应该是正确、完整、一致和健壮的，也是软件用户所期望的。IEEE组织将软件的可靠性定义为：系统在特定环境下，在给定的时间内无故障运行的概率。
对于软件缺陷的精确定义，通常全球软件业界普遍认同下列5条规则：
（1） 软件未达到产品说明书中已经标明的功能；
（2） 软件出现了产品说明书中已经指明不会出现的错误；
（3） 软件未达到产品说明书中虽未指出但应当达到的目标；
（4） 软件功能超出了产品说明书中指明的范围；
（5） 测试专业人员认为软件难以理解、不易使用，或者最终用户认为该软件使用效果不良。
导致软件缺陷的最大原因源于软件产品的设计文档（各种设计、规划文件及说明书）。软件缺陷产生的第二大来源是设计方案，这是实施软件计划的关键环节。
软件测试从软件20世纪60年代被正式建立。1961年，一个简单的软件错误导致了美国大力神洲际导弹的助推器的毁灭，致使美国空军强制要求在其后的关键发射任务中，必须进行独立的验证，从而建立了软件的验证和确认的方法论，软件测试就此开始兴起。
软件测试大致经历了以下几个重要阶段：软件调试à独立的软件测试à 首次被定义à成为专门学科à与软件开发融合
1973年，Bill Hetzel给出了软件测试的第一个定义：“软件测试就是对程序能够按预期的要求运行建立起的一种信心”。
1982年在美国北卡罗莱纳大学召开了首次软件测试正式会议。1983年，IEEE组织对软件测试做出如下定义：
（1） 使用人工或自动的手段来运行或测量软件系统的过程，目的是检验软件系统是否满足规定的要求，并找出与预期结果之间的差异。
（2） 软件测试是一门需要经过设计、开发和维护等完整阶段的软件工程。
(Test-Driven Development, TDD)测试驱动开发，敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定了需要编写什么产品代码。TDD基本思路就是通过测试来推动整个开发的进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析、设计、质量控制量化的过程。
软件模型分类：
① 故障模型：会引起错误的常见软件模型。
② 安全漏洞模型：为他人攻击软件提供可能。
③ 差性能模型：软件动态运行时效率比较低下。
④ 并发故障模型：多线程编码。
⑤ 不良习惯模型：由于编码的不好习惯造成的一种错误。
⑥ 代码国际化模型：存在于语言进行国际化的过程中。
⑦ 诱骗代码模型：容易引起起义的、迷惑人的编写方式。
基于模型的测试机理：首先提出软件模型，然后通过检测算法进行检测，如果检测算法结果是符合质量要求的，则能够从软件中排除该类模型。
基于模型的软件测试技术的优点：
① 工具自动化程度高以及测试效率高，检测所需时间较短。
② 基于模型的软件测试技术往往能发现其他测试技术难以发现的故障。
基于模型的软件测试技术的缺点：
① 误报问题。通常基于模型的软件测试技术都属于静态分析技术，由于某些故障的确定需要动态地执行信息，因此对于基于静态分析的工具来说，误报问题是不可避免的。
② 漏报问题。漏报问题主要是由模型定义和模型检测算法引起的。目前软件模式没有一个规范的、统一的形式化的定义。
③ 模型多样性。由于编程过程中，程序员具有较强的个体性，因此软件模型是多种多样的。
测试经验表明，约一半（47%）的错误仅与系统中4%的程序模块有关。
测试需求分析是对产品生命周期中厕所时所需求的资源、配置、每阶段评判通过的规约；系统测试计划则是依据软件的需求规格说明书，制定测试计划和设计相应的测试用例。
通常有5类终止测试的标准或依据：
① 测试超过了预定时间则终止测试。这类标准不能用来衡量软件测试的质量。
② 执行了所有的测试用例，但并没有发现故障，则终止测试。这类标准对测试并无好的指导作用，相反却有可能默认测试人员没有编出更好的、能暴露出更多故障的测试用例。
③ 使用特定的测试用例设计方案作为判断测试终止的基础。使用特定的测试用例设计方案作为判断测试终止的基础。这类标准仍然是一个主观的测量尺度，无法保证测试人员准确、严格地使用某种测试方法。这类标准只是给出了测试用例设计的方法，并非确定的目标，并且这类标准只适用于某些测试阶段。
④ 正面指出终止测试的具体要求，即终止测试的标准可定义为查出某一预定数目的故障，如规定发现并修改多少个故障就可停止测试。使用第四类标准需要解决两个问题：第一个问题是如何知道将要查处的故障数目，另一个问题是可能会过高地估计了故障的总书目。解决问题的途径是根据过去的经验和软件开发业界常用的一些平均估算值方法
⑤ 根据单位时间内查处故障的数量决定是否终止测试。
常用的软件设计文档的内容如下：
① 构架，即产生描述软件整体设计的文档，包括软件所有主要部分的描述以及相互间的交互方式。
② 数据流示意图，表示数据在程序中如何流动的正规示意图，通常由圆圈和线条组成，所以也称为泡泡图。
③ 状态变化示意图，将软件分解为基本状态或者条件的另一种正规示意图，表示不同状态间的变化的方式。
④ 流程图，用图形描述程序逻辑的最常用方式之一。
⑤ 注释代码。
软件开发模式
1. 大棒开发模式的最大优点是思路简单，经常可能是开发者的“突发奇想”。但它几乎没有任何产品计划、进度安排和规范的开发过程，软件开发者的主要精力花费在程序设计和代码编写上，开发过程是非工程化的。大棒模式的软件测试通常在开发任务完成后进行，测试工作有时较容易，有时则非常困难，这是因为软件已形成产品后，已经无法再修复存在的问题，所以软件测试的工作只是向客户报告软件产品经测试后发现的情况。
2. 软件的边写边改开发模式是对大棒开发模式的一种改进，但考虑到了软件产品的要求。
因为从开始就没有严格地计划和文档编制，软件开发能较迅速地展现成果。因此，边写边改模式适合用在快速制作而且用完就扔掉的小型项目上，如示范程序与演示程序。
处于边写边改开发项目组的软件测试人员要明确的是，自己将和程序员一起陷入可能是长期的循环往复的一个开发过程。
3. 遗漏的需求或者不断变更的需求会使得瀑布开发模型无所适从，它适用于那些需求比较稳定、容易理解的项目。瀑布开发法是将软件生命周期的各项活动规定为按照固定顺序相连的若干阶段性工作，形如瀑布流水，最终得到软件产品。
瀑布开发模型的优点：
Ø 易于理解。
Ø 调研开发的阶段性。
Ø 强调早期计划及需求调查。
Ø 确定何时能够交付产品及何时进行评审与测试。
瀑布开发模型的缺点：
Ø 需求调查分析只进行一次，不能适应需求的变化。
Ø 顺序的开发流程，使得开发中的经验教训不能反馈到该项目的开发中去。
Ø 不能反映出软件开发过程的反复性与迭代性。
Ø 没有包含任何类型的风险评估。
Ø 开发中出现的问题直到开发后期才能暴露，因此失去了及早纠正的机会。
4. 应用快速原型开发模式的目的是为了确定用户的真正需求，使得用户在原型面前能够更加明确自己的需求是什么。
5. 螺旋模型开发是瀑布模型与边写边改方法演化、结合的形式，并加入了开发风险评估所建立的软件开发模式。该软件开发模式由美国TRW公司B.W.Boehm博士提出。
螺旋模型的主要思想是在开始时不必详细定义所有细节，而是从小的规模开始，定义重要功能，尽量实现，然后探测风险，制定风险控制计划，接受客户反馈，进入下一阶段并重复上述过程，然后进行下一个螺旋的反复，确定下一步项目是否还要继续，直到获得最终产品。该模型的最大优点就是随着成本的增加，风险程度随之降低。但螺旋模型的缺点是比较复杂，且需要管理人员有责任心，专注且有管理方面的经验。
螺旋模型具有发现问题早、产品的来龙去脉清晰、成本相对低、测试从最初就参与各项工作的特点。
6. RUP (Rational Unified Process)是Rational公司提出的一套开发过程模型，它是一个面向对象软件工程的通用业务流程。
RUP设计具有两个轴向，一个轴是时间轴，这是动态的；另一个是工作流轴，这是静态的。在时间轴上，RUP划分了四个阶段：初始阶段、细化阶段、构造阶段和发布阶段。每个阶段都使用了迭代的概念。在工作流轴上，RUP设计了六个核心工作流程和三个核心支撑工作流程，核心工作流程包括：业务建模工作流、需求工作流、分析设计工作流、实现工作流、测试工作流和发布工作流；核心支撑工作流程包括：环境工作流、项目管理工作流和配置与变更管理工作流。
7. IPD (Integrated Product Development)流程是由IBM提出来的一套集成产品开发流程，非常适合于复杂的大型开发项目，尤其涉及软硬件结合的项目。该流程中总共划分了六个阶段，即概念阶段、计划阶段、开发阶段、验证阶段、发布阶段和生命周期阶段；四个决策评审点，即概念阶段决策评审点、计划阶段决策评审点、可获得性决策评审点和生命周期终止决策评审点，以及六个技术评审点。
IPD流程是一个阶段性模型，具有瀑布模型的影子。该模型通过使用全面而又复杂的流程来把一个庞大而又复杂的系统进行分解并降低风险。在一定程度上，该模型是通过流程成本来提高整个产品的质量并获得市场的占有率。由于该流程没有定义如何进行流程回退的机制，因此对于需求经常变动的项目，该流程就显得不大适合了；对于一些小的项目，也不是非常适合使用该流程。
敏捷开发
敏捷开发不是仅为一个过程，而是一类过程的统称，这些过程又一个共性，就是符合敏捷价值观，遵循敏捷开发的原则：简单、灵活和效率。敏捷的价值观为：个体和交互胜过过程和工具；可运用工作的软件胜过面面俱到的文档；客户合作进行合同谈判，以相应变化胜过教条地遵循计划。
敏捷开发过程主要包括：SCRUM，Crystal，特征驱动软件开发（FDD），自适应软件开发（ASD）及极限编程（XP）等。
软件测试模型
1. V模型
V模型是软件开发瀑布模型的变型，主要反映测试活动与分析和设计的关系；强调了在整个软件项目开发中需要经历得若干个测试级别，并与每一个开发级别对应；V模型中的过程从左到右，描述了基本的开发过程和测试行为。V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。
V模型的局限性：把测试作为编码之后的最后一个活动，需求分析等前期产生的错误直到后期的验收测试才能发现；忽略了测试的对象不应该仅仅包括程序，没有明确指出对需求、设计的测试，因此也和瀑布模型一样存在不足。
2. X模型
X通常代表未知，并包括探索性测试（exploratory testing）。
X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终合成为可执行的程序（右上半部分），这些可执行程序还需要进行测试。已通过集成测试的成品可以进行封板并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各部分发生。
V模型的一个强项是它明确需求角色的确认，而X模型没有这个机制，这也是X模型的不足之处。
3. H模型
H模型中，软件测试过程活动完全独立，贯穿于整个产品的周期，与其他流程并发地进行，某个测试点准备就绪时，就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早进行，并且可以根据被测物的不同而分层次进行。
4. W模型
W模型基于“尽早地和不断地进行软件测试”的原则，在软件的需求和设计阶段的测试活动遵循IEEE1012-1998《软件验证与确认（V&V）》的原则。
W模型的不足表现在，该模型当中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，只有上一阶段完成后，才可以下一阶段的活动，因此，这种模式不能支持迭代，也不适应开发过程中的变更调整。
5. 前置测试模型
前置测试模型是一个将测试和开发紧密结合的模型，该模型提供灵活的方式，可使项目开发加快速度。
前置测试模型包括两项测试计划技术。第一项技术是开发基于需求的测试用例。这不仅是为以后提交上来的程序的测试做好初始化准备，也是为了验证需求是否是可测试的。第二项技术是定义验收标准。
6. 敏捷开发的测试
在敏捷团队中，测试的核心工作内容依然是不断地寻找缺陷，这时测试需要着重考虑以下几点：①更多采用探索性的测试方法；②更多采用上下文驱动的测试方法；③更多采用敏捷自动化测试原则。
敏捷测试需要持续地测试、不断地回归测试和快速地测试。
测试过程实施要解决的核心问题是制定测试计划、测试用例（大纲）和完成测试报告。
一个良好的测试计划应具备以下几个要素：
（1） 清晰地定义测试目标和出口准则；
（2） 明确测试的策略，定义要执行测试的种类；
（3） 在检测主要缺陷方面有一个好的选择；
（4） 提供绝大部分代码的覆盖率；
（5） 具有灵活性、易于执行、回归和自动化；
（6） 通过清晰地文档表达测试期望的结果；
（7） 当缺陷被发现的时候，能提供缺陷核对；
（8） 没有冗余，确认风险；
（9） 文档化的测试需求；
（10）定义可交付的测试件。
在集成测试过程中的两个重要的里程碑是功能冻结和代码冻结的确定。这两个里程碑界定出回归测试期的起止界限。
质量管理从20实际初创始至今，大约经历3个阶段，这三个阶段是：①产品质量检验阶段：这个时期特征是对产品的质量进行检验。产品质量的检验只是一种事后的检查，不能预防不合格品的产生；②统计质量管理阶段：它是运用概率论和数理统计的原理，提出控制生产过程，预防不合格产品的思想和方法，即通过小部分样品测试，推测和控制全体产品或工艺过程的质量状况。后逐步形成统计质量控制（Statistics Quality Control, SQC）的方法，用控制图表对生产过程中取得的数据进行统计分析，分析不合格产生的原因并采取相应措施，使生产过程保持在不出废品的稳定状态；③全面质量管理（Total Quality Control, TQC）阶段：从以质量管理专业人员为核心进行质量管理，发展到管理者推动、组织各部门的人员都来进行学习和实行质量管理。ISO8402（1994版）标准将全面质量管理定义为：“一个组织以质量为中心，以全员参与为基础，目的在于通过让客户满意和本组织所有成员及社会受益而达到长期管理的途径。”
ISO/IEC9126国际标准所定义的软件质量包括六个部分，分别为功能性、可靠性、可用性、有效性、可维护性和可移植性。
软件质量的度量分为产品质量度量和过程质量度量两种类型。
QA（Quality Assurance），即质量保证；QC（Quality Control），即质量控制。两者都是寻找错误，但QC查找的是产品中的错误，QA查找的是过程中的错误；QA与QC的目标都是对质量进行管理。
软件能力成熟度模型（Capability Maturity Model, CMM）是软件行业的标准模型之一，用来定义和评价软件企业开发过程的成熟度，并提供如何做才能提供软件质量的指导。
CMM将软件组织的过程能力成熟度级别分为5个级别：初始级、可重复级、已定义级、已管理级、优化级。
分层结构的一个重要特点是：判定成熟度等级有关的组成部分处于模型的顶层，它们是成熟度等级（Maturity Levels）、关键过程域（Key Process Areas, KPA）、各个关键过程域的目标（Goals）。每一级的每个关键过程域进一步包含5个关键实践（Key Practice, KP）。
所谓关键过程区域，是指一系列相互关联的操作活动，这些活动反映了一个软件组织改进软件过程时必须集中力量改进的几个方面。换言之，关键过程区域包含了达到某个成熟程度级别时所必须满足的条件。
在CMM中一共有18个关键过程域，分布在2~5级当中。
软件测试成熟度模型（Test Maturity Model, TMM），是基于CMM的原则而构成的，它是一个集成的软件测试成熟度框架模型。
