软件测试之单元测试:开发人员的测试

说到单元测试,几乎所有人都知道,由开发人员完成。可是为什么要进行单元测试呢?

开发人员写单元测试的时间几乎和他写产品代码的时间相当,因此,当做项目计划的时候,把单元测试考虑进去是合理的。尽管单元测试增加了相当大的开发工作量,看上去开发时间延长了,但实际上对于一个长期不断改进和维护的项目而言,我们不能忽视级联效应,要从项目整体来看。

单元测试可以保证最基本的缺陷尽早的发现并解决,因此,用来解决被流转到后期的测试阶段的缺陷时间实际上就会缩短。

而如果问开发人员是否进行了单元测试,他们通常也会说,是的,已经做了单元测试。如果问开发人员,他们的单元测试的步骤,答案很可能是:

  开发完代码之后,实际运行了程序,简单的做了些功能测试,没有问题
  通过断点调试进行了代码跟踪

不得不说,这么做是对的,也都具有一定的价值,但是并未关注到单元测试最核心的价值,那么,什么样的测试是有效的单元测试呢?

有效的单元测试需要编写简单的、自动化的测试代码,并且几乎是和开发代码同时完成的

开发人员做单元测试不仅必要,而且重要,每个开发人员都有责任对自己开发的代码进行单元测试。

那么,单元测试有哪些特点和作用呢?保证代码质量、更容易发现缺陷、可重复执行、代码更容易维护、解决缺陷的成本更低

为什么单元测试可以更容易发现缺陷

因为单元测试是在系统的最低级别进行测试,与别的方法或模块进行隔离了,因此单元测试的缺陷要比其他层面的缺陷更容易发现并解决。

进行单元测试最主要的原因之一就是解决缺陷的成本更低,因为单元测试中就解决缺陷是缺陷生成到解决最短的周期。

开发人员眼中的测试——把缺陷扼杀在摇篮里

1. 什么是单元测试?

单元测试是由开发人员在开发产品代码的同时进行的一种独立测试,验证其开发的每个代码单元。

2. 单元测试的目的是什么?

确保程序的逻辑和开发人员对它的预期是一致的。

3. 为什么单元测试应该由开发人员来执行?

对于程序的预期结果,开发人员自己比其他人都要清楚,因此编写有效的单元测试,开发人员本人是最合适的人选。

4. 什么时候进行单元测试呢?

单元测试和开发产品代码应该是同时进行,实际上,引入敏捷开发理论之后,更高的要求是测试驱动开发,即单元测试代码要在产品代码之前编写。

5. 单元测试的单元是什么?测试对象又如何理解?

从实用角度讲,单元通常是指类的成员方法,也可以是任何具有明确功能、规格定义、明确接口定义,且其规模一般比较小的程序代码模块的组合体。

6. 都说单元测试是独立的测试,那么什么是独立测试呢?

独立,是指将代码从原始程序中隔离出来,尽可能地与程序其他部分或者外界以来隔离,针对各个单元单独进行测试。

到这里,做个小的总结来把握单元测试的关键点:

  a. 单元测试记录预期的行为
  b. 每个单元测试针对一个单独的行为进行测试
  c. 尽可能地与程序其他部分或外界依赖隔离
  d. 一旦失败,可以清楚地定位失败的原因
  e. 可以重复运行,且每次运行都有确定的行为,不受上一次运行的影响
  f. 可以快速地执行(10秒左右),简单、实用、高效
  g. 有效的单元测试是自动化的

通过以上的介绍,可以对单元测试有了大概的了解,单元测试是什么,为什么要进行单元测试,但是,单元测试需要覆盖的内容有哪些呢?单元测试,作为白盒而进行的测试,测试包括主要的流程和出错的分支,以及边界条件,使用代码量来衡量测试的覆盖率。

1. 单元测试的测什么?

单元测试需要保证:覆盖到所有新开发的代码、修改过的代码以及存在的受影响的代码。

  a. 覆盖代码所有分支,包括正常路径和错误路径
  b. 覆盖所有有效的输入/输出情况
  c. 覆盖所有无效的或预期以外的输入/输出情况
  d. 覆盖所有的日志文件和返回代码
  e. 如果有出错恢复步骤,确保其正确性
  f. 验证代码的逻辑正确
  g. 在虚拟翻译的构建环境中通过测试
  h. 对敏感代码要测试其性能(可能需要描述代码路径及对数据库的访问)
  i. 单元测试需要在开发环境中完成
  j. 修改所有可翻译的代码片段,确保其正确

