测试第二阶段重要知识点提要

第二阶段知识点

一、需求文档评审
需求规格说明书的目的：
CMM4级需要针对每一个研发活动进行长期度量，并根据度量数据建立各研发活动的预测模型（系统测试、概要设计、详细设计模型）

需求规格说明书的特点：
 正确性：所描述的需求是用户真正需要的；
 无歧义性：所描述的需求只有唯一的解释；
 完整性：1、所描述的需求涵盖了所有的需求（显示式的、隐式的）
             2、对每一个需求（显式和隐式的）都进行了完整（功能、性能等）的定义
 一致性：1、所描述的需求和上一级需求（原始需求或分配需求）是一致不冲突的；
             2、所描述的同级需求是一致的，不冲突的；
 可验证性：1、所描述的需求是否得到了实现可以被测量和确认
2、尽量避免使用描叙者清楚而阅读易混淆的主观词汇，如：容易、快速等
主观词汇引申：评审SRS时，只关注那些对需求的实现有影响的描述。
 可追踪性：所描述的每一个需求都可追踪到上一级需求；

需求分类：

原始需求               产品需求            软件需求           测试需求
        需求分析                 需求分配           测试分析

需求分类：技术性需求：功能性需求 非功能性需求（性能，可靠性，可移植性等）
          非技术性需求：成本，进度，质量，验收标准等

需求的属性：
 优先级
1、必须的：此类需求决定了系统的基本特质和形态，如果此类需求没有被实现，则该系统不能称之为特定形态的系统。
2、重要的：此类需求不决定系统的基本特质和形态，但是如果此类需求不实现，则该系统不具备任何市场竞争力。
3、可选的：针对特定的目标客户群的个性化需求（手机中MP3功能）或为了和竞争对手展开差异化竞争而实现的需求（夏新手机中的旋转功能）

优先级可能会随市场的变化而改变，是相对的。
需求分级的目的是为了满足软件开发中的版本规划。


版本编号
主版本.子版本.维护版本（或测试版本）.补丁版本
V**   R**   B**   D**
主版本号：1、加入重大功能2、平台变更
子版本：次要功能或可选功能（公司不同而定）
测试版本：BUG被修复
补丁版本：测试被BUG堵塞，打补丁修复该BUG
 工作量估计1、根据长期度量数据建立工作量的估计模型
               2、工程估计精确度依赖于
 参与估计的需求项的粒度的大小；
 参与估计的工程师的技术层次和经验；
 需求风险 1、资源上的风险：物力资源、人力资源
              2、技术上的风险
需求表达
1、通过输入、输出来说明（自然语言，容易产生歧义）
2、使用规范化的模型方法（UML，统一建模语言，形式化语言减少歧义）
 Use Case 图（用例图）：描述客户（不仅仅指用户，和系统有信息交互的都有是客户）和系统所提供的功能之间交互关系的图。
 类图：描述系统中各类之间关系的图
 对象图：描述类的具体实例之间的关系的图
 顺序图（序列图）：描述系统中各实体间信息交互关系的图（一般用于写用例）
 状态图：描述类或实体状态迁移关系的图

SRS写作要点
SRS写作应包括：项目介绍、产品环境介绍、用户特征、假设和依赖关系、具体需求（功能、性能）、
用户接口、软件接口、硬件接口、标准符合、硬件约束、技术限制和本地化 、需求分级等方面。
 项目介绍：介绍历史情景（1、全新开发的软件；2、从已有的软件系统经过增量开发而来）
 产品环境介绍：介绍系统在何种场景下被应用产品环境介绍应该将系统放置到更大一级的系统中去介绍，介绍它和周边系统的功能划分、接口关系等
 用户特征：只分析那些对软件需求的实现有影响的用户特征（将直接影响软件易用性）
 功能需求：简要介绍、输入、处理、输出
 性能需求：包含静态性能指标和动态性能指标

压力测试：测试系统在极限容量下长时间运行时动态性能指标的变化情况测试可靠性和系统崩溃后的
恢复能力（易恢复性）。
负载测试：测试系统在各业务场景、各配置环境下的瞬时动态性能指标。
容量测试：针对系统的静态性能指标进行测试。测试系统在各业务场景、各配置环境下系统的极限容量。

需求评审关注的重点：
 所描述的需求是否可验证（可验证性）
 站在用户的角度去体验需求是否有偏差
 站在用户的角度去挖掘隐式需求

