单元测试标准.docx
《单元测试标准.docx》由会员分享，可在线阅读，更多相关《单元测试标准.docx（11页珍藏版）》请在冰豆网上搜索。
单元测试标准
项目治理文档
单元测试标准
编写
审核
审批
文档管理
。
文档修订摘要
日期
修订号
描述
著者
审阅者
批准人/日期
第1章引言
1.1文档用途
本文档是科技（中国）研发部门内部利用的关于进行单元测试（UnitTest）的标准性文档，本文档中描述了单元测试的原那么、流程和方式，是软件开发人员在进行单元测试的时候的工作指南。
1.2阅读对象
此文档适合以下人员阅读：
●项目领导
●产品开发工程师
●EPG成员
●PPQA人员
1.3参考资料
《有效软件测试方式与应用》飞思科技产品研发忠心电子工业出版社
《软件工程－实践者的研究方式》RogerS.Pressman机械工业出版社
《面向对象的软件测试》JohnD.McGregor,DavidA.Sykes机械工业出版社
《软件测试－原书第2版》PaulC.Jorgensen机械工业出版社
第2章概述
单元测试是对软件大体组成单元进行的测试，所谓“单元”是指：
●具有明确的功能
●具有明确的规格概念（详细设计规格说明书）
●有与其他部份明确的接口概念
●能够与程序的其他部份清楚的进行区分
单元测试的偏重点在于发觉程序设计或实现中的逻辑错误。
它分为打算、设计、实现、执行和评估五个步骤。
各步骤的概念如下：
1）打算单元测试：
确信测试需求，制订测试策略，确信测试所用资源，创建测试任务的时刻表。
2）设计单元测试：
设计单元测试模型，制订测试方案，确认测试进程
3）实现单元测试：
依照单元测试打算和方案，制订具体的测试用例，创建可重用的测试脚本。
4）执行单元测试：
依照单元测试的方案、用例对软件单元进行测试，验证测试结果并记录测试进程中显现的缺点。
5）评估单元测试：
对单元测试的结果进行评估，要紧从需求覆盖和代码覆盖的角度进行测试完备性的评估。
第3章单元测试步骤
3.1设计单元测试方案
3.1.1输入、输出
输入工作产品
待测程序单元
输出工作产品
《XXX单元测试方案》
3.1.2任务
1.设计单元测试的模型，一样如以下图所示
驱动模块
被测单元
测试用例
桩模块
桩模块
桩模块
测试结果
构造单元测试模型需要：
●概念（设计）驱动模块，用以挪用被测程序单元
●概念（设计）测试桩模块，用以模拟被测程序单元挪用的函数接口
●设计测试数据和状态，预备单元测试的动态结构
●确信测试的流程
另外，测试模型也可能是由所采纳的测试工具所决定的。
2.指定测试项目：
指定对不同特性（或特性组合）进行足够测试的途径，包括测试工具、方式和技术的描述和对测试结果进行提取和分析的方式。
3.概念测试完备性标准（例如代码覆盖、途径覆盖或条件覆盖），并设计判定测试完备性的手腕，例如利用工具或设计测试代码等。
3.2编写单元测试CASE
3.2.1输入、输出
输入工作产品
《XXX单元测试方案》
输出工作产品
单元测试案例
测试环境
3.2.2任务
1.依照《XXX单元测试方案》构造测试环境（将待测程序单元纳入测试工具；实现驱动模块和桩模块），编写测试代码（自己开发或利用测试工具）。
需要的时候生成或导入测试所需要的数据。
2.设计单元测试案例
设计测试案例的时候要依照《XXX单元测试方案》中所规定的测试方式、测试项目和完备性标准进行。
单元测试案例的设计，要紧有以下五个步骤：
1）为系统运行起来设计测试用例
第一需要设计如此的测试用例，该用例的执行能够证明测试环境和被测单元是可用的。
若是如此的测试案例失败了，其他的测试案例都失去了执行的基础
2）为正向测试而设计测试用例
第二需要设计正向测试案例。
这些案例也是大体的单元测试案例，它们是用来证明设计规格说明书中对应的功能和性能指标是不是能够实现的。
这些测试案例是依照设计说明书中的描述来开发的。
3）为逆向测试而设计测试用例
逆向测试的测试用例是用来证明软件没有做不该该做的情形。
那个步骤能够基于错误猜想的基础进行测试用例的构造。
4）为特殊要求设计测试用例
从系统的性能、平安性、保密性的角度为具有这些要求的系统制订的测试用例。
5）为覆盖率设计测试用例
测试案例的设计要保证必然的覆盖率要求，因此在最后一步还需要补充一些测试案例，以保证测试案例对代码、途径、或条件的覆盖率。
在单元测试的设计当中，针对测试项目和测试覆盖率的要求常常采纳如下的一些方式：
A）规格导出法
B）等价类划分法
C）边界值分析法
D）状态转移测试法
E）分支测试法
F）条件测试法
G）数据概念－利用测试法
H）内部边界值测试法
I）错误猜想法
这些方式的具体描述，请参见附录一。
3.将设计好的测试案例用工具或文档记录下来。
在需要的时候，标注某个测试案例是为了哪个测试项目而设计的。
一样来讲，测试案例都需要注明：
测试条件、测试输入、测试操作和预期输出这四大要素。
4.将设计好的测试案例编写成为测试脚本（testscript），若是设计自动化测试，驱动模块从测试脚本中逐条读取测试案例而且通进程序或测试人员的目测判定程序单元的行为或输出是不是符合预期。
一样来讲，测试工具或驱动模块也需要将每一条测试案例执行的结果进行记录，以供分析之用。
3.3执行单元测试
3.3.1输入、输出
输入工作产品
单元测试案例
输出工作产品
单元测试结果记录
3.3.2任务
1.执行单元测试案例
对单元测试案例的执行一样意味着由驱动模块读取测试脚本，然后通进程序判定或测试人员目测判定的方式确认测试案例是不是执行通过。
a）第一应该确保测试环境和测试程序能正常执行，若是不能正常执行那么需要进行相应修改直至正常。
b）在碰到测试案例执行失败而无法执行以后的单元测试案例时，需要调整被测程序单元直到该案例能够正常执行。
修改以后需要从头执行之前的测试案例（回归测试）。
利用测试工具或编写自动化的测试驱动模块能够使这项工作相对容易些。
2.对测试案例的执行结果进行记录，若是利用工具或编写了自动化的测试驱动模块，这一步工作能够自动化。
3.依照测试结果修改源代码，从头构造测试环境；需要的时候修改测试案例。
3.4分析单元测试结果
3.4.1输入、输出
输入工作产品
单元测试结果
输出工作产品
单元测试总结报告
3.4.2任务
1.分析测试的完备性，判定是不是执行了事前设计的所有测试案例和在测试进程中新增加的测试案例。
2.利用工具或其他自概念的方式判定单元测试的覆盖率是不是符合事前概念的覆盖率。
3.若是未能达到覆盖率，那么补充测试案例，从头执行测试。
附录1单元测试案例设计指南
1.单元测试目的
单元测试案例的设计要验证被测程序单元的如下这些方面：
1）是不是正确实现了规定的功能
2）模块内部是不是存在错误
2.常见模块单元的错误
模块内部错误往往存在于以下方面：
1）模块接口：
测试模块的数据流
a）挪用所测模块时输入参数与模块的形式参数在个数、属性、顺序上是不是匹配
b）所测模块在挪用其他模块时，它输入给其他模块的参数在个数、属性、顺序上是不是匹配
c）是不是修改了只做输入用的形式参数
d）输出给标准函数的参数在在个数、属性、顺序上是不是匹配
e）全局变量的概念在各模块中是不是一致
f）限制是不是通过形式参数来传递
2）局部数据结构：
g）不正确的或不一致的数据类型说明
h）利用未赋值或未初始化的变量
i）错误的初始值或错误的默许值
j）变量名拼写错误
k）不一致的数据类型
3）途径错误：
不正确的计算、比较和操纵流
4）错误处置
l）犯错的描述难以明白得
m）犯错的描述不足以对错误定位和确信犯错缘故
n）显示的错误与实际错误不符
o）对错误条件的处置不正确
p）在对错误进行处置之前，错误条件已经引发了系统的干与
5）边界
q）在循环的第0次，第一次和最后一次是不是有错误
r）运算或判定中最大最小值是不是有错误
s）数据流、操纵流中恰好大于、小于或等于最大或最小值时是不是有错误
3.单元测试案例常见设计方式
以下是一些单元测试案例的常见设计方式，通过对这些方式的综合运用，能够帮忙咱们发觉上述这些错误。
1）规格导出法
规格导出法是依照有关的规格说明来设计测试用例，每一个测试用例用来查验一个或多个规格陈述的语句。
一个比较实际的方法是依照规格陈述的语句顺序来为被测单元设计测试用例。
这种测试用例的设计能够保证在规格说明中所有的要求在测试案例中都能取得表现，可是它只是一种正向测试的思路，需要其他的测试用例的补充才能达到测试的完整性。
2）等价类划分法
等价类划分是一种正式的测试用例设计方式，它基于被测单元的输入、输出所做的划分，对每一个划分中的所有输入、被测单元都有相同（等价）的反映。
例如对一个范围是0-100的整数输入来讲，2,38,66应该都具有相同的效劳，而－1，120也有相同的效劳。
等价类划分法确实是针对每一个等价类设计至少一个测试案例来确保被测程序单元的处置是完整的。
等价类划分的设计方式也属于正向测试的技术。
3）边界值分析法
边界值分析法利用与等价类划分法相同的划分，只是边界值分析假定错误更多地存在于两个划分的边界上，相应地为边界上及双侧的情形设计测试用例。
4）状态转移测试
关于那些以状态机作为模型或设计为状态机的软件，状态转移测试是适合的。
状态转移测试法的测试案例涵盖能致使状态迁移的事件来测试状态之间的转换是不是正确。
用这种方式能够测试逆向的测试用例，如状态和事件的非法组合。
5）分支测试法
在分支测试中，依照单元中操纵流分支或判定点来设计测试用例。
这通经常使用于达到必然的测试覆盖率。
在单元测试中，若是利用黑盒测试技术，那么需要去猜想存在哪些逻辑分支并相应为这些分支的执行预备测试用例，若是利用白盒测试技术，那么那么需要依照该程序单元中的操纵流设计测试案例，完成份支覆盖的要求。
6）条件测试法
条件测试法中包涵了很多测试案例设计技术，它们都致力于弥补在碰到复杂逻辑条件的时候分支测试的弱点。
条件测试的目标是测试在每一个逻辑条件的单个成份及它们组合的情形下程序都是正确的。
在考虑各个逻辑条件的组合的时候，决策表是一种有效的工具。
在条件测试法中，需要设计足够的测试案例，确保每种逻辑条件的组合都被测试到。
7）数据概念－利用测试法
数据概念是指数据被赋值的地址，数据利用是指数据项被读取或利用的地址。
利用这种方式设计测试案例时，要紧考虑用案例来驱动数据被概念到被利用的途径。
这种方式要紧用于检查数据的初始化和处置的正确性，也能够在静态检查中利用。
8）内部边界值测试法
这种方式与边界值分析法类似，可是它偏重的是白盒测试技术，也确实是说从程序单元的规格说明中导出等价类和边界值。
除外部可见的数据之外，程序的内部的数据也存在等价类和边界值，它们只能通过对程序单元的设计规格说明进行分析而取得。
内部边界值测试法一样只作为测试案例设计的补充方式，与其他方式结合利用。
9）错误猜想法
错误猜想是基于体会和其他一些测试技术的。
在体会的基础上，测试设计者猜想错误的类型及在特定的软件中错误发生的位置，并设计测试用例去发觉它们。
例如，若是所有的资源需要动态申请，那么咱们就需要判定是不是所有的资源都被正确释放了。
一个发觉错误的好地址确实是资源释放的地址。
对一个有体会工程师，错误猜想法可能是最好的设计测试案例的方式，因为它可能发觉别的设计方式所遗漏的错误。
为了最大限度的利用有效的体会并慢慢丰硕测试用例的设计技术，成立一个错误类型的列表是一个好方式，那个列表能够帮忙工程师猜想程序单元中的错误解在哪里。
那个列表需要通过在实践中不断的保护和扩充来帮忙达到错误猜想的有效性。
升级会员 