2022年国内软件质量调查报告（中英翻译对照版）

[SoftwareTeacher]

一、背景

从2020年启动首次国内软件质量的调查，已经进入第3年，参加调查的社区越来越多，调查的题目也在不断丰富和完善。2022年的调查得到更多社区的支持，CSDN社区、QECon、异步社区、腾讯WeTest社区、Testin云测试社区、MeterSphere开源社区、掌动智能国产化社区、龙测社区、Eolink API社区、禅道项目管理软件社区、测试窝等都积极参与进来。

为了保持统计数据的连续性，有利于进行比较分析，调查题目尽量不做改动，只是做了局部的调整和优化，例如：

• 安全隐私、用户体验等方面的质量；
• 引入开源组件带来的质量问题

希望本次调查数据更全面、更有价值。这次通过两个渠道分发数据，一是腾讯投票平台分发，获得980份答卷，1770浏览了，回收率为55%，平均完成时间13分45秒，比去年平均完成时间10分26秒高了30%左右，意味着调查数据的质量得到提升。另一个渠道是CSDN自身的问卷平台，回收了384份。需要说明的是，CSDN关闭了学生答题的通道，只是面向在企业工作的工程师，更好地保证问卷质量。两个渠道合计回收了1364份答卷，和去年持平。

作为“软件质量报道”，开展软件质量调查，是一种责任，希望能促进国内软件质量水平和企业的质量管理能力的提升。

 

二、参与调查的企业、团队和产品情况

1. 企业所处行业分布情况。参与调查的企业以互联网为主，今年和去年的数据非常接近（互联网、信息与通信、金融和保险前三大行业今年分别为47.3%、14.7%、13.4%，而去年分别为47.4%、15.1%、13.6%），可以说明调查样本这两年比较稳定，调查数据的可信度有较好的保证。

 

2. 企业规模分布情况。规模分布比较均匀，但大型企业（超过3000人）占比有所降低，从去年的19.9%降到14.1%，是因为今年经济不景气、裁员造成的？1000-3000人的规模企业比例维持稳定（从去年的9.7%降到今年的9.4%，可以归为误差），但微小型企业（小于100人）有所提升（从去年的18.1%+15%升到今年的19.9%+18.6%，相对去年增加了近16%），进一步说明企业规模在缩小？如图2所示。

3. 团队大小分布情况。团队规模分布还比较稳定，和去年类似，团队更倾向于敏捷化团队，1-9人的小团队占了近1/4，超过50人的大团队进一步降低，比去年又低了1.5%（17.7% vs 19.3%），算是进步，虽然进步不大，如图3所示。将团队规模和团队开发模式进行交叉分析，如图4所示，和去年的形态接近，看不到明显改进，Scrum模式中大规模占比依旧很高，倒是“其他敏捷开发模式（如XP、Lean等）的形态最好，但总体看，20人以内的团队，在不同开发模式中都超过50%，占了大多数。

 

4. 团队采用的开发模式情况。毋庸置疑，敏捷已成为主流的开发模式，Scrum开发模式增长比较明显，绝对值提升了3.3%。如果从相对提升看，BDD/FDD提升最大，相对去年增长了近48%（从4.4%提升到6.5%）。如果加上偏敏捷的自定义开发模式，今年合计超过66%，高于去年的63%，可以说2022年更敏捷了，如图5所示。

 

4. 交付周期情况。上面统计结果是66%的团队采用（偏）敏捷开发模式，而交付周期不超过2个月的团队占到70%，说明敏捷开发模式的交付周期大概处于这个范围。

2022年按天交付的团队，绝对值提高了0.7%，不算多，但相对值提高了近10%。按周算的交付团队则下降了3.7%，比较显著（虽然从相对值看，是小于10%的幅度变化），这是因疫情导致工作效率降低而引起的吗？从交付周期3个月内的总量看，基本持平，但交付周期超过6个月的团队增加比较明显，绝对值增加了2.3%，放慢了交付周期，需要进一步了解背后的原因，我们可以等待2023年的数据，工作和生活恢复到常态之后，到时会不会有所改善。

 

5. 团队所开发的产品属于哪一类，是2B还是2C呢？ 由2C向2B方向发展的趋势虽然不明显，但2B的增长还是比较明显的，和2021年对比，今年2B再次提升了3.4%，说明整体向2B发力的趋势是存在的。而2C、内部使用产品都在下降，各自下降了0.5%、2%，虽然2C的市场没有明显下降，但拐点已经出现，同时企业逐渐使用更多的开源产品或采购市场上成熟的工具，这样内部开发任务会降低，这一点也体现出来了。

 

