軟體測試 / 測試工程 SOP

資料來源: https://mp.weixin.qq.com/s/qcbTSmTDr6c7UWGmQ_cT3g

☆ 項目的測試流程

    1.拿到需求文檔後，寫測試用例

    2.審核測試用例

    3.等待開發包

    4.部署測試環境

    5.冒煙測試（網頁架構圖）

    6.頁面初始化測試（查看數據庫中的數據內容和頁面展示的內容是否一致，並且是否按照某些順序排列）

    7.具體執行測試用例（幾乎所有的功能測試、流程法、場景法）

    8.發現缺陷就要再填寫缺陷表

    9.非功能性測試（sql、js注入、頁面效率、繞過js驗證直接添加數據到數據庫）

    10.書寫最終的測試報告

☆ 測試用例設計方法
    等價類、邊界值、正交試驗法、狀態遷移法、因果圖、場景測試法、異常分析法、因果圖、錯誤猜測法、判定表

☆ 測試用例的要素

    Id 主題、測試名稱、創建日期、設計者、描述、步驟名、步驟描述、預期結果、執行狀態

☆ 測試的優先級

    1.先測試經過變更的部分，然後測試沒有變更的部分；

    2.先測試程序的核心功能，然後測試一般功能；

    3.先測試邏輯性的功能，然後測試業務性的功能；

    4.先測試常規情況，然後測試異常情況；

    5.先測試功能，然後測試性能。

☆ 測試報告包含哪些內容

    1.寫測試背景

    2.測試目標

    3.測試範圍

    4.測試環境

    5.測試數據

    6.測試標準（重點）

    7.測試進度

    8.測試結果

    9.測試結論

    有的公司會採用非標準的測試報告，大致會包含：測試所用時間、測試環境、測試人員、測試發現bug數量、已修復bug數量、遺留bug、遺留bug原因、測試結果等。

☆ BUG的生命週期

    提交–開發驗證–接受–拒絕–開發解決–測試人員驗證–關閉–不通過打開。

☆ BUG的狀態

    1. NEW：所有提交到開發對接的問題狀態為NEW，表示為未處理

    2. OPEN：開發對接人初判為需流轉問題，指定測試人員和開發人員，狀態為OPEN。

    3. REFUSE：開發對接人判斷為不需要流轉至下環節的問題，狀態為REFUSE，並且填寫原因

    4. FIXED：開發人員完成修復，待測試，狀態為FIXED

    5. REOPEN：測試人員針對開發人員的修復結果測試不通過，狀態為REOPEN

    6. CLOSE：測試人員判斷問題為需求或其他問題，需填寫原因。

☆ 缺陷的要素

    缺陷標題、缺陷狀態、提交人、負責人、優先級、嚴重程度、缺陷描述、時間、截圖

☆ 缺陷的級別

    致命問題：核心功能不可用或系統崩潰

    嚴重問題：業務主要流程無法使用，業務主要流程中的某個功能存在缺陷導致主要流程無法繼續使用

    一般問題：一般性問題，非主要流程上的功能缺陷

    輕微問題：界面ui問題提示不規範等

    建議性問題：根據自己的經驗提一些建議性的問題

☆ WEB測試與APP測試的區別

    1. 架構不同
        web端是b/s架構的，b/s架構是基於瀏覽器地址訪問的；

        app端是c/s架構的，c/s架構是要有客戶端作為載體的。

    2.版本發布的方式和流程不同
        web發版本，開發部署新的代碼到對應服務器地址，就可統一實現web端的更新；

        app發版本，開發需要打包（apk包和ipa包），打包之後需要發佈到對應的渠道。

    3. 兼容性
        web，測試不同瀏覽器的兼容性（chrome、firefox、360、QQ）；

        app，測試不同的分辨率、屏幕尺寸、手機品牌、系統版本。

    4. 性能方面
        web，測試響應的時間；

        app，測試響應時間、流量、耗電量、CPU、GPU、memory。

    5. 安全性
        web，sql注入。xss攻擊等；

        app，https加密、簽名、加固、密碼加密等。

    6、app測試特點
        適配性測試

        網絡測試

        在線升級測試

        中斷測試

        耗電量測試

        弱網測試

        安裝卸載測試

        流量測試

☆ app測試的主要內容

    1. 功能測試
        業務邏輯正確性的測試

    2. 兼容性測試
        系統版本

        分辨率

        網絡情況

    3. 異常測試
        熱啟動

        網絡切換

        電話信息終端恢復

    4. 升級、安裝、卸載

    5. 健壯性測試
        手機資源消耗

        流量消耗

        電量測試

        崩潰恢復

☆ 如果一個bug，開發認為不是一個bug，怎麼處理？

    1. 將問題提交到缺陷管理庫裡面進行備案。

    2. 獲取判斷的依據和標準

        根據需求說明書、產品說明、設計文檔等，確認實際結果是否與計劃有不一致的地方，提供缺陷是否確認的直接依據；

        如果沒有文檔依據，可以根據類似軟件的一般特性來說明是否存在不一致的地方，來確認是否是缺陷；根據用戶的一般使用習慣，來確認是否是缺陷；與設計人員、開發人員和客戶代表等相關人員探討，確認是否是缺陷。

    3.合理的論述，向測試經理說明自己的判斷的理由，注意客觀、嚴謹，不參雜個人情緒。

    4.等待測試經理做出最終決定，如果仍然存在爭議，可以通過公司政策所提供的渠道，向上級反映，並由上級做出決定。