单元测试标准

《单元测试标准》由会员分享，可在线阅读，更多相关《单元测试标准（11页珍藏版）》请在装配图网上搜索。

1、管理资源吧（），提供海量管理资料免费下载！更多免费下载，尽在管理资源吧（）单元测试标准S-10001REV-2作业标准S-10001总页数8正文4附件4文件控制部门:项目管理部单元测试标准 批准人刘岩审核人崔戈拟制人刘慧丰批准日期1999.5.12生效日期1999.5.12关联文件单元测试实施规程(R-10002)设计文档标准（S-04001）沈阳东东系统集成有限公司沈阳东东系统集成有限公司S-10001REV-0单元测试标准更改记录序号发行日更改对象更改内容批准审查拟制01999.5.12新发行刘岩崔戈刘慧丰沈阳东东系统集成有限公司P-4/4S-10001REV-0单元测试标准目 录1.测试

2、的一般事项1.1 测试的目的与分类2/41.2 测试与调试的区分2/42.对测试过程的准备2/43.单元测试作业的标准3.1 作业流程2/43.2 制作单元测试方案书2/43.3 测试结果的研讨及调试3/43.4 程序的修正及再编译4/43.5 单元测试结束报告书4/4附图：附图1、单元测试例书写方法1/4附图2、单元测试例书写例式2/4附图3、单元测试结束报告书式3/4附图4、问题分析表4/41.测试的一般事项1.1测试的目的与分类测试是以发现错误为目的执行程序的过程。也就是说，测试并不是为了验证程序是正确的，而是为了找出程序中隐藏的错误。如果经过测试没有发现任何错误，在确认该程序是正确无误

3、的之前，应该先确定测试过程本身的有效性。测试分为静态测试和动态测试两类。静态测试也称为桌面检查，是指通过对程序代码的分析找出程序中可能出现的问题。1.2测试与调试的区分在进行测试之前一定要认清测试和调试的区别。测试的目的是发现错误，而调试的目的是对错误进行定位，分析错误的原因并加以改正。2.对测试过程的准备以自底向上测试方法为基础构造测试过程。自底向上测试是从模块树的下一级别的程序模块开始进行测试的方式。这种测试不需做成支撑模块，但需要驱动模块。有许多种测试工具和系统特有的工具，可根据各程序的性质充分地利用这些工具。3.单元测试作业标准3.1作业流程单元测试从编译错误全部被修正时开始，到提交单

4、元测试结束报告书时结束。单元测试结束报告书（附图3）是对是否进行了全部测试的再确认，同时也是通知该程序已经测试结束的手续。测试人员对在单元测试过程中发现的问题，应做记录并进行原因分析。分析和记录的格式见（附图4 问题分析表），并且要和单元测试成绩书的各项相对应。3.2制作单元测试方案书单元测试必须做成某种形式的测试方案书。这是因为不具有测试方案书的测试不具备判定测试结束的标准。标准的单元测试方案书的制作方法如下：(1)制作测试例依照测试例来推进测试。对于所有的测试例，都得到了预想的结果时，认为对该程序的测试已经结束。从这种角度上来说，测试例的设定就非常的重要。若在测试例中有重大遗漏时，就会使该

5、程序不能被全部测试到。(2)测试例的确认确认测试例覆盖的程序范围。由于程序的复杂性，对每个模块都进行单元测试要花费大量的时间制作相应测试的支撑模块或驱动模块，同时因为与实际环境不同，造成测试结果与实际运行结果之间存在一定的差异。因此单元测试时，可只对基本的模块进行测试，其它测试可在组合测试时进行。(3)制作测试数据可在决定测试例的同时制作测试数据，也可分开来作。对于单元测试，测试数据的制作者主要是实际测试者。(4)测试的准备单元测试方案书原则上由程序设计者来制作。测试数据由测试者(通常是程序制作者)制作。测试者应对测试程序的每个测试例如何在机器上运行及数据设定的方法等进行研讨。 在实际测试中只

6、能找出那些可以同输出结果进行对照的错误。也就是说，大体上可以覆盖与程序的本来功能有关的错误，对于由其它程序的输入/输出不合格而造成的错误(排它、资源的释放等)就很难找出来。这充分说明了动态测试的局限性，从而体现了桌面检查（对程序流程，设计文档等的检查）的重要性。 单元测试方案书的记述方法对于将测试例的设计与测试数据的设计分开进行时，主要由程序设计者进行测试例的设计，而由测试执行者负责测试数据的制作。但是，如果根据测试例不能决定测试数据，也写不出预定的结果时（多见于以计算为主的程序中），由程序设计者负责测试数据的制作。(1)测试例的记述关于测试例的设计，没有必要进行程序代码级的检查，(所谓的桌面

7、检查是在测试数据的制作阶段应该进行的作业。)但有必要进行覆盖率的确认。测试例的记述方法如附图1所示、测试例的记述范例如附图2所示。(2)测试数据的记述原则上是由测试者制作测试数据。但是，测试数据列表不只限定为后记的格式。也可以采用与测试程序相适合的形式。3.3测试结果的研讨及调试 对测试中发现的错误进行调试，必须以桌面调试为主。机器调试作为一种补助手段。 调试时通常会采取如下的顺序进行：(1) 是否正确地设定了测试数据？由于意外，测试数据没有被正确地设定或没有全部设定，这样属于测试本身的错误的情况也很多。因此，将参照数据做成列表，进行确认是很有意义的。(2)有无编码错误？语句被误写成了注释，符

