今天我们聊聊一个比较有趣的话题。某天有人在群里问了一个问题：一名普通的测试人员如何提升在团队中的话语权。笔者在测试很没有话语权的团队中待过，也在测试具有上线一票否决权的团队中呆过，对于 “话语权” 这个事，还真没太注意过。在测试拥有上线一票否决权的团队中，基本上也没见测试动用过那个权利（曾经动用过，而且还真的不让上线了，所以这个权利是真的可以被使用），因为它对团队的伤害太大，使用它，往往意味着整个团队对项目质量已经失控了。个人更喜欢用 “影响力” 来表达测试在团队中的地位，可能发问的那位同学也是这么想的吧。那么如何提高测试自身的影响力呢？

01 增强自己的业务能力

在笔者面试测试人员的时候，都会问到一个问题：请描述下你测试的一个项目，它的基本业务流程是什么样的，业务数据的流转是怎么样的，哪些场景会对此业务产生影响。很多时候，面试候选人都无法很好地回答这些问题。作为测试人员，我们不应该仅停留在对页面数据的增删改查验证。而是需要协助研发人员一起把业务规则梳理清楚，并提醒可能的潜在风险，这些事都需要测试员对业务有深入的了解。能够从产品的一句话需求中，“挖” 出一些有价值的信息（参考从测试看需求）。

举个例子，我们现在常用的健康码，从业务的角度出发，作为测试人员的你，可以提出哪些问题，来帮助研发同学梳理业务呢？如果你的答案是直接找产品啊，那也不能说你错，但这样，其实你就失去了一次影响研发的机会。而且，如果你不是带着问题去找产品，你所获取的信息也会相当有限。
我会准备好以下几个问题：

用户信息如何识别？怎么确认当前登录的用户谁，如何认证？
为了生成这个码，我们需要和哪些公共资源接口对接？还是都是我们自己做？
绿、黄、红码的变化规则是什么？
某个地区突然被升级成高风险，系统如何获得这个信息？
当获取到第 4 点的信息时，我们的系统将如何响应？
如何保障这个码不会被篡改？
。。。。。。
带着这些问题，和研发一起找产品聊，你觉得研发会不喜欢这样的测试么？会没有影响力么？

02 能够和研发同频交流

你是否足够了解被测系统的业务构架是怎么样的？基于当下的微服务拆分，你是否能准确地了解哪些服务是做什么用的？它们之间是如何通信的？当研发的同学在交流时，提到服务注册、API 网关、Mycat、Redis 集群、Kafka、Elastic Search 等词汇时，你能否 GET 到他们在聊什么？知道这些技术的基本应用场景和优缺点么？如果你只能 “嗯，哦、啊” 而插不上话时，你如何体现自己的影响力？你又不是捧哏的。并不是要求你和开发的技术能力要一样，而是至少你要了解这些组件的基本原理，能听得懂，在适当的时候能和他们进行正常的沟通，如果能提一些意见，那就更好了。这几天因为西安一码通的事，分布式和高可用又被炒了一波，看看那些词，你能理解的有多少呢？

03 具备自己的测试思维

对于有一定工作年限的测试人员，一定要形成自己的测试思维，当领到一个测试任务时，知道该如何去验证，能够分清测试重点。而不是人云亦云，被开发牵着鼻子走。这个其实也是基于前面 2 点，形成自己的测试思维，举几个例子。

1. 如何验证需求真的被实现了？
   以前遇到一个需求，很简单，为了保护个人隐私，在页面上，需要把电话 18788888888 显示成 187**888。是不是很简单，那么如何验证研发真的实现了呢？如果你只是看页面的显示，那是不够的。至少你要找到这个接口，看看接口层返回的是 18788888888 还是 187888，如果接口返回的是 18788888888，那在页面上显示成 187***888 又有什么意义？（不要笑，这是个真实的案例，不要高估研发团队的能力，需要自己有验证的能力）

2. 如何提供有效的 BUG 信息 ？
   当我们提交一个 BUG 时，除了常规的那些必填项外，是否还能够提供一些更有价值的信息，来协助开发定位问题？仅仅一个截图是不够的。至少你还需要提供一些日志信息以及你的测试数据。这样有两个好处：第一，可以帮助我们确认是否真的是 BUG。当你可以在众多的微服务中找到这个 BUG 的异常信息时，至少可以说明你对这个系统有足够的了解。第二，当你觉得这个是 BUG，而又找不到什么关键信息时，你需要再次确认下这是否真的是一个 BUG？减少不必要的无效 BUG ，同时又能提升研发定位问题的测试人员，研发肯定是喜欢的，不是么？

3. 要有自己的逻辑思维
   遇到问题要有自己的思考过程。不要被带偏，特别是在做一些专项测试时，更要注意完整的逻辑闭环。当研发提出某些问题不是问题，或者只能那么实现时，需要自己去思考是否合理，而不是就同意了。同时，对于自己给出的数据链或者结论，要形成完整的闭环。有一次看到同事的一份性能测试报告，其中有一条结论大致是这样的：对比发布 200 个 API 和 1000 个 API 的压测结果，无认证 API 最大 TPS 分别为 10797.5 和 4623.4，相差 2.3 倍；通过对比可知，发布的 API 数量影响系统的处理能力。
   我不知道大家对这个结论怎么看，仅仅通过两个数据，就轻意下结论，这种做法并不可取。

04 以上要求真的高吗

一名测试人员具备 “懂业务、懂技术、有思维” 的能力，真的很难么？如果你工作 3 年以上，真的不难，如果不具备，那需要反思的是自己，而不是去争取所谓的 “话语权”。当你做好自己的本职工作，同时又能给团队些许帮助时，你就具备了一定的话语权。单纯行政上的话语权，当你能力不够时，只会沦为被嘲笑的对象。
现在团队对测试的要求已经更高了。可以参考林冰玉老师最新的文章：构建测试的体系化思维（基础篇）。个人非常推荐大家好好看下这篇文章，如果你真的达到了，那么，你一定会有话语权的。

原文连接：https://mp.weixin.qq.com/s/1jOjZSqKoHH7LwukV7zyTQ