业务熟悉
熟悉本系统
测试人员参与测试的系统的各种业务场景，必须做到精熟 。一旦需求有改动，可以清楚快速的知道上下文。同时可以清楚的知道哪些点是需要重点测试的。
熟悉跟本系统有通讯的上下游系统业务
跟本系统有通讯的上下游系统也要非常熟悉。这样一旦系统出现问题，可以知道影响的范围。
熟悉公司主流程业务
熟悉公司主流程业务。虽然不是自己测试的系统，但是熟悉公司主流程业务，可以让测试人员在考虑问题的时候，有更好更广的思路。
逻辑思维好 气场也要好
互联网应用一般是切分成多个子系统的，各个系统都有自己的业务范围，一个任务的完成，通常要有多个部门或者小组进行协作。这个时候，就不可避免的进行各种会议沟通，小组内的或者小组之间的。那么测试人员如果脑子不好使，不能快速的理解别人的意图和想法，会很容易被人忽悠或者陷入各种坑，到时候就会有无穷无尽的测试任务了。另外，当对方太强势的时候，测试人员不能太弱势，应该根据自己对业务和系统理解，提出自己的意见，该做的就做，不应该做的别硬塞过来。积极配合对方，但不是傻傻的啥都做。
掌控系统上线排期
如果开发任务非常的多，测试人员要测试的功能也就非常的多。这个时候，如果功能的上线时间都是由开发经理或者PMO等来定，那测试人员就只能进行无穷无尽的加班。这样是不行的。测试人员有自己专业，对业务精熟，必须清楚的知道哪些任务的优先级是高的，哪些是低的，将任务进行优先级排序。规定某个时间段里，就只能上多少个功能。测试小组能够承受的最大任务队列是多少，测试人员必须有个底。测试任务超过这个队列，可以根据优先级把部分任务挤出去。
能编写覆盖关键路径的测试用例
对业务需求准确的理解后，测试人员能根据业务需求，设计关键的测试用例，能够完整的覆盖业务关键路径和场景,保证只要这些重点用例能通过，就说明需求的重点功能已经OK了。重点功能OK了，就算立刻上线，如果出现问题，也只是小问题。当然能够用测试用例覆盖所有当然是最好的。
熟悉测试技术
在测试互联网应用的时候，测试至少得掌握下面的技术和概念：
- 懂得用jmeter进行性能测试；
- 懂得搭建性能测试需要的环境，例如服务器、redis、memcache等等；
- 懂得如何编写性能测试报告。例如至少包含接口响应时间、QPS、最佳并发数、CPU使用情况、内存情况、抖动、GC情况等等。
- 懂得上下文切换、内存溢出、内存泄露、QPS、稳定性测试等等的概念。
- 要懂得如何做线上UAT验证,尤其是那种需要多系统合作的项目,UAT是极其重要的步骤。
约束开发人员,保证开发质量
当开发提测代码的时候，测试人员应该具备下面的意识：
- 让开发人员先把master分支的代码merge或者rebase到自己分支上，保证提测的时候，代码已经包含了master的代码，这样可以提前发现问题。
- 代码功能测试完毕后，必须再做一次回归测试。这个时候必须强烈的约束开发人员，不许再提交代码了。除非是bug。不然的话，测试人员回归测试完后，开发人员跑来告诉测试说，代码有改动。这样的话，测试人员辛辛苦苦的回归测试就白测了，又得重新回归一次。
- 测试人员必须回收master分支的代码提交权限，一旦开发者要提交代码，只能通过和测试沟通，说明代码做了什么改动。绝对不能让开发人员悄悄的提交代码，这种行为非常造成线上故障的。
要懂的写代码进行接口自动化测试
现在微服务非常的流行，各大互联网公司都在搞微服务接口。针对微服务接口，测试人员一定要懂得编写代码去进行接口自动化测试。大家想想看，假设某系统有50个微服务接口，测试人员测试完一次后，开发人员修改了其中10个接口的代码，这个时候应该可以通过跑自动化case来验证这10个接口的改动有没有影响到其他40个接口。这种回归测试的效率非常的高。如果每次都得人工手动的进行接口回归测试，那测试人员就得累死了。
原文链接
