業(yè)務熟悉

熟悉本系統(tǒng)

測試人員參與測試的系統(tǒng)的各種業(yè)務場景，必須做到精熟 。一旦需求有改動，可以清楚快速的知道上下文。同時可以清楚的知道哪些點是需要重點測試的。

熟悉跟本系統(tǒng)有通訊的上下游系統(tǒng)業(yè)務

跟本系統(tǒng)有通訊的上下游系統(tǒng)也要非常熟悉。這樣一旦系統(tǒng)出現(xiàn)問題，可以知道影響的范圍。

熟悉公司主流程業(yè)務

熟悉公司主流程業(yè)務。雖然不是自己測試的系統(tǒng)，但是熟悉公司主流程業(yè)務，可以讓測試人員在考慮問題的時候，有更好更廣的思路。

邏輯思維好，氣場也要好

互聯(lián)網應用一般是切分成多個子系統(tǒng)的，各個系統(tǒng)都有自己的業(yè)務范圍，一個任務的完成，通常要有多個部門或者小組進行協(xié)作。這個時候，就不可避免的進行各種會議溝通，小組內的或者小組之間的。那么測試人員如果腦子不好使，不能快速的理解別人的意圖和想法，會很容易被人忽悠或者陷入各種坑，到時候就會有無窮無盡的測試任務了。另外，當對方太強勢的時候，測試人員不能太弱勢，應該根據(jù)自己對業(yè)務和系統(tǒng)理解，提出自己的意見，該做的就做，不應該做的別硬塞過來。積極配合對方，但不是傻傻的啥都做。

掌控系統(tǒng)上線排期

如果開發(fā)任務非常的多，測試人員要測試的功能也就非常的多。這個時候，如果功能的上線時間都是由開發(fā)經理或者PMO等來定，那測試人員就只能進行無窮無盡的加班。這樣是不行的。測試人員有自己專業(yè)，對業(yè)務精熟，必須清楚的知道哪些任務的優(yōu)先級是高的，哪些是低的，將任務進行優(yōu)先級排序。規(guī)定某個時間段里，就只能上多少個功能。測試小組能夠承受的最大任務隊列是多少，測試人員必須有個底。測試任務超過這個隊列，可以根據(jù)優(yōu)先級把部分任務擠出去。

能編寫覆蓋關鍵路徑的測試用例

對業(yè)務需求準確的理解后，測試人員能根據(jù)業(yè)務需求，設計關鍵的測試用例，能夠完整的覆蓋業(yè)務關鍵路徑和場景，保證只要這些重點用例能通過，就說明需求的重點功能已經OK了。重點功能OK了，就算立刻上線，如果出現(xiàn)問題，也只是小問題。當然能夠用測試用例覆蓋所有當然是最好的。

熟悉測試技術

在測試互聯(lián)網應用的時候，測試至少得掌握下面的技術和概念：

1. 懂得用jmeter進行性能測試；

2. 懂得搭建性能測試需要的環(huán)境，例如服務器、redis、memcache等等；

3. 懂得如何編寫性能測試報告。例如至少包含接口響應時間、QPS、最佳并發(fā)數(shù)、CPU使用情況、內存情況、抖動、GC情況等等。

4. 懂得上下文切換、內存溢出、內存泄露、QPS、穩(wěn)定性測試等等的概念。

約束開發(fā)人員，保證開發(fā)質量

當開發(fā)提測代碼的時候，測試人員應該具備下面的意識：

1. 讓開發(fā)人員先把master分支的代碼merge或者rebase到自己分支上，保證提測的時候，代碼已經包含了master的代碼，這樣可以提前發(fā)現(xiàn)問題。

2. 代碼功能測試完畢后，必須再做一次回歸測試。這個時候必須強烈的約束開發(fā)人員，不許再提交代碼了。除非是bug。不然的話，測試人員回歸測試完后，開發(fā)人員跑來告訴測試說，代碼有改動。這樣的話，測試人員辛辛苦苦的回歸測試就白測了，又得重新回歸一次。

3. 測試人員必須回收master分支的代碼提交權限，一旦開發(fā)者要提交代碼，只能通過和測試溝通，說明代碼做了什么改動。絕對不能讓開發(fā)人員悄悄的提交代碼，這種行為非常造成線上故障的。

要懂的寫代碼進行接口自動化測試

現(xiàn)在微服務非常的流行，各大互聯(lián)網公司都在搞微服務接口。針對微服務接口，測試人員一定要懂得編寫代碼去進行接口自動化測試。大家想想看，假設某系統(tǒng)有50個微服務接口，測試人員測試完一次后，開發(fā)人員修改了其中10個接口的代碼，這個時候應該可以通過跑自動化case來驗證這10個接口的改動有沒有影響到其他40個接口。這種回歸測試的效率非常的高。如果每次都得人工手動的進行接口回歸測試，那測試人員就得累死了。