走进单元测试:测试需要从哪些方面着手

前言

  笼统的来说测试条件无非就是两个方面:① 正向测试,② 反向测试!

  如果单从这两个方面来思考,肯定出现丢三落四的情况,也就是说不全面,所以应该在上面两种情况的基础上再进行具体划分,那么只要我们能够遵循这些条件基本上就能做到全面(如果能做到,大约80%的问题应该都解决了),于是就出现了下面要说的六个方面内容!

  前辈们把这些测试条件总结为:Right – BICEP

  1、Right - 做正确的事,可以说是“正向测试”

  这种测试前期任务是要准备足够的正确数据(前提是要保证数据的正确性,这个很重要),运行代码后返回的值或产生的影响是要跟自己的预期是一致的!

  注意:如果准备的数据太大或容易丢失,建议把它放在数据文件中,然后让单元测试读取这个文件,这种方法会在下一篇会说到!

  2、B - 边界条件(Boundary)

  边界条件是测试里面的重中之重,必须要有足够的认识和重视!

  而它又被分为七个方面的子条件,下面就让我们来一一熟悉它!

  ① 一致性(Conformance)

  数据是否符合我规定的格式(也可以说是非法字符吧)!

  案例:比如我传入的参数文件名需要的格式是:文件名 + 日期(yy-mm-dd) + 扩展名,那么我就要写一个测试传入的文件名为 :“sa#$#$#$#”这样的格式!

  ② 有序性(Ordering)

  这方面主要是对涉及到数组和集合的数据,而且对数据的顺序有严格要求的函数,需要对它们里面数据的顺序进行测试!

  比如:点菜系统菜谱中每道菜的顺序,或者去银行办理业务的排队系统等等!

  ③ 范围,区间性(Range)

  值是否存在于一个最大值和一个最小值之间,主要是对值类型的数据做的测试!

  这里面还有一个重要的测试点是 → 对数组,集合,以及Table,DataSet中的索引值进行测试,比如索引值不能为负,不能超出索引的范围等等情况!

  比如:一个通过ID来搜索信息的函数,应该对这个ID进行最大值和最小值的测试!

  ④ 引用,耦合性(Reference)

  这方面主要是:代码是否引用了一些不受本身代码控制的外部因素(比如:调用第三方接口,调用其它模块的接口等等)!

  对于这些情况我们是没有办法控制的,所以在测试的时候只能模拟,而在模拟时我们会用到“Mole”技术,让它来帮助我们创建一个模拟环境(下一篇会介绍)!

  比如:有的项目会调用银行接口,这种情况下只能先创造一个虚拟银行接口,然后再进行测试!

  ⑤ 存在性(Exist)

  固定的测试,如Null,Empty,非零等等,这些都是必须考虑的!

  ⑥ 基数性(Cardinality)

  对于这个测试说起来还是蛮难理解,这个测试只有在特定的场合下才会去考虑它!

  它遵循一个原则:“0-1-N”!

  ⑦ 时间性(Timer)

  对时间比较有依赖的软件或系统应该在这个方面着重测试!

  主要考虑:事情是否按时间的顺序执行,是否在正确的时间执行,是否出现执行事情延误了!

  相对时间:网站超时,数据更新超时等等!

  绝对时间:不同的client间的时间是否同步!

  并发问题在时间性测试中比较重要!

  3、I - 反向关联(Inversion)

  在准备数据或者验证数据时的一种反向思维,涉及到个人的思维方式问题了!

  比如:有个函数对数据库进行了操作,但是它没任何返回值也没有任何提示,如果你是对正确的数据进行了测试,那么你要怎么知道测试结果跟你的预期一致呢,这里你就应该去查找数据库,看数据库里面的数据是否有真的改动,这就是一种反向的思维方式!

  4、C - 交叉检查(Cross)

  用一种数量检查另一种数量(需要考虑的情况不是很多)!

  5、E - 强制产生错误(Error)

  通过代码强制产生软件在运行过程中出现的特殊情况!

  可以参考下面几种测试方面:内存耗光,磁盘用满,断电,正在执行更新数据时出现断网现象,网络负载严重导致瘫痪,系统时间出现导致和国际时间不一致等等一些情况!

  6、P - 性能特性(Property)

  性能测试工具的使用,没具体研究过性能测试工具,知道的朋友可以说下你们的经验!

  进行压力测试,一点一点的加大数据量,10000条,100000条,1000000条这样进行压力测试!

  总结:本人对反向关联和交叉检查这两个测试条件不是很理解,知道的朋友可以留言给我,我会把它补充到文章中去!

  最后:下面是我对测试条件的小小总结,比较简陋!

====================================分割线================================

最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-12-28 05:00:48

走进单元测试:测试需要从哪些方面着手的相关文章

单元测试培训系列:(一)单元测试概念以及必要性

说起单元测试,多数同学应该都知道或听过,可能不少同学认为自己也写过,甚至觉得单元测试很简单有什么好培训的?其实这个事情还真没想象的那么简单!我基本可以比较负责任的说,你若没深入对单元测试做过研究,不知道Mock对象为何物的话,那么可能你以前写过的单元测试压根就不是单元测试. 单元测试是什么? 这个问题其实并不太容易一两句话说得特别清楚.先借用下百度百科的定义: 单元测试是在软件开发过程中要进行的最低级别的测试活动,在单元测试活动中,软件的独立单元将在与程序的其他部分相隔离的情况下进行测试. 从以