二、系统测试用例
系统测试是将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的测试活动。
目的：1、验证系统功能是否符合需求规格说明书
2、验证系统的可靠性、可维护性、可用性、稳定性、容错性等其他属性
系统测试的对象应该是被测试软件的整体与硬件集合在一起的整体系统。
系统测试的依据是SRS和各种规范（如企业内部的系统测试出口标准）

单元、集成、系统测试的比较
阶段 测试方法 考察范围 测试自身评估基准
单元 白盒 数据结构、逻辑控制、异常处理等 逻辑覆盖率
集成 灰盒 接口和接口数据传递关系
模块组给后的整体功能 接口覆盖率
系统 黑盒 整个系统相对于需求的符合度 对需求规格的覆盖率

系统测试用例编写思路：
STEP1：根据软件质量模型将需求测试项划到质量特性及质量子特性下；
STEP2：根据需求确定有那些类型的测试（如功能测试、性能测试、压力测试）；
STEP3：将测试项根据step1的划分，总结归纳到相应的测试类型下；
STEP4：将各测试类型下的测试项细分为测试子项；（测试子项有明确的输入输出或明确的表现形式时不再细分；考虑功能组合，将功能中含有相同的子功能提取成单独的测试子项。）
STEP5：对测试子项所覆盖的SRS中的具体需求规格分析，采用等价类、边界值等各种用例设计方法设计用例。
对于各种用例设计方法都不是孤立存在的，应该是各种方法的综合应用，在具体用某种方法设计中也可以包含其他的方法。

功能性 可靠性 易用性 效率 维护性 可移植性
•适合性• •成熟性 •易理解性 •时间特性 •易分析性 •适应性
•准确性 •容错性 •易用性 •资源利用性 •易改变性 •易安装性
•互操作性 •易恢复性 •易操作性 •依从性 •稳定性 •共存性
•保密安全性 •依从性 •吸引性 •易测试性 •易替换性
•依从性 •依从性 •依从性 •依从性

测试类型：
•功能测试 •性能测试 •压力测试 •容量测试 •安全性测试
•GUI测试 •可用性测试 •安装测试 •配置测试 •异常测试
•备份测试 •健壮性测试 •文档测试 •在线帮助测试 •网络测试

用例写作要点
用例编号 产品编号—ST—系统测试项名—系统测试子项名—编号
测试项目 测试用例所属的大类，被测需求，被测的模块，或者是被测的单元
测试标题 每个测试用例的标题不能够重复，因为每个测试用例的测试点是不一样的
重要级别 高/中/低（或1级/2级/3级/4级）
预置条件 就是执行当前测试用例的前提条件，如果不满足这些条件，则无法进行测试
输    入 需要输入的外部信息
操作步骤 需要给出每一步操作的描述
预期输出 用来与实际结果比较
注：一般情况下，重要级别为高的测试用例，一个测试子项里有且只有一个（有效等价类），大多数都是重要级别为中的测试用例（其他有效等价类），级别为低的有（无效等价类和异常、生僻用例）。因为一般我们会进行一个系统测试预测试，如果重要级别为高的太多，则就失去了预测试的实际意义。

系统测试用例设计方法
等价类划分法：
1. 确定每个输入和输入条件，根据每个输入条件的规定方式不同，划分有效等价类与无效等价类。
2. 为每一个等价类规定一个唯一的编号。
3. 设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖地有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止。
4. 设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。
输入 条件限制 有效等价类 无效等价类



边界值分析法：
大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对个中边界情况设计测试用例，可以查处更多的错误。
1. 确定输入有明确的范围/取值/有序集合并先对其等价类划分
2. 根据每个输入条件的规定方式，在其条件内取值，条件边界上取值，离边界点最近的点上取值。
3. 根据这些取值设计用例。
闭区间[50，100]的上点为50和100，离点是49和101，在域范围内的都是内点；
半开半闭区间(50，100]的上点为50和100，离点是51和101，在域范围内的都是内点；
开区间（50，100）的上点为50和100，离点是51和99，在域范围内的都是内点；

判定表分析法：
在多个条件决定多个动作，（并且每个条件的取值只有两种情况下，）我们就可以采用因果图和判定表方法。条件和动作之间的逻辑关系是明确的，可以直接使用判定表法；如果条件和动作关系不明确，则要先使用因果图法。
1. 确定规则的个数 （规则：条件项与其对应的动作项）
2. 列出条件桩和动作桩 并填入条件项 动作项
3. 化简  （动作项相同，条件项只有一个不同才能化简。）
4. 一条规则设计一个用例

