关于开发过程中如何提高项目质量的一些浅识

  随着计算机技术的发展，互联网产品日益增多。相似功能的产品也多如牛毛，产品之间的竞争日益剧烈。一个优秀的产品如何从众多产品中脱颖而出，迅速占据市场，夺取用户量呢？除了产品自身的特点之外，还有一个重要影响因素，即快速迭代-不断完善产品，吸引用户。如何在保证产品质量的前提下，又要按时上线迭代功能？毫无疑问这个重任就落在了技术团队的身上。

   开发同学说：

   俺们的任务就是根据需求尽快用代码实现功能，然后提测版本，保证产品按时上线。

开发将版本提测后，毫无疑问重任就到了QA肩上。

   QA同学说：

   俺们的职责是根据需求设计测试用例，然后执行测试用例验证提测版本是否存在bug，保证产品的质量。

   通过“他们说”不可否认开发和QA同学之间存在”矛盾”，可能开发同学说QA是专门来找茬的，其实也可以这样说，即开发同学希望在规定的提测期限前完成开发任务，这样难以避免的会在开发过程中忽略一些问题，比如交互稿中的隐藏需求，异常情况的处理等等。提测版本难以避免的出现较多bug，尤为严重的是功能逻辑性的bug。而QA同学的任务就是找出这些bug，然后让对应的开发去修改，这可不就是“找茬”嘛，但QA的找茬是褒义的找茬，为什么这么说呢？因为虽然开发和QA来自不同的组，但为了一个共同目标走到一起——即保证项目质量按时上线。

   QA同学在测试迭代过程中会发现bug，然后根据以下流程：

         

为什么需要模块回归，当然是防止开发改出其它bug，虽然说这话有点伤人，但实时如此（记的不要告诉开发同学哦）。可以看出bug解决的流程较长，时间成本较大，更可怕的是如果提测版本中存在的逻辑性bug较多，可能QA的测试之路就比较曲折。

   QA同学大多数情况下会这样抱怨：

   这么严重的bug在开发过程中都没有发现....此处省略很多字。

   开发同学当然也很苦，会说：宝宝心里也很苦，可是宝宝不说。

   在测试过程中，可能会出现下面的场景，QA同学发现一个较为严重的缺陷，bug提过去，开发同学CodeReview，很容易的发现代码中存在的问题，他们也会感慨的说当时怎么是这样设计的，这样设计不好呀，不容易扩展、维护成本高、当初的设计方案有问题等等。QA同学听到开发这样说，心里有苦也不说，因为已经提测了，开发的责任应该算是也告一段落。开发同学本着追求“完美”的心态准备大干一场，去完善自己实现的代码。开发可能会在修复bug的同时优化设计、代码重构等等，这样造成的坑就比较大、比较多、比较深、比较难填，反正你们是懂的，带给QA可怕的后果就是导致回归量大、前期准备数据无效、测试周期延长。

   互联网产品的一个特性就是快速迭代，开发提测后往往会开始下迭代的任务，导致就无法专注的修复提测版本的bug。最终的结果就是延期上线。锅就大家一起背了。

   如何在开发过程中尽早的发现易错点，防止将bug带到提测版本，如何保证开发同学在有限的时间内，实现更完美的功能呢？这也是QA的一个重要任务，因为大家的目标只有一个，就是保证产品质量的前提下，使产品按时上线。

   在开发过程中如何提高项目质量，首先需要分析下项目在开发过程中那些点易产生bug，经过本菜鸟深思熟虑一番，想到了以下几点（当然不全也可能不正确，因为是菜鸟嘛，以后会不断修正和完善的）

1）需求逻辑功能复杂，开发在有限的时间挖掘交互稿深度不够，考虑不周全，导致部分功能没有实现或逻辑实现有误。

2）输入边界值的情况。

3)优化迭代任务中的功能点，优化迭代往往没有复杂的业务逻辑，开发同学在开发过程中容易忽略一些细小的优化点（主要的优化功能）。

4)交互稿中隐藏的细节点，交互稿有些细节的功能点并没有标注，开发同学在开发过程中将其忽略。

5)功能模块间存在依赖关系，不同开发同学开发的功能模块存在依赖，单独实现时可能不会发现问题，系统性的执行时就会暴露出缺陷。

6）前后端接口字段没有提前约定，导致字段不一致。

...

此处省略若干点，留作以后扩展.....

   貌似听说过“QA发现bug多不能证明你牛逼，只能说明开发写的代码太烂了”。初次听到这句话感觉说的毫无道理，QA发现bug多不是说明设计的用例好吗？为什么不能证明QA牛逼呢？现在貌似明白了，不知道正确不正确，说下我的浅见吧，站在Boss的角度，他的目的只有一个——产品能够高质量按时上线，无可厚非，这也是Boss发我们工资的目的。由此可知QA的任务不是去发现提测版本的bug，而是应该尽早进入开发流程，和开发同学一起去避免产生更多的bug，促进开发过程中项目质量，保证甚至提早项目上线时间，保证项目质量的同时推动项目进度。

