[测试指导书]给测试新人的指导，都是经验和积累，测试几个阶段用到的测试方法。

starseeker

1
Objectives 目标本文着重于基本测试方法的介绍，突出了不同测试阶段的方法和重点，对于软件开发项目组中的测试活动给予技术指导。
2
Scope
范围本指导书适用于遵循CMM流程规范的软件开发项目的不同测试阶段UT/IT/ST。
3
General test methodology guideline 通用测试方法指导软件测试是使用人工和自动的手段来运行和测定某个系统的过程，其目的在于检验它是否满足规定的需求，或弄清预期结果和实际结果的区别。简单讲，软件测试以检测是否满足需求为目标。
3.1
单元测试，集成测试，系统测试概念介绍以及区别3.1.1
单元测试3.1.1.1
单元测试的定义单元测试是检测程序最小单位是否有错误。单元（unit）是程序中的最小单位，它具有一些基本属性：
1.
通常可以单独分配给开发人员进行开发，在单元之间或与外界之间的技术接口，可由人员进行协调
2.
单元接受数据输入后，经过加工，输出结果，输出可能是数据，可能是状态的改变，但是输入，加工，输出三个环节缺一不可
3.
原则上，每个程序单元都应该有明确的规格说明，也就是对输入、加工和输出作了明确的描述
比程序单元更大的单位比较模糊，通常我们以模块定义，模块大小没有明确规定，可能在树状结构的不同位置。通常认为基层模块就是程序单元，或者由程序单元构成。

3.1.1.2
单元测试的对象在CMM中，单元测试的对象是LLD中所划分定义的程序单元或模块，它也是单元测试用例设计中可测试的最大单元。该测试对象可能由一个或多个函数或者类组成，测试设计就是对测试对象进行测试用例设计。
如何划分单元，对于单元测试的成本和效果有很大影响。单元划分过大，花费在问题定位等方面的工作量较大；单元划分过小，测试回报率较低，也就是说，发现同等数量的问题，将编写更多的测试用例。确定单元粒度的最基本原则就是“高内聚、低耦合”

starseeker

3.1.2        集成测试
3.1.2.1        集成测试的定义
集成测试是指把若干个经过单元测试的模块（或单元）组装到一起而进行的测试, 集成测试应依据HLD中,主要发现接口、依赖中的错误或不完善的地方。
3.1.2.2        集成测试的对象
集成测试的对象为若干个单元测试对象的组合，至少为两个。以模块为基本单位，测试模块间的接口及同步机制,，模块间全局数据的正确性,测试各个模块或子模块集成后的子功能是否实现
集成测试应重点测试以下内容：
消息接口，功能流程，使用的数据表，对外提供的函数接口，处理性能

starseeker

3.1.3        系统测试
3.1.3.1        系统测试的定义
系统测试是针对软件项目组所承担开发的软件系统进行的整体测试，将软件系统作为整体运行或实施明确定义的软件行为子集的测试。主要采用的测试方法是黑盒测试，即不管程序内部的实现逻辑，以检验输入输出信息是否符合规格说明书中有关需求规定的测试方法。
3.1.3.2        系统测试的对象
系统测试的对象为软件项目组所承担开发的软件系统，
3.1.4        单元测试、集成测试、系统测试的比较
表1 单元测试、集成测试、系统测试比较表
测试类型        测试对象        测试重点        测试依据        测试方法
单元测试        单元模块的
内部程序        消除单元、模块内部的逻辑和功能上的错误与缺陷        软件详细设计        大量采用白盒测试方法
集成测试        单元模块/子模块间的组装        找出与软件架构设计相关的程序结构，单元/子模块间调用(依赖)关系，单元/子模块间接口方面的问题        软件概要设计        结合使用白盒与黑盒测试方法，较多采用黑盒测试构造测试用例
系统测试        整个软件系统        对系统规格中的功能与性能进行一系列的有效性测试        软件需求规格说明书等        黑盒测试

starseeker