因果图法：
因果图法就是从程序规格说明书的描述中找出因（输入条件）和果（输出或程序状态的改变），通过因果图转换为判定表，最后为判定表中的每一列设计一个测试用例。
1．根据程序规格说明书描述的语义内容，分析并确定“因”和“果”，将其表示成连接各个原因与各个结果的“因果图”。需要注意的是，由于语法或环境的限制，某些原因和结果的组合情况是不可能出现的。为表明这些特定的情况，需要在因果图上使用若干个约束符号来标明约束条件；
2．将得到的因果图转换成判定表；
3．为判定表中每一列所表示的情况设计一个测试用例。
对于较为复杂的问题，这个方法常常是十分有效的。

状态迁移法：
许多需求用状态机的方式来描述，状态机的测试主要关注在测试状态转移的正确性上面。对于一个有限状态机，通过测试验证其在给定的条件内是否能够产生需要的状态变化，有没有不可达的状态和非法的状态，可能不可能产生非法的状态转移等。
构造能导致状态迁移的事件，来测试状态之间的转换。
1. 画出状态迁移图；
2. 列出状态——事件表；
3. 得到状态转换树；
4. 推出测试路径；
5. 根据测试路径编写测试用例。

流程分析法：
流程分析法是将软件系统的某个流程看成路径，用路径分析的方法来设计测试用例。根据流程的顺序依次进行组合，使得流程的各个分支都能走到。
确定测试路径：
1. 最基本的流程（正确的流程）；
2. 循环尽量只考虑一次
3. 覆盖每一个出口，每一条分支

正交试验法：
用最少的用例覆盖两两组合。
指标：通常把判断试验结果优劣的标准叫做试验的指标；
因子：所有影响试验指标的条件；（输入）
因子的状态：影响试验因子的，叫做因子的状态。（输入的取值）
1. 提取功能说明，按照下表构造因子—状态表；
因子1 因子2 … 因子n
状态1
状态2
…
状态3
2. 利用正交表构造测试数据集；
每个因子状态数相同，根据因子数找一个最接近的正交表。
不同因子状态数不同，先确定状态表的状态数，选出现次数最多的（尽可能大），再确定因子数，根据状态数找最接近的因子数。
3. 正交表的每行数据构造测试用例。


输入域测试：对输入进行等价类，边界值和特殊值测试。
输出域覆盖法：分析输出的等价类和边界值。
异常分析法：针对系统有可能存在的异常操作、软件硬件缺陷引起的故障进行分析，依此设计用例。
错误猜测法：根据经验猜想可能有什么问题并依此设计测试用例。

三、系统测试执行
系统测试预测试的目的是验证软件系统基本功能或预测主要的系统功能，以确保其后的系统测试执行能够顺利进行。

系统测试环境：
硬件环境：服务器、客户端、网络连接设备、打印机、扫描仪以及测试仪器等，关注配置和型号。
软件环境：操作系统、数据库、共存软件、测试工具及被测软件。在主环境上（选用比较普及的操作系统和软件平台）测试所有用例，在辅环境上测试部分用例。测试环境应避免开发软件。
仿真测试环境能够保证测试的：完整性、可扩展性和可重复性（注意测试数据的备份）。

系统测试报告
目的：
1. 软件测试人员完成对上一个测试阶段的总结，完成对被测试对象的评估，并对下一阶段的测试工作给出建议；
2. 测试经理通过测试报告了解被测试产品的质量情况、测试过程的质量；
3. 软件开发项目经理通过软件测试报告了解开发产品的质量情况，并在下阶段的开发工作中采取应对措施；
4. 在软件测试报告中，软件测试人员作出的软件产品质量评估，可以作为软件产品是否商用发布的重要参考依据。
要点：
 概述：简单介绍被测对象，测试特性及其版本/修订级别情况
 测试时间、地点、人员（分工）
 环境描述：软件、硬件、仪器、组网图（结构关系图）
 总结与评价
