今天看到了博客园的这篇文章:细节-质量-态度
摘一段如下:

来看看一个TextBox可能涉及到的测试项,下面所列出的测试项,在实际项目中数目还会有更多,有几条也可以合为一个
,但一般的项目都会涉及到:
1.      是否必输
2.      输入长度限制是否正确
3.      特殊输入类型的检查是否正确
   l         数字 :位数正确吗?
   l         Email:是否有效
   l         货币:小数位,四舍五入正确吗?货币类型?
   l         电话:格式化正确吗?
   l         小数:小数位数正确吗?
   l         名字:如果是老外的名字,首字母大写
4.      Tab键顺序正确吗?
5.      颜色表示正确吗?(有可能分为必输项,非必输项,当前输入项)
6.      文本框长度和数据库中长度对应吗?
7.      输入的长度不足时是否自动补位?
8.      初始化时焦点的设置正确吗?
9.      初始化时Enable属性设置正确吗?
10.  初始化时的内容正确吗?
11.  当界面上进行其他操作时,文本的Enable属性设置
12.  文本框命名
13.  如果有回车替换Tab,是否正确
14.  是否可以多行
15.  字体设置正确吗?
16.  Text属性时对空格的控制(Trim)正确吗?

但是大家可以算算这样一个界面,只有5TextBox,但是在TextBox处理上隐含了多少个bug50个?太多了,取一半,25个。
现在把添,删,查,改加上,再算算,这样一个简单的单表维护界面上就隐含了多少个
bug,保守点也30个!要达到50也不是没有可能的。
如果我们再加上一些其他的
CheckBoxComboBoxListBox什么的,编辑查看附件,发送什么的附加功能,测试点会膨胀到什么程度?

这个问题在数据库操作的企业应用软件中特别普遍。我们的软件在开始阶段出现的也大多是这类问题。如果有一个问题没有测试出来而在用户那里出现了,这时程序员会推卸责任,测试人员觉得冤枉,总之这种低级错误让人不爽。

问题在哪呢?是在于对细节的态度吗?

关于细节的重性,我们已经非常重视了。但人总有疏忽的时候,不能指望一个人总是不犯错。

问题在于没有一个良好的机制,一个注重细节检查的机制。让自动化的、预先检查的机制,来代替成本非常之高的人工检查。

一个很好的、行之有效的解决办法,就是“验证控件”。把原来程序员要单独的、一个一个去检查的控件,封装成一套完整的、带验证方法的控件,把保贵的程序员的精力解放出来。

比如,我们可以做字符串控件,有个最长值的属性;可以做数值控件,只能录入数值,这样程序员取得的值直接是数值而不用再手工转换;数值控件也有很多种,整数的,小数的等等;email控件、phone控件、日期控件等等。

做控件的时间是可控的、很少的;而在有繁杂界面的企业应用中,一套这样的控件可以节省的测试人工成本、避免出错的带来的经济损失是非常有用的,收益是永久的。一套控件可以用在其它的案例中,收益更是长久的。

我看到过的一些web framework,无不把控件的值校验功能放在核心层面,这样做也已经证明是非常成功的。哪些?Ruby on Rails!TurboGears!Java下的一些大的筐架。

.Net下面为什么没有?等着你自己来做呢。微软可没有这个经验。看了原文后面的评论,感觉还是有很多还没有意识这个问题的根本。还在争论什么面向对象编程、面向过程编程,希望多“想些实际问题,少谈些主义”。能解决问题的方法,就是好方法。

再补充一点:不能把所有的事情都丢给测试 人员。测试人员的时间、精力也一样是有限的,测试本身也不是万能的。如果软件质量不好,统统怪测试人员,那样一方面解决不了根本问题,程序员该犯的错还是会继续犯;一方面还会在公司内部造成测试与开发的对立,测试永远低开发一等,这样不利于良好的团队合作精神的养成。

我是项目经理,我一向的观点是,不能把保证软件质量的担子全部落到最后测试的身上。软件质量的责任是整个小组中每一个人都应该承担的,每一个环节都应该重视的。


评论

该日志第一篇评论

发表评论

评论也有版权!