測試點

選擇的測試點有兩個

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

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

測試階段目标(Roadmap)

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

各階段出口條件：

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

測試工具

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

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

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

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

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

前測試點

設計模式

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

測試環境的搭建

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

通過使用openssl自己簽個證書以及使用werkzeug_debugger_runserver實作本機支援https。

本地劫持騰訊驗證碼伺服器

因為我們使用了騰訊驗證碼作為安全措施，但這個措施會導緻自動測試的不可行。解決方案是本地架設了一台假的騰訊驗證碼伺服器，然後利用Fiddler劫持一切發送給真的騰訊驗證碼伺服器上的請求給假的上面去，進而確定自動化測試的可行性。

端口情況

nginx伺服器，開在80端口，負責分發html, js檔案。
django伺服器，開在随機使用者端口，負責後端接口的供應。
faketx伺服器，開在3668端口，負責假裝自己是騰訊的驗證碼伺服器
testcase程序，開在随機使用者端口，負責調用selenium，然後selenium打開浏覽器，請求nginx伺服器擷取網頁檔案，再通過ajax請求django伺服器擷取後端資料。

代碼覆寫率計算方法

使用jscover，啟用local-storage來支援跨頁面的插樁記錄存取。詳見。

基本流程如下：

使用jscover對前端js檔案插樁。
修改測試代碼，使得每個WebDriver被銷毀前會儲存插樁記錄。
合并插樁記錄，得到覆寫率報告。

不過需要注意的是，僅僅隻對js檔案插樁，裸寫在html檔案中的js代碼不會被納入覆寫率的統計中。

測試思路

細的來說：

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

粗的來說：

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

測試樣例總覽

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

[+]号表示還未完成。

頁面跳轉邏輯檢查
功能檢查
- 登入功能
- 注冊功能
- 登出功能
- 搜尋功能
- 切頁功能
- 評論發表功能
- 個人資訊修改功能
- 評論贊踩功能
[+]頁面備援檢查
相容性檢查
- [+]頁面長寬比相容性檢查：在不同長寬比的浏覽器界面下是否都能有良好響應
- 浏覽器相容性檢查：在不同浏覽器中是否都能有良好響應
  - chrome, firefox, edge
  - [+]國産浏覽器
- [+]作業系統相容性檢查
- [+]硬體平台相容性檢查
[+]易用性檢查
- 在登入/注冊資訊不完整/錯誤的情況下能否給出有效提示引導使用者完善資訊
- 在評論超字數的情況下能否給出有效提示引導使用者
- 各功能的響應速度是否合理

後測試點

前提

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

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

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

标準檢查：對于非常良好的輸入的情況下，各接口是否給出正确輸出。
[+]邊界檢查：對于滿足傳入需求，但處在邊界的輸入，各接口是否能給出正确輸出。
安全性檢查：是否存在能在無權限的情況下擷取敏感資訊的接口，或在無限制的情況下占用過多伺服器資源的接口。

Beta階段測試結果

因為大量使用了python的subTest，很多測試樣例被轉變成了一組子測試樣例的線性執行序列，是以統計測試樣例數目已經變成一件沒啥意義的事情了，以後也都不将統計。

commit: 5c6e26850dd8f74f423433f78d60535647bd90ef

Bug:

切頁功能：1, 2, 3
贊踩功能：1
Edge的相容性問題：1, 2
其他：1

Invalid:

切頁功能：1

js覆寫率：

commit: ff51f9ec21efb90cce08e5585c90cb7235cd7da1

評分功能：1
評分計算：1

python覆寫率：

安全性檢查

分析書
解決報告書

主要解決的問題：

Django的秘鑰的存放
CSRF攻擊
XSS攻擊
Clickjacking攻擊
啟用HSTS

回答問題

在測試過程中發現了多少Bug？有哪些是Beta階段的新Bug？有哪些是Alpha階段沒有發現的Bug？

邊敲邊測的單元測試中發現的bug數沒有統計，因為沒有進issue。黑盒測試的過程中發現了9個bug。沒有alpha階段遺留下來的bug，全部都是beta階段的新bug。

你是怎麼進行場景測試（scenario testing）的？包括你預期不同的使用者會怎樣使用你的軟體？他們有什麼需求和目标？你的軟體提供的功能怎麼組合起來滿足他們的需要？（僅描述新功能即可）

場景測試

模拟使用者的一系列操作，并在每個操作的步驟上檢查頁面是否如使用者期望進行。

一名無聊的學生，需求是檢視别人對課程的評價，并且發表自己的評價
1. 注冊
2. 登入
3. 搜尋課程
4. 點進課程頁面
5. 檢視評論
6. 點贊/踩評論
7. 添加評論
8. 登出
- 贊踩功能能夠讓這名學生在探索課程評價的時候更好地參與并互動進去。
一名選課中的學生，需求是大量浏覽别人對課程的評價
6. 若已經檢索完，則登出，否則傳回3
- 切頁功能可以使這名學生在大量檢索課程時得到更佳高效、舒适的體驗。

你是否有回歸測試確定新功能的加入沒有影響已有功能？請給出一到兩個測試用例并解釋。

所寫的所有測試樣例都是回歸測試的一部分。

def test_regist_exist_user(self):
    page = HomePage(self.driver, self.domain)
    page = page.goRegistPage()
    page.fillForm(
        name="rbq",
        email="[email protected]",
        password="abc123!@#",
        repassword="abc123!@#",
    )
    page.submit() # Should still be RegistPage
    rs(min=3)
    page.checkIsSelf()

注冊功能是alpha階段已經實作的，在alpha階段寫完的這個測試樣例在beta階段就成為了回歸測試的測試樣例。它做的事情是打開首頁，進入注冊頁面，填寫表單，送出，然後檢查是否注冊失敗（因為是試圖注冊一個已經注冊了的使用者）。

給出你的測試矩陣（test matrix），也即在什麼樣的平台、硬體配置、浏覽器類型……上對你的軟體進行測試？

Window Size	Browser
PC	Chrome
Mobile(Only for Chrome)	Firefox
Edge

你的軟體Beta版本的出口條件（exit criteria）是什麼？也即在什麼條件下，認定你的軟體已經足夠好，可以釋出Beta版本？

通過安全性、相容性檢查。并通過alpha階段的回歸測試。主要功能的代碼在測試中都被覆寫到。

Beta階段測試報告

測試點