內幕：阿里老測驗員告訴你，新人如何做好功能測驗，學會這幾項

內幕：阿里老測驗員告訴你，新人如何做好功能測驗，學會這幾項

根據一份報告，應用程式崩潰導致71％的卸載，迫使用戶卸載應用程式的其他原因是頁面回應時間，混亂的UI，電池消耗等，這表明功能測驗和非功能測驗對于交付用戶友好型應用程式的重要性，

一、測驗基礎的重要性

作為一名測驗新人，測驗基礎非常非常重要，這里說的基礎，不僅僅是什么是軟體測驗、軟體測驗的目的，而是測驗用例的設計能力，

因作業的原因，近來接觸不少畢業3、4年，甚至7、8年的測驗同學，對用例設計還是停留在理論階段，這讓人不免有些無力吐槽，

問題：軟體測驗用例的測驗方法有哪些？
回答：等價類、邊界值、因果圖等等，
問題：結合實際的業務場景，來說說常用到的測驗用例設計的方法，
回答：不少回復都是以登錄來做說明的，

其實日常作業中，常用到的用例設計也就那么幾種，如果我們能把理論好好應用到實際作業中，那么漲薪其實也很容易，

那么，怎么樣才能設計出好的測驗用例呢？業務、業務、業務，重要的事情說三遍，

結合實際的業務場景設計用例非常重要，用例中不僅僅涉及到當前的功能，還需要把上下游關聯的業務考慮進去，盡可能覆寫完整，下面就來給大家著重介紹一番~

二、提升資料庫處理能力

作為一名合格的測驗人員，資料庫的增刪改查、關聯查詢是必會科目，但對于測驗新手來說，這個難度似乎有點大，很多人做事前往往關注的是表象，

比如：點擊保存、提交保存，那是否就判斷保存功能是正常的呢？

而正確的做法是，我們必須去資料庫中查看資料落庫的情況，確認欄位值是否存盤正確，涉及到有業務關聯的功能，也需要到資料庫中，對資料的準確性進一步確認，對業務資料流向做到心中有數才行，

三、具備定位問題的能力

在測驗程序中，我們經常會遇到介面報錯、例外錯誤資訊等情況，作為一名測驗新人，你可能第一反應就是直接丟給開發：“喂，兄弟，你這里報錯了，”

可是當開發人員問：“是前端還是后端報錯啊？”

你可能就只剩下一臉懵了，因為目前大部分軟體都是前后端分離的，所以，此時你要做的，就是學會看日志，

通過日志，初步判斷是前端還是后端問題，包括：借助抓包工具判斷是否是前端傳值傳錯了，還是后端邏輯處理錯誤等相關問題，并通過初步定位問題，幫助開發人員提升解決問題的效率等，

四、具備總結能力

作為測驗新人，我們要多總結，

博主曾問過一名剛畢業的同事，他有一套自己的總結方式比如：通過x-mind梳理總結/梳理業務，遇到的問題會記錄處理方法，在測驗作業中也形成自己的經驗總結，并將自己的方式分享到團隊中，這名同學在公司成長非常快，因表現突出，得到晉升，

作為一名技術同學，總結能力非常重要，在日常作業中我們會踩各種各樣的坑，將這些遇到的問題總結匯總形成經驗并分享給他人，在競爭中也能夠更加突出，在之后的作業中可以時不時翻出來看看，每次都會有不一樣的識訓，

五、適時做好能力提升

技術人員的永恒話題：技術水平的提升，

新人在前期成長非常快，在測驗程序中可以多思考，遇到問題想想是否有更好的方法解決，

之前聽說不少新人心態比較浮躁，動不動就想用自動化解決問題，但自己的自動化測驗水平有限，做起來問題層出不窮，

幾乎可以說是，走還沒有學會就想跑等問題，以為我們可以先打好基礎，做好功能測驗，在理解業務的情況下，考慮如何更加高效/高質量的完成測驗作業，

博主以為，其實有些同學在處理測驗作業時，很多時候是為了自動化而自動化，不少自動化框架既沒有運用到作業中，也沒有產生實際的價值，還沒有自己的思考，建議大家可以先做一個框架，然后引入一定的思考，結合業務來的做自動化測驗，

比如，可以從市面上已有的工具入手，

舉個例子：介面測驗工具jmeter/postman等等，先通過工具了解介面測驗流程以及方法，再結合自己的業務，發現當前測驗工具解決不了的問題，后期再結合業務開發平臺，不斷思考和實踐，

六、功能測驗的測驗作業流程

1、測驗計劃：這個計劃，我個人覺得應該在詳細設計確定后，代碼開始撰寫的時候進行制定，因為我是“提早開始測驗作業”思路的忠實fans.

