• 3
  • 1
分享

  摘要:单元测试(unit testing)是人为规定的最小的被测功能模块,单元测试的质量会直接影响到软件的后期测试,最终在很大程度上影响到产品的质量。测试过程中应该从可自动化,可重复独立的执行。

  单元测试可以说是软件测试的基础单元,单元测试的质量会直接影响到软件的后期测试,最终在很大程度上影响到产品的质量。

  测试成本:在单元测试阶段,某些问题是很容易发现的,如果忽略了单元测试,在后期的测试中所花的成本将成倍的上升。图表摘自<<实用软件度量>>(Capers Jones,McGraw-Hill 1991),这些数据显示单元测试的成本效率大约是集成测试的两倍 系统测试的三倍(参见条形图)。

  单元测试是直接对最小的模块进行测试的,我们都知道盖房子地基是很重要的,而单元测试是所用测试的基础,将单元测试做好,在做集成测试和系统测试将会变的容易很多。

  既然说单元测试如此的重要,那么该如何确保单元测试的质量呢?下面就从几方面进行讲述。

  1、自动化

  单元测试需要能够自动化的执行。应该包含执行测试自动化和检查结果自动化。

  对于单元测试人员,你做的事情将是成天或者日复一日的去执行你所写的单元测试,你要确保你的单元测试是易于调用的。因此要运行单元测试不能比按下按钮或者提示符输入一行的命令来的更复杂。可以将单元测试设置成后台持续的运行,可以用脚本去驱动它运行等等。

  对于这个自动化,需要注意的是任何时候不要引入需要手动去执行的步骤而破坏这个自动化的测试过程。比如说数据库,按钮等,当遇到这些时需要让这些也成为自动化组成的一部分。

  另一方面,要让测试自己是判断pass or fail。如果说测试专门找出一个人去读取测试的输出,在去验证这个用例是否通过,这是我们不希望看到的,浪费了资源不说,对结果判断的准确度也带提高,而且对于后期的回归测试带来很大的不便。所以说自动的检查结果是必不可少的一个环节。

  2、可重复

  对于测试,应该能够随机的执行每一个测试,且其产生的结果都应该保持一致。这就要求你的测试系统不依赖任何的外部因素,独立于周围的环境。

  在必要的时候,在测试中可以引入桩函数,将测试的外界因素隔离,使测试能够独立于开发环境。比如说系统的时间,在测试的不同时刻获取到的时间是不一样的,这是我们不愿意看到的,这时你可以写个函数代替这个系统的时间。如果说你一定要用到一些外界的因素,比如说数据库,这时你该确保数据库不会受到开发环境的影响,是完全由你控制的。

  如果测试结果不具备重复性,你可能对你的测试结果感到惊讶,结果可能是一个随机的值。这时候你无法判断它是不是一个真正的bug,而只是测试本身的问题,这时候会花费大量的时间去追溯测试自身的问题。所以应当确保测试每次执行都有相同的结果。

  3、独立的

  对于单元测试要举要针对性的,并且独立于环境同时与其他测试独立开来。

  在编写单元测试的过程中应该确保一次只测试一个东西,一个测试函数应该专注于产品代码的一个函数、一个类或者合起来实现某一特性/功能的一组函数。

  一个测试函数有可能只测试了一个复杂函数中的一小部分,你可能需要多个测试用例才能测低的验证该函数,当一个测试失败时,你可以定位到bug的位置。

  独立的还意味着不依赖于任何的其他测试,测试可以在任何时刻运行任何一个测试,而不会因为某一个测试的失败而影响到后面的测试。

  综上所述,单元测试是构筑产品质量的基石,我们不要因为节约单元测试的时间不做单元测试或随便做而让我们在后期浪费太多的不值得的时间,我们也不愿意因为由于节约那些时间导致开发出来的整个产品失败或重来!


作者:甘彩凤   

