1. 程式人生 > >軟體測試(團隊)

軟體測試(團隊)

Part 0.開篇

作業連結

組長部落格連結

本次測試報告

本次評審表

Part 1.調研,評測

· 評測

  • 描述最簡單直觀的個人第一次上手體驗

整體深藍配淺灰的色調,第一眼看起來並不會有違和感,主介面課表頁課程分塊的底色多樣,可通過重新整理換色,直觀漂亮。

功能上基本滿足學生群體的必備需求,例如課表與成績的查詢,圖書館的便利服務,空教室的查詢,實驗預約等等,同時結合融入易班工具與期末考啦等等其他軟體,形成一個整合平臺,這一點足以吸引大多數本校學生群體。

同時單獨提一下該軟體的蘋果客戶端,增設一鍵評議與二手市場工具等功能,功能雖小卻給人帶來相當便利的使用者體驗。

  • 按照描述的bug定義,找出至少兩個功能性的比較嚴重的bug

    • 斷網環境下,二手市場功能因無法獲取資料而進入無休止的載入狀態
      • bug曝光:
      • 具體描述: 斷開wifi後,啟用福大助手的二手市場功能,因無法從伺服器端獲取資料,程式在載入狀態中執行迴圈等待,但未設定跳出條件判斷而陷入無休止的載入等待狀態中。
      • 可能發生的原因: 網路不穩定出現斷開網路或使用者無接入網路
      • 沒有發現此類bug的原因: 沒有充分考慮斷網未能獲取資料的異常處理
    • 設定下的推送設定點選後導致軟體未響應
      • bug曝光:
      • 具體描述: 進入設定模組,點選推送功能,程式出現快閃跳回設定介面後卡死未響應,軟體整體奔潰。
      • 可能發生的原因: 軟體自身內部存在程式碼錯誤
      • 沒有發現此類bug的原因: 沒有在軟體測試階段及時修復以至於該模組應用無法正常使用甚至導致軟體自身奔潰。
  • 假設你們團隊需要開發這套系統,需要注意哪些方面(架構、部署運維、微服務等)

可採取微服務的軟體架構方式,即將整體軟體應用構建成一系列按業務領域劃分模組的、小的自治服務,這些自治模組會處理他們自己的資料、執行不同的功能。這種服務分離的方式很大程度上使得整體可以輕易的構建、修改並拓展整合。獨立開發、獨立部署、錯誤隔離等,這些都非常適合於整套系統一個健壯的開發過程。

· 採訪

某同學甲
  • 介紹採訪物件的背景和需求(他們有沒有用過類似的APP,除了現有的功能還有別的需求麼)

    一位福州大學大三的學生。他目前在使用福大教務通和易班。他除了現有的功能沒有其他更多的需求。

  • 描述使用者使用這個產品的過程, 使用者的問題解決了麼?軟體在資料量/介面/功能/準確度上各有什麼優缺點?使用者體驗方面有問題麼?

    使用過程中他認為該軟體的介面比福大教務通要好看一些,福大教務通的功能它基本都有,而且還集成了其他的小功能,不用再去下載多餘的軟體。十分的方便。

  • 使用者對產品有什麼改進意見?

    主介面的懸浮按鈕太靠下了,不容易按到。無法通過向右滑動的方式開啟側邊欄,使用起來不太習慣。在使用一項側邊欄的其他功能時無法通過返回鍵回到主頁面。

  • 結論:經過這麼多工作,你一定有充分的理由給這個軟體下一個評價,請選擇一個結論

    非常推薦

某同學乙
  • 介紹採訪物件的背景和需求(他們有沒有用過類似的APP,除了現有的功能還有別的需求麼)

    一位福州大學大三的學生。他目前在使用福大教務通。他除了現有的功能沒有其他更多的需求。

  • 描述使用者使用這個產品的過程, 使用者的問題解決了麼?軟體在資料量/介面/功能/準確度上各有什麼優缺點?使用者體驗方面有問題麼?

    這個軟體的功能很豐富,基礎的功能與福大教務通使用的感覺一致,介面會更好一些,在課表的顯示上可以將未開始或以結束的課以灰色狀態顯示,這個功能很不錯。

  • 使用者對產品有什麼改進意見?

    對歷年卷這個功能希望裡面的內容能更新更豐富一些。

  • 結論:經過這麼多工作,你一定有充分的理由給這個軟體下一個評價,請選擇一個結論

    非常推薦

