详细讲解单元测试的内容

单元测试由一组独立的测试构成,每个测试针对软件中的一个单独的程序单元。单元测试并非检查程序单元之间是否能够合作良好,而是检查单个程序单元行为是否正确。

在单元测试时,测试人员根据详细设计说明书和源程序清单,了解到该模块的I/O条件和模块的逻辑结构,主要采用白盒测试的测试用例,辅之以黑盒测试的测试用例,使之对任何合理和不合理的输入都要能鉴别和响应。这就要求对程序所有的局部和全局的数据结构、外部接口和程序代码的关键部分进行桌面检查和代码审查。

在单元测试中进行的测试工作主要在5个方面对被测模块进行检查:

1. 模块接口测试

在单元测试开始时,应该对通过所有被测模块的数据流进行测试。如果数据不能正常地输入及输出,那么其他的全部测试都说明不了问题。Myers在关于软件测试的书中为接口测试提出了一个检查表:

  • 模块输入参数的数目是否与模块形式参数数目相同。
  • 模块各输入的参数属性与对应的形参属性是否一致。
  • 模块各输入的参数类型与对应的形参类型是否一致。
  • 传到被调用模块的实参的数目是否与被调用模块形参的数目相同。
  • 传到被调用模块的实参的属性是否与被调用模块形参的属性相同。
  • 传到被调用模块的实参的类型是否与被调用模块形参的类型相同。
  • 引用内部函数时,实参的次序和数目是否正确。
  • 是否引用了与当前入口无关的参数。
  • 用于输入的变量有没有改变。
  • 在经过不同模块时,全局变量的定义是否一致。
  • 限制条件是否以形参的形式传递。
  • 使用外部资源时,是否检查可用性并及时释放资源,如内存、文件、硬盘、端口等。

当模块通过外部设备进行输入/输出操作时,必须扩展接口测试,附加如下的测试项目:

  • 文件的属性是否正确。
  • Open与Close语句是否正确。
  • 规定的格式是否与I/O语句相符。
  • 缓冲区的大小与记录的大小是否相配合。
  • 在使用文件前,文件是否打开。
  • 文件结束的条件是否安排好了。
  • I/O错误是否检查并做了处理。
  • 在输出信息中是否有文字错误。

2. 局部数据结构测试

模块的局部数据结构是最常见的错误来源,应设计测试用例以检查以下各种错误:

  • 不正确或不一致的数据类型说明。
  • 使用尚未赋值或尚未初始化的变量。
  • 错误的初始值或错误的默认值。
  • 变量名拼写错或书写错—— 使用了外部变量或函数。
  • 不一致的数据类型。
  • 全局数据对模块的影响。
  • 数组越界。
  • 非法指针。

3. 路径测试

检查由于计算错误、判定错误、控制流错误导致的程序错误。由于在测试时不可能做到穷举测试,所以在单元测试时要根据“白盒”测试和“黑盒”测试用例设计方法设计测试用例,对模块中重要的执行路径进行测试。重要的执行路径指那些处在完成单元功能的算法、控制、数据处理等重要位置的执行路径,也指由于控制较复杂而易错的路径,有选择地对执行路径进行测试是一项重要的任务。应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误,对基本执行路径和循环进行测试可发现大量的路径错误。

在路径测试中,要检查的错误有:死代码,错误的计算优先级,算法错误,混用不同类的操作,初始化不正确,精度错误—— 比较运算错误、赋值错误,表达式的不正确符号—— >、>=;=、==、!=,循环变量的使用错误—— 错误赋值以及其他错误等。

比较操作和控制流向紧密相关,测试用例设计需要注意发现比较操作的错误:

  • 不同数据类型的比较。
  • 不正确的逻辑运算符或优先次序。
  • 因浮点运算精度问题而造成的两值比较不等。
  • 关系表达式中不正确的变量和比较符。
  • “差 1 错”,即不正常的或不存在的循环中的条件。
  • 当遇到发散的循环时无法跳出循环。
  • 当遇到发散的迭代时不能终止循环。
  • 错误的修改循环变量。

