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

前言

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

一、測試基礎的重要性

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

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

問題：軟件測試用例的測試方法有哪些？

回答：等價類、邊界值、因果圖等等。

問題：結合實際的業務場景，來說說常用到的測試用例設計的方法。

回答：不少回復都是以登錄來做說明的。

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

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

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

二、提升數據庫處理能力

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

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

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

三、具備定位問題的能力

在測試過程中，我們經常會遇到接口報錯、異常錯誤信息等情況。作為一名測試新人，你可能第一反應就是直接丟給開發：“喂，兄弟，你這里報錯了。”

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

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

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

四、具備總結能力

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

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

五、適時做好能力提升

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

新人在前期成長非?？?，在測試過程中可以多思考，遇到問題想想是否有更好的方法解決。

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

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

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

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

六、功能測試的測試工作流程

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

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

b) 包含的內容可能有：

測試團隊人員及分工(要確定當測試時出現缺陷界定、測試環境準備等問題時能找到指定的人員)

測試開始結束時間(理想情況下，不要安排的太緊，趕工肯定會造成延期或測試不完整，可惜理想和現實的差距被規定為很大)

測試環境配置(什么樣的硬件條件，是否網絡、設備等，系統在什么地址訪問，訪問權限、使用的測試數據等方面的預計和準備)

測試哪些東西要說清楚，這里我建議把簡單的測試大綱納入測試計劃中，一方面領導可以看到你的計劃寫的多詳細，另一方面大綱可以很好的成為編寫用例的依據

怎么測試要說明白，如只做系統測試，那就要寫清楚不做集成測試，如果需要集成測試，就需要寫明白集成順序。另外如果需要進行性能、文檔、等其他的測試也要在這個計劃中寫明，雖然一般這個計劃都是針對功能測試，但是如果有其他測試，也要寫出來并安排時間，相應測試的相關計劃等也需要指明

測試結束標志(要說明測試達到什么程度可以結束測試，不能等到把所有缺陷都找出來以后才結束，因為那將是一萬年)，允許缺陷存留在系統里，我們只需要找到留多少這個度就夠了

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

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

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

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

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

b) 缺陷記錄填寫指南：

缺陷級別(即嚴重程度)，一般由公司統一定義，為發現的缺陷進行分類，以便決定修改的緩急

bug分類：區分發生的位置，是功能的，還是性能的，是有效性問題 還是其他問題等，與bug級別一起，用于決定bug的修改要求度

bug狀態：是標志bug的當前情況，標識是否被處置(關閉狀態)

上述這些指標一般由公司統一定義(一般標準都大同小異)，也會用于項目的度量

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

描述bug要有三要素：在哪里，什么情況(前提)下，發生了什么樣的問題

可以借助截圖、引用位置、模塊等方式來描述bug，目的是讓開發人員能夠通過您的描述立刻馬上能夠重現bug，即使不能重現，也能讓開發人員了解到錯誤的所在

缺陷報告要由開發人員和測試人員共同完成，測試人員要督促開發人員填寫該表以便測試后續的回測工作

如果是在執行用例的同時填寫bug報告，用例的最后一列一般可以填寫用例的執行結果，如果用例發生了非期望的結果，那么就要把問題記錄在缺陷記錄中，此時可以在缺陷記錄中引用該用例的編號

4、測試總結報告：用于報告和總結項目測試工作的執行結果，列舉和統計相關測試數據，對比分析數據即工作中存在的問題為后續工作做出提示，并記錄遺留的問題等

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

最后

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

Postman web前端 數據庫 自動化測試 軟件開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。