登录注册
最新博客
最新资源下载
项目代码质量的推进之路
达芬奇密码2018-06-25 09:40
前言
QA部门集中推动代码质量改进的工作已经1年半了，这1年半以来，杭研大多数项目的提测质量提升很快，体现在：
- Bug数量和Bug率下降很快，很多项目的bug率从之前 >2 Bug/人日下降到1.5以下，到现在大多数项目已经<1了；
- 从产品的反馈来看，很多项目团队的开发、PM和测试人员都反馈项目质量变好了，测试过程更加顺利了，测试阶段缩短了。
第一阶段 项目试行
2016年初开始，我们选取漫画、青果等项目进行质量提升的探索，经过团队内的多次讨论，选取了一些方法，包括用例细化Review、开发冒烟自测等方式。这些方法被证明是行之有效的。
用例细化Review
- 测试设计文档出来之后，策划、开发、测试人员一起评审测试思路，往往能发现很多策划案之前没有涉及到的异常细节，补充了策划案，从而让开发和测试过程中的因为需求问题导致的Bug减少，使流程更加顺畅。我们会采取比较轻量级但是有效的方式，比如说，就只要相关功能的策划、开发参加，用小会议的形式直接讨论，一个功能点Review完成后，换一个开发继续，避免了大会议打酱油的情况，提高Review效率。
开发冒烟自测
开发冒烟自测是我们在推动代码质量上最有效的一个措施。说起来倒是很简单，我们在开发提测之前就把冒烟用例发给开发，请开发根据这些用例通过自测之后才把版本提测。
我们之前给开发的冒烟用例很少，只涉及10%左右的主干用例，因为开发时间也非常紧张，导致一些项目的开发只完成了主干功能就把版本提测给测试，版本质量不好，测试人员需要测试很多轮才能达到可发布状态，整个过程中Bug很多，测试流程不顺畅，测试进度比较长。针对这个问题，我们把冒烟自测用例提高到了50%～100%，让开发承担更多的冒烟测试，从而保证开发提测质量。
有人可能会问，开发也很忙，这个举措相当于给开发加了更多的工作量，开发为什么愿意承担更多的测试工作？说到这个，真的应该感谢开发团队和PM团队的支持，大家都是从项目整体流畅度的角度去考虑，才能使这个措施慢慢地推行开来，而事实证明，开发自测力度增加以后，提测质量确实变好了，测试流程顺畅很多。
当然，我们也做了很多交流、沟通、意识宣传这类的工作，到现在，这个开发冒烟自测已经在所有项目顺利地做起来了。 图1是开发冒烟自测完成之后的反馈邮件。
图1开发冒烟自测之后的反馈邮件
第二阶段 指标确定
在做试点的同时，我们也开始考虑选取一些合适的指标评价开发的提测质量，一开始我们选取了几个主要指标：千行代码Bug率、冒烟测试通过率、Bug Reopen率。
在实际实施的过程中，发现千行代码Bug率有一些缺点：比如，千行代码Bug率需要统计所有的新增、修改的代码，有一些开发人员进行merge操作的、或者导入一个第三方jar包的，代码量就会飙升，统计不准确。还有一些其他因素导致这个指标不准确的，每一个人看到这个指标，首先就是怀疑的态度，他们会问，你们是怎么统计的？有没有剔除所有影响统计的因素？针对这种情况，我们团队也商量过解决方案，从技术上来说，我们是可以把所有的影响准确的因素消除掉，但是，我们无法消除人们的怀疑，如果为了一个指标总是需要解释很多的话，如何保证我们统计数据的权威性？
基于这点考虑，我们后来才采用了一个看起来不是那么精确，但是却是比较直观明了的指标，那就是开发的人日Bug率，也就是开发的Bug个数／开发人日。对于这个指标我们团队内部也有一些疑义，比如说，有些开发的效率很高，别人开发2天的功能他开发1天就搞定了，那他在统计中不是吃亏了吗？针对这个问题，我们思考着，其实很难有完全精确的数据去评价开发质量，我们希望测试人员在看待这个数据的时候，千万不能完全信任数据，而是要尽量去挖掘数据背后的一些故事。
最终，我们选择了 开发人日Bug率、自测型Bug率、Bug Reopen率、冒烟测试通过率这几个指标来评价提测质量。少既是多，太多的指标反而容易分散判断，这几个足矣。参考图2的模版
。
图2 所有指标的模版
第三阶段 项目铺开
在这个阶段，我们开始把试点项目的成功经验拿过来，复制到各个其他的项目中，密切跟进各个项目的推进进度，在这个阶段，我们讨论了很多细节的问题，包括：
- 有一些项目组已经习惯了之前的模式，不太愿意改变。如何更好地把开发自测的思维导入到项目中，让项目组都能接受这种方式。针对这个问题，我们讨论出来一些方式，比较有效的方有Bug回溯，找一个典型的版本，跟一个项目组一起分析Bug产生的原因，在Bug分析中我们会发现一些开发简单测一下就能发现的Bug，大家就容易打成共识；当然，前面也提到过，各种单点沟通、集体沟通也都是需要的，特别是跟开发负责人和PM的沟通。
- 已经开始开发自测了，但是开发自测通过率是100%，测试验证发现通过率只有90%，怎么办？针对这种情况，比较好的方式是马上开一个简单的分析会，看看究竟是哪些测试用例失败了，是因为测试用例写的不充分呢，还是开发执行不到位？就事论事，制定解决方案，那下一次就不会出现类似问题了。
- 我们还确定了代码质量度量报告的格式，还是遵循少即是多的原则，整个报告做到精简、易懂、主题突出。感谢李丹，她的质量度量报告被我们用来做为最终的质量报告原型。
执行过程中还有很多细节问题，各个项目的情况都不一样。我们通过双周会跟踪各个项目的进展、讨论问题，达成共识，最终都顺利推行起来了。
第四阶段 数据自动统计
项目铺开来之后，每个项目都需要统计数据、写Excel，重复工作量很大。所以，我们开始考虑做平台化、自动化的事情。自动地把Bug相关的数据和开发工作量相关的数据抓出来进行统计。
每个项目对于Jira的用法不同，为了保证数据的准确性，我们做了很多的工作，比如说，有一些项目的Bug包括了需求的Bug，我们拉取数据的时候，就统一规定不拉取这类Bug；有一些Bug关联了很多个版本，导致每个重复统计多次，我们也通过规范消除了这种情况；关于开发工作量，也是尽量做到精确。
为什么花这么多时间在数据校正上？因为我们希望我们的报告是有可信、有参考意义的，是能尽量反映实际情况的。
数据统计出来之后，难免会涉及到“横向对比”这个敏感的事情，关于这个“横向对比”，QA的内部有一些人提出要谨慎地使用这个数据，我们内部也进行了一些沟通，最终决定还是从目的出发。我们之所以做质量统计，目的当然是希望能推动项目质量的改进，而根据我们的经验，项目组内部本身就有提升质量的动力，只要定期把本项目纵向数据呈现给项目组，再加上一些推动的措施，项目质量就能维持在一个较好的水平。如果在一个太大的范围内曝光这个横向数据，可能反而会把项目组的关注度引到数据本身，反而会有一些副作用。所以，我们现在的代码质量报告还是以项目组内的纵向对比和产品内部的小范围横向对比为主，谨慎地使用横向数据，代码质量报告部分截图如图3。
图3 代码质量报告部分截图
通过前面的这一些步骤，我们已经完成了质量推动相关的一系列事情，流程也已经基本确立。只要按照现有的规范持续地进行推动和改进，相信项目的质量能维持在一个较高的水平上。
关于推动代码质量的提升的故事已经进入尾声，然而关于开发自测的另一个故事，却才刚刚开始。
互联网业内已经有公司尝试深度开发自测的方式，开发人员自己开发、测试并上线，测试人员则进行测试思路的培训、测试工具的开发、测试框架的调研及引入等工作，整个项目的测试达到了高度的自动化，做到持续交付。这种公司往往是通过自上而下搞运动的方式推行的、也有一些项目团队是因为开发负责人有
DevOps
的意识，才推行得比较好。在这些团队的测试人员则跟随着这个过程进行了职责的转变，由测试的执行者变成了测试框架的搭建、测试相关工具的开发的角色。
测试团队内部其实挺希望这样的趋势，不过，现在我们公司项目开发负责人、项目负责人都还没有足够的信心把测试工作完全交给开发人员。现在我们虽然开始在推行把打点、后台管理系统、简单的运营活动交出去给开发和运营测试，但是整体进展还是很慢。
我们觉得，项目开发负责人和项目负责人的意识转变、开发的技术和测试思路的积累可能需要一个比较长期的过程，不是一下子就能达到理想的状态，不过，希望测试人员能主动学习相关的技术，时刻准备着，等时机成熟的时候来一个华丽丽的转身。
本文来自网易实践者社区，经作者钱蓓蕾授权发布。
分享至：
