单元测试方法里静态方法 java 静态测试的对象为

 

第七章

 

一、软件静态测试

1.概念

（1）静态测试：通常是指不执行程序代码而寻找代码中可能存在的错误或评估程序代码的过程。

（2）静态测试对象：各种与软件相关的有必要进行测试的产物，比如各类文档、源代码等。

2.特点

（1）不必动态地运行程序。

（2）可以人工进行，充分发挥人的思维优势。

（3）不需要特别的条件，容易展开。

（4）对测试人员要求比较高。

3.主要内容

（1）各阶段的评审：一般评审包括：培训评审、预备评审、同行评审，我们所关心的是同行评审

（2）代码检查：主要检查代码和设计的一致性、代码对标准的遵循、代码的可读性、代码的逻辑表达正确性，代码的合理性

（3）软件复杂性分析：主要包括软件复杂性度量与控制，软件复杂性度量元，面向对象的软件复杂性度量

（4）软件质量度量：就是从整体上对软件质量进行评测，用于软件开发中对软件进行质量控制，并最终对软件产品进行评价和验收

二、同行评审

（1）同行评审一般包括审查、小组评审、走查、桌面评审、临时评审五种类型。

（2）同行评审越正式，发现的缺陷越多，但评审越正式，花费成本越高

（3）同行评审类型的区别在于正式程度，正式程度从低到高：临时评审、桌面评审、走查、小组评审审查

（4）被评审对象越重要或者风险越高，采用的评审方式就越正式

三、代码检查

（1）定义：是以组为单位阅读代码，是一系列规程和错误检查技术的集合

（2）代码评审开展时间：代码全部或部分完成后

（3）测试目的：及早发现缺陷

（4）具体方法：一般采用静态“白盒”测试的方法

（5）代码检查输出的信息：度量标准、易产生错误的代码、代码规则的执行、流图和调用图的分析

四、软件复杂性分析

1.软件复杂性度量

（1）模块复杂性：模块复杂性度量主要用来对模块中的数据流和控制流结构（或模块信息流结构）和模块之间互连的复杂程度等进行度量和评价。

（2）总体复杂性度量：软件总体设计中，试图通过对总体复杂性的度量，力求平衡模块复杂性与模块结构复杂性。

2.软件复杂性控制

（1）模块复杂性控制：模块复杂性控制主要包括模块的大小和结构的控制。

（2）模块结构复杂性控制：模块独立，通常通过耦合性和内聚性对模块独立性进行控制。

（3）软件总体复杂性控制：它是在对软件的各种复杂性度量的基础上，在综合考虑软件开发成本、可靠性要求等一系列因素之后，对软件复杂性的一种平衡。

3.软件复杂性度量元

（1）结构：通常用与程序结构有关的度量来表示

（2）难度：通常由程序中出现的操作数的数目所决定的量来表示

（3）智能度：算法的难易程度

（4）规模：总共的指令数或源程序的行数

五、软件质量模型

1.软件质量概念

软件质量可用6个特性来评价：

（1）功能性：软件所实现的功能达到它的设计规范和满足用户需求的程度

（2）可靠性：在满足一定条件的应用环境中，软件能够正常维持其工作的能力

（3）可用性：对于一个软件，用户在学习、操作和理解过程中所做努力的程度

（4）效率：在规定条件下，用软件实现某种功能所需的计算机资源(包括时间)的有效程度

（5）维护性：当环境改变或软件运行发生故障时，为使其恢复正常运行所做努力的程度

（6）可移植性：为使一个软件从现有运行平台向另一个运行平台过度所做努力的程度

2.软件质量分层模型

（1）McCall模型：软件质量要素，衡量标准和量度标准。

（2）Boehm模型：软件质量模型第一层: 功能性、可靠性、可用性、效率、可维护性和可移植性

（3）ISO/IEC 9126质量模型：该模型将软件质量定义为六大特性：功能性、可靠性、可用性、效率、可维护性和可移植性，每个特性又分为一系列子特性。

（4）GB/T 16260-2006质量模型：该模型在上述模型的基础上对软件质量从6个质量特性和27个质量子特性进行概念性描述。

六、软件质量管理

1.软件质量管理三个关键阶段

（1）质量计划制定

（2）质量控制

（3）质量保证

2.项目中质量管理的原则

（1）软件质量的适度原则

（2）软件质量的落实原则

（3）以客户需求为指导的原则

3.软件质量管理的方法

