软件测试之软件测试的原理与方法第一篇

第一章引论

测试和质量保证的关系

软件质量保证活动（SQA）是通过对软件产品有计划地进行评审和审计来验证软件是否合乎标准的系统工程，通过协调，审查，跟踪来获取有用信息，形成分析结果以指导软件过程。（也就是通过检查看软件是否符合标准，获取有用信息，做成分析结果用来指导软件过程）

测试和质量保证SQA的关系相辅相成，sqa指导监督软件测试的计划和执行，协调测试流程的改进。软件测试是sqa重要手段之一，为sqa提供需要的数据。sqa是管理工作，注重对流程的评审和监控。软件测试是技术性的工作，侧重对产品进行评估和验证。

测试和开发的关系

软件测试人员从项目启动的第一天就要介入，认真对待需求评审。软件测试和软件开发在整个软件开发生命周期中交互协作，从头到尾一起工作，按时高质量的完成项目。后续会深入讨论他们之间的关系。

练习题：

1.为什么要展开软件测试活动：

1. 发现和修复错误2.提高用户体验3.保护数据安全4.节约成本和时间5.遵守法规和标准

什么是软件测试：软件测试是一个关键的过程，它涉及使用人工或自动化的手段来运行或检测软件系统，以确保软件满足用户的需求和预期。

如何理解软件测试：首先，软件测试就是为了发现程序错误而执行的过程，它的目的就是发现缺陷，保障系统的正常运行。并且，软件测试不仅是测试软件产品本身，还包括软件开发的过程。我认为软件测试是整个软件质量保证过程中重要的一部分

第二章软件测试的基本概念

做好测试就要了解什么是缺陷，在这之前就要知道质量的概念。没有满足质量要求和质量冲突的东西就是缺陷，缺陷是质量的对立面。

本章讲解思路：软件质量的概念，了解软件质量的内涵，然后引出软件缺陷的产生原因，种类和代价等，最后介绍与软件测试相关的概念。

学习本章的目的：完整的理解软件测试的基本内涵。

2.1软件缺陷

2.1.1软件质量的内涵

iso提出质量的定义：质量是反映实体满足明确或隐含需要能力的固有特征和特征的总和。

固有特征：该事务本来就有的，比如桌子的硬度。

明确需要能力：规定的要求，比如国家的规定。

隐含需要的能力：有社会习俗约定，行为管理所要求的一种潜规则，不能用语言形容。比如酒桌上的潜规则。

ibm rup（统一过程）中：质量：满足或超出认定的一组需求，并使用经过认可的评测方法和标准来评估，还使用认定的流程来生产。

质量就是要满足需求，并且通过啦认可的评测方法和认可的标准的评估，还需要使用认定的流程来生产。 

在以前分为内部，外部质量还有使用质量。他们之间的关系书上有p20

在这里需要理解到：

1.产品质量模型八大特性：功能性、性能效率、兼容性、易用性、可靠性、信息安全性、维护性和可移植性。

2.使用质量的属性描述：有效性、效率、满意度、抗风险和语境覆盖（覆盖完整的业务领域）。

2.1.2软件缺陷的定义

• 从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。

2.1.3测试缺陷的测试判断准则

我们看测试结果是都符合质量要求，需要了解测试预言（Test Oracle）概念，它决定测试是否通过的机制，他的使用要求测试系统的实际输出和所期望的输出无差异，表示测试无缺陷。

2.1.4软件缺陷的产生

缺陷产生会从这几个方面产生

1.技术问题2.软件本身的问题3.团队工作上

2.1.5软件缺陷的构成

软件缺陷在不同开发阶段出现的比例：

2.1.6修复软件缺陷的代价

越早发现成本越低

2.2软件测试分类

目的：了解软件测试的全貌

先大概了解测试的整体种类，深入了解需要自行去了解。

2.3静态测试和动态测试

静态测试是指不运行被测试的软件系统，而是采用其他手段和技术对被测试软件进行检测的一种测试技术。例如：代码走读、文档评审、程序分析等都是静态测试的范畴。

动态测试是指按照预先设计的数据和步骤去运行被测软件系统，从而对被测软件系统进行检测的一种测试技术。

本章更多的去谈论静态测试

2.3.1产品评审

通过软件评审可以尽早的发现产品中的缺陷。

评审是对软件元素或项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改善。

软件评审的形式：1.互为评审（两个人看对方的代码）2.走查（给别人从头到尾的检查）3.会议评审

软件评审的对象：管理，技术，文档，流程评审等。软件测试需要：需求，设计，代码，文档评审。

2.3.2静态分析

对模块的源代码进行研读，查找错误或收集一些度量数据，不需要对代码进行运行编译。软件测试贯穿整个软件开发过程，是软件验证和用户需求确认的统一，和软件评审密不可分。

