Beta階段測試報告

測試點

選擇的測試點有兩個

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

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

測試階段目標(Roadmap)

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

各階段出口條件：

1. alpha：在理想條件下運行符合規格描述。
2. beta：經過安全性、兼容性檢查。並經過alpha階段的迴歸測試。
3. 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來支持跨頁面的插樁記錄存取。詳見。

基本流程以下：

1. 使用jscover對前端js文件插樁。
2. 修改測試代碼，使得每一個WebDriver被銷燬前會保存插樁記錄。
3. 合併插樁記錄，獲得覆蓋率報告。

不過須要注意的是，僅僅只對js文件插樁，裸寫在html文件中的js代碼不會被歸入覆蓋率的統計中。

測試思路

細的來講：

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

粗的來講：

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

測試樣例總覽

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

• [+]號表示還未完成。

---

• 頁面跳轉邏輯檢查
• 功能檢查
  • 登陸功能
  • 註冊功能
  • 註銷功能
  • 搜索功能
  • 切頁功能
  • 評論發表功能
  • 我的信息修改功能
  • 評論贊踩功能
• [+]頁面冗餘檢查
• 兼容性檢查
  • [+]頁面長寬比兼容性檢查：在不一樣長寬比的瀏覽器界面下是否都能有良好響應
  • 瀏覽器兼容性檢查：在不一樣瀏覽器中是否都能有良好響應
    • chrome, firefox, edge
    • [+]國產瀏覽器
  • [+]操做系統兼容性檢查
  • [+]硬件平臺兼容性檢查
• [+]易用性檢查
  • 在登陸/註冊信息不完整/錯誤的狀況下可否給出有效提示引導用戶完善信息
  • 在評論超字數的狀況下可否給出有效提示引導用戶
  • 各功能的響應速度是否合理

後測試點

前提

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

代碼覆蓋率計算方法

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

測試思路

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

測試樣例總覽

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

• [+]號表示還未完成。

---

• 標準檢查：對於很是良好的輸入的狀況下，各接口是否給出正確輸出。
• [+]邊界檢查：對於知足傳入需求，但處在邊界的輸入，各接口是否能給出正確輸出。
• 安全性檢查：是否存在能在無權限的狀況下獲取敏感信息的接口，或在無限制的狀況下佔用過多服務器資源的接口。

Beta階段測試結果

由於大量使用了python的subTest，不少測試樣例被轉變成了一組子測試樣例的線性執行序列，因此統計測試樣例數目已經變成一件沒啥意義的事情了，之後也都不將統計。

前測試點

commit: 5c6e26850dd8f74f423433f78d60535647bd90ef

Bug:

• 切頁功能：1, 2, 3
• 贊踩功能：1
• Edge的兼容性問題：1, 2
• 其餘：1

Invalid:

• 切頁功能：1

js覆蓋率：

後測試點

commit: ff51f9ec21efb90cce08e5585c90cb7235cd7da1

Bug:

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

Invalid:

• 評分計算：1

python覆蓋率：

安全性檢查

• 分析書
• 解決報告書

主要解決的問題：

• Django的祕鑰的存放
• CSRF攻擊
• XSS攻擊
• Clickjacking攻擊
• 啓用HSTS

回答問題

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

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

你是怎麼進行場景測試（scenario testing）的？包括你預期不一樣的用戶會怎樣使用你的軟件？他們有什麼需求和目標？你的軟件提供的功能怎麼組合起來知足他們的須要？（僅描述新功能便可）

場景測試

模擬用戶的一系列操做，並在每一個操做的步驟上檢查頁面是否如用戶指望進行。

1. 一名無聊的學生，需求是查看別人對課程的評價，而且發表本身的評價
   1. 註冊
   2. 登陸
   3. 搜索課程
   4. 點進課程頁面
   5. 查看評論
   6. 點贊/踩評論
   7. 添加評論
   8. 註銷
   • 贊踩功能可以讓這名學生在探索課程評價的時候更好地參與並互動進去。
2. 一名選課中的學生，需求是大量瀏覽別人對課程的評價
   1. 註冊
   2. 登陸
   3. 搜索課程
   4. 點進課程頁面
   5. 查看評論
   6. 若已經檢索完，則註銷，不然返回3
   • 切頁功能可使這名學生在大量檢索課程時獲得更佳高效、溫馨的體驗。

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

所寫的全部測試樣例都是迴歸測試的一部分。

def test_regist_exist_user(self):
    page = HomePage(self.driver, self.domain)
    page = page.goRegistPage()
    page.fillForm(
        name="rbq",
        email="rbq@test.com",
        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階段的迴歸測試。主要功能的代碼在測試中都被覆蓋到。