软件评测师知识点汇合（部分笔记）

软件评测
上午题理论篇
第一章 软件测试概论
1.1概论
测试是为发现错误而执行的一个程序或者系统的过程。
测试是以评价一个程序或者系统属性为目标的任何一种活动，测试是对软件质量的度量。
测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施和维护整个生命周期过程。
1.3软件测试与软件项目的关系
软件测试为软件项目服务。
软件测试的目的是为了发现软件中存在的错误，但是，其根本是为了提高软件质量，降低软件项目的风险。
软件质量的风险表现在：
①内部风险（在即将销售的时候发现有重大的错误，从而延迟发布日期，失去市场机会）
②外部风险（用户发现了不能容忍的错误，引起索赔、法律纠纷，以及用于客户支持的费用甚至失去客户的风险）
软件测试只能证明软件存在错误，而不能证明软件没有错误。
1.5第三方测试
第三方测试是指独立于软件公司自身测试的测试。
第二章 软件测试基础
2.1软件测试与软件质量
2.1.1什么是软件测试
软件是由文档、数据以及程序组成的，那么软件测试就应该是对软件形成过程的文档、数据以及程序进行测试，而不仅仅是对程序进行的测试。
2.1.2什么是软件质量
软件质量：（ISO9126）软件满足规定或潜在用户需求特性的总和；（ISO14598）软件特性的总和，软件满足规定或潜在用户需求的能力。
一般对“质量”的理解是一个实体的“属性”，“属性”好就是质量好的。但是这不够全面，“属性”是内在特性，内在特性好，不一定能胜任和完成用户的任务。
软件质量包括内部质量、外部质量和使用质量三部分。
2.1.3软件测试与质量保证的区别
是软件质量工程的两个不同层面的工作。
·质量保证（QA）:质量保证的重要工作通过预防、检查与改进来保证软件质量。
QA的工作是软件生命周期的管理以及验证软件是否满足规定的质量和用户的需求。
软件测试：关心的不是过程的活动，而是对过程的产物以及开发出的软件进行剖析。
2.2 软件测试目的
早期的软件定义指出软件测试的目的是寻找错误，并且尽最大的可能去找出最多的错误。
就软件测试提出以下观点：
·测试是程序的执行过程，目的在于发现错误；
·一个好的测试用例在于能发现至今未发现的错误；
·一个成功的测试是发现了至今未发现的错误的测试。
2.3 软件测试原则
①所有的软件测试都应该追溯到用户需求。
②尽早地和不断地进行软件测试。
③完全测试是不可能的，测试需要终止（不可能的原因：输入量太大；输出结果太多；路径组合太多）。
④测试无法显示软件潜在的缺陷。
⑤充分注意测试中的群集现象。
⑥程序员应避免检查自己的程序。
⑦尽量避免测试的随意性（有组织、有计划、有步骤的活动）。
2.4 软件测试对象
需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为**“软件测试”的对象**。
为了把握各个环节的正确性，人们需要进行各种验证和确认工作。
验证是为了保证软件正确实现特定功能的一系列活动和过程，目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段所设定的目标。
确认是保证软件满足用户需求的一系列的活动和过程，目的是在软件开发完成后保证软件与用户需求相符合。
验证与确认都属于软件测试，它包括对软件分析、设计以及程序的验证和确认。
2.5 软件测试分类
测试对象应该包括软件设计开发的各个阶段的内容。
2.5.1按照开发阶段划分
单元测试、集成测试、系统测试、确认测试和验收测试。
①单元测试又称模块测试，是针对软件设计的最小单位——程序模块进行正确性检验的测试工作。
单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
②集成测试又称组件测试。在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。
集成测试是检验程序单元或部件的接口关系。
在每个版本提交时，都需要进行冒烟测试，即对程序主要功能进行验证。冒烟测试也叫版本验证测试、提交测试。
③确认测试是通过检验和提供客观证据，证实软件是否满足预定用途的需求。确认测试是检测与证实软件是否满足软件需求说明书中规定的要求。
④系统测试是为验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试。
系统测试是在真实或模拟系统运行的环境下，检查完整的程序系统能否和系统（包括硬件、外设、网络和系统软件、支持平台等）正确配置、链接，并满足用户需求。
⑤验收测试，按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。
2.5.2按照测试实施组织划分
开发方测试、用户测试（β测试）、第三方测试。
开发方测试（验证测试、α测试），验证测试是在软件开发环境下，有开发者检测与证实软件的实现是否满足软件设计说明或者软件需求说明的要求。主要是指在软件开发完成以后，开发方对要提交的软件进行全面的自我检查与验证，可以和软件的“系统测试”一并进行。
用户测试不是指用户的“验收测试”，而是指用户的使用性测试，由用户找出软件的应用过程中发现的软件的缺陷与问题，并对使用质量进行评价。
β测试通常被看成一种“用户测试”。主要是把软件产品有计划地免费分发到目标市场，让用户大量使用，并评价、检查软件。
第三方测试介于软件开发方和用户方之间的测试组织的测试。第三方测试也称为独立测试。
软件质量工程强调开展独立验证和确认（IV&V）活动。
2.5.3 按照测试技术划分
白盒测试、黑盒测试、灰盒测试；也可划分为静态测试和动态测试。
静态测试：不运行程序，通过人工对程序和文档进行分析与检查；静态测试技术又称静态分析技术，静态测试实际上是对软件中的需求说明书、设计说明书、程序源代码等进行非运行的检查；
静态测试包括：走查、符号执行、需求确认等。
动态测试是指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现。
白盒测试、黑盒测试、灰盒测试，在实现测试方法上既包括了动态测试也包括静态测试。
白盒测试（结构测试）：通过对程序内部结构的分析、检测来寻找问题。
黑盒测试：通过软件的外部表现来发现其缺陷和错误。（不考虑内部结构）在程序界面处进行测试，只是检查样序是否按照需求规格说明书的规定正常实现。
灰盒测试：介于白盒测试与黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性，同时关注内部表现。
开发文档和源程序可以应用单元测试应用走查的方法；
单元测试可应用白盒测试方法；
集成测试应用近似灰盒测试方法；
系统测试和确认测试应用黑盒测试方法。
2.6软件测试过程模型
2.6.1 V模型（软件开发瀑布模型的变种）

