软件质量控制问题与质量控制技术

相信搞软件的平时听的最多的就是你们的产品质量不好，你的代码质量差，缺陷多。那么凭什么说我的质量不行呢？往往就是通过代码缺陷率来作为参考的依据。缺陷率一般指的是1000行代码有多少个bug。那么bug怎么算呢？测试说了算呗。开玩笑的，他给你提了问题单而你认了，那就算了。问题单的严重程度不一样，分提示、一般、严重和致命，然后有个加权算法，比如提示按0.1算，一般按1算，最后得到一个缺陷值。

那么再问一句，凭什么测试说是问题你就得认？那肯定得有你认同或者抵赖不了的东西是吧，这个往往就是设计方案、需求文档了。这两个东西相当于开发和测试都承认的合同了，两边都按这个合同来核对，对不上那只能自认倒霉。那要是合同本身有问题呢？找写合同的人呗，给他提单。测试可以给架构师提单，但给客户提单的是产品经理或者项目经理，由他们去跟客户沟通并发起需求变更。
1.最终产品的质量需求是什么？
①内部质量的评估准则
②外部质量的评估准则
③使用质量的评估准则
2.选择什么样的开发组织？
团队中的技术人员
在开发app的过程中技术人员是非常重要的，团队的技术人员水平高低直接决定了开发出来app的质量高低。
后期的服务
app开发的工作在开发完成之后并不是就全部完成了，在完成app开发以后还涉及到app的更新等等方面，如果选择了后期团队完善的公司那么服务也会更好一些。
开发团队的技术能力
不同的行业导致app有各种各样的类型，很多企业对于app开发的要求也会高一些，在开发的过程中，每个不同的app开发团队也有属于自己的特色，对于app开发公司的考察因素主要包括企业的服务周期、后期代码的更新优化水平以及ui的开发设计等等。所以，一个app开发团队的技术能力，直接决定了app开发完成以后的结果。
3.为预防软件质量缺陷应该做点什么？
常见的方法就是评审、重构、复用以及原因分析。
评审
评审是很常见的一种验证手段。虽然普通，但它的作用可不小。
软件缺陷很大一部分是来自于对需求的定义和理解不正确。而如果你能做好需求评审，可以很大程度地减少这部分缺陷。
同样的，设计评审可以很大程度上减少设计缺陷。
在软件实现之前，评审是最有效地去除缺陷的手段，而越早去除这些潜在的缺陷，所需的代价也会越小。
评审是一种缺陷去除手段，在这里说是缺陷预防方法，是站在代码的角度来说的，因为这时代码还没有生成，评审去除的缺陷就像是预防了在代码中生成缺陷。
重构
当开始代码实现之后，程序员会发现随着对业务需求更深入的理解，代码的结构可能会变得不合时宜；或者代码的结构有些臃肿，有了“坏味道”，这时就需要对代码进行重构。
因为重构是在测试之前，程序员主动地重构，就会预防因为代码变坏而产生更多的缺陷。
复用
软件复用的前提，是已经有了经过验证和确认正确的可复用的构件。如果软件都是由这些构件组成的，那么这些功能模块本身是没有缺陷的，从而就会使集成起来的软件的缺陷也大大降低。
对于复用来说，困难的是持续不断地推进复用的策略，不断丰富组织的可复用构件库。
原因分析
原因分析是解决问题的一种通用方法。
对于软件开发来说，把软件研制过程中发现的问题进行统计分析，找出问题产生的根本原因，制定出对应的纠正措施，可以使新开发的软件避免出现重复的问题。
我们应当要求所有新开发的软件在开发之前先去查找同类软件之前发生过的问题，对应的解决措施，在软件设计和实现时，吸取教训，完善设计，以达到预防缺陷的目的。
4.怎样检查软件质量？
首先，质量是个很大的概念，本质是一种主观感受。我们通常所指的狭义质量为可靠性，软件的可靠性可以通过线上bug数来衡量（或者数量的变化趋势）。 更加准确的计算为线上bug数/开发中的bug数。
这个指标是量化可靠性的其中一种理论，由于业界本身对于软件质量的度量还没有统一的结论，我们可以采用这个值作为相对值进行对比。例如当比率很大时，可靠性质量很不好。
还有一个评估方法是工业界的的质量体系。也就是说，你的开发流程需要符合一定的标准，我就认为你的质量是有保证的。但是这个方式比较复杂而且不好量化
线上bug数属于简单粗暴型，用比例会准确一下是因为产品的规模不同，线上bug数是不同的。
5.在检查点应该获得哪些信息？
检查点记录是一类新的日志记录。它的获得信息包括：
①建立检查点时刻所有正在执行的事务清单
②这些事务的最近一个日志记录的地址。