Alpha階段測試報告

時間 2019-12-06

標籤 alpha 階段測試報告简体版

原文原文鏈接

測試點

選擇的測試點有兩個前端

一個是用戶與瀏覽器（客戶端）之間的節點，也就是模擬用戶對瀏覽器的操做與獲取的響應來進行測試，稱之爲「前測試點」(Front Test Point)。
一個是瀏覽器（客戶端）與服務器之間的節點，也就是模擬客戶端來向服務器收發HTTP請求來進行測試，稱之爲「後測試點」(Back Test Point)。

咱們沒有在服務器內部設置測試點，也就是說咱們將服務器視爲一個黑盒。python

測試階段目標(Roadmap)

alpha階段：
- 搭建自動測試環境
  - 在後測試點，實現測試邏輯和測試數據分離，爲持續測試作基礎。
  - 在前測試點，實現自動化測試，爲持續測試作基礎。
- 檢驗各功能在理想條件下是否如規格書所描述地運行。
  - 理想條件：徹底符合預期的簡單輸入。
beta階段：
- 魯棒性檢查：檢驗邊界條件，在非異常的極端/特殊狀況下各功能是否如規格書所描述地運行。
  - 在後測試點，構建複雜測試樣例。
  - 在前測試點，構造usercase模擬一套用戶的操做，並在此基礎上實現並行測試。
    - 並行測試：構建多個usercase，隨機僞併發執行，檢驗是否運做正常。
- 兼容性檢查：測試在不一樣終端、不一樣平臺、不一樣瀏覽器上的運行狀況。
  - 不一樣終端：mobile、PC
  - 不一樣平臺：mac OS, windows, android, ios
  - 不一樣瀏覽器：chrome, edge, firefox
gamma階段：
- 易用性檢查：檢驗是否存在不合理的設計/不易用的情景。
  - 良好的響應性。
  - 快捷的操做。
  - 直觀的反饋。
  - 需求的知足程度。
- 安全性檢查：使用攻擊性的測試思路，挖掘安全性漏洞。
  - 泄露敏感信息的代碼、包、數據、接口。
  - 能夠被利用的接口。
  - 在被攻破後的可執行的應急措施。

各階段出口條件：android

alpha：在理想條件下運行符合規格描述。
beta：經過魯棒性、兼容性檢查。並經過alpha階段的迴歸測試。
gamma：經過安全性檢查。並經過alpha, beta階段的迴歸測試。

測試工具

測試架構徹底使用Django的django.test模塊。ios

服務器端對兩個測試點使用不一樣的作法：git

對於前測試點，由於須要在js代碼中指定後端的域名+端口，因此沒法使用具備隨機端口的django測試服務器。因此咱們每次進行前測試的時候，都須要手動刷新一下本地的服務器，將測試數據填充進去。
對於後測試點，直接使用django的fixture系統來填充測試服務器。

客戶端對兩個測試點採用不一樣的工具來模擬：github

對於前測試點，使用Selenium模擬客戶端。
對於後測試點，使用Django原生的Client模擬客戶端。

前測試點

設計模式

使用Page Object做爲Design Pattern。即，將每一個頁面做爲一個類，將該頁面提供的服務做爲接口。每一個類內部本身維護該頁面的元素定位符。chrome

測試環境的搭建

使用Fiddler對域名和端口進行重映射，將對遠端服務器的請求轉換爲對本地服務器的請求。
不過要注意一點，由於本機環境下沒法使用https（django不支持），因此須要手動將前端代碼中的全部https都替換成http。數據庫

代碼覆蓋率計算方法

目前沒有。django

嘗試過jscover，但jscover的原理是對js代碼插樁，並使用一個js全局變量來存放覆蓋率結果。然而js全局變量沒法跨頁面存在，因此一旦一個測試樣例中出現了頁面跳轉，那麼覆蓋率就會丟失一部分。而咱們的網站目前是必定要求從首頁進入的線性訪問模式，故而頁面跳轉是必須的。因此目前沒法使用jscover來獲取代碼覆蓋率。合適的替代品目前仍未找到。json

測試思路

細的來講：

檢查用戶須要知道的信息的元素是否出如今頁面上。
檢查頁面上是否出現了不應出現的元素。（例如已經登陸的用戶卻在界面上找到了登陸按鈕）
檢查用戶操做是否獲得預期的響應。
檢查頁面跳轉邏輯是否如逾期執行。
檢查異常處理是否合理完善。

粗的來講：

檢查典型用戶的一套操做流程是否能正常執行，而且用戶是否可以的獲得他們想要的信息。
檢查用戶的異常操做是否會獲得合理的報錯，並能順利恢復現場。

測試樣例總覽

此處不將列出詳細的測試用例內容，只列出每族測試樣例的概述。
+號表示還未完成，或可能與已經寫的測試樣例重複。

