Alpha階段測試報告

測試點

選擇的測試點有兩個

• 一個是使用者與浏覽器（用戶端）之間的節點，也就是模拟使用者對浏覽器的操作與擷取的響應來進行測試，稱之為“前測試點”(Front Test Point)。
• 一個是浏覽器（用戶端）與伺服器之間的節點，也就是模拟用戶端來向伺服器收發HTTP請求來進行測試，稱之為“後測試點”(Back Test Point)。

我們沒有在伺服器内部設定測試點，也就是說我們将伺服器視為一個黑盒。

測試階段目标(Roadmap)

1. alpha階段：
   • 搭建自動測試環境
     • 在後測試點，實作測試邏輯和測試資料分離，為持續測試做基礎。
     • 在前測試點，實作自動化測試，為持續測試做基礎。
   • 檢驗各功能在理想條件下是否如規格書所描述地運作。
     • 理想條件：完全符合預期的簡單輸入。
2. beta階段：
   • 魯棒性檢查：檢驗邊界條件，在非異常的極端/特殊情況下各功能是否如規格書所描述地運作。
     • 在後測試點，建構複雜測試樣例。
     • 在前測試點，構造usercase模拟一套使用者的操作，并在此基礎上實作并行測試。
       • 并行測試：建構多個usercase，随機僞并發執行，檢驗是否運作正常。
   • 相容性檢查：測試在不同終端、不同平台、不同浏覽器上的運作情況。
     • 不同終端：mobile、PC
     • 不同平台：mac OS, windows, android, ios
     • 不同浏覽器：chrome, edge, firefox
3. gamma階段：
   • 易用性檢查：檢驗是否存在不合理的設計/不易用的情景。
     • 良好的響應性。
     • 快捷的操作。
     • 直覺的回報。
     • 需求的滿足程度。
   • 安全性檢查：使用攻擊性的測試思路，挖掘安全性漏洞。
     • 洩露敏感資訊的代碼、包、資料、接口。
     • 可以被利用的接口。
     • 在被攻破後的可執行的應急措施。

各階段出口條件：

1. alpha：在理想條件下運作符合規格描述。
2. beta：通過魯棒性、相容性檢查。并通過alpha階段的回歸測試。
3. gamma：通過安全性檢查。并通過alpha, beta階段的回歸測試。

測試工具

測試架構完全使用Django的django.test子產品。

伺服器端對兩個測試點使用不同的做法：

• 對于前測試點，因為需要在js代碼中指定後端的域名+端口，是以無法使用具有随機端口的django測試伺服器。是以我們每次進行前測試的時候，都需要手動重新整理一下本地的伺服器，将測試資料填充進去。
• 對于後測試點，直接使用django的fixture系統來填充測試伺服器。

用戶端對兩個測試點采用不同的工具來模拟：

• 對于前測試點，使用Selenium模拟用戶端。
• 對于後測試點，使用Django原生的Client模拟用戶端。

前測試點

設計模式

使用Page Object作為Design Pattern。即，将每個頁面作為一個類，将該頁面提供的服務作為接口。每個類内部自己維護該頁面的元素定位符。

測試環境的搭建

使用Fiddler對域名和端口進行重映射，将對遠端伺服器的請求轉換為對本地伺服器的請求。

不過要注意一點，因為本機環境下無法使用https（django不支援），是以需要手動将前端代碼中的所有https都替換成http。

代碼覆寫率計算方法

目前沒有。

嘗試過jscover，但jscover的原理是對js代碼插樁，并使用一個js全局變量來存放覆寫率結果。然而js全局變量無法跨頁面存在，是以一旦一個測試樣例中出現了頁面跳轉，那麼覆寫率就會丢失一部分。而我們的網站目前是一定要求從首頁進入的線性通路模式，故而頁面跳轉是必須的。是以目前無法使用jscover來擷取代碼覆寫率。合适的替代品目前仍未找到。

測試思路

細的來說：

1. 檢查使用者需要知道的資訊的元素是否出現在頁面上。
2. 檢查頁面上是否出現了不該出現的元素。（例如已經登入的使用者卻在界面上找到了登入按鈕）
3. 檢查使用者操作是否得到預期的響應。
4. 檢查頁面跳轉邏輯是否如逾期執行。
5. 檢查異常處理是否合理完善。

粗的來說：

1. 檢查典型使用者的一套操作流程是否能正常執行，并且使用者是否能夠的得到他們想要的資訊。
2. 檢查使用者的異常操作是否會得到合理的報錯，并能順利恢複現場。

測試樣例總覽

此處不将列出詳細的測試用例内容，隻列出每族測試樣例的概述。

+号表示還未完成，或可能與已經寫的測試樣例重複。

• +内容檢查
  • 搜尋結果頁面的課程資訊是否與課程資訊頁面的課程資訊一緻
  • 課程資訊頁面是否給出評論資訊
  • 首頁的“選擇學院”能否給出所有學院
• 頁面跳轉邏輯檢查
  • 各頁面的跳轉邏輯是否與規格一緻
  • Addition（規格裡沒提到的）：
    • 首頁 => 搜尋
      • 搜尋課程按鈕
      • 搜尋框内回車
    • 注冊 => 首頁
      • 首頁按鈕
    • 注冊 => 登入
      • 登入按鈕
      • 确認注冊按鈕
    • 登入 => 首頁
      • 确認登入
    • 登入 => 注冊
      • 注冊按鈕
