产品的软件质量对于产品的重要性众所周知，但不同公司在产品软件处于研发阶段的质量管理却是相距甚远。今天叶子就用西游世界中的天、地、神、人、鬼五种仙级侃侃不同的公司在软件研发质量管理方面修炼到何种仙级？

一、质量管理全无—鬼仙级

读研期间，我到导师朋友的公司A公司实习，A公司的主要业务是出售**行业软件和根据自行开发的软件平台实施客户项目的二次开发。

当时A公司的研发人员10人左右，其中包含了我们4个实习生。我进入的团队里，其实就是一个资深的系统架构师+ 4个实习生。我们实习生的工作是在已经搭建好的软件架构上各负责一个模块的开发，每隔一到两天，系统架构师就会把我们叫到面前，将我们开发的代码合入到他的源代码版本中，build过程有问题就解决一下，没有问题就直接合入了。当时我睁大了眼睛，心想我这一实习生写的代码就进入到平台了？平台就可以拿出去做客户项目的软件实施了？要知道我只是在本地电脑上稍微测试了两把。可看到架构师淡定的样子，就啥也没提。和我一起开发的另一个男实习生，他对自己要求高些，他经常想出各种方法测试他开发的模块，以自己最大努力保证不出现bug。

可以说那时，A公司没有一个专职的人来测试这个软件平台。软件研发的质量只存在于开发人员随机的责任心，公司也没有明确要求软件工程师要详细自测，要自己负责自己模块的质量。

即便如此，在当年，我们开发的软件平台在**行业软件测评中还是荣获了“推荐软件”的最高荣誉，也许当时**行业其他的国产软件更烂吧。

当时A公司，可以说产品在研发端的质量管理全无，叶子将其等同为西游世界的“鬼仙”级别，“鬼仙”代表人物是山神、土地，能以鬼魂之体长期存活，但因为是鬼魂之体，在许多方面会受到天地法则的克制。一旦利用该软件平台实施一个现实的客户项目，软件质量问题都会随之而来。

二 质量控制活动只有测试—人仙级

后来经历了公司总人数100人，40-50人研发团队的中小型公司B公司。B公司的主要产品是集成软硬件的终端产品。B公司相对于A公司而言，在软件研发的质量管理实现了从无到有的跨越。

1、从人力设置来讲，研发体系有独立的测试部门，测试人员与开发人员的比例达到1:3。

2、从过程控制来讲，测试标准和测试用例都是集公司的最强技术实力评审而来；公司有bug管理系统跟踪测试提出问题的解决情况；发布的软件经过测试部100%用例覆盖的验证；针对产品发货后的质量问题的改进措施能够循环到下一步产品改进中。

B公司软件研发质量管理从A公司依赖于一个开发人员的随机责任心修炼到依赖于一个测试部门的规范管理，这是一个巨大的进步。叶子将B公司软件研发质量管理列为“人仙”级别，西游世界中人仙的代表是观音禅院中的老方丈，他活了几百岁。B公司的产品在客户环境中软件质量要求不算高，业务也不算复杂，所以B公司的软件研发质量管理暂时还能匹配B公司的业务发展，能够实现正常的产品迭代。但是B公司的软件研发质量仅仅依赖于产品测试，即便测试，也只开展了研发末端的系统测试，即便系统测试，也只开展了针对固定测试用例的手动系统测试，这种最基本的研发质量管理，碰到软件质量要求比较高的产品，就难逃轮回之苦。

三  系统性研发质量管理—神仙级

职业生涯中有幸进入了C公司，C公司当时员工总数万级，主盈业务是**行业集成软硬件的设备提供商。光我进入的产品线，就有1个测试部加3个软件开发部，测试人员与开发人员比例也接近1:3。进入C公司之后，才发现软件研发质量管理的道道如此之多，那么C公司相对于B公司增加了哪些法术来提升产品的软件研发质量呢？

法术一：软件部门落实编程规范，每个软件部门按照自己的业务特点，并吸收历史上容易犯错的一些编码方式形成部门级别的编程规范，全部门学习并且考试，通过这种低成本的方式预防软件bug的产生。

法术二：开发过程中开展代码review，代码review是请在业务上有经验的资深工程师review其他工程师的代码。

法术三：重点产品软件开展白盒、灰盒测试，C公司的测试部不只是在做系统级的黑盒测试，有一半的测试人员在做白盒及灰盒级别的测试。不过白盒和灰盒测试并不是针对所有产品软件开展，只有部分质量要求很高的产品而且公司评估无法仅仅靠黑盒测试来提升质量的才采用。

法术四：测试部门成立技术研究小组，提升测试人员业务能力。当时测试部除了按照产品类型分为几个业务小组之外，还成立几个技术研究小组，这些技术小组组织测试工程师研究协议标准、自动化测试方法等，并在部门内互相学习和分享。C公司的测试人员在对产品功能性能的测试要求和测试重点的把握上，比开发人员更专业。

法术五：开展自动化测试，自动化测试的应用使得测试效率大幅提升，这样固定的测试用例都会尽量采用自动化方式，测试工程师的精力主要放在无测试用例参考的发散型测试上面。

法术六：增加客户环境测试，在产品开发流程中增加实验局阶段，实验局一般部署在能够充分验证产品质量的客户场景。实验室的模拟测试环境跟真实的客户环境还是有区别的，只有通过实验局客户环境验证的产品，才能进行批量出货。