结果统计：
功能性测试按模块分类；性能测试按场景数分类；GUI测试按界面数分类；配置测试按环境数分类。
类型 规模（KLOC） 测试执行（人时） 工作量投入（人时/KLOC）
……
合计
用例状态统计：
类型 OK NOK BLOCK NT 合计
……
合计
缺陷统计（可选）：
类型 致命 严重 一般 提示 合计
……
合计
版本缺陷统计/累计遗留问题统计（可选）
类型 版本1 版本2 版本3 版本4 合计
……
合计
效率分析：
测试活动持续时间：X小时 执行用例数：Y个 发现缺陷总数：Z个
平均每小时用例数=执行用例数/测试活动持续时间=Y/X
平均每小时发现缺陷数=发现缺陷总数/测试活动持续时间=Z/X
影响测试效率的原因分析。
充分性分析：
分析用例对需求的覆盖率。
类型 千行代码用例数 已执行用例数 用例总数
……
合计

稳定性分析：
根据以前版本的统计数据，用表格或图表的方式进行比较，分析产品的稳定性。
 综合评介：对被测软件质量作出客观评价
 总结和建议：总本次测试活动的经验和教训，提供改进建议。附上对测试方案、用例的修改和补充
 遗留问题：列出遗留问题的缺陷ID、缺陷描述、缺陷级别

系统测试计划
系统测试计划阶段
入口准则：软件开发计划（SDP）和软件测试计划（SVVP）完成；
出口准则：《软件系统测试计划》完成并通过评审；
输入：SDP、SVVP、SRS；
输出：软件系统测试计划；

系统测试设计阶段
入口准则：需求分析完成，建立了需求基线；
出口准则：《软件系统测试方案》完成并通过评审；
输入：SRS、软件系统测试计划；
输出：软件系统测试方案；

系统测试实现阶段
入口准则：软件系统测试方案完成；
出口准则：《软件系统测试用例》、《软件系统预测试项》、《软件系统测试规程》及自动化测试代码完成并通过评审；
输入：系统测试计划、系统测试方案、SRS、HLD、LLD；
输出：系统测试用例、预测试项、规程、测试代码；

系统测试执行阶段
入口准则：集成测试完成；
出口准则：达到系统测试计划中的测试通过准则要求，通过《软件系统测试报告》的评审；
输入：系统测试计划、方案、用例、系统预测试项、测试规程、集成测试报告；
输出：软件系统预测试报告及评审表、系统测试报告及评审表、缺陷报告、测试日报、测试记录。

系统测试计划要明确的内容：
1. 目标，概述
2. 明确系统测试的组织形式——测试与各部门的沟通方式，权限（外）；测试内部的人员职责
3. 明确系统测试的测试对象——分析测试项，以便分配任务和进度安排
4. 完成系统测试的需求跟踪
5. 明确系统测试的明确系统测试的通过/失败标准——通过标准和失败标准一一对应，采用量化的数据
6. 明确系统测试的挂起标准及恢复的必要条件——挂起和恢复一一对应，采用量化的数据
7. 明确系统测试的工作任务分配——可按阶段，特性或组合方式分配；风险应有相应的规避措施
8. 结束后应交付的测试工作产品
9. 工作量估计——工作量，难度均衡；
10. 资源的分配

四、集成测试阶段
概要设计思路：
1. 根据需求子项划分模块；
2. 确定每一个模块的功能；
3. 确定模块间的调用关系；
4. 确定模块接口（接口原型：int add (int x,int y)），接口类型，名称，参数个数，参数类型；
5. 评估/评价系统结构，接口设计是否合理；
 模块太大：开发效率低，无法有效支持故障隔离；
 模块太小：接口太多，软件结构过于复杂，容易出现BUG；

概要设计层次：
零层：描述系统外界关系（可选）；
一层：描述系统总体设计（必须）；
二层：描述系统子模块设计（可选）；

每层设计应作如下描述：
1. 分解描述：先描述系统/组件的整体结构，再描述每个组件的功能等属性。建议使用框图的形式描述组件的体系结构，用顺序（时序）图表示调用关系；
2. 依赖关系描述：建议按功能处理过程/业务流程进行组织，并采用DFD等方式进行描述；数据间的关系建议采用DR图进行描述；
3. 接口描述：含接口功能，形式，输入，输出，返回值，描述（输入，输出，返回值应指明取值范围，标明特殊值的含义）；

