1. 版权所有ã2021 2020 年国内软件质量调查报告 《软件质量报道》编写 腾讯 WeTest ThoughtWorks 社区 校对 2021 年 1 月 1

2. 版权所有ã2021 目录 2020 年国内软件质量调查报告 .................................... 1 一、背景.................................................... 3 二、参与调查的企业、团队和产品情况.......................... 4 三、软件质量整体状况........................................ 8 四、需求质量............................................... 10 五、设计质量............................................... 12 六、代码质量............................................... 13 七、测试质量............................................... 16 八、今明两年的软件质量管理工作............................. 17 九、附录：金句............................................. 19 十、关于组织者............................................. 24 2

3. 版权所有ã2021 一、背景 最近十年，国内针对软件质量都没有做过全面的调查，根据搜索结果，只在 2009 年有 过一次。当时为了贯彻落实党中央、国务院关于在全国开展“质量和安全年”活动的重大 决策和部署，将提高软件质量作为落实《电子信息产业十一五质量发展规划》和促进软件 服务业平稳快速发展的重要手段，2009 年 10 月，在工业和信息化部科技司、软件服务业 司指导和支持下，工业和信息化部软件与集成电路是进中心(CSIP)在全国范围内开展了软 件质量调查工作。收集了来自 24 个省市自治区的软件企业调研问卷 1173 份，涵盖了软件 标准化、软件过程改进、软件质量管理工具、软件企业评估和软件质量人才培养等各个方 面，在分析和研究的基础上，最终形成了《2009 年中国软件质量硏究报告》。这里摘出几 个和质量管理密切相关的调查结果，如图 1～图 3 所示，供大家参考。 图 1 质量控制的策略和措施 图 2 企业采用的质量管理方法 3

4. 版权所有ã2021 图 3 基础软件企业质量改进需求 十年后的今天，我们处在一个“数字化”的时代，传统企业不得不进行数字化转型， 将客户管理、销售等搬到云上，线上和线下互动；我们还处在“软件定义一切”的时代， 万物互联，家具、汽车、穿戴、运动等都离不开软件，如智能家居、自动驾驶、智能穿戴 等等。在这样的背景下，软件质量非常重要，关系到每一个企业的未来命运，关系到每一 个人的工作与生活。为此，“软件质量报道”公众号联合腾讯 WeTest 和 ThoughtWorks 社 区进行国内软件质量的调查，虽然达不到 2009 年那样的规模，但也收集了来自 22 个省市 469 份有效问卷，而且这次调查的问题更有现实意义和参考价值。 二、参与调查的企业、团队和产品情况 1. 企业所处行业分布情况 。参与调查的企业以互联网为主，占到近 40%，其次是信息和通 信、金融和保险等行业，制造业、航空航天、教育占比比较低 6%～3%，如图 4 所示。 图 4 企业所处行业分布情况 4

5. 版权所有ã2021 2. 企业规模分布情况 。规模分布比较均匀，大型企业（超过 3000 人）和微小型企业（小 于 100 人）基本接近，前者是 23.2%，后者是 21.1%（12.8%+8.3%），和 101～300 人 （21.3%）、301～1000 人（20.7%）规模企业也非常接近，如图 5 所示。 图 5 企业规模分布情况 3. 团队大小分布情况 。现在提倡敏捷开发模式，团队人数相对比较少，10～20 人这样的 团队最多，占到三分之一，少于 20 人的团队超过一半（50.9%）。但让我们惊奇的是，超 过 50 人的团队，居然也接近四分之一，如图 6 所示。 图 6 团队大小分布情况 为什么会有四分之一的团队有这么大的团队？即使经过交叉分析，也没发现什么规 律，即使团队采用敏捷 Scrum 开发模式，团队多于 20 人的占一半，有 23.7%的团队超过 50 人，而采用传统的瀑布模型、V 模型的团队，大于 20 人的团队占到 52%，只高了 2%；大于 50 人的团队占到 25.3%，比 Scrum 团队多出 1.6%，没有显著区分。相对来说，采用 BDD/FDD/XP/Lean 的团队，敏捷特征更显著些。 是不是 Scrum 模式用得比较混乱？ 5