4. 错误处理测试

错误处理路径是可能引发错误处理的路径及进行错误处理的路径,错误出现时错误处理程序重新安排执行路线,或通知用户处理,或干脆停止执行使程序进入一种安全等待状态。测试人员应意识到,每一行程序代码都可能执行到,不能自己认为错误发生的概率很小而不去进行测试。一般软件错误处理测试应考虑下面几种可能的错误:

  • 出错的描述是否难以理解,是否能够对错误定位。
  • 显示的错误与实际的错误是否相符;
  • 对错误条件的处理正确与否;
  • 在对错误进行处理之前,错误条件是否已经引起系统的干预等。

在进行错误处理测试时,要检查如下内容:

  • 在资源使用前后或其他模块使用前后,程序是否进行错误出现检查。
  • 出现错误后,是否可以进行错误处理,如引发错误、通知用户、进行记录。
  • 在系统干预前,错误处理是否有效,报告和记录的错误是否真实详细。

5. 边界测试

边界测试是单元测试中最后的任务。软件常常在边界上出错,例如,在一个程序段中有一个n次循环,当到达第n次循环时就可能会出错;或者在一个有n个元素的数组中,第n个元素时是很容易出错的。因此,要特别注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例,认真加以测试。

此外,如果对模块性能有要求的话,还要专门进行关键路径测试,以确定最坏情况下和平均意义下影响运行时间的因素。下面是边界测试的具体要检查的内容:

  • 普通合法数据是否正确处理。
  • 普通非法数据是否正确处理。
  • 边界内最接近边界的(合法)数据是否正确处理。
  • 边界外最接近边界的(非法)数据是否正确处理等。
  • 在n次循环的第0次、第1次、第n次是否有错误。
  • 运算或判断中取最大最小值时是否有错误;
  • 数据流、控制流中刚好等于、大于、小于确定的比较值时是否出现错误。

为了使单元测试能充分细致地展开,应在实施单元测试中遵守下述要求:

1)语句覆盖达到100%。

语句覆盖指被测单元中每条可执行语句都被测试用例所覆盖。语句覆盖是强度最低的覆盖要求,要考虑语句覆盖的意义,只要想象一下用一段从没执行过的程序控制庞大的飞行器升上天空,然后设法使它精确入轨,这种轻率简直就是荒唐。实际测试中,不一定能做到每条语句都执行到。第一,存在“死码”,即由于程序设计错误在任何情况下都不可能执行到的代码。第二,不是“死码”,但是由于要求的测试输入及条件非常难达到或单元测试的条件所限,使得代码没有得到运行。因此,在可执行语句未得到执行时,要深入程序作详细的分析。如果是属于以上两种情况,则可以认为完成了覆盖,但是对于后者,如果可能一定要尽量测试到,如果以上两者都不是,则是因为测试用例设计不充分,需要再设计测试用例。

2)分支覆盖达到100%。

分支覆盖指分支语句取真值和取假值各一次,分支语句是程序控制流的重要处理语句,在不同流向上测试可以验证这些控制流向的正确性。分支覆盖使这些分支产生的输出都得到验证,提高测试的充分性。

3)覆盖错误处理路径。

4)单元的软件特性覆盖。

软件的特性包括功能、性能、属性、设计约束、状态数目、分支的行数等。

5)对试用额定数据值、奇异数据值和边界值的计算进行检验,用假想的数据类型和数据值运行,测试排斥不规则输入的能力。

单元测试通常是由编写程序的人自己完成的,但是项目负责人应当关心测试的结果。所有的测试用例和测试结果都是模块开发的重要资料,需妥善保存。

【编辑推荐】

  1. 软件测试理论:目的、周期、流程
  2. 详谈软件测试中的动态测试
  3. 浅谈软件测试嵌入式单元测试技能
  4. 软件测试中排错的基本方法
  5. 软件测试接口测试的测试用例类型

分享文章:详细讲解单元测试的内容
URL分享:http://www.shufengxianlan.com/qtweb/news7/335107.html

网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联