论研发项目生产质量低的原因分析和解决方案

姜成玲

（中国—东盟信息港股份有限公司，广西 南宁 530200）

0 引言

本文在开展研发项目生产管理质量的研究中，对公司中的度量数据进行调查和分析，发现项目中存在的问题，将统计数据和计划目标的缺陷密度水平进行对比。发现项目问题缺陷较少，能够满足目标要求，但是仍然存在很多问题亟待改进。企业的发展建设中，必须要对研发项目生产质量问题进行分析，确定原因所在，以提出针对性的解决方案与策略。

1 研发项目生产质量分析

1.1 数据收集和分析

为进一步提升企业项目生产质量问题分析的水平，在研究中引入了EPG技术以扩大数据收集范围和数据收集量。以某公司两个月的数据进行统计分析，在数据筛选和分析中基于一定的原则执行，项目和数据选择中按照如下原则进行：

（1）分别采用简单测试配置和详细测试两种测试方式进行测试，获得的数据用于本研究。

（2）本研究中涉及的项目要求需求和设计评审过程稳定。

（3）故事点数、测试用例数和线上bug等数据收集完整。

基于前面数据和项目筛选原则，结合相应模型对研发项目生产质量情况进行评价，主要包括以下几个模型：

简单测试缺陷密度模型：

缺陷密度=0.2141+0.1461＊用例密度-0.05176＊开发平均行业经验

目前公司平均行业开发经验5.78年，行业经验需要在本领域内进行经验积累，也很难在短时间内对开发平均行业经验进行大幅度提升，对本因子暂不考虑改进。测试用的密度：UCL=1.491，均值=0.638，标准差=0.256，1个故事点只有0.638个用例，用例密度不高，仍然有进一步提升的空间，后期再对此进行更进一步的分析。

详细测试缺陷密度模型：

缺陷密度详细=0.4460-0.003130＊需求清晰度+0.02801＊测试人员平均行业经验

目前公司测试平均行业约2.99年，测试行业经验需要在本领域内进行经验积累，也很难在短时间内对测试平均行业经验进行大幅度提升，对本因子暂不考虑改进。需求清晰度密度：UCL=113.18，均值=72.33，标准差=11.16，需求清晰度的均值不高，根据需求清晰度模型：需求清晰度=需求评审分值（65）+需求文档分值（35），需求评审均值为15分，需求文档规范性平均分数为50分。EPG又对需求规范及需求评审做了进一步的分析，分析如下图1：

图1 需求规范的I-MR控制图

需求规范：UCL=84.64，均值=51.4，标准差=9.605，需求规范均值较低。

需求评审：UCL=31.95，均值=20.93，标准差=3.41。需求评审均值较低。

通过评价结果能够看出，该公司当中目前研发项目生产的需求规范均值较低，且需求评审均值也较低。因此需要对需求规范分数及需求评审进一步地提高，来降低缺陷密度。

图2 需求评审的I-MR控制图

1.2 数据分析初步结论

从以上的数据分析结果看，简单测试中测试用例的密度对缺陷密度有很重要的影响。而详细测试中需求的清晰度与系统缺陷呈负相关，需求越清晰缺陷密度越小，系统质量将越高[1]。且研究的公司中研发项目生产的需求规范均值较低，且需求评审均值较低。因此，本文希望就需求规范较低及需求评审均值较低的原因进行分析，并就如何提升项目用例密度及需求清晰度展开研究。

2 研发项目生产质量低原因分析

根据前面数据分析的结论，跟缺陷密度相关的关键因素主要包括：需求清晰度和用例密度，下面将从这两个维度进行分析。

2.1 用例密度

对简单测试软件质量影响的主要因素是用例的密度，EPG对符合条件的6个17个版本项目进行分析，目前用例均值为0.638。

公司用例密度模型：用例密度=checklist检查点/故事点，检查点数包括：公共用例及关键用例。关键用例是每次迭代中涉及主流程的用例，目前关键用例在每次需求中均进行了完整的输入和评审，提升空间较小。公共用例包括产品管理办法中通用模块的用例、通用经验形成的用例及线上bug用例。

目前公司公共用例共有107条，涉及功能模块10个，涉及2个应用场景，移动端和桌面端，移动端用例数占整体用例15个。

EPG又对近2个月发生的28个线上bug所属责任人进行了访谈，汇总了产生线上bug原因。共发现28个线上bug，11%是由客户提出的优化性bug，14%是因为测试环境与线上环境不一致引起的bug，75%的原因是因测试用例未涉而导致测试遗漏bug。现有公共因测试用例未涉及的线上bug占比75%，占比较高[2]。

EPG对用例密度低的原因进行分析发现：

①很多项目将功能点作为测试用例，并未引入测试公共测试用例。②公用测试用例只涉及app端和web端，且模块类型少。③原有公共用例未对常出现的bug进行汇总整理。④公用用例未根据项目的发展情况做定期的更新维护。⑤每次迭代未对已经出现过的线上bug的再次回归。

