拼多多“薅羊毛”事件引发测试工作的思考

Posted 2021-02-05

前言

2017年我有幸负责公司DevOps治理和落地项目，在整个DevOps落地工作中，深感测试环节在持续交付工作中的弱态及重要。实践是检验真理的唯一标准，没有实践就没有发言权。为求深入理解，我亲身投入了测试岗位的一线工作。从测试用例的编写、宣讲、测试、复测、上线、回归等一些列实际工作，再到带领测试团队、提炼测试经验，推动测试变化的一系列行为，让我对测试工作有了深刻的认识。在测试岗位一年多的工作经验中，补全了我Devops治理工作中测试环节的内容，为我Devops的工作提供了丰富的经验。我也借这次拼多多事件与大家分享一下我的测试工作体验。

线上的测试券

这几天拼多多被薅羊毛的事刷爆了朋友圈，作为经历了生产删库、用户数据泄露等诸多互联网安全新闻的圈内互联网从业人员，早已内心淡定、波澜不惊了。昨天朋友圈发了一篇关于拼多多事件技术复盘的文章，我匆撩一眼便觉得有必要给这位小编科普一下为什么测试券可以发布到生产环境。
小编在文章中提到了拼多多事件是由测试券引发的生产漏洞。他确实阐述了一个在互联网企业客观存在的现象，就是生产环境中，测试商品的存在。记得去年某东也曾出现过测试商品被用户下单的问题。
我在刚做测试的时候，我们项目团队也存在同样的问题，如我们开发了新的支付功能，在漆黑的深夜（12点左右吧），项目组的同事们（开发、测试、产品、运营）相约起床（有时也会约在公司熬夜到此时的），将代码发布上线，然后开始线上回归测试。这时的测试工作是个主流程的回归测试，测试人员在代码发布上线后，要通知产品经理和运营人员配置上线测试商品，然后通过新版本进行下单、购买、退款等可覆盖新功能的主要闭环流程的测试工作。顺利的话，很快结束，大家开心安稳睡觉，不顺利的话，在许可的条件下开发同事会反复定位，最后完成上线工作，否则超过发布时间窗口的话，就回滚代码等着下次吧。
以前测试人员或产品经理有着很大的权限，有着超级管理员的权限。后来运管中心进行了权限管控，回收权限，但这也直接导致了发布生产后，被管控权限功能无法进行线上回归测试。因此每次上线也会因为功能的不同，带上相关的运营的同事。

我的测试实践

线上测试环境

客观问题既然存在，并不表示放任他的存在而不管，我觉得我们同样需要根据客观事实去实施一种管理策略，既可以完成线上环境的测试工作，又可以不影响实际的商户运营。
我在负责广场优惠券小程序的项目测试工作时，为了提高测试能力同时避免生产事故，我联合开发、运营同事，共同在生产环境开通了一个虚拟广场的商户，对这个虚拟广场，我们测试人员有完全管理权限，可实现广场商户的全功能测试覆盖。对于实际用户，即便切换到该广场，看到的也全是测试商品和测试说明（这也未尝不是一种彩蛋），但无法领用，因为这里的券只有被指定的测试人员的会员才可以领用。利用这个虚拟广场，我们在后续的测试工作中获得极大的便利。
举个例子，当时我们要上线一个类似大转盘，点击后抽奖的活动功能。经过项目组同事的努力，快速的完成了代码的开发和测试工作，我们提前几天就把代码发到了生产环境，并在虚拟广场中进行了活动的上线，为了得到更充分的测试，我们发动了公司同事共同的参与了内测活动，得到了充分的测试和很好的用户反馈。这样我们即提升了测试的覆盖能力，又没有影响到实际的商户，高效的完成了代码上线及测试工作。

这个解决方案有他的特殊性，虚拟广场是可独立存在的，所以并没有开发同事深入的介入，只是在运营同事方面开通相应的权限就实现了。但这个测试实践，也为在生产环境进行测试工作提供了一种可实用的方法，就是在生产环境上进行灰度隔离，创建一个可测试的真实环境。依照现在的技术，实现起来也不是存在很大难度的，不同场景更因其实际情况的复杂程度要区别对待，可能测试人员、产品经理和运营同事就可以把方案实现并落实，也可能要依赖产品经理、开发同事、测试人员、运维同事、运营同事等诸多同事共同设计来完成此事。