6. 版权所有ã2021 图 7 团队大小与团队开发模式交叉分析结果 4. 团队采用的开发模式情况 。毋庸置疑，敏捷已成为主导开发模式，各种敏捷开发模式 占 28.6，加上偏敏捷的自定义开发模式，合计近 60%，如图 8 所示。传统模式（瀑布模式+ 偏瀑布的自定义开发模式+其它传统开发模式）只占到 28.3%，不到 30%。有高达 10.7%说 不清楚采用的是何种开发模式，还有近 2%属于其它，如“伪敏捷+传统混合”、W 模型（其 实是 V 模型）、混合开发模式、定制、IPD 转型中等。虽然对一个公司来说会有多种开发 模式，不同的团队可以有不同的开发模式，但 对一个团队来说，一般只有一种开发模式 。 图 8 团队采用开发模式统计结果 4. 交付周期情况 。上面统计结果是 60%的团队采用（偏）敏捷开发模式，按天、按周计算 交付周期的占到 56.3%，如图 9 所示，即这部分团队交付周期不会超过 1 个月，可能有 （3～4%）少数团队交付周期是 2～3 个月。根据统计，交付周期 3 个月或比 3 个月还短的 团队占到 77.6%，接近 80%，即绝大部份的团队交付周期都比较短，虽然还有 10%的团队交 付周期超过 6 个月。根据交叉分析的结果，交付周期超过 6 个月的团队主要来源于航空航 天、军工、制造业等（占了 70%），这些团队几乎全部采用传统开发模式或“说不清”。 这说明，敏捷的确会提升软件交付速度。 6

7. 版权所有ã2021 图 9 团队产品交付周期统计结果 5. 团队所开发的产品属于哪一类，是 2B 还是 2C 呢？ 2B 和 2C 产品交付方式差别很大， 从团队的角度看，产品有明确的定位，不会有两种模式共存的，有些产品会是例外，例如 腾讯会议，既可以提供给个人使用，同时也会销售给企业使用，所以这里有 7.7%的“其 他”，如图 10 所示，“2B&2C”。不过，有些同学把政府、医院、军口放在“其他”中， 但它们实际可以归为“2B”，表达为“面向机构的”产品，这样“2B”占到 50%以上。 图 10 团队采用开发模式统计结果 6. 产品形态分布情况 。从图 11 可以看出，基础软件、中间件占的比重低，这也很正常， 多数公司开发软件都是服务于应用，无论是前端还是后端。在“其他”中主要填有 “整个 应用系统（含有前端和后端）”，其次是嵌入式软件、工控软件、网络产品等。 图 11 产品形态统计结果 7

8. 版权所有ã2021 三、软件质量整体状况 1. 从调查结果看，整体质量不乐观 。 近 20%的产品在线上服务发生过严重崩溃事件，如图 12 所示。通过交叉分析，如图 13 所示，互联网行业、教育、政府等行业这类问题相对严重，虽然物流快递最严重，但样 本太少，不宜成为判断的依据。一般来说，互联网行业由于大并发、大流量会发生严重崩 溃事件，而教育、政府等行业主要是由于软件质量偏低、性能测试不足等造成。从开发模 式看，如图 14 所示，敏捷开发模式（或偏敏捷开发模式）产生的严重崩溃事件相对较高， 比传统的开发模式平均高出 6%。 线上问题比较多，占了 37.1%，处在第 2 位置 ，这也进一步说明整体质量不佳。但最 严重的质量问题是“需求变更频繁”，高达 58.2%，但不可思议的是，航空航天、国防行 业需求变更频繁的问题高达 87.5%处在第二，仅次于物流行业（物流行业是一个新兴行 业，需求不稳定应该是常态），如图 13 所示。互联网行业处在平均水平（58.3%），算是 一个比较低的水平，低于通信、政府、教育等行业。需求最稳定行业是制造业（40%），其 次是大金融行业（50%）。另一个不可思议的事——传统或偏传统开发模式的“需求变更频 繁”（算术平均 61.8%）居然高于敏捷开发模式（53.7%）8 个百分点，如图 14 所示。这是 因为采用敏捷开发的公司相对成熟、人员素质水平偏高？开发模式说不清楚的一类团队中 需求变更频繁（一般代表落后企业）也偏高，达到 60%，算不算一个佐证？ 图 12 软件产品质量整体状况 8