+內容檢查
- 搜索結果頁面的課程信息是否與課程信息頁面的課程信息一致
- 課程信息頁面是否給出評論信息
- 首頁的「選擇學院」可否給出全部學院
頁面跳轉邏輯檢查
- 各頁面的跳轉邏輯是否與規格一致
- Addition（規格里沒提到的）：
  - 首頁 => 搜索
    - 搜索課程按鈕
    - 搜索框內回車
  - 註冊 => 首頁
    - 首頁按鈕
  - 註冊 => 登陸
    - 登陸按鈕
    - 確認註冊按鈕
  - 登陸 => 首頁
    - 首頁按鈕
    - 確認登陸
  - 登陸 => 註冊
    - 註冊按鈕
功能檢查 & 魯棒性檢查
- 登陸功能
  - 是否能登陸到一個已註冊用戶上
  - 是否不能登陸到一個未註冊用戶上
  - 在登錄後是否在各場景下都能正確反映登陸用戶信息
    - 評論後該評論的做者是不是登陸用戶
    - 我的信息頁面是不是登陸用戶的信息
- 註冊功能
  - 是否不能註冊一個已註冊用戶
  - 是否能註冊一個未註冊用戶
- 註銷功能
  - 在各頁面是否能正常註銷
- 評論功能
  - 是否能在對應課程下給出相應的評論
    - 這個好像和上面的登陸功能裏面的評論重了，一塊兒作了
- 搜索功能
  - +是否能經過課程信息頁面的一些條項搜索對應的內容
  - 是否能搜索到確實存在的課程
  - 是否會搜索到不存在的課程
  - 在指定學院的狀況下可否正常執行
    - 在不指定學院的狀況下，可否給出全部課程
    - 在只指定學院的狀況下，可否只給出該學院的全部課程
    - 在課程名稱、學院都被指定的狀況下
      - 當課程名稱不屬於該學院時，可否不給出該課程
      - 當課程名稱屬於該學員時，可否給出該課程
  - +模糊搜索是否有效
  - TODO 是否存在非法的搜索字符？
- +切頁功能
  - 搜索結果、課程信息頁面的切頁功能是否能正常工做
+頁面冗餘檢查
- 在未登陸狀況下是否存在我的信息、註銷按鈕。以及登陸狀況下是否存在登陸、註冊按鈕
+兼容性檢查
- 頁面長寬比兼容性檢查：在不一樣長寬比的瀏覽器界面下是否都能有良好響應
- 瀏覽器兼容性檢查：在不一樣瀏覽器中是否都能有良好響應
- 分辨率兼容性檢查
  - 應該不作這個
+易用性檢查
- 在登陸/註冊信息不完整/錯誤的狀況下可否給出有效提示引導用戶完善信息
- 在評論超字數的狀況下可否給出有效提示引導用戶

後測試點

前提

咱們默認一切規格規定的渠道的用戶輸入都已在前端被充分檢驗正確性（例如，註冊時用戶名、密碼是否符合格式），故在後端不作任何相關測試。

代碼覆蓋率計算方法

使用python的coverage獲取代碼覆蓋率。僅計算rateMyCoure目錄下的代碼。

測試思路

檢查各接口是否如規格描述地正確響應。
檢查是否存在不應暴露給用戶的資源也暴露了。
使用代碼覆蓋率，檢查是否存在無用代碼。

測試樣例總覽

此處不將列出詳細的測試用例內容，只列出每族測試樣例的概述。

標準檢查：對於很是良好的輸入的狀況下，各接口是否給出正確輸出。
邊界檢查：對於知足傳入需求，但處在邊界的輸入，各接口是否能給出正確輸出。
- TODO
安全性檢查：是否存在能在無權限的狀況下獲取敏感信息的接口，或在無限制的狀況下佔用過多服務器資源的接口。
- 在未登陸狀況下是否能訪問我的信息，及已登陸狀況下可否訪問其餘用戶的我的信息。
- TODO 可能還有。
異常檢查：在出現異常狀況時，服務器的響應狀況。
- 咱們應該不作這個。
壓力測試
- 咱們應該也不作這個。

測試樣例構造思路

這裏只將給出部分比較抽象的測試樣例的構造思路。

標準檢查-同質合併

注意到有大量的接口都是Create, Update, Search這類對Model的操做，考慮它們的同質性。

觀察可知同質性：

Create, Update: 都是發送Post請求，並將修改的Model信息附加在payload上。收到回覆後檢查回覆請求中的狀態碼來肯定是否成功，最後檢查數據庫中是否有符合要求的Model被添加/更新。
Search: 都是發送Get請求，並將指望的Model信息附加在payload上。收到回覆後檢查回覆請求中的狀態碼來肯定是否成功，最後檢查回覆請求中body的信息是否符合預期。

也就是說大多數的測試樣例之間的區別僅僅在於