软件工程第三次作业——关于软件质量保障初探

关于软件质量保障你的体会

1、 质量意识的培养

之所以把这点放在第一位，真的是人为这点是最重要也是最难做到的，可能你自己有质量意识，但是要让整个团队甚至整个公司都有质量意识还是非常难的，首先要建立大家共有的质量价值观，从企业文化中将质量意识植入人心，不然以中国人的“聪明”总是上有政策，下有对策。所以我认为意识和价值观的建立是一切的基础，有了共同的价值才能更好的执行规则。

2、 有清晰的质量目标和向导

有了意识，还需要有目标，要用清晰可见的目标来推动大家为质量负责，量化好什么样的代码是质量好的，比如每千行代码少于多少个bug，bug要根据影响划分出不同级别。质量一定要作为一个评价研发人员工作或绩效的重要因素。

3、 重要的地方请重要的人把关

假设你现在有一个10个普通级别的人的开发团队，我建议换成一个1个大牛级别+5个普通级别的团队，哪怕花5倍的工资请一个大牛，然后要他做核心的框架、系统设计、重点问题公关和保证其他人开发的质量把控。有些地方如果做的不好修改代价可能会比较小，比如某个程序写的不好，或某个独立的功能有问题，但是有的地方代价会很大，比如架构设计不合理，或系统设计有问题。而且如前言所说，软件开发越是靠前的步骤出问题，带来的代价就会越大，而且会大的明显。

4、 编程规范

这点刚工作的时候体会不深，随着工作的深入，体会越来越明显，大型软件的编写不是一个人的事，定位、修改问题，也不是只改自己的部分，我们甚至定位的大部分问题都是老版本和别人的问题，这个时候，如果大家没有一个统一格式的编程规范，就会很难读懂别人的逻辑，只能到处骂娘了。而且好的编程规范确实能让我们的程序可读性更好，更少的犯错误。

5、 管理好复杂度

人类在同时面临更多更复杂的东西的时候，往往就会显得更加吃力，也更容易犯错误。一开始部门老大给我们设定函数圈复杂度标准的时候，我也是有些不解，特别是修改别人圈复杂度很高的函数，有时候甚至是一种负担，但后来越发体会到，合理的复杂度确实能要我们少犯些错误，而且定位问题和走读代码也会更加清晰。代码大全的作者甚至认为软件的首要技术使命就是管理复杂度。

6、 测试甚至调试之前就要保证代码质量

不要过分的依赖测试，测试当然很重要，但这是保证我们质量的最后一道关口，代码大全的作者也认为测试不是改进质量的方法，要从代码源头进行把控，好的代码应该不需要调试或很少需要调试的。当然不需要代码的代码几乎是不存在的，但是意识上一定是要这样的。就好比找到初中那会儿做数学卷子的状态，交卷之前就要确保自己能得满分，这样成绩出来即使不是满分，成绩也应该不会差。

确保调试前就有高质量代码的一些手段：

(1) 使用静态检查工具，清除一切警告。

(2) 代码检视，这点是一定要做的。首先自检是必须要有的，然后互检也可以开展，对应风险需求，除此之外还可以会议集体检视。

7、 严格控制修改引入

对于大型软件项目来说，修改问题引入新问题是一件非常可怕的事，这样除了让你的团队有改不完的问题之外，还很容易把新引入的问题遗留到更后端，造成更大损失，所以修改问题一定要谨慎评估影响，有其他人把控检视，测试也要发散测试，总之修改引入是一件非常严重的事。

8、 改正bug定位根因，且举一反三

首先不能在没定位出根因的情况下去规避，因为这样不仅可能解决不了问题，还可能会带来更大的隐患。不能只改bug本身，要培养发起排查改进的习惯。

9、 测试都没有发现的问题一定要回溯

测试是质量的最后一道保障，如果测试都把问题遗漏了，一定要回溯，寻找遗漏原因，排查改进。

10、 构建自动化测试环境

这点不比多说，如果每天都有自动化在跑测试用例，起码一些基本的问题不会往后遗留，前面已经多次提到，越早发现问题，解决问题的代价就会越小。

11、 改进改进

再好的规则和团队都有不足，所以更好的办法就是与时俱进，实时改进，发现不足就及时总结改进，可以跌倒一次，但绝不在同一个地方跌倒两次。

QA的工作职责范围
概念上：
QA：Quality Assurance （质量保证）
定义上：
QA：为达到质量要求所采取的作业技术和活动
职责上：
QA：最重要的职责在于系统层面的完善，侧重于问题的防范及对已发生问题的根源的探究及其对策的实施，从而降低不良的产生

（3）：
企业不需要全职的QA，甚至不需要QA这一专职角色或部门。因为，不懂开发的人必然做不好测试，就像不懂开发的研发经理必然管不好研发团队一样
开发人员应该测试自己的代码。这没什么可说的。背后的道理并不重要。这包括单元测试，全覆盖的自动化测试、手工测试或组合测试等。如果你的开发人员不能、不愿意或认为这“不归我管”，那你需要更好的程序员。