几种测试类型的理解和实际操作

按一般统计，在完整的软件项目中测试成本占整个开发成本的35%，而开发部分只占30%多一点；另外的35%是系统架构，也就是平常说的需求分析，系统分析，项目规划这些工作。如果说需求分析部分的成本由于往往以来来去去的修改体现出它的价值的话，那么测试，尽管天天说成本比开发的部分还要多；但实际上呢？通常如果是IMS类型的项目，都是十到二十分之一的时间用于测试，更多的时侯，干脆让用户来测试，美其名若系统稳定期。唯一例外的大概是开发防火墙的过程，为了获取准确的性能水平，必须外包进行测试，这才显得测试的成本变得铁打不动的真金白银。

    测试一般是放在系统完成后进行测试，但今天，却常常听到资深开发人员劝导新人们：“测试是开发的第一步”这句话如何理解呢？如果从日本人发明的巴克质量管理的方式去理解，大概是指每一个环节交给下一级时都应该进行测试。有些测试对后面的操作没有太大的影响，如图片不漂亮，菜单不合理，布局很难看之类；而另一些，却直接让下一级无法开始工作，象用例不清晰；用例自相矛盾；组件内部错误；框架不合理等等。固然，一级级把关，可以把质量提高到至少一个档次以上；但就每一个环节而言，仍然是在开发的最后阶段。所以，看来本人的水平还是不到家，"测试是开发的第一步"难以理解，唯一可理解的就是规范先行，文档先行，文档规范化总应该是在编码以前，这也是QA的主要内容；大概这还多少算解释得通。这样，测试和规范两样东西就重合起来了，从严格角度看，测试就是测试，规范归入规范，还是从模块（项目）后的测试开始理解吧；所以所有关于编程和文档、设计规范的内容本人全部不纳入测试讨论范围。或者说，我们重点放在QC上，而不是着眼于规范的QA，尽管那也非常重要。

    单元测试(Unit test)：是针对模块组件或方法的测试。在本人的操作中，一般是开发员工作范围内的测试；在具备组件接口规范的情况下，一般需要做一个测试工具模拟调用环境，编写测试实例，通过断点情况监视模块实际工作是否正常。一股采用这种方式开发的单一功能模块质量都是非常高的。但是如果没有统一的模块规范，那么开发与测试的工作量接近一比一；但如果模块是按统一的标准开发的，那么同一套测试套件就可以用到各个模件上，从而节省了测试时间。本人认为这属于开发部门工作范围内的测试，与QA/QC部门没有什么大的关系，事实上，在这一层次的用例也不是QC可以做到和理解的。

    白箱测试：在理解内部流程的情况下针对逻辑流程设计测试实例，目的是找出极限边缘以及内在的逻辑错误。单元测试中白箱测试的比例很高，（原因不难理解，还有谁比作者自已更理解模块的构造流程的？）。

    黑箱测试：这是QC部门的主要工作。黑箱测试主要在于编写测试实例。不过在实际操作中，都是把最不懂技术的成员分配做测试，最高技术水平就是会用VSS，所以也就别指望编什么测试实例。所谓的黑箱测试，常常是对着菜单按钮，这个按下去，噢，有东西出来了，对的，打个勾——其实，这时侯的实例就是一个个按下去然后看看有没有输出，而且只限于界面方面，内在的部分和边缘情况大概是不用指望的。但据作者所知，在CMM达到四以上的国外软件公司中，黑箱测试是对软件评价的最主要方式，通过合适的测试实例，除了最常见的可用性测试外，还包括压力测试，和怪用测试（Monkey test)。

    压力测试：评价一个系统极限可以承受的压力是多少，同时在超负荷后的的响应情况；同时，在极限状况下，一些平时不太出现的bug也会浮现出来。所以，这个测试作者认为不应该单独由QC部门进行，而应该由开发部门与QC部门联合进行。理想的系统在极限测试状况下就算响应不及，也不至于当机，并在负荷恢复正常后一段时间内可以恢复正常运转。这时当初对windows恶评的原因之一：象网站一旦超出100-200个concurrent,windows不但罢工还死掉了；不得不重启系统（当然，windows任意硬重启都能死鱼翻生，大多数情况下吧，也属一种难能可贵的优点）；而linux在超出负荷后一般情况下下降曲线不至于太明显——不过这也不是绝对的，作者就发现一旦linux在极限状态下进入内存抖动时，死相和windows差不了多少；所以内存不至于耗干是 linux可靠性能超过windows的重要因素。

    回归测试；在修改其中一个模块后看其他模块有什么问题。作者认为这个测试是过程化程序的观念产物，在模块化软件中相互耦合程度低，而且服从统一的调动协议，是不是修改真是自家里的事情，和他人（模块）没有半点相干。

    整体测试：把不同的模块连结后，看看联合工作情况如何。这实际上是对接口协议的测试。作者认为是可以作为接口互动部分的设计一部分工作，没有必要摆出来作为流程之一。同理还有系统测试，反正最后整个系统运行起来是什么情况。看似大，但如果前面已经做到好好的，这里如果出问题那才叫怪呢！

    Alpha测试：放任内部成员胡作非为的测试；

    Beta测试：让全世界的坏人都胡作非为的测试。

    过了这一关后，大概应该可以了吧？？在欧洲美国日本的规范的软件公司大概是可以了。但在中国可不见得，许多时侯业务需求人员会蹦出来说：“不是这个样子的！”早的时侯他不知上那里去了！或者“加上另一个什么功能吧？”，早的时侯他大概是睡觉了。大家伙儿前面做的事情，就冲这两句话就全废了,全部事情得从中间某个环节重来，这才叫恶梦。这时，与其顺着他们老哥胡说八道跑，不如找出合同来一条条地仔细颁下去。

原文转自：http://www.ltesting.net