9. 版权所有ã2021 图 13 不同行业的软件产品质量状况 图 14 不同开发模式的软件产品质量状况 2.质量管理依旧比较落后 质量不好，在质量管理上会有明显的体现 ，例如当产品发布时，如果质量和进度有 冲突，只有 25%团队优先考虑质量，而绝大多数的团队则优先考虑进度（如图 15 所示）。 图 15 质量管理主要表现统计结果 9

10. 版权所有ã2021 有“质量指标的可视化看板” （可以看作是质量度量）的，则更低，只有 21.5% ，所 以线上出现严重崩溃问题、线上问题比较多，就容易理解了。从其他方面看，企业整体表 现也不够理想，只有一半的企业重视质量文化建设、绩效考核中有明确的质量指标。只有 40%的领导重视质量、40%的公司制定了明确的质量放方针，而我们的期望是 80%以上的企 业能做到上面几点。 3. 质量管理组织不到位 对标准不重视、对质量不重视，在软件行业是一种普遍现象。软件测试虽然是质量 保证的重要手段，但软件测试部门不是质量管理部门，软件测试只是软件研发中一种技术 岗位，软件测试人员也很难规范开发人员、产品人员和业务人员的工作，没有时间和精力 去审查流程和优化流程。所以，要做好质量管理，需要在公司层次建立自上而下的 SQA （软件质量保证）部门。从调查来看，只有不到 40%的公司建立了 SQA 部门，质量管理组 织上是不到位的，如图 16 所示。如果加上有 SQA 角色的，不管是专职的还是兼职的，接近 75%，只有四分之一的公司彻底没有 SQA。从交叉分析看，制造业、通信和大金融等行业的 SQA 部门设置比较高，互联网行业设置比较低（31%），最低的是教育机构，只有 13.3%。 但令人惊奇的是航空航天、军工企业设置也偏低，只有 37.5%，低于平均值。 图 16 SQA 部门或角色设置情况 四、需求质量 需求是源头，需求质量最重要，但绝大多数对需求质量不满意，感觉 “满意”或 “很满意” 的不到四分之一，只有 24.8%，如图 17 所示。从保障需求质量实践看，如图 10

11. 版权所有ã2021 18 所示，超过 60%的团队有明确的需求规范，而且有集体的会议评审，但为什么需求质量 还不高呢？ 图 17 对需求质量的感受 调查结果说明多数团队需求规范没有严格执行、评审走过场（虽然有 40%的团队有严 格的评审流程），没有真正发挥评审的价值或作用。这次调查，有人在“其他”中就写上 “有流程但操作看缘分”、“虽然有规范流程，但实际中执行率不高”等。有些同学在调 查中还写道“无明确管理规范”、“需求不规范”和“大家做习惯了，规范不起来”等 等。但有些公司有 SQA 这样的角色进行专人检查、有完善的需求工程体系，结果应该会好 些。从统计结果看，这两项的比例（22.4～27.9%）和图 17 的“满意+很满意”的比例 （24.8%）比较接近，通过交叉分析，也验证了这点，“有 SQA 这样的角色进行专人检查、 有完善的需求工程体系”的团队对需求质量“满意+”的接近 50%，远远超过整体比例 24.8%，对需求质量“不满意-”不到 10%，远远低于平均水平 23.1%。 图 18 保障需求质量的主要实践 11

