让我们来谈谈统计吧 - 面向软件质量的统计入门(No.1 什么是统计?为什么软件质量需要它?)
Back to Top
为了覆盖更广泛的受众,这篇文章已从日语翻译而来。
您可以在这里找到原始版本。
引言
#某IT企业的某个部门。
部长(质量保证):“上次发布的时候,我感觉Bug特别多,这是怎么回事?”
开发负责人:“嗯……确实感觉有点多,这是我的印象。”
部长:“‘印象’啊……数据上是什么情况?”
开发负责人:“那个,嗯……”
部长:“还有,上个月新增的测试,见效了吗?缺陷减少了吗?”
成员:“从感觉上看似乎减少了……但不太确定……”
这样的对话,在IT企业的现场并不少见。
像这样用“感觉”或“可能”来谈论质量,是看不到真正问题的。
在影响项目质量的判断中,仅凭感性印象就可以了吗?
这时所需的就是“统计”。
统计,是一种将具有波动的现实以数值方式捕捉,并以此作为判断依据的工具。
“正确测量、可视化、思考”──这就是质量提升的第一步。
不过,一提到“统计”,很多人就会想起复杂的公式和图表而却步。
请放心。在本系列中,我们将从与软件开发和质量管理相关的人员可在实际工作中使用的视角出发,轻松地介绍统计思维。
首先,让我们一起从“统计究竟是什么?”的基本概念开始了解。
什么是统计?
#当听到“统计”一词,你会联想到什么?
是图表、平均、方差、正态分布……还是令人生畏的复杂公式?
然而,统计的本质其实非常简单。
“收集数据、整理数据、分析数据,并提取有意义信息的方法论”,这就是统计。
无论在日常生活还是工作中,我们都在不知不觉中做着“统计式判断”。
在日常生活中
- “这家咖啡店总是很挤,所以我们换个时间去吧”
- “最近感觉睡前看手机的时间变长了”
- “看样子要下雨了,出门带把伞吧”
这样的判断,是基于过去的经验和观察(即数据)来决定今后行动的例子。
也就是说,我们自然而然地在“从数据中读取趋势并做出决策”。
在工作中
- “这个月的评审指出数,好像比平时少?”
- “最近执行测试的时间似乎在延长……”
- “这项工作,B团队完成得似乎比A团队要快”
这些行为同样是在日常生活中,通过累积的数据来感知“变化”和“差异”并做出判断的行为。
也就是说,统计并不是“只有专家才能使用的困难技术”。
而是一种将我们已有的“直观数据利用能力”以更准确、更可靠的形式展现出来的技术。
在实际工作中,统计将成为支撑问题解决和决策的强大武器,具体表现在:
- 把握项目进度和质量趋势
- 及早察觉异常征兆
- 客观评估改进措施效果
- 向团队或客户进行让人信服的说明
“让看不见的事物变得可见”──
这正是统计的最大价值,并与质量提升和预防重发直接相关。
在下一节中,我们将探讨统计的核心概念——“描述性统计”和“推断性统计”之间的区别。
统计的两个支柱
#统计的世界主要由“两大支柱”构成。
即描述性统计(Descriptive Statistics)和推断性统计(Inferential Statistics,亦称推计统计)。
理解这两大支柱后,就能掌握“如何看待数据”“如何做出判断”的基本态度。
这两者从“如何处理手头数据”的角度划分出不同的角色。
描述性统计(Descriptive Statistics)
#描述性统计是对现有数据进行“整理”“概括”“可视化”的技术。
例如,以下处理即属于描述性统计:
- 计算平均值、中位数、众数等 代表值
- 计算标准差、方差、极差(范围)等 离散程度指标
- 使用直方图或箱线图等 可视化数据分布
示例:按周汇总缺陷工单数量,并用条形图查看趋势
描述性统计的优势在于,能够清晰地把握“当前状况”。
可立即用于项目进度确认、评审结果趋势分析、日报定量化等日常工作。
描述性统计的要义是“掌握现状的能力”
描述性统计正是为了“现在发生了什么?”的可视化而设计的技术。
例如,通过整理测试执行结果的通过率、缺陷发生的时机、代码评审的指出次数等,就能明确工序的瓶颈和稳定性。
- 代表值(平均值、中位数) → 缺陷发生的中心趋势
- 离散度(标准差) → 稳定性的波动
- 直方图或箱线图 → 分布形态及异常值检测
如果没有统计,这些往往只能停留在“感觉多/少”的印象评估。
使用描述性统计,就能以数值形式清晰地、有根据地说明。
推断性统计(Inferential Statistics)
#推断性统计是从“手头的一部分数据(样本)”推测“整体(总体)”特性的手法。
也就是基于有限的观测结果,推测不可见部分的技术。
主要包含以下分析:
- 置信区间:真平均值可能落在哪个范围
- 假设检验:能否说明改进措施的效果“非偶然”
示例:“在引入新的测试流程后,Bug数真的减少了吗?”
推断性统计的要义是“做出判断的能力”
推断性统计用于判断“这样就可以了吗?”、“变化是真实的吗?”。
例如:
- 新的评审指南后指出次数减少 → 这是否并非偶然?
- 看起来已达成质量目标 → 真在可信范围内吗?
要验证这些,就需要用从样本推测整体的方法=推断性统计。
置信区间、假设检验、p值等概念将在此发挥作用。
关于贝叶斯统计(Bayesian Statistics)
#在统计学中,实际上还有另一种思路,称为贝叶斯统计(Bayesian Statistics)。
它是一种在考虑观测数据的同时,加入“预先持有的知识(先验概率)”来进行推断的方法。
不过,从概率定义上看,贝叶斯统计是与之不同的“另一体系”,且应用较为专业。
在本系列中,首先将限定于“频率主义”统计,即描述性统计和推断性统计进行讲解。
关于贝叶斯统计,将在系列后半或番外篇中介绍。
软件质量与统计的关系
#质量具有“波动性”
#在软件开发现场,“质量”是每天都在变化的。
缺陷数量、发现时机、修复成本、测试通过率——没有任何一项是完全固定的。
这样的**“波动”正是质量风险的本质**。
若忽视这种波动,仅凭感觉来判断,会导致重大遗漏或判断失误。
因此,需要通过统计来“以数值捕捉并洞察趋势”。
将波动数值化、检测异常、保持流程稳定。
这正是统计在软件质量管理中的作用。
统计发挥作用的场景
#在软件开发中,统计可以在比想象中更多的场景下发挥作用。
描述性统计和推断性统计各司其职。
-
缺陷数量的趋势分析(描述性统计)
→ 汇总每周的Bug报告数量,把握每次发布的质量趋势 -
流程改进效果的验证(推断性统计)
→ 引入新的评审流程后,指出的问题数量是否减少?通过假设检验来判断 -
流程稳定性确认(描述性统计 + 管理图)
→ 使用X̄-R控制图监控测试通过率,及早检测异常信号 -
异常值的识别与原因分析(描述性统计)
→ 识别修复耗时异常的缺陷,并制定防止重发的对策 -
目标达成度的评估(推断性统计)
→ 针对“不良密度控制在0.8件/KLOC(※1)以下”的质量目标,统计地确认实际值是否在达成标准内
※1:KLOC(Kilo Lines of Code):在软件工程中用作规模(Size)、生产率、质量指标的单位。1 KLOC 表示 1,000 行源代码。
质量管理 = 统计的应用
#常说“质量是要精心打造的”。
但实际上,只有测量、观测并控制质量,才能保证质量。
统计质量管理(SQC)是在制造业中发展起来的。
但近年来,正是在像软件开发这样“难以目见的产品”领域,其意义被重新评估。
缺陷工单、评审记录、测试日志——我们已经被大量数据所包围。
将这些“当作数字来处理”,并用于改进,这才是统计的真正价值。
学习统计可以获得的能力
#统计不仅仅是分析工具。
对于质量经理和工程师来说,它也是获得以下能力的一种“思维技巧”:
-
不受直觉和偏见左右的 定量判断力
→ 不再是“感觉Bug少了”,而是“p值为0.01,显著减少” -
回答“为什么能这么说?”的 说明力
→ 能用客观依据说服团队、上司和客户 -
展示改进效果的 证明力
→ 能判断措施效果是“偶然”还是“实力” -
通过可视化的 可视化技能
→ 能制作用热力图和图表直观传达数据的资料
将统计思维掌握在手中,是从“依赖经验和直觉的现场”向“能用数据做判断的现场”演进。
而这也是**“能够自信地谈论质量的人才”的第一步**。
学习之后
#那么,开头中那段对话,发生了怎样的变化呢?
部长(质量保证):“上个月发布的版本,Bug的趋势如何?”
开发负责人:“是的,与上次相比,Bug数量从18件减少到11件。在95%置信区间内也显示出显著差异。”
部长:“原来如此,这说明新增测试的效果显现了吗?”
成员:“是的。引入后Bug密度从0.9降至0.5件/KLOC,通过假设检验也判定具有显著差异。”
部长:“不错。效果以数值形式展现,让人更安心。”
总结
#- 统计是从数据中“正确判断”的工具
- 通过区分使用描述性统计和推断性统计,可以改进实际工作
- 在软件质量领域,统计是不可或缺的技能
下次预告
#下次我们将以“如何面对数据”为主题,
详细解说定性/定量数据的区别、测量值及其误差、什么才是好数据。
希望对您在数据分析中有所帮助。