前面研究了很多自動化，有時候覺得有點好高騖遠的意思，但是這些技術有時候確實需要。回頭想想，基本的功能測試好像還做不好，用例寫的也不是特別好用，還研究一堆技術。這篇文章以後應該會不斷增加內容，寫一些功能測試遇到的特殊點，距離上一個大專案時間有點長了，可能會漏一些東西，先把能記起的寫這裡。

一般用例設計都會說等價類、邊界值。說都好說，真正寫用例的時候，可能就漏了一些。

等價類，我理解的輸入框輸入字母、數字、漢字、特殊字元、空、全形，根據實際情況，測試哪些哪些能輸入，哪些不能輸入，特殊符號比較多，如果都試下來有點麻煩，我最常試的幾個：'|\%*#=;還有空格，可能還有特例沒發現（還有容易出bug的請下面評論一下，也像各位學習一下經驗）。空格有些輸入框可以輸，會自動去掉前後空格。感覺如果有問題，只會在前面幾個。去年一個測試測一個小介面，試了多個異常都給攔截了，我讓試試’和|，果然這倆都成功通過，後面幾個特殊符號都攔截了，也算提了兩個小bug。

邊界值一般都想到輸入數字大小，長度。上個專案快上線的時候，突然想到一種情況，日期的邊界值，從嬰兒到兒童、兒童到成人的轉變，試了一下，果然過了生日，沒那麼智慧的把嬰兒變成兒童，把兒童變成成人。日期還有一種情況，選擇嬰兒型別，輸入兒童生日，不過這個在很早就試了。

上面的情況不只看能不能攔截異常，還要看報錯資訊是否準確，比如：密碼格式有誤和密碼只能是8-20位字母和數字。

上個專案很大，分PC端會員中心、手機端會員中心、會員後臺、還有多個渠道的會員介面，一開始是非常明確的只測一種，後來測了一段時間，由於有點懶了，直接從介面加了很多資料，然後去會員中心用，在這個時候又發現問題了，介面新增的資訊，會員中心修改不了，包括PC端和手機端，只用這倆都會出問題，後面就又試了多種渠道互相驗證。

還有一處我覺得我運氣相當好，專案也涉及了資料遷移，從生產上遷移到新的資料庫，自然測試環境也有了生產資料，隨便找了幾條資料，發現在會員中心的時候，有的賬號報異常了，去會員後臺看，顯示的是正常。進資料庫裡找了一會兒，幸好資料庫幾乎每個欄位都有備註，很快發現賬號確實異常，但是在後臺沒判斷那個欄位，只判斷了另一個欄位。涉及到資料遷移真得好好看看，尤其兩次資料庫表是兩個公司設計的，老資料性別用的0、1表示，新資料性別用的M、F表示，遷移過來自然0、1的不能正常顯示出性別。類似這種情況還發生幾處，都是後面發現的。

後面測試多了，也想試試用Appscan掃描一下有沒有漏洞，但是之前沒用過，而且電腦一直阻止Appscan執行，後面也沒仔細研究，有專門測試安全的公司。後來領導說發現了一處，修改返回值，會出異常，大概步驟就是登入時候輸入錯誤的賬號和密碼，然後攔截介面返回資料，把返回的狀態碼改為登入成功的狀態碼。用fiddler試了一下，果然修改以後，再看頁面，像是登入成功的頁面，裡面還有點資訊的樣子，實際資訊都是假的，但是被要求一定要改。還有一次可能是網絡卡了一下，新增資訊滑鼠點了兩次，結果真添加了兩次，實際只能新增一個，後來也用fiddler攔截試了一下，發現fiddler真是好東西，可以攔截請求，還能攔截返回值，修改返回值。還有一處用了fiddler，修改密碼的時候，需求裡寫的密碼一定要8-20位字母和數字組合，前端頁面攔截了純數字或者純字母的情況，但是使用fiddler攔截請求，在裡面修改引數，可以把密碼改為純數字或純字母了。

基本問題就是這麼多，不過感覺在需求評審階段就發現問題真的很管用，需求評審時候已經填了很多坑，主要業務上的坑，如果業務不熟，恐怕測試時候難免漏了一些。就像這兩天那個很火的產品經理一樣，開發的圈子怎麼說我不知道，測試圈子很多人都在說：要我我也得打他。

從技術上來說，我覺得是有點異想天開，腦洞簡直比測試腦洞還大，在討論怎麼實現的時候，我也想了一下這個需求：強制啟動手機前置攝像頭，對使用者眼角膜的手機倒影進行影象分析。強制啟動手機前置攝像頭感覺很像流氓軟體，然後這會兒使用者正在看手機呢，肯定看手機正面，即使技術真實現手機倒影影象分析了，眼角膜裡最多的恐怕是APP的預設主題顏色吧。如果說再去掉螢幕那一塊，只識別邊上。最近vivo出的一款手機好像已經沒有邊了，全是螢幕。最重要的一點，如果正面是白色，背面是金色，我覺得金色肯定是識別不到的。所以可以說：需求評審不通過，哈哈，這個時候感覺自己很強大，在測試群裡說，還有很多擁護者。比較靠譜的需求：可以根據天氣變化主題，用一個查詢天氣的介面，再需要一個位置資訊，應該就可以了。