一個測試的幾點感悟

    在新公司上班了兩個多月，有幾點感悟須要記錄一下。雖然書本上常常說這些原則，可是本身實際經歷過，踩過坑，感覺是徹底不同的。

    需求文檔越明確越好。關於需求文檔這一塊，感受永遠是開發和測試的痛。通常需求都是隻記錄整個程序最基本的功能，而那些輔助功能，異常情景處理，要麼是一筆帶過，要麼就是徹底被忽視了。這幾個項目的測試，發現一點，就是需求文檔裏面明確有的，開發基本上都會作出來，錯誤也比較少，而需求上沒有提過的，基本上都會錯漏。這體現了開發們的想法，我只是個寫代碼的，不要讓我去想業務邏輯，異常處理，文案提示啥的好很差，你都列出來，我就只管寫代碼好很差？並且，項目時間都是特別趕的，能把這些主要的功能邏輯實現已經着實不易了，哪還有時間去考慮什麼異常狀況了。甚至就算是很常識的問題，需求文檔沒說起，沒經驗的開發也可能會沒考慮到。我以前就遇到過，購物車上調整商品數量，能夠一直減減到負數的。因此說，需求越明確，開發出來的程序就越完善，bug也會越少，反而會更節省時間。有時候到了測試時期，才發現需求有些邏輯是自相矛盾的，就要從新定義邏輯，形成開發返工，致使功能都要重測，連鎖反應，延期在所不免。因而可知，開發和測試早早就要參與需求評審，若是開發前就能找出需求自己的bug，那該節省多少時間成本呀！順便說一下，我遇到的好多產品都沒有項目管理，項目流程之類的意識的，並且都以爲寫代碼很容易，吃飯前提的需求，設計圖都還沒出，就說下班前就要上線了。一環扣一環，每每測試時間是最被壓縮的。說了那麼多，單純想說，好的產品經理是項目成功的一半。

     產品是否上線該由產品經理決定。有時候測試時間過短，產品測試不完，或者遺留有bug開發沒時間改，而上線時間就定死在那。是否要上線不該該由測試決定的，而測試主要是要反饋產品的測試狀況，羅列出未解決的bug，能夠提出建議，最好不上線，能夠上線之類的。可是最後拍板應該由產品經理來。產品經理可以更好的評估風險。還有就是避免背鍋。

      編寫測試用例不該該照搬需求文檔的描述，要有本身的測試思路。其一，需求文檔自己是有漏洞的，若是徹底照搬需求文檔，只是把裏面羅列的功能點轉化成測試用例表述語言，就很難發現需求文檔自己的漏洞，會被帶跑偏了。通常來講，測試不能只關注程序自己，對於需求文檔，接口文檔要有一種質疑精神，都應該把這些產出物看成測試對象。其二，需求文檔的模塊劃分，功能排序等是按產品經理本身思考的邏輯的，有時候一直補需求補需求，整個文檔的功能順序是可能有點混亂的，若是測試用例的結構和需求文檔的結構同樣，是極可能不方便閱讀和理解，也不利於對照着執行測試的。

     接口測試時，必定要注意接口之間的依賴關係。雖然接口測試時沒有前端界面，但也要根據設計圖好好想一想接口是用於哪一個界面哪一個功能的。並且要注意驗證接口所產生的實際結果，不能被表象騙了，好比，一個帖子點贊接口，不能接口返回了點同意功就認爲這個接口是經過的，而是要調用帖子列表接口，查看點贊數是否正確。測試接口的時候，真的是要假想是有前端界面的，想象接口返回的數據可以匹配界面上展現的元素嗎？返回結果的排序正確嗎？結果是否有重複，列表翻頁是否正常？結果爲空，入參不正確等等狀況。

      測試時最好要用有意義的測試數據，這樣後面看到纔不會莫名其妙，有時候對提高測試效率也是頗有幫助的。測試時也要有一種思惟導圖的那種思惟，大模塊，大功能，小功能，注意細節，特殊狀況。最好可以作到一看到界面，腦海就能造成一份測試用例。對了，測試時，界面的一些小元素常常會被忽略，好比頭像旁的暱稱，評論的發佈時間，右上角的更多按鈕等等，還有界面標題很容易被遺忘。

      此次先說那麼多，一個月後再來吐吐槽吧。