2.3.3验证和确认

软件测试不仅要检查产品的问题，还有检验产品是否能实现用户所需要的功能。这里就提出啦：验证和有效性确认。

2.4主动测试和被动测试

主动测试：测试人员主动向被测试对象发送请求，接收被测试对象的行为，从而验证其反应或输出结果。一般在测试环境中进行的。

为了能够在线测试，被动测试产生啦。

被动测试：测试人员被动地监控产品的运行，通过一定的被动机制来获取系统运行的数据，适合性能测试和在线监控。

主动测试需要设计测试用例，被动测试则不用，只需要想办法获取运行的各种数据。

2.5黑盒测试和白盒测试

白盒测试：能够看清事物的内部，即了解事物的内部结构和运行机制，通过剖析事物的内部结构和运行机制，来处理和解决问题。

白盒测试的基本原则：

黑盒测试：没有办法或不用了解事物的内部结构和运行机制，而把整个事物看成一个整体——黑盒子，通过分析事物的输入与输出，以及周边条件来分析和处理问题。

在实际测试工作中，结合不同的测试方法，以达到良好的测试效果。

2.6软件测试层次

从测试层次可以把测试分为：单元，集成，系统，验收测试。每个层次最好单独进行，有时候为了减少测试工作量或者缩短测试周期，可以进行层次合并，比如：单元和集成测试合并。

单元测试：在编码阶段对每个程序单元的测试。如：类，函数，模块，组件等。主要使用白盒测试，通常要编写驱动程序和桩程序，或者采用mock技术。测试思路：使用白盒方法的结构化测试用例，加以功能测试用例，使其对任何合理的与不合理的输入都能鉴别和响应，从而达到较为彻底的测试。单元测试一般由编程人员完成。

面对接口的集成测试：集成测试又叫组装测试。在单元测试的基础上，根据设计要求不断进行集成而进行的测试，目的是发现单元之间接口的问题。我们需要考虑使用什么方式集成。

方式1.一次性集成的方式。

2.渐增式集成方式。

系统测试

它在集成测试完成之后进行，针对应用系统进行测试。它基于产品功能说明书，用户角度对各种功能进行验证。它不用考虑程序的组成。功能测试包括：用户界面，各种操作，不同的数据输入输出和存储等的测试。

系统非功能测试：在实际运行环境中，或者模拟的运行环境中，针对系统的非功能特征进行的测试，包括：负载，性能，灾难恢复性，安全，可靠性测试等。

面对业务的验收测试

验收测试：就是向用户表示软件的功能和特性是否与用户要求的一致。一般在实际的用户环境上进行，并且和用户共同完成。

Alpha测试：软件开发公司内部人员试用产品，真实使用看能不能发现未发现的缺陷。

经过alpha测试和修正的产品叫Beta版本。

beta测试：公司外部的典型用户试用，并要求用户提出报告和意见，再对beta版本进行修正和完善，最后得到正式的发布版本。

2.7软件测试工作范畴

软件测试过程分为：工程过程和测试项目管理过程。

2.7.1测试分析

测试分析确定”测什么“的问题。测试设计之前需要做测试需求分析。

这里需要了解：测试点/测试项：具体的测试对象，测试优先级：测试项执行的优先程度。

测试需求分析做的事（后期补上）

测试需求分析是测试设计和开发测试用例的基础。

2.7.2测试策略制定

测试策略：指定或选择更适合更有效的测试方式，测试方法和技术等。

体现：1.测试方式，2.测试方法。3.测试过程（先测什么后测什么，对测试阶段的不同划分等）

2.7.3测试计划

测试计划包括：工作量的估算，测试资源和进度安排，测试风险评估，测试策略制定等工作。

测试计划书主要体现：1.目标和范围。2.项目估算。3.风险计划。4.进度安排。5.资源配置。6.跟踪和控制机制。

2.7.4测试设计

它为啦解决：如何测的问题。分为测试总体设计（测试方案和测试结构的设计）和测试详细设计（测试用例的设计）。测试分析和测试设计不容易分清楚他们是交织在一起的，都是为啦测试目标的达成。

测试结构设计：将测试用例组合成测试集（test set）或测试套件（teat suite）

测试用例：有效的发现软件缺陷的最小测试执行单元。

测试脚本：测试工具执行的一组指令集合，让计算机自动完成测试用例的执行。脚本的产生：录制测试的操作，脚本语言编写。

测试的用例作用：

1.测试用例是测试人员在测试过程中重要的参考依据。

2.测试用例可以帮助实施有效的测试，所有被执行的测试都是有意义的，不要执行无意义的测试操作。