法术七：成立独立的研发质量保证部门，专职的质量保证人员监控并且审计质量管理过程的合规性和质量活动的有效性，负责组织年复一年的持续改进活动。例如总体方案设计、软件模块设计、测试用例设计都必须走同行评审，评审过程质量部监控。

C公司软件研发质量管理从人员配备、流程管控、质量保证、质量控制等方面都比B公司跨越了一个阶梯，实现了系统化的软件研发质量管理体系，并且该体系进入持续改进的良性循环中，所以叶子将C公司的软件研发质量管理列为神仙级。神仙已经脱离了六道轮回之苦，只要不发生大的天劫一般都能安然无恙。C公司目标是成为百年公司，叶子觉得有这个潜力。

四  形神兼备的质量管理—地仙级

D公司工作经历是最令人兴奋，D公司总人数万级以上，主盈业务同C公司一样，是**行业集成软硬件的设备提供商。在D公司，俺才经历和体验什么是真正的软件研发质量管理。前面的C公司软件研发质量管理已经完备了，那么D公司与C公司来比，到底在什么方面不同呢，叶子认为关键两点如下：

1. 质量管理形神中“神”的存在，开发员工具备强烈的质量意识。D公司一位开发人员说的话，我至今记忆犹新。那位开发人员说每次代码合入SVN的时候，他都是胆颤心惊。而事实上，D公司每位开发人员在代码合入之前，都在本地电脑上做过最大限度的自测试，也执行了圈复杂度工具和静态代码走查工具的检查，甚至有些重点模块，软件开发经理已经安排过同行评审。即便这样，在合入SVN的时候，开发人员依然小心翼翼。在代码合入之后，当晚系统就会自动执行持续集成+冒烟测试，第二天一早开发人员就会收到自己所开发模块的bug邮件（如果有的话）。因为冒烟测试执行的是比较基本的功能测试，开发人员如果多次持续集成收到较多bug的话，在绩效方面肯定是受影响。还有一个问题回归不通过，也是非常严肃的事情。如果开发人员修改一个问题后提交给测试部，测试反馈出来该问题回归不通过，开发人员的绩效也是受影响的。严重时,QA可以要求软件开发团队启动内部回溯。正是这些细致的切身可见的质量管理措施，提高了大家的质量意识。相对于那些概念型的质量管理培训，那些遥远的质量案例，这些更能让研发人员感同身受。

2. 项目管理中流程清晰、质量目标明确、质量控制活动经过细致地策划。在D公司，项目计划出来的同时，项目的质量控制活动计划和质量目标已经给出并且经过评审。整个项目开发过程中QA会密切监控质量计划和目标的达成情况。当时我在D公司的项目正好碰到瀑布开发模式向敏捷开发模式转换。软件SE在需求规格分析分解清楚之后，将所有需求拆分为一个个story，软件开发经理将这些story根据紧急程度和基础程度计划到几轮迭代中，并用JIRA工具管理起来，所有人都可以看到整个迭代开发的进展状态。当时我们的项目计划了三轮迭代，每轮迭代里面都安排集中的代码review+系统测试。当然因为产品的商业用途，敏捷里面所提倡的“测试驱动开发”“结对编程”因成本投入太大，没有开展，白盒和灰盒测试也因为投入太大，没有开展。其他关键的质量控制活动和质量目标都定义的非常清晰。下面表格给出部分质量控制活动以及对应的目标定义，供大家理解和参考。

所以叶子将D公司的软件研发质量管理列为地仙级。西游世界中，最厉害的地仙是镇元子。镇元子的人参果，九千年成熟一次，闻一闻人参果，就能活三百六十岁；吃一颗，就能活四万七千年。 试想，D公司的这些管理精髓如果其他公司能学到、用到，是不是有人参果的功效呢。有了人参果，D公司已经是法力无边，即使遭遇天劫也有渡劫之法。

五 只在书上见过没有经历过的质量管理—天仙级

至于天仙级别的软件研发质量管理公司，叶子没有经历过。毕竟A、B、C、D四家公司都是以民用产品为主，并且产品本身不直接涉及到人身性命安全。叶子想，医疗器械、航空设备、汽车设备这些与大众生命密切相关的产品，应该比D公司执行更加严格的研发质量管理，在质量管理上面理应更高一筹。

六 小结

A、B、C、D四家公司规模不同，发展阶段不同，所处的行业也不完全相同，本文也阐述了他们软件研发质量管理层次也是有差距的。质量管理的首要原则是 “以顾客为中心”，产品的质量要求因产品的使用场景不同客户要求也不同，当然每个公司都是把“客户的满意度”放到第一位，但在质量管理方面每个公司都会尽力做到投入收益比的最佳状态，所以对一个公司而言，合适的质量管理很重要。但叶子只是想说，即使目前的软件研发质量管理没有拖业务发展的后腿，管理者也需要知道从哪些方面去提升，更高一个层次的质量管理是什么样子的，需要了解不同层次的质量管理带来投入和产出是什么，需要知道自己所在的团队是否在当前的质量管理投入下做到了卓越。比如说，你所研发的产品也许不需要白盒这种级别的测试，但软件编程规范和代码review这些极低成本质量提升手段，是否可以实施呢？

本文的内容纯属个人工作中一些感想和拙见，如果能够给读者带来一些启发，就已经非常感动；如果有写得不到位的地方，还想读者海涵包容！

另本文用的几个英文缩写，解释如下：

QA：Quality Assurance

SE： System Engineer

DI:   Defect Index

PMO: ProjectManagement Office

SVN: Subversion