V模型的软件测试策略既包括低层测试又包括高层测试，低层测试是为了源代码的正确性，高层测试是为了使整个系统满足用户的需求。（V模型不能体现“尽早地和不断地进行软件测试”的原则）
2.6.2 W模型

2.6.3 H模型

H模型揭示了：
·软件测试不仅仅指测试的执行，还包括很多其他的活动。
·软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。
·软件测试要尽早准备，尽早执行。
·软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。
在H模型中，软件测试模型是一个独立的流程，贯穿于整个产品周期，与其他流程并发地进行。当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。
2.6.4 其他模型
1.X模型

X模型左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后，将进行频繁的交接，通过集成最终合成为可执行的程序。
X模型定位了探索性测试。
2.前置测试模型

·开发和测试相结合:前置测试模型将开发和测试的生命周期整合在一起，标识了项目生命周期从开始到结束之间的关键行为。
·对每一个交付内容进行测试:每一个交付的开发结果都必须通过一定的方式进行测试。
·在设计阶段进行测试计划和测试设计:很多组织要么根本不作测试计划和测试设计，要么在即将开始执行测试之前才飞快地完成测试计划和测试设计。在这种情况下，测试只是验证了程序的正确性，而不是验证整个系统本该实现的东西。
·浏试和开发结合在一起:前置测试将测试执行和开发结合在一起，并在开发阶段以编码——测试——编码——测试的方式来体现。也就是说，程序片段一旦编写完成，就会立即进行测试。
·让验收浏试和技术测试保持相互独立:验收测试应该独立于技术测试，这样可以提供双重的保险，以保证设计及程序编码能够符合最终用户的需求。验收测试既可以在实施阶段的第一步来执行，也可以在开发阶段的最后一步执行。
2.7 软件生命周期测试策略
2.7.1 软件开发与软件测试

2.7.2 软件测试策略
软件测试经历的4个步骤：单元测试、集成（组装）测试、确认测试、系统测试。

1.测试信息流

软件配置:包括软件需求规格说明、软件设计规格说明、源代码等。
测试配置:包括测试计划、测试用例、测试驱动程序等。
测试工具:为提高软件测试效率，可使用测试工具支持测试工作，其作用就是为测试的实施提供某种服务，以减轻测试任务中的手工劳动。
2.分析设计阶段
分析设计阶段的测试工作是评审与测试相结合的过程，主要包括需求说明书评测、概要设计说明书评测、详细设计说明书评测以及软件编码规范评测等。
（1）需求说明书评测
·需求说明书的框架

·需求说明书评测内容
（主内）
①系统定义的目标是否与用户的要求一致;
②系统需求分析阶段提供的文档资料是否齐全;
③文档中的所有描述是否完整、清晰，准确地反映用户要求;
④与所有其他系统成份的重要接口是否都已经描述;
⑤被开发项目的数据流与数据结构是否足够、确定;
⑥所有图表是否清楚,在不补充说明时能否理解;
⑦主要功能是否已包括在规定的软件范围之内，是否都已充分说明;
⑧软件的行为和它必须处理的信息、必须完成的功能是否一致；
⑨设计的约束条件或限制条件是否符合实际;
⑩是否考虑了开发的技术风险;
11是否考虑过软件需求的其他方案；
12是否考虑过将来可能会提出的软件需求;﹒
13是否详细制定了检验标准，它们能否对系统定义是否成功进行确认;
14有没有遗漏、重复或不一致的地方;
15用户是否审查了初步的用户手册或原型；
16项目开发计划中的估算是否受到了影响。
·需求说明书评测规范


（2）概要设计说明书评测
·软件设计规格说明大纲

·概要设计说明书评测的内容
可追溯性、接口、风险、实用性、技术清晰度、可维护性、质量、各种选择方案、限制、其他具体问题（对文档、可测试性、设计过程等进行评估）
为评测设计是否达到目标，必须建立衡量设计的技术标准。如下:1.设计出来的结构应是分层结构，从而建立软件成分之间的控制。
2.设计应当模块化，从逻辑上将软件划分为完成特定功能或子功能的构件。
3.设计应当既包含数据抽象，也包含过程抽象。
4.设计应当建立具有独立功能特征的模块。
5.设计应当建立能够降低模块与外部环境之间复杂连接的接口。
6.设计应能根据软件需求分析获取的信息，建立可驱动、可重复的方法。

（3）详细设计说明书评测


（4）软件编码规范评测
程序良好的风格表现在源程序文档化、数据说明的方法、语句结构和输入/输出方法这四个方面。
·源程序文档化
①符号名的命名（符号名即标识符，包括模块名、变量名、常量名、标号名、子程序名、数据区名以及缓冲区名等）
精炼，意义明确的名字、必要时使用缩写
②程序的注释（注释绝不是可有可无的。一些正规的程序文本中，注释行的数量占到整个源程序的1/3~1/2，甚至更多。注释分为序言性注释和功能性注释。）
序言性注释通常置于每个程序模块的开头部分，它应当给出程序的整体说明，对于理解程序本身具有引导作用。
功能性注释嵌在源程序体中，用以描述其后的语句或程序段是在做什么工作，或是执行了下面的语句会怎么样。
③标准的书写格式
·数据说明
①数据说明的次序应当规范化。
②说明语句中变量安排有序化。
③使用注释说明复杂数据结构。
·语句说明
·输入输出（与用户使用直接相关）
不论是批处理的输入/输出方式，还是交互式的输入/输出方式，在设计和程序编码时都应考虑下列原则。
①对所有的输入数据都要进行检验，识别错误的输入，以保证每个数据的有效性;
②检查输入项的各种重要组合的合理性，必要时报告输入状态信息;
③使输入的步骤和操作尽可能简单，并保持简单的输入格式;
④输入数据时，应允许使用自由格式输入;
⑤应允许缺省值;.
⑥输入一批数据时，最好使用输入结束标志，而不要由用户指定输入数据数目；
⑦在交互式输入时，要在屏幕上使用提示符，明确提示交互输入的请求，指明可使用选择项的种类和取值范围。同时，在数据输入的过程中和输入结束时，也要在屏幕上给出状态信息;
⑧当程序设计语言对输入/输出格式有严格要求时，应保持输入格式与输入语句要求的一致性；
⑨给所有的输出加注释，并设计输出报表格式。
3.开发阶段
（1）单元测试（模块测试）
主要采用白盒测试的测试用例。辅之以黑盒测试的测试用例。

