01
增强自己的业务能力
在笔者面试测试人员的时候，都会问到一个问题：请描述下你测试的一个项目，它的基本业务流程是什么样的，业务数据的流转是怎么样的，哪些场景会对此业务产生影响。很多时候，面试候选人都无法很好地回答这些问题。作为测试人员，我们不应该仅停留在对页面数据的增删改查验证。而是需要协助研发人员一起把业务规则梳理清楚，并提醒可能的潜在风险，这些事都需要测试员对业务有深入的了解。能够从产品的一句话需求中，“挖”出一些有价值的信息（参考从测试看需求）。
举个例子，我们现在常用的健康码，从业务的角度出发，作为测试人员的你，可以提出哪些问题，来帮助研发同学梳理业务呢？如果你的答案是直接找产品啊，那也不能说你错，但这样，其实你就失去了一次影响研发的机会。而且，如果你不是带着问题去找产品，你所获取的信息也会相当有限。
我会准备好以下几个问题：
(1）用户信息如何识别？怎么确认当前登录的用户谁，如何认证？
(2）为了生成这个码，我们需要和哪些公共资源接口对接？还是都是我们自己做？
(3)绿、黄、红码的变化规则是什么？
(4)某个地区突然被升级成高风险，系统如何获得这个信息？
(5)当获取到第4点的信息时，我们的系统将如何响应？
(6)如何保障这个码不会被篡改？
(7)。。。。。。
02
能够和研发同频交流
你是否足够了解被测系统的业务构架是怎么样的？基于当下的微服务拆分，你是否能准确地了解哪些服务是做什么用的？它们之间是如何通信的？当研发的同学在交流时，提到服务注册、API网关、Mycat、Redis集群、Kafka、Elastic Search等词汇时，你能否GET到他们在聊什么？知道这些技术的基本应用场景和优缺点么？如果你只能“嗯，哦、啊”而插不上话时，你如何体现自己的影响力？你又不是捧哏的。并不是要求你和开发的技术能力要一样，而是至少你要了解这些组件的基本原理，能听得懂，在适当的时候能和他们进行正常的沟通，如果能提一些意见，那就更好了。这几天因为西安一码通的事，分布式和高可用又被炒了一波，看看那些词，你能理解的有多少呢？
03
具备自己的测试思维
对于有一定工作年限的测试人员，一定要形成自己的测试思维，当领到一个测试任务时，知道该如何去验证，能够分清测试重点。而不是人云亦云，被开发牵着鼻子走。这个其实也是基于前面2点，形成自己的测试思维，举几个例子。
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数量影响系统的处理能力。
我不知道大家对这个结论怎么看，仅仅通过两个数据，就轻意下结论，这种做法并不可取。
04
以上要求真的高吗
一名测试人员具备“懂业务、懂技术、有思维”的能力，真的很难么？如果你工作3年以上，真的不难，如果不具备，那需要反思的是自己，而不是去争取所谓的“话语权”。当你做好自己的本职工作，同时又能给团队些许帮助时，你就具备了一定的话语权。单纯行政上的话语权，当你能力不够时，只会沦为被嘲笑的对象。
网友评论