6. 产品形态分布情况。2020年是信创产业全面推广的起点，2021年，信创产业有了更好的发展，基础软件占的比重越来越大，在去年的报告中，我们重点说明了这点，增长显著，相对增长了60%（从2020年的9.4%增长到2021年的15.1%）。今年依旧保持了增长15.7%，虽然只增长了0.6%。

其次，工业互联网和其它网络应用越来越多，后端（服务器端）的开发比重增大。2021年调查的结果显示，后端是前端的两倍，2021年比2020年增加了10%，今年后端继续增长了3.5%（从2021年的43.5%增长到了47%），这样后端是前端的2.47倍，做大平台的趋势明显。

 

三、软件质量整体状况

1. 从调查结果看，整体质量不乐观，和去年基本持平，严重崩溃事件和安全问题还有所恶化。发生过线上严重崩溃事件提升了1.2%，而发生了被攻击且不能正常提供服务的事件有明显增长，绝对值增长了5.3%，相对增加了60%！今年的确发生多起用户数据泄漏问题，调查数据从侧面也暴露出类似的问题，再次显示安全问题不容忽视，希望企业更加关注数据安全，保护好用户的数据。严重崩溃事件和安全问题也会导致了客户满意度降低。

 

最严重的质量问题还是“需求变更频繁”，只是看到有改善的迹象，下降比较明显（下降了4.1%）；排在第2位的线上问题也有所下降（降了2%），但占比依旧很高（39%）。当需求、架构设计质量有所改进的时候，代码质量、测试质量却有所恶化，特别是漏测问题明显恶化，绝对值增加了4.1%，相对值增加了20%。过去一年企业的日子过得艰难，努力在降本增效，从而减少了测试投入或缩短了测试周期？希望背后不是这样的原因。只是从调查数据看，测试的质量下降明显，需要引起企业管理层的重视。质量下降，不应该成为降本增效的副产品，通过提升质量获取更多新用户或留住老用户，反而是降本增效的正确之路。

 

2.质量文化依旧比较落后

质量文化不是一朝一日可以改变的，总体看，2022年没有大的变化，提倡以客户为中心的质量文化反而下降2.4%，刚超过50%，远离我们的期望，如图10所示。从我们期望看，这是最基本的质量文化，80%的团队都应具备这样的质量文化。也有可喜的一面，相对2021年，领导更强调质量的重要性、有更明确的质量目标/方针/政策，而且当产品发布时，如果质量和进度有冲突，相对去年有更多的团队优先考虑质量，虽然整体比例还很低（不到1/3）。

 

3. 质量管理组织不到位

从调查数据来看，在公司层次建立自上而下的SQA（软件质量保证）部门逐年下降，每年下降10%，两年下降超过了20%（相对值，从40%到现在的30%）。但可喜的是每个团队有独立的SQA人员、兼职的SQA角色每年在增加，有独立的SQA人员增加更为明显，两年相对增加了60%。这样的趋势也许是好事，组织弱化，但团队SQA工作增强，团队自身更为主动积极，而不是靠组织压下来。只是绝对比例还比较低，有独立的SQA人员不到20%，但加上兼职的SQA角色，接近50%，再加上有SQA部门的接近80%，挺好，说明绝大多数团队还是重视质量的，如图11所示。

 

四、需求质量

好消息是需求质量有明显改善，对需求质量“很满意”或 “满意” 的团队都有明显的增加，绝对值分别增加了4.1%、6.3%，相对2021年增加了50%、20%等，相对2020年增加了400%、50%等，的确可喜可贺。需求是源头，它的质量会极大影响了产品的质量，甚至对研发效能、最终的价值交付影响都很关键，我们这份调查也一直把“需求质量”放在重要的位置，推动需求质量的不断提升，见证了这方面的进步。

 

虽然需求质量正在明显改善，但整体质量不够乐观，满意的团队还不到50%。如果有一天，满意的团队超过80%，我们的质量调查就可以停止了。目前需求质量还存在比较多的问题，排在首位的依旧是： “需求文档描述模糊、细化不够”，而且还提高了几个百分点，超过了54%，但2021年排在第2位“需求变更频繁”降到第4位，而2021年并列第3位的“ 需求文档缺少典型的场景/用例”、“ 需求文档缺少验收标准（未实施ATDD）”上升到第2、第3位。总体看，严重的问题更严重了，而相对不严重的问题更不严重了。