• 功能檢查 & 魯棒性檢查
  • 登入功能
    • 是否能登入到一個已注冊使用者上
    • 是否不能登入到一個未注冊使用者上
    • 在登陸後是否在各場景下都能正确反映登入使用者資訊
      • 評論後該評論的作者是否是登入使用者
      • 個人資訊頁面是否是登入使用者的資訊
  • 注冊功能
    • 是否不能注冊一個已注冊使用者
    • 是否能注冊一個未注冊使用者
  • 登出功能
    • 在各頁面是否能正常登出
  • 評論功能
    • 是否能在對應課程下給出相應的評論
      • 這個好像和上面的登入功能裡面的評論重了，一起做了
  • 搜尋功能
    • +是否能通過課程資訊頁面的一些條項搜尋對應的内容
    • 是否能搜尋到确實存在的課程
    • 是否會搜尋到不存在的課程
    • 在指定學院的情況下能否正常執行
      • 在不指定學院的情況下，能否給出所有課程
      • 在隻指定學院的情況下，能否隻給出該學院的所有課程
      • 在課程名稱、學院都被指定的情況下
        • 當課程名稱不屬于該學院時，能否不給出該課程
        • 當課程名稱屬于該學員時，能否給出該課程
    • +模糊搜尋是否有效
    • TODO 是否存在非法的搜尋字元？
  • +切頁功能
    • 搜尋結果、課程資訊頁面的切頁功能是否能正常工作
• +頁面備援檢查
  • 在未登入情況下是否存在個人資訊、登出按鈕。以及登入情況下是否存在登入、注冊按鈕
• +相容性檢查
  • 頁面長寬比相容性檢查：在不同長寬比的浏覽器界面下是否都能有良好響應
  • 浏覽器相容性檢查：在不同浏覽器中是否都能有良好響應
  • 分辨率相容性檢查
    • 應該不做這個
• +易用性檢查
  • 在登入/注冊資訊不完整/錯誤的情況下能否給出有效提示引導使用者完善資訊
  • 在評論超字數的情況下能否給出有效提示引導使用者

後測試點

前提

我們預設一切規格規定的管道的使用者輸入都已在前端被充分檢驗正确性（例如，注冊時使用者名、密碼是否符合格式），故在後端不做任何相關測試。

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

1. 檢查各接口是否如規格描述地正确響應。
2. 檢查是否存在不該暴露給使用者的資源也暴露了。
3. 使用代碼覆寫率，檢查是否存在無用代碼。

• 标準檢查：對于非常良好的輸入的情況下，各接口是否給出正确輸出。
• 邊界檢查：對于滿足傳入需求，但處在邊界的輸入，各接口是否能給出正确輸出。
  • TODO
• 安全性檢查：是否存在能在無權限的情況下擷取敏感資訊的接口，或在無限制的情況下占用過多伺服器資源的接口。
  • 在未登入情況下是否能通路個人資訊，及已登入情況下能否通路其他使用者的個人資訊。
  • TODO 可能還有。
• 異常檢查：在出現異常情況時，伺服器的響應情況。
  • 我們應該不做這個。
• 壓力測試
  • 我們應該也不做這個。

測試樣例構造思路

這裡隻将給出部分比較抽象的測試樣例的構造思路。

标準檢查-同質合并

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

觀察可知同質性：

• Create, Update: 都是發送Post請求，并将修改的Model資訊附加在payload上。收到回複後檢查回複請求中的狀态碼來确定是否成功，最後檢查資料庫中是否有符合要求的Model被添加/更新。
• Search: 都是發送Get請求，并将期望的Model資訊附加在payload上。收到回複後檢查回複請求中的狀态碼來确定是否成功，最後檢查回複請求中body的資訊是否符合預期。

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

• 請求的url
• 請求的payload
• 檢查的Model/Body内容

故而可以将這部分資料抽離出來單獨存放，使用統一的邏輯進行測試。

測試代碼管理

測試代碼和伺服器代碼不在一個庫中，它獨立地作為一個庫存在。但主庫（伺服器代碼所在庫）會将測試代碼作為submodule引入。

這麼做的目的是為了使得任何時候都能從主庫的任意分支擷取測試代碼的任何分支的任何commit，避免了因為測試需要而對主庫代碼的合并/切出作出要求。

測試樣例管理

我們使用了django提供的tag來管理測試樣例，使得在測試時可以選取測試樣例執行。目前使用的tag包括

• front
  • 該測試樣例為前測試點測試樣例。
• back
  • 該測試樣例為後測試點測試樣例。
• db_modify
  • 用于前測試點，該測試樣例會修改資料庫，每次使用前需要重新整理資料庫，重新加載測試資料庫。
• split
  • 用于前測試點，該測試樣例用于測試切頁，需要加載額外的資料庫來進行測試。
  • 待廢棄。
• auto
  • 用于後測試點，該測試樣例分離了測試邏輯和測試資料，它會加載json檔案來執行測試。
• foreign
  • 用于後測試點，該測試樣例使用了Model的外鍵，目前無法分離這部分的測試邏輯和測試資料。

Alpha階段測試結果

commit: 666cc6afa8556d0618d630e9118f1df88518e994

共47個測試樣例，全部通過。

• bug數：4
• invalid數：2

目前沒有找到合适的工具來和selenium配合擷取代碼覆寫率。

commit: 55890581df5543ce2e34768306f72bf01e62c867

共31個測試樣例，全部通過。

• invalid數：8

代碼覆寫率：