12. 版权所有ã2021 五、设计质量 平时大家对设计质量关注会比较少，但设计质量也很关键，特别是系统架构设计好 坏会影响软件系统整个生命周期，所以 IBM RUP 就特别强调 以架构设计为中心，架构设计 好了，系统不仅性能好、稳定可靠，而且将来更容易维护、扩充，更能适应业务需求的变 更。 但调查显示，设计质量也不乐观 ，如图 19 所示，人们对“系统整体设计”满意的， 只有 27.3% ，比需求略高一些，人们对关键的“系统架构设计”满意的，也不到三分之 一，只有 32.4%。 UI 设计是最低的，只有 25.8%，即只有四分之一的人满意。功能设计、 接口设计相对好些，也不到一半。有几个参与调查者回答：“没有设计评审”，也有参与 调查者写到“不太重视设计”、“没有根据公司开发人员实际能力水平进行调整”、“设 计规范只是个摆设，没有实际用途”等。 图 19 对各项设计质量满意的统计结果 图 20 对各项设计质量不 满意的统计结果 12

13. 版权所有ã2021 图 20 的对各项设计质量不 满意的统计结果正好是对图 19 的结果的验证，两种结果 是一致的，而且在 UI 设计、架构设计和整体设计上不满意的比例高于满意的比例不少，像 在 UI 设计上，“不满意 : 满意”比例为 42.2% : 25.8%。 在如何保证设计质量上，大家有一系列的优秀实践，最主要的实践有：加强设计评 审、邀请测试人员参加设计评审、制定设计规范；其次，选用成熟的设计模式、培养/设置 能力强的架构师 和 原型验证，但这些方面做得不够。而邀请运维人员参加设计评审的比 例只有 15.6%，说明这方面做得明显不足。正常情况下，除了嵌入式软件、政府/军工、航 空航天等行业之外，像互联网行业、金融行业、通信行业等（超过 70%）都需要运维人员 参与评审，所以比例不至于这么低。 除了这些实践，也有参与者提供了其它的实践： ² 敏捷持续迭代 或 引入 BDD； ² 规范的流程体系； ² 高管评审； ² 开发人员进行自测、交叉评审； ² 邮件通知上下游等。 图 21 软件设计主要实践 六、代码质量 需求决定了我们是否能做对事情，设计决定了软件如何被开发出来，但软件的最终 载体是代码，以后长期维护的也是代码，代码质量自然不容忽视，代码质量也是许多公司 13

14. 版权所有ã2021 更关注的，但从调查结果看，如图 22 所示，近 4 成的团队（高达 38%）并不清楚自己公司 的代码质量处在什么水平，说明有很多公司对代码质量关注还是不够。如果按照 CMMI 之前 的参考数据，差不多有 10%公司达到或接近 CMMI 5 级水平（0.86 Bug/KLOC），20%公司达 到或接近 CMMI 4 级，也就是说这 30%的公司代码质量还是很高的。如果觉得 Bug 数/KLOC 低于 3.5，代码质量还不错，那么接近一半（46.2%）公司的代码质量达到了较高水平。 图 22 代码质量 KLOC 度量结果 每千行代码（KLOC）的缺陷数还取决于测试，测试做得不好，缺陷数反而比较低， 给出“代码质量高”的假象。例如，单元测试始终没有得到大家的重视，“单元测试不 足”一直是软件质量上不去的重要原因之一，从统计结果（如图 23 所示）看，对单元测试 没有要求的团队占到大部分 （60%），在软件定义一切、万物互联的时代，这就是一种潜 在的风险，甚至可以说是无数颗不定时的炸弹埋在代码中。因为从系统层次进行测试， 图 23 单元测试统计结果 14

