驱动开发自测
【APP测试中的头疼闹热】测试人员如何驱动开发做好自测 https://mp.weixin.qq.com/s/in5M9VcdwPp6d9VzdvE-Eg
【APP测试中的头疼闹热】测试人员如何驱动开发做好自测
今天TestBird的测试工程师@lixiaoli在内部论坛给大家带来了第一篇非常好的原创文章，而且看样子是个系列文章哟！有这样的好文，Bird也甘愿当搬运工哦~！
如今，随着移动互联网的浪潮越翻越涌，移动APP测试工作的现状已经成了那本“家家难念“的经。不管公司大小，不管测试哪种类型的APP，让广泛测试者苦不堪言的就属重复性最多，测试工作量最大的功能测试。而这个系列文章将逐一解构一些问题。
笔者通过对目前大型的安卓市场和APPstore进行调查，其实我们可以发现每天都不乏有有创意的，能够针对市场需求的APP上线，但不管当时这些APP是不是排在榜单前列，过不了多久，它们便在应用市场中销声匿迹，变成所谓的“僵尸”应用。
面对这些如雨后春笋般冒出的APP，若是你使用过的话，其实就可以发现一个常见的问题---APP本身不错，但用户使用过中程碰到了各种异常，面对这样的情况，一般用户都会选择删除，继而选择其他更适合的APP。
大公司：有多名测试专家，有庞大的测试用例库，测试工作分工明确，做功能测试的人员通常固定，新员工能力建设主要通过执行用例。功能测试人员耗费了大量时间在与开发的沟通博弈上。
中型公司：有一个看得过去的测试团队，测试用例和测试平台管理通常有待完善，而测试人员流动性对其测试能力的建设和传递提出了很大考验。通常一个人负责多项测试工作，时间耗费最多而对能力提升最小的手工功能测试则让测试者崩溃。
小型公司：只有一两个测试人员甚至没有，快速的研发进程都让研发团队应接不暇，更多的就忽略了全面的功能测试，更不用说测试体系建立。
而对中小型公司来说，版本迭代没有严格的流程，通常版本提交测试后，发现很多问题导致冒烟不能通过，反反复复。
本文先解决第一个问题：
怎样提高中小型公司测试执行的规范性，让测试驱动开发进行自测？
毫无疑问，很多测试接口人或者测试者都遇到过这种情况，开发人员完成功能开发就丢给测试人员，你问他自测过吗，他的回答是肯定的。
而往往测试人员一验证就发现冒烟不能通过，再打回重新修改，一来二往，时间浪费了，测试人员不胜其烦地为开发做了验证工作。
你再问开发“你到底有没有自己好好做一轮功能测试？”
开发回复你“哦，我这边没有手机了~”
到最后项目时间变得很紧张，因为在国内测试主要是后期工作，这时间压力就落到测试者头上。测试不完整导致的大黑锅便自然落在了测试人员身上。
我们基于云手机把功能测试搬到线上，这样避免了双方责任推诿，通过工具详细记录测试过程，并以执行用例的方式呈现。测试成功与否，测试问题截图日志全部都自动保存。
测试结果可以直观看到，省去了一来二去的相互推诿，不管是开发还是测试，工作效率都会更高。
驱动开发去自测，APP开发的流程会更加自然而规范
关于TestBird：
TestBird能够提供真机兼容性测试、真人体验测试、真人压力测试。与腾讯、网易等5500多家游戏厂商建立合作关系，测试手游超过16000款，占据手游行业70%以上份额。
TestBird真机测试平台：已经拥有2000多款全球热门机型，覆盖市面上95%以上人群；
真人体验测试：已经吸引40000多名高品质玩家，供开发者进行游戏玩法体验调研；
真人服务器压力测试：基于TestBird已有的40000多名真实玩家，为开发者提供多人在线服务器压力测试；
云手机：基于云端2000+真实手机，可供开发者远程使用。方便调试BUG、应用演示、游戏在线试玩等。
信不信？我们项目没Bug https://mp.weixin.qq.com/s/AV4irlmaRGGuz-ySF5_Xuw
不推开发自测，你就干死了 https://mp.weixin.qq.com/s/3lyO-tILFGymbu8LFct9-w
信不信？我们项目没Bug
1
引言
曾经， 我以为
作为一名测试工程师， 提交Bug就是我的本职工作。 Bug提的多，说明我牛。
直到有一天，我跟了一个糟糕的项目，逾期未交付， 做砸了~ 虽然我们测试团队报了近千个Bug，可依然阻止不了项目的失败。
我的总监（负责开发和测试团队）在绩效考核时，评价我的工作：“Bug报的多，并不能代表什么，只能说明开发质量烂”，“项目失败了，虽然不是你的原因，但按照个人贡献，我只能给你打个Meet（合格）”
站在大Boss的角度，是希望这个产品是成功的，高质量的。而线下Bug多，都只是内耗。
那，我， 一名测试工程师，我能推动开发代码质量的改进吗？
有幸，在网易**项目中，基于PDCA质量管理理念， 做了一次实践。
2
计划 Plan
1、分析现状
项目负责人:
为什么测试员都已经报了这么多Bug，还是会有很多线上问题？
整天在救火， 还怎么好好的做新需求啊！
究竟是开发代码质量差，还是测试员覆盖不全啊？
开发:
我需求都没开发完，你们就催着提测，催着上线。
哪有时间保证质量啊？ 加班997， 都没时间和老婆生孩子了， 还要被责怪，我委屈啊委屈。
测试:
这Bug都好low哦！ block我测试了。
这个Bug 怎么还没改好啊？都打回2次了。
啊？ 怎么最后一轮还有Bug啊！不开心。
可是， Deadline的号角已经吹响了~宝宝心里虚啊！
项目负责人:
是时候整顿下了。
2、分析原因
既然是由Bug引起的一场战乱，那咱就从Bug着手。 于是，有了一周一次的Bug回溯。
分析哪些bug？
-
线上的Bug
-
线下Critical 和 Major 的Bug
-
罗列出可以通过开发自测解决的Bug
分析什么？由谁分析？ 怎样分析？
-
每周挑选5个左右。
-
分析 Root Cause, 以及落地改进方案。
-
线下的Bug改进方案由开发分析，线上的由开发和测试共同给出。
-
每周周会，在测试发言环节,和所有人分享,其他所有人会进行补充并优化落地改进方案。
3、制定计划
落地改进包括两点：技术改进和流程改进。流程改进包含以下内容：
-
简单粗暴的Bug请开发加强自测。
-
开发加强 Code Review
-
测试加强业务异常以及系统异常测试
-
其他流程上的改进。
其他流程上的改进包含以下内容：
-
对需求进行细化
-
对接口进行详细定义和异常处理
-
Hotfix 流程改进
-
提测前客户端与服务器进行联调
-
测试阶段进行BugBash
-
整理并维护上线CheckList
3
执行 Do
问题都已经暴露出来， 改进方案也有了。那么如何确保证这些改进真正地落实了。
纵观整个改进方案，最难落实的应该就是开发自测和代码评审。
开发先哭了，我们加班加点，周末无休， 需求都赶不完。还让我们自测，让我们代码评审。 我们也知道好处多多，but 时间啊， 时间啊~~
头儿发话了： 需求是一定要赶的（竞品太多），但是质量也得抓。
他锊了锊性感的胡须：“这样吧！下期需求，你们把自测和评审的时间都评估进去。随着你们对项目的逐渐深入， 对需求的评估能力应该会更加准确的。 到时候自测没做，可不能以时间为借口了哦！”
会哭的孩子有奶吃， 时间终归是有了。
那么怎么来监控开发自测和代码评审的过程呢? 毕竟这2个流程都是贯彻始终、持之以恒的事情！
1、开发自测的监控
开发自测，如果仅仅只关注开发冒烟用例的通过率，往往是不够的。 因为执行效果怎样，需要打一个问号。
配合自测型Bug的跟进，疗效不错！（所谓自测型Bug，说的狠一点，就是低端Bug，哦，请原谅我是一个刀子嘴豆腐心的人）
说实在的，开发小哥们都是三观正、有理想的。谁愿意让人家指指点点Bug多代码烂呢？
之前真的是流程的问题， 真的是流程的，流程的问题~
2、代码评审的监控
Gitlab自带Code Review 功能，跟踪者可以通过Activity 模块下的Comments 查看到所有评论。
可以每周统计一次数据， 包括评论条数、内容、修复情况， 在团队内部晾晒数据。
4
检查 Check
检查是对执行后效果的评估，是伴随着实施过程自始至终的，不断收集数据的过程。
版本时长: 计算开发开始--测试结束的时间。
总开发人日： 所有的开发人员在这个版本中投入的人日总和， 指版本规模。
关注的指标： 总bug数除以总开发人日。
实践2个半月后，统计了近7个版本的指标， 大家可以看到，最后2个版本，指标降下来。
开发负责人： 质量好了，不用总是被锅了。
测试： 郁闷，找不到Bug了（其实有找到几个old Bug）
项目负责人： 测试找不到Bug， 我也还是担心啊！
我：测试期间找不到Bug，同样的测试资源，只会比以前更心细。 测试深度更深。对测试环节，请放心~~~
5
实践总结 Action
以上流程核心：以Bug回溯的方式来推动开发自测、代码评审以提高提测质量，进而提高产品质量。并且，不断收集晾晒数据，让团队所有成员知道我们在不断进步。
开发鼓励坚持以这样的方式做质量改进。原因如下：
-
质量是真的在变好。提测后，发现的总Bug数少了很多。
-
开发把测试阶段修改Bug的时间解放出来，可以做其他更有价值的事情。
-
上线前所有人比以前更有底气了。
-
整个团队规范性、自信心、士气、更好了。
不推开发自测，你就干死了
发表了《信不信？我们项目没Bug》之后，陆续会被问到一些细节问题。今天主要和大家聊聊，怎么去推动开发团队做开发自测。
1
QA怎样去推动？
QA动员开发，让开发做自己不擅长不喜爱不太接受的事情， 你说的没错！的确是有难度的。
但，大家也非常明确一件事，流程的推动一定程度上都是自上而下的。
所以，第一件需要做的事情是，用数据说话， 获得开发经理的支持。
1. 统计出最近一个版本自测型Bug（低端Bug）的占比
2. 罗列出自测型的Bug
3. 向开发负责人、项目经理等提出QA的建议
-
希望开发能够加强功能点的自测，减少低端Bug。
-
QA 将主要精力投入基于整体业务、用户场景的系统测试。
我相信，作为一名有情怀、有素质、有质量意识的开发经理，不会无动于衷。
也许，他也想做这件事情，而你恰好提供了这样的契机和方案呢。(重点是，如果一次不成功，脸皮厚点找各种机会多磨几次)
2
全体宣贯
任何一个流程的推动，我个人觉得，还是需要一定的仪式感的。
最好是以会议的形式。
如果有线上事故驱动，QA可以适时展示Bug数据，提出合作改进方案。
如果没有线上事故，以QA牵头，组织《Bug分析》会议是最自然的方式。
传统上的质量报告，大家最关注的是上线前的质量。
而Bug分析，将开发团队带入到过程中， 将测试对开发，一对一的过程公开透明化。让不太优雅的流程改进化。
我们要在这个会议上不仅暴露问题，还要提出改进具体细则。
另外： 这个会议开发经理一定要在场哦！因为流程的推动肯定是自上而下的。对了，最好再叫上项目管理。
最后有了结论，别忘了邮件里敲定。
3
数据统计晾晒
质量改进后第一次统计
结论： 在开发投入人力增多，节奏加快的情况下，Bug率、自测型Bug率反而明显降低！
几乎每个人的Bug率较基准版本均下降，前端下降幅度最大！
我们在会议上，美美的表扬了进步幅度最大的开发，荣获当期质量之星！
4
持续跟进，验收结果，健康
持续跟进了6个月的质量，状态健康。
系统Bug率从1.62下降到0.57，进入稳定期，在0.6左右徘徊，质量提高近3倍
尤其是在前2个月，成效显著！
5
持续跟进，指标反弹，不健康
2017年3月份的版本，系统Bug率0.59，但前端Bug率达到1.29。
分析背后的原因：
•前端界面全新改版
•而开发自测用例只提供了主干功能，导致开发自测颗粒度太大，且不够系统
改进措施：
效果：
Bug率出现了历史最低0.38
6
各方反馈
前端负责人：
开发自测，投入产出比还算挺高的。
一、能够缩短整个项目时间，因为我们修改Bug时间缩短了很多。
二、能加强开发对需求的理解，需求理解的一致性很重要。
三、自测很快的，就是造数据有点耗时，如果能帮助开发快速造数据，那就更赞了。
后台开发：
用例，对于整体流程跑通的作用还是比较大的，并且自测的时候，能够提前发现一些问题，感觉挺好的。
测试：
Bug率最低(0.38)的这个版本
一、基本没有大问题。也许，开发自测的用例不用验收，问题也不会太大。
二、历史以来测试最顺畅的一次， 居然都不用和开发，产品去沟通交流了。
三、改进后，开发人日/测试执行人日，出现最大值4.28
说明测试执行人力(man*day)在下降。
换句话说， 测试执行成本在降低。
对开发团队隐形的好处，是战斗力在增强。我们的前端同学都已说明， 测试期间，改Bug时间缩短了，和测试同学纠缠的时间少了，可以安静地做下一个迭代的开发了！！！
所以我们的项目可以达到一周一次上线，开发测试可以高效地并行。
