基於網路爬蟲的小湖知識圖譜系統 測試心得
組名：SE真香隊
專案：基於網路爬蟲的小湖知識圖譜系統
組：軟體1602班第6組
在這個學期，我們組做了基於網路爬蟲的小湖知識圖譜系統，在做專案的過程中，團隊成員都覺的很完美，然而，最後一個周進行測試的時候（雖然是手動測試）發現我們的這個系統仍然存在很多bug，有些bug及時修改了，而有些bug則很難改，或者來不及改，如下是我們組的測試報告：
第1章引言
1.1目的
本測試報告的具體編寫目的，指出預期的讀者範圍。
本次測試報告的目的是，記錄專案測試歷史，保留專案測試資料以及測試方法，將本專案仍存在的不足之處記錄下來，方便接下來的開發者瞭解專案歷史。
1.2名詞解釋
列出本計劃中使用的專用術語及其定義。
列出本計劃中使用的全部縮略語全稱及其定義
1、白盒
白盒測試也稱結構測試或邏輯驅動測試，它是知道產品內部工作過程，可通過測試來檢測產品內部動作是否按照規格說明書的規定正常進行，按照程式內部的結構測試程式，檢驗程式中的每條通路是否都有能按預定要求正確工作
2、黑盒
黑盒測試也稱功能測試或資料驅動測試，它是在已知產品所應具有的功能的情況下，通過測試來檢測每個功能是否都能正常使用的一種測試方法。
3、爬蟲
網路爬蟲（又被稱為網頁蜘蛛，網路機器人），是一種按照一定的規則，自動地抓取全球資訊網
1.3參考及引用的資料
列出本計劃各處參考的經過核准的全部文件和主要文獻。
無
第2章 測試概述
2.1測試物件
本專案的測試物件分為兩個：爬蟲程式及網站。
2.2專案背景
學生們在小學或者初中，高中的時候，每天都可以和老師接觸，這樣自然很容易就可以瞭解到自己的任課老師們的資訊或者是和老師們取得溝通，但我們到了大學以後，學生與老師的交流機會減少了，那麼學生們想要了解到老師們的資訊就會變得困難，本專案就是為了解決學生這一困境而產生的。本專案主要的功能就是從各學校的官網上爬取教師們公開的資訊，並以知識圖譜的方式展現在網站上，方便學生查閱。
2.3測試目的
1、爬蟲方面：測試爬蟲程式是否能夠成功的從網站上爬取到我們所需要的教師相關的資訊。
2、網站：
①以使用者身份測試是否能夠順利使用網站上的各種功能，併成功的查詢到所需要的相關資訊。
| 測試要點 |
測試範圍 |
測試 |
| 使用者登入 |
輸入錯誤的賬號密碼，輸入正確的賬號密碼 |
確保只有輸入正確的賬號密碼才能完成使用者登入 |
| 使用者修改資訊 |
修改使用者賬號上資料中的暱稱等資訊 |
確保使用者可以正常的修改資訊 |
| 使用者檢視教師資訊 |
使用者點選教師管理後，檢視教師資訊 |
測試是否能夠看到教師資訊 |
| 使用者搜尋教師資訊 |
輸入正確的教師資訊，輸入錯誤的教師資訊 |
確保只有在使用者輸入了正確的教師資訊的情況下，才會顯示相應老師的相關資訊 |
| 使用者檢視知識圖譜 |
點選知識圖譜按鈕 |
確保使用者可以正常的檢視知識圖譜 |
| 使用者檢視學院資訊 |
使用者點選學院管理，檢視學院資訊 |
測試是否能夠看到已有的學院資訊 |
| 使用者搜尋學院資訊 |
使用者輸入學院相信資訊 |
測試是否能夠看到學院的相關資訊 |
| 使用者搜尋學校資訊 |
使用者輸入學校相關資訊，點選搜尋 |
測試是否能夠看到學校的相關資訊 |
| 使用者檢視學校資訊 |
使用者點選學校管理，檢視學校資訊 |
測試使用者是否能夠看到已有的學校資訊 |
②以管理員身份測試是否能夠根據需求進行各種資料管理以及許可權分配。
| 測試要點 |
測試範圍 |
測試 |
| 管理員登入 |
輸入正確的賬號密碼，輸入錯誤的賬號密碼 |
測試是否只有輸入正確的賬號密碼時才能登入入系統 |
| 管理員修改資訊 |
修改賬號上的暱稱等資訊 |
測試是否管理員可以順利的修改賬號上的資訊 |
| 管理員重置密碼 |
輸入新的密碼 |
測試是否管理員可以順利修改密碼 |
| 管理員新增學校 |
管理員填寫學校的相關資訊後新增學校 |
測試是否有必填項提示，測試是否可以順利新增，測試是否不能輸入空資料 |
| 管理員修改學校 |
管理員選中一個學校後點擊修改，修改學校的相關資訊點選確定後更新學校相關資訊 |
測試是否有必填項提示，測試是否可以順利修改，測試是否不能輸入空資料，測試是否提示選中一個學校 |
| 管理員刪除學校 |
管理員選中一個學校後，點選刪除以刪除學校 |
測試是否提示選中學校，測試正確操作後是否能夠順利刪除學校 |
| 管理員查詢學校 |
管理員輸入相應資訊後點擊查詢 |
測試是否能夠成功輸出相關學校資訊 |
| 管理員新增學院 |
管理員填寫學院相關資訊後點擊新增 |
測試是否有必填項提示，測試是否可以順利新增，測試是否不能夠輸入空資料 |
| 管理員修改學院 |
管理員選中一個學院後點擊修改，修改學院的相關資訊點選確定後更新學院相關資訊 |
測試是否有必填項提示，測試是否可以順利修改，測試是否不能夠輸入空資料，測試是否提示選中一個學院 |
| 管理員刪除學院 |
選中一個學院，點選刪除 |
測試是否提示選中學院，測試正確操作後是否能夠順利刪除學院 |
| 管理員查詢學院 |
管理員輸入相應資訊後點擊查詢 |
測試是否能夠成功輸出相關學院資訊 |
| 管理員新增教師資訊 |
管理員填寫教師資訊後點擊新增 |
測試是否有必填項提示，測試是否可以順利新增，測試是否不能夠輸入空資料 |
| 管理員修改教師資訊 |
管理員選中一個教師後點擊修改，修改學校的相關資訊點選確定後更新學校相關資訊 |
測試是否有必填項提示，測試是否可以順利修改，測試是否不能夠輸入空資料，測試是否提示選中一個教師資訊 |
| 管理員刪除教師資訊 |
選中一個教師，點選刪除 |
測試是否提示選中教師資訊，測試正確操作後是否能夠順利刪除相關教師資訊 |
| 管理員查詢教師資訊 |
輸入相關資訊後，點選查詢 |
測試是否能夠成功查詢 |
| 管理員檢視知識圖譜 |
管理員點選檢視知識圖譜 |
測試是否能夠正確顯示出知識圖譜 |
| 管理員新增反饋資訊 |
管理員新增相關資訊後點擊新增。 |
測試是否有必填項提示，測試是否可以順利新增，測試是否不能夠輸入空資料 |
| 管理員刪除反饋資訊 |
管理員選擇一條資訊後點擊刪除。 |
測試是否提示選中反饋資訊，測試正確操作後是否能夠順利刪除反饋資訊 |
| 管理員進行系統管理 |
進行系統管理的相關操作 |
測試相關操作是否能夠生效，是否符合要求。 |
| 管理員任務管理 |
管理員進行任務管理的相關操作 |
測試任務管理的相關操作是否能夠實現，是否符合相關要求 |
2.4測試時間
測試開始時間：2018年12月31號
測試結束時間：2019年1月3號
2.5系統結構
第3章 測試方法
測試方法和測試環境的概要介紹，包括測試的一些宣告、測試範圍、測試目的等等，主要是測試情況簡介。
2.1測試用例設計（略）
（略）
3.1
3.1.1硬體環境
3.1.2軟體環境
windows xp及以上系統，IE 10及以上版本瀏覽器。
3.2 測試工具
使用了開發工具idea進行了測試，除此之外，我們沒有使用其他的測試工具。
3.3測試方法
1.白盒測試法
白盒測試也稱結構測試或邏輯驅動測試，它是知道產品內部工作過程，可通過測試來檢測產品內部動作是否按照規格說明書的規定正常進行，按照程式內部的結構測試程式，檢驗程式中的每條通路是否都有能按預定要求正確工作
這部分的測試由組內相關部分開發人員在寫完程式碼時進行。
2.黑盒
黑盒測試也稱功能測試或資料驅動測試，它是在已知產品所應具有的功能的情況下，通過測試來檢測每個功能是否都能正常使用的一種測試方法。
在本次的測試中，我們組採用的主要技術就是黑盒測試。在測試過程中有意不考慮程式內部結構，站在使用者及管理員的角度對專案進行測試。
第4章 測試結果及缺陷分析
這是測試報告的核心，主要彙總測試各種資料並進行度量，度量包括對測試過程的度量和能力評估、對軟體產品的質量度量和產品評估。
4.1 覆蓋分析
4.1.1需求覆蓋分析
需求覆蓋率是指經過測試的需求/功能和需求規格說明書中所有需求/功能的比值，通常情況下要達到100％的目標。
根據測試結果，按編號給出每一測試需求的通過與否結論。
需求覆蓋率=測試通過需求點/需求總數×100％
經過分析比較，我們可以很輕易的得出如下結論，凡是在需求所明書上的需求都經過了我們的測試，所以本次測試，我們的需求覆蓋率應當是100％。
4.1.2測試覆蓋分析
（如無測試用例部分，該部分可忽略）
測試覆蓋是指根據經過測試的測試用例和設計測試用例的比值，通過這個指標獲得測試情況的資料。
測試覆蓋率=執行數/用例總數×100％
測試通過率=通過數/執行數×100％
無測試用例。
4.2 缺陷統計與分析
對測試過程中產生的缺陷進行統計和分析。
在本次的測試中，我們總共統計出了8個缺陷，這些缺陷分佈在重置密碼的簡訊驗證，任務管理，任務執行，知識圖譜生成等模組
4.2.1缺陷統計
4.2.1.1所有bug列表
這部分主要列出測試過程中的所有bug，並對其進行描述。
1、新增資訊時沒有必填項提示。
2、在新增各種資訊時，可以輸入空資料
3、任務管理修改開始時間時，只能讀取到年月日的資料，但是資料庫能夠儲存到時分秒
4、任務不能到點自動執行，任務設定了執行開始時間及結束時間，但是到了時間並不能執行相關操作。
5、在重置密碼時，第一次不能發簡訊，必須要輸入完整資訊有錯誤用例之後才能傳送驗證簡訊。
6、當用戶輸入不對應自己的手機號的時候修改失敗，但是沒有提示
7、知識圖譜展示時，搜尋相關實體時，無法顯示其附近的三元組。
8、爬蟲部分結果無法寫入資料庫，因為網站上面的資料格式不同，雖然已經對不同格式進行了處理，但是仍有部分資料無法寫入。
9、當輸入的資訊過多時，知識圖譜顯示會出現重疊。
10、刪除資訊時，沒有確認刪除的提示框
4.2.1.2重要解決bug列表
這部分主要列出測試過程中產生關鍵的並且解決了的bug，對於重要的bug，需要對其產生的原因和解決方法進行分析說明。
1、新增資訊時沒有必填項提示。
2、在新增各種資訊時，可以輸入空資料
4.2.1.3遺留bug列表
3、任務管理修改開始時間時，只能讀取到年月日的資料，但是資料庫能夠儲存到時分秒
4、任務不能到點自動執行，任務設定了執行開始時間及結束時間，但是到了時間並不能執行相關操作。
5、在重置密碼時，第一次不能發簡訊，必須要輸入完整資訊有錯誤用例之後才能傳送驗證簡訊。
6、當用戶輸入不對應自己的手機號的時候修改失敗，但是沒有提示
7、知識圖譜展示時，搜尋相關實體時，無法顯示其附近的三元組。
8、爬蟲部分結果無法寫入資料庫，因為網站上面的資料格式不同，雖然已經對不同格式進行了處理，但是仍有部分資料無法寫入。
9、當輸入的資訊過多時，知識圖譜顯示會出現重疊。
10、刪除資訊時，沒有確認刪除的提示框
4.2.2缺陷分析
本部分對上述缺陷和其他收集資料進行綜合分析。
部分缺陷因為改動影響過大所以沒有改。
4.2.2.1缺陷綜合分析
缺陷發現效率 ＝ 缺陷總數/執行測試用時
可到具體人員得出平均指標
用例質量 ＝ 缺陷總數/測試用例總數 ×100％
缺陷密度 ＝ 缺陷總數/功能點總數
缺陷密度可以得出系統各功能或各需求的缺陷分佈情況，開發人員可以在此分析基礎上得出那部分功能/需求缺陷最多，從而在今後開發注意避免並注意在實施時予與關注，測試經驗表明，測試缺陷越多的部分，其隱藏的缺陷也越多。
本次測試時長持續三天，缺陷發現效率為：8/3（個/天）
缺陷密度為：8/29
4.2.2.2測試曲線圖
描繪被測系統每工作日/周缺陷數情況，得出缺陷走勢和趨向。
無
4.3 效能資料與分析
這部分簡要地列出效能測試結果，並對測試結果進行分析說明，以說明是否符合軟體需求。該部分也可以在效能測試報告中進行說明。
無
4.3.1效能資料
記錄測試輸出結果，將測試結果的資料表格，圖表如實的反映到測試結果中。用於資料分析。
無
4.3.2測試結論
測試通過，能夠正式釋出。
第5章 測試總結和建議
這部分是測試報告中最關注的內容，主要是對測試過程產生的測試結果進行分析之後，得出測試的結論和建議。這部分為測試經理、專案經理和高層領導最關心的部分，因此需要準確、清晰、扼要地對測試結果進行總結。
5.1軟體質量
說明該軟體的開發是否達到了預期的目標，能否交付使用。
本專案雖然還存在一些小問題，但是我們基本達到了預期的目標，已經能夠交付使用
5.2軟體風險
說明測試後可能存在的風險，對系統存在問題的說明，描述測試所揭露的軟體缺陷和不足，以及可能給軟體實施和執行帶來的影響。
軟體可能存在的風險應該是知識圖譜展示方面，如果展示資料過大，會導致知識圖譜出現嚴重的重疊
5.3測試結論
對測試計劃執行情況以及測試結果進行總結，包括：
1．測試計劃執行是否充分（可以增加對安全性、可靠性、可維護性和功能性描述）
2．對測試風險的控制措施和成效
3．測試目標是否完成
4．測試是否通過
5．是否可以進入下一階段專案目標
本次測試的計劃執行的十分充分，解決了專案中的一些問題，而且測試目標基本完成，專案的測試可以通過，專案可以進入下一階段的開發與測試。
5.4 測試建議
對軟體的各項缺陷所提出的改進建議，如：各項修改的方法、工作量和負責人、各項修改的緊迫程度、後續改進工作的建議、對產品修改和設計的建議、對過程管理方面的建議等。
接下來的測試應該偏重知識圖譜的展示以及簡訊驗證方
測試報告如上，通過測試，我感受到了一個很難（或者無法保證100%）保證不出bug，不過通過努力，可以將bug的數量不斷的下降。最後通過這次測試我感受到了並且學會了在開發專案的時候要考慮哪些，要注意哪些等問題。