請根據團隊項目中軟件的需求文檔、功能說明、系統設計和測試計劃,寫出軟件的測試過程和測試結果,並回答下述問題。html
1、在測試過程當中總共發現了多少Bug?每一個類別的Bug分別爲多少個?(10分)sql
在測試過程當中總共發現了5個Bug瀏覽器
a.修復的bug(2個);tomcat
1.sql server用Date類型存日期的時候,讀出來的時間比存進去的時間會少兩天微信
這個問題我查資料後發現這是微軟的鍋。微軟官方給出的解釋是,若是要避免出現這樣的問題,須要使用jre1.5或者1.6。而我用的是jre.1.8。網絡
解決這個問題的方法:我把Date類型換成了DateTime類型。session
2.用<a>標籤url傳遞參數的時候,不能出現包括漢字在內的不少非法字符模塊化
相關代碼以下圖佈局
這個問題是測試的時候偶然發現的。此處,咱們本來想經過<a>標籤傳遞用戶名${package.owner}到後臺servlet(上圖註釋部分)。開發的時候並無發現這個問題,由於當時調試用的全是英文名字。作測試的時候用了一箇中文名,結果就404了。console報的錯誤類型是:Invalid character found in the request target.The valid characters are defined in RFC 7230 and RFC3986查資料後發現經瞭解,這個問題是高版本tomcat中的新特性:就是嚴格按照 RFC 3986規範進行訪問解析,而 RFC 3986規範定義了Url中只容許包含英文字母(a-zA-Z)、數字(0-9)、-_.~4個特殊字符以及全部保留字符(RFC3986中指定了如下字符爲保留字符:! * ’ ( ) ; : @ & = + $ , / ? # [ ])。而咱們的系統在經過地址傳參時傳遞的是漢字,而漢字不在RFC3986中的保留字段中,因此會報這個錯。測試
解決辦法如上圖:咱們把經過url傳參改爲form表單提交,把咱們想傳遞的參數設置成form表單中的一個隱藏域。
b.不能重現的bug(0個)
這個暫時沒有發現
c.這個產品就是這樣設計的,不是bug;(1個)
這個問題是咱們的用戶(其實就是否是咱們小組的同窗)提出的,他說咱們有受助者發表comment,提供幫助的人卻不能對此comment進行回覆。其實,這和咱們的設計有關,comment首先在咱們的系統中不是主要功能;其次,咱們設計的時候,咱們的初衷是但願受助者能夠經過comment這個功能對幫助者表達感謝,僅此而已。
d.沒有能力修復,未來也不打算修復;(1個)
包括髮布快遞信息,未匹配成功自取以後須要手動移除這條代取信息這些功能,若是咱們擁有來自快遞公司系統的數據,這些都能自動實現,到時候用戶體驗將會大大提高。可是鑑於如今的條件,咱們沒法得到這個數據,所以短時間內,咱們不會去修復這個BUG.儘管如此,咱們的項目模塊化設計是考慮到這點,屆時只須要把手工輸入模塊換成自動輸入模塊就能夠,其餘部分不用修改。
e. 這個bug的確應該修復,可是沒有時間在這個版本修復,延遲到下一個版本修復。(2個)
1.在發佈快遞信息以後,若是咱們刷新地址欄,就會發布一條新的快遞信息,這條新信息除pakageId和以前的不同,其餘都同樣。這個是不符合咱們設計預期的。由於咱們預想的是,若是用戶要發佈新快遞信息,必需要手動填寫信息,而後提交。
2.咱們預期用戶使用本系統的全部功能都要先登陸。雖然這個版本在登陸成功後第一個頁面控制的servlet中加入了判斷session中的user屬性是否爲空,可是後面的就沒寫了。這致使咱們能夠在未登陸的時候,直接經過url地址訪問到後面的頁面。這是咱們不但願看到的。
咱們暫時解決這兩個bug的思路是經過過濾器filter控制訪問。
2、場景測試(scenario testing),包括如下內容:(5分)
A:你預期不一樣的用戶會怎樣使用你的軟件?
第一類用戶:想要讓別人幫助本身拿快遞的同窗,先會進入咱們的官網瞭解一下咱們彼岸芳華平臺,一進入頁面,便會播放咱們的宣傳視頻,因而用戶會滑到宣傳視頻那裏,直觀的瞭解一下咱們平臺,觀看完視頻以後會看到旁邊的top10,向下滑,瞭解完top10,便會看到一些成功的互助案例,而後註冊成爲咱們的用戶,點擊發布最新快遞信息,就能夠將本身的快遞信息發佈上去,等待匹配,在與我相關頁能夠查看快遞最新詳細信息。
第二類用戶:但願經過幫別人代取快遞來賺取好人值以方便後來別人代取本身快遞的用戶。該類用戶將本身的快遞信息以及取快遞時間上傳至網站,經過但願別人代取快遞的用戶查詢和主動聯繫來幫助他人代取快遞,完成代取任務後得到好人值。
第三類用戶:須要咱們幫忙作活動宣傳的各院活動負責人。可能據說過有一個校園代取快遞的彼岸芳華,以爲名氣挺大,便會想着經過咱們的平臺來宣傳本身學院辦的活動,擴大影響力,咱們在主頁面以及快遞頁,與我相關頁均設了廣告專區,這類用戶會衝着宣傳活動成爲咱們的用戶。
B:他們有什麼需求和目標?
第一類用戶:需求很明確,就是須要在本身忙的時候能夠找一個可靠的人幫本身取快遞,彼岸芳華無疑是一個最好的選擇,由學號註冊,都是本校學生,有必定的保障,並且只要有足夠的好人值便不須要付費,好人值能夠由幫助別人取快遞得到。
第二類用戶:需求即上傳本身的快遞信息及代取時間;目標即得到好人值,便於之後聯繫他人讓他人代取快遞。
第三類用戶:用戶想要達到的就是經過彼岸芳華平臺提高本身活動的知名度。宣傳是一個活動成功與否的很重要的環節,一個再好的活動,宣傳力度不夠,也撐不起來場子,可是現階段學生活動宣傳僅僅限制在海報、qq、微信、H5等等,有時推送在揚思網上,閱讀量也是少之又少。急需一個既能夠知足校園宣傳,又能夠有較大影響力的平臺,彼岸芳華無疑又是最好的選擇。
C:你的軟件提供的功能怎麼組合起來知足他們的須要?
前兩類用戶之間的關係能夠轉換。目前幫人代取快遞的用戶未來也能夠成爲被人代取快遞的用戶,好人值是靠幫人代取快遞增長的,同時被人代取快遞則需消耗好人值。對於第三類用戶可經過廣告區向前兩類用戶展現本身的活動內容,從而達到宣傳的目的。快遞代取區這些功能結合起來,能夠更好的知足各種用戶的需求。
3、大家在什麼樣的平臺、硬件配置、瀏覽器類型等條件上對大家的軟件進行測試?——測試矩陣(test matrix)(10分)
|
用戶 類型 |
屏幕 分辨率 |
操做系統 |
操做系統 默認語言 |
網絡速度 |
瀏覽器 |
組合 總數 |
變量數目 |
3 |
2 |
3 |
3 |
3 |
3 |
486 |
|
用戶 |
800像素×600像素 |
Win7 |
中文(簡體) |
撥號 |
Chrome |
|
|
瀏覽者 |
1024像素×768像素 |
Win8 |
中文(繁體) |
ADSL |
IE7 |
|
|
管理員 |
|
Win10 |
英語 |
局域網 |
Firefox |
|
測試項 |
檢查點 |
預期結果 |
火狐Firefox |
IE瀏覽器 |
谷歌 |
登陸、註冊界面 |
登陸界面佈局 |
正常顯示 |
✔ |
✔ |
✔ |
不輸入登陸信息點擊登陸按鈕 |
沒法登陸 |
✔ |
✔ |
✔ |
|
輸入錯誤的登陸信息 |
沒法登陸 |
✔ |
✔ |
✔ |
|
輸入正確的登陸信息 |
跳轉到用戶界面 |
✔ |
✔ |
✔ |
|
點擊註冊按鈕 |
跳轉到註冊界面 |
✔ |
✔ |
✔ |
|
輸入不正確的註冊信息 |
註冊失敗 |
✔ |
✔ |
✔ |
|
輸入正確的註冊信息 |
註冊成功 |
✔ |
✔ |
✔ |
|
點擊好人值 |
顯示好人值排行榜 |
✔ |
✔ |
✔ |
|
用戶界面 |
界面佈局 |
正常顯示 |
✔ |
✔ |
✔ |
點擊發布新快遞信息按鈕 |
進入發佈界面 |
✔ |
✔ |
✔ |
|
點擊匹配按鈕 |
顯示快遞信息 |
√ |
✔ |
✔ |
|
點擊移除按鈕 |
移除快遞當前信息 |
✔ |
✔ |
✔ |
|
快遞信息發佈界面 |
輸入錯誤的快遞信息 |
發佈失敗 |
✔ |
✔ |
✔ |
輸入正確的快遞信息 |
發佈成功並在用戶主頁顯示快遞信息 |
✔ |
✔ |
✔ |
|
匹配界面 |
點擊匹配按鈕 |
顯示彼此關係 |
✔ |
✔ |
✔ |
點擊助人按鈕 |
好人值加一且清除已經匹配的快遞信息 |
✔ |
✔ |
✔ |
|
點擊求助按鈕 |
好人值減一且清除已經匹配的快遞信息 |
✔ |
✔ |
✔ |
|
點擊退出登陸 |
匹配成功且退出系統 |
✔ |
✔ |
✔ |