①模块接口测试
②局部数据结构测试
（模块的局部数据结构是最常见的错误来源，应设计测试用例以检查以下各种错误:
不正确或不一致的数据类型说明；
使用尚未赋值或尚未初始化的变量；
错误的初始值或错误的缺省值；
变量名拼写错或书写错；
不一致的数据类型。
可能的话，除局部数据之外的全局数据对模块的影响也需要查清）
③路径测试
④错误处理测试
⑤边界测试
通常单元测试是在编码阶段进行的。
模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与所测模块相联系的其他模块。这些辅助模块分为两种:
驱动模块(driver)——相当于所浏模块的主程序。它接收测试数据，把这些数据传送给所测模块，最后再输出实测结果。
桩模块（stub)一一也叫做存根模块。用以代替所测模块调用的子模块。

（2）集成测试（组装测试或联合测试）
在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。
子系统的集成测试称为部件测试，它所做的工作是要找出组装后的子系统与系统需求规格说明之间的不一致。
·模块组装成为系统的方式有两种：一次性组装方式和增值式组装方式。
①一次性组装方式
它是一种非增值式组装方式，也叫做整体拼装。
先对每个模块分别进行模块测试，再把所有模块组装在一起进行测试。

（a）模块系统结构
（b）单元测试和组装顺序
模块d1、d2、d3、d4、d5是对各个模块做单元测试时建立的驱动模块
s1、s2、s3、s4、s5是为单元测试而建立的桩模块。
②增值式组装方式又称渐增值式组装
自顶向下的增值方式（将模块按系统程序结构，沿控制层次自顶向下进行组装）

自顶向上的增值方式（从程序模块结构的最底层模块开始组装和测试）

混合增值式测试
自顶向下的增值方式
缺点：需要建立桩模块，桩模块模拟实际子模块的功能十分困难
优点：能够较早地发现主要控制方面的问题
自顶向上的增值方式
缺点：程序一直未能作为一个实体存在，直到最后一个模块加上去后才形成一个实体
优点：不需要桩模块，建立驱动模块一般比建立桩模块容易
·集成测试完成的标志主要有以下几项：
①成功地执行了测试计划中规定的所有集成测试。
②修正了所发现的错误。
③测试结果通过了专门小组的评审。
集成测试需要提交的文档有集成测试计划、集成测试规范和集成测试分析报告。
（3）确认测试
确认测试的任务是验证软件的功能和性能及其他特性是否与用户的要求一致。
确认测试一般由独立的第三方测试机构进行。
·进行有效性测试（黑盒测试方法）
·软件配置复查
软件配置复查的目的是保证软件配置的所有成分都齐全，各方面的质量都符合要求，具有维护阶段所必须的细节，而且已经编排好分类的目录。
（4）系统测试
系统测试的目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或与之矛盾的地方。
（5）验收测试
以用户为主的测试。
软件开发人员和质量保证人员也应参加。
由用户参加设计测试用例。
使用用户界面输入测试数据，并分析测试的输出结果。
一般使用生产中的实际数据进行测试。
验收测试往往在系统测试完成后、项目最终交付前进行。
4.软件验证与确认（V&V）过程
（1）V&V基本概念
验证:通过检查和提供客观证据，证实规定的需求己满足。
确认:通过检查和提供客观证据，证实预期用途的需求是否得到满足。
独立验证和确认:由在技术、管理和财务上与开发组织有规定程度独立性的组织执行的V&V过程。
（2）软件V&V过程

（3）软件V&V过程中的测试
测试过程（4个）