Part 2.分析

  • 估計這個專案做到這個程度大約需要多少時間(團隊人數6人左右,計算機大學畢業生,並有專業UI 支援)

估計大概要3個月左右,有專業的UI支援可以省去較多邏輯介面的問題,但是由於系統功能較多,需要爬取的資料量比較大,和原應用涉及的關係也比較多,因此開發和溝通週期應該不會太短,但是應該也會有一些現成介面,所以估計3個月左右。

  • 分析這個軟體目前的優劣(和類似軟體相比),並推理出開發團隊在軟體工程方面可以提高的一個重要部分(具體建議)

與福大教務通相比,福大助手的操作比較簡潔,但是視覺化稍弱。

福大助手較期末考啦功能會比較少一些。

易班的介面和功能比較美觀和齊全,但是邏輯不如福大助手簡潔和清晰。

福大圖書檢索系統載入速度快,但是不如福大助手介面簡單。

相似APP或網頁端:福大教務通、課程盒子、期末考啦、福大易班、福大圖書檢索系統、福大大學物理實驗選課平臺、福大教務處官網等。

相比較下,福大助手的頁面簡潔,邏輯清晰,載入快,但是功能不齊全,美觀性較弱。

  • 根據理解和體驗,畫出整個軟體所有功能邏輯框圖,根據重要度標識出各模組的重要度、完成度、出發點及效果

  • 針對不同的維度評分,對使用者體驗方面、UI介面美觀度、核心功能,分別打分
評分內容 滿分 團隊打 評分理由
使用者體驗 10 8 一站式的服務十分便捷,但存在少量bug
UI介面 10 7.3 介面簡潔,邏輯清晰,但圖示等美感較差
核心功能 10 8.5 功能較多,速度快,但是子模組功能不夠齊全

Part 3.建議和規劃

  • 如果你是專案經理,如何提高從而在競爭中勝出?

    提高產品的穩定性。儘量減少登入錯誤的情況發生,避免出現某個功能忽然無法使用的情況發生。

  • 目前市場上有什麼樣的產品了?

    福大教務通和福大易班。功能基本上差不多,都是可以查成績,考試安排和課表。

  • 你要設計什麼樣的功能?

    成績詳情。可以檢視每門課的平均分和和最高分,瞭解自己的學習情況。

  • 為何要做這個功能,而不是其他功能?

    從學生的需求出發,成績是他們所關心的。而出於競爭心理,他們也會有了解大家總體考試情況的需要。

  • 為什麼使用者會用你的產品/功能?

    因為學生都是比較關心成績的,不僅關心自己考得如何,也會想知道大家的情況,知道自己處於什麼樣的水平。

  • 你的創新在哪裡?可以用 NABCD 分析。
    • Need 需求:

      對於以上的創新,我們不禁可以想到,會有同學使用“福大助手”檢視成績時,不僅僅是想要看到一堆資料,更多的要檢視到圖表的型別,從而能夠更清晰的檢視到自身成績所處的位置。

      同時對於過於單一的介面形式,當功能過於多時,希望介面可以形式多樣化一些。
    • Approach 方法:
    1. 增加適當的圖表資訊,藉助統計學的方法進行對資料的分析。
    2. 對於各個不同功能的模組採用相對不同但又獨具功能風格的介面。
    • Benefit 好處:
    1. 使用圖表可以便於使用者直觀地檢視到相關資訊。
    2. 多樣且個性化的介面不僅可以很直觀的讓使用者區分開各個功能的介面模組,而且還可以豐富產品的內涵,這不僅是審美上的提升,還是功能上的改善。
    • Competitors 競爭:

      針對市面上的類似產品,我們主打整合功能型的產品。一款產品就可以滿足使用者對於諸多功能的需求,我們的產品雖然功能眾多,但是功能使用方面卻不遜色於單一功能的產品。
    • Delivery 推廣:

      首先,將我們的方案給客戶稽核,若稽核通過,我們將進行推廣,可以配合客戶的方法進行推廣,線上和線下進行推廣。線上,如:微信、微博、推特等App以及電視廣告等進行推廣;線下,如:傳單宣傳、講座宣傳等措施進行。
  • 如果你來領導這個團隊,會有什麼不一樣?