概要设计评审要点：
1. 抽象：不关注实现的细节；
2. 模块化：大小合适；
3. 模块独立性：高内聚低耦合；
4. 信息屏蔽：尽量使用数据耦合，少用控制耦合，限制公共耦合的范围，坚决避免内容耦合；
主要集成测试策略
一． 大爆炸集成
优点：方法简单效率高（只测试一次）；
缺点：急于求成，成功率不高；
大海捞针，定位问题困难，不支持故 障隔离；
囫囵吞枣，大量的问题被漏测，引入到下一阶段；
适用范围：维护型项目，小项目；
软件结构不清晰的系统（网状结构或耦合度很高）；
二． 自顶向下集成
有深度优先和广度优先两种，深度优先在集成早期能看到效果。
优点：测试活动和开发（设计）顺序一致，可以并行展开；
缺点：如果底层组件变更将导致上层组件必须进行回归测试，甚至整个集成测试推倒重来；
适应范围：高层稳定，底层频繁变更，产品结构清晰。
三． 自底向上集成
优点：利于集成测试并于开展
四． 三明治集成
三明治集成继承了自顶向下和自底向上的优缺点。中间层测试不充分。
改进三明治集成继承了自顶向上和自低向上的优缺点。中间层的驱动和桩开发量大，时间和成本增加。
五． 基于功能的集成
具有大爆炸的优缺点，可能会有较大的冗余测试。
集成测试策略应根据集成层次的不同采用不同的策略。

TCL集成测试
一． TCL解释器创建步聚
定义TCL解释器
Tcl_Interp* MyInterp;
创建TCL解释器
MyInterp = Tcl_CreateInterp();
初始化TCL解释器
Tcl_Init(MyInterp);
在解释器中注册扩展指令
Tcl_CreateCommand(MyInterp,"testcounter",TclEx_Counter,NULL,NULL);
二． 外部TCL脚本设计思路
1) 将用例以数据（文件）的形式记录下来，每个用例的输入，预期输出对应一条数据记录
2) 打开数据文件，循环读取各用例的数据记录
3) 每读取一个用例的数据记录，将该记录的各参数解析出来
4) 把上述数据作为输入， 调用TCL的扩展指令进行测试
5) 把扩展指令执行结果保存到结果文件中
三． 扩展指令创建步聚
1) 按照扩展指令函数的格式定义自己的扩展指令函数
2) 检查参数的数目
3) 逐个获取参数的数值（用例输入和预期输出参数）
4) 把获取到的输入参数传送给被测试模块的接口，将其驱动起来
5) 将获取到的预期输出和被测试模块的实际输出进行比较，得到测试结果，并将结果传送到指定位置

四、单元测试
单元测试用例编写思路：
1) 为系统进行起来而设计用例：最基本的用例；
2) 为正向测试而设计用例：LLD中的有效等价类；
3) 为逆向测试而设计用例：无效等价类，错误猜测法，异常分析法；
4) 为满足特殊需求而设计用例：除功能之外的属性（性能，安全保密性等）；
5) 为代码覆盖而设计用例：语句，判定，条件，路径；
6) 为覆盖率指标完成而补充用例：执行之后发现覆盖有遗漏再补充。

基本路径法设计思路：
1) 画出控制流图（将判定中的多个逻辑运行算符改为一系列只有单条件的嵌套判断）
2) 计算圈复杂度（区域数）
3) 得出独立路径（每一条路径都包含前面没走过的路径）
4) 设计用例覆盖独立路径
5) 如果设计的独立路径无法达到，可适当更改，但必须保证所有路径都被覆盖到。

简单循环路径
1) 零次循环：从循环入口一到出口
2) 一次循环：检查循环初始值
3) 二次循环：检查多次循环
4) M次循环：检查更多次循环，反映执行典型的循环的执行数次
5) 最大次数循环，比最大次数多一次，少一次的循环
6) 对于增量和减量不是1的循环，要特别注意

CppUnit框架图
测试执行器
测试工厂1（对应类2）
测试套11（对应类1的方法）
测试方法111（对应用例1）
测试方法112（对应用例2）
……
测试工厂2（对应类2）
测试套21（对应类2的方法1）
测试套22（对应类2的方法2）


测试方法加入到测试套中，套声明为测试装置类，然后加入到测试工厂，多个工厂加入到执行器。

CPPUNIT-ASSERT（condition） 判断条件是否满足
CPPUNIT-ASSERT-EQUAL（P1,P2） 比较两个参数是否相等
CPPUNIT-ASSERT-DDUBLES-EQUAL（P1,P2,della） 比较两个参数之差是否在范围之内