3.好的测试用例不断被使用，测试过程就会事半功倍。

4.测试用例是知识积累的过程。

测试用例的设计：根据测试思想和测试方法设计出来的。

设计测试用例的流程：

1.制定测试用例护色剂的策略和思想。

2.设计测试用例的框架（结构）

3.细化结构，逐步设计出具体的测试用例。

4.通过测试用例的评审，不断优化测试用例。

2.7.5测试执行

准备好以上的东西之后就可以执行测试啦，测试执行一般分为：手工测试执行和自动化测试执行。

手工 测试执行有两个概念：

1.基于脚本的测试：先设计脚本，再执行脚本的测试方式。分两个明确的阶段：脚本设计与开发，脚本执行。开发人员和测试人员相对独立，在开发提测（提交测试版本里程碑）之前先完成测试设计，写测试用例。开发提测之后就可以全力进行测试的执行啦。

2.探索式测试：一种软件测试方式，在一段时间里，一边想一边设计测试用例的过程，不用规范的写出来，类似随机提问系统问题看它的反应是否合规。

测试执行可以做到无人看守，在晚上自动运行，测试人员第二天就可以拿到测试结果。

2.7.6测试结果和过程评估

得到测试结果后就要进行测试结果的分析，每个测试方式都要进行测试结果和过程的评估，不是到测试结束啦才进行的，这个是持续进行的，因为要根据出现的问题修改测试计划等，进行及时的修改，如每天 或者每周进行一次测试结果和过程的评估。这个评估还要结合测试计划来进行，把计划的测试活动和实际执行的活动进行比较，了解测试计划执行的情况和效果。

思考题（不一定全对，个人思考出来的答案）

1. 如何看待软件测试在保证软件产品质量的作用？

答：软件测试能够检测出大部分软件系统的缺陷，能够更好进行软件质量保证活动。

2.如何理解软件质量和软件缺陷的对立统一关系？

答：软件质量的定义：满足用户明确和隐含需求的特性以及特有特性的集合，并且需要通过规定的流程来生产，通过认可的评测方法和标准评估。软件缺陷的定义：从内部看，软件缺陷是软件产品在生产或维护中所存在的问题，从外部看，软件缺陷是软件系统的某种功能的失效或违背。它们是对立的，因为质量是达到要求，而缺陷是不满足要求的。

统一：找到的缺陷越多，从而修复缺陷，提高软件质量

3.从修复软件缺陷的代价来讨论测试为什么要尽早开始？

答：因为早点发现缺陷就能早点整改改变，如果到后期才发现错误，严重的会出现反工，消耗的成本是巨大的。

4.结合测试目标分析测试工作的各项主要内容

答：根据测试目的分析可以分为：功能测试，性能测试，安全性测试，兼容性测试，可靠性测试，易用性测试，回归测试。

5.需求分析,系统设计所存在的问题在软件缺陷中占有大比例，对软件开发和测试工作有何启发？

答：对于软件开发人员，以及测试人员而言，告诉他们自己也需要认真审视以及去理解用户需求，需要认真阅读需求分析以及系统设计文档，并且需要花多一些时间在这两个阶段，做好测试工作，检查缺陷。下面是标准答案

第三章软件测试方法

通过前面的学习更容易理解软件测试的目的，我们要在有限的时间里找出系统中绝大部分的软件缺陷，依赖有效的软件测试方法。这些方法有助于实现测试用例的设计。从不同的层次分测试方法：

从高层次看，测试方法体现啦方法论或测试流派，作为一个方法类别出现的：

(1)基于直觉和经验的方法;
(2)基于输人域的方法;
(3)基于代码的方法;
(4)基于故障模式的测试方法;
(5)基于模型的测试方法;
(6)基于使用的方法;
(7)基于需求验证或标准验证的测试方法;
(8)基于逻辑分析的测试方法;
(9)基于上下文驱动的测试方法;
(10)基于风险的测试方法。

有一些测试方法，依赖于软件过程模型，软件开发方法或应用领域：

(1)面向对象的软件采用面向对象的测试方法;
(2)面向服务架构(Service-Oriented Architecture,SOA)
SOA的测试方法;
(3)Web应用测试方法;
(4)移动App应用测试方法;
(5)针对嵌人式应用的嵌人式测试方法(技术);

(6)敏捷开发中会采用更贴近敏捷的测试方法(技术实践)。

不过他们是测试技术，不算方法，是前面1-10的测试方法及其综合运用。

3.1基于直觉和经验的方法

这个算是没有办法的办法，测试结果不可靠，但是软件测试呈现一定的不确定性，人的直觉和经验显得很有用。

3.1.1Ah-hoc测试方法和ALAC测试方法