根据以上分析结果，EPG建议增加测试用例密度，引入公共用例库和线上bug用例库，并定期对用例进行更新和完善。

2.2 需求清晰度

根据模型可知详细测试软件质量影响的主要因素是需求清晰度，需求清晰度又与需求规范程度及需求评审质量有关，公司需求清晰度模型：需求清晰度（100）=需求规范（65）+需求评审（35）。

EPG对需求规范和需求评审与缺陷密度进行了进一步的相关性分析。根据相关性分析可见R²=0.5678，需求规范与缺陷密度显著相关，需求越规范缺陷密度则会越低。根据相关性分析可见R²=0.3104，需求评审与缺陷密度显著相关，需求评审越高缺陷密度则会越低[3]。

对某公司2个月的需求清晰度数值进行分析，发现公司需求清晰度均值72.3分，需求规范均值50分，需求评审均值15分。

EPG进一步对项目组成员抽样访谈，样本总数为20个人，然后根据访谈人员问题进行分类汇总。统计结果显示逆向场景未体现问题占11%；需求前后不一致，端与端不一致问题占11%；违反撰写不二性问题占14%；未体现需求优先级问题占16%；设计未体现交互设计占23%。 其中设计为体现交互问题占比较高，未按照产品需求规范编写占41%。表达不清晰问题占12%，业务流程逻辑不清晰问题占13%，未覆盖前端人员需求占17%，评审有遗留问题未闭环占20%，场景考虑不全占28%。其中需求覆盖不全、场景覆盖不全，需求、问题未闭环占比较高。

对以上需求不规范及需求评审均值低， EPG又进一步对其原因进行分析，主要包括以下几点：①生命周期覆盖不全：未涉及运维和客服人员的需求；未能覆盖市场前端，产品和市场前端存在脱节。②规范场景不够丰富：规范仅仅覆盖桌面及移动端，共性提炼有待进一步丰富。③缺乏有效管控手段：管控手段更多是定性手段；精细管控手段确实无法保障规范的有效执行。④未能形成价值闭环：需求没有定义价值预期；需求实现后没有进行价值回顾。⑤端到端模板管控缺失：从原型设计、UI设计、代码实现及测试等端到端模板化管控，避免失真[4]。

从以上分析结果可以看出，一方面，在项目中引入并采用公共用例库及线上bug用例库增加用例的密度可以提高缺陷密度，从而提高软件的质量；另一方面，提高需求的清晰度，通过制定完善产品需求规范，完整的流程规范，并对公司产品人员进行产品知识的定期培训，来提升产品人员的技能，提高需求的清晰度。

3 研发项目生产质量低的解决方案与应对策略

3.1 引入公共用例及线上bug用例库提高测试用例的密度

①根据产品规范补充完善公共用例库。②公共用例库中引入bug类的用例。③分析总结线上bug，建立各个项目组线上bug用例库。④针对公共用例库进行季度更新补充机制，线上用例库进行月度更新补充机制。⑤对测试人员进行培训和宣贯。

3.2 完善现有产品管理办法，并进行推广

公司根据现有规范存在的问题，对《中国东信产品管理办法V1.0》进行修订，修订方面如下：

全生命周期管理：规范产品管理14项标准环节，统一文档模板、统一设计及开发原件库、统一操作标准，环环相扣，确保信息在各环境不出现衰减，实现产品全过程规范化、流程化、模板化高质量输出[5]。

全业务场景覆盖：梳理公司现有及潜在的业务场景，针对性进行UI设计规范完善，覆盖公司四大类产品以及桌面、移动端、小程序、大屏、资讯等多种展示方式。

端到端模板管控：流程起始，产品经理按照模板输出标准原型图，途径UI设计、前端界面开发、QA验证等环节，使用Axure模板等工具确保各环节信息传递不失真，最终由产品经理进行验收，形成流程闭环。产品经理为产品标准执行的第一责任人。

需求价值闭环管理：建立基于价值的闭环的需求管理机制，让每个需求提出人有序、公平地提出需求，将有限的研发资源投入到对公司最有利的需求上，实现公司利益最大化。

4 结语

企业的新产品研发管理，是一个包括战略规划（新产品策略形成、制定）和战略实施（包括新产品项目评价、控制）的过程。依据企业的文化、特殊核心竞争能力，分析产业环境及竞争者动态，所有的产品开发，我们认为都是独立的项目，整合管理的概念及资讯、技术，构建一个优质的新产品开发支持及监测系统，提供项目人员便利、丰富、即时及多层面的信息，并控制新产品研发质量、进度、成本及相关工程文件管理，在提升新产品的质量、掌握新产品的成本及开发费用之同时，可以缩短新产品上市的时间。