测试技术与方法.doc

测试技术与方法向平2013-07-101黑盒测试方法41.1等价类划分法41.2边界值分析法61.3因果图法71.4错误推断法71.5组合分析法82白盒测试方法82.1逻辑覆盖法102.1.1语句覆盖102.1.2判定覆盖122.1.3条件覆盖132.1.4判定/条件覆盖152.1.5条件组合覆盖162.2基本路径测试法192.2.1基本路径测试法的基本步骤192.2.2基本路径测试法的工具方法202.2.3程序的控制流图203单元测试253.1单元测试测试内容253.1.1模块接口263.1.2局部数据结构273.1.3重要的执行路径283.1.4错误处理293.1.5边界测试293.2单元测试步骤294集成测试314.1非渐增式测试314.2渐增式测试315确认测试（验收测试）365.1有效性测试375.2软件配置复复查375.3测试和测试376系统测试386.1恢复测试396.2安全性测试396.2.1静态的代码安全测试406.2.2动态的渗透测试406.2.3程序数据扫描406.3强度测试416.4性能测试416.4.1单交易基准测试426.4.2单交易负载测试426.4.3混合场景436.4.4稳定性测试446.4.5异常测试446.4.6极限测试456.4.7性能测试的主要策略456.4.8综合系统性能测试指标471黑盒测试方法1.1等价类划分法1.2边界值分析法例子：排序程序，边界条件有：u 序列为空；u 序列仅有一个数据；u 序列为满，用猜错法补充一下测试用例；u 序列已经按要求排好序；u 序列的顺序与要求的顺序恰好相反；u 序列中的所有数据全部相等。因为错误最容易发生在边界值附近，所以边界值分析法对于多变量函数的测试很有效，尤其是对于像C/C+数据类型要求不是很严格的语言有利 。例：(1) 使输出刚好等于最小的负整数。例如：输入：32768 预期的输出：32768(2) 使输出刚好等于最大的正整数。例如：输入：32767 预期的输出：32767(3) 使输出刚好小于最小的负整数。例如：输入：32769 预期的输出：“错误无效输入”(4) 使输出刚好大于最大的正整数。例如：输入：32768 预期的输出：“错误无效输入”1.3因果图法1.4错误推断法u 零作为测试数据往往容易使程序发生错误。u 分析规格说明书中的漏洞，编写测试数据。u 根据尚未发现的软件错误与已发现软件错误成正比u 的统计规律，进一步测试时重点测试已发现错误的程序段。u 等价类划分与边界值分析容易忽略组合的测试数u 据，因而，可采用判定表或判定树列出测试数据。u 与人工代码审查相结合，两个模块中共享的变量已u 被做修改的，可用来做测试用例。因为对一个模块测试出u 错，同样会引起另一模块的错误。1.5组合分析法组合分析是一种基于每对参数组合的测试技术，主要考虑参数之间的影响是主要的错误来源和大多数的错误起源于简单的参数组合。2白盒测试方法白盒测试(white box testing),也叫玻璃盒测试，对软件的过程性细节做细致的检查。这一方法是把测试对象看作是一个打开的盒子，它允许测试人员利用程序内壁的逻辑结构及有关信息，来设计或选择测试用例，对程序所有逻辑路径进行测试。从理论上讲白盒测试是可以进行完全的测试的。但实际测试中，这种穷举法是无法实现的，因为即使是很小的程序，也可能会出现数目惊人的逻辑路径。测试用例设计的基本目的：是确定一组最有可能发现某个错误或某类错误的测试数据。白盒测试主要测试方法有u 代码检查法u 静态结构分析法u 静态质量度量法u 逻辑覆盖法u 基本路径测试法（应用最广泛）u 域测试u 符号测试u Z路径覆盖u 程序变异只介绍主要的逻辑覆盖法和基本路径测试法。2.1逻辑覆盖法逻辑覆测试方法通常采用流程图来设计测试用例，它考察的重点是图中的判定框，因为这些判定通常是与选择结构有关或是与循环结构有关，是决定程序结构的关键成分白盒测试的用例设计2.1.1语句覆盖语句覆盖的含义是选择足够多的测试用例，使得被测程序中的每条语句至少执行一次。图7.3是测试的一段程序的流程图对应的C源程序(用C语言书写)。float A, B, X;if(A1&B= =0)X=X/A;if(A= =2|X1)X=X+1;为了使每条语句都执行一次，程序应该按sacbed路径执行，为实现此路径而选取下面的一组输入数据(实际上X可以是任意实数):A=2, B=0, X=2说明：这组数据只测试了条件为真的情况，若实际输入的条件为假时有错误显然测试不出来。事实上，语句覆盖对程序的逻辑覆盖很少，语句覆盖只关心判定表达式的值，而没有分别测试判定表达式中每个条件取不同值的情况。在上例中，为了执行sacbed路径以测试每个语句，只需两个判定表达(A1)AND(B=0)和(A=2)OR(X1)都取真值，上例中测试数据足够满足要求。但是，若程序中第一个判断表达式中的逻辑运算符“AND”错写成“OR”，或把第二个判定表达式中的条件“X1”误写成“X1”，上组测试数据则不符要求，不能查出这些错误。与后面所介绍的其他覆盖相比，语句覆盖是最弱的逻辑覆盖准则。2.1.2判定覆盖判定覆盖就是设计若干个测试用例，运行所测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。判定覆盖又称为分支覆盖。判定覆盖的每个语句至少经历一次。能够分别覆盖路径sacbed和sabd的一组测试数据，或者覆盖路径sacbd和sabed的两组测试数据均可满足判定覆盖标准。例如，以两组测试数据就可做到判定覆盖：(1) A=4，B=0，X=1(覆盖sacbd)；(2) A=2，B=1，X=3(覆盖sabed)。判定覆盖的缺点：仍然是覆盖的不全，只覆盖了路径的一半，如将X1误写成X1，上组(1)数据仍覆盖sacbd，可见判定覆盖仍然很弱，但比语句覆盖强。2.1.3条件覆盖条件覆盖就是设计若干个测试用例，运行所测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。条件覆盖使得每个语句至少执行一次。例如对于图7.3来说，共有两个判定表达式，每个表达式中有两个条件。为满足条件覆盖，在a点有以下几种情况出现：A1，A1，B0，B0；在b点有以下几种情况出现：A=2，A2，X1，X1。因而，只需要使用下面两组测试数据就可达到上述覆盖标准。(1) A=2，B=0，X=3(满足A1，B0，A=2和X1的条件，执行路径sacbed)；(2) A=0，B=1，X=0(满足A1，B0，A2和X1的条件执行路径sabd)。说明：条件覆盖一般比判定覆盖强，因为条件覆盖使判定表达式中每个条件都取到了两个不同的结果，判定覆盖却只关心整个判定表达式的值。上例两组测试数据也同时满足判定覆盖标准。但是，也可能有相反情况：虽然每个条件都取到了两个不同的结果，判定表达式却始终只取一个值。例如，若使用以下两组测试数据，则只满足条件覆盖标准并不满足判定覆盖标准。(1) A=2，B=0，X=1(满足A1，B0，A=2和X1的条件，执行路径sacbed)；(2) A=1，B=1，X=2 (满足A1，B0，A2和X1的条件，执行路径sabed)。上述例子的第二个判定表达式的值总为真，不满足判定覆盖的要求，为解决这一矛盾，需要对条件和分支兼顾。2.1.4判定/条件覆盖判定/条件覆盖就是设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，同时每个判断的所有可能判断结果至少执行一次。下述两组测试数据满足判定/条件覆盖标准。(1) A=2，B=0，X=4；(2) A=1，B=1，X=1。说明：判定/条件覆盖也有缺陷。从表面来看，它测试了所有条件的取值。但实际并不是这样。因为一些条件往往掩盖了另一些条件。对于条件表达式(A1)AND(B=0)来说，只要(A1)的测试为真，才需测试(B=0)的值来确定此表达式的值，但是若(A1)的测试值为假时，不需再测(B=0)的值就可确定此表达式的值为假，因而B=0没有被检查。同理，对于(A=2)OR(X1)这个表达式来说，只要(A=2)测试结果为真，不必测试(X1)的结果就可确定表达式的值为真。所以对于判定/条件覆盖来说，逻辑表达式中的错误不一定能够查得出来。2.1.5条件组合覆盖条件组合覆盖就是设计足够的测试用例，运行所测程序，使得每个判断的所有可能的条件取值组合至少执行一次。共有以下八种可能的条件组合：(1) A1，B=0 属第一个判断的取真分支；(2) A1，B0 属第一个判断的取假分支；(3) A1，B=0 属第一个判断的取假分支；(4) A1，B0 属第一个判断的取假分支；(5) A2，X1 属第二个判断的取真分支；(6) A2，X1 属第二个判断的取真分支；(7) A2，X1 属第二个判断的取真分支；(8) A2，X1 属第二个判断的取假分支。下面的四组测试数据可以使上面列出的八种组合每种至少出现一次：(1) A=2，B=0，X=4 (针对1，5两种组合，执行路径sacbed)；(2) A=2，B=1，X=1 (针对2，6两种组合，执行路径sabed)；(3) A=1，B=0，X=2 (针对3，7两种组合，执行路径sabed)；(4) A=1，B=1，X=1 (针对4，8两种组合，执行路径sabd)。说明：在此例中条件组合覆盖并未要求第一个判定的四个组合与第二个判定的四个组合再进行组合，要那样的话，就需42=16个测试用例了。显然，满足条件组合覆盖标准的测试数据，也一定满足判定覆盖、条件覆盖和判定/条件覆盖标准。因此，条件组合覆盖是前述几种覆盖标准中最强的。但是，满足条件覆盖标准的测试数据并不一定能使程序中的每条路径都执行到，如上述四组测试数据都没有测试到路径sacbd。2.2基本路径测试法基本路径测试法是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次。2.2.1基本路径测试法的基本步骤1) 程序的控制流图：描述程序控制流的一种图示方法。2） 程序圈复杂度：McCabe复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。 3） 导出测试用例：根据圈复杂度和程序结构设计用例数据输入和预期结果。4） 准备测试用例：确保基本路径集中的每一条路径的执行。2.2.2基本路径测试法的工具方法图形矩阵：是在基本路径测试中起辅助作用的软件工具，利用它可以实现自动地确定一个基本路径集。2.2.3程序的控制流图控制流程图是描述程序控制流的一种图示方法。圆圈称为控制流图的一个结点，表示一个或多个无分支的语句或源程序语句流图只有二种图形符号：图中的每一个圆称为流图的结点，代表一条或多条语句。流图中的箭头称为边或连接，代表控制流。任何过程设计都要被翻译成控制流图。2.2.3.1根据程序流程图化成控制流图在将程序流程图简化成控制流图时，应注意：1）在选择或多分支结构中，分支的汇聚处应有一个汇聚结点。2） 边和结点圈定的区域叫做区域，当对区域计数时，图形外的区域也应记为一个区域。如下页图所示：如果判断中的条件表达式是由一个或多个逻辑运算符 (OR, AND, NAND, NOR) 连接的复合条件表达式，则需要改为一系列只有单条件的嵌套的判断。例如：1 if a or b2 x3 else4 y对应的逻辑为：独立路径：至少沿一条新的边移动的路径2.2.3.2实例说明基本路径测试法的步骤：第一步：画出控制流图流程图用来描述程序控制结构。可将流程图映射到一个相应的流图(假设流程图的菱形决定框中不包含复合条件)。在流图中，每一个圆，称为流图的结点，代表一个或多个语句。一个处理方框序列和一个菱形决测框可被映射为一个结点，流图中的箭头，称为边或连接，代表控制流，类似于流程图中的箭头。一条边必须终止于 一个结点，即使该结点并不代表任何语句(例如：if-else-then结构)。由边和结点限定的范围称为区域。计算区域时应包括图外部的范围。例如：用如下基本路径测试法进行测试Void Sort(int iRecordNum, int iType) 1int x=0; 2Int y=0; 3while ( iRecordNum-0) 4 5 If(0=iType) 6x=y+2;break; 7else 8if(1=iType) 9x=y+10; 10else 11x=y+20; 12 13 14画出其程序流程图和对应的控制流图如下：第二步：计算圈复杂度圈复杂度是一种为程序逻辑复杂性提供定量测度的软件度量，将该度量用于计算程序的基本的独立路径数目，为确保所有语句至少执行一次的测试数量的上界。独立路径必须包含一条在定义之前不曾用到的边。有以下三种方法计算圈复杂度：A 流图中区域的数量对应于环型的复杂性;B给定流图G的圈复杂度V(G)，定义为V(G)=E-N+2，E是流图中边的数量，N是流图中结点的数量;C 给定流图G的圈复杂度V(G)，定义为V(G)=P+1，P是流图G中判定结点的数量。第三步：导出测试用例根据上面的计算方法，可得出四个独立的路径。(一条独立路径是指，和其他的独立路径相比，至少引入一个新处理语句或一个新判断的程序通路。V(G)值正好等于该程序的独立路径的条数。路径1：4-14路径2：4-6-7-14路径3：4-6-8-10-13-4-14路径4：4-6-8-11-13-4-14根据上面的独立路径，去设计输入数据，使程序分别执行到上面四条路径。第四步：准备测试用例为了确保基本路径集中的每一条路径的执行，根据判断结点给出的条件，选择适当的数据以保证某一条路径可以被测试到，满足上面例子基本路径集的测试用例是：路径1: 4-14输入数据：iRecordNum=0，或者取iRecordNum0的某一个值预期结果：x=0路径2: 4-6-7-14输入数据：iRecordNum=1，iType=0预期结果：x=2路径3 : 4-6-8-10-13-4-14输入数据：iRecordNum=1，iType=1预期结果：x=10路径2: 4-6-8-11-13-4-14输入数据：iRecordNum=1，iType=2预期结果：x=203单元测试单元测试的对象是软件设计的最小单位模块。单元测试的依据是详细设描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。单元测试多采用白盒测试技术，系统内多个模块可以并行地进行测试。 3.1单元测试测试内容：3.1.1模块接口测试要点(1) 实际参数与形式参数的个数是否相等。(2) 实际参数与形式参数的属性是否匹配。(3) 实际参数与形式参数的单位是否匹配。(4) 调用其他模块时所给实际参数的个数是否与被调模块的形参数个数相等。(5) 调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配。(6) 调用其他模块时所给实际参数的单位是否与被调模块的形参单位匹配。(7) 调用内部函数所用参数的个数、属性和次序是否正确。(8) 是否存在与当前入口点无关的参数引用。(9) 输入是否仅改变了形式参数。(10) 全程变量在各模块中的定义是否一致。(11) 常数是否当作变量传送。若一个模块需要完成外部的输入或输出时，还应检查下述各点：(1) 文件属性是否正确。(2) OPEN/CLOSE语句是否正确。(3) 格式说明与I/O语句是否匹配。(4) 缓冲器大小与记录长度是否匹配。(5) 文件是否先打开后使用。(6) 文件结束的条件是否处理过。(7) I/O的错误是否处理过。(8) 输出信息中是否有正文的错误。3.1.2局部数据结构检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。局部数据结构往往是错误的根源。应仔细设计测试用例，力求发现下面几类错误：(1) 不正确或不一致的说明。(2) 错误的初始化或错误的缺省值。(3) 拼写错或截短的变量名。(4) 不一致的数据类型。(5) 上溢、下溢和地址错误。除了局部数据结构外，如有可能，单元测试期间还应考虑全局数据(例如c语言的全局变量)对模块的影响。3.1.3重要的执行路径在模块中应对每一条独立的执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。此时，设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。此时，基本路径测试和循环测试是最常用、最有效的测试技术。计算中常见的错误如下：(1) 算术运算优先次序不正确或理解错误。(2) 运算方式不正确。(3) 初始化不正确。(4) 精度不够。(5) 表达式的符号表示错误。比较判断与控制流常常紧密相关，常见错误有：(1) 不同的数据类型比较。(2) 逻辑运算不正确或优先次序错误。(3) 因为精度误差造成本应相等的量不相等。(4) 比较不正确，或变量不正确。(5) 循环不终止或循环终止不正确。(6) 当遇到分支循环时，出口错误。(7) 错误地修改循环变量。3.1.4错误处理一个好的设计应能预见各种出错条件，并预设各种出错处理通路。出错处理通路同样需要认真测试，测试应着重检查下列问题：(1) 错误描述难以理解。(2) 错误提示与实际错误不相符。(3) 在程序自定义的出错处理段运行之前，系统已介入。(4) 对错误的处理不正确。(5) 提供的错误信息不足，无法确定错误位置和查错。3.1.5边界测试边界测试是单元测试步骤中的最后一步，也是最重要的一项任务。众所周知，软件通常容易在边界上失效，因而，采用边界值分析技术，针对边界值及其左、右值设计测试用例，很有可能发现新的错误。3.2单元测试步骤驱动模块（driver）模拟主程序功能，用于向被测模块传递数据，接收、打印从被测模块返回的数据。桩模块（stub）又称为假模块，用于模拟那些由被测模块所调用的下属模块功能。一般，驱动模块比桩模块容易设计。但都是额外开销。测试方法以白盒法为主。单元测试的步骤如下：(1) 按照图7.8配置测试环境，设计辅助测试模块。(2) 编写测试数据。根据逻辑覆盖及上述关于单元测试要解决的测试问题的考虑原则，设计测试用例。(3) 进行多个单元的并行测试。单元测试环境4集成测试集成测试也称组装测试，综合测试或联合测试。集成测试：是按设计要求把通过单元测试的各个模块组装在一起之后进行测试，以便发现与接口有关的各种错误。集成测试需考虑的有关问题（即为什么要进行集成测试）数据经过接口是否会丢失；一个模块对另一模块是否造成不应有的影响；几个子功能组合起来能否实现主功能；误差不断积累是否达到不可接受的程度；全局数据结构是否有问题。集成测试分为：非渐增式测试和渐增式测试。4.1非渐增式测试非渐增式测试方法是先分别测试每个模块，再把所有模块按设计要求放在一起，结合成所要的程序再进行测试。4.2渐增式测试渐增式测试是把下一个要测试的模块同已经测试好的那些模块结合起来进行测试，测试完以后再把下下一个应该测试的模块结合进来测试，这种测试每次增加一个模块。这种方法实际上同时完成单元测试和集成测试。两套方案：u 自顶而下增值u 自底而上增值1) 自顶向下结合自顶向下结合是一种递增的装配软件结构的方法。这种方法被日益广泛地采用，它需要连接程序，但不需要驱动程序。它是从主控制模块(“主程序”)开始，沿着软件的控制层次向下移动，从而逐渐把各个模块结合起来。自顶向下结合，把主控模块所属的那些模块都装配到结构中去时，有两种方案可供选择。深度优先策略，宽度优先策略深度优先策略先组装在软件结构的一条主控制通路上的所有模块。主控路径的选择决定于软件的应用特性。如上图，选取最左边的路径，先结合模块M1、M2和M5，接着是M8，如果M2的某个功能需要，可结合M6，然后再构造中央和右侧的控制通路。宽度优先策略宽度优先策略是沿软件结构水平地移动，把处于同一个控制层次上的所有模块组装起来。如上图，先结合模块M2、M3和M4(代替存根程序S4)，接着是M5、M6和M7(代替存根程序S7)这一层，如此继续进行下去，直到所有模块都被结合进来为止。自顶向下综合测试可归纳为以下五个步骤：(1) 用主控制模块做测试驱动程序，用连接程序代替所有直接附属于主控制模块的模块。(2) 依据所选的集成策略(深度优先或宽度优先)，每次只用一个实际模块替换一个桩模块。(3) 每集成一个模块立即测试一遍。(4) 只有每组测试完成后，才用实际模块替换下一个桩模块。(5) 为避免引入新错误，须不断进行回归测试(即全部或部分地重复已做过的测试)。2) 自底向上结合自底向上测试是从软件结构最低层的模块开始组装和测试，当测试到较高层模块时，所需的下层模块均已具备，因而不再需要桩模块。自底向上综合测试可归纳为以下四个步骤：(1) 把低层模块组合成实现一个特定软件子功能的族，如上图中，中模块族1、2、3。(2) 为每个族设计一个驱动软件，作为测试的控制程序，以协调测试用例的输入和输出。上图中，虚线接的框D1、D2、D3是各个族的驱动程序。(3) 对模块族进行测试。(4) 按结构向上次序，用实际模块替换驱动程序，将模块族结合起来组装成新的模块族，再进行测试，直至全部完成。例如，上图中，族1、族2上属于Ma，因而去掉D1和D2将这两个族直接与Ma接口；同样族3与Mb接口前将D3去掉；Ma与Mb最后与Mc接口。5确认测试（验收测试）确认测试又称有效性测试、合格测试或验收测试。模块组装后已成为完整的软件包，消除了接口的错误。确认测试主要由使用用户参加测试，检验软件规格说明的技术标准的符合程度，是保证软件质量的最后关键环节。5.1有效性测试制定测试计划，运用黑盒法，验证软件特性是否与需求符合。5.2软件配置复复查软件配置指软件工程过程中所产生的所有信息项:文档、报告、程序、表格、数据。随着软件工程过程的进展软件配置项（SCI softwareConfiguration Item）快速增加和变化。应复查SCI是否齐全。指软件工程过程中所产生的所有信息项:文档、报告、程序、表格、数据。随着软件工程过程的进展软件配置项（SCI softwareConfiguration Item）快速增加和变化。应复查SCI是否齐全。upportability Testing 可支持性测试5.3测试和测试测试是在开发机构的监督下，由个别用户在确认测试阶段后期对软件进行测试，目的是评价软件的FLURPS（功能、局域化、可使用性、可靠性、性能和支持），注重界面和特色。是在开发机构的监督下，由个别用户在确认测试阶段后期对软件进行测试，目的是评价软件的FLURPS（功能、局域化、可使用性、可靠性、性能和支持），注重界面和特色。测试由软件的多个用户对FLURPS进行测试，主要目的是测试系统的可支持性。进行测试，主要目的是测试系统的可支持性。FFunction Testing 功能测试LLocal Area Testing 局域化测试UUsability Testing 可使用性测试RRegression Testing 回归测试PPerformance Testing 性能测试SSupportability Testing 可支持性测试6系统测试系统测试是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行(使用)环境下，对计算机系统进行一系列的组装测试和确认测试。在系统测试实施之前，软件工程师应完成以下工作：为测试软件系统的输入信息设计出错处理通路；设计测试用例，模拟错误数据和软件界面可能发生的错误，记录测试结果，为系统测试提供经验和帮助；参与系统测试的规划和设计，保证软件测试的合理性。系统测试实质上是由一系列不同测试组成的，其主要目的是充分运行系统，验证系统各个部件是否都能正常工作并完成所分配的功能。以下，我们将讨论用于系统的几种软件系统测试类型。6.1恢复测试恢复测试主要检查系统的容错能力。当系统出错时，能否在指定的时间间隔内修正错误并重新启动系统。恢复测试首先要采用不同的方式强迫系统出现故障，然后验证系统是否能尽快恢复。如果恢复是自动的(由系统自身完成)，则重新初始化、检测点设置、数据恢复以及重新启动等都是对其正确性的评价。若恢复需人工干予，则需估算出修复的平均时间，确定其是否在可接受的限制范围以内。6.2安全性测试安全性测试(Security Testing)是指有关验证应用程序的安全等级和识别潜在安全性缺陷的过程。应用程序级安全测试的主要目的是查找软件自身程序设计中存在的安全隐患，并检查应用程序对非法侵入的防范能力, 根据安全指标不同测试策略也不同。注意：安全性测试并不最终证明应用程序是安全的，而是用于验证所设立策略的有效性，这些对策是基于威胁分析阶段所做的假设而选择的。例如，测试应用软件在防止非授权的内部或外部用户的访问或故意破坏等情况时的运作。目前主要安全测试方法有：6.2.1静态的代码安全测试主要通过对源代码进行安全扫描，根据程序中数据流、控制流、语义等信息与其特有软件安全规则库进行匹对，从中找出代码中潜在的安全漏洞。静态的源代码安全测试是非常有用的方法，它可以在编码阶段找出所有可能存在安全风险的代码，这样开发人员可以在早期解决潜在的安全问题。而正因为如此，静态代码测试比较适用于早期的代码开发阶段，而不是测试阶段。6.2.2动态的渗透测试渗透测试也是常用的安全测试方法。是使用自动化工具或者人工的方法模拟黑客的输入，对应用系统进行攻击性测试，从中找出运行时刻所存在的安全漏洞。这种测试的特点就是真实有效，一般找出来的问题都是正确的，也是较为严重的。但渗透测试一个致命的缺点是模拟的测试数据只能到达有限的测试点，覆盖率很低。6.2.3程序数据扫描一个有高安全性需求的软件，在运行过程中数据是不能遭到破坏的，否则就会导致缓冲区溢出类型的攻击。数据扫描的手段通常是进行内存测试，内存测试可以发现许多诸如缓冲区溢出之类的漏洞，而这类漏洞使用除此之外的测试手段都难以发现。例如，对软件运行时的内存信息进行扫描，看是否存在一些导致隐患的信息，当然这需要专门的工具来进行验证，手工做是比较困难的。6.3强度测试强度测试是要检查在系统运行环境不正常到发生故障的时间内，系统可以运行到何种程度的测试。强度测试是在要求一个非正常数量、频率或容量资源方式下运行一个系统。如：当平均速度有一种或两种时，可以设计每秒产生十个中断的特殊测试；定量地增长数据输入率，检查输入子功能的反映能力；运行需要最大内存或其他资源的测试用例；运行可能导致虚拟操作系统崩溃或磁盘剧烈抖动的测试用例等。6.4性能测试性能测试就是测试软件在被组装进系统的环境下运行时的性能。性能测试应覆盖测试过程的每一步。即使在单元层，单个模块的性能也可以通过白盒测试来评价，而不是等到所有系统元素全组装以后，再确认系统的真正性能。性能测试有时是与强度测试联系在一起的，常常需要硬件和软件的测试设备。性能测试流程主要性能测试：单交易基准测试、单交易负载测试、混合场景测试、稳定性测试、异常测试、极限测试。6.4.1单交易基准测试：测试原理：在测试环境经过确认，脚本预验证之后，针对每支选定的交易或操作，在系统无压力的情况下，单交易用户迭代若干次，获取每个交易或操作的平均响应时间，以此作为多用户并发测试的基准和参考。测试方法：使用性能测试工具LR模拟客户端向目标系统发送交易请求，在系统无压力的情况下重复50-100次（或10分钟），每次迭代间等待1秒，获取交易的平均响应时间、TPS、点击率作为衡量指标。6.4.2单交易负载测试测试原理：在完成单交易基准测试后，针对测试模型中的每一支交易或每一个操作，采用多个（5-10，是具体情况而定）虚拟用户数进行负载测试，获取业务处理性能和系统资源利用率等数据，并验证交易是否存在并发性问题。测试方法：实用LR模拟客户端向目标用户发送业务请求，并接受返回结果的脚本。采用梯度发送的方式逐步增加系统请求的压力，每个梯度测试持续运行10-15分钟并记录测试相关数据，获取该交易最大处理能力，同时进行资源监控，问题定位测试结果分析。6.4.3混合场景测试原理：在既定的测试模型下，在给定的测试限制条件下，通过在被测试系统上逐步增加的并发用户数，梯度增加压力，获得系统响应时间、吞吐量、CPU和内存的使用等性能数据。确定在各种工作负载下系统的性能指标，直到突破限定条件。获取在不同压力下的性能表现，以及交易的TPS、响应时间、系统资源利用率等指标数据。经过测试分析获取应用系统在该测试环境下的最大处理能力。测试方法:根据测试模型中的交易比例构成测试场景，使用LR模拟客户端向目标系统发起交易请求。按照并发梯度的方法，逐步提升并发用户数的压力，每组梯队运行15-20分钟。观察并收集应用系统的CPU、内存、磁盘的占用情况、交易响应情况、交易成功率等指标。直到系统出现容量拐点或瓶颈后结束测试。（若在各项参数指标满足参考预设值，同时交易响应时间，TPS指标满足业务需求即可记录和结束测试；若在测试过程中，某项指标未达到预期，随即进入调优过程，直至达标后记录最后测试结果；若因时间等原因无法完成最终调优过程，详细描述测试过程，并记录当前系统的最高性能处理能力）6.4.4稳定性测试测试原理：根据混合场景负载测试结果，采用系统容量峰值的60%-80%的压力负载，稳定运行8-12小时，检验应用系统在测试环境下的稳定运行能力，获取系统长时间运行的稳定性指标。根据应用系统的操作习惯或业务处理规律，必要时采用变化的交易压力的方式，进行稳定性测试。主要方式是随机和定时的变更交易压力，有益于根据业务运行规律模拟真实状况下的系统运行状况。测试方法：根据单交易场景负载测试结果，结合生产实际业务量的统计，推算负载测试模型系统峰值的压力60-80%的并发压力。使用LR连续发起并发压力8-12小时，主要监控系统的CPU、内存、磁盘的占用情况和交易响应情况，主要是检查内存泄漏、网络处理能力、负载均衡等问题，检验系统在持续压力状况下的稳定运行能力。6.4.5异常测试测试原理：在单节点故障或者网络故障等问题发生时，系统的处理能力，数据的完整性。测试方法： 通过一定方法（如断开网线