去年提到的、其它的一些问题也依旧存在，如：根本没有系统性的质量管理、需求浮于表面、老板说了算、领导不重视需求、需求澄清做得不够、流程不够规范、开发前缺少非功能性需求、没有需求计划会议、不完善的需求评审制度等。

需求质量保障措施相对稳定，2022年和2021年相比，没有明显变化，虽然第1、2名“有明确的需求规范”、“在会议上集中评审”换了位置，但两者相差只有0.9%，依旧是主流措施，遥遥领先其他措施。排在第3、4位的依旧是“严格的需求评审流程”、“需求管理系统对基线、变更等审核、管理”等。

参与调查的同学也提了一些其它保证需求质量的实践：

• 和客户直接沟通/面对面的交流；
• 研发、测试发现问题并补全；
• 内部一致性认知；
• 加强自测；
• 项目组有资深业务员佐证需求；
• 工具条目化管理。

 

五、设计质量

和2021年相比，设计质量有所改善，除了整体设计有略微下降之外，“系统架构设计、UI设计、接口设计、功能设计”都有所提升，其中UI设计、接口设计提升明显，如图15所示。这也符合我们的预期，一方面软件团队更关注用户体验（UX），着力提升UX设计，会在UI设计上反映出来；另方面，现在软件架构多采用微服务架构，自然会关注接口设计。但从数据看，满意的数据都没达到50%，努力提升的空间还是很大的，需要培养更多、更优秀的架构师、UI设计师和产品经理等，提升设计质量。

 

对各项设计不满意的数据总体变好，对“系统架构设计、UI设计”不满意的人数下降明显（分别降了7%、4.5%），只有接口设计上升了1%，如图16所示。看似图16数据和图15数据不一致——图16下降的数据并不等于图15上升的数据，但我们可以这样解释，供参考：例如这7%的人可能从2021年对“系统架构设计”负面情绪转化为2022年的中性情绪，而没有转化为正面（满意）情绪。“系统架构设计”满意的人占35.1%，不满意的人占28%，持中性态度的人占36.9%（100-35.1-28=36.9）。持正面情绪的人数都高于持负面情绪的人数，除了“系统整体设计”（25.1% vs 28.3%）。

在2022年增加了“安全/个人隐私相关的设计”、“移动端体验设计”两个指标项，从调查结果看，“安全/个人隐私相关的设计”排在第2的位置，质量相对较差，需要引起我们的重视，而“移动端体验设计”排在最后一位（不考虑“其他”选项），说明是设计质量中最好的，这也基本符合预期，移动端是商家必争之地，各家公司在“移动端体验设计”上的确下了功夫，甚至下了血本来提升用户体验。

 

去年，我们提醒“设计评审”下降比较快，引起国内团队关注，今年这块有提升，从55.6%提升到58.1%，排在第一的位置。“选用成熟的设计模式”、“ 邀请测试人员参加设计评审”都有一定程度的提升，这些是进步的项，如图17所示。但也有退步的项，如“设计规范”、“原型仿真”等，其中“邀请运维人员参加设计评审”退步明显，不符合我们预期，因为这两年大家提倡DevOps实践，开发与运维更加融合，从这个角度看，“邀请运维人员参加设计评审”不应该退步，而应该是大踏步前进，希望明年会有改观。明年也需要增加运维相关的调查题目，让更多开发关注这块。

 

六、代码质量

在我们软件质量调查的不断推动下，研发团队越来越关注代码的质量，“不清楚”自己公司的代码质量水平的比例逐年下降，相对降幅已接近30%，如图18所示。高质量代码（<=2%）的公司比较稳定，接近30%；少数团队（接近8%）的代码质量堪忧，算上26.6%“不清楚”的，超过1/3的研发团队的代码质量堪忧，希望未来几年能降到20%以下。