如果讓我來領導這個團隊,我應該會比較注重團隊的規範化和制度化。比如時間表的成立,哪個時間該完成什麼事情強制的列出來,並且比較詳細的對隊員要求工作,而不是等到截止日期之前才來完成。而且技術文件的建立也很重要,比如遇到的技術上的bug有同學解決了,那麼就更新到文件裡,遇到同樣問題的同學可以進行查閱,從而降低學習成本。

  • 如果你的團隊有5個人, 4個月的時間,你作為專案經理,應該如何配置角色(開發,測試,美工等等)?
任務 人數 所佔時間比
後端程式碼研發 2 40
美工和介面 1 30
測試 1 20
靈活調整部分(統籌和監管等) 1 10
  • 文字說明:

一個人負責監管和統籌整個專案程序,合理把握產品的研發方向;兩個人完成主要的後端程式碼的開發;一個人負責介面和美工;一個同學完成測試。具體情況還應當根據團隊的實現能力來進行,根據完成的質量和效率進行調整。整體時間比例:開發和測試整體佔60%;美工和介面的實現佔30%;剩餘的10%屬於靈活時間的調配,可根據具體情況增加或減少。

  • 描述你的團隊在16 週期間每週都要做什麼,才能在第16周如期釋出軟體,大小里程碑績點設定。
週數 任務安排
第一週 小組第一次會議,將接下去的工作列表化和明確化;討論整體的功能佈局;分配任務。
第二週 小組進行考察,考察市面上類似的產品,並對其進行產品評估,列出類似產品的優缺點,為接下來的研發做好準備。
第三週 進行介面的設計和佈局的規劃。
第四周至第七週 進行產品後端的程式碼研發,同時介面和美工組進行相應的除錯以及跟後端組進行會談,改進原始方案。
第八週至第九周 測試人員進行產品測試,此時前端、後端、測試人員一齊進行協作。
第十週至第十五週 針對前期遇到的問題每個小組進行改整,繼續完善產品。
第十六週 靈活時間,繼續完善產品,(養成在deadline前完成的好習慣。)等待最終的釋出。
  • 專案釋出後,有沒有考慮過專案該怎麼部署才能滿足需求。依據附錄圖(某校教務處系統的部署)作為參考,分析16周後你所完成的專案上線需要哪些配套裝置(伺服器、頻寬、資料庫需求數量與配置)

應用伺服器配置:2 核 2G * 12

後端伺服器配置:16 核 64G * 4

關係型資料庫數量:12(備份 4)

快取資料庫數量:6(備份 2)

網站安全性:WAF、DDOS

Part 4.增量開發設計

優化/新增的功能點

優化功能:

想必都有用過一鍵評議功能,期末查成績的時候或者選課的時候還要逼迫我們評議,雖然福大助手的一鍵評議對學生很友好,但是評議的分數都是隨機的,對於那些你喜歡的老師就不是很友好,所以希望在一鍵評議功能上新加一個可以選擇分數的功能。

新增功能:

線上列印資料功能:線上列印ppt或歷年卷,線下到店取或者出點小錢線下送貨。

選課功能:現在為止好像任何一個軟體都無法實現選課功能,選課還要登陸教務處網上很麻煩,希望能增加一個選課功能。

基本實現思路:

評議功能優化:

在評議介面加入分數選擇,可以設定整體分數,也可以為每位老師設定分數。

新增線上列印資料功能:

這個功能實現起來需要成本,但是也是能夠賺錢的主要功能。實現上分為線上與線下兩部分。

線上:在資料的下載介面上新增列印資料功能,即可跳轉到設定介面,設定列印的格式,如單面雙面、份數、一面多頁、是否裝訂、是否送貨上門、以及收件地址等功能,還可以新加選擇商家功能,設定完畢後跳轉支付頁面,支付成功後商家接單處理。

線下:可以自立門店,與別的商家競爭,也可以與校內商家合作,從中賺錢利潤。

新增選課功能:

這個功能需要自立門戶,在主選單中加入選課功能,相關的選課操作和教務處一致。