15. 版权所有ã2021 总是很难充分、彻底地完成测试的。只有把每一个单元测试都做好，再进行集成测试、系 统测试、验收测试，质量才能达到很高的水平。按要求，性命攸关系统（如航空航天、军 工、核工业、交通控制等领域的软件）的单元测试需要达到 100% MC/DC 覆盖率，使命攸关 系统（如银行、关键政府部门等领域的软件）的单元测试需要达到 100% 分支覆盖率，而 一般商业软件的单元测试需要超过 80% 代码行覆盖率。实际调查结果，与这些要求相距甚 远，例如虽然单元测试达到 MCDC>90% 的团队，其绝大部分来自航空航天、军工部门，但 在这一领域的团队中，也仅占了 30%左右；金融行业的单元测试达到分支覆盖>90%的团队 比例更低，仅占了 10%左右。 如何保证良好的代码质量呢？主要依赖于人工的代码评审和工具的代码分析，但也 只有三分之一的团队做了，大部分的团队没有做到。这也远低于我们的预期，因为大家可 以借助不少代码扫描的开源工具来做代码静态测试，如图 24 所示，即使购买商业工具，投 入也不大，平时使用时，成本也相对比较低，应该比较容易实施。所以说，质量管理也是 一种习惯，如果看重代码评审，不管是人工评审还是工具分析，团队要么都不做，要做都 做。良好的代码规范，只有 16.6%，打破了 80/20 原则， 说明国内软件团队对代码质量重 视严重不足。 借助 AI 技术推荐代码，幸好不是零，虽然很低，也说明有团队开始尝试了。 有些团队在代码质量保证上什么都没做，参与调查的若干个同学这样写道“啥都没 有”、“个人随意发挥”或“靠程序员自我修养”等，还有一些团队，主要还是靠后期的 测试（联调测试、系统测试等）来保证，虽然有内部审查、普通走查等。 图 24 保证代码质量的主要实践 15

16. 版权所有ã2021 七、测试质量 测试是保证软件质量的重要手段，通过测试发现缺陷、暴露质量风险等，帮助团队 提高质量。测试也是软件交付的质量守门员，通过测试来全面评估软件产品质量，从而基 于测试结果做出产品能否发布的决定。如果测试自身没有做好，有些缺陷或大量的缺陷不 能及时发现，从而我们会做出错误的决定，让不该发布的软件发布出去，造成引起质量事 故，所以测试工作自身的质量也需要一系列实践来保证。 通过调查发现，如图 25 所示，“ 加强测试用例的评审 ”是 “如何保证测试的质 量” 中最常用的手段，接近 70%的团队都会加强测试用例的评审 ； 其次是“依赖功能覆盖 率来衡量”、“依赖业务覆盖率来衡量”、“加强测试计划/方案的评审”等，分别为 60.8%、51.8%、55.7%，都超过了一半。依赖代码覆盖率反倒不高（22.2%），代码覆盖率 是相对客观的手段，未来需要加强。将线上缺陷数作为考核指标的占了 35.2%,但 只有 26.9%的团队“强调质量是构建的”，明显偏低，毕竟质量是内建的，而且开发产生的缺 陷越少，对测试质量的帮助就越大，因为测试的风险会降低、工作量也会减少。个别团队 在保证测试质量方面什么都没有做。 图 25 保证测试质量的主要实践 16

17. 版权所有ã2021 同时，本次调查的参与者也提供了一些保证测试质量的其它实践，如加强对测试人 员的培训、测试流程的规范性、测试自动化平台的支持和代码评审的有效性等。但只有 “代码评审的有效性”还不够，更好的实践是评估“需求评审、设计评审和代码评审”的 有效性，而不只是代码评审。 八、今明两年的软件质量管理工作 调查是在 2020 年底做的，今年是指 2020 年，明年是指 2021 年。根据调查结果，如 图 26 所示，人们在 2020 年软件质量管理上的重点工作，首推“提升测试能力、规范测试 水平”，这实际是进入了一个常见的误区 ——许多公司抓质量就是抓测试。正如前面所 说，质量是内建的，缺陷预防比发现缺陷更有价值，在质量方面开发人员可以做出比测试 人员更大的贡献，正确做法是优先抓开发的质量，但“优化架构、代码重构/优化、质量文 化建设”占比都比较低，分别为 16.9%、26.7%、32.%6,都不到三分之一。 流程改进有利于提升质量，但人更是决定的因素， 但从调查结果看，有些颠倒黑 白，“流程改进（49.7%）”反而高于“团队人员能力建设（41.2%）”。“研发基础设施 建设”属于技术（工具）方面的改进，28.1%，远低于流程改进（49.7%），似乎也不合 理，流程的改进完全可以固化在（融于）研发基础设施中。 图 26 2020 年软件质量管理工作的重点 17