自由测试（Ah-hoc）需要测试人员有经验的，放开思想的进行测试，经验具体包括一下几个方面：

(1)软件开发(如系统设计、编程等)的经验和知识;
(2)与失效和缺陷打交道的经验(发现和处理缺陷的经验和知识);
(3)对被测软件系统的经验和知识;
自由测试可以作为严格意义上的测试方法的一种补充手段,完善软件测试用例,无拘无束。
(5)其他方面的经验,包括心理学、社会学等。

自由测试可以作为测试方法的一种补充手段。

ALAC测试方法:它是基于一个思想：软件有百分之20的功能是常用功能，不常用功能有80%，客户有80%的时间在20%的常用功能上，在测试中，80%的错误很可能集中在20%的常用功能上，而80%的不常用功能可能集中20%的错误。这也就是从客户的手段进行分析的。测试时间有限，只需要集中测试常用功能即可。常用于：产品是一个演示版，开发预算低，测试时间不够的情况。

3.1.2错误推测法

测试人员根据自己的经验直觉对可能出现的问题进行针对性测试。他的思想：发现某处出现缺陷，可能会隐藏其他缺陷，把这些可能出现问题的地方列出来，然后根据经验做出选择，进行测试。

他只能用于辅助手段。

3.2基于输入域的方法

这个就是通过输入数据看输出数据，看测试是否通过。

3.2.1等价类划分法

数据测试是功能测试的主要内容，借助数据的输入输出来判断功能是否正常，类似与穷举法，不过这个在数据多的时候不能用。就出现啦等价类划分法，用有限的数据来代表无线的数据。通过降低测试数据找到更多的缺陷问题。

它将所有可能的输入数据划分成若干等价类，从每个等价类中选一定的代表值进行测试。属于黑盒测试。

等价类：每个输入域的特殊子集，如果用等价类的代表值作为测试用例，没有发现问题，那么这个等价类中的其他数据也不会发生问题。

等价类划分：分类和抽象

分类：将输入域按照相同特性或类似功能进行分类。

抽象：在每个等价类中去抽象出相同特征并用实例来表征这个特征。

等价类划分法可以用较少的用例完成完整的覆盖，缺点就是需要深入的系统知识才能选择有效的数据。

等价类划分要看有效和无效的。

有效等价类：输入完全满足程序输入的规格说明，有意义的输入数据所构成的集合，可以看程序是否满足规格说明规定的功能和性能。

无效等价类与上面相反，它的作用就是测试程序或者系统的容错率，对异常输入情况的处理。

就是为啦保证输入正常的数据有正确的输出，还要保证错误的输入有异常的保护。

不同情况的处理：1.输入条件规定取值范围或个数的时候，可以定一个有效等价类和两个无效等价类。例如：输入小于100大于10的整数，有效等价类：10<x<100，无效等价类：x<10,x>100.

其他特殊情况就是讲使用这个方法的情况，具体的看书本p46。

3.2.2边界值分析法

在某个输入输出变量范围的边界上，验证系统功能是否正常运行的测试方法。错误最容易发生在边界值附近。它常被看成等价类划分法的一种补充，他们两个常结合起来使用。

边界值分析法处理技巧p47

这个方法最重要的是边界值域的确定，例子排序程序的边界值分析的例子p48.

边界值分析法的应用在p48-p49

3.3基于组合及其优化的方法

当输入条件比较多的时候就需要进行组合分析。

组合分析：基于每对参数组合的测试技术，主要考虑参数之间的影响 是主要的错误来源 和 大多数的错误 起源于 简单的参数组合。

3.3.1判定表法

如果输入条件或输出结果可以用成立或不成立来表示，即0或1两个取值，就可以采用判定表法。

判定表：条件（输入）和活动（输出）组成。

要知道怎么做判定表了解5个概念。

1.条件桩：列出问题的所有条件。

2.动作桩：列出针对问题所作的操作。

3.条件项：针对所列条件的取值。

4.动作项：列出在条件项组合情况下采取的动作。

5.规则：任何一个条件组合的特定取值及其相应要执行的操作。

制作判定表的步骤：

1.列出所有条件桩和动作桩。

2.填入条件项

3.填入动作项，制定初始判定表。

4.简化合并相似规则或相同动作。

看课本例子理解p50-51

3.3.2因果图法

借助图形着重分析输入条件的各种组合，每种组合条件就是因，它必然有一个输出结果，这就是果。

绘制因果图的方式：p51

可以去看课本的例子p52理解因果图

3.3.3Pairwise方法

这个方法也叫成对组合测试，就是设计组合能覆盖很多因素的值的两两组合。也就是解决一些输入条件多，且条件的取值也多的组合。

