项目需求那些事儿

互联网产品讲究“唯快不破”，各种产品都是在用生命赶进度，以期望比同类的产品要更早一步进入市场，从这个市场大饼中划走一笔。于是，项目管理说：我们要尽快把功能上去。然后，各种迭代排起来，开发测试行动起来。过了一段时间，眼看就要到了交付截止日期了，项目还没有上线，项目管理过来问，为啥还没上线呢？测试：一言难尽，委屈.jpg。上线后不久，运营找过来说，我发现了个线上bug！测试一惊，艾玛，咋又有线上bug，再一看…

下面，我们就来说说作为一枚测试小白在迭代版本过程中遇到的那些事儿～（ps：本文章不带有任何对其他项目角色进行攻击的成分，只是从测试的角度谈一谈项目过程中的一些问题，如有不对的地方，欢迎指正～）

案例一：交互和开发肯定是一对好基友

正当开发的大大们忙着coding，coding and coding以及测试同学夜以继日地写用例的时候，交互同学幽幽地走到开发同学面前说：“之前的需求没考虑清楚，这里应该是酱紫的，¥#¥%#%&*”。开发同学嘴里重复着交互新的需求并飞快地在脑海中搜索需求的实现方案，叮！有了，这个问题so easy！然后开发自信地跟交互说：“OK，没问题！”。于是，交互和开发同学就这么愉快地决定了。然后开发继续争分夺秒地埋头coding，coding and coding，交互继续回去看看有什么需要优化改进的地方好再修改，仿佛一切什么事情都没有发生过。测试心想，这交互和开发肯定是一对好基友，这么忙都会时不时地抽空过去聊两句，也不知道聊的啥秘密，想八卦一下也不给机会，算了，还是继续徜徉在我的用例编写的海洋里吧。。。

终于到了版本快要提测的日子，按照惯例，测试需要提供测试用例，然后跟相关的策划、交互、开发等同学一起进行用例评审。于是，大家小黑屋走起过用例。正当测试同学讲的正带劲儿的时候，开发说：“等一等！这里需求有修改，新的需求是%#%#¥#%”。测试一脸懵逼地说：“为什么我没有收到需求变更通知？”，交互说：“我以为开发会转告你。。。”，开发说：“啊？你不知道？我以为交互已经跟你提前说过了。。。”。

就这样，五十个冒烟用例下来，可能就有十几个问题需要修改或重新确认的。于是，测试同学不仅要改这些问题的冒烟，还有可能要毁掉之前精心设计的详细用例，重写一波。但这不是最重要的，改用例嘛，谁还没有个改一改用例的时候，OK的。最重要的是，一些冒烟用例中没有涉及到的，但又被偷偷修改掉的详细用例功能依然不能被发现，从而流到测试阶段（由于迭代时间紧迫，评审用例时，通常只评审冒烟用例，详细用例不做评审）。于是，测试阶段变成了一个发现bug后都不敢确定是需求改动还是bug，从而需要耗费大量时间不断跟开发和交互双向确认需求的尴尬局面！

案例二：交互说：“有一个很小的需求改动”

版本进入了如火如荼的测试阶段，测试天天忙着测试和提bug，开发天天忙着改bug和开发下一迭代的内容，可谓是忙得不可开交。这时候，交互幽幽地过来了，说：“我感觉xx功能不太好，优化一下比较好，¥#¥#%%#”。ok，小需求嘛，能改还是改了吧，毕竟都是为了产品体验更好，于是按照新需求改动之。过了一会儿，交互说：“xx地方再加一个xx功能吧，运营说最好有一个xx功能，不然用起来会很麻烦@¥！%¥”。此时开发和测试的内心是拒绝的，但想着运营确实也很辛苦，能方便就方便点吧，ok，改动之。又过了一会儿，交互又过来了，说：“xx功能跟我之前想象的不一样¥¥#¥@。。”pardon？想象？交互中没有体现的，我们如何得知你内心的想象呢？猜？不了解你的内心，掐指一算？功力不够深厚。所以只能老老实实地看交互，至于“想象”。。。表示臣妾真的做不到啊，哭ing。又过了一会儿，交互又走了过来。。。（这是一个循环的故事）

案例三：前端说：“我只作一个前端技术优化，不影响任何功能”