18. 版权所有ã2021 下面我们看看 2021 年，大家计划在软件质量管理上的重点工作和 2020 年有什么不 同？从调查结果看，如图 27 所示，质量管理的误区依旧在那里，只是稍微有些改进，“提 升测试能力、规范测试水平”从 2020 年的 66.3%降到 62.3%。 更大的改进是在“人与流 程”上的拨乱反正 ， 认可人更有价值 ，加强了“团队人员能力建设”，高于“流程改 进”。第 3 个改进是“质量文化建设”有明显提升，从 32.6% 提高到 43.5%，整整 11 个百 分点。第 4 个改进，“优化架构、代码重构/优化、研发基础设施”也都有提升，这也是本 调查所带来的公益，帮助更多的团队在这些方面有更多的思考，引导大家做好 2021 年的计 划工作。 图 27 2021 年软件质量管理工作的重点 18

19. 版权所有ã2021 九、附录：金句 最后，经过整理，关于软件质量或软件质量管理，参与调查的同学奉献了 整整 100 条 有价值、有启发的金句 。 1) 质量是价值的体现、是公司的生存之道。 2) 软件质量是企业生命线、产品的生命线。持续优化、持续改进。 3) 软件质量管理是一个长期进化的历程，没有止境唯有更好，企业能走多远质量管理 就有多严。 4) 质量是一个系统工程，短时间很难看到成效，持续改进是最好的方法。 5) 团队时刻关注质量，质量是团队中每个成员头上悬着的一把刀，持续改进深深烙在 每个人心中。 6) 没有质量保证的高速开发是一种灾难。 7) 质量是 1 到 100 的事情。 8) 质量免费，第一次做对成本最低。 9) 质量不是某个人的事、某个版本的事，而是一种习惯的养成。 10) 坚持以客户为中心，站在客户角度考虑问题。 11) 站在最终用户/客户的角度才能衡量一个产品的质量。 12) 检验质量的主要标准只有一个：满足使用者的实际需要，用户使用软件获得了预期 的信息化带来红利。 13) 如果质量不重要，那么在做的事情一定是不重要的。 14) 你永远都不知道你的用户会怎样使用你的产品。 15) 业务发展走在前面，组织架构变革要紧随其后，质量文化要根植于心。 16) 质量是内建的，质量不是测出来的，但很多开发人员意识不够。 17) 质量是集体内建的，缺陷的预防重于缺陷发现，这个文化还没有形成。 18) 所有与质量有关的人都必须要有对质量的责任心，这样流程才有人遵循，规范才有 人落实，质量才有人保证。 19) 软件质量根源是开发质量，测试如何帮助提升开发质量是一个视角。 20) 质量是一种文化，这点很重要，需要每个岗位上的人员共同加入并与自身工作融入。 21) 流程和标准背后是企业文化，文化畸形结果自然不好。 22) 提高质量意识，流程控制质量，避免个人能力差异。 19

20. 版权所有ã2021 23) 质量不是口号，需要实质性行动。 24) 质量文化的建设，不能只靠理论宣传，更依赖实际有效的行动，以及过程的持续把 控和改进。 25) 质量很重要，做好质量很难，需要有强领军人物和把质量重要性落到实处， 而不仅 仅是一句口号。 26) 关于软件质量，始终坚持：软件质量不是测试出来的，需要对整个软件项目的整个 流程进行构建， 以及质量保障体系的建立。 构建质量体系才是提升软件质量的核心 部分。 27) 软件质量的提升应该是全面质量管理、全员参与意识以及持续不断的价值交付效 率的提升，以内部流程达到 CMMI3 的流程规范以及质量达到 3 西格玛作为年度质 量目标 28) 质量无穷尽，关注质量的同时也要关注如何低成本的实现高质量。 29) 研发前中后三个阶段都需强调质量的重要性，软件质量是要靠全流程来保障， 但现 实中，不同角色对质量认知标准不一致，需要改变。 30) 软件质量受软件生命周期中的每个细节影响，要想做好软件质量保障， 必须全方位 监控。 31) 需要对软件过程有敬畏之心。 32) 流程与人员，对质量缺一不可。 33) 软件工程中人是万恶之源，培养人的能力与责任感，人人对自己的事负责，质量会 有提升。 34) 无论规范是否建立，软件质量还是和个人能力关系较大。 35) 完善基础设施的情况下，以人为本，事半功倍。 36) 流程规范严谨，开发前做好各种评估工作。 37) 开发流程管控对质量的影响比具体细节更重要。 38) 提倡全过程、关键环节全流程质量管理。质量管理是全员扎实做出来的，不是某方 面管出来的。 39) 还是得自上而下的支持、优化流程，提高各类人员的专业素质。 40) 质量必须是一把手工程。一把手不把质量放在经营同等重要位置，没有办法从根本 上提升软件质量。 41) 质量问题归根结底是管理问题。 20