那么在开发过程中如何提高项目质量，我们可以做些什么呢？或者说人话我们的任务是什么呢？我们做那些工作可以提高项目质量呢？

首先明确下QA在开发过程中提高项目质量的重要性，我们知道QA的作用是很大的，具体如何做，该怎么做呢？我要告诉大家的是，不要急嘛，一定要淡定。好了，不说了，不然就没人看了，闲话不说，进入整体，请君向下看：

1）QA根据交互稿编写测试用例时，应深入挖掘交互稿，要挖啊挖，挖啊挖...重申下不是挖煤的，是挖功能点的，不但要挖交互稿中已有的功能点，对交互稿中隐藏的功能点也不要放过，必须要挖出来，不要怪哥残忍，因为哥只有一个愿望，就是保证产品的质量。在这个过程中，我们要与策划和交互同学多亲热，与他们多交流，对交互稿中不清晰或自己认为不合适的功能点或认为交互稿中缺失的功能点，需要尽快与策划交互确认及讨论，将结论与开发同步，让其提早介入，避免走弯路，虽然条条大路通罗马，但弯太多，可能在单元时间就无法走到正道了。

2）冒烟测试用例评审是不可缺少的，应诚心邀请相应的策划、交互、开发及有丰富经验的QA人员参加用例评审，需要虚心听取大家的意见，因为你再牛逼，但你只有一人，俗话说“三个臭皮匠顶一个诸葛亮”，但前提你才是臭皮匠，人家是诸葛亮。自己测试思维不系统或个体思维局限导致的用例不全的问题必然存在，所以记得要多多听取大家的意见哦。在讲解用例时一定要清晰，如果讲不清楚估计人家也懒得听，更不会提什么意见了，结果就是产品质量就不能保证了。人生中难免不会磕磕碰碰，在用例设计时亦是如此，将在设计用例时遇到的问题或是有争议的点抛出来，因为这些点已经折磨了你很久了，让你寝食难安，当然也要抛出来折磨下他们，哈哈，是不是太坏了，答案当然不是，因为我们大家有一个共同的梦想，就是保证产品质量。没有办法，只有一起确认解决了。

3)提前给出冒烟测试用例，最好同时给出详细测试用例，让开发尽早同步，减少开发过程中的坑。未雨绸缪~早起的鸟儿有虫吃，早给出用例少bug。用例给什么时候给出呢，是越早越好吗？答案当然~不是，开发初期开发同学可能脑子还是一片空白，没有调查就没有发言权嘛，此时给出用例开发同学还没有进行系统性的思考，对用例中的功能点甚至如初见，虽然一见钟情是浪漫的事，人生若只如初见也是一种美好的向往，但我们是理工男，当然需要理性的去看待事物，因为我们相信日久生情，相信只有相知才会幸福，虽然有点屌丝思想，但却是如此...因为我们本来就是屌丝嘛，因此需要给开发一段时间去和需求相互了解，培养感情。而实践是检验真理的唯一途径，让开发去深度了解对方，虽然需求漫漫其修远兮，但开发也会孜孜不倦的上下去求索的..有点污呀~好了回归主题,一般认为在开发周期的60%左右给出用例最好，因为此时开发和需求已经交往了一段时间，有了一定的了解，此时和开发沟通需求的特点(即用例)，是最佳时机..

4）根据冒烟测试结果，建议给予的相关人士一定的奖惩措施，督促开发提高提测质量。没有比较就必要伤害，根据心里学可知，当看到周围的人过的比自己好，就会滋生羡慕嫉妒恨这种复杂的苦逼情感。苦逼是进步的动力，要想摆脱苦逼就要改善开发代码质量，提高产品质量，最终的目标是一致的。

5）在产品开发过程中，QA应根据交互稿中的易错点或开发易忽略点或者以前出现过类似bug的点和相应的开发（前端、后端）去确认，提醒开发在开发过程中去开发该功能或注意判断条件。俗话说，前人之鉴、后人之师。一朝被蛇咬，三年怕井绳。但开发同学是健忘的，或是说是懒，为什么说懒呢，懒得想嘛，你说能不懒吗？所以QA要时刻的去提醒开发，去接他们的伤疤，让他们时刻记着疼，我不坏，因为我们的目标是一致的。

