『編程題全隊』團隊做業5---測試博客

---

測試部分：

---

1.在測試過程當中總共發現了多少Bug？每一個類別的Bug分別爲多少個？

a.修復的bug

b.不能重現的bug

c.這個產品就是這樣設計的，不是bug；

d.沒有能力修復，未來也不打算修復；

e.這個bug的確應該修復，可是沒有時間在這個版本修復，延遲到下一個版本修復。

在功能性測試中
看板任務消失：點擊一個任務，在出現特定狀況時（任務大小超過看板寬度，並再次點擊其餘），任務消失。不可重現，屬於E類；
看板排序：點擊一個任務，任務自動排序到本欄中最下方。可重現，屬於C類。

BUG類別	A	B	C	D	E
BUG數/個	0	0	1	0	1

---

2.場景測試（scenario testing），包括如下內容：

a.你預期不一樣的用戶會怎樣使用你的軟件？

b.他們有什麼需求和目標？

c.你的軟件提供的功能怎麼組合起來知足他們的須要？

在《Gugua需求文檔中》2.3章用戶類和特徵中指出

咱們的軟件實現了任務事項的優先級分類，在繁雜的事務中能及時提醒用戶當前最重要的事項；完善事務的劃分以及提醒功能；將完成的事務保存以供往後翻查審計；在可以知足大多數人羣管理事務、提高效率需求下，增長了其餘功能的實現，如輕量級的團隊合做模塊，可以實現用戶更多的目標。

---

3.大家在什麼樣的平臺、硬件配置、瀏覽器類型等條件上對大家的軟件進行測試？——測試矩陣（test matrix）

	操做系統	處理器	主板	內存	硬盤	瀏覽器	數據庫	Windows	Linux
客戶端	Windows 10 專業版 64位	英特爾 第四代酷睿 i5-4258U 雙核	聯想 Lancer 4A2	三星 DDR3L 1600MHz / 金士頓 DDR3L 1600MHz	浦科特 PX-128M7VC（128G固態硬盤）		MySQL5.5.53	√	√

---

4.非功能測試

a.性能指標（響應時間和吞吐量，須要給出截圖和測試實例以及結果）

b.系統資源監控（CPU、內存佔用狀況，須要給出截圖和測試實例以及結果）

c.壓力測試（不一樣併發用戶數，須要給出截圖和測試實例以及結果）

d.疲勞度測試（測試服務器持續運行的能力，須要給出截圖和測試實例以及結果）

e.安全測試（從三個角度來看，即保密性、可用性、完整性。須要給出截圖和測試實例以及結果）

序號	所完成的測試	系統所指望的性能指標	實際測試結果	差異分析	性能問題及其改進建議
1	性能測試	服務器響應時間不大於3s	平均響應時間不大於3s	多用戶同時併發，單個的響應時間沒法準確反映真實狀況，使用平均響應時間爲準	因爲測試工具的侷限性，目前只能併發50個用戶。服務器性能的話仍是要用錢說話￥_￥
2	系統資源監控	CPU佔用少，內存佔用少	CPU佔用僅爲2.4%，內存僅爲20M左右	目前項目處於Alpha階段，功能實現較少，其餘設計還不徹底，天然體積小。	軟件自己的體積取決於設計和代碼的質量
3	壓力測試	多用戶併發	50之內用戶併發效果良好	功能實現較爲良好，服務器性能良好	壓力測試本是性能測試一部分，同理
4	疲勞度測試	服務器長時間運行而且狀態良好	該服務器已經處於長期的工做當中，且性能良好	無差異	啊又是服務器的問題，一是產品自己的質量，再是維護方面
5	安全測試	用戶數據以及安全漏洞	數據保密、可用以及完整不被篡改	基本實現安全性	經過數據傳輸中的加密算法，保證保密性；用戶數據同步在服務器數據庫中，以保證可用性；數據庫一樣須要加密保護，以防用戶數據被盜取、篡改。

性能測試
響應時間

吞吐量

系統資源監控

壓力測試
分別設置單個用戶、30個用戶和50個用戶併發（因爲測試軟件的緣由，沒法使用50個以上併發用戶）。

疲勞度測試

針對需求中的性能測試，進行了疲勞度測試，使用LoadRunner設置持續訪問服務器24小時，用以測試服務器持續運行能力，結果基本知足要求。

安全性測試

用戶登陸和註冊時輸入的密碼在服務器端通過加密算法存入數據庫中或者進行匹配，較爲安全。

---

5.你認爲大家團隊的軟件在什麼條件下，就能夠認定其已經足夠好，能夠發佈Alpha版本？——出口條件（exit criteria）

咱們團隊的項目的出口條件固然是在實現基本功能，無明顯且嚴重的BUG狀況下，能夠發佈Alpha版本。

---

發佈

發佈博客連接：『編程題全隊』Alpha階段發佈說明