2. 单元测试的流程?

  设计文档--设计单元测试--创建/修改代码和相关文档--对新开发代码或者修改代码进行单元测试--代码审核--集成到代码存储库

3. 单元测试开始的标志?

当接收到一份新的设计文档或者一个缺陷后,就需要开始考虑单元测试了。

4. 单元测试结束的标志?

代码完成,解决了已知的问题或已提出解决遗留问题的下一步计划,且经过代码审核及执行通过单元测试后集成至代码存储库中。

5. 审核单元测试报告:

  手动的单元测试报告需要有详细的步骤,包括使用到的数据集
  自动化的单元测试报告不仅要有运行结果,还要给出描述,说明这一组单元测试所测的是哪一部分代码

接下来了解下测试驱动开发(TDD)

TDD每次针对一个很小的功能点,通常是小到一个单独的方法。

1. TDD流程:

  a. 在实现新功能之前,先考虑代码的使用需求(包括功能、过程、接口等),为其编写测试代码
  b. 让新写的测试代码和已有的测试代码一起运行
  c. 为新功能编写最少的实现代码
  d. 再次让新测试代码和已有的测试代码一起运行,根据运行结果修改实现代码,直到测试全部通过
  e. 在此过程中,积极地对待代码重构,使底层设计和实现更加优化,使接口更加简单
  f. 重复以上步骤

对TDD的总结:设计代码-->编写代码-->代码不可运行-->可运行-->重构

2. TDD的目的?

不是为了验证代码的实现,而是为了描述一段代码的用途和用法的设计规格说明,这种描述是无二义的,是可执行验证的。

3. TDD的优势在哪里?

  TDD要求测试优先,因此可以使得代码天生具有可测性,也因此保证了几乎100%的单元测试覆盖,代码中的缺陷密度低,有利于更早地发现缺陷,方便调试。
  TDD最大的好处,不是最终得到单元测试资产,也不是使单元测试全部通过,而是通过不断对代码进行重构,而最终从设计层面对代码做出改进。

4. TDD与敏捷开发的关系总结:

时间: 2024-11-06 07:35:13

软件测试之单元测试:开发人员的测试的相关文章

开发人员与测试人员的那些事

关于开发人员和测试人员的关系,人们阐述了很多,讨论了很多,争论了很多.而貌似一旦这两者坐在一起,对峙便开始了,两者间的争论多于相互认同.显然,这不利于实现两者合作的目标——向用户提供价值.(推荐学习零基础学习软件测试基础篇) 下面我们来分析一下其中的原因: 史前时期 在最开始,不存在测试人员, 只有开发人员.软件开发人员和软件项目的其他人员比起来并没有特别大的不同.从经济角度考虑,专门成立测试人员是行不通的:开发软件的时间如此昂贵,为测试人员分配时间显得很浪费. 没有专门人员检查工作,软件开发人

SWTBOK测试实践系列(2) --你会把开发人员提交测试的版本打回去吗?

开发人员奋斗了很多个夜晚,终于把版本提交测试了.他们可以松一口气了.但是噩耗很快传来,软件没有通过测试团队的预测试(为了保证测试进程,对开发人员提交的代码进行基本功能或业务流程的验证).开发经理老王,迅速找到负责预测试的测试经理老张. 老王说:老张啊,怎么回事?出什么问题了?我们好不容易开发完成了,你们怎么不测试还把版本打回来了? 老张说:你们提交的版本质量太差,没有我们的预测试,需要重新修改后,符合我们的要求,我们才能测试.你看看我们发现的这两个问题. 老王并没有看这两个问题,而是直接质疑老张

对于软件开发中开发人员与测试人员关系的理解

在软件开发中都会有开发人员(以下简称开发)和测试人员(以下简称测试),在一些小型公司可能并没有测试,仅仅是开发兼任测试.在这里我仅针对于有专业的测试和专业的开发的项目. 每个公司应该都有考核机制,对于开发和测试的考核实际上很难量化,通常来讲大的方向就是开发所负责模块的bug数,对于测试来讲就是测出来的bug数,但这真的有效吗?这也许对开发有约束力,理论上开发是能够自己控制bug数的,如果从产生的bug数来评判开发的绩效还算有效,这样开发自然就会把代码写得更加认真.但如果根据测试测出来的bug数来