对一般的应用系统，采用两两组合就可以基本满足测试要求啦。

我们可以使用工具：微软的PICT软件生成组合。 

使用例子P53

3.3.4正交实验法

解决组合数很多的问题，也可以使用这个方法。

从大量的数据中挑选适量的，有代表性的点，从而合理地安排测试。

1.确定影响功能的因子和状态：根据被测软件的规格说明书，确定影响某个功能的操作对象和外部因素，把这些影响测试结果的条件因素作为因子，而把每个因子的取值作为状态，状态数叫水平数。确定：1.因子数多少，有哪些因素。2.每个因素有什么取值，水平数是多少。

2.选择正交表：p54.

3.4基于逻辑覆盖的方法

3.4.1判定覆盖（分支覆盖）

思想：设计若干用例，运行被测程序，让程序中判断结构的判断真假值都满足一次。

满足这个也就满足啦语句覆盖，如果程序中判断语句的判断and写成or，or写成and，则需要多设计几个用例。

3.4.2条件覆盖

思想：设计的测试用例，使每个判断中每个条件的可能取值至少满足一次。

条件覆盖的测试不一定比代码行覆盖，判断覆盖强。

3.4.3判断条件覆盖

它是前面两种判段的交集，即判断条件中所有条件可能取值至少执行一次，同时所有判断的可能结果至少执行一次。

3.4.4条件组合覆盖

思想：设计足够的测试用例，让判断中每个条件的所有可能至少出现一次，并且每个判断本身的判断结果也至少出现一次。要求是所有可能组合都至少出现一次。

3.4.5基本路径覆盖

思路：设计所有的测试用例，来覆盖程序中的所有可能的执行路径。

实际的测试用例设计过程中覆盖率不可能为100%，所以就需要把这几个方法交叉起来使用，提高覆盖率。

基本路径测试法在程序控制流图的基础上，通过解析控制构造的环路复杂度，导出基本可执行路径集合，从而设计测试用例的方法。设计步骤：

1.构造程序的流程图。2.计算程序的环路复杂度。3.确定基本路径。

3.5基于缺陷模式的方法

根据测试中发现的缺陷模式进行匹配，发现其中的问题。这里理解就可以啦。

3.5.1常见的缺陷模型

1.错误使用语法类故障模式：该模式主要引起缺陷的常见软件故障，比如：内存泄漏等。

2.安全漏洞模式

3.低性能模式：该模式主要调用啦不必要的类或者方法，比如：空字符串，复制字符串等。创建不必要的属性等。

4.并发缺陷模式：该模式主要针对程序员对多线程，java虚拟机的工作机制不了解引起的问题，以及由于线程启动的任意性等其他问题引起的死锁等。

5.不良习惯模式：该模式主要是由于程序员不良的编写代码习惯引起的。

6.硬编码模式

7.易诱骗代码模式：该模式主要指代码中容易引起歧义，迷惑人的编写方式。

3.5.2DPBT（动态规划和回溯法相结合的技术）的自动化实现

1.预处理2.词法分析3.语法分析4.抽象语法树生成5.控制流图生成6.ip扫描7.人工确认。

3.6基于模型的测试

这个测试是利用模型来生成相应的测试用例，然后根据实际结果和原先预想的结果的差异来测试系统。

操作步骤：1.从概念上形成模型2.尝试用数学的方法来描述模型3.逐渐形成仿真模型4.完成测试。可看p64图3-8

这个测试方法只是其他测试技术的一个补充。

3.6.1功能图法

程序的功能组成：静态说明（输入数据的次序）+动态说明（输入条件和输出条件间的关系）

功能图法使用 功能图 形式化地表示程序的功能说明，并按照 图覆盖原理 生成测试用例。

图覆盖准则：1.节点覆盖 2.边覆盖 3.路径覆盖

功能图模型由状态迁移图和逻辑功能模型组成。

功能图法深入了解看p66

3.6.2模糊测试

通过自动产生数据的模板来构造数据作为系统的输入，从而检验在个中数据情况下是否有问题。

模糊测试工具的工作过程：

1.测试工具通过随机的方式产生大量的数据。

2.测试工具将生成的数据发生给被测试系统。

3.测试工具检测被测系统的状态。

4.根据被测系统的状态判断是否存在潜在的安全漏洞。

可以使用的模糊测试工具：AFL效率最高的工具。

3.7形式化测试方法

形式化方法的基础是数学和逻辑学，它的产生就是解决基于自然语言的设计和描述带来的问题，统一建模语言UML可以看作是一种半形式化的方法。

3.7.1形式化方法

凡是采用严格的数学 语言，具有精确的数学语义方法，都称为形式化方法。

形式化规范说明语言组成：

