如何提升产品质量-开发维度

最近，咱们的产品上线了，上线以后，稳定是最重要的，可是，出现了几回bug，都是不该该犯的错误，因此，避免bug特别是重大bug出现，提升产品质量，很是迫切。

产品开发过程

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

能够看到，随着项目规模变大，架构、设计和集成测试、系统测试须要的时间会更多，而编码和开发者测试的时间更少。所以，提升效率最为明显的方法是提升产品质量， 减小测试、调试和修改所需时间。因此，设计、测试和编码一样重要，要分配更多时间，编码完 != 工做完成。

测试的重要

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

 

以微软和google为表明的保证产品质量的作法，都有道理，并且都是成功的。可是，我我的更倾向于full stack developer，第一，招不少SDET对大部分公司都不现实，合格的SDET薪资不会比SDE低;第二，我认为开发人员要对本身的开发的内容负责，主 动的想办法提升产品质量，而不是被动的等测试。

产品质量目标

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

集成测试

跟性能瓶颈同样，80%的错误每每出如今20%的代码中。大部分错误都是低级错误，好比，对需求或设计的误解、书写错误、赋值语句、边界错误或循环错误。大多数错误是容易改正的。另外，warning是不少错误的根源，因此工程里要禁止warning。

发现错误

主要经过检查和测试。检查包括：需求检查、设计检查、代码详查，测试包括：单元测试、集成测试、系统测试等。

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

检查

阅读代码要比测试平均每小时多发现80%多的错误，代码检查和测试所得到的收效之比为8:1。这是由于，错误越早发现，解决成本越低。

检查方法：协同编程，详查需求、设计、代码。不只仅是检查，要提早思考怎么作?带着思考检查。

单元测试

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

2. 数据流测试，避免重复初始化、重复销毁、定义不使用、未初始化使用等状况，检测数据流变化。

3. 错误猜想：

1). 边界分析，>=与>的区别，null、size是0的状况，好比测试小于MAX，三种边界状况MAX，10000个好友/道具的时候会不会致使游戏卡死?

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

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

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

集成测试

在单元测试的基础上，将全部模块按照设计要求组装成为子系统或系统，进行集成测试。

执行方案

综合考，制定“详查+单元测试+集成测试+系统测试”的方案，来提升咱们的产品质量。有些方法，好比协同编程、净室开发，虽然很好，可是对于咱们的团队来讲，执行起来太难。

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

单元测试：重点是理清流程，针对每一个流程都测试到。集成测试：把单元测试的功能组合起来测试，侧重于模块的总体性。系统测试：有点像QA的广泛工做，从功能上测试，各个需求点是否都正常。

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