21. 版权所有ã2021 42) 领导重视是关键，部门领导不重视质量，有再多的规范流程，也很难落地执行。 43) 软件质量任重道远，需要领导重视、项目支持。 44) 全员、全面、全流程、全天候质量，各个环节都要问责！ 45) 质量来源于团队整体的保证，需强调团队责任。 46) 质量面前人人有责，质量是全公司至上而下所有人的努力的结果。 47) 看软件的质量就先看生产它的组织，如果组织混乱，分工不清，质量肯定不行。 48) 质量不单单是测试的事情，全员都需要有质量意识。 49) 软件质量根本是研发质量， 就像空气污染的源头是排放污染的企业， 而不是监管部 门。 50) 软件质量不仅仅是测试人员的责任，应该是全员责任，这应该成为一种共识。 51) 提测质量上不去，质量给进度让步，凡事给业务方跪舔，本身就说明了团队导向有 问题。 52) 除了建立各种规范，还得有度量，没有度量就没有改进， 但也不能一味地依赖度量， 可以当做一种改进的途径。 53) 质量从需求开始，靠开发规范，测试人员保障。 54) 需要从细节入手，不急功近利，急于求成。 55) 开发写每一行代码都要考虑质量，提倡开发测试一体化。 56) 质量需要有可靠的工具和有效的方法、加强规范流程来保证。 57) 持续性的迭代质量需要一个规范的流程来保障，需要团队成员包含领导层有共同 的质量意识。 58) 软件质量是设计出来的不是测出来的，不能把所有的问题都遗留给功能测试团队 去解决。 59) 软件设计模式的选取很重要，选对了，可以节省很多时间；产品设计定位不好，累 死开发、测试、交付人员。 60) 质量由测试说了算，拍胸脯、做保证都是扯淡，见过最多的就是项目之初胸脯拍得 响，后期掉链子，质量不是主观上的自信能得到的。 61) 测试背锅的角色始终没有改变，很多行业对测试作用的理解存在误区。 62) 测试人员可尽早介入开发设计的评审，了解设计思路，结合功能业务和设计分析会 更加有针对性。 63) 测试一定要左移，整个团队的质量意识要提高，提测后为时已晚。 21