8、号出错(I：1、O：0等)，因为没有说明而成为缺省说明，这样的错误会成为意外和盲点。(3)测试例在程序设计上已经被假定了吗？这是一个根本性的问题，但是如果不注意的话，就会将程序向错误的方向修正。(4)条件判定是正确的吗？在缩小“bug”的范围的基础上，应确认程序是否通过了所定的路径。(5)OS宏/函数/模块等(系统调用)的使用方法、输入/输出方法是正确的吗？错误地使用各种宏及子程序也很常见。通常返回到原点进行确认，是早期发现“bug”的一个方法。(6)缩小错误的范围从得到的结果和条件来缩小错误的范围，根据错误的种类有多种不同的方法，但其基本是对得到的数据进行详细的研讨从而找出矛盾。若以上的项目

9、全部都被检查确认过了，大多情况是若正确检查了要检查的项目，应该能够发现绝大部分的“bug”。以下为在调试时必须注意的其它事项：1)不可漏掉错误发生了错误，而且没有再现性时，就无视该错误而想通过，这是常情。但是，该错误在今后的某个时候肯定会再次发生的。因此，测试者一定要重视。2)要考虑种种的可能性出现了错误，在一般的情况下直接就可以想到错误的位置。但是有时当不能在该地点发现“bug”时，因为先入为主的观念，就会发生不再考虑别的地点而在该地点浪费时间的现象。在怎么也找不到“bug”时，有必要到别的地点去找找原因，或是将想法全部重新整理一下。3)对于一个错误要考虑存在多个“bug”在发现了一个“bu

10、g”时，在此处还有“bug”的概率就变得很高。因此，在已发现的“bug”不能完全地对错误进行说明时，必须要想到此处还可能存在“bug”。 4)不要抱住错误常常有为了微不足道的“bug”而浪费了很多时间的情况。很多即使对于他人是一目了然的“bug”，而担当者却很难发现。因此，对于无论做了怎样的调查仍不明白的错误，应该同上级或设计者商量。常有在进行说明的同时发现“bug”的情况。3.4程序的修正及再编译若能在调试时明白错误的原因，接下来就要考虑程序的修正、编辑、再编译。这种工作看上去好象是当然的，而实际上是极其重要的工作。这是因为，对程序的修正，有可能使到此为止合格的测试全都化为乌有。而且，草率的

11、更改进一步产生更改，接下去就有可能破坏了程序的结构，而成为不易收拾的状态。因此，关于程序的修正、再编译必须遵守以下的事项：1)一定要先确认程序的修正对于程序的其它部分没有影响。在无论如何要产生影响时，要重新测试。2)程序的修正一定要先在清单上清楚地写上以后再进行。千万不可进行只在头脑中考虑的修正。3)一定要认真并且整洁地填写清单。不可进行别人看不懂的修正。4)一定要保留程序的更改经历。在测试中经常有前一次的修正对下一次的测试造成影响的情况。一定要保留更改履历。5)若程序修正并不是编码上的错误，而是程序设计上的错误的话，就一定要先进行程序规范书的修正。3.5单元测试结束报告书若是对所有的测试例都

12、得到了正确的结果，根据单元测试结束报告，进行再确认，制作单元测试结束报告书，单元测试结束报告样式见附图3。P-2/4(附)S-10001REV-0单元测试标准附图1 单元测试例书写方法CPU 程序名（模块名）测试项目测试方法预想结果判定良否日期判定者问题及备注测试例的序号及测试例名主要以各测试例的以下各点为中心记述：1目的本测试的含义(在不易理解时记述)2内容进行什么样的测试3条件在什么样的条件下进行测试。*条件复杂时，也可在附页上做成各条件的组合表，取得与各测试例对应。记述各测试例的：1.预想结果(无错误时的结果)2.记述以外的应进行检查的项。对于错误而进行程序的修正，而修正涉及到程序规范书

13、的修正时记述。(参考)在同实际的运行状态不同的条件下进行测试时，记述其内容。(例如stub的利用等) 或者记述单元测试很困难，即使做了也没有什么意义而省略了的测试以及在组合测试时应该确认的事项。 附图2单元测试例书写例共同 SSGETMOD 模块读出宏 测试项目测试方法预想结果判定良否日期判定者问题及备注1.正常读出 1(online on时)确认在CPU online状态时，对边界mode序号的读出是正常的。1.读出mode单一2.读出mode多个回车情况=0读出数据=被set为MMMODTBL的值读出数据没有破坏的领域以外良6/10中西2.正常读出 2(online off时)1 CPU

14、offline状态时的连续读出 scc1 online scc2 offline 确认对读出在此中间的mode状态的scc2的mode中，全部选择了offmode 。 回车情报=0读出数据 MMMODTBL的 scc1 内容 scc2 mode grant=0 (仅是与online有关的mode)良6/11中西3参数异常测试1 确认在读出范围外的mode NO.时为错误(超越下限时)2 同上(超越上限时)3 在连续读出mode中，在指定了超越最大mode序号的读出个数时的参数异常回车回车情报=2参数异常message的输出良6/11中西因为在连续读出中，没有超越范围时的参数检查，而修正了程序。 (参考)online状态时将check module作为stub module进行测试。P-4/4(附)S-10001REV-0单元测试标准附图3单元测试结束报告书批准审查担当模块名语言模块_ID担当者W/T日期W/T记录品质号承认日承认者设计编码单元测试规范单元测试成绩设计书页数枚Code Review 有无有无 数KStep测试项目数项目不合格数件检查覆盖率项目Kstep错误命中率件项目错误密度件Kstep附图4 问题分析表问题分析表批准审查担当程序名：测试项目：测试方法：不合格现象：不合格原因分析：修改方法： 修改担当：