測試與發佈

時間 2019-12-01

標籤測試發佈简体版

原文原文鏈接

測試

請根據團隊項目中軟件的需求文檔、功能說明、系統設計和測試計劃，寫出軟件的測試過程和測試結果，並回答下述問題。html

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

a.修復的bug；
b.不能重現的bug
c.這個產品就是這樣設計的，不是bug；
d.沒有能力修復，未來也不打算修復；
e.這個bug的確應該修復，可是沒有時間在這個版本修復，延遲到下一個版本修復。

測試過程當中共發現bug2個，其中a類bug一個，b類、c類、d類bug無，e類bug兩個。
a類bug：
①在register的頁面中，若是用戶名或密碼爲空或者密碼、確認密碼不一致，不會跳出提示信息。
e類bug：
①若是出現同名帳戶，會註冊失敗，可是用戶不會收到失敗的緣由；
②遊戲結束到主頁面以後返回，會回到別的頁面而不是退出。git

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

你預期不一樣的用戶會怎樣使用你的軟件？
他們有什麼需求和目標？
你的軟件提供的功能怎麼組合起來知足他們的須要？

小明是一名大三的學生，大三的學習和就業壓力令其感到煩躁，從而致使小明的精神萎靡，時常悶悶不樂，同時，因爲常常在宿舍被電腦遊戲消磨精力，小明的腦力也遭到了退化，這時候他能夠嘗試咱們的24點小遊戲。咱們的24點小遊戲最大的特色，就是在消磨閒暇時間、防止腦力衰退的同時，還適應瞭如今這種快節奏生活。也就是說你根本沒有必要花上一整塊時間來進行這個遊戲，而是可讓用戶在空閒時間達到以上的目的。而小明若是使用咱們的遊戲，我認爲他能夠再必定程度上減緩學習上、就業上的壓力，同時防止被電腦遊戲侵蝕，最重要的，咱們是一款益智類小遊戲，確定能夠給小明同窗帶去新的活力。數據庫

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

4.非功能測試

性能指標（響應時間和吞吐量，須要給出截圖和測試實例以及結果）
系統資源監控（CPU、內存佔用狀況，須要給出截圖和測試實例以及結果）
壓力測試（不一樣併發用戶數，須要給出截圖和測試實例以及結果）
疲勞度測試（測試服務器持續運行的能力，須要給出截圖和測試實例以及結果）
安全測試（從三個角度來看，即保密性、可用性、完整性。須要給出截圖和測試實例以及結果）
參考
http://www.cnblogs.com/freeton/archive/2013/05/31/3109815.html
http://www.javashuo.com/article/p-niigqpxj-ma.html
吞吐量：http://www.cnblogs.com/fnng/archive/2012/06/29/2570558.html
併發用戶：http://www.cnblogs.com/fnng/archive/2012/06/29/2570558.html
響應時間：http://www.cnblogs.com/fnng/archive/2012/07/01/2571990.html
Android應用性能測試：http://www.cnblogs.com/mliangchen/p/5125114.html

（1）性能指標：

上圖中記錄了併發數爲100時的吞吐量和程序的響應時間，吞吐量爲1600.23reqs/s，響應時間爲62.491ms瀏覽器

（2）系統資源監控：
應用佔用CPU率(%)（橫座標爲時間戳，縱座標爲佔用比例，下同）：

應用佔用內存比(%)：
安全

（3）壓力測試：

爲了直觀地分析這些數據，咱們生成下列曲線圖。首先來看吞吐率隨併發用戶數變化的曲線圖，以下圖所示。在併發用戶數達到100以前，隨着併發數的增加，服務器的資源被不斷地充分利用，因此其吞吐率在不斷提升。當併發用戶數爲100時，吞吐率最高。當併發用戶數超過100後，吞吐率開始走下坡路。

接着來看服務器平均請求處理時間隨併發用戶數變化的曲線圖。當併發用戶數開始增長併到達100的過程當中，請求的平均等待時間在逐漸地縮短，超過100以後，請求的平均等待時間又開始增長，當併發用戶達到500後，等待時間開始有較大幅度增長。

下面來看用戶平均請求等待時間隨併發用戶數變化的曲線圖，當併發數超過500後，等待時間開始急劇上升，當併發用戶數到達1000時，等待時間接近2s，這是使用者不能容忍的。
服務器

（4）疲勞度測試：

咱們的服務器是購買的阿里雲服務器，已經連續工做11天，故疲勞度的問題咱們不用擔憂、併發

（5）安全測試：
用戶登陸和註冊時輸入的密碼在服務器端通過sha1哈希以後在存入數據庫中或者進行匹配app