6）没事多和相应的开发交流下，培养下感情，了解下他们实现某功能的设计方案，要静静的聆听发现有坑的地方要及时确认，如果可能还可以帮助他们优化下或是修正下他们的设计方案，毕竟QA了解需求比较全面也挖掘的比较深。知己知彼，才能保证项目的质量，虽然有点阴险但我们也是帮助开发去追求完美，保证项目的质量，毕竟我们的出发点是好的（曾经深夜和开发讲某一需求，因为认为逻辑比较复杂，容易产生坑，不放心呀，就去和开发聊，听他的实现方案，果断发现实现逻辑的坑，然后就开始讲需求功能点，及怎么实现。貌似有吹牛逼的嫌疑）。请大家把注意点放在括号外面，因为这才是重点，就是尽快了解开发的实现方案，是否满足需求，将其扼杀在项目开发过程。

 QA同学应该感到自豪，的确也应该自豪，因为QA在项目开发过程中的作用是巨大的，呵呵意淫一下，那么接下来介绍下功能的主要实现者即我们最钦佩的大神们开发同学在开发工程中提高项目质量的注意的工作：

1）开发前需深度挖掘交互稿，整理自己开发的功能模块，做好实现设计再进行开发。俗话说开发是搬砖工，其实应该也是挖掘工，用挖掘机搬砖效果应该更好，，，呵呵，开发同学开着挖掘机去挖掘交互稿中的需求，将表面的隐藏的全部挖出来，根据挖出来对的需求设计实现方案，掌控全局，是不是有种运筹在挖掘机中，决胜在千里之外，是不是很吊，没错，大神就是很吊的。

2）数据库设计，互联网产品或可以说时数据产品，因为充满了写数据和读数据，产品在数据的瀚海中遨游，因此数据库设计是产品质量的基石，数据库设计的有问题，也就是根基不稳。想起了一部玄幻小说——斗破苍穹，难以达到斗帝巅峰呀！根基一定要打牢呀。。。

3）冒烟用例评审时，如果认为QA说的需求特点(用例)不正确或认为与自己了解的不一致，就要勇敢的站出来与QA同学PK下，为了真爱要不惜一切代价，一定要维护需求的本质特点。当然PK过程中难免会磕磕碰碰，但要相信爱要越挫越勇，何况你不是孤军奋斗，当然如果两者相持不下，我们就需要请出需求的创造者——策划同学去定位他创造该需求的本质特点是什么，最后经过三方会审，达成一致，使开发同学更正确的去了解他们的的恋人——需求君。

4）交叉执行冒烟用例，人多力量大，术业有专攻，在看开发冒烟测试执行集，很容易发现一个很奇葩的问题，某用例的执行者却不是他的创造者执行的，而是“小三”操作的，这么纯真的关系就被混乱了，结果导致因为不匹配，造成产生了一个畸形后代（就是我们常说的bug），白日做梦一下，或者直白的说意淫一下，如果时间充足时开发可以在开发过程中参照详细用例进行开发，防止功能点遗漏。（估计想多了....）

5）CodeReview，他的中文名字叫代码审查，重要性不言而喻。再牛逼的大神也会犯低级的错误，金无足赤人无完人。“完美”本来就是个理想主义者的瞎想，但我们却都是以完美为目标而奋斗，需要外人或自己去不断检测自己平时的行为（及你自己写的代码），然后反思或让别人告知自己的不足，然后不断改善、不断修炼，使自己去成为大神，使自己做的东西尽量完美。其中让别人帮忙review也是非常重要的，原因大家都知道吧，不知庐山真面目、只缘身在此山中。当局者迷等等因素。Codereview可以保证代码质量，及时的发现代码中的bug，特别是隐藏较深的逻辑缺陷。基于及早发现容易修复的真理，可以减少以后大量修复bug成本。

    在开发过程中提高项目质量，不仅可以减少测试周期还可以减少开发修复bug的时间，在开发过程中修复bug，开发同学所需要的时间较少。因为刚写完代码，开发同学记忆尤新，容易定位到bug根源，如果bug带到提测版本或是线上，则带来的修复成本将会增大许多。人都是健忘的，从数月前写的代码中定位影响产品运行的bug，则需要更多的时间。特别是有些bug在开发过程中比较容易复现，其实只要定位到修改bug是较容易修复的，可能只是修改个字段或是过滤条件或是某一行代码即可。我们就很容易面临“寻寻觅觅，凄凄凉凉戚戚”、“哪怕终于千辛万苦滴水穿石，也只能在那边不由自主地抓耳挠腮，最后无奈叹一句路漫漫其修远兮”的尴尬局面。如果不想像瞎子摸象那样去定位bug，那么促进开发过程中的项目质量就尤为重要。

    从整体的项目上线周期来看，其意义也较为重大。因此，需要在项目组中加深开发过程中如何提高项目质量的重视度。

网易云新用户大礼包：https://www.163yun.com/gift

本文来自网易实践者社区，经作者付二帅授权发布。