1.语法。2.语义。3.一组关系。详细见p69

形式化方法可以分为：

1.基于建模的方法。2.代数方法。3.过程代数方法。4.基于逻辑的方法。5.基于网络的方法。

3.7.2形式化验证

形式化验证被作为生成软件规格说明书，然后将其作为软件开发的基础和软件测试验证的依据。

软件测试无法证明系统不存在缺陷，只有形式化验证过程可以证明一个系统不存在某个缺陷。

所以测试人员能做的就是 1.证明一个系统 不存在 可以想到的缺陷，2.验证满足系统质量要求的属性。

目前关于形式化验证方法的研究：

有限自动机，uml语义转换形式化验证等。

第四章软件测试流程和规范

在传统的数据模型中，软件测试只能用动态测试，那些现在被淘汰啦。

现在软件测试贯穿整个软件生命周期，包括测试左移和右移。

1.测试左移：需要测试人员做更多测试工作，而且需要做需求评审，设计评审，以及验收测试驱动开发。

2.测试右移：即在线测试，包括在线性能监控与分析，A/B测试和日志分析等。软件测试贯穿于整个软件开发过程，可以减少软件缺陷数量，提高软件质量，而且可以减少开发周期，降低开发成本。

本章讲述：软件测试过程模型，讨论传统的软件测试过程和敏捷测试过程，进而扩展DevOps和持续测试，然后讨论测试过程改进模型TMMi，TPI，最后讨论软件测试和质量标准，软件测试规范等。

4.1传统的软件流程和规范

两个角度了解软件测试的基本过程：

在实际的工作中有些流程是一起进行，或者交替进行的，不过基本的流程是这样的。

 为啦更好理解软件开发过程的特性，必须建立合适的模型。模型是对事物的一种抽象，在建造事物之前，先建立一个简化的模型，忽略细节，去掉与问题无关的东西，让模型和现实的实体相比起来简单明了，这样能了解它的本质，抓住主要问题。可以防止人们过早陷入各个模块的细节，让人们从全局上把握系统的全貌以及相关部件的关系。

总的来说就是构建一个东西的时候，先构建模型，这样就可以了解事物的全貌，做出大概之后再去弥补细节的东西，把主要的部分先构造出来。能够了解各部件之间的关系。

接下来讲解每种模型

4.1.1w模型

w模型前身的v模型，它增加啦软件 每个开发阶段中，应该同步进行的验证活动和确认活动。

如图：

这个是w模型，由两个v模型构成，分别为开发过程的v模型（实线）和测试过程的v模型（虚线）

在开发过程每个阶段进行对应需要同步的测试过程的那个阶段，比如：需求分析阶段与需求测试阶段同步进行。

这两个过程都贯穿软件过程的整个生命周期，它们相辅相成相互依赖。

主要概括一下三点：

(1)测试过程和开发过程是同时开始、同时结束的,两者保持同步的关系。
(2)测试过程是对开发过程中阶段性成果和最终的产品进行验证的过程,所以两者是
相互依赖的。前期,测试过程更多地依赖于开发过程;后期,开发过程更多地依赖于测试
过程。
(3)测试过程中的工作重点和开发工作的重点可能是不一样的,两者有各自的特点。不
论在资源管理,还是在风险管理,两者都存在着差异。

概括起来就是：测试过程和开发过程同步进行，相互依赖，侧重点不一样。

4.1.2TMap（测试 管理方法）

它是一种业务驱动的、结构化的、基于风险策略的测试方法体系, 目的能更早地发现缺陷，以最小的成本、有效地、彻底地完成测试任务，以减少软件发布后的支持成本。

它所定义的TMsp的测试生命周期组成：计划和控制，基础设施，准备，说明，执行和完成阶段。

下面是各阶段需要做的事情图示

详细内容：

TMap可以根据环境创建量身定制的测试方法，在不同的特定环境中可以采用通用的方法，从而适合于各行业以及各种规模的组织。

它的三大基石：O ,I ,T支撑整个生命周期L

1. 测试活动生命周期（L）：描述啦在测试过程的某些特殊阶段需要实施的活动。

2.组织融合（O）：强调测试小组融入项目组织中，每个成员都必须被分配任务。

3.正确的基础设施和工具（I）：测试环境要稳定，可控制有代表性，通过工具的使用提高测试的有效性。

4.可用的技术（T）：支持测试过程的技术，这些技术的作用：1.定义基于风险的测试策略。2.至支持有计划的测试过程。3.研究和审查测试基准。4.详细说明测试用例以及如何提交报告。

在TMap基础上还开发啦其他的方法：TPI,TAKT,Tsite等。

4.2敏捷测试过程

