在測試過程中發現的Bug
前端bug
| 前端BUG | 是否解決 |
|---|---|
| 無法上傳PDF檔案 | 是。最初功能設想是每名使用者使用自己的Azure storage賬戶，如果使用這種方法我們的工具将變得難以推廣，因為國内大部分人都沒有一張visa卡。是以我們後來改變了功能設計，在改變時卻忽略了上傳模闆的功能，後來增加了一個上傳頁面，讓使用者上傳空表單模闆 |
| 工具欄圖示錯誤 | 是。不熟悉fabric-icons這個UI庫的使用，導緻本地圖示無法顯示，并且在前端控制台中報warning和error。在研讀原代碼之後，知道了如何關聯和使用這個圖示庫，但顯示時圖示發生了莫名其妙的“失真”，最終挑選原項目已有的圖示作為工具欄中的頁面圖示。 |
| data頁面展示pdf時，無法切換想要展示的pdf | 是。由于原代碼架構過于複雜，一些讀取storage的服務和寫好的關于pdf資源展示的子產品了解出錯，花費一天時間才找到問題，但同時也對項目架構有了更多的了解 |
| 生成資料改變時，展示界面更新有延遲 | 是。一開始以為是網絡問題導緻的延遲，後來在代碼複審的過程中，發現在生成新的pdf後，沒有及時調用更新展示界面的函數，而令其自動檢測容器中檔案是否發生變化，有變化時才更新。發現錯誤後就及時進行了修補。 |
| 頁面部分文字錯誤 | 是。某前端開發人員搞錯了單詞是否是可數名詞，在代碼複審的時候發現并修複，增長了姿勢。😃 |
| 前端向後端發送請求時有機率出現500錯誤 | 是，發現本地測試與部署網站後測試時，Azure Function設定需要進行改變 |
| 下載下傳的數量固定為四個 | 是，修改後支援任意數量PDF的下載下傳 |
| 标注頁面标注時響應時間時快時慢 | 否。由于原項目架構為先更新伺服器端資料，再讀取伺服器資料顯示在前端，我們依然使用了這種架構，是以響應時間會受到網速影響 |
| 有時候前端頁面展示的pdf與伺服器中存儲的pdf不相同 | 否。一開始由于bug無法穩定複現，懷疑是受到網絡情況的影響而擱置（确實是收到網絡影響）。後來進行代碼複審時，發現可以通過改變原有不合理架構避免網絡狀況影響，修改之後網絡狀況的問題不會導緻展示出現錯亂。但在其他條件下嘗試的時候，發現是由于chrome浏覽器緩存導緻的問題。由于讀取資源從原項目繼承，且不能穩定複現，目前還在探索中，如果出現此情況需要清楚浏覽器緩存後才能正常顯示 |
後端BUG
Azure Functions 臨時檔案使用問題
BUG：Azure Functions為我們帶來好處和便利的同時也帶來了一個沖突性問題——臨時檔案的使用；
解決：因為Azure Functions的定位是函數，且運作環境不受本地控制，我們發現在函數中生成臨時的檔案會失敗，導緻後端邏輯一度無法實作，後來經過研究和探索，我們通過使用Azure Storage來臨時存儲檔案，雖然帶來一定的傳輸時延，但是整體的效果足以滿足目前需求。
檔案删除
Bug：前端需要顯示後端對應記憶體中的檔案，而OCR掃描會生成一些臨時檔案，使得第二次使用時顯示錯誤。
解決辦法：後端增加判斷，每次上傳時先清空對應的存儲。
container删除問題
Azure Storage的存儲結構如下：
—container1
|—blob1
|—blob2
—container2
BUG：删除之後的操作會失敗！
解決：因為Azure删除container需要一定的時間，導緻後續的http請求到達時，前一個container還沒有被删除，造成沖突。是以我們改為了周遊container删除相應的blob！
name和address生成的支援
BUG：接第一個問題，name和address的生成需要後端資料，但是因為無法部署資料到Azure Functions，導緻這一功能一度無法實作
解決：通過把資料庫檔案儲存在Azure Storage上，每一次使用時通過API調用下載下傳，雖然帶來一定的時延，但是解決了這一問題。實測顯示時延問題并不明顯！
補充bug
前端标記框時候由對角線，有四種情況：
- 先左上，後右下
-
先右下，後左上
……
因為後端在生成時需要一個基點，一開始沒有考慮到第二種情況，導緻可能會出現文字反轉的BUG。
解決：後端增加了處理邏輯，解決這一問題！
後端測試方案
本項目的後端是基于微軟Azure Functions建構的http通路接口，遵循RESTful架構。
目前前後端的互動較為單一，隻涉及了GET和POST兩種請求，是以測試主要針對這兩種，同時API的功能主要為：
- 上傳pdf模闆檔案 —— POST + pdf二進制檔案
- 上傳JSON檔案 —— POST + JSON字元串
- 請求生成 —— GET + 參數：生成數量
- 請求下載下傳 —— GET
如上，對于各種情況，分别建構相應的http請求，使用Postman軟體來測試API的正确性，前後端結合後，通過前端進一步測試後端API的正确性。
同時，Azure Functions提供了請求的追蹤，使得我們可以追蹤每一次請求的具體過程，分析問題，監控http服務的運作！
壓力測試
你是怎麼進行場景測試（scenario testing）的？包括你預期不同的使用者會怎樣使用你的軟體？他們有什麼需求和目标？你的軟體提供的功能怎麼組合起來滿足他們的需要？
卡羅爾·狗蛋·史密斯
| 使用者資訊 | 使用者情況 |
|---|---|
| 姓名 | |
| 使用者身份 | 微軟表單項目開發測試人員 |
| 為了測試項目的bug，需要雇用大量的人力來填寫表單 | |
| 使用者痛點 | 大量人力意味着大量的薪水，另外耗時較多 |
| 典型場景 | 新的模型開發出來了，又到了緊張刺激的訓練和測試環節，但是真實表單資料，公司有要求不讓用，隻能花錢請人僞造表單來訓練測試了，又費時又費錢。發現有一個自動生成表單資料的項目，可以把資料生成到Azure裡，還能下載下傳下來，真是非常友善呀！ |
| 預期場景 | 史密斯通路項目網址，建立一個項目 史密斯上傳了要進行測試的空白PDF，并進行了标注 史密斯使用生成功能，生成出了大量的仿真PDF 史密斯下載下傳好PDF，完成任務 |
給出你的測試矩陣（test matrix），也即在什麼樣的平台、硬體配置、浏覽器類型……上對你的軟體進行測試？
基于chromium的浏覽器均可以正常使用
| 作業系統 | 浏覽器類型 | 是否正常 |
|---|---|---|
| win10 | Microsoft Edge（版本号81.0.416.68 ） | 正常顯示和使用 |
| Internet Explorer（版本号11.778.18362.0） | 不正常。該版本最後釋出日期應該是2015年，比較老舊，無法正常顯示 | |
| Google Chrome（版本号81.0.4044.129） | ||
| Ubuntu16.04 | Google chrome | |
| Android9 | 華為手機自帶浏覽器（版本号5.0.420） | 可以正常顯示，并且界面大小比較合适。但由于部分操作涉及鍵盤，在使用時存在困難。 |
你的軟體Alpha版本的出口條件（exit criteria）是什麼？也即在什麼條件下，認定你的軟體已經足夠好，可以釋出Alpha版本？
當Alpha版本能夠在浏覽器上正常顯示，并且：
- 使用者能夠上傳空白表單；
- 支援對空白表單進行操作，使PDF能夠添加姓名、年齡、位址等簡單的相關資訊；
- 能夠正确生成PDF檔案；
-
能構正常下載下傳PDF和JSON檔案的壓縮包；
即認為符合alpha版本釋出條件