谈如何提高产品质量

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

最近,我们的产品上线了,上线之后,稳定是最重要的,但是,出现了几次bug,都是不应该犯的错误,所以,避免bug特别是重大bug出现,提高产品质量,非常迫切。为此,我花了几天时间,翻一些资料来系统地学习,此文是学习的总结。

zhiliang产品开发过程

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

zhiliang2

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

测试的重要

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

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

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

以微软和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,要兼容这些玩家。

集成测试

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

执行方案

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

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

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

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

来源:PMTOO

您的赞赏,是对我创作的最大鼓励。

评论( 0

登录后参与评论
加载中