（1）技术评审

（2）过程检查

（3）实施软件测试

 

第八章

 

一、白盒测试

1.白盒测试的概念

“白盒”测试又称为结构测试或逻辑驱动测试是一种按照程序内部逻辑结构和编码结构设计测试数据并完成测试的一种测试方法。

2.白盒测试的特点

（1）可以构成测试数据使特定程序部分得到测试

（2）有一定的充分性度量手段

（3）可获得较多工具支持

（4）通常只用于单元测试

3.白盒测试的基本测试内容

（1）对程序模块的所有独立执行路径至少测试一次

（2）对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次

（3）在循环的边界和运行的边界限内执行循环体

（4）测试内部数据结构的有效性

4.白盒测试技术

（1）静态白盒测试技术：代码检查、编码标准和规范

（2）动态白盒测试技术：逻辑覆盖测试、路径测试、数据流测试、信息流分析、覆盖率分析

5.逻辑覆盖

（1）语句覆盖：语句覆盖是最起码的测试要求，使得每一条语句至少被执行一次；对程序的逻辑覆盖很少，只关心判定表达式的值，是很弱的逻辑覆盖标准。

（2）判定覆盖：要求设计足够的测试用例，使得程序中的每一个分支至少通过一次即每一条分支语句的“真”值和“假”值都至少执行一次。

（3）条件覆盖：不仅每一个语句至少执行一次，使得判定中的每个条件获得各种可能的结果；判定覆盖只关心整个判定表达式的结果，条件覆盖关心的则是每个条件各种取值的结果。

（4）判定/条件覆盖：设计足够多的测试用例，使得判定中每个条件的所有可能取值至少能够获取一次，同时每个判断的所有可能的判定结果至少执行一次。

（5）条件组合覆盖：要求设计足够多的测试用例，使得每个判定中条件的各种组合至少出现一次；满足条件组合覆盖标准的测试用例，也一定满足判定覆盖、条件覆盖和判定/条件覆盖标准。

（6）路径覆盖：要求设计足够多的测试用例，使得程序中所有的路径都至少执行一次 。

6.路径测试

（1)概念：根据程序的逻辑控制所产生的路径进行测试用例设计的方法 。

（2）基本路径测试步骤：1) 根据过程设计结果画出相应的流图2) 计算控制流图的圈复杂度3) 确定线性独立路径的基本集合4) 设计可强制执行基本集合中每条路径的测试用例

二、黑盒测试

1.概念

黑盒测试又称功能测试或数据驱动测试，把测试对象当作看不见内部的黑盒，在完全不考虑程序内部结构和处理过程的情况下，测试者仅依据程序功能的需求规范考虑，确定测试用例和推断测试结果的正确性。

2.黑盒测试主要用到的方法

（1）等价类划分法

（2）因果图法

（3）边界值分析法

（4）猜错法

（5）随机数法

3.等价类划分

（1）概念：等价类，把所有可能的输入数据,即程序的输入域划分成若干部分,从每一部分中选取少数有代表性的数据做为测试用例，代表性数据等同于该类中的其他值。

（2）分类：有效等价类、无效等价类

（3）等价类划分步骤：划分确定等价类、选取测试用例

4.边界值分析

（1）概念：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法,稍高于其边界值及稍低于其边界值的一些特定情况。

（2）目的：针对各种边界情况设计测试用例，可以查出更多的错误

（3）方法：选取正好等于，刚刚大于，或刚刚小于边界的值做为测试数据

5.因果图

（1）概念：是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，该方法充分考虑了输入情况的各种组合及输入条件之间的相互制约关系。

（2）适用范围：适合检查程序输入条件的各种组合情况

（3）产生背景：等价类法、边界值法分析着重考虑输入条件，未考虑输入条件之间的关系

（4）用因果图生成测试用例的基本步骤：

A：分析软件规格说明描述：原因、结果、标识符

B：分析软件规格说明描述中的语义：找出逻辑关系

C：由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现，添加必要的约束条件

D:把因果图转换成判定表5)把判定表的每一列拿出来作为依据，设计测试用例

6.随机测试

随机测试指测试输入数据是所有可能输入值中随机选取的，是一种基本的黑盒测试方法。

7.猜错法

猜错法是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。

三、灰盒测试

1.灰盒测试与白盒测试的区别

（1）白盒测试在测试过程中测试者可以看到被测的源程序，通过分析程序的内部结构，根据其内部结构设计测试用例。