（4）软件测试V&V活动
测试V&V活动覆盖了集成测试、系统测试、验收测试
2.8 软件失效分类与管理
2.8.1 软件失效分类
①软件错误（人为错误）
是指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。
软件错误是一种人为过程，相对于软件本身，是一种外部行为。
②软件缺陷
软件缺陷是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差，如少一逗点、多一语句等。
软件缺陷的情况：
①软件未达到产品说明书中标明的功能；
②软件出现了产品说明书中指明的不会出现的错误；③软件功能超出了产品说明书指明的范围；
④软件未达到产品说明书虽未指出但应达到的目标；
⑤软件测试人员认为软件难以理解、不易使用、运行速度慢，或最终用户认为不好使用。
③软件故障
是指软件运行过程中出现的一种不希望或不可接受的内部状态。
④软件失效
是指软件运行时产生的一种不希望或不可接受的外部行为结果。
2.8.3 缺陷与错误严重性和优先级
给软件缺陷与错误规划严重性和优先级的通用原则是：
①表示软件缺陷所造成的危害的恶劣程度;
②优先级表示修复缺陷的重要程度与次序。
·严重级。
①严重:系统崩溃、数据丢失、数据毁坏。
②较严重:操作性错误、错误结果、遗漏功能。
③一般:小问题、错别字、UI布局、罕见故障。
④建议:不影响使用的瑕疵或更好的实现。
·优先级。
①最高优先级:立即修复，停止进一步测试。
②次高优先级:在产品发布之前必须修复。
③中等优先级:如果时间允许应该修复。
④最低等优先级:可能会修复,但是也能发布。
2.8.4 软件错误跟踪管理
1.错误跟踪管理
（1）Bug记录信息
主要包括以下几项内容：
测试软件名称；测试版本号；测试人名称；测试事件；测试软件和硬件配置环境；发现软件错误的类型；错误的严重等级；详细步骤；必要的附图；测试注释。
（2）Bug处理信息
主要包括以下4项内容：
处理者姓名；处理时间；处理步骤；错误记录的当前状态。
2.软件错误的状态
软件错误的主要状态包括以下内容：
·新信息（New):测试中新报告的软件Bug。
·打开(Open):被确认并分配给相关开发人员处理。
·修正（Fixed):开发人员已完成修正，等待测试人员验证。
·拒绝（Declined):拒绝修改Bug。
·延期(Deferred):不在当前版本修复的错误，下一版修复。
·关闭(Closed):Bug已被修复。
3.错误管理流程
错误管理的流程可以概括为以下几项内容。
·测试人员提交新的错误入库，错误状态为“New"。
高级测试人员验证错误。
①如果确认是错误，分配给相应的开发人员，设置状态为“Open”。
②如果不是错误，则拒绝，设置为“Declined”状态。
·开发人员查询状态为“Open”的错误，做如下处理。
①如果不是错误，则置状态为“Declined”。
②如果是错误，则修复并置状态为“Fixed”。
③如果不能解决的错误，要留下文字说明并保持错误为“Open”状态。
④对于不能解决和延期解决的错误，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。
·测试人员查询状态为“Fixed”的错误，验证错误是否已解决，做如下处理。
①如问题解决了，置错误的状态为“Closed”。
②如问题没有解决，则置状态为“Reopen”。
4.错误流程管理原则
①为了保证错误处理的正确性，需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误，书写的测试步骤是否准确，可以重复。
②每次对错误的处理都要保留处理信息，包括处理姓名、时间、处理方法、处理意见、Bug状态。
③拒绝或延期处理错误不能由程序员单方面决定，应该由项目经理、测试经理和设计经理共同决定。
④错误修复后必须由报告错误的测试人员验证，确认已经修复后，才能关闭错误。
2.9白盒测试（也称结构测试或逻辑驱动测试）内部
常用的软件测试方法有两大类：静态测试方法和动态测试方法。
2.10 黑盒测试（也称功能测试）外部，主要针对软件界面和软件功能进行测试。
黑盒测试法注重于测试软件的功能需求，主要试图发现下列几类错误：
功能不正确或遗漏;
界面错误;
数据库访问错误;
性能错误;
初始化和终止错误等。
黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法。
等价类划分的办法是把程序的输入域划分成若干部分,然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。
边界值分析是通过选择等价类边界的测试用例。边界值分析法不仅重视输入条件边界，而且也必须考虑输出域边界。
错误推测设计方法就是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。
因果图方法是从用自然语言书写的程序规格说明的描述中找出因(输入条件）和果输出或程序状态的改变)，可以通过因果图转换为判定表。
正交试验设计法，就是使用已经造好了的正交表格来安排试验并进行数据分析的一种方法，目的是用最少的测试用例达到最高的测试覆盖率。
2.11 自动化测试
··优点：
提高测试质量；提高测试效率，缩短测试工作时间；提高测试效率；提高测试覆盖率；执行手工测试不能完成的测试任务；更好地重现软件缺陷的能力；更好地利用资源；增进测试人员与开发人员之间的合作伙伴关系。
··局限性：
定制型项目；周期很短的项目；业务规则复杂的对象；人体感观与易用性测试；不稳定的软件；涉及物理交互。
··自动化测试工具分类：
·负载压力测试工具：LoadRunner、QAload、SILKPERFORMA V和E-Test Suite等。
·功能测试工具：WinRunner、QARun
·白盒测试工具：
静态测试工具（对代码进行语法扫描）代表有Logiscope软件和PRQA软件；
动态测试工具（插桩）代表有DevPartner、Rational Purify
·网络测试工具：
这类工具主要包括网络故障定位工具、网络性能监测工具、网络仿真模拟工具等。
·测试管理工具：TestDirector、TestManger、TrackRecord
·测试辅助工具：生成测试数据，为测试提供数据准备。
2.11.4 功能自动化测试
环境判断模式、模拟模式（创建脚本、调试脚本、执行测试、结果分析）
2.11.5 负载压力自动化测试
进程回放模式、线程回放模式
录制回放模式必须经历的几个操作步骤：
协议选择、创建测试脚本、参数化测试数据、创建虚拟用户、执行测试、结果分析。
第3章 软件质量与评价（软件测试标准）
3.1 质量的定义
软件质量：实体特性的总和，满足明确或隐含要求的能力。
3.2 测度与质量
软件工程中使用的“度量”有多种含义，在软件质盘中用于测量的一种量化的标度和方法即为“测度”，而名词的“度量”用来指测量的结果。
3.3 软件质量模型
影响软件质量的因素可以分为两大类：可直接测量（如每个功能点的错误）和间接度量（如可用性、可维护性）。
集中在软件产品的三个重要方面：操作特性（产品运行）、承受可改变能力（产品修订）、新环境适应能力（产品变迁）。


3.5 GB/T 18905产品评价
GB/T 18905-2002《软件工程 产品评价》
该系列标准由以下6个部分组成：
1.概述 2.策划和管理 3.开发者用的过程 4.需方用的过程 5.评价者用的过程 6.评价模块的文档编制
3.5.4 通用评价过程
软件产品的一般评价过程是：确立评价需求，然后，规定、设计和执行评价，如下图：

3.5.6 确定要评价产品的类型

3.5.8 规定质量模型
软件评价所用的质量模型通常代表软件质量属性的总体，这些质量属性用特性和子特性的分层树结构进行分类。
6种软件质量特性:功能性、可靠性、易用性、效率、可维护性和可移植性。

软件产品的内部质盘属性是软件产品的可测量的性质，这些性质影响产品满足明确和隐含要求的能力。可以用一个或更多的属性来评估一个特定的软件质量特性或子特性。

3.6 GB/T 16260.1 产品质量
GB/T 16260-2003《软件工程 产品质量》，该系列标准由以下4部分组成：
1.质量模型 2.外部度量 3.内部度量 4.使用质量度量

3.6.4 质量模型框架
1.软件质量特性与度量
质量特性和子特性（GB/T 16260.1);
外部度量(GB/T 16260.2);
内部度量(GB/T 16260.3)。
2.质量途径

3.产品质量和生存周期

1)）用户的质量要求
可按使用质量的度量、外部度量或内部度量来规定质量需求。当验证产品时，这些由度量规定的需求应作为准则使用。
(2)外部质量需求
从外部观点来规定必须的质量级别，包括来源于用户质量要求（使用质量需求)。外部质量需求用作不同开发阶段的验证目标。
(3)内部质量需求
内部质量需求是从产品的内部观点来规定必须的质量水平。内部质量需求用来规定中间产品的属性，包括静态的和动态的模型、其他的文档和源代码。内部质量需求可用作不同开发阶段的验证目标。
(4)使用质量
使用质量是从用户观点出发。来看待软件产品用于特定环境和条件下的质量。它测量用户在特定环境中达到其任务目标的程度，而不是测量软件自身的性质。
(5)外部质量
外部质量是从外部观点出发的软件产品特性的总体。它是当软件执行时，更典型地是使用外部度量在模拟环境中，用模拟数据测试时，所被测量和评价的质量。
(6)内部质量
内部质量是从内部观点出发的软件产品特性的总体。内部质量是针对内部质量需求被测量和评价的质量。
3.6.5 外部质量和内部质量的质量模型
6种特性

