尽管，软件测试过程改进现在还没有得到足够的重视，但并不意味着我们不需要做这项工作。相反，它对于提高软件质量尤为重要。 

　　过程改进并不是IT行业专有的词汇。自从有质量活动以来，人们就开始广泛地关注过程改进。在著名的Deming循环中，过程改进甚至被赋予了举足轻重的地位。我们知道在这个循环中（即计划、实施、检查、改进循环），过程改进既是一次质量活动的终点，又是下次质量活动的原点，它起着承上启下的作用。Deming循环中过程改进的理念是如此鲜明而且深入人心，以致CMM的起草者，卡内基梅隆大学软件工程研究所直接将它作为成为CMM进行持续过程改进的基本模型。 

　　尽管过程改进已经不再是新的名词，然而，提出软件测试过程改进却是近些年的事情。读者不妨查阅一下IEEE、ISO、CMM或者CMMI。在这些文献中，有关软件测试过程改进的描述少之又少。那么这是不是意味着软件测试就不需要做过程改进了呢？显然不是这样。首先，测试作为质量控制的重要活动，天然属于Deming循环的应用范畴。这是因为Deming循环最初就是针对质量控制而提出的。其次，软件测试真正进入大众的视野也仅仅是近20年间的事，相关的研究工作做得都还不够。 

　　鉴于资料的严重缺乏，本文仅从工程实践的角度，对软件测试过程改进做一个浅显的介绍与探讨，并欢迎读者朋友来信交流。 

　　软件测试过程的提出 

　　从软件测试外包发展起来的印度软件业，测试过程改进方面值得中国企业学习。 

　　在软件作为手工艺品产出的年代，软件过程的概念还没有萌芽，就谈不上软件测试过程了。直到人们意识到必须用工程化的手段来规范软件生产，软件过程才开始广受关注。一些激进的理论家甚至提出“软件工厂”的概念。顾名思义，这个词很形象地表达了人们对软件开发行业的一种“流程化”的愿望：即开发过程遵循一定的开发步骤，各司其职，井然有序，如同流水线作业一般完成软件产品的开发。不错，在工程思想上，它们的生产过程的确有可以类比的地方，不同的是，流水线生产的冰箱、彩电都是有形的，而软件是无形的。 

　　我们假想一下冰箱的生产过程，在冰箱开始组装之前，所需的所有组件都必须采购或生产出来，并且这些组件必须是严格按照要求的大小、规格、质量完成的，这样才能够组装在一起，达到相应的功能和性能指标。如果冰箱的门比柜体高了2厘米或者说某个螺丝的直径小了1毫米，那么这批冰箱是不能正常使用甚至是不能销售的。 

　　假设冰箱质量检查的流程是这样的：明确标准（也就是知道冰箱的柜体的尺寸，冰箱门的尺寸）→验证标准（验证冰箱柜体的尺寸，冰箱门的尺寸是否匹配）→发现不符合的产品（冰箱门比柜体高了2厘米）→采取措施（更换冰箱柜体或者更换冰箱门）→重新验证（确定冰箱门与柜体的尺寸相匹配了）。 

　　软件测试流程与上述冰箱质量检查流程是类似的，一个较为典型的软件测试流程可以这样描述：制定测试计划→撰写测试用例→执行测试用例→记录并提交缺陷→修改缺陷→回归测试。 

　　把两个过程一一对应起来，得到如下映射关系：制定测试计划、撰写测试用例，也就是明确标准，类似于在生产冰箱的时候，需要根据设计图纸、生产程序，零部件样品逐一确定冰箱的零部件检验标准。执行测试用例，也就是验证标准，类似于逐一分解冰箱的零部件，逐一检查生产质量。记录并提交缺陷，也就是发现不符合的产品。这里略有不同，冰箱的零部件一旦被发现不符合标准，就可能被扔进废品堆，软件部件却不会因此全部都被废弃掉。所以详细的记录缺陷的操作步骤、便于开发人员进行缺陷修复是很有必要的。修改缺陷，类似于冰箱生产过程中发现问题后采取措施，可能是图纸设计的时候尺寸标注错误，也可能试生产系统参数设置的错误，还可能是工人操作不当，总之真正的原因是一定要被找到的。回归测试，类似于冰箱返工后的重新验证，一般找到不符合标准的零件原因后，冰箱除更换相关零部件还需经过二次检测。软件产品也是这样，修正缺陷后仍需进行回归测试。 

　　软件测试过程改进 

　　咋一看，软件测试过程非常简单，读者或许会问，对这样一个简单的过程，有必要进行过程改进吗？回答是肯定的。请看下面这样一个工程经验公式: 质量控制=技术+管理+过程。 