（2）灰盒测试无需关心模块内部的实现细节

2.灰盒测试与黑盒测试的区别

（1）黑盒测试是在测试者完全不考虑程序内部结构和内部特征的情况下，根据需求规格说明书设计测试用例和推断的测试结果的正确性。

（2）黑盒测试只考虑了程序的输入，以及在该情况下的输出，并没有考虑程序的内部结构。

（3）灰盒测试需关心模块与模块之间的交互。

3.灰盒测试概念

（1）灰盒测试是一种综合测试法，它将黑盒测试、白盒测试、回归测试结合在一起，构成一种无缝测试技术。

（2）灰盒测试一种软件全生命周期测试法，该方法通常是深入到用Ada/C/Fortran或汇编语言开发的嵌入式应用软件代码中进行功能的测试，或者与Web服务一起使用。

4.灰盒测试的优点

（1）能够进行基于需求的覆盖测试和基于程序路径覆盖的测试；

（2）测试结果可以对应到程序内部路径，便于bug的定位、分析和解决；

（3）能够保证设计的“黑盒”测试用例的完整性，防止遗漏软件的一些不常用的功能或功能组合；

（4）能够需求或设计不详细或不完整对测试造成的影响。

5.灰盒测试的不足

（1）投入的时间比“黑盒”测试大概多20-40%的时间

（2）对测试人员的要求比“黑盒”测试高

（3）要求测试人员清楚系统内部由哪些模块构成，模块之间如何协作

（4）不如白盒测试深入

（5）不适用于简单的系统

四、测试用例设计

1.测试用例的覆盖内容

正确性测试、容错性(健壮性)测试、完整(安全)性测试、接口测试、数据库测试、边界值测试、压力测试、等价划分测试、错误推测、效率、可理解(操作)性测试、可移植性测试、回归测试、比较测试 

2.测试用例主要元素

（1）测试环境

（2）测试输入数据

（3）测试执行步骤

（4）测试预期结果

3.测试用例设计步骤

（1）测试需求分析

（2）业务流程分析

（3）测试用例设计

（4）测试用例评审

（5）测试用例更新完善

4.测试用例分级

（1）重要性：1 基本、2 重要、3 一般、4 特殊

（2）优先级：1 高、2中、3低

五、单元测试

1.单元测试的好处

（1）程序最小组成部分

（2）可以并行开展

（3）规模小，复杂性低

（4）做好单元测试后，后续的集成测试和系统测试会很顺利

（5）不管怎样，集成测试或系统测试将会抓住所有的bug

（6）尽早的发现缺陷，降低测试成本

2.单元测试的内容

（1）模块接口测试

（2）局部数据结构测试

（3）路径测试

（4）错误处理测试

（5）边界测试

3.单元测试要求

（1）语句覆盖达到 100%

（2）分支覆盖达到 100%

（3）错误处理路径达到 100%

（4）单元的软件特性覆盖

（5）各种数据特性覆盖

4.单元测试步骤

（1）构造测试用例的运行环境

（2）设计“黑盒”测试用例

（3）设计“白盒”测试用例(覆盖测试用例)

六、集成测试

1.集成测试在软件分级测试中的意义

（1）在单元测试和系统测试间起到承上启下的作用，既能发现大量单元测试阶段不易发现的接口类错误，又可以保证在进入系统测试前及早发现错误，减少损失。

（2）能够较容易地测试到系统测试用例难以模拟的特殊异常流程，从纯理论的角度来讲，集成测试能够模拟所有实际情况。

2.集成测试的内容

（1）集成后的功能性测试

（2）接口测试

（3）全局数据结构测试

（4）资源测试（共享资源测试和资源极限测试）

（5）性能测试

（6）稳定性测试

3.集成测试的步骤

（1）体系结构分析

（2）模块分析

（3）接口分析

（4）风险分析

（5）可测试性分析

（6）集成测试策略分析

4.集成测试方法

（1）一次性组装

（2）渐增式组装：自顶向下、自底向上

七、确认测试

1.确认测试基本概念

（1）确认测试是严格遵循有关标准的一种符合性测试，以确定软件产品是否满足所给定的要求。

（2）确认测试是在完成集成测试后，依据确认测试准则，针对需求规格说明进行的测试，以确定所开发的软件系统是否能满足规定的功能和性能要求。