1.功能性
功能性是指当软件在指定条件下使用时，软件产品满足明确和隐含要求功能的能力。
(1)适合性
适合性是指软件产品为指定的任务和用户目标提供一组合适的功能的能力。
(2）准确性
准确性是指软件产品具有所需精确度的正确或相符的结果及效果的能力。
(3)互操作性
互操作性是指软件产品与一个或更多的规定系统进行交互的能力。(4)保密安全
保密安全是指软件产品保护信息和数据的能力，以使未授权的人员或系统不能阅读或修改这些信息和数据，但不拒绝授权人员或系统对它们的访问。
(5)功能性依从性
功能性依从性是指软件产品依附于同功能性相关的标准、约定或法规以及类似规定的能力。
2.可靠性
在指定条件下使用时,软件产品维持规定的性能级别的能力。
(1)成熟性
成熟性是指软件产品避免因软件中错误的发生而导致失效的能力。(2〉容错性
容错性是指在软件发生故障或者违反指定接口的情况下，软件产品维持规定的性能级别的能力。
(3）易恢复性
易恢复性是指在失效发生的情况下，软件产品重建规定的性能级别并恢复受直接影响的数据的能力。
(4）可靠性依从性
可靠性依从性是指软件产品依附于同可靠性相关的标准、约定或规定的能力。
3．易用性
易用性是指在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。
(1)易理解性
易理解性是指软件产品使用户能理解软件是否合适以及如何能将软件用于特定的任务和使用环境的能力。
(2)易学性
易学性是指软件产品使用户能学习它的能力。
(3）易操作性
易操作性是指软件产品使用户能操作和控制它的能力。
(4)吸引性
吸引性是指软件产品吸引用户的能力。(5）易用性依从性
易用性依从性是指软件产品依附于同易用性相关的标准、约定、风格指南或规定的能力。
`4、效率
效率是指在规定条件下，相对于所用资源的数量，软件产品可提供适当的性能的能力。
(1）时间特性
时间特性是指在规定条件下，软件产品执行其功能时，提供适当的响应和处理时间以及吞吐率的能力。
(2)资源利用性
资源利用性是指在规定条件下，软件产品执行其功能时，使用合适的数量和类型的资源的能力。
(3）效率依从性
效率依从性是指软件产品依附于同效率相关的标准或约定的能力。5．维护性
维护性是指软件产品可被修改的能力。修改可能包括修正、改进或软件适应环境、需求和功能规格说明中的变化。
(1）易分析性
易分析性是指软件产品诊断软件中的缺陷或失效原因，以及判定待修改的部分的能力。
(2〉易改变性
易改变性是指软件产品使指定的修改可以被实现的能力。
(3〉稳定性
稳定性是指软件产品避免由于软件修改而造成意外结果的能力。(4)易测试性
易测试性是指软件产品使已修改软件能被确认的能力。
(5)维护性依从性
维护性依从性是指软件产品依附于同维护性相关的标准或约定的能力。
6、可移植性
可移植性是指软件产品从一种环境迁移到另外一种环境的能力。(1）适应性
适应性是指软件产品无需采用有别于为考虑该软件的目的而准备的活动或手段，就可能适应不同的指定环境的能力。
(2)易安装性
易安装性是指软件产品在指定环境中被安装的能力。
(3)共存性
共存性是指软件产品在公共环境中同与其分享公共资源的其他独立软件共存的能力。
(4)易替换性
易替换性是指软件产品在环境相同、目的相同的情况下替代另一个指定软件产品的能力。
(5)可移植性依从性
可移植性依从性是指软件产品依附于同可移植性相关的标准或约定的能力。
3.6.6 使用质量的质量模型
属性分为4种
(1)有效性
有效性是指软件产品在指定的使用环境下，使用户获得满足准确度和完整性要求的规定目标的能力。
()生产率
生产率是指软件产品在指定的使用环境下，使用户可使用与获得的有效性有关的合适数量资源的能力。
(3）安全性
安全性是指软件产品在指定使用环境下，获得可接受的对人类、事务、软件、财产或环境有害的风险级别的能力。
(4)满意度
满意度是指软件产品在指定使用环境下，使用户满意的能力。
3.7 软件测试国家标准

第4章 软件测试过程与管理
4.2 评价过程的特性
可重复性、可再现性、公正性、客观性
4.3 评价过程
4.3.1 评价活动
评价过程由下列5个活动组成：
（1）确立软件评价需求
（2）编制评价规格说明
（3）制定评价计划
（4）评价执行计划
（5）作评价结论
4.3.2 评价过程的输入
请求者提供下列评价过程的输入：
（1）软件的说明书
（2）软件的部件。软件的说明书标识的软件产品以及供评价的部件。
评价者提供下列评价过程输入：
（1）预先确定的评价规格说明
（2）评价方法
（3）评价工具
4.3.3 评价过程的输出
（1）评价记录，包括评价计划和评价动作的记录；
（2）评价报告草案，包括评价需求，评价规格说明和综合的评价结果
（3）经过评审的评价报告
4.3.4 评价过程文档
（1）评价需求（评价过程的中间产品）：描述评价的目标，特别是描述了产品的质量需求
（2）评价规格说明（评价过程的中间产品）：确定对软件及其部件实行的所有分析和测量，标识要分析和测量的软件部件
（3）评价计划（评价过程的中间产品）：描述评价规格，说明需要实施的操作规程；描述评价所需用到的方法和工具
（4）评价记录（评价过程的最终产品）：评价执行计划时详细记载的动作组成；记录由评价者保留
（5）评价报告（评价过程的最终产品）：执行测量和分析的结果，以及能被重复和重新评价的必要信息。评价报告首先作为评审草案来发布，其最终版本将交给请求者

4.5 评价过程的要求
4.5.1 一般要求
1.组织和质量体系
为了满足评价结果的可重复性、可再现性、公正性及客观性，评价者应立足于一个组织。该组织为使其活动达到充分的质量要求提供所有必要保证。
2.请求者的职责
评价请求者的职责应包括:
①为进行评价,对软件产品确立必要的合法权利；
②为标识和描述产品提供必要的信息；
③阐述最初的评价需求，并与评价者协商，确定实际的评价需求，这些评价需求宜遵守相关的法规和标准;
④阐述对评价提交的信息的保密性需求;
⑤必要时在开发者和评价者之间起中介作用:
⑥必要时向评价者提供对用于开发和操作使用软件产品的计算机和其他设备;
⑦必要时对评价者提供必要的支持，包括培训和走访;
⑧必要时确保及时提供软件、产品说明书和部件，包括文档及其他资料;
⑨必要时告知评价者可能导致评价结果无效的原因。
3.评价者的职责
评价者的职责应是:
①检查请求者对要评价执行的软件产品是否有充分合法的权利;
②按规定对请求者提供信息保密承诺，包括评价的软件、评价记录和评价报告;
③提供有资格的和经过培训的人员,以便实施评价;
④提供评价工具和技术;
⑤按照评价需求实施测试；
⑥保留评价期间影响评价结果的所有工作记录；
⑦保证及时向请求者提交评价报告。
4.5.2 评价需求确立
1.评价需求确立的目的是描述评价目标。
2.评价需求分析
分析评价需求的活动由下列5个子活动组成:
①请求者提出评价需求建议;
②请求者说明评价覆盖范围；
③评价者分析评价原因和描述评价需求来响应请求者；
④评价者解释评价的保密范围和严格程度:
⑤评价者同意评价需求。
3.评价需求内容
①评价需求应包含对评价产品应用领域的描述，以及产品用途的描述。
②评价需求应由GB/T 16260中定义为“质量特性”的一系列质量需求组成，还可能用到一些子特性。
③评价需求中的每项需求，都应提供要评价软件及部件的规格说明信息。
4.认可与报告
①评价需求应作为请求者与评价者联合评审的结果而予以承认;
②评价需求应包括在评价报告和评价记录中。
4.5.3 评价规格说明
1.规定评价规格说明的目的是定义评价范围，定义供评价产品及各种部件执行的测量。评价规格说明应详细到以此能确保评价的可重复性和可再现性。
2.评价规格说明编制
由下列3个子活动组成：
①分析产品的描述;
②规定对产品及部件执行的测量；
③按照评价需求验证编制的规格说明。
（1）产品说明分析
（2）测量规定
（3）评价者规格说明验证
3.评价规格说明的内容
评价规格说明应包括:
①评价范围，涉及在产品说明中标识的产品部件；
②评价执行所需的信息，在产品说明中列出的软件部件及其他相关文档之间的相互引用；
③要执行的测盘和验证的规格说明，以及对要评价的产品部件的引用；
④测量和验证的规格说明与评价需求之间，与引用标准或对所列的每个测量或验证的理由之间的映射。
4.认可和报告
评价规格说明应作为请求者和测试者之间联合评审的结果予以认可。
评价规格说明应包含在评价报告和评价记录中。
4.5.4 评价设计
1.评价设计目的：评价设计应把评价者使用的测量规程编成文档，以便评价执行规格说明中规定的测量。
2.制定评价计划（3个子活动）
①把评价方法编成文档，起草计划;
②优化评价计划;
③根据可用资源安排评价动作的进度。
3.认可和报告
评价计划应作为请求者或评价者之间联合评审的结果而予以认可。
4.5.5 评价执行
1.评价执行目的
评价执行目的是根据评价需求，按照评价规格说明中的规定和评价计划，从对软件产品的测量和验证中获得结果，执行这些动作将完成评价报告和评价记录的草稿。
2.评价执行者的动作
①管理请求者提供的产品部件；
②管理评价动作所产生的数据（包括报告和记录);
③管理评价执行动作的工具。
4.5.6 评价结论
1.评价结论的目的包括评价报告的评审和评价数据的处理。
2.评价报告的联合评审
评价报告的草稿应交付评价的请求者。
应组织评价者和请求者之间的联合评审。
请求者应该有机会对评价报告提出意见。
应把该评价报告交给请求者。
3.评价数据和文档的处置
①供评价的文档应归还给请求者，或者存档一个规定的期限，或者以安全的方式销毁:
②评价报告和评价记录应存档一个规定的期限;
③所有其他数据应存档一个规定的期限或以安全的方式销毁。
4.6 配置管理
软件测试过程的配置管理和软件开发过程中的配置管理是一样的。
软件测试配置管理包括4个最基本的活动：
①配置项标识:
②配置项控制(变更控制);
③配迓状态报告;
④配置审计。





4.7.3 测试组织管理者
测试组织的管理者必须具备:
·理解与评价软件测试政策、标准、过程、工具、培训和度量的能力;
·领导一个测试组织的能力，该组织必须坚强有力、独立自主、办事规范没有偏见;
·吸引并留住杰出测试专业人才的能力;
·领导、沟通、支持和控制的能力;
·测试时间、质量和成本控制的能力。
4.7.4 集中管理的测试组织

优点：软件立项后，由独立的测试组织提供资源与软件开发人员并肩作战，与合作伙伴一块行动，可以减少软件开发人员与测试人员合作时的不利因素。
4.7.5 选择合理的组织方案

4.8 软件测试风险分析
4.8.2 软件风险：开发不成功引起损失的可能性
风险分析是对软件中潜在的问题进行识别、估计和评价的过程。
软件风险分析的目的是确定测试对象、测试优先级以及测试的深度。
软件风险分析工作应由各部门的专家组成，一般包括:项目经理、开发人员、测试人员、用户、客户以及销售人员。
4.8.3 软件风险分析
风险分析包括两个部分：
①发生的可能性②影响严重性
风险分析由以下几个步骤组成:首先列出潜在问题，然后对标识的每个潜在问题发生的可能性和影响严重性赋值，进行风险测定。
风险分析采用两种方法：表格分析法和矩阵分析法
通用的风险分析表包括以下几项内容：
①风险标识（ID）②风险问题③发生的可能性④影响的严重性⑤风险预测值⑥风险优先级

可能性与严重性的乘积产生的风险预测值,决定了风险优先级的排序。预测值越高，优先级别越高，针对该问题的测试就越重要。
计算结果风险问题的排列为B、A、D、C、E
软件风险分析的目的是:确定测试对象、确定优先级，以及测试深度。

4.8.4 软件测试风险
软件测试的风险是指软件测试过程出现的或潜在的问题，造成的原因主要是测试计划的不充分、测试方法有误或测试过程的偏离，造成测试的补充以及结果不准确。
4.9 软件测试的成本管理
4.9.1 测试费用有效性

4.9.2 测试成本控制
测试实施成本组成部分包括：测试准备成本、测试执行成本和测试结果成本。
1.测试准备成本控制
准备工作一般包括:硬件配置、软件配置、测试环境建立，以及测试环境的确定。
2.测试执行成本控制
测试执行成本控制的目标是使总执行时间和所需的测试专用设备尽可能地减少。
完全重新测试
部分重新测试
部分重新测试选择方法有两种：
①对由于程序变化而受到影响的每一部分进行重新测试;
②对与变化有密切和直接关系的部分进行重新测试。
3.测试结束成本控制
4.降低侧事故实施成本
测试自动化的方法主要有：使用测试工具；测试用例的自动化执行；测试文档编制的模板自动化生产。
5.降低测试维护成本
4.9.3 质量成本
1.质量成本要素
（1）一致性成本：用于保证软件质量的支出，包括预防成本和测试预算（审查费）
（2）非一致性成本是由出现的软件错误和测试过程故障引起的。
一般情况下，外部故障非一致成本要大于一致性成本与内部故障非一致成本之和。
2.质量成本计算
质量成本=一致性成本＋非一致性成本
4.9.4 缺陷探测率（DDP）

缺陷探测率越高，也就是测试者发现的错误多，发布后客户发现的错误就越少，降低了外部故障不一致成本，达到了节约总成本的目的，可获得较高的测试投资回报率（ROI）


第二篇 测试技术
第5章 黑盒测试案例设计技术
5.2.2等价类划分法
等价类划分的办法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。
1.划分等价类和列出等价类表
等价类划分有两种不同的情况：有效等价类和无效等价类
6条确定等价类的原则：
①在输入条件规定了取值范围或值的个数的情况下，可以确立一个有效等价类和两个无效等价类
②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确立一个有效等价类和一个无效等价类
③在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。
④在规定了输入数据的一组值（假定n个)，并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。
⑤在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则)。
⑥在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类。

2.确定测试用例
①为每个等价类规定一个惟一的编号。
②设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。
③设计一个新的测试用例，使其只覆盖一个无效等价类。


5.2.3 边界值分析法
原则
①如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。
②如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1的数作为测试数据。
③根据规格说明的每个输出条件，使用前面的原则①。④根据规格说明的每个输出条件，应用前面的原则②。
⑤如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
⑥如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构边界上的值作为测试用例。
⑦分析规格说明，找出其他可能的边界条件。
5.2.4 错误推测法
错误推测法就是基于经验和直觉推测程序中所有可能存在的各种错误，有针对性地设计测试用例的方法。
5.2.5 因果图法
1.因果图设计方法
因果图法是从用自然语言书写的程序规格说明的描述中找出因(输入条件)和果(输出或程序状态的改变)，通过因果图转换为判定表。
利用因果图导出测试用例需要经过以下几个步骤;
①分析程序规格说明的描述中，哪些是原因，哪些是结果。原因常常是输入条件或是输入条件的等价类，而结果是输出条件。
②分析程序规格说明的描述中语义的内容，并将其表示成连接各个原因与各个结果的“因果图”。
③标明约束条件。由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的。为表明这些特定的情况，在因果图上使用若干个标准的符号标明约束条件。
④把因果图转换成判定表。
⑤为判定表中每一列表示的情况设计测试用例。

①恒等:若原因出现，则结果出现;若原因不出现，则结果也不出现。
②非(~):若原因出现，则结果不出现:若原因不出现，则结果出现。
③或(V):若几个原因中有1个出现，则结果出现:若几个原因都不出现，则结果不出现。
④与(入):若几个原因都出现，结果才出现。若其中有1个原因不出现，则结果不出现。

2.因果图测试用例


5.2.6 判定表驱动法
1.判定表组成

·条件桩（condition stub):列出了问题的所有条件。通常认为列出的条件的次序无关紧要。
·动作桩（action stub):列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
·条件项(condition entry):列出针对它所列条件的取值，在所有可能情况下的真假值。
·动作项(action entry):列出在条件项的各种取值情况下应该采取的动作。
2.判定表建立
判定表的建立因该依据软件规格说明，步骤如下:
①确定规则的个数。假如有n个条件，每个条件有两个取值(0，1)，故有2n种规则。
②列出所有的条件桩和动作桩。
③填入条件项。
④填入动作项。制定初始判定表。
⑤简化。合并相似规则或者相同动作。
指出了适合使用判定表设计测试用例的条件:
①规格说明以判定表的形式给出，或很容易转换成判定表。
②条件的排列顺序不影响执行哪些操作。
③规则的排列顺序不影响执行哪些操作。
④当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。
⑤如果某一规则要执行多个操作，这些操作的执行顺序无关紧要。
5.2.7 正交试验法
利用正交试验设计方法设计测试用例，与使用等价类划分、边界值分析、因果图等方法相比，有以下优点:节省测试工作工时；可控制生成的测试用例的数量；测试用例具有一定的覆盖率。
5.2.8 功能图法
1.功能图设计方法
功能图方法是用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用列。功能图模型由状态迁移图和逻辑功能模型构成。
·状态迁移图用于表示输入数据序列以及相应的输出数据。
·逻辑功能模型用于表示在状态中输入条件和输出条件之间的对应关系。逻辑功能模型只适合于描述静态说明，输出数据仅由输入数据决定。
功能图方法实际上是一种黑盒、白盒混合用例设计方法。
逻辑覆盖可分为:语句覆盖、判定覆盖、判定-条件覆盖，条件组合覆盖及路径覆盖。
2.功能图法生成测试用例
功能图由状态迁移图和布尔函数组成。
从功能图生成测试用例的过程如下:
·生成局部测试用例
·测试路径生成
·测试用例合成
·测试用例的合成算法
5.2.9 场景法
1.基本流和备选流

2.ATM例子



第6章 白盒测试技术
6.2白盒测试方法
6.2.1代码检查法
代码检查包括桌面检查、代码审查和走查
桌面检查：由程序员检查自己编写的程序
代码审查:由若干程序员和测试员组成一个审查小组，通过阅读、讨论和争议，对程序进行静态分析的过程。
走查：与代码审查步骤基本相同
6.2.2 静态结构分析法
模块控制流图可以直观地反映出一个函数的内部逻辑结构，通过检查这些模块控制流图,能够很快发现软件的错误与缺陷。

6.2.3 静态质量度量法
软件的质量包括以下六方面：
功能性
可靠性
可用性
有效性
可维护性
轻便性
6.2.4 逻辑覆盖法
白盒测试的动态测试要根据程序的控制结构设计测试用例，其原则是:
·保证一个模块中的所有独立路径至少被使用一次;
·对所有逻辑值均需测试true和 false；
·在上下边界及可操作范围内运行所有循环;
·检查内部数据结构以确保其有效性。
逻辑覆盖标准包括以下不同的覆盖标准:语句覆盖(SC)、判定覆盖（DC)、条件覆盖(CC)、条件判定组合覆盖（CDC)、多条件覆盖(MCC）和修正判定条件覆盖(MCDC)。
语句覆盖(SC)：程序中的每条语句至少应该执行一次
判定覆盖（DC)（又称分支覆盖）：强于语句覆盖
设计足够的测试用例，使得程序中的每个判定至少都获得一次“真值”或“假值”。或者说使得程序中的每一个取“真”分支和取“假”分支至少经历一次。

条件覆盖(CC)：一个判定语句是由多个条件组合而成的复合判定。构造一组测试用例,使得每一判定语句中每个逻辑条件的可能值至少满足一次。

条件判定组合覆盖（CDC)：设计足够的测试用例，使得判定中每个条件的所有可能（真/假）至少出现一次。并且每个判定本身的判定结果（真/假）也至少出现一次。

多条件覆盖(MCC）（条件组合覆盖）：设计足够的测试用例。使得每个判定中条件的各种可能组合都至少出现一次。显然满足多条件覆盖的测试用例是一定满足判定覆盖、条件覆盖和条件判定组合覆盖的。

修正判定条件覆盖(MCDC)：这个覆盖度量需要足够的测试用例来确定各个条件能够影响到包含的判定的结果。它要求满足两个条件:首先，每一个程序模块的入口和出口点都要考虑至少要被调用一次。每个程序的判定到所有可能的结果值要至少转换一次:其次，程序的判定被分解为通过逻辑操作符( and、or）连接的 bool条件，每个条件对于判定的结果值是独立的。

6.2.5 基本路径测试法
1.程序的控制流图



2.程序环路复杂性
程序的环路复杂性即 McCabe复杂性度量，在进行程序的基本路径测试时，从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确保程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。
3.基本路径测试步骤
①以详细设计或源代码作为基础，导出程序的控制流图;
②计算得到的控制流图G的环路复杂性V(G);
③确定线性无关的路径的基本集;
④生成测试用例，确保基本路径集中每条路径的执行。
6.2.6 其他白盒测试方法
1.域测试：一种基于程序结构的测试方法
程序错误分为域错误、计算型错误和丢失路径错误三种。
如果程序的控制流有错误，对于某一特定的输入可能执行的是一条错误路径，这种错误称为路径错误，也叫做域错误。
如果对于特定输入执行的是正确路径，但由于赋值语句的错误致使输出结果不正确，则称此为计算型错误。
丢失路径错误：由于程序中的某处少了一点判断谓语而引起的。
域测试主要针对错误进行的程序测试。
2.符号测试
3.z路径覆盖
4.程序变异
第7章面向对象的软件测试技术
封装、继承、多态性
1、面向对象的软件测试分为
面向对象分析(OOA）的测试、面向对象设计(OOD）的测试、面向对象编程(OOP)的测试、面向对象单元测试、面向对象集成测试、面向对象确认和系统测试。OOA Test:对分析结果进行测试
ooD Tes t:对设计结果进行测试
OOp Test:针对编程风格和程序代码实现进行测试
面向对象单元测试:对程序内部具体单一的功能模块的测试，主是对类成员函数的测试。
面向对象集成测试:主要对系统内部的相互服务进行测试，如成员函数间相互作用，类间的消息传递等。
面向对象确认、系统测试:是基于面向对象集成测试的最后阶段的测试，主要以用户需求为测试目标
2、面向对象分析(OOA）的测试
对OOA阶段的测试划分为五个方面
1)、对认定的对象的测试
2)、对认定的结构的测试
3)、对认定的主题的测试
4)、对定义的属性和实例关联的测试
5)、对定义的服务和消息关联的测试
3、面向对象设计(OOD)的测试
对oOD阶段测试划分为三个方面
1)、对认定的类的测试
2)、对构造的类层次结构的测试
3)、对类库的支持的测试
4、面向对象编程(OOP)的测试
对OOP阶段测试划分为二个方面
1)、数据成员是否满足数据封装的要求
2)、类是否实现了要求的功能
5、面向对象的软件单元测试
一些传统的单元测试方法在面向对象的软件单元测试也可以使用。
6、面向对象的软件集成测试

1. 、面向对象的软件集成测试通常需要在整个程序编译完成后进行
   2)、两种测试策略
   第一种基于线程序的测试
   集成对回应系统的一个输入或事件所需的一组类，每个线程集成并分别测试，应用回归测试以保证没有产生副作用。
   第二种基于使用的测试
   通过测试那些几乎不使用服务器类的类（称为独立类)而开始构造系统，在独立类测试完成后，下一层中使用独立类的类(称为依赖类）被测试。
   3)、可以先进行静态测试，再进行动态测试。
   7、面向对象的软件确认、系统测试
   传统的黑盒测试方法可被用于驱动有效性测试。
   8、面向对象的软件测试策略
   1)、基于故障的测试
   具有较高的发现可能故障的能力
   2)、基于场景的测试
   两种错，一是不正确的规格说明;二是没有考虑子系统间的交互作用
2. 、OO类的随机测试
   如果一个类有多个操作（功能)，这些操作（功能)序列有多种排列。而这种不变化的操作序列可随机产生，用这种可随机排列的序列来检查不同类实例的生存史,就叫随机测试。
   4)、类层次的分割测试
   基于状态的分割、基于属生的分割、基于型的分割
   5)、由行为模型(状态、活劝、顺序和合作图)导出的测试