师兄很愤愤不平的说：“我的笔试成绩那么高，竟然还把我分到测试那边了，我想做开发啊……” 嗯，啥是测试啊？ 百度百度~~
转载一 ： 这是上次SQL Server 2005广州发布会时，我们吃饭的时候讨论起测试的话题。 当时刘老师(刘劲浩)说，你们说说，什么是测试？ 有人说，测试是个流程，当软件要发布了就需要测试部门的确认；也有人说测试就是找Bug；也有人测试是为了验证需求，也有说测试是为了保证产品质量。 刘老师说，现在的软件产品的开发中，测试成为衡量你产品质量和进度的一把尺子。具体的说，你的软件产品在不断开发的各个过程，你就需要有一种度量的水平随时可以知道你产品的质量和进度。某天某日，你的老板问你产品，开发得如何了，你要能够随时拿出这把尺子进行丈量和报告。行或不行不是随便说的，而是靠数据，靠你身边实践的这个模型。之后，他给我们讲了之前他看到的一篇文章，他说有空的时候，他一定要写出来，他说这个故事和现代的软件开发由非常雷同的地方。不知道他之后有没有写，不过我按照当天的记忆和当时感受，把这些描述出来吧。 故事的概括是这样的，说二次大战前，德国秘密研制的一种潜水艇，聚集了当时{dj1}的科学家，耗资巨大，而且整整研制了4年，当研制出来后，在{dy}次试水的时候，因为有4级的小台风，所以船下水后，因为重心不稳，从而翻倒，然后就沉没了。事后人们对这个船的遗骸和整个的开发过程作了分析和反思，发现这个船的生产过程和现在的研发过程，非常的相似。 比如，{dy}重心不稳的问题。说原来这艘船是按两层炮楼的结构设计的，但是因为开发时间太长，两年之后三层炮楼变得比较流行，所以统帅就询问开发人员和设计人员，能否改成三层炮楼，设计师看了图纸，说设计时多留了位置进行扩展，三层炮楼是支持的。看统帅这么说，大家也一致认为三层没有问题。结果日后一试航，船就翻了。这和现在的软件开发也非常的相似，当我们仓促的加入一个新的需求的时候，你根本没有办法衡量整个系统的承重能力和状态。普通或新产品的开发还好办，麻烦在于像Windows、Office、SQL这样的产品，当你加入一个产品功能或修改了某处，你很难知道影响了什么东西，整个产品的质量会到什么水平。这时候，你就需要有一把尺子随时的可以测量一下。 他说，在SQL Server 2005的开发中，他们就有这样的尺子--98% 。一个数值，他说，整个的开发中有两次系统的表现低于这个指标：一次，是整个的开发组都叫停了下来，大家一起检讨出了什么问题，什么是需要解决的，不然这就像船的结果一样了，大家辛辛苦苦的开发，但{zh1}产品可能已经出现了重大问题。{zh1}大家停下来找到问题，重新修正了设计、修复了Bug，指标又恢复上去了，然后开发继续向前。还有一次，是大家讨论之后，针对这个问题/bug 和目前的进度以及各项情况比较下来，认为这个指标低是暂时的，而且目前它的优先级并不高，所以测试的负责人{zh1}做了决定，保留这个Bug，让进度继续向前。大约4周后，Bug被修复，指标又上去了。 他说，未来的软件开发一定要是动态的和非线性的发展，但是在这个动态和非线性的过程中，测试要能制造出这根尺子，有这个模型来动态的评估你的系统和产品的质量。如果没有，他说，那就会这个船一样。所以你说，如果测试是找bug，那么大家很容易去追求这个Bug的数量，而忽视质量；同样你也不能只验证功能，就像这造潜艇的，所有的零件质量都是合格的，但是{zh1}它一样会翻船，质量好只能是说船翻了，残骸还挺牢固的。 至于这98%，内行都知道，这时产品测试规划中，通过各种模型、指标、约束条件、客户环境、市场因素、软硬件环境、需求复杂度和技术水平综合考虑，拟定的一个指标，你的产品测试达到这个指标，那么所约定的所有指标和环境下，这个产品都应该是测试计划和规划中描述的一个表现和质量水平。 刘老师说，他们楼里面，有三层楼分别有三个不同的大的测试系统，从不同的角度和模型来测试和考量产品的质量。 他说完后，我心中有了动态系统，动态尺子的概念，在整个产品开发的生命周期中，你是否有一把动态的尺子衡量你的产品质量和进度。我想，做到这个很难。但心里感觉这是一个挺新的概念。 他又说，第二个问题。还是重心的问题。潜艇的研发过程中，为什么不能测试发现这个问题？他说，资料上说是两个原因，{dy}原因是当时的条件下，对于这种潜艇的架构和动力理论下面，很难进行模拟，而且根本没有办法进行测试。只有在潜艇完成80%的时候，他们动用了几千人，通过人的模拟来测试重心系统，而且非常简单，让这几千人从船头跑到船尾。资料上说，这次测试的结果并不十分理想，但是潜艇已经完成了80%，到了项目的后期，统帅在等待这个潜艇的完工下水，所以这时候，没有人敢提这个问题，大家只能这么做下去了。 他说，这就是我们测试经常讨论的第二问题，怎么测试的问题？传统中，测试似乎都是测试组的事情，开发组完成开发就可以了。但是这个例子说明，测试是设计的事情，产品设计要可测，你不能设计完了就完了。现在所有的PM完成你的Spec，在Review之前你一定要准备好两点，{dy}，你设计的东西怎么测试，你要告诉别人你的设计怎样来测试。第二，你设计的东西是否安全，为什么这样设计是安全的？ 他说，SQL Server中有一个核心的模块，代码量很少，但是太底层了，所以很难测试，但是因为设计的时候就要求达到可测试性，所以这个模块的开发人员有两个月就在为测试写代码，写了许多供测试组调用的函数和接口，测试的设计工程师再通过这个函数和接口编写自己的测试程序。而且这些代码在产品发布的时候都没有被编译进去，但是这个函数集和代码量非常的大。他说这个和潜艇动力系统的重心测试一样，如果你设计的产品没法测试或者别人不知道怎样测试，那么你的设计就有问题。而且越晚测试，问题就可能越大，到{zh1}即使发现问题，产品明天要发布，你怎么办？ 然后聊到请这些测试人员要花很多钱，为什么不用现成的测试工具？刘老师说，这个没有办法，这也是产品开发投资的一部分，他说，{zh0}的测试工具不在VSTS中，而在产品组中，在产品组的内部。他说，一般内部测试30%的是手工测试，70%的是自动测试，他说高一点的要求85%都是自动测试，如果你靠购买的现成的测试工具，那风险太大了，况且这些工具不能覆盖整个的产品开发周期，也就很难产生一把动态的"尺子"。他说，他不知中国的公司怎样，即使在美国，也很少有公司像微软这样，会请这么多的人进行测试。一想到85%的自动测试、1比2的测试人数，我想，中国大多数公司也会害怕了。不过我认为，测试永无止境，99%容易达到，往往再提高1% 可能需要花费你现在所有的花费再加上200%的力气才可能达到，这个依照不同的环境、客户、公司而不同。 不过聊完成之后，感到前面潜艇的故事还是非常有收获。如果不是下午他还有课程要讲，我想，还会收获更多。 好了，这是我参加广州的SQL Server 2005/ Visual Studio 2005{zh1}也是{zd0}的收获，和你一起分享。并在{zh1}衷心地谢谢刘老师。 （本文来自CSDN博客:）
转载二： 转眼已经是毕业后的第5个年头，从事硬件测试工作也已经超过两年，随着工作的逐步深入以及职位的变化，测试这项工作带给我的困惑似乎越来越多，这段时间总会不经意的问自己，究竟什么是测试？和周边的同事朋友交流后发觉很多人都存在和我一样的疑惑，只能是仁者见仁，智者见智。 毕业后的{dy}份工作从事的是汽车电子硬件开发，从那时起就开始或多或少的接触测试，准确的说是接触测试人员。记得当时部门里开发团队有十几二十人，有车载CD、DVD、胎压检测、GPS等好几个项目组，测试人员却只配备了两个，而且还是两个女孩。当时就觉得这两女孩挺厉害啊，两个人能够对付这么多项目这么多产品的测试。没过多久，才发现根本不是那么回事。她们的工作仅仅是在开发人员把产品调测稳定后用相关仪器验证下产品的各种指标即可。这样说或许还有些不准确，举个例子吧，对车载CD的测试，她们顶多拿个音频分析仪测试下左右声道的接受灵敏度、{zd0}输出功率等指标即可，过了就标个pass，不过就标个fail，然后把测试结果交给开发人员就没事了，对那些不过的项她们也无须给出任何修改建议，更别说负责定位解决了。当然，不可能只有这么俩指标，具体还有哪些指标我是记不住了，但基本上都是些音频指标，其它什么功能、性能、指标、可靠性都不用测试，顺利的话{yt}就可以搞定，因此在后面还从两个做测试的女孩中调了一个专门去管理部门的研发物料。这就是测试给我的{dy}印象：简单，毫无技术含量，测试人员在部门的地位也比开发低了不少，几乎等同打杂。在{dy}个公司待了两年半左右的时间，在这两年半里对测试的理解也就一直是这个程度。 两年前，收到华为的面试通知，聊过后才知道是让我过去做硬件测试工作。基于我当时对测试的理解，肯定是不愿意了，觉得做测试除了轻松，什么都学不到，也得不到周边同事的认同。面试官知道我的想法后，大概给我介绍了下华为的测试工作，具体忘了当时是怎么说的，只记得有两个意思，一是说华为的测试流程与国内绝大多数公司不一样，而是与国外知名公司思路一致；二是说测试人员和开发人员在公司是两个独立的团体，都不可或缺。并且保证到那边学到的东西会比我现在学到的更多，且花的时间更短。我想他应该不会骗我吧，只要能保证这些，我就同意了，再怎么说待遇也比这边好嘛。 从进华为的{dy}天起，就开始对测试有了个全新的认识，才发觉测试工作远没有想象中的那么简单。从方案评审检视，原理图的检视审查，PCB的检视审查到后续的信号质量、时序测试，基本功能性能验证，到可靠性测试，基本上贯穿了产品研发的整个流程，并且对过程中的每个环节都有严格的流程要求 。从这个时候起，我理解的测试简单的来说就是站在用户的角度，把关产品质量。它涉及的工作内容很多，这些工作基本上涵盖在产品的整个生命周期，从需求提取、方案评审、测试执行到后续的产品试产、量产到最终的产品维护，因此对测试人员的要求也很高，知识点不但要专，还要广。 因为有挑战，所以逐步的爱上了这项工作，甚至觉得自己更适合做测试而不是做开发…… （【天涯博客】本文地址） |
