什么是测试

什么是测试?
[ 2005-12-29 21:13:31 | Author:ccBoy ]
Font Size:Large |Medium |Small
这是上次SQL Server 2005 广州发布会时，我们吃饭的时候讨论起测试的话题。
当时刘老师(刘劲浩)说，你们说说，什么是测试？
有人说，测试是个流程，当软件要发布了就需要测试部门的确认；也有人说测试就是找Bug；也有人测试是为了验证需求，也有说测试是为了保证产品质量。
刘老师说，现在的软件产品的开发中，测试成为衡量你产品质量和进度的一把尺子。具体的说，你的软件产品在不断开发的各个过程，你就需要有一种度量的水平随时可以知道你产品的质量和进度。某天某日，你的老板问你产品，开发得如何了，你要能够随时拿出这把尺子进行丈量和报告。行或不行不是随便说的，而是靠数据，靠你身边实践的这个模型。
之后，他给我们讲了之前他看到的一篇文章，他说有空的时候，他一定要写出了，他说这个故事和现代的软件开发非常有雷同的地方。不知道他之后有没有写，不过我按照当天的记忆和当时感受，把这些描述出来吧。
故事的概括是这样的，说二次大战前，德国秘密研制的一种潜水艇，聚集了当时顶尖的科学家，耗资巨大，而且整整研制了4年，当研制出来后，在第一次试水的时候，因为有4级的小台风，所以船下水后，因为重心不稳，从而翻倒，然后就沉没了。事后人们对这个船的遗骸和整个的开发过程作了分析和反思，发现这个船的生产过程和现在的研发过程，非常的相似。
比如，第一重心不稳的问题。说原来这艘船是按两层炮楼的结构设计的，但是因为开发时间太长，两年之后三层炮楼变得比较流行，所以统帅就询问开发人员和设计人员，能否改成三层炮楼，设计师看了图纸，说设计时多留了位置进行扩展，三层炮楼是支持的。看统帅这么说，大家也一致认为三层没有问题。结果日后一试航，船就翻了。这和现在的软件开发也非常的相似，当我们仓促的加入一个新的需求的时候，你根本没有办法衡量整个系统的承重能力和状态。普通或新产品的开发还好办，麻烦在于像Windows、Office、SQL这样的产品，当你加入一个产品功能或修改了某处，你很难知道影响了什么东西，整个产品的质量会到什么水平。这时候，你就需要有一把尺子随时的可以测量一下。
他说，在SQL Server 2005的开发中，他们就有这样的尺子--98% 。一个数值，他说，整个的开发中有两次系统的表现低于这个指标，他说一次，是整个的开发组都叫停了下来，大家一起检讨出了什么问题，什么是需要解决的，不然这就像这船的结果一样了，大家辛辛苦苦的开发，但最后产品可能已经出现了重大问题。最后大家停下来找到问题，重新修正了设计修复了Bug，指标又恢复上去了，然后开发继续向前。还有一次，是大家讨论之后，针对这个问题/bug 和目前的进度以及各项情况比较下来，认为这个指标低是暂时的，而且目前它的优先级并不高，所以测试的负责人最后做了决定，保留这个Bug，让进度继续向前。大约4周后，Bug被修复，指标又上去了。
他说，未来的软件开发一定要是动态的和非线性的发展，但是在这个动态和非线性的过程中，测试要能制造出这根尺子，有这个模型来动态的评估你的系统和产品的质量。如果没有，他说，那就会这个船一样。所以你说，如果测试是找bug，那么大家很容易去追求这个Bug的数量，而忽视质量；同样你也不能只验证功能，就像这造潜艇的，所有的零件质量都是合格的，但是最后它一样会翻船，质量好只能是说船翻了，残骸还挺牢固的。
至于这98% ，内行都知道，这时产品测试规划中，通过各种模型、指标、约束条件、客户环境、市场因素、软硬件环境、需求复杂度和技术水平综合考虑，拟定的一个指标，你的产品测试达到这个指标，那么所约定的所有指标和环境下，这个产品都应该是测试计划和规划中描述的一个表现和质量水平。
刘老师说，他们楼里面，有三层楼分别有三个不同的大的测试系统，从不同的角度和模型来测试和考量产品的质量。
他说完后，我心中有了动态系统，动态尺子的概念，在整个产品开发的生命周期中，你是否有一把动态的尺子衡量你的产品质量和进度。我想，做到这个很难。但心里感觉这是一个挺新的概念。
他又说，第二个问题。还是重心的问题。潜艇的研发过程中，为什么不能测试发现这个问题？ 他说，资料上说是两个原因，第一原因是当时的条件下，对于这种潜艇的架构和动力理论下面，很难进行模拟，而且根本没有办法进行测试。只有在潜艇完成80%的时候，他们动用了几千人，通过人的模拟来测试重心系统，而且非常简单，让这几千人从船头跑到船尾。资料上说，这次测试的结果并不十分理想，但是潜艇已经完成了80%，到了项目的后期，统帅在等待这个潜艇的完工下水，所以这时候，没有人敢提这个问题，大家只能这么做下去了。
他说，这就是我们测试经常讨论的第二问题，怎么测试的问题？传统中，测试似乎都是测试组的事情，开发组完成开发就可以了。但是这个例子说明，测试是设计的事情，产品设计要可测，你不能设计完了就完了。现在所有的PM完成你的Spec，在Review之前你一定要准备好两点，第一，你设计的东西怎么测试，你要告诉别人你的设计怎样来测试。第二，你设计的东西是否安全，为什么这样设计是安全的？
他说，SQL Server中有一个核心的模块，代码量很少，但是太底层了，所以很难测试，但是因为设计的时候就要求达到可测试性，所以这个模块的开发人员有两个月就在为测试写代码，写了许多供测试组调用的函数和接口，测试的设计工程师再通过这个函数和接口编写自己的测试程序。而且这些代码再产品发布的时候都没有被编译进去，但是这个函数集和代码量非常的大。他说这个和潜艇动力系统的重心测试一样，如果你设计的产品没法测试或者别人不知道怎样测试，那么你的设计就有问题。而且越晚测试，问题就可能越大，到最后即使发现问题，产品明天要发布，你怎么办？
然后聊到请这些测试人员要花很多钱，为什么不用现成的测试工具？刘老师说，这个没有办法，这也是产品开发投资的一部分，他说，最好的测试工具不在VSTS中，而在产品组中，在产品组的内部。海洋和老周顿时语塞他说，一般内部测试30%的是手工测试，70%的是自动测试，他说高一点的要求85%都是自动测试，如果你靠购买的现成的测试工具，那风险太大了，况且这些工具不能覆盖整个的产品开发周期，也就很难产生一把动态的"尺子"。他说，他不知中国的公司怎样，即使在美国，也很少有公司像微软这样，会请这么多的人进行测试。一想到85%的自动测试、1比2的测试人数，我想，中国大多数公司也会害怕了。不过我认为，测试永无止境，99%容易达到，往往再提高1% 可能需要花费你现在所有的花费再加上200%的力气才可能达到，这个依照不同的环境、客户、公司而不同。
不过聊完成之后，感到前面潜艇的故事还是非常有收获。如果不是下午他还有课程要讲，我想，还会收获更多。
好了，这是我参加广州的SQL Server 2005/ Visual Studio 2005 最后也是最大的收获，和你一起分享。并在最后衷心地谢谢刘老师
_xyz