3.2        通用测试方法，技术的介绍
为了检验开发的软件能否符合规格说明书的要求，测试活动可以采用各种不同的策略。这些策略的区别在于他们表明了不同的出发点、不同的思路以及采用不同的手段和方法。常用的测试方法有：黑盒测试和白盒测试，静态测试和动态测试，随机测试和穷举测试，单元测试、集成测试和系统测试，自顶向下和自底向上的测试，累进测试和非累进测试，以及人工测试和自动化测试。

黑盒测试和白盒测试：这两种方法是业界常用的测试方法。黑盒测试又称功能测试、数据驱动测试或基于规格说明的测试。用这种方法进行测试是，被测程序被当作打不开的黑盒，因而无法了解其内部构造。完全不考虑程序内部接口和内部特性的情况下，测试者只关注程序的输入和输出直接的关系，或者程序的功能，依靠这一关系和程序功能的需求规格说明书考虑确定测试用例和推断测试结果的正确性。因此黑盒测试从用户角度出发的测试。常用的方法有等价类划分，因果图，正交实验设计法，边界值分析法，判定表驱动法等。白盒测试又称为结构测试、逻辑驱动测试或基于程序的测试。这种测试方法，测试者可以看到被测试的源程序，可以分析程序的内部接口，并且根据内部构造设计测试用例，可以完全不考虑系统的功能。常用的测试方法有程序控制流分析、数据流分析、逻辑覆盖、域测试、符号测试、路径分析、程序插装及程序变异等。
静态测试和动态测试：静态测试主要的特征是不利用计算机运行被测试的程序，而是采用其它手段达到检测的目的，这种方法并不意味完全不利用计算机作为分析的工具。动态测试即是静态测试的反方向。
人工测试和自动化测试：人工测试是针对自动化测试技术而言的。自动化测试技术并不是完全脱离人的测试，严格的讲任何测试都离不开人的干预，所谓自动化，只是用计算机编写相应的测试脚本和代码，通过这些代码的执行来代替人工测试的部分工作。
各种测试方法是相辅相成的，并不是独立存在的。在针对软件系统进行测试的过程中，往往是多种方法相互结合，进行完整性测试的，从而保证软件系统的最终满足需求规格说明书。
3.3        软件测试原则
软件测试的原则是“尽早测试原则”。因为缺陷修改的成本随着阶段的后移指数级增加，缺陷发现越早，改正缺陷所消耗成本将越低，因此应尽早开展可执行的测试。
例1：
模块A，B，C共同完成软件需求中的某项完整的系统级功能，那么在集成测试中完成ABC的集成后即可测试验证该项功能，不要推迟到整个系统（ABCDEF）的系统测试才进行测试。
例2：
SRS和PPL中指定产品模块的性能要求应分解到HLD和LLD中实现，因此性能测试也应在UT/IT阶段尽早进行，避免将所有的性能测试都推迟到ST阶段才进行。
3.4        回归测试原则
回归测试是对软件系统存在的缺陷进行修改后的再验证测试，针对系统存在的缺陷情况，需要制定相应的测试策略，主要步骤如下：
1.        分析功能、模块存在的缺陷影响程度；
2.        根据影响程度，选取相应测试策略：完全重复测试，选择性重复测试

下面针对完全重复测试和选择性重复测试的方法进行介绍：
1、        完全重复测试：重新执行所有在前期测试阶段建立的测试用例，来确认问题修改的正确性和修改的扩散局部影响性，显然，这种回归测试的代价是很高的。
2、        选择性重复测试：即有选择地重新执行部分在前期测试阶段建立的测试用例，来测试被修改的程序，这种方法的执行代价将大大少于完全重复测试，但如何选取那是关键问题，可以基于风险（运行最重要的、关键的和可疑的测试），成本，操作剖面（系统的实际使用情况，可靠性有最大影响）。目前选择性重复测试有如下三种方法：
        覆盖修改法：即针对被修改的部分，选取或重新构造测试用例验证没有错误再次发生的用例选择方法。这就是简单的“改哪再测哪”的方法。
        周边影响法：该方法不但要包含覆盖修改法确定的用例，还需要分析修改的扩散影响，对那些受到修改间接影响的部分选择测试用例验证它没有受到不良影响。该方法比覆盖修改法更充分一点。
        指标达成方法：这是一种类似于单元测试的方法，在重新执行测试前，先确定一个要达成的指标，如修改部分代码100%的覆盖、与修改有关的接口100%的覆盖等，基于这种要求选择一个最小的测试用例集合。

