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

来看看一个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）正确吗？

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

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

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

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

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

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

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

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

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

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

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

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