作者：非妃是公主
专栏：《软件工程》
个性签：顺境不惰，逆境不馁，以心制境，万事可成。——曾国藩
专栏地址
专栏系列文章
1.软件工程的质量体现在哪些方面
我们知道：
- 软件 = 程序 + 软件工程
- 那么我们可以套用这个公式，看看“程序的质量”和“软件工程的质量”如何影响软件的质量。
- 就像下面这个公式： 软件质量 = 程序质量 + 软件工程质量
- 程序的质量体现在软件外在功能的质量。
- 衡量软件的功能， 功能测试，基本的判断可以用“是| 否”来 判定， 例如，一个字处理软件能否通过拷贝/ 粘贴与其他软件传递信息。
- 多维度特性的综合指标来衡量， 例如，衡量一个搜索引擎的质量，业界通常用准确度 （Precision）和覆盖率（Recall）的综合指标来表示。
- 服务质量，例如， 网站显示查询结果的速度；订票网站能并发处理业务的吞吐量；支持同时在线用户的数量。
- 程序的质量还有其他方面，例如用户体验的质量、国际化的质量和安全性的质量。我们还可以用其他数值来表示质量，如NPS（Net Promoter Score）。
- 软件工程的质量体现在
- 开发过程的可见性
- 开发过程的风险控制
- 内部模块的交付质量
- 开发成本的控制
- 内部质量指标的完成情况
2.根据燃尽图（或类似的图）能够说明软件过程中出现的问题
燃尽图1:正常的 未解决/解决/关闭 的比例
燃尽图2:什么地方资源不够?
描述：Bulge in work in process (i.e. in testing) indicates inadequate resources or inadequate incoming quality.
在制品（即测试中）激增表明资源不足（测试人员不够）或进货质量（开发人员编写代码质量）不高。
燃尽图3:低估了项目的难度/Underestimating
- 描述：
- Slow progress leading to cuts in planned work,but not enough cuts.（进展缓慢，导致计划中的工作被削减，但削减得不够多。）
- Steady rates of progress, but slope too shallow.(进展速度稳定，但坡度太浅。)
燃尽图4:Inadequate Allotment(拨款不足)
- 描述：
- New work not planned at iteration start.(迭代开始时没有计划的新工作。)
燃尽图5:Scope Creep(范围蠕变)
- 描述：
- “Dark matter” emerging during iteration （暗物质激增）
- Planned work is squeezed out （原有计划被挤掉）
燃尽图6:A real example
3.了解用户代替测试的问题
曾经有一个大型团队开发客户端软件，他们进行了改革，去掉了测试 （Test）这个角色,原来测试的人员或者离职，或者做收集用户数据的工作。
领导设计了下面的“更好的计划”：所有开发人员都做测试一个新功能从开发的各个发布圈子到外部，有严格的使用时间/bug 标准，达不到标准，就不能发到下一个版本。
所有的功能都有一个 “开/关”，新功能只有在“开” 的情况下才有。默认一个新功能是“关”的，开发一个新的工具去管理这个渐进发布的开关在各级发布圈子的开关情况。
- 说明：
开：可以使用新功能
关：不能使用新功能
给用户可选择的权利，在各个社区里面进行测试，必须达到一定的使用时间/bug 标准，才可以发布下一个版本。
- 愿望是良好的，但是在实践中有下面问题：
- 1） 没有测试，就没有人给第一时间的反馈，特别是各种非主流配置下的非主流使用场景。例如， 我们想测试各个模块如何处理闰年的2月 29号（或者闰年的最后一天），我们要等到实际闰年的时候， 才能让用户帮我们测试么？
- 2） 严格的时间标准听起来很好，但是这个时间是某个版本在某个目标用户手上的时间，这些目标 用户都有自己的日常工作要求，不会像测试人员那样去全面和深入测试，更没有任何动力去整天测试。
- 3）如果有专职测试，他们就可以在较短时间内完整测试，给出有信心的 “go/no go” 判断。而不是 要等一帮dogfood 用户N 天的使用。这个规定比较僵化，不能处理一些比较紧急的情况，例如， 需要3 周就上线，但是规定要求必须走两个环，每个环要强制4 周的使用时间。
- 4）用户报告的Bug 很多， 很多开发人员在自己的机器上试了一试，发现无法重现，于是就标上 “无法重现”(not reproducible)，就把这个Bug 关闭了。岂不知这个在用户的环境中是的确发生了 的！但是没有专业测试团队试图重现这个环境，开发人员只有有限的配置（而且从处理器，内存， 网速，都是高端，干净的配置），也没有精力和动力去找到如何能重现这个Bug的环境。 “快速重现用户报过的Bug”这是专业测试人员的价值所在。没有测试人员之后，开发人员并没有 负责这个新的任务，他们的主要目标还是“快速开发功能”。
- 5） 针对这些 Bug的修复也要一级一级地发出去，增加很多成本。
- 6） 质量控制的核心是：尽早，高效地找到Bug，一个专职的测试团队就能做到这些。全部依赖于社区，会出现很多副作用。还是那句话，没有责任，就没有质量。
-
完美的情况:
- 问：但是这样的安排，如果每一个环节都正确发挥作用，那是多美妙啊！
- 答：当然，项目管理要讲究风险管理，这么多环节中，如果有一个环节是不受这个团队控制的，这个环节可能会给产品质量带来很大的破坏，那还不如自己来控制。
-
自己控制： 开发团队 <–> 测试团队 （测试团队可以马上提供反馈）
-
不受控制： 开发团队 –> 发布团队 –>普通用户 –> 通过实际使用送回反馈 –>软件工具收集并展现问题（不受自己控制的环节太多）
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/130556.html