学习软件测试之客户端(Client)测试

Client测试的特点 Client测试也叫做客户端测试,他是测试安装在用户机器上的应用程序的各个功能是否可以正常运行 需要先在本机安装Client程序包,然后通过运行Client程序,进行各种数据的输入,保存等操作. 测试内容包括:安装测试.卸载测试.用户界面测试.功能测试.字符输入测试.提示信息测试.超链接测试.操作按钮测试.菜单测试.视频音频测试.程序运行权限测试等. Client测试 安装测试: 包括进行首次安装.升级安装.完整的或自定义安装.以及异常的情况,如:磁盘空间不足.缺少目录创

《google的软件测试之道》读后感

这本书让人见识了一流互联网公司是如何做测试的,有很多感想但不知从何写起,也许太久没有写字,更别说读后感这种东西,简单罗列下让我印象深刻并且认为极为重要的几点: 1. 一个团队能写出高质量软件的唯一途径是全体成员共同对质量负责,包括产品经理.开发人员.测试人员等所有人. 对这个观点感触很深是因为,在我们实际的工作中,产品.开发与测试的工作是有部分脱节的,大家在各自领域都是专业的,而在共同保证产品质量这一终极目标上是有不足的,这三个角色都只关注自己的角色,而不是产品,没有精力也没有能力延伸到其他领域

Google软件测试之道 pdf下载

引领一代风骚的明星企业google, 推出过很多成功优秀的产品,搜索引擎不用说,譬如Gmail ,Chrome, Google Doc, G+等等等等,也推出过很多短命的产品,譬如Google Wave等等. 作为一个时常需要推出新产品,但又要根据用户反馈而做进一步选择继续还是放弃的企业,作为一个需要让产品稳定健壮以保持客户满意度的明星企业,该如何测试是一个很大的问题.Google的经验非常值得借鉴. 该书的作者是Google测试的Senior Director(如果我没记错的话),在测试领域有

如何有效地与开发人员一起工作(二)

现在什么问题变小了? 为什么我要这么麻烦呢?看起来我是想去巴结一些朋友.朋友是好的,但是公司不会为我的社交生活付钱.公司给我报酬是让我使用一部分权力来达到某些目的,一种减少问题的方法.什么问题? 一般而言,摩擦. 我遵照John Daly的原则,不断地问自己:“我做测试不是找bug是做什么?”摩擦会减缓进度.开发人员和测试人员的一些典型摩擦浪费的时间其实可以更好地用在找bug上. 我的这种方法还帮助解决其它的问题. 找Bug的成本高.找得太迟. 如果一个bug能尽早发现,总是会比等到开发人员已经

284.软件体系结构集成开发环境的作用

软件体系结构集成开发环境基于体系结构形式化描述从系统框架的角度关注软件开发.体系结构开发工具是体系结构研究和分析的工具,给软件系统提供了形式化和可视化的描述.它不但提供了图形用户界面.文本编辑器.图形编辑器等可视化工具,还集成了编译器.解析器.校验器.仿真器等工具:不但可以针对每个系统元素,还支持从较高的构件层次分析和设计系统,这样可以有效地支持构件重用.具体来说,软件体系结构集成开发环境的功能可以分为以下5类. 1.辅助体系结构建模 建立体系结构模型是体系结构集成开发环境最重要的功能之一.集成

如何有效地与开发人员一起工作(五)

测试人员则会对程序员的自我形象造成威胁,他们会打击程序员的那些特征.他们会展示给人们看到那些抽象概念没有用,细节没有被掌握好,或者是问题还没被解决.这一点也不奇怪,然后,程序员往往会把测试员的注意力从那些基础的概念转移出去,把它看成是对他们写的代码的系统的探索,寻找代码错误.代码错误不是什么大问题.一个对代码错误不重视的程序员可能会失去一些威望,但是仍然可能会被认为是优秀的.程序员可能从来不制造代码错误,但是创建笨拙的抽象概念. 现在,对于测试人员而言,寻找代码错误只是工作的一小部分.概念上的错