測試兩年半的我，談?wù)勛约旱睦斫?br/>

從2020年7月畢業(yè)，就成為一名測試仔。日子混了一鯤年，感覺需要好好梳理一下自己的職業(yè)道路了，回顧與總結(jié)下吧。

一、測試的定位

做事嘛，搞清楚自己的定位很重要。
要搞清楚自己的定位，就需要先了解整個流程，然后通過流程中的“相對位置”來確認自己的位置。
對于一個產(chǎn)品大團隊而言，從頭到尾總是大概需要經(jīng)過這么一些角色。（在大小團隊中某些崗位可能合并或者分立，但大致是這么一些要做的事情）

1、需求提出者（產(chǎn)品經(jīng)理、策劃或者客戶）
2、產(chǎn)品實現(xiàn)者（架構(gòu)人員、開發(fā)人員）
3、質(zhì)量驗證者（測試人員：測試設(shè)計、測試執(zhí)行、自動化團隊）
4、銷售
5、客戶
6、交付/運維團隊

而我們的定位，就來自于我們與其他角色的關(guān)系。

1、測試與需求：

首先，產(chǎn)品經(jīng)理通過市場風向的研究，想要實現(xiàn)某個功能來滿足客戶需要，形成競爭優(yōu)勢； 或者 接收客戶對于產(chǎn)品某些問題的反饋，提出一個解決方案。
以上這些，落到產(chǎn)品團隊中，最終就成為一個個 待做的需求。然后向研發(fā)團隊講解自己期望實現(xiàn)的功能。

測試工作內(nèi)容，歸根結(jié)底就是“保障質(zhì)量”。
而質(zhì)量，其實不僅僅來源于開發(fā)的實現(xiàn)代碼，也來源于“需求合理性”。
以極端情況舉例，有可能需求提出了畫面要“五彩斑斕的黑”，或者期望在現(xiàn)實世界建造一棟某個特殊造型的房子，而那個房子，本身完全不符合力學結(jié)構(gòu)。
這種情況下，質(zhì)量問題的來源，并不在開發(fā)，而是更前一個環(huán)節(jié)的需求層面。
因為各種原因（如理解偏差、新人上手），需求存在錯誤這種事情，是時有發(fā)生的。而當一個需求本身是存在錯誤的，如果等到開發(fā)已經(jīng)投入實現(xiàn)了大部分之后才發(fā)現(xiàn)，無論是將就著做下去，還是推翻重來浪費的人力都將巨大。
因此，最近有了一個概念叫做“測試左移”，所說的就是測試應(yīng)該在更早的階段（如需求階段）去發(fā)現(xiàn)問題，從而規(guī)避問題。
如果我們能在需求階段，就把問題提出來，就能讓后面的環(huán)節(jié)更加順利。

輸入：
a、產(chǎn)品經(jīng)理講解客戶目前的痛點是什么
b、產(chǎn)品經(jīng)理講解提出什么樣的需求方案，覺得可以解決客戶的痛點
輸出：
a、根據(jù)經(jīng)驗，說出這樣的需求方案可能有什么坑 （比如和已有的某些功能存在重復、或者存在沖突）
b、根據(jù)產(chǎn)品所描述方案，輸出“用戶使用場景性”的測試用例

對測試的能力要求：
a、熟悉產(chǎn)品已有的幾乎所有功能，特別是責任田內(nèi)的。以便于能在第一時間反應(yīng)發(fā)現(xiàn)，和新需求可能產(chǎn)生關(guān)聯(lián)的會是哪些功能。
b、帶入客戶視角的能力。（可以參考5W1H的方法去帶入和思考）

2、測試與開發(fā)：

作為測試，溝通的最多的人，無疑還是開發(fā)。

通常一個測試，需要同時對接多個開發(fā)，前端、后端，甚至后端可能還需要區(qū)分配置面、運行面，對某些產(chǎn)品可能還需要區(qū)分“客戶端和服務(wù)端”。
而測試的策略通常又需要區(qū)分“黑盒測試”與“白盒測試”。
當進行黑盒測試時，我們只需要考慮功能是否能用，里面的細節(jié)不關(guān)心，這種情況下，我們對于開發(fā)輸入的依賴相對沒有那么大。只需要根據(jù)需求的特性，羅列出所有的可能輸入項類型，以及輸入后的期望輸出即可。
而很多場景下，黑盒測試往往是不夠的，一些問題往往出現(xiàn)在奇奇怪怪的地方。
這個時候，我們就需要白盒測試了，白盒測試的第一步，首先測試就需要也先基本理解運行的邏輯。對于開發(fā)的“原理設(shè)計文檔”我們需要能夠去看懂，這樣才能從設(shè)計文檔中，分析出我們所需要的測試點。

