1. 程式人生 > >Beta版本測試報告以及Beta版本發布說明

Beta版本測試報告以及Beta版本發布說明

exit 不能 -1 行處理 滿足 修復 相對 學校 sting

Beta版本測試報告

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

  1. 在測試過程中總共發現了多少bug?每個類別的bug分別為多少個?
    bug的分類:

    技術分享


    a. 修復的bug
    1.當使用添加功能時,沒有填寫數據會造成空指針異常,跳轉到報錯頁面;

    技術分享

    技術分享

    2.當刪除有依賴性關系時的,沒有提示有記錄存在;

    技術分享

    技術分享

    3.當有已報修記錄時,沒有對處理報修單,按鈕進行處理,會造成重復報修,出錯;

    技術分享

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

    添加設備類型時,部件有添加上限:

    技術分享

    d. 沒有能力修復,將來也不打算修復;

    當某些瀏覽器使用極速模式時,頁面的樣式和js效果無法顯現

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

    只要通過查看源碼,可以通過輸入網址,就可以進頁面(無需登錄):

    技術分享

    解決初步策略:

    策略1:每個頁面都判定一下,session中有沒有user存在,如果沒有,直接跳轉到登錄界面;

    策略2:使用Filter類過濾,chain方法可以判定每個頁面是否有user存在;

    策略3:使用struts2自帶的攔截器Interceptor,然後在struts.xml配置文件中配置攔截器解決;

  2. 場景測試(scenario testing),包括以下內容:

    a. 你預期不同的用戶會怎樣使用你的軟件? 我的用戶主要為實驗室的同學們,在他們上機的時候發現所用的電腦有問題直接申請報修方便快捷。老師管理那邊也很容易看見匯總後自己想要的結果提升效率。

    b. 他們有什麽需求和目標?學生:擺脫以往的手工登記費事費力的這項工作調動大家都是主人翁的態度積極參與進來:管理老師:方便匯總統計大大提升工作效率

    c. 你的軟件提供的功能怎麽組合起來滿足他們的需要?媒人一樣牽線搭橋,將學生老師的所需信息匯總分類後給雙方各自所需要

  3. 你們在什麽樣的平臺、硬件配置、瀏覽器類型等條件上對你們的軟件進行測試?——測試矩陣(test matrix)技術分享

  4. 你認為你們團隊的軟件在什麽條件下,就可以認定其已經足夠好,可以發布Beta版本?——出口條件(exit criteria)

管理員能添加用戶、管理實驗室及其設備,還有查看報修單,處理完畢後,修改設備狀態。

學生登陸系統後,通過之前設置好的選項,能比較輕松地完成報修。

Beta版本發布說明

軟件發布的同時,在團隊博客上寫一個發布說明

  • 列出這一版本相對於Alpha版本的新功能:
    • 在Alpha階段,我們的用戶原來設計的是註冊,後來又改成由管理員後臺添加,現在我們打算添加由Execl直接導入用戶信息。
    • 添加軟件模塊
    • 添加設備類型與修改

  • 列出這一版本對Alpha版本修復的缺陷:
    • 我們改善l了自己的界面設計,之前只照顧了功能,沒有對UI設計放太多精力,這次會側重在用戶體驗方面(畢竟軟件是給人用,要讓人看起來不會不舒服)。
    • 對於一些異常的處理與提示。

  • 對運行環境的要求:在瀏覽器上運行即可

  • 安裝方法:電腦上配備有web瀏覽器即可

  • 說明軟件的發布方式以及發布地址:發布方式:發布到web服務器上
    發布地址:http://172.21.10.33:8080/lrsPrj
    (校園網的IP每次連接都會變,如果不能訪問請留言。且每天的23:00-6:00學校斷網,請避開這個時間訪問)

Beta版本測試報告以及Beta版本發布說明