来源:51Testing软件测试网原创

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          •   响应时间  响应时间是指某个请求或操作从发出到接收到反馈所消耗的时间,包括应用服务器(客户端)处理时间、网络传输时间以及数据库服务器处理时间。比如一个页面从点击/输入到完全加载的时间;完成一次增加、删除、修改或者查询动作的事务响应时间等。  一个请求在网络上的传输往往要经历多个网络节点才能到达目标服务器,我们假设请求经历了三个网络节点的传输时间B1、B2、B3,客户端的处理时间为A,服务器的响应时间为C。则一次请求的完整路径可以描述为下图:  客户端从发出请求到接收到服务器反馈的完整链路时间为A—>B1—>B2—>B3—>C(节点处理时间都包括接收和发送两个过程)。...
            0 0 558
            分享
          • 1、软件文档一般分为三类:开发文档、产品文档、管理文档1)开发文档描述开发过程本身,基本的开发文档包括:(1)可行性研究报告和项目任务书(2)需求规格说明书(3)功能规格说明书(4)设计规格说明书,包括程序和数据规格说明书(5)开发计划(6)软件集成和测试计划(7)质量保证计划(8)安全和测试信息2)产品文档描述开发过程的产物,基本的产品文档包括:(1)培训手册(2)参考手册和用户指南(3)软件支持手册(4)产品手册和信息广告3)管理文档记录项目信息管理的信息,例如:(1)开发过程的每个阶段的进度和进度变更的记录(2)软件变更情况记录(3)开发团队职责定义(4)项目计划、项目阶段报告(5)配置...
            13 14 1278
            分享
          • IT之家 10 月 7 日消息,据充电头网消息,苹果 iPhone 14 原装 C-L 数据线的连接器从 C94 换为 C91M。据报道,新的 C91M 数据线的元件布局与老款 C94 相同,快充性能也无明显差别。充电头网称,苹果更换 C91M 连接器可能是出于防伪考虑。IT之家曾报道,不久前,欧洲议会以压倒性的票数支持在 2024 年底前强制将 USB-C 作为包括 iPhone 和 AirPods 在内的各种消费电子设备的通用充电端口。这可能意味着新的 C91M 数据线可能将是苹果最后一代的 Lightning 数据线。欧洲议会新法规规定,从 2024 年秋季开始,USB type-C 将...
            0 0 796
            分享
          • 我们都知道对于测试人员来说最重要的两个评审会议是需求评审和用例评审。需求评审需求会议评审的最根本有以下几个目的:第一,评审需求中产品设计的功能中有问题的地方,和没有量化的地方,比如功能设计的字段的类型和限制长度,规则等等。第二,评审需求中有问题的地方我们肯定都要推动产品进行修改最终达成一致。第三,我强调为什么要量化,只有量化之后,测试才能后期的用例编写,开发才能进行一些程序设计包括数据库设计。什么是量化?我举个简单的例子:比如某软件登录是手机号登录,产品设计的文档中写的是输入规范的手机号。这句话就是有问题的,没办法量化,什么是规范的手机号?如果说手机号为首位为1,11位数字,这样的需求才是没问...
            0 0 2012
            分享
          • 一、找不到元素可能出现的原因:1、元素表达式错误;2、不在指定的frame;3、等待时间短,页面加载速度慢;4、执行脚本打开了新的页面,不在指定的窗口中。二、优化web自动化测试效率避免使用强制等待,会浪费等待的时间三、PO模式的理解1、PO模式实现代码的复用性;2、提高了代码的可维护性、可读性;将业务逻辑和测试逻辑相分离;当页面发生变化的时候,测试逻辑不需要发生改变,只需要改动业务逻辑;当测试逻辑发生变化的时候,业务逻辑不需要变化,只需要改动测试逻辑。3、页面方法一般是返回的是self或者其他页面;4、assert 断言不要写在页面当中;5、如果可能有多种情况的返回值,封装多个方法(行为)。...
            0 1 5829
            分享
      • 51testing软件测试圈微信