它是为啦使用敏捷开发而设计的软件测试解决方案。

敏捷测试是一种在敏捷开发环境中进行软件测试的方法，强调持续测试、快速反馈和合作开发。

4.2.1敏捷测试的价值观和原则

这里主要讲述敏捷测试的一些原则，只有遵守这些原则才能更好地跟敏捷开发合作。具体在书本p81，也可网上查

4.2.2传统测试和敏捷测试区别

单元测试是敏捷测试地基础，也就是开发人员承担更多地测试。

它们地区别：

1.传统测试分开发人员和测试人员，而敏捷测试不分，强调整个团队对测试负责。

2.传统地测试强调阶段性，一个一个阶段往前推进。而敏捷测试强调持续测试，持续的质量反馈，无明确的阶段性界限。

其他区别在p82页

4.2.3敏捷测试流程

敏捷测试的流程中，要参与单元测试，关注持续迭代的新功能，针对这些新功能进行足够的验收测试，对原有功能的回归测试就需要使用自动化测试。敏捷开发流程中，阶段性不够明显，持续测试和持续质量反馈的特征明显。

以敏捷Scrum为例理解敏捷测试的流程：

整个流程中，只有验收测试阶段有明显的测试特征。

对图片的流程进行解读：

1.Product Backlog（需求定义阶段）：测试需要考虑：用户的优先级，估算工作量，研究与产品相关的用户的行为模式，产品质量需求，相关的竞争产品等。

2.Sprint Backlog（迭代任务划分和安排）：明确具体待实现的具体功能特性和任务，测试需要特别关注任务完成的验收标准（任务结束的要求），特别是功能特性的设计和代码实现的验收标准要特别关注。

3.在每个迭代实施阶段，主要完成sprint backlog的任务，这时要完成：TDD和单元测试，持续集成测试。

4.敏捷的验收测试，侧重点在于对一个功能特性是都真正完成进行验证，敏捷的验收测试是在研发环境中进行的，可以考虑追加一个完整的回归测试。

4.2.4 SBTM

敏捷测试过程中，新功能的测试通过探索式测试为主，为啦解决一些问题就建立啦一套流程来管理探索式测试，通过基于会话的测试管理（SBTM）方法

这个框架的示意图：

对图片的解析：在测试计划之后，是每个带着小目标的测试活动，这些小目标最终是为啦实现总测试目标而设立的。

每个特定的测试子目标由一个或者多个Session完成，一个Session是一段测试活动，每个Session关联着一个任务（mission）一系列Session相互支持，组合在一起，完成测试整个产品的各项任务。所以这里的Session和mission都需要设计。设计出来的Session需要描述，这种描述看作是对Session执行的指导书，在SBTM中称为Charter（章程）。

他们之间的关系如图：

设计Mission和Charter可以从功能特性，用户故事，操作场景出发进行测试，目标：能够覆盖测试需求分析整理出的所有测试项，最终目标是覆盖产品的所有功能特性。

在探索式测试中，每个人，session都是独立的，基于这是需要采用角色扮演来模拟客户的业务处理逻辑，所以基于场景的测试设计方法在这里比较合适。

4.3软件测试学派

分析学派（Analytic School）：认为软件是逻辑性的，将测试看做计算机科学和数学的一部分，结构化测试、代码覆盖率就是其中一些典型的例子。他们认为测试工作是技术性很强的工作，侧重使用类似UML工具进行分析和建模。

标准学派（standard school）：从分析学派分离出来并得到IEEE的支持，把测试看做侧重劣质成本控制并具有可重复标准的、旨在衡量项目进度的一项工作，测试是对产品需求的确认，每个需求都要得到验证。

质量学派（Quality School）：软件质量需要规范，测试就是过程的质量控制、揭示项目质量风险的活动，确定开发人员是否遵守规范，测试人员扮演产品质量的守门员角色。

上下文驱动学派（Context-Drive School）：认为软件是人创造的，测试所发现的每一个缺陷都和利益者密切相关，认为测试是一种有技巧的心理活动；强调人的能动性和启发式测试思维，探索性测试就是典型的代表。

敏捷学派（Agile School）：认为软件就是持续不断的对话，而测试就是验证开发工作是否完成，强调自动化测试，TDD是典型代表。

工厂学派（Factory School）：强调将测试任务演化成一系列的操作过程，然后这些操作过程自动化以后，获得廉价的劳动力来执行测试。

控制学派（Control School）：强调标准和依据标准建立的流程，类似标准学派。

测试驱动学派（Test-Drive School）：强调以代码为焦点的测试，且程序员执行测试，类似敏捷测试。

4.4软件过程改进