a) 測驗計劃，主要是給后面的測驗作業一些指南，不能寫成領導看的計劃，而是要寫成由做事的人看的計劃

b) 包含的內容可能有：

• 測驗團隊人員及分工(要確定當測驗時出現缺陷界定、測驗環境準備等問題時能找到指定的人員)
• 測驗開始結束時間(理想情況下，不要安排的太緊，趕工肯定會造成延期或測驗不完整，可惜理想和現實的差距被規定為很大)
• 測驗環境配置(什么樣的硬體條件，是否網路、設備等，系統在什么地址訪問，訪問權限、使用的測驗資料等方面的預計和準備)
• 測驗哪些東西要說清楚，這里我建議把簡單的測驗大綱納入測驗計劃中，一方面領導可以看到你的計劃寫的多詳細，另一方面大綱可以很好的成為撰寫用例的依據
• 怎么測驗要說明白，如只做系統測驗，那就要寫清楚不做集成測驗，如果需要集成測驗，就需要寫明白集成順序，另外如果需要進行性能、檔案、等其他的測驗也要在這個計劃中寫明，雖然一般這個計劃都是針對功能測驗，但是如果有其他測驗，也要寫出來并安排時間，相應測驗的相關計劃等也需要指明
• 測驗結束標志(要說明測驗達到什么程度可以結束測驗，不能等到把所有缺陷都找出來以后才結束，因為那將是一萬年)，允許缺陷存留在系統里，我們只需要找到留多少這個度就夠了

2、測驗用例：這個檔案，主要描述具體的測驗步驟

但實際應用中，至少目前我的專案里，由于時間的原因，很少有寫的，就算寫了的，也基本沒有用到測驗里，在這邊的很多專案大都是直接來測，全憑我個人的經驗來檢查，

但是我想說其實他很重要，也許你不需要寫的很詳細，但是絕對需要通過這樣的步驟來理順思路，這個檔案的好壞和實用程度，直接可以決定你是否能“用最少的作業(量和時間)，盡早的發現盡可能多的缺陷”，寫這個檔案需要用到一些測驗方法理論，如等價類劃分、邊界值、這個表那個表(汗，，，忘記了)

3、缺陷記錄：是功能測驗程序中使用頻率最高的檔案，用于在測驗程序中記錄發現的缺陷，并由開發人員作為修改缺陷的依據，以及修改后測驗人員進行回測的主要依據

a) 該文當也有助于分析開發人員存在的“錯誤集群”現象，總結易出錯的地方，對缺陷多的部分做更深入的測驗，并提醒開發人員避免缺陷

b) 缺陷記錄填寫指南：

• 缺陷級別(即嚴重程度)，一般由公司統一定義，為發現的缺陷進行分類，以便決定修改的緩急
• bug分類：區分發生的位置，是功能的，還是性能的，是有效性問題 還是其他問題等，與bug級別一起，用于決定bug的修改要求度
• bug狀態：是標志bug的當前情況，標識是否被處置(關閉狀態)
• 上述這些指標一般由公司統一定義(一般標準都大同小異)，也會用于專案的度量

c) 缺陷記錄使用時的注意點：

• 描述bug要有三要素：在哪里，什么情況(前提)下，發生了什么樣的問題
• 可以借助截圖、參考位置、模塊等方式來描述bug，目的是讓開發人員能夠通過您的描述立刻馬上能夠重現bug，即使不能重現，也能讓開發人員了解到錯誤的所在
• 缺陷報告要由開發人員和測驗人員共同完成，測驗人員要督促開發人員填寫該表以便測驗后續的回測作業
• 如果是在執行用例的同時填寫bug報告，用例的最后一列一般可以填寫用例的執行結果，如果用例發生了非期望的結果，那么就要把問題記錄在缺陷記錄中，此時可以在缺陷記錄中參考該用例的編號

4、測驗總結報告：用于報告和總結專案測驗作業的執行結果，列舉和統計相關測驗資料，對比分析資料即作業中存在的問題為后續作業做出提示，并記錄遺留的問題等

總結報告的還有一個功能就是告訴專案組成員該系統已經按照測驗計劃的要求進行了測驗，并已經達到測驗計劃中說明的“測驗結束條件”，可以證明系統已經達到測驗計劃所期望的質量

最后

如果我的文章對你有幫助、如果你喜歡我的博客內容，請 “點贊” “評論” “收藏” 一鍵三連不收費哦！

標籤：其他

上一篇：10 月 30 日 北京 LiveVideoStack 阿里云視頻云專場限量贈票 100 張

下一篇：合并字典串列以洗掉所有重復項