单元测试标准.docx
- 文档编号:13934972
- 上传时间:2023-06-19
- 格式:DOCX
- 页数:12
- 大小:56.76KB
单元测试标准.docx
《单元测试标准.docx》由会员分享,可在线阅读,更多相关《单元测试标准.docx(12页珍藏版)》请在冰点文库上搜索。
单元测试标准
单元测试标准
批准人
审核人
拟制人
批准日期
生效日期
关
联
文
件
单元测试实施规程(R-10002)
设计文档标准(S-04001)
广东海斯贝尔网络科技有限公司
更改记录
序号
发行日
更改对象·更改内容
批准
审查
拟制
目录
1.测试的一般事项
1.1测试的目的与分类2/4
1.2测试与调试的区分2/4
2.对测试过程的准备2/4
3.单元测试作业的标准
3.1作业流程2/4
3.2制作单元测试方案书2/4
3.3测试结果的研讨及调试3/4
3.4程序的修正及再编译4/4
3.5单元测试结束报告书4/4
附图:
附图1、单元测试例书写方法1/4
附图2、单元测试例书写例式2/4
附图3、单元测试结束报告书式3/4
附图4、问题分析表4/4
1.测试的一般事项
1.1测试的目的与分类
测试是以发现错误为目的执行程序的过程。
也就是说,测试并不是为了验证程序是正确的,而是为了找出程序中隐藏的错误。
如果经过测试没有发现任何错误,在确认该程序是正确无误的之前,应该先确定测试过程本身的有效性。
测试分为静态测试和动态测试两类。
静态测试也称为桌面检查,是指通过对程序代码的分析找出程序中可能出现的问题。
1.2测试与调试的区分
在进行测试之前一定要认清测试和调试的区别。
测试的目的是发现错误,而调试的目的是对错误进行定位,分析错误的原因并加以改正。
2.对测试过程的准备
以自底向上测试方法为基础构造测试过程。
自底向上测试是从模块树的下一级别的程序模块开始进行测试的方式。
这种测试不需做成支撑模块,但需要驱动模块。
有许多种测试工具和系统特有的工具,可根据各程序的性质充分地利用这些工具。
3.单元测试作业标准
3.1作业流程
单元测试从编译错误全部被修正时开始,到提交单元测试结束报告书时结束。
单元测试结束报告书(附图3)是对是否进行了全部测试的再确认,同时也是通知该程序已经测试结束的手续。
测试人员对在单元测试过程中发现的问题,应做记录并进行原因分析。
分析和记录的格式见(附图4问题分析表),并且要和单元测试成绩书的各项相对应。
3.2制作单元测试方案书
单元测试必须做成某种形式的测试方案书。
这是因为不具有测试方案书的测试不具备判定测试结束的标准。
标准的单元测试方案书的制作方法如下:
(1)制作测试例
依照测试例来推进测试。
对于所有的测试例,都得到了预想的结果时,认为对该程序的测试已经结束。
从这种角度上来说,测试例的设定就非常的重要。
若在测试例中有重大遗漏时,就会使该程序不能被全部测试到。
(2)测试例的确认
确认测试例覆盖的程序范围。
由于程序的复杂性,对每个模块都进行单元测试要花费大量的时间制作相应测试的支撑模块或驱动模块,同时因为与实际环境不同,造成测试结果与实际运行结果之间存在一定的差异。
因此单元测试时,可只对基本的模块进行测试,其它测试可在组合测试时进行。
(3)制作测试数据
可在决定测试例的同时制作测试数据,也可分开来作。
对于单元测试,测试数据的制作者主要是实际测试者。
(4)测试的准备
单元测试方案书原则上由程序设计者来制作。
测试数据由测试者(通常是程序制作者)制作。
测试者应对测试程序的每个测试例如何在机器上运行及数据设定的方法等进行研讨。
在实际测试中只能找出那些可以同输出结果进行对照的错误。
也就是说,大体上可以覆盖与程序的本来功能有关的错误,对于由其它程序的输入/输出不合格而造成的错误(排它、资源的释放等)就很难找出来。
这充分说明了动态测试的局限性,从而体现了桌面检查(对程序流程,设计文档等的检查)的重要性。
单元测试方案书的记述方法
对于将测试例的设计与测试数据的设计分开进行时,主要由程序设计者进行测试例的设计,而由测试执行者负责测试数据的制作。
但是,如果根据测试例不能决定测试数据,也写不出预定的结果时(多见于以计算为主的程序中),由程序设计者负责测试数据的制作。
(1)测试例的记述
关于测试例的设计,没有必要进行程序代码级的检查,(所谓的桌面检查是在测试数据的制作阶段应该进行的作业。
)但有必要进行覆盖率的确认。
测试例的记述方法如附图1所示、测试例的记述范例如附图2所示。
(2)测试数据的记述
原则上是由测试者制作测试数据。
但是,测试数据列表不只限定为后记的格式。
也可以采用与测试程序相适合的形式。
3.3测试结果的研讨及调试
对测试中发现的错误进行调试,必须以桌面调试为主。
机器调试作为一种补助手段。
调试时通常会采取如下的顺序进行:
(1)是否正确地设定了测试数据?
由于意外,测试数据没有被正确地设定或没有全部设定,这样属于测试本身的错误的情况也很多。
因此,将参照数据做成列表,进行确认是很有意义的。
(2)有无编码错误?
语句被误写成了注释,符号出错(I:
1、O:
0等),因为没有说明而成为缺省说明,这样的错误会成为意外和盲点。
(3)测试例在程序设计上已经被假定了吗?
这是一个根本性的问题,但是如果不注意的话,就会将程序向错误的方向修正。
(4)条件判定是正确的吗?
在缩小“bug”的范围的基础上,应确认程序是否通过了所定的路径。
(5)OS宏/函数/模块等(系统调用)的使用方法、输入/输出方法是正确的吗?
错误地使用各种宏及子程序也很常见。
通常返回到原点进行确认,是早期发现“bug”的一个方法。
(6)缩小错误的范围
从得到的结果和条件来缩小错误的范围,根据错误的种类有多种不同的方法,但其基本是对得到的数据进行详细的研讨从而找出矛盾。
若以上的项目全部都被检查确认过了,大多情况是若正确检查了要检查的项目,应该能够发现绝大部分的“bug”。
以下为在调试时必须注意的其它事项:
1)不可漏掉错误
发生了错误,而且没有再现性时,就无视该错误而想通过,这是常情。
但是,该错误在今后的某个时候肯定会再次发生的。
因此,测试者一定要重视。
2)要考虑种种的可能性
出现了错误,在一般的情况下直接就可以想到错误的位置。
但是有时当不能在该地点发现“bug”时,因为先入为主的观念,就会发生不再考虑别的地点而在该地点浪费时间的现象。
在怎么也找不到“bug”时,有必要到别的地点去找找原因,或是将想法全部重新整理一下。
3)对于一个错误要考虑存在多个“bug”
在发现了一个“bug”时,在此处还有“bug”的概率就变得很高。
因此,在已发现的“bug”不能完全地对错误进行说明时,必须要想到此处还可能存在“bug”。
4)不要抱住错误
常常有为了微不足道的“bug”而浪费了很多时间的情况。
很多即使对于他人是一目了然的“bug”,而担当者却很难发现。
因此,对于无论做了怎样的调查仍不明白的错误,应该同上级或设计者商量。
常有在进行说明的同时发现“bug”的情况。
3.4程序的修正及再编译
若能在调试时明白错误的原因,接下来就要考虑程序的修正、编辑、再编译。
这种工作看上去好象是当然的,而实际上是极其重要的工作。
这是因为,对程序的修正,有可能使到此为止合格的测试全都化为乌有。
而且,草率的更改进一步产生更改,接下去就有可能破坏了程序的结构,而成为不易收拾的状态。
因此,关于程序的修正、再编译必须遵守以下的事项:
1)一定要先确认程序的修正对于程序的其它部分没有影响。
在无论如何要产生影响时,要重新测试。
2)程序的修正一定要先在清单上清楚地写上以后再进行。
千万不可进行只在头脑中考虑的修正。
3)一定要认真并且整洁地填写清单。
不可进行别人看不懂的修正。
4)一定要保留程序的更改经历。
在测试中经常有前一次的修正对下一次的测试造成影响的情况。
一定要保留更改履历。
5)若程序修正并不是编码上的错误,而是程序设计上的错误的话,就一定要先进行程序规范书的修正。
3.5单元测试结束报告书
若是对所有的测试例都得到了正确的结果,根据单元测试结束报告,进行再确认,制作单元测试结束报告书,单元测试结束报告样式见附图3。
附图1单元测试例书写方法
程序名(模块名)
测试项目
测试方法
预想结果
判定良否
日期
判定者
问题及备注
测试例的序号及测试例名
主要以各测试例的以下各点为中心记述:
1目的—本测试的含义
(在不易理解时记述)
2内容—进行什么样的测试
3条件—在什么样的条件下进行测试。
*条件复杂时,也可在附页上做成各条件的组合表,取得与各测试例对应。
记述各测试例的:
1.预想结果(无错误时的结果)
2.记述以外的应进行检查的项。
对于错误而进行程序的修正,而修正涉及到程序规范书的修正时记述。
附图2单元测试例书写例
SSGETMOD模块读出宏
测试项目
测试方法
预想结果
判定良否
日期
判定者
问题及备注
1.正常读出1
(onlineon时)
确认在CPUonline状态时,对边界mode序号的读出是正常的。
1.读出mode单一
2.读出mode多个
回车情况=0
读出数据=被set为MMMODTBL的值
·读出数据没有破坏的领域以外
良
6/10
中西
2.正常读出2
(onlineoff时)
1CPUoffline状态时的连续读出
scc1online……
scc2offline……确认对读出在此中间的mode状态的scc2的mode中,全部选择了offmode。
回车情报=0
读出数据
MMMODTBL的
scc1内容
scc2
modegrant=0
(仅是与online有关的mode)
良
6/11
中西
3参数异常测试
1确认在读出范围外的modeNO.时为错误(超越下限时)
2同上(超越上限时)
3在连续读出mode中,在指定了超越最大mode序号的读出个数时的参数异常回车
回车情报=2
参数异常message的输出
良
6/11
中西
因为在连续读出中,没有超越范围时的参数检查,而修正了程序。
(参考)online状态时将checkmodule作为stubmodule进行测试。
附图3单元测试结束报告书
批准
审查
担当
模块名
语言
模块_ID
担当者
W/T日期
W/T记录品质号
承认日
承认者
设 计
编码
单元测试规范
单元测试成绩
设计书页数
枚
CodeReview有无
有 ・ 无・
Step数
KStep
测试项目数
项目
不合格数
件
检查覆盖率
项目/Kstep
错误命中率
件/项目
错误密度
件/Kstep
附图4问题分析表
问题分析表
批准
审查
担当
程序名:
测试项目:
测试方法:
不合格现象:
不合格原因分析:
修改方法:
修改担当:
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 单元测试 标准