上面提到修改覆盖法、周边影响法、指标达成法三种重复选择方法。一般来讲，我们倾向于选择修改覆盖法，即改哪测哪法，但我们也要有足够的分析过程表明我们可以不测试该修改的扩散影响，这就涉及到我们对被测试系统设计的方法和理解。扩散影响法是一种科学的全面的用例选择法，它需要仔细对修改部分和周边部分进行审视，理清楚边界关系，确定扩散的边界。具体对错误分析如下：
1.        可能导致输出内容错，而不是输出格式错，则测试用例的扩散范围可限制在本模块内。
2.        可能导致输出格式错或者发现是接口错，则意味着将引起其它部分接口定义的修改，则在该接口流程上所有模块的测试用例都需要纳入扩散范围。最简单的方法就是仅将测试用例的范围扩大到与被修改模块直接相邻的模块。
3.        修改可能引起了接口定义较大的改动，则测试用例可扩散到子系统一级。

starseeker

3.5        测试用例设计
3.5.1        测试用例的设计角度
测试用例的是为验证测试对象的实现正确性而设计的，为了达到某种验证的目的，就需要根据测试需求从不同的角度进行设计，如可运行，可满足等角度。
1.        为运行起来而设计用例
（1）用最简单的方法使被测对象运行起来
（2）如果不能够执行起来，那么最好重新调试，也就是说还不具备开始测试的条件
2.        为正向测试而设计用例
（1）测试用例的设计者应该通读相关的设计说明，每一个测试用例，就是针对设计说明书中的一项或多项内容来设计的
（2）正向测试的用例就是验证设计说明书所对应的功能项或性能指标能否兑现
3.        为逆向测试而设计用例
（1）逆向测试的用例就是用来验证被测的软件对象有没有做它不应该作的事情
（2）此步骤主要依靠错误猜测的方法进行测试用例的构造
4.        为满足特殊需求而设计用例
（1）从系统的性能，安全性，保密性的角度来设计测试用例也是十分必要的
（2）尤其对于安全及保密要求较高的系统，在测试方案中，特别标明用来进行安全及保密验证的测试用例是有好处的
5.        为漏测而设计用例
（1）设计好的测试用例是可以保证较高的代码覆盖率
（2）当这种情况发生时，有必要分析为什么会导致覆盖率目标没有达到。一般的原因可能有这样一些：不可能的路径或条件，不可达的或冗余的代码和不充分的测试用例。

另外测试用例设计的时候还要考虑可读性和易用性，测试用例要在测试中还要不断的进行完善，因此要及时跟踪和纳入管理.
3.5.2        测试用例的组织方式
测试设计中，对测试子集的划分是很重要的，划分得好，则即可以提高测试执行效率，又可以使测试步骤清晰化，使测试执行人员准确快速的完成测试执行操作。对测试集的划分可以从发现测试用例中以下几个方面的共性来考虑：
1.        测试预置条件有共性的测试用例；
2.        采用的测试仪器设备有共性的测试用例，如将用XX商用测试工具测试的归到一起；
3.        测试环境、组网限制方面有共性的测试用例，如完成一个集成测试需要变换三种组网模式，则要按照组网方式的不同来分别组织测试规程集，避免多次反复搭建组网环境；
4.        测试执行策略的原因有共性的测试用例，如有些测试用例是需要修改软件版本的某一类参数，并需要再次加载的，或需要修改源代码某些语句并编译的。因为加载、编译等一般时间比较长，为提高效率，可以将其放在一起成为一个测试规程集。
5.        另外，还要综合测试资源划分的因素进行考虑，如对于某集成的测试，没有独立的后台操作维护（OMC）测试组，也没有独立的后台测试环境，则要按功能进行划分，并将前后台的测试用例捆绑在一起，对测试规程的规划不分前后台（一个规程中即要完成前台功能的测试用例，又要完成后台功能的测试用例）。
3.5.3        测试用例的设计步骤
1.        列出用户需求功能，测试目标，评估标准
2.        归纳出公用子功能，列出一次便可（比如某些子功能可以是预置条件）
3.        根据子功能测试目标中分析得出测试点
4.        将测试点分类规划入每个测试序列
定义测试序列预置条件需考虑下列因素：
        启动条件（Set up），数据，工作流；Archival of results (between cycles as a minimum)；
        逻辑相关的测试点组装在一起
        将预置条件相同的测试点组装在一起
        将相关测试点组装在到一个测试序列中，使得一个测试用例的输出成为另一个用例的预置条件