22. 版权所有ã2021 64) 面对的系统本身的特性，个性化的保证不同的方面，也是质量保证的关键。 65) 质量意识是前提，测试基建是基础。准入准出靠测试标准，问题挖掘靠大脑。 66) 专业的人做专业的事，不懂软件的人不要硬套方法论。 67) 感觉公司的软件质量需要改进的地方很多，但是没有找到真正适合自己的路。 68) 质量是构建出来的，通过人的创造力和科学的技术运用，找到适合适用自身的。 69) 对于软件质量的评判标准还是要有一个可视化的标准。 70) 软件质量不是测出来的，应该从源头设计开始，全员参与测试！ 71) 软件质量与开发密切相关。懂开发才更懂测试，开发和测试要共担质量。 72) 保证软件质量是测试人员的基本素养。 73) 通过持续测试来提升软件质量。 74) 提升测试人员的能力，希望团队领导能更加重视和投入很多的精力在测试和质量 保证这块。 75) 渔网的好坏和池塘里有没有鱼是没有关系的， 测试设计的好坏和系统中有没有 bug 也是没有关系的。 76) 在低成熟度的企业里，百人规模以上应该更强调传统的 QA 职能，强调过程裁剪和 规范。小规模和成熟度高的企业可弱化 QA 职能。 77) 聚集核心业务价值，质量与效率相平衡。 78) 软件质量是重中之重，质量就是效率。 79) AI 未来将会起到很大作用。 80) 在智能 AI 评估器到来前，这所有的一切都是人为的构建、构建、构建！只能证明 哪些地方无恙，不能说明一切安好。 81) 增强自动化客观指标体系建设。 82) 质量在于团队协同，协同不好，再牛的人产出也低。 83) 关于软件质量，它是一个让人头疼又非常有趣的谈之不尽的话题。 84) 很多时候感觉自己很容易到了天花板，心力交瘁，无法入手，领导想重视但是没给 力支持。 85) 国内互联网企业竞争激烈，研发团队基本都是在做功能实现的事情，中间过程没有 质量保障的活动， 比如设计和代码评审、 单元测试等这些最基础的质量保障活动， 牺牲这些时间来追赶进度，尽快占领市场。大家都知道这是在饮鸩止渴，但项目太 多、老板不断施压，很难找到走出这个困局的办法。 22

23. 版权所有ã2021 86) 单元测试怎么落地，难啊！ ！ 87) 要质量没速度，要速度没质量。 88) 软件最终是交付给客户的，没有用户量没有兑「现」 ，都是无法体现软件质量的。 89) 因压缩资源成本，砍掉很多测试的工时，很难过。 90) 对于重灾区的团队，吹哨人会被干掉。 91) 公司不注重质量，只求快速出成品，测试孤独寂寞冷。 92) 企业高层对质量认识不足、理解有偏差，业界又缺乏质量实践经验分享和支撑，质 量工作很难开展。 93) 现在产品越来越追求快，质量技能却未跟进，测试很被动，干的越来越辛苦。 94) 敏捷开发，基础设施和服务要扎实，否则跑着跑着轮子都掉了，就别提敏捷了。 95) 感觉好难推动各个阶段的质量把控，好多环节如需求评审，形式大于效果。 96) 软件质量都认为重要， 但在进度等压力下又容易会被忽视，人们更容易关注带来短 期效益的直接指标而对改进质量带来的、缓慢的长期收益视而不见。 97) 软件质量靠的还是整体的构建， 单靠其中任何一个环节都是不行的。 吐槽的地方很 多，越来越快的迭代频率，越来越短的开发周期，总有更高优先级的需求插队。 98) 体制内单位的组织改进，需要自上而下，全方位的去改。因为企业文化的原因，导 致任何改变都无比艰难，牵一发而动全身。 99) 当前规范太杂乱，国标又很多不适用，要是有专业机构来牵头规范会好点。 100)质量很难，测试不易，且行且珍惜。 23

24. 版权所有ã2021 十、关于组织者 1.《软件质量报道》公众号 本公众号致力于健康、安全、绿色的软件生态，分享软件质量管理、软件测试的思 想、方法、技术与优秀实践，追踪软件质量领域的热点，及时报道软件质量管理的成功案 例或质量事故，以及分享深度思考、有温度的技术文章等，努力成为您工作中的朋友。 2. 腾讯 WeTest 腾讯 WeTest 是由腾讯官方推出的一站式品质开放平台。十余年品质管理经验，致力 于质量标准建设、产品质量提升。腾讯 WeTest 为移动开发者提供兼容性测试、云真机、性 能测试、安全防护、企鹅风讯（舆情分析）等优秀研发工具，为百余行业提供解决方案， 覆盖产品在研发、运营各阶段的测试需求，历经千款产品磨砺。金牌专家团队，通过 5 大 维度，41 项指标，360 度保障您的产品质量。 3. ThoughtWorks 社区 ThoughtWorks Community 由来自 ThoughtWorks 全球技术人才及创新爱好者发起并 组建，本着自由、开放、分享、互动的原则，由社区志愿者发起并组织多样化的技术主题 活动，希望以此分享洞见，带动行业及地区的整体技术能力，推动创新与 IT 变革。 24