在最初我带队Devops落地项目的时候，也曾自动的忽略了测试岗位的存在。在很多情况下，测试人员只是需要时才被想起来的角色。当经过测试工作的实际参与，我觉得在目前开发团队里，应该给测试人员更重要的定位和更多的赋能。如何发挥测试人员在开发团队中的作用，在思考的同时，我也切身在工作中进行了如下实践：

测试驱动产品

我的测试团队，在接到产品经理的需求文档后，会主动与产品经理进行沟通，开始进行测试用例的编写，并与产品经理反复确认产品设计中的每个细节，力求充分理解产品需求，使得测试用例可以覆盖到产品设计的每个细节，此时产品经理也在和测试的沟通中弥补了产品设计细节的不足。在测试用例设计后，会组织在测试团队进行内部宣讲，用团队的力量弥补个人思考的不足。然后负责测试的同事再组织开发同事与产品经理进行测试用例宣讲，待到项目小组内都明确测试目的后，测试用例就定稿了。测试用例是测试工作的基础，是一个非常明确的待办事项列表，为了清晰内容，明确目的，我把测试用例拆分成功能用例和流程用例。在与开发同事和产品经理宣讲时，只讲流程用例，既明确了产品目的和需求，又有效的控制了宣讲会的节奏和提升了会议的效率。

测试驱动开发

此处的测试驱动开发，不同于TDD的概念，而是让测试人员来驱动开发工作。开发工作与测试用例的设计往往是并行进行的，测试用例定稿后，有部分测试工作已经可以开始了，这不单包括测试人员进行的测试工作，也包括测试用例分享给开发同事后，他们的自测试工作。每日站会时，测试人员会根据测试用例的内容梳理出的待办事项列表与ScrumMaster 共同与开发同事明确开发目标和deadline。会后测试人员也会针对当日目标配合开发同事完成相关的测试工作，推动开发完成目标。

业务故障处理

经过上述一系列的工作，虽然测试人员没有参与编写代码，但是产品功能、业务流程、接口参数更甚至版本迭代历史，测试人员都是最熟悉的，所以在业务故障出现时，测试人员将会更清晰是哪个环节导致了该问题的发生。因我们在测试用例设计时，就把业务流程单列出来作为独立的用例进行编写，并作内部宣讲，所以组内同事都能够清晰的把线上业务的主流程、分支流程、逆流程说清楚。在出现业务故障时，我们组的测试人员，可以根据所熟悉的业务流程，很快的分析出问题方向，并根据问题界定好用户操作、运营配置、接口服务、代码问题等业务故障类型，并进行直接答复解决或联系该部分代码的开发同事深入排查。该工作，在实际的业务故障处理时也给我们带来的有益的效果，极大的缩短了业务故障的处理时间。

后续的思考

互联网企业管理，传统思维要不得

每次企业的生产事故，都会有人说要加强管理，于是就颁布了诸多的管理规定和操作流程，然后就期盼着大家共同去遵守。对于传统型企业，这是很常规的做法。但在互联网企业更应该将管理规定和操作流程进行工具化的落地。制度是规则，管理是约束，工具才是更人性化管理落地的体现。不是在事后的抱怨和惩罚，而是事前做好每个人的保护才是根本管理之道。

普通人视角，客观看待问题

每次看到优秀的产品或优秀严谨的代码，我们都会为之赞叹。但我们更应客观的认识到世界是由80%的普通人构成的，如何让普通的人做成优秀的事，才是真正需要去思考的问题。我认为devops 里提倡的pipeline 的精髓就是，复杂的事情简单做，一个人只专注做一个完整的流程，让普通人更容易的去完成一件事。开发流行的各种框架结构、微服务等手段都在不断的降低开发人员能力的需求。这都是不断的在追求让普通的人做更优秀的事的先进实践。

用户的需求就像一副抽象画，他模糊、复杂、易变且不确定，互联网产品为满足用户的需求，就必须可以具有敏捷的特性去反复的试探用户的体验。产品从设计、开发、测试、上线、运营、再次迭代的过程中，测试人员更应该把团队中的各个角色贯穿起来，只有给予测试人员正确的定位和足够的赋能，才可真正的将敏捷开发的理念更好融入到实际工作中，快速应对用户需求的各种变化。