測試思維

????????? 測試思維是體現(xiàn)在測試用例上的。我們在編寫測試用例的時候千萬不要撒網(wǎng)式搬需求，寫的全部是需求本身，特別是使用腦圖形式這樣寫，一眼望去全是網(wǎng)，條理混亂沒有任何測試思維其中。我們用例模塊層級盡量不要超過三層，測試點盡量一句話簡潔描述，條理清晰具有測試思維在里面。雖然用例最終是測試人員執(zhí)行的，但一個好的測試用例是可以幫助開發(fā)梳理需求、提前避免一些異常情況出現(xiàn)，甚至可以讓開發(fā)直接拿來開始寫業(yè)務(wù)代碼，也好規(guī)避一些異常問題，同時也幫助產(chǎn)品發(fā)現(xiàn)一些未明確的問題。

????????? 測試從需求開始。我們可以在需求出來后就開始測試，從需求開始到提測階段，雖然該階段沒有成形的產(chǎn)品出來，但我們可以通過需求發(fā)現(xiàn)一些未知的風(fēng)險，該階段大多是需求未明確點、需求之間沖突的點；需求完后就是服務(wù)端接口。我們可以跟隨服務(wù)端同學(xué)寫的接口文檔，了解業(yè)務(wù)在接口層面的一些邏輯、幫助后期測試定位問題來源，該階段大多是接口與需求沖突、接口中泄漏用戶隱私、接口中有一些不安全字段暴露； 然后就是UI設(shè)計稿?？梢宰卟閁I設(shè)計稿當(dāng)中的一些問題，提前排查服務(wù)端返回來的字段值在UI展示上限制，大多情況UI會落下部分頁面的空頁面UI以及斷網(wǎng)情況。

?????????? bug從哪來。保證產(chǎn)品質(zhì)量單靠測試人員根本不可能完成。要靠該項目組的每一個人共同把控質(zhì)量。測試過程中出現(xiàn)的bug的來源有這些情況：產(chǎn)品需求未覆蓋到、產(chǎn)品需求之間沖突、開發(fā)理解需求有偏差、開發(fā)未詳細看需求、客戶端未詳細看UI設(shè)計稿、服務(wù)端由測試環(huán)境部署到正式環(huán)境異常、產(chǎn)品前端服務(wù)端測試獲取信息不一致、前后端聯(lián)調(diào)時接口對接問題、接第三方sdk時未知坑問題、開發(fā)包打好了忘進代碼、代碼混淆導(dǎo)致的問題、開發(fā)遺漏部分異常情況的處理、接口字段值格式變動導(dǎo)致客戶端不識別（特別是時間）、代碼本身的問題。還有一些問題是測試構(gòu)造測試數(shù)據(jù)導(dǎo)致的問題，我們應(yīng)當(dāng)避免此類情況發(fā)生。

????????? 偶現(xiàn)的bug。嚴格意義上說根本不存在偶現(xiàn)的bug，只是沒有找到必要環(huán)境下的必現(xiàn)路徑。對于偶現(xiàn)的bug我們測試是很頭疼的，開發(fā)也頭疼，無從下手。對于在測試前期偶現(xiàn)一兩次的bug，發(fā)現(xiàn)后根本無法復(fù)現(xiàn)的話，后期觀察處理；對于偶現(xiàn)概率比較高就盡最大努力復(fù)現(xiàn)，如果完全相同操作這個bug時而出現(xiàn)時而不出現(xiàn)的話，那這個bug 90%是跟響應(yīng)時間上有關(guān)系，可以在一些頁面切換臨界點上操作去復(fù)現(xiàn)；如果高概率偶現(xiàn)的bug沒有注意到必現(xiàn)路徑，不知道怎么出現(xiàn)的，就用排除法，每一個操作路徑去遍歷找復(fù)現(xiàn)路徑，或者下載一個錄屏工具，集中操作一會兒回看操作步驟復(fù)現(xiàn)；還可以用跳躍思維，就是不要按部就班正常操作復(fù)現(xiàn)，跳出當(dāng)前思維尋找其他操作情況。當(dāng)然我們發(fā)現(xiàn)偶現(xiàn)的bug先提交給開發(fā)，有時候偶現(xiàn)的bug開發(fā)會找到根本問題的，后面測試有時間再復(fù)現(xiàn)。偶現(xiàn)的bug出現(xiàn)后影響用戶正常使用或影響關(guān)鍵數(shù)據(jù)（如金額），這類bug一定要改，如果偶現(xiàn)的bug出現(xiàn)后不影響用戶正常使用，根據(jù)情況可暫且觀察。

????????? 多從實際用戶角度出發(fā)測試。之前就出現(xiàn)過問題，在app內(nèi)視頻在移動網(wǎng)絡(luò)下各個功能均正常，測試沒問題，但是發(fā)版后，發(fā)現(xiàn)大部分用戶進入app無法觀看視頻，這個是我們在測移動網(wǎng)絡(luò)時，是在無線網(wǎng)下啟動app，然后切換成移動網(wǎng)絡(luò)漏測的。實際用戶本身就是移動網(wǎng)絡(luò)下啟動app的；還有一次是移動網(wǎng)絡(luò)下給用戶提示耗費流量，因為在辦公室，將手機聲音調(diào)的特別小，在移動網(wǎng)絡(luò)下測的時候是給用戶提示的，但是發(fā)版后發(fā)現(xiàn)，用戶在移動網(wǎng)絡(luò)下看視頻有這個提示，但提示過程中，視頻的聲音還在繼續(xù)進行著。所以我們要在測試過程中保證是實際環(huán)境。