（3）确认测试必须有用户参加，或者是以用户为主进行用户应参与设计测试方案，使用用户界面输入测试数据，并分析测试结果，为使用户积极参与测试，有效使用系统，通常需要对用户进行培训。

（4）在确认测试中，alpha测试在开发现场进行、有用户参与，beta测试在客户现场进行。

2.确认测试过程

（1）有效性测试

A：在模拟的环境下，运用“黑盒”测试的方法，验证被测软件是否满足需求规格说明书列出的需求

B：仔细设计测试计划和测试过程

C：有效性测试两种结果：功能和性能与用户要求一致、功能和性能与用户要求有差距

（2）软件配置复查

A：其目的在于保证软件配置齐全、分类有序，并且包括软件维护所必须的细节。

B：除按合同要求，由人工审查软件配置外，还应该严格遵循用户指南及其他操作程序，以便检验这些使用手册的完整性和正确性。

（3）α测试和β测试

（4）验收测试

A：有效性及软件配置审查后就应该开始系统地验收测试。

B：验收测试是以用户为主的测试。

C：在测试过程中，除考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。

（5）确认测试结果

八、系统测试

1.系统测试的概念

（1）系统测试是将已经集成好的软件系统与计算机硬件、外设、网络、数据等其他元素结合在一起，在实际运行环境下，对软件信息系统的各种组装测试和确认测试。

（2）系统测试的目的：通过与系统的需求定义比较，检查软件是否存在于系统定义不符合或与之矛盾的地方，以验证软件系统的功能和性能等满足其规约指定的要求

（3）系统测试的对象：需要测试的产品系统的软件，软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及接口

2.系统测试中关注的重要问题

（1）系统测试过程定义：执行系统测试、评估系统测试

（2）系统测试需求获取：需求规格说明或系统测试项目合同等

（3）系统测试策略选择：测试策略用于说明某项特定测试工作的一般方法和目标

（4）系统测试采用的技术：系统测试主要采用黑盒测试技术

（5）系统测试环境建立：被测软件可能运行的环境有：开发环境、测试环境、用户环境

（6）系统测试人员组织：系统测试至少需要由一个独立的测试组来开展工作，或者由项目组为每一个软件项目成立测试组，确定测试经理一名，测试设计员和测试员多名。

（7）系统测试要交付的文档：系统测试计划、系统测试用例、系统测试脚本、系统测试报告

3.系统测试的类型及主要内容

（1）功能测试：对软件需求规格说明中的功能需求逐项进行的测试，以验证其功能是否满足需求。

（2）性能测试：对软件需求规格规格说明中的性能需求逐项进行的测试，以验证其性能是否满足要求。

（3）接口测试：对软件需求说明中的接口需求逐项进行的测试。

（4）人机交互界面测试：对所有人机交互界面提供的操作和显示界面进行的测试，以检验是否满足用户的要求；制软件运行在不正常到发生故障的情况下，检验软件可以运行到何种程度的测试。

（5）强度测试：软件运行在不正常到发生故障的情况下，检验软件可以运行到何种程度的测试。

（6）余量测试：对软件是否达到需求规格说明中要求的余量的测试。

（7）可靠性测试：在真实环境中，为做出软件可靠性估计而对软件进行的功能测试。

（8）安全性测试：检验软件中已存在的安全性、安全保密措施是否有效的测试。

（9）恢复性测试：对有恢复或重置功能的软件的每一类导致恢复或重置的情况，逐一进行的测试，以验证其恢复或重置的功能。

（10）边界测试：对软件处在边界或端点情况下运行状态的测试。

（11）数据处理测试：对完成专门数据处理功能所进行的测试。

（12）安装性测试：对软件安装过程是否符合安装规范的测试，以发现安装过程中的错误。

（13）容量测试：为验证软件的能力最高能达到什么程度的测试。

（14）互操作性测试：为验证软件之间的互操作能力而进行的测试。

（15）敏感性测试：为发现在有效输入类中可能引起某种不稳定性或不正常处理的某种数据的组合而进行的测试。

（16）标准符合性测试：验证软件与相关国家标准或规范一致性的测试。

（17）兼容性测试：验证软件在规定条件下雨若干个实体共同使用或实现数据格式转换时能满足有关要求能力的测试。

（18）中文本地化测试：验证软件在不降低软件原有能力的条件下，处理中文能力的测试。

4.测试设计的一般流程

（1）理解软件和测试目标

（2）设计测试用例

（3）运行测试用例并处理测试结果

（4）评估测试用例和测试设计