如何提高产品质量？（提高产品质量的总结大全）

最(zui)近，何提我(wo)们的高产高产产品上线了，上线之后，品质品质稳定(ding)是量提量最重要的(de)，但是(shi)总结，出现了几次bug，大全都是何提不(bu)应(ying)该犯的错误，所以，高产高产避免bug特别是品质(zhi)品质重大bug出(chu)现，提高产品质(zhi)量，量提(ti)量(liang)非常(chang)迫切。总结(jie)为此，大(da)全我花了几天时间，何提翻一些资料来系(xi)统地学(xue)习，高产高产此文是品质品质学习的总结。

产品开发过程

产品开发过程：需求分析、设计、编码、单元测试(shi)、集成测试、功能测试、Beta测试和发布。在工程师开发之前，策划或(huo)产品提过来的需求、策划的配置文件或(huo)者后期的测试，都(dou)可能影响产品质量，但是，本文侧重于从开发者角度谈提高产品质量。先分享一张来自《Code Complete》的插图。

可以看到，随着项目规模变大，架构、设计(ji)和集成测试、系统测试需要(yao)的时间会(hui)更多(duo)，而编码和开(kai)发者(zhe)测试的时间更少。因此，提高效率最为明显的方法是提高产品质量， 减少测试(shi)、调试和修改所需时间。所以，设计、测试和编码同样重要(yao)，要分配更多时间，编码完 != 工作完成。

测试的重要

在很多大一些的IT公司，比如微软，开发职位叫Software Development Engineer，SDE，软件开发工程师;测试(shi)职位叫Software Development Engineer in Test，SDET，软件测试开发工程师，可见测试人员本质还是开发工(gong)程师。这有别于我们在公司里(li)常常见到的QA，我是做游戏的，我见到的QA都是打开游戏，然后(hou)点点点，从(cong)表现上测试功能是否正常，这(zhe)样测试是无法全面测试的，这也难怪在很(hen)多公司里QA比开发团队地位低。我(wo)觉得，对于测试这个职位(wei)，要做好(hao)，是很难的(de)。他要能读懂策划文档和开发(fa)文(wen)档，从源头(tou)上开始着手。如果白盒测试，要能看懂别人写的代码;如果黑盒测试，要和开发人员多沟通，画出来实现的流程图，并且分析网络协议;然后(hou)，设计完备的测试用例。如果不根据需求、设计和实现，设计完备的测试流程，而只是操作一下试试功能是否正常，很多隐藏的bug是测试不出(chu)来的。

在传统软件行业：软件的质量和稳定最重要(yao)，代表企业：IBM、微软、思科等。根(gen)据我查到的资(zi)料，开发与测试人员比(bi)例，微软1:1，思科1:1.5，普遍在1:1 – 3:1。SDET从需求文档、设计文档开始Review，SDE编码，SDET写测试用例，跟极限编程的过程类似。极限编程的基本过程：构思 -> 编写测试代码 -> 编写代码 -> 测试，编写测试和(he)编写代码都是增量式的，写一点测一点，在编写以后的代码中如果发(fa)现问题可以较快的追踪到问题的原因(yin)，减小回归错误的纠错难度。

而互联网行业(ye)：快很重要，有bug在线上也方便修改发布，更提倡full stack developer，代表企业：amazon、facebook、google等。开发(fa)与测试人(ren)员比例，google 10:1， MySpace 5:1。阿里(li)资深专家，amazon前高级经理，陈皓认为(wei)：并不是互联网公司认为测试不重要，而(er)是他们认为正因为(wei)测试很重要，所以才不应该交给只做测试的人，开(kai)发人员(yuan)要对自己开发的(de)产品质量负责。对于(yu)一个公司，“产出性”的人应该多于“支(zhi)持性(xing)”的人。当你的条件受限人手不够的时候，你必然不能干所有的事，但你要去做很多(duo)自动化的事情，不管是(shi)自(zi)动化(hua)部署还是自动化运维。然而当你的人多的时候，你必然只会简单用人来解决问题。劳动(dong)密集型(xing)与知识密集型的公司差别就在这里。

