软件工程第三次作业——关于软件质量保障初探
（1）对教材与参考资料阅读后关于软件质量保障你的体会是什么？
1、软件工程的质量体现在那些方面？
从书中了解到的有以下几个方面：
- 软件开发过程的可见性
- 软件开发过程的风险控制
- 软件内部模块，项目中间阶段的交付质量，项目管理工具的因素
- 软件开发成本的控制
- 内部质量指标的完成情况
2、QA和Test的区别与联系
书中了解到内容如下：
二者区别：
软件测试（Test）：运用一定的流程和工具，验证软件能实现预先设计的功能和特性，工作的流程和结果通常是可量化的。也正因如此，很多测试工作是可以自动化的。
软件质量保障工作（Quality Assurance）：软件团队为了让软件达到事先定义的质量标准而进行的所有活动。
二者联系：软件质量保障工作包括测试工作。
3、如何衡量软件工程的质量
通过邹欣老师的博客我了解到的内容下：
在本书开头我们讲了如何证明自己做好了软件工程：
- 研发出符合用户需求的软件
- 通过一定的软件流程，在预计的时间内发布 “足够好” 的软件
- 并通过数据和其他方式展现所开发的软件是可以维护和继续发展的
常用的量化标准如下：
- 软件 CC 后 DCR 的数量
- 用户的好评/差评 （例如AppStore 的5星级评价）
- 在CC 后发现的bug 的数量
- 文档的完备性和准确性 （用百分率表示）
- 修复 bug 所需的平均时间
- 单位开发量（人*月）出现的重大 bug 的数量
- 测试用例的覆盖率
- 模块的复杂程度 （用工具检测并有量化结果）
- 代码的行数
- 文档的数量和复杂程度
- 有多少代码被重用了
- 平均每天构建失败的次数
- 软件实现了多少功能点
- 软件能运行多久， 平均初次错误时间 （mean time to failure) 平均无故障时间 (mean time between failure)...
团队可以选取 7 个指标 （包括自己想出的指标），然后在项目中计算这些指标并跟踪。
有一套比较成熟的理论是CMMI（全称Capacity Maturity Model Integrated，能力成熟度模型集成），它有以下几个等级衡量软件工程的质量：
- 一级，初始级
- 二级，管理级
- 三级，明确级
- 四级，量化管理级
- 五级，优化级
（2）如果你是一个项目的QA，那么你认为你的工作职责范围是什么？
1. 制定和完善项目开发过程中的各项工作流程和规范。
2. 监督项目过程按照既定的工作流程与规范执行。
3. 对项目进行中产出的各项文档进行评估。
4. 保证文档与工作进程的一致性。
5. 与PM沟通，共同推动项目进行。
6. 评估需求文档，规则文档，设计文档和测试用例。
7. 评估需求分析过程所产出的各项设计文档。
8. 监督在开发过程中，各小组按组内规范进行工作，有组间交互的任务需按组间交互规范去完成。检查设计文档是否与程序源码一致，这些期间QA按工作流程规范监督各项工作任务的进行。和PM及时沟通共同推动项目的进行。
9. 评估视觉设计的工作规范。
10. 评估发布文档。
11. 对新来的人员作流程和规范方面的培训。
（3）如果你是一个项目经理，那么你认为这你的项目中需要专职的QA么？还是只需有Test即可？如果一旦出现问题，你如何界定由谁担责？
通过阅读书和参考资料我了解到对于项目中是否需要专职的QA有很大的争议的，在陈皓的文章中以他实战经验说明了一下他自己的观点，他就认为不需要全职的QA的，甚至不需要QA这一专职角色或部门，因为，不懂开发的人必然做不好测试。就像不懂开发的研发经理必然管不好研发团队一样。我觉得其实说的还挺有道理的，但是他的观点未免有点太极端了。但是在书中邹欣老师的观点就很中规中矩，邹老师将来Dev要懂测试，QA摇动开发，只是分工不同。这句话我觉得非常有道理，既然你负责管理的是这一部分的东西，你怎么能不懂呢，那怎么有资格跟专业人士讨论呢。
所以如果我是项目经理的话，在我的项目中需要QA，但是不需要专职的QA，这样的话就需要与Test打好配合，两者不分彼此但是一定要分工明确，不然一旦出现问题的话，就没办法找出直接负责人，可能造成推卸责任的现象。
邹老师在书中还举了许多因为分工不好，造成一些不好的问题，比如画地为牢的分工，无明确责任分工，为了自己的角色而做绩效优化等，这些问题都直接命中了分工的要害。
因此只要找到合适的分工方法，那么一旦出现问题的话，就有了界定的依据，就在一定程度上避免了一些推卸责任的现象出现。
浙公网安备 33010602011771号