谈如何提高产品质量

　　最近，我们的产品上线了，上线之后，稳定是最重要的，但是，出现了几次bug，都是不应该犯的错误，所以，避免bug特别是重大bug出现，提高产品质量，非常迫切。为此，我花了几天时间，翻一些资料来系统地学习，此文是学习的总结。
　　产品开发过程：需求分析、设计、编码、单元测试、集成测试、功能测试、Beta测试和发布。在工程师开发之前，策划或产品提过来的需求、策划的配置文件或者后期的测试，都可能影响产品质量，但是，本文侧重于从开发者角度谈提高产品质量。先分享一张来自《CodeComplete》的插图。
　　可以看到，随着项目规模变大，架构、设计和集成测试、系统测试需要的时间会更多，而编码和开发者测试的时间更少。因此，提高效率最为明显的方法是提高产品质量，减少测试、调试和修改所需时间。所以，设计、测试和编码同样重要，要分配更多时间，编码完！工作完成。
　　测试的重要
　　在很多大一些的IT公司，比如微软，开发职位叫SoftwareDevelopmentEngineer，SDE，软件开发工程师；测试职位叫SoftwareDevelopmentEngineerinTest，SDET，软件测试开发工程师，可见测试人员本质还是开发工程师。这有别于我们在公司里常常见到的QA，我是做游戏的，我见到的QA都是打开游戏，然后点点点，从表现上测试功能是否正常，这样测试是无法全面测试的，这也难怪在很多公司里QA比开发团队地位低。我觉得，对于测试这个职位，要做好，是很难的。他要能读懂策划文档和开发文档，从源头上开始着手。如果白盒测试，要能看懂别人写的代码；如果黑盒测试，要和开发人员多沟通，画出来实现的流程图，并且分析网络协议；然后，设计完备的测试用例。如果不根据需求、设计和实现，设计完备的测试流程，而只是操作一下试试功能是否正常，很多隐藏的bug是测试不出来的。
　　在传统软件行业：软件的质量和稳定最重要，代表企业：IBM、微软、思科等。根据我查到的资料，开发与测试人员比例，微软1：1，思科1：1。5，普遍在1：13：1。SDET从需求文档、设计文档开始Review，SDE编码，SDET写测试用例，跟极限编程的过程类似。极限编程的基本过程：构思amp；gt；编写测试代码amp；gt；编写代码amp；gt；测试，编写测试和编写代码都是增量式的，写一点测一点，在编写以后的代码中如果发现问题可以较快的追踪到问题的原因，减小回归错误的纠错难度。
　　而互联网行业：快很重要，有bug在线上也方便修改发布，更提倡fullstackdeveloper，代表企业：amazon、facebook、google等。开发与测试人员比例，google10：1，MySpace5：1。阿里资深专家，amazon前高级经理，陈皓认为：并不是互联网公司认为测试不重要，而是他们认为正因为测试很重要，所以才不应该交给只做测试的人，开发人员要对自己开发的产品质量负责。对于一个公司，产出性的人应该多于支持性的人。当你的条件受限人手不够的时候，你必然不能干所有的事，但你要去做很多自动化的事情，不管是自动化部署还是自动化运维。然而当你的人多的时候，你必然只会简单用人来解决问题。劳动密集型与知识密集型的公司差别就在这里。
　　以微软和google为代表的保证产品质量的做法，都有道理，而且都是成功的。但是，我个人更倾向于fullstackdeveloper，第一，招很多SDET对大部分公司都不现实，合格的SDET薪资不会比SDE低；第二，我认为开发人员要对自己的开发的内容负责，主动的想办法提高产品质量，而不是被动的等测试。
　　产品质量目标
　　评估产品质量，常用的是千行代码缺陷率，以下是查到的一些业界的千行代码缺陷率数据。典型的统计表明，在开发阶段，平均5060个，交付后1518个；微软内部测试的产品1020个，正式发布产品0。5个；某外包公司，A级0。5个，B级1个，C级5个；航天飞机的软件，0个50万行。缺陷率做到平均水平的110是很少见的，而如果10倍以上，产品可能永远也不会完工。
　　跟性能瓶颈一样，80的错误往往出现在20的代码中。大部分错误都是低级错误，比如，对需求或设计的误解、书写错误、赋值语句、边界错误或循环错误。大多数错误是容易改正的。另外，warning是很多错误的根源，所以工程里要禁止warning。
　　发现错误
　　主要通过检查和测试。检查包括：需求检查、设计检查、代码详查，测试包括：单元测试、集成测试、系统测试等。
　　有统计数据表明：单元测试的平均错误检出率是25，集成测试35，小规模Beta测试35，系统测试45。而对设计和代码进行详查的错误检出率分别是55和60。
　　检查
　　阅读代码要比测试平均每小时多发现80多的错误，代码检查和测试所获得的收效之比为8：1。这是因为，错误越早发现，解决成本越低。
　　检查方法：协同编程，详查需求、设计、代码。不仅仅是检查，要提前思考怎么做？带着思考检查。
　　单元测试
　　1。基于结构的测试。测试用例要覆盖每一条控制语句，ifforwhileandorswitchcase等。
　　2。数据流测试，避免重复初始化、重复销毁、定义不使用、未初始化使用等情况，检测数据流变化。
　　3。错误猜测：
　　1）。边界分析，amp；gt；与amp；gt；的区别，null、size是0的情况，比如测试小于MAX，三种边界情况MAX，10000个好友道具的时候会不会导致游戏卡死？
　　2）。复合边界，intadd（inta，intb），a和b都小于231，但是，如果a和b都很大，它们的和会不会出界？
　　3）。坏数据，太小大的数据，未初始化的数据，错误类型的数据，错误长度的数据等。
　　4）。向前兼容和向后兼容。比如，游戏最新版本是2。5，但是有的玩家一直不更新，还是1。0，要兼容这些玩家。
　　集成测试
　　在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统，进行集成测试。
　　执行方案
　　综合考虑我们团队的实际情况，最后我制定了详查单元测试集成测试系统测试的方案，来提高我们的产品质量。有些方法，比如协同编程、净室开发，虽然很好，但是对于我们的团队来说，执行起来太难。ps：我对净室开发很感兴趣，正在研究，研究透以后可能会试着采用。