輸入：
a、原理設(shè)計文檔（以及講解和評審會議）
b、
輸出：
a、提出開發(fā)設(shè)計文檔中可能存在問題的點（比如邊界、兼容性等 任何開發(fā)沒有考慮到的點）
b、測試設(shè)計文檔+測試用例+測試策略
c、可測試性工具需求提交
對測試的能力要求：
a、需要能理解開發(fā)文檔，并從中拆解測試點
b、需要能從測試點組裝成測試用例
c、需要識別測試過程中可能需要用的工具與環(huán)境

誤區(qū)說明：傳統(tǒng)的流程上來說，測試只是開發(fā)的下一道流程。但已經(jīng)不太適用于當下，特別是敏捷當?shù)赖臓顟B(tài)下，要求測試能提前識別問題，也是不能再等到開發(fā)什么都搞完再接手了，而是要 幾乎并行 地去開展工作。

3、測試與測試：

測試內(nèi)部也有許多的分工，大體分為 “測試設(shè)計人員”、“測試執(zhí)行人員”、“自動化測試人員”幾種角色。
測試設(shè)計人員產(chǎn)出的用例，最終則會成為執(zhí)行人員和自動化人員的輸入項。

對于測試設(shè)計的能力要求：所輸出的用例是可執(zhí)行的，不存在歧義的，且可以驗證到功能是否存在問題的。
對于測試執(zhí)行的能力要求：在用例正確的前提下，是可以嚴格執(zhí)行用例步驟的；在用例可能存在錯誤的情況下，是能夠進行一定程度識別的。
對于自動化測試的能力要求：是要能使用自動化方法實現(xiàn)用例內(nèi)容，并在后續(xù)迭代中可以持續(xù)自動化執(zhí)行的。

4、測試與銷售：

測試過程中，比如性能測試、穩(wěn)定性測試，通常會產(chǎn)出一些產(chǎn)品指標數(shù)據(jù)。
通過實打?qū)嵉闹笜藬?shù)據(jù)，銷售則可以更好的與友商PK，進行更好的推廣，從而賣得更好，大家分得更多。

5、測試與客戶：

前有提到，測試在產(chǎn)品團隊內(nèi)部，就應(yīng)該把自己代入‘客戶’的角度來進行工作。
大部分時候通過 ‘將心比心’的方法能比較好的做到這件事，但還是偶爾陷入‘以己度人’的誤區(qū)。
這種情況下，就只有通過‘測試右移“的方法來實現(xiàn)了。
通過產(chǎn)品發(fā)布后，持續(xù)關(guān)注客戶的使用情況以及反饋情況，來了解是否有解決客戶的問題。（比如 通過網(wǎng)上問題報單數(shù)量）

6、測試與運維

在測試過程中，通常會用到一些測試方法與問題排查技巧。測試如果有做一個比較好的整理匯總的話，這些信息應(yīng)該是可以作為運維人員的一份參考手冊的

二、測試的關(guān)注點

壹、功能測試

1、本身功能測試
就像改一個房子，你希望它能遮風擋雨，能有臥室可以睡覺，有廚房可以做飯，有廁所可以~
這些就是功能點，你需要測試床是不是舒服，廚房有沒有燃氣，廁所有沒有水等等功能性。

2、關(guān)聯(lián)功能測試
在同一個產(chǎn)品下，有時候很多東西都是息息相關(guān)的，功能與功能之間的依賴，進程與進程之間的依賴。
修改其中某處地方，可能不只要考慮功能本身，還需要考慮和他相關(guān)的功能。

舉個栗子，就像是大家買房裝修，如果有某一戶人家把承重墻給拆了，其他樓層也會受到影響。

貳、性能測試

性能優(yōu)化，說白了，就是想要用最少的資源去做最多的事情。
而性能測試的數(shù)據(jù)，則是需要作為性能優(yōu)化是否到位的一個表現(xiàn)。

通常就是通過控制變量來測試。
1、控制固定資源量不變，看單位時間內(nèi)程序處理工作的數(shù)量。（比如，固定CPU吃滿情況下，測試平均每秒可以進行多少次 乘法運算。 ）
2、控制需處理的數(shù)量不變，看資源消耗與耗時。（比如，就固定做十萬次乘法運算，耗時多久，過程中CPU、內(nèi)存、磁盤IO、網(wǎng)路帶寬等消耗多少）