终于在测试环境测试完毕，并上预发了，之前在测试环境各种正常、异常的流程都走的差不多啦，除环境等不可抗力因素外，应该是木有什么大问题啦。这么说，就快要上线啦？终于可以早点上线了，想到这里，内心就有点小激动呢！

就在这时，前端一同学过来跟我说：“我们想做一个前端技术优化。。。”，思忖着这事儿不靠谱，首先已经上预发了，现在再来优化肯定是晚了，再说万一改出点事儿来那可就不好了是吧，于是我就委婉拒绝了。然而，前端同学怀着一颗坚持不懈的心，“我们只是优化了一下环境部署，后面再部署环境的时候就方便很多（至于怎么个方便法，此处省略n个字），没有任何功能上的修改，也不需要回归，只需要给我两分钟搞定，真的，不骗你！”看着他坚定和渴求的眼神，想想就两分钟，算了，优化就优化吧，反正就两分钟。然而，事实证明，我还是太年轻。。。

他的优化确实是两分钟，但是问题是两分钟后部署失败了。这一失败不要紧，不仅优化的版本坏了，改回以前的版本也坏了，坏了，了。。。就这样，一个原本可以下午四点上线的版本，一直上到凌晨才上去。

案例四：后端说：“我这里有一个搭车需求，就一个小问题”

版本已经在预发上，并且已经快验证完了，这时候，有一个开发同学过来说，“我们这里有一个小需求，想搭个车，很快的，就一个小问题，直接上预发上看一下，没问题就可以上线了。。。”心想着，既然是小问题，而且听起来很快的样子，反正我还要在预发上再验一会儿，等我验好了，他们应该也好了，时间应该赶得上，搭就搭吧。于是这车就成功搭起来了，这一搭不要紧，预发上发现了bug，并且一时半会儿找不到解决方案，眼睁睁看着这车要翻了。。。

案例五：策划说：“这个问题没关系，不用修改”，上线后……

测试过程中，有时候会发现一些所谓的“不重要”的问题，开发说这个改起来影响可能会比较大，会动到底层代码或者影响其他功能。策划说，这个功能都没人用或者只是运营同学偶尔用一用，这个先不用管，后续我们再优化。上线后，后续没有了后续。有一天，运营找过来说，有一个线上bug。。。

案例六：开发说：“这个没必要做（其实是不想做，艾玛，不小心被我发现啦，哈哈）”，交互说：“不做就不做吧”

开发过程中，有时候会复用以前的老逻辑，而以前的老逻辑可能因为一些历史原因，导致逻辑复杂且不易复用（之所以还要复用，是因为模块功能复杂，再次开发需要时间很久且项目周期短等等等等一些原因，总之就是一定要复用）。交互想在原来的基础上做点个性化定制的东西，以符合本迭代的style。开发在开发过程中，发现如果要个性化定制，需要更改复用的逻辑，万一改着改着改出问题了怎么办，而且改起来有点麻烦，还是不要改了吧，复用多好。于是，开发找交互说，“这个功能实现不了，改了之后很可能影响其他的功能。”交互想了想，“那就不改吧”。于是，开发觉得做起来比较困难或者改了有风险的地方就会跟交互说，这个做不了。交互的回答依旧是：那就不改吧。那么问题来了，最初的个性化定制真的需要吗？又或者，功能真的很难实现吗？可能原本就没有考虑好真正需要的是什么。

案例七：运营说：“这个做出来的效果咋跟我们的需求不一样呢？是个线上bug吧。”

一个项目版本从策划、交互、视觉、开发、测试后，终于上线了，千呼万唤始出来，艾玛，终于可以小喘口气儿了。正在这时，运营找过来了，“这功能咋跟我们想要的不一样啊，我们的需求是¥@¥#@¥！#，做出来的效果怎么是*¥#¥#@”，此时的我一脸懵逼，两脸懵逼，对称懵逼，各种懵逼。。。明明是跟交互上一致的哇，没有问题哇，难道运营和策划交互的需求不一样？于是，赶紧找策划交互过来确认，果然。。。

 ---------------------------------------------------------这是一条华丽丽的分割线--------------------------------------------------

测试该做点什么？

那么同学就要问了，你这把产品线上的所有童鞋都吐槽了一圈，难道测试就没有值得吐槽的地方？你测试你完美还咋滴？