　　其中，测试技术解决了测试采用的方法和技术问题，测试管理保证各项测试活动的顺利开展。然而，对于一个工程而言，过程也就是生命周期，也会至关重要地影响着生产效率和软件质量。软件测试的过程改进，主要着眼于合理调整各项测试活动的时序关系，优化各项测试活动的资源配置以及实现各项测试活动效果的最优化。 

　　以下笔者根据工程实践经验粗略谈谈如何实施软件过程改进。需要引起注意的是，这里列出的仅仅是过程改进中很小的一部分，也是最常见的一些内容。切勿将它们当作过程改进工作的全部。 

　　1．调整测试活动的时序关系 

　　不恰当的测试时序会引起误工和测试进度失控。具体到某个工程实践中，哪些测试活动可以并行，哪些测试活动可以归并完成，哪些测试活动存在时间上的线序关系，一定要区分清楚并做最优化调整。 

　　2．优化测试活动资源配置 

　　测试活动会涉及到人力、设备、场地、软件环境与经费等资源。如何合理地调配各项资源给相关测试活动也是非常值得斟酌的。最常见的就是人力资源的调配，测试部门如果能深入了解员工的专长与兴趣所在，能对测试活动的开展起到事半功倍的效果。 

　　3．提高测试计划的指导性 

　　提高软件测试计划指导性通俗地讲就是提高测试计划的执行力度。这部分内容具体涵盖软件测试策划、软件测试技术剪裁、测试进度管理、成本管理等几个部分。其中测试策划工作主要是指具体测试活动实施之前做好策划工作; 软件测试技术剪裁工作主要是指测试团队应根据软件项目的具体实际剪裁出所要实施的测试技术; 测试进度管理工作主要是指排出各项测试的时间进度及人员安排，如有变动时应做相应调整; 测试成本管理工作的内容是开列出测试活动中会涉及到的资源需求。完成这项工作不仅仅是起草测试大纲以及测试计划，而是要确保这些大纲，计划的内容能真正被执行、真正能用于指导测试工作。 

　　4．确立合理的度量模型和标准 

　　测试过程改进小组应根据企业与项目的实际情况制订适合自己公司的质量度量模型和标准，做符合自己公司发展策略的投入。必须说明：这个标准和模型的确立不是一蹴而就的，而是需要过程改进小组不断实践、不断总结、不断改进的。在公司与项目不断发展变化的氛围中保持动态平衡。一旦确立了质量度量模型和标准，很多测试活动就不至于陷入过度测试或测试不够的尴尬状态中。 

　　5．提高覆盖率 

　　在兼顾成本的前提下，尽量提高覆盖率，对于过程改进而言，是很有意义的。这里主要谈以下三个方面： 

　　一是提高内容的覆盖。不论是起草测试计划、设计测试用例、执行测试用例还是跟踪软件缺陷，内容覆盖率越高，就越能避免故障被遗漏的情况。 

　　二是提高技术的覆盖。对于一项技术指标要尽可能地做到测试技术的覆盖，我们不必要迷信于某位专家或者专业人士，但必须相信他们提出的科学的验证方法，采用越科学的方法来验证某项指标，我们对产品的质量就越有信心。 

　　三是提高测试过程的覆盖。我们知道，没有需求就不能做分析，就不能设计，就不能做开发。测试也是一样，在测试过程中如果疏漏了一个重要环节，就不能很好地达到预先的目标。比如有些企业根本不写测试用例就让测试人员去做测试; 有些企业根本不做测试用例评审，就匆匆发布出去让测试人员执行测试用例; 有些企业测试人员不知道测试的标准，就去报Bug。这些看似不很重要的工作流程一旦被省略往往就造成工作无所适从，难于开展，成为测试活动失败的关键原因所在。 

　　软件测试过程改进的注意事项 

　　1．必须注意过程改进是跟公司的发展战略相关的 

　　过程改进是跟公司的发展战略相关的。有句话叫“过犹不及”，做事情要把握好度。不是所有的公司都像微软公司那样对质量控制和管理能大手笔投入，也不是所有的项目都需要像delphi第一版发布时那样投入3万开发工程师去测试。公司的规模、经济实力、产品投放市场的契机等都将影响软件测试过程订制的策略。不要忘了利润是很多公司的命脉所在。 

　　2．测试过程改进并不意味着必须投入大笔资金 

　　测试过程改进不意味着需要大笔资金投入。有些人说我们公司不给钱买测试工具，不给任何资金请咨询公司，所以我们的过程改进没有任何进展。其实，很多情况下，工具只不过是一个辅助手段，并不足以影响到工作部署与过程改进的效果。请咨询公司固然能很快获得一些知识，但没有它们，也并不意味着过程改进就寸步难行。当然，如果公司已经承诺能提供相关投入，那就另当别论了，在这种情况下，就更有理由做好测试过程改进了。 

本文转自 life0 51CTO博客，原文链接：http://blog.51cto.com/life0/12371，如需转载请自行联系原作者