作者|李京京
項目中QA同學需要針對不同項目特點，采用不同的測試手段，大家常用的測試手段包括：功能測試，接口測試，接口Mock測試等，那如何将這些測試手段應用到自己的項目中，形成特定的測試方案呢。下面會結合具體項目來作詳細闡述。
一、接口自動化測試
項目名稱：盤古類目體系改造
1、背景介紹
通過新老類目體系的互相映射，保證新老類目體系并行一段時間，待各個業務方完成由舊類目體系到新類目體系遷移完成，下線舊類目體系，全部切到使用新類目體系。APP會作為盤古的第一個接入方。
2、難點分析
- 本項目的核心是偏下遊的基礎服務，調用場景較多，且7000多個分類的新老資料映射，需要測試的case量巨大，完全基于功能層面去測試成本高，耗時長，且無法保證全量覆寫，可行性低
- 不同業務線業務場景不同，且有一些特殊場景存在，單純的接口測試是不能覆寫業務線的實際應用場景的，且互動邏輯是否正确，最終還是要通過功能層面去驗收
3、測試方案
全量自動化接口測試+業務場景功能測試
4、效果
- 全量接口自動化測試，大大提升了測試效率（詳見表格），實作了case的全量覆寫，保證了測試品質；且沉澱下來的測試代碼，項目後期維護階段，可以複用進行回歸測試
- 從使用者功能角度做驗收是必要的，發現業務特定場景下的細節問題，保障使用者體驗
二、提前産出測試工具
項目名稱：我釋出的清單頁改版
1、任務展示邏輯及曝光政策測試
（1）難點分析
- 任務及曝光政策涉及到的條件都是結合Redis緩存的特定字段的時間戳或字段狀态值來判斷的，構造Redis裡有代表性的時間戳和可能的狀态值是可行的，但是構造的資料隻有在隔天才會影響到Redis中特定值的變動，頻繁的構造真實資料，進行用戶端展現的測試，幾乎是不可行的。
- 可不可以讓server從代碼裡把時間間隔改小呢？溝通結論是不可行的，因為如果修改了，模拟測試，測試的不是真實邏輯，意義不大。
（2）測試方案 采用分層測試
- 真實構造可能的測試場景，生成Redis中具有代表性的時間戳和可能的狀态值，并校驗這些字段值是正确的
- 編寫操作Redis的工具類，針對性的對Redis中的時間戳和狀态字段進行增删改查，對用戶端展示進行測試
2、不同量級的曝光數在用戶端的展示樣式
通過Mock接口字段的不同傳回值，檢視用戶端的展示樣式是否正常
綜上，
- 通過提升QA自身的技術能力和代碼能力，有助于豐富自身的測試手段，深入了解技術實作方案，進而制定合理的測試方案。
- 一個優秀的測試方案，除了它的有效性外，還需要做到可以對提測部分盡早介入測試，将問題盡早暴露出來，減少項目後期壓力。
- 結合QA内部推行的冒煙流程等有利條件，可以提前準備好RD自測所需的資料構造，測試工具，接口case等，是實作QA從保姆型到輔助型的有效途徑。
end
複制