业务熟悉

　　熟悉本系统

　　测试人员参与测试的系统的各种业务场景，必须做到精熟 。一旦需求有改动，可以清楚快速的知道上下文。同时可以清楚的知道哪些点是需要重点测试的。

　　熟悉跟本系统有通讯的上下游系统业务

　　跟本系统有通讯的上下游系统也要非常熟悉。这样一旦系统出现问题，可以知道影响的范围。

　　熟悉公司主流程业务

　　熟悉公司主流程业务。虽然不是自己测试的系统，但是熟悉公司主流程业务，可以让测试人员在考虑问题的时候，有更好更广的思路。

　　逻辑思维好 气场也要好

　　互联网应用一般是切分成多个子系统的，各个系统都有自己的业务范围，一个任务的完成，通常要有多个部门或者小组进行协作。这个时候，就不可避免的进行各种会议沟通，小组内的或者小组之间的。那么测试人员如果脑子不好使，不能快速的理解别人的意图和想法，会很容易被人忽悠或者陷入各种坑，到时候就会有无穷无尽的测试任务了。另外，当对方太强势的时候，测试人员不能太弱势，应该根据自己对业务和系统理解，提出自己的意见，该做的就做，不应该做的别硬塞过来。积极配合对方，但不是傻傻的啥都做。

　　掌控系统上线排期

　　如果开发任务非常的多，测试人员要测试的功能也就非常的多。这个时候，如果功能的上线时间都是由开发经理或者PMO等来定，那测试人员就只能进行无穷无尽的加班。这样是不行的。测试人员有自己专业，对业务精熟，必须清楚的知道哪些任务的优先级是高的，哪些是低的，将任务进行优先级排序。规定某个时间段里，就只能上多少个功能。测试小组能够承受的最大任务队列是多少，测试人员必须有个底。测试任务超过这个队列，可以根据优先级把部分任务挤出去。

　　能编写覆盖关键路径的测试用例

　　对业务需求准确的理解后，测试人员能根据业务需求，设计关键的测试用例，能够完整的覆盖业务关键路径和场景,保证只要这些重点用例能通过，就说明需求的重点功能已经OK了。重点功能OK了，就算立刻上线，如果出现问题，也只是小问题。当然能够用测试用例覆盖所有当然是最好的。

　　熟悉测试技术

　　在测试互联网应用的时候，测试至少得掌握下面的技术和概念：

　　1. 懂得用jmeter进行性能测试；

　　2. 懂得搭建性能测试需要的环境，例如服务器、redis、memcache等等；

　　3. 懂得如何编写性能测试报告。例如至少包含接口响应时间、QPS、最佳并发数、CPU使用情况、内存情况、抖动、GC情况等等。

　　4. 懂得上下文切换、内存溢出、内存泄露、QPS、稳定性测试等等的概念。

　　5. 要懂得如何做线上UAT验证,尤其是那种需要多系统合作的项目,UAT是极其重要的步骤。

　　约束开发人员,保证开发质量

　　当开发提测代码的时候，测试人员应该具备下面的意识：

　　让开发人员先把master分支的代码merge或者rebase到自己分支上，保证提测的时候，代码已经包含了master的代码，这样可以提前发现问题。

　　代码功能测试完毕后，必须再做一次回归测试。这个时候必须强烈的约束开发人员，不许再提交代码了。除非是bug。不然的话，测试人员回归测试完后，开发人员跑来告诉测试说，代码有改动。这样的话，测试人员辛辛苦苦的回归测试就白测了，又得重新回归一次。

　　测试人员必须回收master分支的代码提交权限，一旦开发者要提交代码，只能通过和测试沟通，说明代码做了什么改动。绝对不能让开发人员悄悄的提交代码，这种行为非常造成线上故障的。

如果功能模块是跨系统的,也即是会调用另外一个系统的接口。这种的，测试人员一定要要求各个系统之间的开发必须做【开发联调】。测试人员必须强制要求开发做到这一点。不然到时候可能出现各种接口调用不通呀、接口入参出参理解错了呀，这样会及其严重的阻碍测试的进度。如果没做【开发联调】，测试人员是可以不测的，直接打回。