在软件过程的不断改进下，SEI推出啦软件能力成熟度模型（CMM），它逐渐成为评估软件开发过程的管理以及工程能力的标准。现在形成啦PSP,TSP,CMMI等为主导的软件开发过程改进体系。

许多研究机构和测试服务机构分别提出啦有关软件测试方面能力成熟度模型。这是对SEI-SMMI的有效补充。

下面进行讨论测试过程改进的几种模型

4.4.1 TMMI

我们需要了解概念：

1.过程能力：它描述啦 遵循 一个软件测试过程 可能达到的 预期结果的 范围。

了解它对于预测产品质量十分关键。也就是过程能力说明啦，如果你按照一个标准的测试流程走，你就可以达到你测试目标预期的范围，也就是测试的软件质量怎么样。

组织的过程能力 给 组织接到的新项目 能否达到工作的预期结果 提供啦 预测依据。

一个可以预测的过程需要有一致的执行，如果过程不稳定，需要由检查过程的一致性开始。过程一致性检查可以从一下方面检查：

1.执行过程的适宜性检查。

2.已定义过程的应用度量

3.过程评审和纠正。

很多组织没有意识到测试流程的全部潜力，因为这些过程往往不成熟。而TMM就是解决这些问题的模型。

借助TMM模型可以协助评估改善 软件测试流程软件组织。

TMM将测试过程成熟度分为5个等级：如下图所示，每一个等级都有特定的过程域，组织升级到下一个的等级需要满足前一个等级的过程域，想要升级到特定的等级需要实现预先定义好的成熟度目标和附属目标。

TMM组成：

由5个级别的一堆测试能力成熟度的定义和一套评价模型组成。

其中：每个级别由：到期目标，到期子目标活动，任务和职责等组成。评价模型中应包括：成熟度问卷，评估程序和团队选拔培训指南。

TMMI基础（www.tmmi.org）定义啦tmm的接替标准。说白啦TMMI就是TMM的升级版，比它更加细节。

有一个伊利的组织总结了TMM和CMMI中相应过程域的实践经验，包含以下两个主要文档：

1.TMMI参考模型。2.TMMi评估方法应用需求。

4.4.2 TPI

TPI是业务驱动的，基于 连续性表示法的 测试过程改进 的参考模型。

TPI的作用:1.用于支持测试过程的改进，2.用于了解组织内测试过程的成熟度。

它有助于定义渐进的，可控的改进步骤。

它的构成：

下面对这个结构进行讲解：

1.关键域：

通过对不同方面的评估，让测试过程的优点和缺点都变得清晰，这些不方面就是关键域。就是一个方面就是一个关键域：如：测试策略方面，估算和计划方面，他们两个都是关键域。

测试过程分成16个需要明确的关键域，基线和改进都是基于下面这16个关键域进行的。

2.级别;

关键域的评估结果通过级别来体现。

测试级别由A-M，A最低级。等级的评估方式：

1.对于部分的关键域级别描述，可能达不到初始A级的要求。有些只能评为A或B级。

2.对于一些给定的 关键领域 的评估，可以通过TPI模型定义的检查点来进行评估。

TPI定义啦很多过程和等级之间的依赖关系，这些依赖关系保证啦测试过程的均衡发展。也就是说每个关键域等级之间有个依赖关系，某个关键域达不到一定的等级，另外一个关键域的等级就会被受影响。

3.测试成熟度矩阵

它提供一种映射关系，关键域每个等级和总体测试过程成熟度等级之间的关系映射。

它可以很好的帮助我们定义内在的优先级，以及级别和关键域之间的依赖关系。

4.检查点

作用：为啦能客观的决定每个关键域的 级别。

每个级别都有检查点，测试过程要满足这些检查点才算达到特定的级别。

5.建议

检查点帮助我们发现测试过程中的问题，建议会帮助我们解决问题，最终改进测试过程。

4.4.3 CTP

关键测试过程评估模型（CTP）它是一个内容参考模型。

4.4.4 STEP

以上两个模型不做详细介绍。

4.5软件测试规范

这里讲解的内容参考于计算机软件测试规范。其中包括软件测试的每个子过程中的测试人员的角色，职责，活动描述以及所需要的资料。

1.角色

也就是划分角色进行安排职责。一般按照这个图片的方式划分

2.进入准则

也就是确立软件测试的切入点。软件项目立项并得到批准就意味着软件测试开始啦。

3.输入项

软件测试需要有相关的文档，这些文档都作为软件测试的输入。

4.活动

1.制定测试计划 2.测试设计 3.实施测试 4.执行单元测试 5.执行集成测试 6.执行系统测试 7.评估测试 5.输出项 ：与输入项的文档资料相对应。6.验证与确认 7.退出准则 8.度量。

以上具体内容看p97-p99