優化/新增功能點與原有產品如何接入:

一鍵評議新增設定分數功能接入:

此功能在一鍵評議功能上新增,系統自動評議時獲取分數的資料從使用者的輸入欄上獲取,而不是隨機獲取,對於使用者未輸入分數的欄目還是使用隨機數。

線上列印資料功能接入:

此功能在歷年卷功能下接入,在使用者下載文件介面選擇線上列印,隨後跳轉到線上列印設定介面。

選課功能接入:

此功能從主介面加入,選課資訊要從教務處調入,主要設計好符合人性的選課介面,將學生選完的資訊返回教務處。

Part 5.答辯總結

組員得分細則

姓名 得分(百分制比例%)
柯奇豪 24
蔣雄 21
黃志銘 12
黃毓明 7
林翔宇 8
丁水源 8
楊禮亮 12
林淇 8

評審表格設計

Final Score

小組 評分
第一組 74
第二組 82
第三組 78
第四組 77
第五組 72
第六組 71
第七組 72
第八組 79
最低分 71(第六組)
最高分 82(第二組)
有效分數 74,78,77,72,72,79
最終平均得分 75.4

Q&A

第四組

Q1: 現場播放音樂讓人有些分心,下次希望可以換一種音樂或者不放。

A1: 好的,我們會吸取經驗,爭取下次能夠讓你們滿意。

Q2: PPT中第五頁左上角的餅狀圖讓人難以分辨,希望可以改進。

A2: 謝謝你們的提意,我們會對這一部分進行適當地改進的。

Q3: 有的bug有標註是ios系統,那麼沒有描述的bug是否是安卓端的呢?

A3: 由於裝置原因,其餘的大多數是安卓端的,我們也認識到了我們的測試不足,會爭取進行改進的。

第五組

Q1:BUG測試記錄的第五點圖片太多引起接下來的表格很多空白,能夠
否適當排版一下,還有第二張圖片反了

A1:好的,我們會對此問題進行修改,並引起注意

Q2:報告中IOS的BUG測試是否太少了?

A2:你好,你應該是說反了,應該是安卓較少,可能我們測試的時候疏忽,我們下次會注意。

Q3:能否再測試報告中加上具體的人員分工?

A3:好的,我們會對此問題進行修改,並引起注意

第八組

Q1: ppt的右側的黃色欄感覺看的很不舒服很多餘,字很小,希望能考慮到聽眾的視覺感受

A1: ppt的問題我們會根據大家的意見去改進,同時也學習一些ppt做的好的組的ppt。

Q2: 考卷列印的具體實施方案能否分享一下?

A2: 考卷列印我們想做一個外賣的入口,列印店作為商家,商品為列印的份數,將資料的編號作為外賣的備註新增。這是我們覺得目前比較可行也比較容易實現的方式。

Q3: 雖然有一定難度,但是還是一提研究生和導師賬號登入後的介面是否有過測評?

A3: 這個我們當時沒有想過這方面的,也沒有獲得這些賬號的渠道。

Part 6.個人部分

  • 個人PSP
PSP Personal Software Process Stages 預估耗時(分鐘) 實際耗時(分鐘)
Planning 計劃
· Estimate · 估計這個任務需要多少時間 0 0
Development 開發
· Analysis · 需求分析 (包括學習新技術) 0 0
· Design Spec · 生成設計文件 0 0
· Design Review · 設計複審 (和同事稽核設計文件) 0 0
· Coding Standard · 程式碼規範 (為目前的開發制定合適的規範) 0 0
· Design · 具體設計 10 10
· Coding · 具體編碼 60 80
· Code Review · 程式碼複審 0 0
· Test · 測試(自我測試,修改程式碼,提交修改) 10 20
Reporting 報告
· Test Report · 測試報告 0 0
· Size Measurement · 計算工作量 10 10
· Postmortem & Process Improvement Plan · 事後總結, 並提出過程改進計劃 10 10
合計 100 130
  • 個人學習進度條(每週追加)
第N周 新增程式碼(行) 累計程式碼(行) 本週學習耗時(小時) 累計學習耗時(小時) 重要成長
10 N N 12 99 進行微信小程式自定義控制元件部分的學習,學習傳遞控制元件內資料的方式