5.        将测试序列扩展为测试用例

starseeker

3.6        测试评估
3.6.1        测试评估目的
在测试结束后，通过对测试过程测试数据的收集，分析各个评估点的数值，主要的目的有：
1.        评估测试设计的质量，
2.        评估测试过程的质量
3.        评估测试对象的质量
4.        为下个阶段的工作提供合理化建议
3.6.2        测试评估内容
测试活动的评价主要包括以下内容：
1.        缺陷趋势：包括引入缺陷趋势、关闭缺陷趋势、积压缺陷趋势、缺陷年龄趋势、缺陷增减趋势
2.        缺陷密度：缺陷发现密度是指每千行代码发现的问题个数,包括所有发现问题的缺陷密度及各模块的缺陷密度等
3.        缺陷分布：包括问题根源如需求、设计、编码、其它（如操作文档、测试用例、操作系统错误、硬件错误、操作失误、理解有误）的分布比例及问题的分类（如接口、逻辑、标准、功能、性能、数据、文档）比例等
4.        工作量分布：包括每千行代码的工作量分布等

3.6.3        测试评估项目
在测试评估方法中，Gompertz模型是其中应用较广的一个。
1.        缺陷密度
（1）模块级分析：
        将各个模块的缺陷发现密度和模块平均情况进行比较，可以发现异常的模块，并进行针对分析；
        将各个模块的缺陷发现密度和质量目标对比，可以评估项目的整体测试有效性；
说明：由于各个模块有各自得代码特点，比如DB模块，可能就和业务模块缺陷密度差异比较大一些，因此，用统一的缺陷密度来判断不同的模块，可能会有失偏颇。因此，比较合理的方式，是在UT前，针对不同的代码模块，给定不同的质量目标。
（2）横向比较：
        将被分析项目和相似的历史项目进行比较，可以得到该项目的UT是否比历史项目排除更多的缺陷，UT水平是否有提升；
        和同一产品内的同一时期的项目对比，根据该测试结果，可以看出项目测试是否达到组织能力范围。
2.        用例代码比
用例代码比是指每千行代码对应的测试用例数。利用该指标，可以：
        评估用例充分性；对覆盖率建立一个初步的认识；
        对测试执行完毕发现问题较少时，该指标往往是一个评判测试是否可通过的重要依据。
（1）模块级的分析:
        将项目各模块的用例代码比横向比较，并和平均值比较，可以找到用例设计不充分的模块。在未建立基线以前，该方法更为行之有效；
        将各模块及其平均情况和组织能力对比，可以评估项目的总体用例设计是否充分。
（2）项目间的横向比较：通过与历史项目和类似成功项目的横向比较，可以评估用例设计充分性的总体情况。

3.        投入分析
测试投入，可以有两种表达方法：
（1）平均每千行代码的测试执行时间；
（2）平均每用例的测试执行时间。
该指标的主要目的，是评估项目成员在测试活动的投入量，从一个侧面反映出测试的充分性和细致程度。由于目前的工作量统计未细化到模块一级，因此，该指标一般在项目之间横向比较。
        将项目的实际测试工作量和计划工作量进行比对，计算偏差，可以得到测试投入的初步印象。
        项目间的横向比较：通过横向比较，可以看出项目的测试投入是否合理。