单元测试是质量保证的基础工作，能够比较彻底地发现缺陷，许多开源项目都做得挺好的，但是单元测试一直是国内软件研发老大难的问题，不受重视，许多团队在做项目计划时都没有把单元测试考虑进去，也是国内软件质量上不去的主要原因之一。在《软件质量报道》公众号、敏捷教练等不断呼吁之下，这两年还是有很大进步，从2020年对单元测试没有要求的团队占到60%，降到今年的39.6%，下降了20%，每年下降10%，如图19所示，降幅还是很大的，值得高兴。同时，“分支覆盖率大于90%、行覆盖率大于90%”增长明显，分别增加了4.3%、4.5%，希望未来还能保持这样向好的发展趋势。“MC/DC大于90%” 基本稳定，属于航空航天、核工业等领域、开发性命攸关软件的团队。

去年报告做了交叉分析，从开发模式看，采用敏捷的、规范的开发模式，在单元测试上都有更好的表现，而自定义的开发模式在单元测试上表现比较差；从行业看，性命攸关系统（如航空航天、军工等领域）的单元测试在MC/DC、分支覆盖率上表现最好，远高于其它行业，是互联网、信息和通信、金融和保险等的2-3倍。

 

在2021年软件质量调查中，代码质量保证措施的结果让人激动，虽然今年的结果没有让我们激动，但和去年的结果基本保持一致，这也说明这两年的调查数据具有很高的可信度。代码质量所依赖的三大法宝：“人工的代码评审、工具的代码分析和良好的代码规范”的每一项占比都超过了55%，即使在普遍采用代码静态分析工具的今天，人们也没忽视人工代码评审，排在第一的位置，占比超过60%。不过，从我们内心深处，希望这三项占比能达到80%，符合80/20原则，即大多数公司是好公司，不好的公司占20%。

 

七、开源组件质量管理

现在引入开源组件非常普遍，所以在2022年软件质量调查中增加了一道开源组件的质量管理项目。“有专门的团队负责”、“有严格的审查制度”接近1/3，感觉还是不错的，之前认为只有一些大公司才会有专门的团队负责、严格的审查制度。有些开源的组件测试不充分，所以“自己再进行相关的测试”排在第一的位置，但也不到50%，而更低的是“使用PCA工具进行检查”，刚接近1/5，看来不少公司对PCA工具不了解，虽然对代码的安全扫描或静态分析是常态。

 

八、测试质量

测试是软件各个阶段的质量守护，同时提供质量信息，软件测试的质量关系到开发的效率和最终的交付质量。如果漏测严重，那么线上的问题就会比较多，用户就不会满意，最终影响企业的竞争力和利润。

测试的充分性主要是通过测试覆盖率来度量，从调查数据看，主要依赖功能和业务方面的测试覆盖率来度量，其中“依赖业务覆盖率来衡量”增长明显（增长了近6%），如图22所示。这也没错，毕竟我们交付的是功能，确保业务不出问题，但代码覆盖率毕竟客观，是一个值得关注的度量指标。从过去三年数据看，代码覆盖率的度量是在不断增加的，虽然还低于30%。测试人员比较注重评审，所以测试计划、测试用例评审做得比较好，超过50%，其中测试用例评审达到56.3%，排在第一的位置，在意料之中，但还是低于我们的预期（预期是80%），所以还有比较大的改进空间。从调查数据看，2022年各项都是在提高，只有“强调质量是构建的”不增反降，而且差不多是最低的，只有16.5%，这项数据就让我们忧伤。去年报告还说“‘强调质量是构建的’从2020年的26.9%降到现在的18.1%，刚看到的一线希望又被扑灭了”，难道进入2022年，希望彻底被扑灭了吗？不！只要不等于零，还存在希望。希望未来人们拥有先进的质量理念，如“质量是内建起来的、不是测试测出来的”，从而也更加关注“根因分析”、预防缺陷，目前“根因分析与持续改进”也只有34%。

 

2021年增加了“测试团队/人员配置情况”调查，今年拿到的数据比去年有进步， “有独立的测试团队（项目中测试小组）”下降了仅5%（从去年的67.3%下降到今年的62.4%），同时 “没有专职的测试人员”、“没有测试人员”这两项都有所上升（分别提升了2.7%、1%），如图23所示，这说明国内开始形成开发测试融合的趋势，只是这个进展非常慢。2022年也了解到一两个大厂正在做类似微软2012年-2014年做的事——“专职的测试工程师”转型为“软件工程师”。