产品质量目标

评估产品质量，常用的是(shi)千行(xing)代码缺陷率，以下是查到的一些业界的千行代码缺陷率数据。典型的统计表明，在开(kai)发阶段，平均50~60个，交(jiao)付后15~18个;微软内部测试(shi)的产品10-20个(ge)，正(zheng)式发布产品0.5个;某外包公(gong)司，A级≤ 0.5个，B级≤1个，C级≤5个;航天飞机的软件，0个/50万行。缺陷率做到平(ping)均水平的(de)1/10是很(hen)少见的，而如果10倍以上，产品可能(neng)永远也不会完工。

跟性能瓶颈一样，80%的(de)错误往往出(chu)现在20%的代码中。大部分错误都是低级错误，比如，对需求或设计的误解、书写错误、赋值语句、边界错误或循环错误。大多数(shu)错误是容易改正的(de)。另外，warning是很多错误的根源，所以工程里要禁止warning。

发现错误

有统计数据表明：单元测试的平均错误检出率是25%，集成测试35%，小规模Beta测试35%，系统测试45%。而对设计和代码进行详查的错误检出率分别(bie)是(shi)55%和60%。

检查

检查方法：协同编程，详查需求、设计(ji)、代码。不仅仅是(shi)检查，要提前思考怎么做?带着思考检查。

单元测试

1. 基于结构的(de)测试。测试用例要覆盖每一条控制(zhi)语句，if for while and or switch case等。

2. 数据流测试，避免重复初始化、重复销毁、定义不使用、未初始化(hua)使(shi)用等情况，检测数据(ju)流(liu)变化。

3. 错误猜测：

2). 复合边界，int add(int a, int b)，a和b都小于2^31，但是，如果a和b都很大，它们的和会不(bu)会出界?

3). 坏数据，太小/大的数据，未初始化的数据(ju)，错误类型的数据，错误长度的数据等。

4). 向前兼容和向后兼容。比如，游戏最新版本是2.5，但(dan)是有的玩家一直不更新，还是1.0，要兼容这些玩家。

集成测试

在单元测试(shi)的基础上，将所有模块按照设计要求组装成为(wei)子系统或系统，进(jin)行集成测试。

执行方案

综合考虑我们团队(dui)的实际情况，最后我(wo)制定了“详查+单元测试+集(ji)成测试+系统测试”的方案，来提高我们的产品质量。有些方法，比如协同编程、净室开发(fa)，虽然很好，但是对于(yu)我们的团(tuan)队来说，执行起来太难。ps：我对净室开发很感兴趣，正在研究，研究透以后可能会试(shi)着采用。

详查：先自己详查，从需求开始，然后是设计和编码;然后，团(tuan)队中的(de)小伙伴互查。关于详查，有两点需要注意：1. 检查前(qian)，要先制定代码规范，让开发人员不把精力耗在代码规范的争执上(shang)。2. 详查结果不作(zuo)为员工表现的考核标准，考核应该基于最终的产品。

单元测试：重点是理清流程，针对每个流程都测试到。集(ji)成测试：把单元测试的功能组合(he)起来测试，侧重于模块的整体(ti)性。系统(tong)测试：有点像QA的普遍工作，从功能上测试，各个需求点(dian)是否都正常。

执行：我首先(xian)制定了代码规范，并给大家讲解，然(ran)后征求大(da)家的意见统一。然后，写了一份本文章的内部版本，并给大家详细讲解(为了(le)让小伙伴们更容易，内部版本细节比较丰富，举了一些(xie)例子，写的比较啰嗦，稍微精简、加(jia)工之后，形成了这篇blog)。另外，需要注意，详查结果不要(yao)作为员工表现的(de)考核标准，考核应该基于最终的产品。