4.        目标达成情况
项目的测试策略/测试计划中，一般会给出测试的停止准则/出口准则，根据它可以判别UT的目标达成情况，并确定测试阶段是否可以通过。比如审查以下指标是否满足既定目标：
（1）测试覆盖率
测试的覆盖率，一般需要借助覆盖率工具来进行统计。比如语句覆盖或者条件覆盖的覆盖率;
（2）测试用例通过率
检查经过一轮或者多轮测试后，最后的测试用例通过率。
（3）测试发现问题解决率
测试完成后，发现的问题解决率是否满足既定目标。
5.        其他评价手段
（1）测试用例的效率
每个用例发现的问题个数，用于评估用例的有效性。一般更适用于同一项目内模块间的横向比较；
（2）请资深专家对个别模块进行用例设计合理性和覆盖率的手工审查，或者不同模块成员间进行交叉审查。

starseeker

4        UT Guideline 单元测试指导
4.1        单元测试策略
单元测试策略的制定要根据单元测试的测试对象、测试需求、测试质量目标等相关因素来决定。
4.1.1        根据测试测试对象确定测试策略
单元测试的测试对象就是项目LLD中所划分定义的单元或子模块，针对这些测试对象，需要考虑测试对象的复杂性，重要性，相关性等。通过分析，可以采取最优先测试的测试策略。比如：
（1）在一个新的软件系统中，对一些非常关键的函数或者被关键函数调用的函数，必须首先测试以降低系统的风险，要在单元测试计划中将这些函数标注出来首先测试；
（2）在团队分配的单元测试任务中，首先罗列出单元/子模块的接口部分，优先测试互相影响的函数，相应的相关性和作用较小的函数可以最后测试。
（3）测试对象（函数，子模块）实现算法比较简单，或者不太适合进行单元测试，比如代码添加点多且分散，SQL语句等，可以通过代码检视的测试策略对函数进行测试，这个也是单元测试的一种特殊形式。
（4）对于一个重点模块或重点函数，可以通过单元测试工具进行测试，缩短测试时间，提高测试质量，常用的测试工具有：TrueCoverage，RTRT，MTT等。
4.1.2        根据测试需求确定测试策略     
单元测试在测试过程中涉及到人力，时间，测试环境，软件工具等因素，针对这些因素，要制定相应的测试策略，比如：
（1）人力，时间紧张
通常人力和时间是相互影响的，如果出现人力和时间紧张的情况，建议项目经理分析测试对象，集中进行测试，测试策略可以采用优先测试原则。
（2）测试环境紧张
在测试环境紧张的情况下，首先对测试对象进行分析，对于可测试的测试对象首先安排测试，同时调配测试环境资源，测试策略可以采用可行性分析，合理安排测试时间的原则。
（3）测试软件工具缺乏：
在单元测试过程中，如果缺乏单元测试工具，可以采取两个原则：一，就现有测试工具进行安排测试，这个需要分析测试对象的可测试性；二，进行测试工具的开发，这个需要分析现有的人力，时间，测试对象的需求，这个就需要分析整个单元测试对软件工具开发的投入产出比。
4.1.3        根据测试质量目标确定测试策略
单元测试的测试策略可以根据单元测试的质量目标进行制定，测试质量目标包括：用例密度，缺陷发现密度，用例执行时间，单元测试时间等。在实际的单元测试过程中，可以参考业界或类似模块、相关模块的统计数据，作为质量目标的参考，以测试质量目标为核心展开单元测试，比如：单元测试要保证单元测试用例密度达到100个/千行代码（参考值）；代码的语句覆盖率为100%；按照业界的单元测试时间和用例执行时间安排测试对象的时间；按照缺陷发现密度来评价单元测试的测试用例设计质量，是否要重新进行用例设计和测试。
       
