今天我们聊聊一个比较有趣的话题。某天有人在群里问了一个问题：一名普通的测试人员如何提升在团队中的话语权。笔者在测试很没有话语权的团队中待过，也在测试具有上线一票否决权的团队中呆过，对于“话语权”这个事，还真没太注意过。在测试拥有上线一票否决权的团队中，基本上也没见测试动用过那个权利（曾经动用过，而且还真的不让上线了，所以这个权利是真的可以被使用），因为它对团队的伤害太大，使用它，往往意味着整个团队对项目质量已经失控了。个人更喜欢用“影响力”来表达测试在团队中的地位，可能发问的那位同学也是这么想的吧。那么如何提高测试自身的影响力呢？
01
在笔者面试测试人员的时候，都会问到一个问题：请描述下你测试的一个项目，它的基本业务流程是什么样的，业务数据的流转是怎么样的，哪些场景会对此业务产生影响。很多时候，面试候选人都无法很好地回答这些问题。作为测试人员，我们不应该仅停留在对页面数据的增删改查验证。而是需要协助研发人员一起把业务规则梳理清楚，并提醒可能的潜在风险，这些事都需要测试员对业务有深入的了解。能够从产品的一句话需求中，“挖”出一些有价值的信息。
举个例子，我们现在常用的健康码，从业务的角度出发，作为测试人员的你，可以提出哪些问题，来帮助研发同学梳理业务呢？如果你的答案是直接找产品啊，那也不能说你错，但这样，其实你就失去了一次影响研发的机会。而且，如果你不是带着问题去找产品，你所获取的信息也会相当有限。
我会准备好以下几个问题：
- 用户信息如何识别？怎么确认当前登录的用户谁，如何认证？
- 为了生成这个码，我们需要和哪些公共资源接口对接？还是都是我们自己做？
- 绿、黄、红码的变化规则是什么？
- 某个地区突然被升级成高风险，系统如何获得这个信息？
- 当获取到第4点的信息时，我们的系统将如何响应？
- 如何保障这个码不会被篡改？
- 。。。。。。
带着这些问题，和研发一起找产品聊，你觉得研发会不喜欢这样的测试么？会没有影响力么？
02
能够和研发同频交流
你是否足够了解被测系统的业务构架是怎么样的？基于当下的微服务拆分，你是否能准确地了解哪些服务是做什么用的？它们之间是如何通信的？当研发的同学在交流时，提到服务注册、API网关、Mycat、Redis集群、Kafka、Elastic Search等词汇时，你能否GET到他们在聊什么？知道这些技术的基本应用场景和优缺点么？如果你只能“嗯，哦、啊”而插不上话时，你如何体现自己的影响力？你又不是捧哏的。并不是要求你和开发的技术能力要一样，而是至少你要了解这些组件的基本原理，能听得懂，在适当的时候能和他们进行正常的沟通，如果能提一些意见，那就更好了。这几天因为西安一码通的事，分布式和高可用又被炒了一波，看看那些词，你能理解的有多少呢？
03
具备自己的测试思维
1. 如何验证需求真的被实现了？以前遇到一个需求，很简单，为了保护个人隐私，在页面上，需要把电话18788888888显示成187*****888。是不是很简单，那么如何验证研发真的实现了呢？如果你只是看页面的显示，那是不够的。至少你要找到这个接口，看看接口层返回的是18788888888还是187*****888，如果接口返回的是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数量影响系统的处理能力。我不知道大家对这个结论怎么看，仅仅通过两个数据，就轻意下结论，这种做法并不可取。