通向架构师的道路(第二十五天)SSH的单元测试与dbunit的整合

一.前言 在二十三天中我们介绍了使用maven来下载工程的依赖库文件,用ant来进行war包的建立.今天我们在这个基础上将使用junit+dbunit来进行带有单元测试报告的框架的架构. 目标: 每次打包之前自动进行单元测试并生成单元测试报告 生成要布署的打包文件即war包 单元测试的代码不能够被打在正式的要布署的war包内,单元测试仅用于unit test用 使用模拟数据对dao层进行测试,使得dao方法的测试结果可被预料 二.Junit+Ant生成的单元测试报告 上面是一份junit生成的测

测试佳话—人人都是测试大牛

何为测试?测试就是检测,审查一个事务是否符合既定的标准.测试就像是空气和影子,如此亲密无间.曾听闻有人说"人人都是产品经理".这话有些过了.今日我说--人人都是测试大牛,这却是实实在在. 不止以下场景你是否熟悉? 1)菜的时候看看蔬菜新鲜否? 2)找钱时候看看真假. 3)买衣服时看看款式默默料子. 4)甚至打英雄联盟时,记得插眼看看情况. 如此之类不胜枚举,其实测试天赋是天生的,只要人有欲有求,就有测试,只有有原则,有所谓的世界观,价值观,就有测试,因为你为人处事,不也拿实际情况和内心

在Python中进行自动化单元测试的教程_python

一.软件测试 大型软件系统的开发是一个很复杂的过程,其中因为人的因素而所产生的错误非常多,因此软件在开发过程必须要有相应的质量保证活动,而软件测试则是保证质量的关键措施.正像软件熵(software entropy)所描述的那样:一个程序从设计很好的状态开始,随着新的功能不断地加入,程序逐渐地失去了原有的结构,最终变成了一团乱麻(其实最初的"很好的状态"得加个问号).测试的目的说起来其实很简单也极具吸引力,那就是写出高质量的软件并解决软件熵这一问题. 可惜的是,软件开发人员很少能在编码

《精通移动App测试实战:技术、工具和案例》一2.2 JUnit在Android开发中的应用

2.2 JUnit在Android开发中的应用 2.2.1 单元测试的重要性 前面我们提到了单元测试,那么什么叫单元测试呢?单元测试(Unit Testing),是指对软件中的最小可测试单元进行的检查和验证.对于单元测试中单元的含义,一般来说,要根据实际情况去判定其具体含义,如在Java中单元指一个类,在C语言里单元指一个函数等.单元测试是在软件开发过程中要进行的最低级别的测试活动,软件的独立单元将在与程序的其他部分相隔离的情况下进行测试.通常,我们在编写大型应用系统的时候,都要写成千上万个方法

jQuery性能优化的38个建议

 想必大家对于jQuery这个最流行的javascript类库都不陌生,而且只要是前端开发人员肯定或多或少的使用或者接触过,在这篇文章中,参考了一些资料及实际使用效率,将介绍一些书写高质量jQuery代码的原则,不单单会告诉你如何去书写,也会告诉你为什么这样书写,希望大家会觉得有所帮助 一.注意定义jQuery变量的时候添加var关键字 这个不仅仅是jQuery,所有javascript开发过程中,都需要注意,请一定不要定义成如下: $loading = $('#loading'); //这个是

新技术、新观念与商业应用的开发——也谈AJAX和NUnit

ajax      最近比较忙,起初是对以前开发的一个C/S模式的系统进行升级,比较痛苦而且出了不少问题,好在系统连同另外两个子系统一块顺利发布,经过几天的调整总算可以全力投入到B/S这边来,说来惭愧的不行,一个不大的系统应用拖了这么久(找点客观理由:其实一直很乱,根本没时间静下来琢磨它),本来以为可以潜心的好好做好,但是经理又提出硬性要求--下周四必须拿出演示版来,至少要保证业务顺畅,我觉得这样的要求根本不是什么,我想的是要把它做得更人性化一些,毕竟这是公司首个大规模的web应用,准备引入一些

不做代码审查又怎样?

从一次回顾会议开始 "要不--我们不做--代码审查了--试试?"还记得当有人抛出这个建议时周围同学的表情,那种表情用两个字加两个标点符号就可以形容:"什么?!" 对了,先介绍一下背景,这是项目一次普通的回顾会议,我们正在讨论的是如何让代码审查更有效率和效果.我们做代码审查的方式比较简单直接,就是每日站会后,大家围在一台开发机周围,逐一轮换讲解昨天所有提交的内容,就像下图中的那样.还有,这是一个已经超过了7年的比较大型的项目,代码审查是我们从项目开始就坚持的一个实践,

JavaScript代码风格要素

1920年,由威廉·斯特伦克(William Strunk jr .)撰写的<英语写作手册:风格的要素(The Elements of Style)>出版了,这本书列举了7条英文写作的准则,过了一个世纪,这些准则并没有过时.对于工程师来说,你可以在自己的编码风格中应用类似的建议来指导日常的编码,提高自己的编码水平. 需要注意的是,这些准则不是一成不变的法则.如果违背它们,能够让代码可读性更高,那么便没有问题,但请特别小心并时刻反思.这些准绳是经受住了时间考验的,有充分的理由说明:它们通常是正确