总之，在实际的单元测试过程中，往往是根据测试对象，结合现有的资源（人力、时间、环境、工具等）以及质量目标进行综合分析，制定相关的测试策略。
4.2        单元测试方法
单元测试是软件测试最底层的测试，主要采用白盒测试方法，业界比较成熟的方法有程序控制流分析、数据流分析、逻辑覆盖、域测试、符号测试、路径测试、测试插装及程序变异等。具体如下：
4.2.1        程序控制流分析
程序控制流分析是指按照程序流程图检查程序控制结构。这种方法主要应用于系统整体架构的检查；
4.2.2        数据流分析
数据流分析是对过程内部数据流，或者过程间的数据流进行分析，用于查找未定义变量、未使用变量的再次赋值等数据流异常错误。这种方法常用于代码优化。
4.2.3        逻辑覆盖测试
逻辑覆盖测试是程序结构测试最常用的测试方法，常用的逻辑覆盖测试方法包括：
        语句覆盖：设计若干测试用例，运行被测程序，使得每一个可执行语句至少执行一次
        判定覆盖：设计若干测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少执行一次
        条件覆盖：设计若干测试用例，运行被测程序，使得程序中每个判断的每个条件的可能取值至少执行一次
        判定－条件覆盖：设计足够的测试用例，使得判断中的每个条件的所有可能至少出现一次，并且每个判断本身的判定结果也至少出现一次。
        路径覆盖：设计的测试用例要求覆盖程序所有可能的路径。
4.2.4        域测试
域测试是一种基于程序接口的测试方法。如果程序的控制流有错误，对于特定的输入可能执行的是一条错误的路径，这种错误称为路径错误，也叫域错误。域测试就是针对域错误进行的程序测试。
4.2.5        符号测试
程序的输入不仅仅是具体的数值数据，还包括符号值，对这些符号的测试就是符号测试。明确地说，普通测试执行是算术运算，符号测试则是执行代数运算，因此符号测试可以认为是普通测试地一个自然补充。
4.2.6        路径测试
路径测试是指分析程序中的路径，检验程序从入口开始，执行过程中经历的各个语句，直到出口。这个是白盒测试最常用测试，完成路径测试的最理想的情况是路径覆盖。

单元测试常采用白盒测试方法，并不是不采用黑盒测试方法，在实际测试过程中，测试方法是相互兼容的，比如在单元测试中也会采用黑盒测试中的等价类，边界值等测试方法。

starseeker

