一篇文章帶你入門軟體測試
由於計算機就業形式所迫，針對開發的要求逐漸嚴苛，因此在此場景下測試開發就變成了一條相對比較容易的道路
所以今天這篇文章我們會從以下角度去學習軟體測試，帶你瞭解軟體測試的基本工作：
- 軟體測試概念
- 軟體測試方法
- 軟體測試缺陷
- 真實測試場景
軟體測試概念
我們首先需要去學習軟體測試的相關概念
軟體測試基本概念
首先我們需要知道軟體測試是什麼：
- 軟體測試是針對已開發的專案進行多方位的檢測來使專案可以滿足使用者的基本需求
- 軟體測試通常是為了找到Bug並提出進行修改，使專案滿足使用者的基本需求不受影響的同時最佳化使用者的使用體驗
此外我們需要一個很重要的概念：
- 軟體測試是為了以儘可能少的時間對軟體整體功能進行檢測，保證不出現重大問題
- 軟體測試只能以找尋Bug並修改Bug為目標，軟體測試是無法找到所有的Bug的，在保證基本功能不出現問題的基礎上去發掘深處Bug
軟體測試主流技術
一般在公司專案中主要分為以下五個步驟（並不是很專業的分類，但專案開發主要是以下流程）：
- 需求分析
- 前端/後端開發 + 測試書寫測試用例
- 前端/後端聯調
- 測試並修改Bug
- 產品經理驗收專案
而這過程中，留給測試人員去測試的時間通常是很短的，大概只有一或兩天的時間
所以我們需要去書寫最為全面的測試用例以及熟悉專案的整個操作流程，以便於我們在實操時效率的提升
現在我們就需要知道測試所需要的主要技術：
- 快速上手專案：在小公司中通常一個人會去管理多個專案的測試，因此快速去熟悉專案流程是測試人員所必須的
- 測試用例書寫：一般測試用例會在XMind上去書寫，具體的書寫方法和書寫技巧我們在後面會講到
- 功能測試：基礎測試人員必須的技能，需要我們按照測試用例去“點點點”，保證專案功能的基本實現，需要涉及專案所有情況
- 自動化測試：採用自己所書寫的小工具使人工操作轉化為機器操作（進階內容，目前不需要掌握）
- 介面測試：介面測試實際上只是功能測試的一個模組，一般使用PostMan或者Charles抓包工具
- 效能測試：效能測試通常是為了測試專案的執行速度，設定多執行緒執行多次的方式來進行測試以及弱網環境測試等
軟體測試主流分類
軟體測試分類主要從兩方面進行分類，下面我們從兩方面進行講解
階段測試
我們首先講解一下階段測試是什麼意思：
- 階段測試通常是以我們需要測試的模組大小來進行分類
我們通常把階段測試分為四種：
- 單元測試：單元測試是指標對於某個功能進行測試，這一點通常是前後端進行聯調時進行測試
- 整合測試：針對介面和介面之間進行測試，也被稱為介面測試
- 系統測試：根據需求文件對整個專案所開發內容的完整性和相容性進行測試，也就是測試人員的測試環節
- 驗收測試：公司內部人員對專案進行測試或者說實際使用，也就是產品經理驗收測試
方法測試
我們可以根據對程式碼的可見度將其劃分為以下三種測試：
我們來簡單介紹一下：
- 黑盒測試：主要針對功能（階段劃分->系統測試）
- 灰盒測試：針對介面測試（階段劃分->整合測試）
- 白盒測試：針對程式原始碼進行測試（階段劃分->單元測試）
軟體測試角度
我們在進行軟體測試時需要從多角度去進行考慮：
- 功能性：是否能滿足需求所需功能
- 相容性：是否能在多平臺（PC，Android，IOS）下均可以執行
- 易用性：是否簡單易操作，是否引導/流程清晰
- 可靠性：軟體壽命是否長久
- 效能性：是否高效，執行速度是否快
- 安全性：軟體是否安全，是否可能暴漏使用者資訊
- 可維護性：在後續版本中是否便於維護
- 可移植性：該專案在後續是否便於移植至其他伺服器
軟體測試流程
在公司開發中，測試組需要進行以下步驟：
- 需求分析：由專案經理發放需求並進行統一講解，保證各方面都完全理解需求
- 計劃編寫：由主管來指定本次測試由誰來負責
- 用例設計：由測試人員來書寫測試用例
- 用例執行：待開發結束提測後，由測試人員根據測試用例執行來找尋Bug
- 缺陷管理：由測試人員找尋Bug並提出Bug，再不斷修改並進行測試
- 測試報告：書寫測試報告文件
軟體測試方法
在這一章節我們會介紹書寫測試用例的方法
測試用例書寫
我們一般採用Xmind並根據需求表來進行測試用例書寫：
- 我們首先根據需求表將其劃分為多個模組進行測試
- 根據每個模組所需要驗證的功能再次進行劃分
- 針對具體功能我們需要去書寫前置條件+執行流程+執行結果
針對最後一步我們給出一個簡單示例：
- 假設我們需要給一個頁面做登入需求
我通常會採用下面兩種型別來設計登入所需資料：
而根據流程的長短還會有不同的測試用例設計方法，我們這裡就不舉例說明了
窮舉場景用例
我們在進行測試時，我們一般會需要測試所有的場景資料,但針對於窮舉場景我們肯定是無法全部窮舉測試的
例如我們註冊賬號時需要5~12位數字當作賬號，但是我們肯定無法全部測試
所以我們就需要一種新的方法——“等價類劃分法”來幫助我們完成這種測試：
因此我們可以將同一種情況的有效值和無效值劃分為一種型別去進行測試，拿我們上述的賬號註冊來舉例：
上述情況是針對單個條件時的窮舉場景展示，但是針對多情況時我們就需要控制變數：
- 正向用例：一條儘可能覆蓋多條
- 逆向用例：每一條資料，都是一條單獨用例
例如我們有一個新的案例：
-
我們需要驗證某個城市的手機號是否正確
-
手機號由以下三部分所組成
-
區號：空/3位數字
-
字首碼：非“0”且非“1”開頭的3位數字
-
字尾碼：4位數字
我們就可以寫出以下的測試用例：
邊界場景用例
我們在測試時，通常需要去檢測邊界，因為邊界是最容易出現問題的地方也是我們需要去詳細區分的地方
例如我們以下兩個場景的使用：
- 使用者名稱稱長度要求在5~12字元：那麼我們就需要去判斷5-12之間是否滿足條件，這是等價類劃分
- 但是我們需要注意的是：我們還需要去確認5和12是否滿足條件，以及4和13是否不滿足條件
因此我們如果採用這個特性，假設我們需要去判斷一個6~10位的qq號是否滿足條件，我們就需要兼顧更多情況：
最後我們可以注意到邊界值法其實是可以和窮舉場景法進行組合使用的，我們可以將所有情況劃分為5種：
- 不滿足條件前置點：4位
- 滿足條件前置點：5位
- 滿足條件測試點：8位
- 滿足條件後置位：12位
- 不滿足條件後置位：13位
多條件場景用例
最後我們來介紹一下多條件下如何去書寫測試用例
首先我們通常將條件稱為“條件樁”，將結果稱為“狀態樁”
我們仍舊給出一個簡單的例子：
- 假設我們給出一個訂單資訊，訂單包含“金額”和“狀態”兩個屬性
- 當金額>500且未過期時，我們允許傳送批准單和提貨單
- 當金額>500但過期時，我們不允許傳送批准單和提貨單
- 當金額<500時無論是否過期，我們允許傳送批准單和提貨單
- 當訂單過期時無論金額大小，我們允許傳送通知單
針對多條件情況，首先我們需要將所有情況都羅列出來，然後在最後給出對應的結果展示（當然可以在Xmind也可以在Excel）：
錯誤推測法
最後我們給出一個我們在正常測試中經常使用到的方法：
- 當專案用例都執行完畢，且BUG修復完成，離上線還有一段時間，這段時間中可使用錯誤推薦法複測主要業務或測試未覆蓋的功能。
軟體測試缺陷
最後我們講一下缺陷，也就是我們經常提及的Bug
軟體測試缺陷定義
首先我們需要了解什麼是缺陷：
- 軟體中存在的各種問題，都為缺陷，簡稱bug
我們如何去判斷該缺點是否為缺陷：
- 在我們的測試用例執行過程中出現執行結果與用例的期望結果不一致的情況為缺陷
- 在我們測試過程中所有出現不符合正常功能的情況以及不便於我們測試的情況統稱為缺陷
缺陷通常會劃分為以下幾種：
- 功能使用缺陷：需求功能無法實現
- 功能個數缺陷：當出現功能多於或少於需求功能
- 隱性功能缺陷：軟體需求中所隱性存在的需求如果沒有實現也被稱為缺陷
- 易用性缺陷：當出現不便於使用者直接操作或需要一系列前置操作的功能也被稱為缺陷
而缺陷產生原因也具有多種情況：
- 需求文件未標識
- 架構設計存在問題
- 前後端開發編碼存在問題
- PC，IOS，Android等適配性問題
軟體測試缺陷提交
我們身為測試人員，主要負責發現Bug並且判斷問題產生原因交給對應的前後端人員進行處理：
因此我們在缺陷提交時，通常需要注意以下幾點：
- 缺陷名稱：模組 + 問題
- 缺陷來源：採用F12或Charles抓包工具判斷前端問題還是後端問題併傳送給對應開發人員
- 缺陷的預置條件：缺陷產生的前置條件，我們需要完全說明
- 缺陷的復現場景：由於缺陷的出現具有機率性，可能是必現bug也可能是有機率出現的bug，我們需要將復現操作書寫出來
- 缺陷的實際結果：我們需要將對應產生的錯誤結果書寫出來以及缺陷應該出現的正確結果
- 缺陷的必要附件：例如出現缺陷時的截圖，出現缺陷的日誌資訊等
缺陷執行的具體流程我們可以參考下述流程圖來理解：
真實測試場景
下面我們藉助這一章節來講解企業中真實的開發場景以及測試人員需要去做什麼
企業執行流程
企業中一般會劃分為以下幾個角色：
- 產品經理：負責和使用者溝通，收集使用者資訊需求
- 前端開發：負責前端頁面的開發，基本聯調
- 後端開發：負責後端功能的開發，基本聯調
- 測試開發：負責軟體測試以及自動化測試工具的開發
企業執行流程：
- 產品經理收集使用者需求，製作需求頁+基本展示圖，製作結束後分給前端後端測試人員檢視
- 組內小會，由產品經理和前端後端測試人員一同開會，講解使用者需求，讓三方明白其專案的所有需求資訊
- 前端後端進行開發，同時測試人員進行測試用例的書寫並且熟悉專案內容以及操作，便於後續測試時加快效率
- 前後端均開發完畢後，雙方進行聯調，檢視功能是否出錯，聯調結束後提測，由測試人員進行測試
- 測試人員將會測試多次，測試過程中出現問題在公司對應平臺上傳送缺陷修改請求，前後端修復後需要進行迴歸測試
- 測試人員大概會重複三次大版本測試，並不斷針對已修改缺陷進行迴歸測試，並測試與該回歸測試相關的功能
- 最後測試人員測試結束，由產品經理進行驗收測試，判斷專案是否可以上線
企業測試注意點
我們在工作中通常測試時間是被壓縮的很緊的，因為開發時間通常會佔用專案的大部分時間，導致測試需求非常緊急
因此我們必須掌握對應技巧，才能又快又好的滿足企業需求，我下面羅列幾點我認為很重要的地方
測試用例
測試用例的書寫我認為有以下幾點需求：
- 首先我們需要充分理解需求，針對不確定的需求及時和產品溝通，否則可能出現漏測，誤測等情況
- 針對測試用例的書寫我們首先需要劃分為幾個大模組，然後針對各個模組分開書寫，以大化小，方便書寫
- 針對新開發的功能頁面等，我們首先需要確定頁面的按鈕有什麼作用，針對每個按鈕（功能）書寫對應的測試用例
- 針對資料測試時，我通常將型別劃分為數字（123），字元（ABC），特殊字元（！@#）來進行判斷
- 針對資料測試時，我通常將數值劃分為不滿足條件前置位，滿足條件前置位，滿足條件後置位，不滿足條件後置位來進行判斷
- 針對流程測試時，首先羅列第一個條件的所有情況，然後在第一條件下去繼續羅列後面的n個情況，注意去除重複情況來減少工作量
- 針對需要操作的專案，我們可以直接在測試用例上寫出我們所需要建立的數值，我們所需要進行的操作，直接完全按照測試用例操作
- 針對複雜的專案，我們可以將一些較為複雜的操作單獨列出一條邏輯線來記錄具體操作
測試過程
測試過程中我認為需要注意的有以下幾點：
- 積極和前端後端人員溝通，積極的溝通有利於你們快速定位Bug並修改Bug
- 注意測試時的重點部分，工作畢竟是令人煩躁的，我們應該首先去著重處理較為複雜的部分
- 注意缺陷的重要程度，因為有些缺陷可能會導致我們後續的測試無法進行，我們應該和前後端溝通讓他們優先修改這些缺陷
- 針對已修復的缺陷，我們首先需要去做迴歸測試，在迴歸測試的同時我們需要注意去測試與之相關的功能，檢視是否受到影響
- 測試是最後一環節，關係到專案能否順利上線，因此時間分配上需要注意，針對難以修改但影響不大的缺陷我們應溝通在下版本修復
結束語
這篇文章主要介紹了測試所需要的一些基本資訊，希望能為你帶來幫助！