????????? ? 測試方法。具體測試方式是圍繞著需求展開的。測試的時候是遵循一個大樹邏輯，由樹干到樹枝再到樹葉走向，先把最重要的部分測試也就我們常說的冒煙測試，然后再各個模塊功能走通，其次是各個功能當(dāng)中的業(yè)務(wù)細節(jié)。注意以上說的只是我們正向測試也就是滿足需求部分測試，這些走通后就是逆向測試，也就是各種異常交互情況，如斷網(wǎng)、弱網(wǎng)、非正常操作，有時候開發(fā)在寫代碼時處理異常情況要比需求還寫的多，所以異常情況同樣重要，但是他的測試時間優(yōu)先級比正向測試稍低一些。

?????????? 確保不要漏測，絕對的測試完整是不可能的，但首先我們要保證需求部分功能一定完成明確，其次是用戶常用的操作流程、然后是異常情況。在測試中帶著傻瓜式為什么的思維去測試，因為一個產(chǎn)品成形也是從一張白紙開始的，是開發(fā)一行一行代碼讓這個傻瓜具有一些思維的，但難免會落下什么。

?????????? 舉個例子，如自動售貨機，先大概理一下，輸入錢，選擇貨物，出貨并有可能找零錢。一步一步走，記得自動售貨機是個傻瓜，首先投入錢。

售貨機：‘什么是錢’，此時我們就可以圍繞什么是錢展開。--------測試點：一分、五角、一元硬幣、一毛、五毛、一塊、五塊、十塊、五十塊、一百塊人民幣分別投入是否生效

售貨機：‘我怎么知道你投錢了’。---------測試點：驗鈔機測試

售貨機：‘只要檢測到錢就算投幣成功了嗎’。--------測試點：投紙幣一半再抽出來

售貨機：‘我怎么知道哪些紙幣是有效的’。--------測試點：殘缺紙幣、直接一張白紙、紙幣折疊不整齊等

售貨機：‘是個圓片都認硬幣嗎’。--------測試點：游戲幣、塑料圈、啤酒瓶蓋

售貨機：‘這么多錢我怎么計算’。--------測試點：計算準確性測試點，

售貨機：‘一塊紙幣+一塊紙幣=兩元，一元硬幣+一元硬幣=兩元，一塊紙幣+一元硬幣=啥’，---------測試點，不同金額形式組合測試

售貨機：‘我怎么知道你要買什么’。--------測試點：單選貨物，多選貨物

售貨機：‘我怎么知道你投的錢就值買的貨’。--------測試點：金錢大于買的貨物時找零，金錢小于買的貨物時不能選貨物，金錢等于買的貨物時，不找零

售貨機：‘我拿什么給你找零’。--------測試點：上述條件下，存儲的零錢大于等于找零錢時找零，小于時無法購買成功或者提前給用戶提示

售貨機：‘我怎么知道我有貨物’。--------測試點：沒有對應(yīng)貨物時不能選擇該貨物，有對應(yīng)該貨物時可選擇

等等等。。。。售貨機偏向流程功能，所以應(yīng)當(dāng)按照事務(wù)處理，只要這個流程中一個環(huán)節(jié)出問題該流程就失敗，其實有發(fā)現(xiàn)我們在能不能找零的那個測試點上發(fā)現(xiàn)了一個需求問題，當(dāng)沒有找零存儲錢的情況下此時怎么處理？以上只是一小部分的測試點，還有一異常情況，使用過程中斷電了，投入的是美元、售貨機出問題了不出貨（其實這個問題拋出了一個產(chǎn)品運營問題，要在售貨機上貼上服務(wù)熱線電話，以便處理實際的異常情況）。

????????? 售貨機就像我們的前端，那有前段起碼就有服務(wù)端，也就是數(shù)據(jù)回傳（貨物與零錢）以及統(tǒng)計打點，千千萬萬個售貨機怎么管理統(tǒng)計，此時就引出了打點測試。打點測試其實很重要，要不然售貨機都報廢了都不知道什么情況，如果當(dāng)中出貨或者投錢統(tǒng)計錯誤，有時候會給管理人誤判，以為今天賺百萬，實際售貨機都讓人給搬走了。引出了打點、數(shù)據(jù)監(jiān)控以及售貨機本身運作狀態(tài)監(jiān)控的測試點。產(chǎn)品可以根據(jù)打點情況來調(diào)整接下來的產(chǎn)品需求改善情況，有些是靠廣告來增加收入的，所以打點測試非常重要。

????????? 除過打點重要外，對于app測試當(dāng)中還有一個很重要但大家很容易忽視的，就是升級安裝測試，如果發(fā)版之后發(fā)現(xiàn)app升級有問題無法升級，那將有一大批老用戶會丟失掉的，還要產(chǎn)品下架重新?lián)Q新版，所以每一個版本都要進行升級安裝測試。