最近在作業中，看到一些新手測驗同學，對介面測驗存在很多疑問，甚至包括一些從事軟體測驗3，5年的同學，在聊到介面時，也是一知半解；今天借著這個機會，對介面測驗做個實戰教學，順便總結一下經驗，分享給大家，計劃拆分成4個模塊跟大家做一個分享，（介面測驗、介面基礎知識、介面自動化、介面進階）感興趣的小伙伴記得關注，希望對你的日常作業和求職面試，帶來一些幫助，注：文章較長有5000多字，希望小伙伴們認真看完，當然有些內容對小白同學不是太友好，如果你需要詳細了解其中的一些概念或者名詞，請在文章之后留言，后續我將針對大家的疑問，整理輸出一些大家感興趣的文章，
隨著開發模式的迭代更新，前后端分離已不是新的概念，現在大部分的專案都采用這種開發模式；當我們拿到待測驗需求時，可能后端已開發完成，但前端還未完成，我們需要進行介面驗證，那如何進行介面測驗？就這個話題，進行一個探討，我們先去做介面測驗，從結果上來分析到底需不需要做介面測驗，測驗哪些內容等等，開始之前，先虛擬一個產品需求：
需求描述：
假設我們要做一個全新的后臺專案，商品CMS管理平臺（這里拋去復雜邏輯，因為需求無限拓展下去，勢必大家對需求認知產生分歧，從而對測驗內容產生分歧），第一期的功能，商家用戶可以在平臺上進行商品的創建，編輯，洗掉，查詢，上下架等操作；運營用戶可以審核商家的商品；我們來簡單描述其中一個功能點內容：用戶點擊添加按鈕，跳轉到商品創建頁面，用戶需填寫商品名稱、商品價格、商品描述，類目資訊，商品圖片，商品庫存等資訊，以上欄位皆必填，且每個欄位的限制內容xxx；商品創建完成后，提交到運營進行審核，運營可根據實際情況審批提交的商品；需求檔案同時提供了商品的創建頁面，商品編輯頁面，商品串列頁，等頁面樣式稿設計，
計劃和目標：
在動手之前，設定計劃和目標，支撐保證質量的程序
計劃：1.需求分析 2.介面測驗用例設計 3.測驗用例評審 4.測驗準備 5.測驗執行
目標：介面質量達成
需求分析：
需求分析是所有執行程序中，最難的一個環節，因為有很多漏測都是因為我們事先沒有想到，或者沒有分析到；在后續程序中，出現和發現的問題（包括測驗計劃、上線回歸方案制訂）多多少少都是因為需求分析不全面所導致；當然，新手同學，因為各方面原因肯定做不到全面，不要想著一口氣吃個胖子；回過頭來說，如果做得好，在需求評審時，可以提出需求的不足，這樣把問題扼殺在需求階段，測驗時必然會輕松；當然你也會發現，有些產品的檔案漏洞百出，如果遇到這樣的檔案，把控質量更是難上加難，
1.功能點劃分
根據需求檔案，和產品同學的語言描述，需求核心是解決什么問題？
商品CMS管理后臺，為商家，運營提供商品管理功能
我們接著做功能點的詳細劃分：
我們從角色，角色行為（可以理解為誰，誰做了什么事）對功能做個劃分；其實準確的應該叫物件，物件行為，至于為什么要從這個角度入手，因為我們需要符合開發的思維習慣，確切地說是抽象業務的思維，找到所抽象的物件，以及物件的屬性和行為，這些東西就是我們測驗用例的具體驗證點，
功能點的劃分也讓我們得到了另一塊重要的內容：顯式需求可度量指標！我們在定制計劃和目標時，介面的目標是：介面質量達成，那我們就需要質量度量指標，也就是這里的7個功能點，作為分母，便于日后度量，當然僅僅從需求檔案中獲得的這些明確的度量指標是不夠的，質量的把控還需要另外一個關鍵指標：隱式需求指標，
介面質量=顯式需求質量+隱式需求質量
簡單地做個解釋，顯示需求，這個很好理解，就是需求檔案中已明確說明的功能點；隱式需求：為了達成某些功能，借助工具或者其功能實作這些功能，這些隱藏但是又客觀存在的需求，就是隱式需求，用當前需求舉例子：登錄和權限，開始我們說過，需求是全新的，肯定會涉及到登錄后臺的問題，如果在大公司里，會有一套統一的登錄系統，這個時候，我們對于不同的登錄實作，會采取不同的測驗手段，回過頭來再看需求檔案中，卻發現沒有對這兩塊內容做解釋，當然有的產品同學會詳細介紹權限這一塊的內容，不管怎樣，這些隱式需求都不會出現在需求檔案中（下文中我會對權限做一個詳細的需求分析，和測驗設計），于是我們有了明確的需求和隱藏的需求這兩個概念，
需求分析程序中，一個重要步驟，就是尋找隱式需求，這個程序是最難的，對于新手及其不友好，因為有些隱式需求完全在我們認知之外，但是需求不給我們學習的時間，等我們了解了隱式需求，知道該怎么測驗了，這時需求可能已經上線了，但我們可能都沒有去覆寫；
先拋不講，這時如果讓你去挖掘這個隱式需求，你會從哪些方面考慮？可以把自己想到的隱式需求做個記錄，看看和我下面的內容是否一致，或者寫下你的思路，
1.1隱式需求挖掘
思路嗎？這個很簡單，前面我們已經說了隱式需求的定義：“為了達成某些功能，借助工具或者其功能實作這些功能，這些隱藏但是又客觀存在的需求，就是隱式需求”，我們當然要從顯式需求上挖掘，看看達成這些功能點，需要什么工具，或者其他什么協助？
我們先抽象這里面的核心物件：商品！商品的屬性：商品名稱、商品價格、商品描述、類目資訊、商品圖片、商品庫存、商品狀態；商品的行為：添加、編輯、洗掉、上下架、審核、查詢，雖然查詢不嚴格屬于商品的行為，但是還是把它放到商品行為中，方便歸類，從商品的行為匯集到介面層面，我們可以分析出本次需求對前端會提供這樣幾個介面：
然后我們脫離需求本身，從提供介面的工具了解一些隱式需求：服務端通過spring框架幫我們提供了以上幾個介面，那程式員在提供這些介面時，都做了哪些作業？
1.）定義統一回傳體，我們都知道，多個不同的介面傳入正確引數時，回傳的結構體是一致的，正確的是同一個code，錯誤的有很多不同的code定義，比如：
2.）定義統一例外攔截，因為spring框架，對httpstatus定義的例外回傳，對我們來說理解比較困難，程式員需要把這些例外，定義成統一的回傳內容，供測驗或者其他同學方便閱讀，比如：
統一處理成：
3）登錄，所有的介面必須登錄過后才能正常請求；那么登錄在介面中到底是什么？是不是只有在前端頁面上才可以登錄？只測驗介面，該怎么登錄呢？其實這里我們需要了解登錄的原理，介面是如何處理登錄的？簡單地解釋一下：登錄的程序，其實是用戶使用賬號密碼，去請求登錄介面，登錄介面會在回傳頭中放置一個用戶身份唯一標識，然后下次請求，在請求頭中加入這個唯一標識即可，服務端在接受http請求時，會通過攔截器處理request header 中的資訊，來判斷當前請求是否登錄，好了知道這些資訊后，我們需要在測驗執行前準備測驗資料，當前登錄要配合權限一起使用，我們接著向下探討，
4）權限處理，后臺系統是怎么判斷，當前登錄的用戶是管理員，還是商家，還是運營人員？這里的實作原理和登錄有些類似，服務端在獲取當前用戶后，會查詢權限表中，當前用戶是什么權限，判斷他是否可以繼續下面的介面操作，
登錄和權限非常重要，會引出我們的測驗資料準備，在測驗用例評審過之后，我們需要準備測驗資料，特別是商家用戶、運營用戶、和管理員用戶（需求中沒有提及該角色，可以先忽略）都需要提前準備測驗賬號；另一方面就是知道了有攔截器的概念，我們不需要每個介面都去測驗是否做了登錄邏輯判斷，因為攔截器可以指定攔截想要攔截的介面，這使得我們的測驗更加準確，
5）統一日志處理
看到日志這里你或許會產生疑問，怎么日志也需要測驗么？這個也是需要的，回顧我們發生線上問題的時候，會發現排查線上問題的第一手段就是日志，假如我們的日志，打得不標準，或者關鍵資訊沒有打出來，勢必會影響線上問題的修復效率才生影響，關于日志這方面的測驗，可以算是程式可排查性，可恢復性的測驗；
好了，我們暫時從工具方面（和開發溝通）得到這些隱式需求，當然不止這些，那至于為什么我們要把這些需求作為隱式需求，也是有原因的，前面說過由于專案是首個專案，后臺前端都是全新的，如果你不在這個時候把控這些質量，如果在后續的程序中，再去修改，就會發現，改動的成本非常的大，可能回歸的范圍也非常的巨大，所以針對每個需求所處的階段、特性，我們都會去做采取不同的手段去執行需求分析；由于篇幅原因，我們就不再舉例子說明了，
2.介面測驗用例設計
有了以上顯式需求和隱式需求，我們開始設計測驗用例，描述用例的話術根據每個人的習慣撰寫即可，把核心的驗證內容描述清楚，評審時，大家能看懂就可以，先來看顯式需求測驗用例（由于撰寫軟體問題，有些場景只是簡單描述了一下，為了能在一個螢屏內截屏展示下，如果你是新手測驗同學，還是描述清楚較好）：
說下思路：我這里習慣把每一個功能點，按照正常和例外進行分類，先保證正常流程，然后會根據這條正常的用例，設計多條例外的用例，但是無論怎么分類，只要最后面的驗證點一致即可，
關于查詢的用例，我在這里補充一下，除了分頁查詢，串列查詢外，還有一個單體查詢，就是查詢單個商品，只要我們傳入正確的id，回傳整個商品物件，物件內屬性無缺失即可，例外場景可以傳入一個不存在的id，看下回傳是否報錯，
說下串列，這里唯一要注意的就是排序，如果需求檔案有明確指出是如何排序的，我們按照檔案設計用例即可，但是多數產品都會遺漏該功能點，其實這個驗證點，來自“串列”的特性，不了解串列特性的人不知道也不為過，另一個就是分頁，如果你是新手，可能只從介面回傳欄位上看，你并不知道分頁，到底需要介面吐出哪些欄位，這時需要結合介面檔案進行比較，（可能會遇到這樣的問題，我們在測驗程序中，并不知道后端提供的回傳引數是否能滿足前端的使用要求，假如分頁回傳了5個欄位，介面檔案和實際請求介面時你也看到了5個欄位，但是前端做分頁時需要6個引數，這個屬于正常情況）
例外的用例設計，一方面來自于例外流程場景，另一方面來自于構成這個物件的每一個屬性的例外，比如“商品名稱”欄位，既然是String型別，就會有長短限制，空限制等等，依次對每一個屬性進行例外測驗，類推遞增，形成基礎的用例，
這里比較難設計的，是例外的有效性，你會發現就某些物件屬性，有很多條例外場景，我們模糊不清，原因是我們不了解java中資料型別，哪些可以為數字型別，哪些可以為null，哪些可以為’'，所以在設計之初，會不分欄位型別，比如String型別的欄位，會設計例外入參傳入純數字123，這些即為無效的例外，因為這樣傳參，會回傳Http Status400入參例外，這就是一條無效的例外用例，但是回傳400也是我們的一個測驗點，只不過它不屬于當下這個場景，屬于隱式需求的測驗用例，下面我們來看隱式需求用例的設計：
每條用例最后的驗證點，沒有文字描述得很清楚，我這里只是為了說明思路，
直到目前為止你會發現我們每一條用例，產生的原因都是有根據的，不會像探索性測驗一樣，漫無目的的測驗；
我們把顯式需求和隱式需求的用例合并成一份用例，就可以拿去用例評審了，
我們要切記勿犯以下錯誤：
1）測驗用例生搬硬套產品需求檔案
2）明確測驗點，比如不要這樣去描述：商品創建介面，回傳內容正確，這里的驗證點需要明確知道，是哪一個欄位，操作步驟是哪個入參不正確，等等，
到了這里介面測驗最重要的流程已經過半了，我們需要停下來總結一下；你會發現介面層面的用例真正體現出需求檔案的內容基本上很少，除了最后的驗證點，我們執行步驟的分類，和需求關系很小，多數是介面的實作邏輯，了解介面的實作原理，才去這樣設計的；經歷過多個需求的介面測驗，你會發現，在介面層面的測驗，用例都大致相同，這是不是在追求效能的今天，可以對用例進行最大程度的復用，關于這點，可以關注后面的文章，我們也會對平臺建設方面，對用例復用提出一種新的見解，回過頭來，因為我們不是做黑盒測驗，既然是介面測驗，就需要測驗同學具備基礎能力，這樣才能保證質量，
3.測驗用例評審
我們拿到一份龐大的用例，可以在評審會上跟研發、產品掰扯很長時間，因為有些細節的地方還需要一一確認，比如每個屬性在例外時的報錯提示，需求檔案是否給出，提示是否合理等等，當然這要在大的思路正確的前提下，才去糾結這些細節，另一方面別忘了我們還需要確認些重要的內容，測驗同學作為小白，并不了解我們挖掘的這些隱式需求是否全面，我們還需要跟研發同學確認是否還有其他的隱式需求，我們還需要繼續補充隱式需求相關的測驗用例，還有就是，上面提及我們不確定物件屬性的例外到底有哪些，測驗設計的例外用例是否是有效例外？我們都需要和研發去溝通，
總結一下用例評審：
需求要解決的核心問題，確認后，作為最終上線驗收的標準，需要跟產品同學保持一致，不要功能都開發了，但是沒有解決用戶的問題，本末倒置，（團隊成員所做的事情方向和目標是一致的，大家以這個為最終檢驗標準，可上線）
顯示需求的確認，把檔案中明確內容，轉換成測驗用例，只需簡單確認驗證即可，注意這里不是生搬硬套產品需求檔案，而是要找出“明確”的驗證點，
隱式需求的確認和探討，我們除了把自己想到的隱式需求跟研發確認外，還需要讓研發幫忙補充更多的隱式需求，
細節的“拍板”，例外的提示，例外的有效性，需要達成明確的結果，
4.測驗準備
對于介面測驗來說，測驗資料的準備，可以加快我們的測驗執行，記得提前申請一下對應角色的賬號，另外我們還需要一款趁手的介面測驗工具，假如公司已有，我們直接使用即可，postman是非常不錯的工具，簡單方便快捷，推薦使用，這里我就不詳細講解工具的使用了，
5.測驗執行
簡單地來說介面測驗就是傳入一些引數，驗證介面出參的正確性，這里我們用http請求舉例子，在動手之前，我們使用工具幫我們完成：請求url，入參，請求頭的構建，發送請求以及回傳體接收作業，校驗回傳體中的內容，就是介面測驗執行校驗結果的主要內容，這個很簡單，我就不在提及，新手可以直接通過肉眼觀察看即可，postman的使用，我們會在后面詳細講解，
別忘了度量！～ 具體度量方法，我會讓再軟體產品質量度量中幫大家整理！
好了到此為止，以上就是有關介面測驗的整個實戰程序，其實還有很多細節沒有講清楚，但是由于篇幅原因，只能到這里，后續會繼續補充，喜歡的小伙伴點個關注～
最后：這里有我建立的一個專門交流軟體測驗方面問題的學習群，里面也有很多大公司的技術大牛，很多時候，技術大牛的幾句話就會讓我們醍醐灌頂，少浪費時間，如果想要多跟有經驗的人學習，就找我加入我的軟體測驗交流群，以后有作業的內推機會都相互推薦一下，畢竟我們是關系社會，
軟體測驗技術交流群社：786229024 等待你的加入... 大家可以一起探討交流，共同學習軟體測驗技術、面試等軟體測驗方方面面，還會有免費直播課，識訓更多測驗技巧，我們一起進階Python自動化測驗/測驗開發，走向高薪之路，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/553318.html
標籤：其他
上一篇：Unity中Button的調色
下一篇：返回列表