《HS∕T 35-2011 单元测试指南(海关).pdf》由会员分享，可在线阅读，更多相关《HS∕T 35-2011 单元测试指南(海关).pdf（20页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、ICS 35.040 L77 HS 中 华 人 民 共 和 国 海 关 行 业 标 准 HS/T 352011 单元测试指南 Unit testing guide 2011-08-12 发布 2011-10-01 实施 中华人民共和国海关总署 发 布 HS/Z XXXXXX 1 目 次 前言.3 引言.4 1 范围.5 2 术语和定义.5 2.1.5 单元测试 unit testing.5 2.2.5 白盒测试 white box testing.5 2.3.5 黑盒测试 black box testing.5 2.4.5 错误推测 error guessing testing.5 2.5.5
2、 驱动 driver.5 2.6.5 桩 stub.5 3 单元测试的目标和任务.6 3.1 单元测试的目标.6 3.2 单元测试的任务.6 3.2.1 模块接口测试.6 3.2.2 模块局部数据结构测试.6 3.2.3 模块边界测试.6 3.2.4 模块通路测试.7 3.2.5 模块错误处理通路测试.7 3.3 单元测试的范围.7 3.4 单元测试与调试的区别.8 4 单元测试的方法.8 4.1 白盒测试.8 4.2 黑盒测试.8 4.3 错误推测法.8 5 单元测试的流程.8 5.1 流程定义.8 5.2 单元测试的策划.9 5.2.1 内容.9 5.2.2 输入.9 HS/Z XXXXX
3、X 2 5.2.3 输出.9 5.3 单元测试用例的设计.9 5.3.1 内容.10 5.3.2 输入.10 5.3.3 输出.10 5.4 单元测试用例的执行.10 5.4.1 内容.10 5.4.2 输入.10 5.4.3 输出.10 6 单元测试的常用工具.10 6.1 Visual Studio Team Test.10 6.2 NUnit.11 6.3 TestDriven.NET.11 6.4 JUnit.11 附 录 A（资料性附录）单元测试计划及报告.12 附 录 B（资料性附录）单元测试工作分解.15 附 录 C（资料性附录）单元测试用例管理.16 附 录 D（资料性附录）单
4、元测试缺陷管理.17 参考文献.19 HS/Z XXXXXX 3 前 言 本标准依据国标GB/T 1.1-2009起草。本标准由中华人民共和国海关总署科技发展司提出。本标准由中华人民共和国海关总署政策法规司归口。本标准起草单位：中华人民共和国海关总署科技发展司、全国海关信息中心（电子通关中心）。本标准主要起草人：*、*。本标准是第一次制定。HS/Z XXXXXX 4 引 言 软件项目开发中执行单元测试的目标是在软件开发过程中尽可能早的发现应用项目开发过程中存在的缺陷，为更好的完成项目开发过程中的单元测试工作，提高海关科技应用项目的产品质量，特制定适用于海关科技应用项目单元测试指南。依据海关科技
5、应用项目管理办法并结合海关科技应用项目的开展过程，制定本标准。HS/Z XXXXXX 5 单元测试指南 1 范围 本标准给出了海关信息系统软件新开发或修改过的代码在单元测试工作中可使用的流程、方法、工具。2 术语和定义 下列术语和定义适用于本文件。2.1 单元测试 unit testing 对软件程序最小单位模块开展的正确性检验的测试工作。2.2 白盒测试 white box testing 利用程序内部的逻辑结构及有关信息，设计测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致的测试方法。2.3 黑盒测试 black box testing 已知
6、程序所具有的功能，基于接口设计测试用例，通过在不同输入时，检查实际输出结果是否与预期输出结果一致的测试方法。2.4 错误推测 error guessing testing 根据测试人员的经验和直觉，推测程序最有可能出错的地方，有针对性的选择测试用例进行测试的测试方法。2.5 驱动 driver 对底层或子层模块进行测试所编写的调用这些模块的程序。2.6 桩 stub HS/Z XXXXXX 6 对顶层或上层模块进行测试时所编写的替代下层模块的程序。3 单元测试的目标和任务 3.1 单元测试的目标 单元测试的目标是保证软件程序最小单位模块的正确编码。通过单元测试，发现被测试模块的实际功能与预定义
7、的功能之间的不符合情况，或者编码的错误。3.2 单元测试的任务 3.2.1 模块接口测试 模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。测试接口正确与否，应从以下方面展开测试：输入的实际参数与预定义参数的个数是否相同、属性是否匹配、值域是否一致；调用其他模块时所给实际参数与被调模块的预定义参数的个数是否相同相同、属性是否匹配、值域是否一致；调用预定义函数时所用参数的个数、属性和次序是否正确；输入的实际参数为空时，程序能够正确处理；是否存在与当前入口点无关的参数引用；对全程变量的定义各模块是否一致。在模块内包括外部输入输出的情况下，还应从以下方面开展测试
8、：文件属性是否正确；OPEN/CLOSE 语句是否正确；格式说明与输入输出语句是否匹配；缓冲区大小与记录长度是否匹配；文件使用前是否已经打开；是否处理了文件尾；是否处理了输入/输出错误；输出信息中是否有文字性错误。3.2.2 模块局部数据结构测试 局部数据结构测试是为了保证临时存储在模块内的数据在程序执行过程中完整和正确。局部数据结构是错误的根源，应在设计测试用例时，确认是否有下面几类错误：不合适或不相容的类型说明；变量无初值；变量初始化或缺省值有错；不正确的变量名（拼错或不正确地截断）；出现上溢、下溢和地址异常。除局部数据结构测试外，单元测试时还应查清全局数据对模块的影响。3.2.3 模块边
9、界测试 模块边界测试是单元测试中最重要的一项任务。软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，可能发现新的错误。常见的边界值包括：HS/Z XXXXXX 7 数据类型的边界，例如：对于 16 位整数而言，32767 和-32768 是其边界值；对于日期而言，1900-1-1 和 2999-12-31 是其边界；位置的边界，例如：屏幕光标、窗体位置的最左上、最右下是其边界值；对象的边界，例如：报表的第一行和最后一张是其边界值；数组元素、记录集的第一行和最后一张是其边界值；程序逻辑的边界，例如：循环的第 0 次、第 1 次、最后 1 次是其边界值。3.2.4 模块通
10、路测试 在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。在模块通路测试中，可能发现以下常见的错误：误解或用错了算符优先级；混合类型运算；变量初值错；精度不够；表达式符号错。比较判断与控制流常常紧密相关，测试用例还应致力于发现下列错误：不同数据类型的对象之间进行比较；错误地使用逻辑运算符或优先级；因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等；比较运算或变量出错；循环终止条件或不可能出现；递归时不能退出；错误地修改了循环变量。3.2.5 模块错误处理通路测试
11、软件设计应能预见各种出错条件，并预设各种出错处理通路，出错处理通路同样需要认真测试，测试应着重检查下列问题：输出的出错信息难以理解；记录的错误与实际遇到的错误不相符；错误描述中未能提供足够的定位信息；在程序自定义的出错处理段运行之前，系统已介入；异常处理不当。3.3 单元测试的范围 对软件进行全面的单元测试需要较大的工作量，投入较长的时间，因此，项目组可根据具备的资源情况，逐步扩大单元测试的范围。第一步，对所有程序中的公开类以及公开类里面的公开方法进行单元测试。第二步，对应用或程序初始化过程中运行的代码（例如：公共属性或构造函数）进行单元测试。第三步，进行全面的单元测试。在做第一步单元测试的时
12、候，也应有选择性的、有重点的进行测试。HS/Z XXXXXX 8 首先，应针对属于应用软件框架中的代码进行单元测试。具体包含操作数据库的组件、操作外部Web Service的组件、后台服务与前台程序之间的消息传递的组件。通过为这些主要的可复用代码进行测试，可加强程序底层操作的正确性和健壮性。其次，应使用业务逻辑层对界面公开的方法进行单元测试。以达到业务逻辑正确和业务操作被归纳到单元测试中的目的，从而保证在产品发布之后，出现问题时，可直接通过业务逻辑的单元测试来找到缺陷。剩下的代码大部分属于代码生成器生成的，而且大多数的操作都是类似的，因此我们可先针对某一个业务逻辑对象做详细的单元测试。通过这样
13、的步骤，单元测试可有序的开展。3.4 单元测试与调试的区别 单元测试与调试的对象及采用的方法虽然相似，但其目的却完全不同。单元测试是为了找出软件中存在的缺陷，而调试是为了解决存在的缺陷。4 单元测试的方法 4.1 白盒测试 在单元测试过程中，可使用白盒测试方法对软件的过程性细节做检查。测试人员应了解程序的内部结构，并利用程序内部的逻辑结构及有关信息，设计或选择测试用例，通过在不同点检查程序状态，确定实际状态是否与预期的状态一致，对程序所有逻辑路径进行测试。测试人员编写的测试用例要进行语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和独立路径覆盖。4.2 黑盒测试 黑盒测试方法能够辅助
14、白盒测试发现白盒测试未能发现的其他类型的错误。测试人员可从正确性、可用性、边界条件、性能、压力、错误处理、安全性、兼容性等方面，开展黑盒测试。测试过程中，需要编写驱动程序或桩程序，通过运行被测试单元接口的程序，来检查单元的正确性。执行黑盒测试的测试人员必须先了解当前被测试单元所具有的功能，在测试中可完全不考虑程序内部结构，仅基于接口进行测试，测试每个功能是否都能使用。测试过程中，测试人员应关注被测试单元的输入、输出。4.3 错误推测法 错误推测法能够使测试人员更快切入测试工作，更有针对性的开展测试工作。测试人员可根据自己的工作经验和直觉推测出程序可能存在的错误，进行测试。由于不同测试人员经验不
15、同，不同程序容易出错的地方不同，为了避免测试中忽略大量未知区域的测试，在测试过程中，测试小组需要首先集思广益，列举程序中最容易、最有可能出错的地方，选择测试用例进行测试，从而避免引起测试工作的偏差。5 单元测试的流程 5.1 流程定义 HS/Z XXXXXX 9 单元测试活动，包括单元测试的策划、单元测试用例的设计、单元测试用例的执行。单元测试的流程如图1所示。单元测试的策划单元测试用例的设计单元测试用例的执行结束开始是否存在缺陷是修改代码否 图1 单元测试流程 5.2 单元测试的策划 5.2.1 内容 单元测试的策划，主要是对单元测试时间、人员、职责、分工、工作量，以及所需的软件资源、硬件资
16、源进行策划，对具体的单元测试工作任务进行分解，确定单元测试的要求、终止测试的条件，制定具体计划。单元测试计划的内容及格式参见附录A，单元测试工作分解的内容及格式参见附录B。5.2.2 输入 项目计划 5.2.3 输出 单元测试计划 5.3 单元测试用例的设计 HS/Z XXXXXX 10 5.3.1 内容 测试用例是为特定的目的而设计的一组输入、执行条件和期望的结果。单元测试用例的设计，应根据软件的设计信息，选取测试数据，将增大发现各类错误的可能性。在确定测试用例的同时，应给出期望结果。在设计单元测试用例时，需要编写驱动程序或桩程序，通过运行被测试单元接口的程序，来检查单元的正确性。驱动程序或
17、桩程序应作为测试用例的一部分进行配置管理。测试用例在执行时，还需要一些数据输入。因此，在设计测试用例时，还应进行测试数据的准备。准备测试数据时，应结合测试用例执行的场景，软件的基础数据环境进行准备，尽量提高测试数据的真实性，防止由于脏数据问题导致测试用例执行失败。单元测试用例的内容及格式参见附录C。5.3.2 输入 单元测试计划、详细设计 5.3.3 输出 单元测试用例（包括驱动程序、桩程序、测试数据）5.4 单元测试用例的执行 5.4.1 内容 单元测试用例的执行，应紧接在编码之后，当源代码编制完成并通过代码复查和编译，便可开始执行单元测试。将用例执行结果与预期结果进行对比、验证，发现可能存
18、在的缺陷。对于单元测试中发现的缺陷，进行记录，然后对源代码进行修改，再进行单元测试，直至符合单元测试的结束条件，编制单元测试报告，完成单元测试。实现单元测试期间的工作情况、测试用例执行情况、缺陷发现及修复情况应进行跟踪记录。单元测试缺陷管理的内容及格式参见附录D。5.4.2 输入 单元测试用例、源代码文件 5.4.3 输出 单元测试报告、工作跟踪情况、测试用例执行情况、缺陷管理表 6 单元测试的常用工具 6.1 Visual Studio Team Test Visual Studio Team Test 是Visual Studio集成的单元测试框架，从Visual Studio 2005开
19、始，可以完成对C#、VB代码的单元测试。Team Test在单元测试方面，具有以下特性：在开发工具的集成开发环境（IDE）中运行；所有的测试代码位于一个单独的项目，尽可能少的影响被测试的代码；可以从数据库中加载测试数据；测试运行完成后，可以进行代码覆盖分析。HS/Z XXXXXX 11 6.2 NUnit NUnit是一个开源的，支持.Net语言的单元测试框架。具有以下特性：不依赖开发工具的集成开发环境（IDE），可以独立运行；轻型框架，运行速度快；不支持调试，需要结合 NCover 一起使用才能进行代码覆盖分析。6.3 TestDriven.NET TestDriven.NET是以插件的形式
20、集成在Visual Studio.NET 开发环境（IDE）中的单元测试工具，它集成NUnit单元测试框架以及.NET Reflector、NConver、NConverExplorer等工具，功能更加强大。TestDriven.NET在单元测试方面，具有以下特性：免配置，能够兼容各种 Visual Studio 版本；轻型框架，运行速度快；功能丰富，解决了 NUnit 无法调试、无法进行代码分析等缺憾。6.4 JUnit JUnit是一个开源的，基于面向对象构建的Java单元测试框架，在1997年由Erich Gamma和Kent Beck开发完成。JUnit在单元测试方面，具有以下特性：提
21、供的 API 可以使测试人员写出测试结果明确的、可复用的单元测试用例；提供了三种方式显示测试结果，还可以按需要进行扩展；提供了单元测试用例批量运行的功能；框架易于扩展；轻型框架且使用简单。HS/Z XXXXXX 12 附 录 A（资料性附录）单元测试计划及报告 A.1 项目信息 项目信息见表A.1。表A.1 项目信息 内容内容 项目信息项目信息 项目名称:项目 ID:单元测试计划开始日期：单元测试计划结束日期：单元测试实际开始日期：单元测试实际结束日期：A.2 策划信息 A.2.1 人员和职责 人员和指责信息见表A.2。表A.2 人员和职责 姓名姓名 主要职责主要职责 能力要求能力要求 备注备
22、注 A.2.2 软件环境 软件环境信息见表A.3。表A.3 软件环境 软件环境软件环境 软件类型软件类型 环境要求环境要求 操作系统 数据库软件 开发工具 模拟器 HS/Z XXXXXX 13 编译器 测试工具 外部系统 浏览器 A.2.3 硬件环境 硬件环境信息见表A.4。表A.4 硬件环境 硬件环境硬件环境 硬件类型硬件类型 环境要求环境要求 数据库服务器 最低配置 中间层服务器 最低配置 客户端 最低配置 A.2.4 环境准备情况 已具备 未具备 A.3 单元测试准则 A.3.1 测试开始标准 例如：被测试的代码开发完成，测试工具、测试的软件、硬件环境准备完毕、测试用例准备完毕，执行单元
23、测试的人员准备就绪，可以开始正式进行单元测试。A.3.2 测试通过标准 例如：底层代码的单元测试覆盖率达到100%，单元测试用例执行100%，单元测试发现的缺陷中已经全部被关闭，可认为单元测试通过。A.4 其他信息 A.4.1 批准 批准信息见表A.5。表A.5 批准信息 批准方式批准方式 记录保存路径记录保存路径 评审通过 批准人：批准日期：HS/Z XXXXXX 14 A.4.2 裁剪信息 裁剪信息见表A.6。表A.6 裁剪信息 裁剪项裁剪项 裁剪内容裁剪内容 裁剪原因（适用条件）裁剪原因（适用条件）A.4.3 备注 备注信息见表A.7。A.5 备注信息 内容内容 说明说明 A.6 单元测
24、试报告 A.6.1 单元测试结论 例如：本系统底层代码已全部通过单元测试，单元测试用例已全部执行，单元单元发现的缺陷已经全部关闭，符合本项目单元测试通过的条件，本项目单元测试通过。A.6.2 分析与建议 例如：在进行错误通路类型的单元测试中，发现由于在需求、设计中对错误处理要求不详细，导致出现了很多不人性化的错误被系统抛出，建议今后细化此部分内容。无其他改进建议。HS/Z XXXXXX 15 A B 附 录 B（资料性附录）单元测试工作分解 B.1 工作任务分解 工作任务分解信息见表B.1。表B.1 工作任务分解 工作任务分解工作任务分解层次层次 工作包工作包 计划计划 实际实际 1 2 3
25、4 5 阶段阶段 过程过程 构构件件 单单元元 任任务务 任任务务描描述述 工工作作产产品品 任任务务类类别别 负负责责人人 计划计划 开始开始 日期日期 计划计划结束结束日期日期 计计划划人人时时 实际实际开始开始日期日期 实际实际结束结束日期日期 实实际际人人时时 技术活动技术活动 HS/Z XXXXXX 16 B C 附 录 C（资料性附录）单元测试用例管理 C.1 单元测试用例列表 单元测试用例列表见表C.1。表C.1 单元测试用例列表 编号编号 测试用例名称测试用例名称 测试模块或代码测试模块或代码 制作人制作人 制作制作 日期日期 执行人执行人 执行执行 日期日期 结果记录结果记录
26、 C.2 单元测试用例 单元测试用例信息参见表C.2。表C.2 单元测试用例 测试用例名称：测试用例名称：测试用例编号：测试用例编号：目的：目的：关键点：关键点：初始条件：初始条件：终止条件：终止条件：序号序号 操作步骤操作步骤 预期结果预期结果 1 2 3 4 备备注：注：HS/Z XXXXXX 17 C D 附 录 D（资料性附录）单元测试缺陷管理 D.1 缺陷管理表 缺陷管理表见表D.1。表D.1 缺陷管理表 缺缺陷陷IDID 缺缺陷陷描描述述 发发现现人人员员 解解决决人人员员 测测试试用用例例编编号号 问问题题发发现现版版本本 发发现现日日期期 缺缺陷陷状状态态 发发现现缺缺陷陷的的
27、活活动动类类型型 缺缺陷陷发发现现阶阶段段 缺缺陷陷引引入入阶阶段段 缺缺陷陷引引入入工工程程活活动动 解解决决日日期期 缺缺陷陷类类型型 严严重重程程度度 优优先先级级 计计划划完完成成版版本本 缺缺陷陷潜潜伏伏期期 -D.2 缺陷分析报告 D.2.1 缺陷数量统计 缺陷数量统计信息见表D.2。表D.2 缺陷数量统计 发现日期发现日期 识别缺陷数识别缺陷数 累计识别缺陷数累计识别缺陷数 总计总计 HS/Z XXXXXX 18 D.2.2 缺陷状态统计 缺陷状态统计信息见表D.3。表D.3 缺陷状态统计 缺陷状态缺陷状态 缺陷数量缺陷数量 占比占比 打开 修复 重新打开 拒绝 关闭 D.2.3 缺陷引入工程活动统计 缺陷引入工程活动信息见表D.4。表D.4 缺陷引入工程活动统计 缺陷引入工程活动缺陷引入工程活动 缺陷数量缺陷数量 占比占比 业务需求 软件需求 总体设计 详细设计 编码 集成编译 HS/Z XXXXXX 19 参 考 文 献 1 GB/T 15532-1995 计算机软件单元测试 2 科技应用项目管理办法 _