5        IT Guideline 集成测试指导
5.1        集成测试策略
5.1.1        定义
集成测试中合理的组织方式很关键，常用的组织方式有非增式集成测试，增式集成测试，衍变式集成测试。
1 非增式集成测试：在配备辅助模块的条件下，对所有的模块进行个别的单元测试，然后在这个基础上，按照程序结构图将各个模块联接起来，把连接后的程序当作一个整体进行测试。
2 增式集成测试：增式测试是按照程序结构图通过自顶向下或自底向上底逐步集成，逐步测试进行的。
3 衍变式集成测试：增式集成和非增式集成两种策略各有自己的优缺点，而且他们的优点和缺点互补，在实际工作中往往将两种方法结合起来，充分利用各自的优点，克服其中的缺点，这就是衍变式集成策略。
实际测试中很少使用“纯”增式或“纯”非增式，增式集成里也很少采用“纯”自顶向下或自底向上增值方式，而是各种方式混合使用。
5.1.2        集成测试策略的选择：
1.        增式策略：
能够保证测试充分，发现问题易于定位，但是要求测试时间很长，人力，物力资源不能够充分利用，测试效率比较低。
一般来说，仅在以下情况可以考虑增式策略：
（1）、该特性包含的所有模块（或者绝大部分模块）的代码成熟度都很低，需要都能得到充分测试；
（2）、每个模块的重要程度都较高，不便于轻易取舍；
（3）、测试时间足够，无紧迫的测试进度要求；
（4）、某些对软件可靠性要求极高的特殊场合，如飞行控制软件等。
2.        非增式策略：
分别测试各个模块，最后一次组装起来进行测试。这种策略存在测试不够充分，发现问题难于定位，对测试人员把握全局的能力要求较高，易受环境有限等因素制约的缺点，但是它简单清楚，能够充分利用人力物力，如果运气好的话，能够把测试周期适当缩短。但总的来说，实施起来比较困难，就第一步，对各个模块分别测试就很难办到，一次组装起来，也可能“欲速而不达”。因此选择这种策略时需要慎重考虑，充分评估它的风险性。在具体实践中，遇到以下情况，可以谨慎采用非增式：
（1）、该特性所包含的各模块代码成熟度较高，（只有一两个模块是新增模块并经过比较充分的单元测试或各模块属于大部分移植而来）
（2）、模块之间关系密切，来往消息众多，有清晰的功能流程或数据流向把所有模块联系在一起；
这种情况下可以不对各个模块分别测试（或只对一两个关键模块测试一下），直接全部组装起来进行集成测试。 在实际工作中容易遇到这种情况，因此该策略应用较多，它的优点是工作量偏小，重点突出，实现容易。
3.        衍变式：
在实际工作中，我们往往会遇到一个子系统很庞大复杂，里面包含多个相对独立的特性，代码的成熟度适中，测试进度要求又偏紧，单纯采用以上任何一种策略都难以解决这种情况。一般来说，可以这样考虑：
（1）、按照关键特性进一步细分下去，相对独立的关键特性之间采用非增式策略分别测试
（2）、每一个关键特性下面，根据模块的复杂度，重要度，代码的成熟度，人力资源，测试进度等诸多因素，灵活选择策略。
5.2        集成测试方法
集成测试介于单元测试和系统测试之间，测试方法介于也相应的单元测试方法（白盒测试）和系统测试方法（黑盒测试），即业界通用的灰盒测试方法。集成测试方法主要采用黑盒测试方法来构造测试用例，也可以采用白盒测试方法。
集成测试主要依据是概要设计说明书，一般不过多的考虑集成测试对象（子模块）内部的实现，通过对模块功能、接口设计进行分析，覆盖所有的功能项目，重点的接口、重点的边界进行重点测试。具体如下：
        功能测试：从模块功能角度出发，HLD设计已经分析了模块功能和接口，选择并设计测试用例来尽可能覆盖所有的功能。
        接口协议测试：从模块间的消息流出发设计测试用例，将消息流中涉及的标准协议和自定通信协议的内容按照协议一致性和鲁棒性设计测试用例，比如消息检测状态机的超时机制进行。
        接口性能测试：设计适当的网络模型，对集成接口的进行必要的处理性能和冲击测试。
        异常测试：贯穿多种测试项目，模拟错误的数据配置和消息来设计测试用例。异常消息包括消息本身的异常、消息流程的异常、某状态下不处理消息等
        资源申请释放测试：资源是否正确申请并释放，并考虑申请释放的效率和性能是否满足需求

集成测试某种程度上也是一种白盒测试，因此我们需要对程序设计加强了解，对接口输入做出有意义选择。
6        ST Guideline 系统测试指导
6.1        系统测试策略
系统测试是对项目组开发的软件系统进行全面的测试，该软件系统可能是大型软件系统的一个组成部分，也可能是一个最终的软件系统，不管处于那种位置，软件的系统测试都存在接口，以及周边环境的配套关系。针对软件系统进行系统测试，主要考虑以下几个方面：
选择外部接口的测试方法；
明确测试对象的重点；
确定测试顺序
6.1.1        选择外部接口的测试方法
1.        与外部交互的接口都使用驱动或桩进行测试的方式
优点： 通过构造驱动模块和桩模块，可以屏蔽周边模块引入的错误，容易定位问题。另外还不受周边模块进度的影响。
缺点： 驱动模块和桩模块的工作量很大。 性能、可靠性测试进行不充分。
2.        与外部交互的接口不是使用驱动或桩，而是直接采用其他项目组的软件代码进行测试的方式。
3.        混合方式，就是一方面采用其他项目组比较稳定的软件代码，另一方面对风险较大的模块采用驱动或桩模拟的方式。
优点： 规避了风险，同时减少了驱动和桩模块开发的工作量。
缺点： 性能、可靠性测试进行不充分。
6.1.2        明确测试对象的重点
根据系统测试资源情况，分析测试对象，通过横向或纵向比较，确定测试重点， 并对测试重点优先测试、多投入资源。
（1）横向比较：横向比较是指所测试的不同功能之间的对比，包括以下方面：
        复杂度；
        需求优先级；
        对已有功能和接口的影响程度；
        对已有功能和接口的依赖性；
        需求之间的顺序、并行、制约等的依赖关系；