进一步做“测试团队/人员配置情况”与“团队开发模式”的交叉分析，结果和去年接近，甚至在Scrum开发模式中，“有独立的测试团队”还增长了1.8%，今年高达74%，高于平均值10%，如图24所示。我们可以说：Scrum被做烂了？“不少团队实施的Scrum都是伪敏捷”，其实就是小瀑布模型。类似的，偏敏捷的、偏瀑布的自定义开发模式都超过了70%，换汤不换药，只有采用XP、Lean、BDD/FDD开发模式的，表现要好得多。总之，国内相对保守，开发和测试融合得不彻底，在未来几年“降本增效”的大潮中，会不会加快开发测试融合的步伐呢？我们拭目以待。

 

九、质量工程与工具

从2021年开始，增加了质量工程、自动化测试和质量门禁工具等的调查，配合《数字化时代质量工程白皮书》未来的版本改进工作，同时也进一步了解大家比较关注的自动化测试等方面的情况。

首先看自动化测试水平分布情况，有升有降，“90%以上”自动化水平的比例没有上升，反而下降了1.3%，但“50～70%”自动化水平上升了4.3%，还比较显著，给我们带来一丝喜悦。5年前大部分（超过50%水平的）已实现自动化测试只有32%，现在（2022年）达到47%，增长了15%，算是长足的进步，希望保持这样进步的趋势，甚至有更快的进步，2023年就超过50%。

 

其次看质量工程技术/实践应用情况，基本符合预期，由于混沌工程的兴起、DevOps的进一步推进，“面向弹性/韧性的设计”、“高度自动化的CI/CD流水线”这两项有显著的增长，分别增长了3.8%、2.3%，其中混沌工程也增长了1.3%，接近10%，虽然还很低。退步明显的是“业务驱动的需求工程”，下降了3.1%。总体看，“性能工程”、“安全工程”、“用户体验工程”都低于20%，有较大的发展空间。

 

去年质量门禁工具，“Jenkins + SonarQube”堪称一支独秀，占据半壁江山（58.7%），今年则大幅下降到37.1%。现实情况可能变化没那么大，今年的选项也是根据去年的调查结果进行了调整，考虑到自研偏多，增加了“自研工具”、“混合方案”，这两项的占比分别有24.9%和18.1%，但排在第二位的不是它们，而是落后的手工测试，占比达33%，希望未来几年，手工测试占比急剧下降。

明年（2023年）团队希望在哪几个质量专项增加更多的自动化测试/工具的投入？和2022年对比，排序没有大的变化，第2名“后端性能（含监控）”成为了第一名，而第一名“功能UI/API测试”成了第2，但两者只差1%，去年也是差1%，意味着后台运维更为重要，如最近一年开始兴起的“可观测性”， 符合大势。再往下看。“前端性能（含监控）”、“安全性”等工具投入的比例增加了4.8%、2.8%，也符合大势，但用户体验下降就很难理解，是因为这方面之前投入比较多了、接近成熟？

 

十、今明两年的软件质量管理工作

质量管理重点工作，2022年在内建质量上有明显增长，即“重新设计/优化架构”、 “代码重构优化”分别增长了3.7%、5.2%，重点工作方向是正确的，此处可以给掌声。 “提升测试能力、规范测试水平”、“流程改进”等比例适当下降，这是可以接受的，甚至可以说 “方向正确”，但仍排在第1、第2的位置，不是很合适。 “质量文化”、 “研发基础设施建设”连续两年下滑，方向都有问题了，需要引起我们足够的警惕，是不是再次说明某些领导不重视质量？

不过，从2021年调查项“明年（2022年），您团队软件质量改进，会侧重哪几个方面？”的结果和今年调查项“*今年*（2022年），您团队把质量工作的重点放在哪个方面？”基本是一致的，只是存在一些误区，例如“抓质量就是抓测试”、“抓质量就是抓流程改进”，但没有从“质量文化”这个根本上去抓，也没有把“架构设计、代码”等内建质量放在更高的位置，希望团队在未来要远离误区，真正把工作重点放在质量文化、核心能力的建设上。

 

明年计划的重点排在第一位的还是“提升测试能力、规范测试水平”，相比去年还略增，如前所述，这是一大误区。“团队人员能力建设（培训）上”虽然还排在第2的位置，但连续两年下滑，方向性出了问题，因为人是决定的因素，甚至说，所有的问题最终都归为人的问题。因为明年计划和今年的工作重点是吻合的，该说的，已经说了。