那当然……不可能！测试是干啥滴，保证版本按时保质上线那就是测试的活！无论整个流程下来是什么问题导致了版本没有按时上线，或者线上发现有bug或者类似bug 的东东出现，那测试这个锅都甩不掉！no why，谁让你是最后的把关者呢！

既然都已经到这份儿上了，那作为测试是时候必须要做点什么来避免那时不时飞来的锅了。

上述的这些问题其实作为一个有经验的测试同学来说，那都妥妥的不是问题。然而，对于我这枚测试小白来说，那都是问题。不过，不实实在在地踩过一些坑，永远不知道都有哪些坑存在，以及这些坑到底有多深，这就是所谓的“经验”，所以踩坑也很重要哇是不是？！（自我安慰ing）

其实上面说的这些问题，说到底还是流程不够规范，大家奔着想怎么来就怎么来，反正最后不是我的锅的心态搞事情，那妥妥地要出问题。如果流程够规范，相互约定好规则，有一个约束，自然就不会由着个人爱好来了，上述这些需求问题都自然迎刃而解。

就像案例一和案例二中，交互时不时地改需求，一两个需求改动没感觉，n个需求改动，那妥妥地就是个大工程！于是，大家忙得热火朝天，开发同学天天忙着改代码，测试同学不仅要测改动点，还要回归可能会影响到的各种逻辑，稍不留神，一个线上bug就这么产生了。于是，迭代周期拉长不说，说不定还有线上bug。这时候项目管理迷茫了，为啥迭代延期了，既然迭代周期都拉长了，为啥还有线上bug呢？更重要的是，当项目管理问起来的时候，竟一时间没找到原因所在！尴尬。。。为了不莫名其妙地背锅，必须要采取点措施来拯救这混沌的局面，比如将需求改动点都作为一个个任务评估成工作量，这样每天站会的时候大家都可以看到有哪些需求改动，以及这些改动点造成的工作量增加的多少；或者将各种改动的jira打上标签，版本结束时，将改动的需求统计出来，并在质量报告中体现并进行分析后发送给大家。这样，交互在修改需求时就会谨慎些，起初设计的时候也自然会尽量考虑周全，避免后续修改。

对于案例中开发同学新增技术优化或者搭车的问题，不是说不可以，谁还没有个紧急需求啥的是吧，相互帮忙是中华民族的传统美德！有时候确实比较紧急的需求，那也是没办法的事，只能尽量早地进入流程，谨慎修改和测试上线，毕竟都是为了产品好。但是，对于一些一点都不紧急，什么时候上都行的问题，那就别等到上预发了还掺和了哈，这种类型的优化必须拒绝！开发说的两分钟，可能是二十分钟，也有可能是两个小时，或者更久。为什么呢，不是开发不诚实，开发也都是诚实的孩子。如果这个没问题，可能确实是两分钟搞定，然而，在没有试之前，谁能保证没问题呢？事实上，多数情况下都是会有问题的，很少有无bug的代码。

最后，说一说策划或者交互或者其他人觉得没有必要修复的问题。测试的一个很重要的职责就是测试的系统尽量不要有bug（为什么说“尽量”，我们平常测的时候都是按照等价类来的，除非把所有场景穷举一遍才有可能敢说一定没有bug。这种大话还是不要说，不然上线后可能分分钟打脸），我们要抱着让产品完美的心态来测试产品，而不是得过且过、差不多就得了的心态。当其他人都觉得问题无伤大雅的时候，这时候用户发现了这个bug，那么在用户的内心里首先就会对产品产生一定的不信任感：产品竟然有bug，态度不认真，懒散，重视程度不够，不值得信赖！其次，当用户实在忍不了了，投诉了产品说有bug的时候，这时候会有一大堆人过来问你，这里为什么会有一个线上bug，测试是怎么测的！所以，我们要站在用户以及其他各个角度考虑，这个问题是不是真的不需要修复。通常情况下，只要是有问题的，能修复的都尽量修复，实在赶不上修复的或者准备下线的功能，要及时跟进问题修复情况，不要放任不管，谁知道时间久了大家会不会忘了这里是之前约定好的不用修复或者准备下线的呢？

以上是个人对需求过程中遇到的一些问题的一点想法，如有不对或者不合理的地方，欢迎提出批评、意见或者建议，撒花～

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

本文来自网易实践者社区，经作者黄芬授权发布。