叁、可靠性測試

可靠性測試說白了就是考驗極端情況下，程序還能不能干活。
比如人類，在-100度的高溫下，和-100低溫下，就無法工作了。在30度情況下，人類能勉強工作；40度情況下，基本上無法進行勞作了。
程序也一樣，CPU壓力大的情況下，是否能正常進行。網(wǎng)絡(luò)狀態(tài)差的情況下，是否能正常進行?？蛻舳顺绦螂娔X休眠之后打開是否還能正常使用。
比如 朱日和演習，藍軍的各種buff就是可靠性測試下的壓力。

可靠性下還有一個重要的分支，就是可恢復性，就像大家使用手機，有些情況下手機就是可能會出現(xiàn)卡死的現(xiàn)象。這個時候，只要選擇強制重啟基本上就可以解決99.99%的問題。而如果可恢復性做得不好的話，那就可能導致手機出現(xiàn)一次故障，然后就直接變磚了，里面的各種信息也丟失了。

例舉幾種常見的可靠性：
進程可靠性：1、進程啟動失敗 2、進程退出 3、進程掛死 4、進程Z/D/T
文件可靠性：1、文件損壞/丟失 2、文件讀寫權(quán)限異常 3、存儲空間不足 4、存儲介質(zhì)故障
數(shù)據(jù)可靠性：1、數(shù)據(jù)庫異常 2、數(shù)據(jù)丟失 3、數(shù)據(jù)損壞 4、數(shù)據(jù)內(nèi)容錯誤
網(wǎng)絡(luò)可靠性：1、弱網(wǎng) 2、斷網(wǎng)重連 3、數(shù)據(jù)包過大，數(shù)據(jù)截斷
時間可靠性：1、系統(tǒng)時間跳變（向前跳變、向后跳變、跳變范圍跨小時/天/月/年）
資源可靠性：1、CPU過載 2、內(nèi)存過載 3、磁盤IO過載 4、磁盤空間滿 5、文件句柄 6、網(wǎng)絡(luò)端口被占用 7、網(wǎng)絡(luò)連接過載 8、數(shù)據(jù)庫連接過載等
設(shè)備可靠性：1、設(shè)備掉電重啟 2、設(shè)備關(guān)機重啟

肆、穩(wěn)定性測試

有些產(chǎn)品，是需要持續(xù)運行不出錯的。
有些隱藏的極深的問題，是一時半會無法暴露出來的。
例如：每分鐘會執(zhí)行一個定時任務(wù)，這個定時任務(wù)會產(chǎn)生一個1MB的文件，原則上這個文件在每分鐘使用之后都會刪除掉。而中間出現(xiàn)了bug，文件因為權(quán)限問題或其他問題刪除失敗了。這個時候如果只是測試了幾分鐘，可能根本就無法發(fā)現(xiàn)這個問題。但如果程序持續(xù)運行1天、甚至1周，問題的影響就十分巨大了。

伍、兼容性測試

如果是一個有頁面可以在瀏覽器訪問的應(yīng)用， 則需要考慮各種瀏覽器類型的兼容，各種瀏覽器（chrome、Edge、Firefox、IE、360瀏覽器、QQ瀏覽器）都需要能兼容。
如果是安裝到終端上的應(yīng)用程序，則需要考慮系統(tǒng)類型，如win7、win10、winserver、mac11、mac12、Linux。
如果程序調(diào)用的東西涉及到指令集的層次，則還需要考慮如 intel、AMD等各種不同芯片的情況。
如果程序的傳輸，是涉及到需要加密的，則還需要考慮到加密算法的問題。國際密碼標準 與 中國商用密碼標準 都需要考慮兼容。
如果程序的邏輯，是與時間相關(guān)的， 則需要考慮時間跳變、時區(qū)兼容、12小時/24小時制的兼容
以上只是部分例子，有機會再好好整理一下。

陸、可運維性測試

大家的期許，肯定是完美的。
但現(xiàn)實世界是，產(chǎn)品總會有不夠完美的地方，在一些特定的場景下，就是可能會產(chǎn)生問題。
這個時候，可運維性就十分重要的了。
當產(chǎn)品出了問題，當客戶詢問原因的時候。如果可運維性做得足夠好，那可能問題就會在很短的時間，幾分鐘之內(nèi)得到答案。
而如果可運維性做得極差，那么當產(chǎn)品在客戶處出現(xiàn)問題，甚至可能出現(xiàn)無從下手的原因。
這里帶入客戶的角度模擬兩個場景，
1、產(chǎn)品壞了，打電話去問客服，然后向?qū)Ψ矫枋霈F(xiàn)象，對方告訴你是什么什么原因?qū)е碌?，需要怎么怎么樣處理可能就好了。然后工程師上門，咔，好了
2、產(chǎn)品壞了，打電話去問客服，對方說，嗯~啊~這個~得具體現(xiàn)象具體分析。 然后工程師上門，查了半天沒得結(jié)果，說還得回去看代碼再研究一下。
如果你是客戶，對于這兩種現(xiàn)象會有怎么樣的評價。