（2）纵向比较：纵向把握是指相同需求不同方面所要测试的对比，包括以下方面：
        基本功能测试；
        接口功能测试(包括接口协议和消息处理、对标准协议规范的处理)；
        性能测试；
        国际化方面的测试；
        可靠性测试：
        可用性测试：
6.1.3        确定测试顺序
虽然系统测试是对整个系统进行一系列的整体、有效性测试，但是测试对象间及其功能属性间可能存在一定的依赖关系，在确定测试顺序时需要重点考虑它们之间的依赖关系，包括以下三个方面：
        当前测试对象与其他对象是否存在依赖
        测试对象当前测试的功能对已有的功能是否存在依赖；
        测试对象当前测试的功能与其他新开发的功能是否存在依赖；
6.2        系统测试方法
系统测试是对项目组开发的软件系统进行整体测试，主要采用的测试方法是黑盒测试，业界比较成熟的测试方法有等价类划分，因果图、正交实验设计方法、边值分析、判定表驱动、功能测试等。
6.2.1        等价类划分
根据系统的输入域划分成若干部分，然后从每个部分中选取少数代表性数据当作测试用例。简单讲等价类是某个输入域的集合，它包括有效等价类和无效等价类。
有效等价类：指对程序的规格说明是有意义的、合理的输入数据所有构成的集合。
无效等价类：指对程序的规格说明不合理的或者无意义的输入数据所构成的集合。
6.2.2        因果图
因果图测试方法是根据输入条件的组合、约束关系和输出条件的因果关系进行组合测试的一种方法。
6.2.3        边界值分析
系统的大量错误往往发生在输入或输出范围的边界上，边界值分析就是根据输入输出等价类的边界值进行测试。基本思想是使用在最小值、略高于最小值、正常值、略低于最大值、最大值处取输入变量值，简称“4＋1”取值法。
6.2.4        正交实验设计法
所谓正交实验设计法，是从大量的实验点中挑选适量的、有代表性的点，应用依据伽罗瓦理论到处的“正交表”，合理的安排实验的一种科学的实验设计方法。利用这种方法，可使用所有因子和水平在实验中均匀的分配与搭配，均匀的有规律变化。
因子：通常把判断实验结果优劣的标准叫做实验指标，把有可能影响到实验指标的条件成为因子。
水平：影响实验因子的，就叫做因子的水平（或状态）。
该测试方法是软件功能测试的一种，常用来选取测试数据，提高测试效率。
6.2.5        判定表驱动测试
采用判定表进行数据分析测试的方法建成为判定表驱动测试。它可以把复杂的逻辑关系和多种组合条件的情况表达的既明确又具体。这种测试方法是复杂逻辑测试和组合复杂测试的最佳测试方法。
判定表：在一些数据处理问题中，某些操作依赖于多个逻辑条件的取值，这些条件的取值组合构成了多种情况下不同的操作，对这些问题分析和表达工具就是判定表。
6.2.6        功能测试
功能测试是不管程序内部的实现逻辑，以检验输入输出信息是否符合规格说明书中有关功能需求规定的为目标的测试方法。事实上前面的几种测试方法都是功能测试。

starseeker

难得总结了这么好的东西，这个不要说对新手就是2－3年经验的老手也有指导意义，放在其他版居然没人懂得欣赏，郁闷！
sdlkfj5

starseeker

在汇总一下

starseeker

最后加一个求助，谁知道TD中流程管理代码的写法和实现，希望告知则个。谢谢
我需要对流程的控制进行修改，还有能够在跳转时实现自动填写某些字段的信息。谢谢

starseeker

顶起，才２人下载就沉了啊

yiyi820106

好帖，不能沉啊。顶一个！！sdlkfj2

hihotb

好多多哦

cdq1010

好贴，下了慢慢看

tugang11

恩。。。顶了~~~

tugang11

好东西啊~~~顶了在顶

yzconj

好贴,顶下!

wanghuahua66

ding

wy3123863

十分感谢