你的代码完成了吗?(之三)——可测试性和健壮性

发表于:2011-10-18 11:18

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:侯伯薇    来源:51Testing软件测试网采编

分享:

  三、可测试性和健壮性

  首先想说说可测试性,而这其中先要交代的就是测试的方法。

  大家都知道,在一个系统的开发过程中,有很多测试环节,而这些测试环节与设计与开发环节又都是相互对应的,大概是这样:

  单体测试----->详细设计
  结合测试----->概要设计
  业务测试----->需求分析

  但是,在不同的开发环境中,所采用的测试方法也都是不一样的。

  通常我们都会使用人工的测试方法,尤其是对于界面上的一些元素针对特定操作的反应,只有真正能够得出想要的结果,那样才能够算是做好了这个功能。

  但即使是人工的测试,详细的程度也会有所不同:在对日项目中,因为会有人针对详细设计编写详细的单体测试设计书,然后会有测试人员按照这份文档,对界面上的每个功能都做详细的检查,看所提供的功能是否复合设计书上的要求。而对于整合测试,同样会有类似的文档以及更高一级的测试人员来完成相应的工作。并且,日本使用计算机的程度普遍比较高,到了用户那里,同样会测试出一些问题。经过详细的三个步骤,加上厚厚的文档,最终交付使用的产品一般质量会比较高。

  而对于国内的项目,很多时间抽不出那么多人来做那么多的流程,所以一般测试都比较简略,而很多开发人员对于应该怎样测试自己的程序也不甚了解,只测试最理想的情况,很多的边界情况和特殊情况都考虑的不够。再加上整合测试做的不够,一般交给用户测试的时候,会有比较多的问题。

  在这里,有人可能会说,我们做国内项目的并不是不想测试,也不是不会测试,而是时间紧、任务重,要么要质量、要么要进度,二者权衡取其重,所以我们就用质量来换速度。客户明天就要了,我今天才做好,哪有时间测试啊。

  但是,我还是觉得那样做,其实是在饮鸩止渴,项目之所会砸掉,很多都是因为用质量换进度造成的。

  上面有些扯远了,其实我在这里想要说的可测试性针对的是另一种测试方法,也就是利用xUnit工具进行的自动化单元测试

  关于此最经典的东西可能就是那本《测试驱动开发》了,每次拜读的时候都会受益匪浅。

  然而,在很多情况下,想要达到那样的目标都比较困难,因为那需要编写很多测试代码,而那些代码对于程序本身,或者更清楚一些,针对用户是毫无意义的,只是用来保证我们确实实现了所需要的功能。而且,开发人员编写程序代码的时间都比较紧张,怎么会有时间再去编写一份测试代码呢?

  我也是一样,似乎到现在真正编写过的自动化测试代码也不超过20个,只有在觉得时间比较充裕,而且感觉到测试的步骤很多,必须需要自动化测试来帮忙的时候才会那样做。

  其实,测试代码与其说是给自己编写的,不如说是给别人编写的,给整个项目组编写的。

  我们经常会遇到这种情况,修改一个程序,改好了之后,自己测试了没问题,但是发布了之后,发现其实有一种情况没有考虑到,或者说原有的程序中有一些特殊的处理我们不知道,结果就会导致在某些情况下程序崩溃。

  如果有自动化测试代码,特别是自动化的整合测试代码,就可以在某种程度上改善这种情况,每次在修改之后,只修改相关的测试代码,而不变原有的,那样执行一下,闪闪发光的小绿条和小红条就会告诉我们的修改是否合理了。

  因此说,如果说自己的代码在可测试性方面完成的话,那就必须有相对应、比较完善的自动化单体测试代码,并且测试的代码覆盖率达到了一定的程序,比方说80%以上。

  接下来,我想说的是什么样的程序是健壮的,看我的程序的抗击打性如何,哈哈。

  曾经在做对日项目的时候,有这么一种说法(大家一定觉得奇怪我怎么总是提对日开发,希望大家不要对一件事物全盘肯定和否定,其实对日、对国内、对欧美三种开发模式都各有各的优点,也各有各的缺点),那就是叫做“猴子测试”!

  猴子怎么会测试呢?当然不会,他们所说的是,像猴子一样测试,因为猴子什么都不知道,它只会在键盘上一顿乱敲,在鼠标上一顿乱按,是吧,哈哈。

  而猴子测试方法就是这样,拿过一个程序,打开界面,然后乱弄一顿,看看程序报错了没?如果程序崩溃了,那就意味着你的程序的健壮性不够啊,被猴子给搞定了,哈哈。

  解决这个问题可不是那么容易的,首先必须要对所有的输入进行比较完善的验证,比方说字段的长度、是否是数字、数字的范围、是否子日期类型、日期的范围、成对日期之间的比较等等,一切都需要校验。此外还有对数据库方面的校验,比方说是否有重复的主键,是否有不可为空的输入,是否超出了数据库所定义的范围等等。另外还有对业务的校验,这个就需要针对具体的情况了。如果没有校验的话,就麻烦了,一方面这些非法的输入到程序中处理就会出错,或者存放到数据库中的时候会出问题。而缺少对业务上的校验,可能产生的数据非常不合理,闹了笑话。总之,我们首先要做的就是校验!校验!校验!

  除了验证之外,就是对异常情况的处理,那不是错误,而是一种我们预料之中的一种特殊情况,可能不符合一些标准,而这里正是考验一个程序员的经验是否丰富的地方了。知己知彼、百战不殆,如果你能够知道程序在什么情况下可能会出错,并在相应的地方设置好“陷阱”给它,那么你就是战无不胜的大将军了,哈哈。

  而这两种操作,对于Winform形式和Web形式的应用,或者说针对C/S和B/S的程序,总体的思想是一样的,而细节上的处理又会有不少的不同,这些也只能具体情况具体分析了。

  原文出处:http://www.cnblogs.com/houbowei/archive/2010/03/24/1693425.html

相关链接:

你的代码完成了吗?(之一)——可用性和易用性

你的代码完成了吗?(之二)——可维护性和规范性

《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号