论新时代软件测试人员的工作之道（二）之让评审更有意义

评审的不仅是需求

需求是为业务发展服务的，如果需求缺陷被引入线上，导致了用户的需求未得到满足，服务质量降低，用户体验很差的话，用户极有可能放弃这款产品，如果要想挽回用户的信心，需要成倍的努力，而且不只是需要在产品上的改造，更需要在市场营销活动拉新和召回老用户上多加努力。

所以每一次的需求评审，我们首先应该关注以下几个问题：

1）项目背景是什么，为了解决什么问题？

2）有没有更好的方案来解决这个问题？

3）是否做过用户调研？如果这个项目上线，怎么样才能判断是否解决了这个问题？是否可量化？

4）如果该项目上线，会对相关部门有影响吗？会导致其工作量过度增加吗？需要提前增加headcount吗？

也许这些问题的确是产品经理首先应该考虑的问题，可是恰有不巧，并不是每个产品经理都那么资深，或者说产品部门应该给定一个模板让大家按此执行，每次都提前解决好这些问题。但是，工程人员的产品思维同样重要，人多力量大，从不同的出发点考虑总会相对周全。很多时候干好一件事，有好几种解决方案，产品经理所设计的并不一定是以最低成本（即开发工作量）来实现同样目的的，毕竟很多产品经理都不太懂技术，并不具备架构思维，也许一个细小的改动不但牵涉到功能的开发，还涉及到性能的考量，其工作量不可小视。

上面提到的关于量化，更应该是产品经理们的基本功，项目的核心，这关乎到项目的成败以及持续优化，毕竟所有的产品都是要迭代的，有了数据的量化有助于项目组对产品各个模块的用户行为进行分析，并对数据进行同环比，得出对用户所产生的影响，若是积极的影响是否还可以继续改进，若是消极的那就要寻找症结，改变思路。

而考虑到项目上线对相关部门的影响，亦是很重要的，就好比某个审批流的改动，为了给用户带来即时服务的功能，审核数据若从原来一月一次变成每日一次的话，会造成审核工作的N倍增长，如果此部门不提前考虑headcount的话，贸然上线，会导致公司服务的瓶颈，用户一定怨声载道，当然对需求的充分评估有助于这种情况的缓解，比如适当降低点即时服务的频率又能让用户得到更好的体验等等。这种类似的案例，大家可以结合自身工作情况，总结总结。

另外，关于做好需求评审的重要性，还可以从另外一个维度即成本上来阐述。特别是针对2B即企业的项目， 更多的是搭框架，以满足共赢为目的，产品方的很多需求都来自于销售或运营，在前期需求调研，整理汇总及成型阶段若过于大意，返工的话，消耗的是研发团队的成本，而研发团队人员薪酬相对于销售或运营来说会高一些，整体上来说是耗费了公司的成本，所以每一次前期需求阶段更是重要。这里，肯定有人会说如果把一件事情做的太完美了，可能已经过了最好阶段了，早被竞争对手抢先一步了，的确如此，所以我们要明确的是方向正确，细枝末节可以迭代优化，如果频繁调整方向耗费的不只是公司的人力成本，更是错了宝贵的时间节点。

在我们的工作中很少有测试同学关注到以上内容，所有的开始都基于前面的工作都已经就绪，毕竟那主要是产品方的活儿，他们的kpi，但是作为项目中的一员，我个人觉得仍然很有必要与团队一起打磨好产品。

除了上面的内容，需求阶段还需要关注的几点：完整性、正确性、一致性、可行性、无二义性、健壮性、必要性、可测试性、可修改性、可跟踪性。这些都没有什么特别之处，不再累述。

设计评审时关注架构

在参加开发设计评审时，不但要关注其对需求分解的完整性和一致性，还要关注系统组成及接口协调的合理性，模块调用的正确性，易维护性，安全性，性能及稳定性，同时为了满足这些要求，是如何设计实现的。测试同学为了发表自己的见解，的确需要在平时多积累了解系统架构相关知识，在测试过程中，除了用户直观所见的界面之外，还需要了解在这后面系统间是如何处理的，包括正常流和异常流，数据是怎么样流转及存储的等等。只有深入了，才能发现更难发现且更有价值的bug，如此开发人员更愿意和这样的测试人员合作，一个字爽。

就好比微信红包，核心功能就是充值à发红包à拆红包，需求简单明了，却为了满足数亿人在春节期间顺利使用该功能，微信研发团队在背后做了很多的努力，而之前来我司分享其技术解密，我有幸参加了。在对架构设计时，有损服务和柔性服务更是用到了极致，每一个有交互的模块都做了相关处理，我想也只有对架构有一定了解且知道通过一定方法来测试各种异常情况的测试人员方能胜任此项工作。这也将成为做好业务功能测试同学的必备技能。关于什么是有损服务，柔性服务或服务降级，感兴趣的同学可以去补充一下相关知识。

文章同步发布在我的个人博客:www.oktest.me上，可点击原文链接进入查看，同时收录全网海量测试相关文章，欢迎阅读。