柒、安全性測試

當前的大環(huán)境下，安全性測試一般會有專業(yè)的安全團隊來負責。但一般測試如果能稍微了解一些相關(guān)的概念，也是有所幫助的。

三、測試的道法術(shù)器勢

最近發(fā)現(xiàn)，用“道”、“法”、“術(shù)”、“器”、“勢”來拆分任何一個事情，都是很好用的。

道，是根本性的規(guī)律。通常是自然而然存在的。
法，是一般性的規(guī)律。一般是由人自己定的。
術(shù)，是具體的實踐方法。
器，是工具。
勢，是指當前的客觀條件與形式。

"道不易，法簡易，術(shù)常易"
韓非子說，抱法處勢而用術(shù)。

測試的道

對于測試來說，道很簡單，就是盡可能的發(fā)現(xiàn)bug。
竭盡所能地去保障產(chǎn)品的“質(zhì)量”。

測試的法

能提前識別問題的測試左移方法
能持續(xù)運營問題的測試右移方法
分層測試的方法（UI、接口、后端等）
求全的冗余測試方法
求快的精準測試方法
求穩(wěn)的最后一包全量測試方法
求快的分步增量測試方法

撒網(wǎng)撈bug之法
漏網(wǎng)之魚追捕之法
突發(fā)問題補救之法
問題復盤之法

測試的術(shù)

1、自動化技術(shù)
2、接口測試技術(shù)
3、單元測試技術(shù)
4、搭建溝通橋梁的話術(shù)

測試的器

網(wǎng)絡(luò)類：
wireshark抓包工具
nslookup
dig
nsupdate
ping
tracert
tcpdump
……

數(shù)據(jù)構(gòu)造類：
POSTMAN
ApiFox
Fiddler
……

自動化類：
RF框架
selenium
……

資源觀察類：
telegram
top命令
……

測試站點搭建：
Nginx
Apache
XAMPP
Bind9（DNS服務(wù)器）
……

以及各種自制腳本

測試的勢

韓非子說，抱法處勢而用術(shù)。

不知道大家有沒有感覺，保障質(zhì)量，這句話看著哪里都很對。
唯一的缺點就是，很虛。
而只有結(jié)合“勢”，我們才能得到一個答案，團隊希望投入多大的成本來保障質(zhì)量，是否愿意為了質(zhì)量而做出時間上的妥協(xié)。

對于求穩(wěn)的產(chǎn)品，大家希望的是用盡全力保障質(zhì)量，但凡發(fā)現(xiàn)有風險，就必須要解決后才能發(fā)布。

對于高速迭代的產(chǎn)品，大家的重點是“先推出去”，無論如何像讓客戶體驗起來，用起來。

在這兩種截然不同的“勢”下，我們所需要遵從的“法”，使用的“術(shù)”，自然也是需要隨之改變的。

總結(jié)

掌握了器，大抵我們就成為了一個合格的工具人。
掌握了術(shù)，干起活來我們基本上得心應(yīng)手。
掌握了法，我們測試工作上所要做的事情，基本上達到了知其然且知其所以然。
掌握了道，才能在長時間的路上不走偏。

四、測試的時間管理

通常一個開發(fā)，同時可能就投入在一個需求之中。
通常一個測試，對接的是將近一個組的開發(fā)，可能有多個需求。
怎么安排時間？誰先誰后？時間分配

五、測試的未來

而早在多年前，AI用于測試的話題就存在了。
在AI飛速發(fā)展的今天，我們都見識到chatGPT的冰山一角。
大家紛紛討論，哪些職業(yè)可能會被chatGPT家族所取代。
對新技術(shù)，我通常會思考兩個問題。
1、挑戰(zhàn)是什么？ta能替代我們的哪些能力？
2、機遇是什么？ta有哪些能力可以為我們所用？

AI+測試，是一個值得思考的方向，也可能是我接下來期望致力于的方向。
等有更多成體系的想法與點子，再為諸位拋轉(zhuǎn)。

（轉(zhuǎn)載請私）