軟體測試作業

一、總覽和相關連結

這個作業屬于哪個課程	2020春|W班
這個作業要求在哪裡	軟體測試作業要求
這個作業的目标	對騰訊即時通訊Demo進行測試、分析和建議
作業正文	軟體評測作業
其他參考文獻	《建構之法》第三版 鄒欣著

二、評測與采訪

評測（Demo方式）

Web評測截圖

小程式評測截圖

Android評測截圖

已發現的BUG

1. 敏感詞檢測功能不完善

BUG示範

聲明：以下發送的敏感詞僅用于測試，并無其它意圖

示範1 Android發送敏感詞

示範2 Web端發送敏感詞

BUG描述

  含有敏感詞的會話消息在第一次發送時均會被檢測并導緻發送失敗。但是若多次嘗試重新發送該消息，則能夠将該條消息成功發送，資訊接收方也可接收到該條消息。經測試，所有Demo平台都能夠通過此方式将帶有敏感詞的消息發送出去。

BUG詳細資訊

• 平台：全平台
• 嚴重程度：極其嚴重！有可能導緻不利于國家和社會的消息被廣泛傳播，也會破壞網絡言論環境。
• 觸發頻率：每次

為什麼開發人員沒發現這個問題？

  開發人員雖考慮到了敏感詞檢測，但未覆寫消息發送請求的所有類型。含有敏感詞第一次發送會被攔截，但是後續消息發送是在原發送失敗消息的基礎上重發，必然消息請求内容不同，對于這方面的消息合法性檢測和處理，開發人員考慮的不夠周到。即沒有滿足《建構之法》非功能測試中服務品質需求，實作基本功能固然重要，但是也要考慮功能的使用需求再進行進一步的完善和特性化定制，目前開發人員缺乏此方面的考慮。

2. Android端未讀消息狀态未更新

  Android端發送消息後，若消息接收者通過非Android端檢視消息，則會導緻消息發送方始終顯示發出的消息為未讀狀态。

BUG消息資訊

• 平台：安卓系統 MIUI-11.0.8
• 嚴重程度：比較嚴重。若發出的消息始終顯示為未讀狀态，會引起許多不必要的誤會，導緻不良的後果。

為什麼開發人員沒發現這個問題

  Demo隻有Android APK和IOS應用支援消息未讀已讀功能。說明開發團隊在不同裝置上的功能劃分有所不同，但是負責不同裝置的開發團隊的消息接收回報沒有進行同步處理，導緻隻有同系統的手機終端才能正常使用消息未讀已讀功能。可能的原因之一是負責Android和IOS的開發團隊沒有向其它開發團隊要求消息接收回報，還有可能是其它開發團隊并未提供該接口或該接口未實作消息接收回報到移動端的功能。

3. 小程式群聊未讀消息氣泡

  當群組有新成員加入或群組資訊被修改時，該群組将顯示未讀消息氣泡。進入該群組檢視聊天消息、檢視成員消息、檢視群組資訊之後未讀消息氣泡仍舊存在，在主界面手動重新整理之後氣泡才消失。

• 平台：安卓系統 微信小程式 微信版本7.0.11
• 嚴重程度：一般。錯誤提示群組有未讀消息且無法消除是部分使用者無法忍受的。
• 觸發頻率：經常，當群組新增成員和群組資訊修改時大機率會出現。

  微信端的未讀消息氣泡的消除處理僅考慮了會話消息的檢視，并未考慮到群組資訊變化帶來的影響，而在其它平台卻沒有這個問題。《建構之法》中提到，使用者體驗要貫穿到多種裝置，保證同一産品在不同裝置上有同一體驗，很顯然負責不同裝置的開發團隊之間的統一标準還不夠明确和細緻，導緻了不同裝置執行着同樣的功能，體驗卻不盡相同，甚至出現了BUG。

采訪

SDK構思

項目概述

  使用騰訊即時通訊SDK給某手機遊戲新增内置一個聊天子產品，消息類型僅限文字、表情和音頻。

主要功能

1. 玩家可以在公共頻道文字聊天
2. 玩家可以互相添加好友，進行私聊
3. 黑名單功能能屏蔽某個玩家的會話消息
4. 工會（或稱戰隊）相當于一個群組，隊長能對其進行管理，其它玩家也可以進入，玩家可在工會内讨論
5. 每個玩家都可以收到伺服器的通知資訊

面向使用者

  該遊戲的所有玩家

NABCD分析

• Need（需求）
  • 許多移動端玩家渴望遊戲内的聊天功能
  • 遊戲需要聊天子產品來吸引使用者，增加活躍度
• Approach（方法）
  • 使用騰訊即時通訊Android和IOS的SDK進行通訊功能的開發
  • 界面設計使用Vux基于WeUI和Vue(2.x)開發的移動端UI元件庫設計
  • 和遊戲開發團隊協作完成界面設計和聊天遊戲事件處理
• Benefit（好處）
  • 擁有聊天功能可以增加玩家的互動感、歸屬感，吸引更多的玩家，增加遊戲人氣
  • 伺服器的通知資訊能更加友善地通知到玩家，使玩家更清晰地擷取訊息
  • 延長遊戲壽命，增加遊戲收入
• Competitors（競争）
  • 移動端許多遊戲并沒有内置聊天子產品，相比他們我們很有優勢
  • 大部分移動端遊戲的聊天子產品僅僅提供聊天功能，并不支援加好友、黑名單、工會等此類操作，我們的聊天子產品還整合了部分遊戲事件
• Delivery（推廣）
  • 遊戲廠商在各大媒體的廣告投放
  • 遊戲廠商在各大應用市場的部署

使用者采訪

調查對象背景：男，21歲，在校大學生，軟體工程大三在讀

體驗方式：Web端、IOS

需求：大型論壇即時通訊聊天室。聊天室賬号即為論壇使用者ID，聊天室不開放音視訊通話，僅限文字交流。聊天室内可添加好友，效果和論壇加關注相同；也可将使用者拉黑名單，即聊天室内的操作和網頁論壇的操作達到一樣的效果。

使用體驗

  受訪對象先體驗了Web端的Demo，注冊了兩個賬号，并加入了群組進行使用。依次體驗了建立對話，好友間互動、加入群組、群組聊天、群組管理、黑名單功能。之後又安裝了IOS用戶端進行了和上述流程一緻的體驗，随後進行了Web端和IOS端的通話，具體體驗感受如下：

• 資料量
  1. 最好能保證一千人線上聊天無障礙，該Demo可以滿足要求
  2. 伺服器存儲能力有限，消息漫遊時間不長，能否将聊天記錄資料儲存在本地？需要在Demo基礎上進行二次開發。
• 功能
  1. 消息類型（表情、圖檔、視訊、檔案）比較豐富，這一點比較滿意
  2. 群管理功能比較雞肋，論壇是公共場合，需要更強大的群管理功能來保證聊天室和論壇的環境
  3. 添加好友驗證形同虛設，輸入ID号直接就能加好友不合理
• 界面
  1. 界面比較美觀，簡潔，資訊醒目，排版整齊
  2. 敏感詞報錯界面不夠明顯，提示資訊比較奇怪
• 準确度
  • 消息傳輸及時迅速，提示消息明顯準确

  總體來說，受訪對象對該Demo比較滿意，部分功能不盡人意但也能保證基本使用，并無太大體驗的問題。

對騰訊IM改進意見

  受訪對象認為：添加好友功能要進一步完善，要達到QQ那樣的要求；群組管理的功能也要進行大幅度的加強；新增消息聲音提醒，回報要更加明顯。

對我開發産品的意見

  遊戲内置聊天子產品觸發的遊戲事件要細化和謹慎設計，要積極和遊戲開發團隊溝通，否則會導緻項目失敗，必須要保證功能的健壯性。

結論

  我對騰訊即時通訊的評價：推薦

采訪截圖

三、分析

時間分析

  對于大學畢業的6人團隊，實作成品大概要6個月時間。大學畢業的學生非比已就業的開發人員，大部分都沒有進行架構的深入學習，開發時可能會出現不熟練或不了解架構技術的情況，這會拖慢項目的完成時間，是以保守估計需要半年時間完成到SDK的程度。但是對于有項目開發經驗、技術架構運用熟練的團隊，完成時間可縮短到4個月。

優劣比較

優點

• 具有敏感詞屏蔽功能
• 消息能夠撤回
• 群成員上限更多
• 資費更低

缺點

• 消息漫遊時間很短，僅一周
• 關于SDK的相關服務（客服，運維等）較少，服務範圍不夠全面

團隊提高建議

  要充分了解實作目标功能所需的技術。隻有對所需技術進行充分了解，可行性分析才能更加精确和合适，項目風險管理也能獲得很大的進展，進而準确的制定項目完成所需時間、人員配置設定等。

四、建議和規劃

如果你是項目經理，如何提高進而在競争中勝出？

• 與遊戲開發團隊進行充分的交流，確定開發出滿足需求的産品
• 對廣大的玩家需求調研，總結并仔細分析使用者需求
• 對服務功能需求子產品（即聊天和遊戲事件聯系）進行缜密的規劃和細緻的設計，并在該功能子產品增加分工，以保證這個“人無我有、人有我強”的功能子產品的易用性、健壯性、高效性

目前市場上有什麼樣的産品了？

  移動端存在于騰訊網易等部分高人氣遊戲中，如王者榮耀、和平精英等

你要設計什麼樣的功能？

為何要做這個功能，而不是其他功能？

  正如第二部分SDK構思中提到，聊天子產品的導入能增加玩家的互動感，進而提升體驗玩家、給遊戲營運商增加收入。

為什麼使用者會用你的産品/功能？

  與人交流是人的本能，許多玩家也樂于在遊戲内進行聊天互動。将遊戲事件整合入其中，更加能吸引玩家，激起使用者使用興趣。

你的創新在哪裡？

如果你來上司這個團隊，會有什麼不一樣？

  我會不斷和遊戲開發人員以視訊會議等交流聯系，總結清楚開發任務和需求。定期召開項目會議，總結問題、協調任務、做出調整，

如果你的團隊有5個人, 4個月的時間，你作為項目經理，應該如何配置分工？

• 界面設計 1人
• 聊天子產品設計 4人
  • 基礎聊天功能導入 2人
  • 遊戲事件整合 2人

描述你的團隊在周期為16周，每周都要做什麼，才能保證在第16周如期釋出軟體。

時間	任務
第1周	需求分析、分工、SDK學習
第2周	撰寫需求文檔 遊戲事件處理學習
第3周	原型設計 聊天子產品初步設計
第4周	原型傳遞甲方，根據回報進行相關修改 召開開發前會議，明确任務分工
第5~8周	完成界面的初步設計 聊天子產品的初步功能 進行遊戲事件的初步整合
第09周	傳遞甲方測試版本，根據回報修改相關功能
第10~14周	完成頁面的整體設計 聊天子產品功能實作 遊戲事件完全整合
第15周	進行測試，修改漏洞和不完善的功能 開發收尾總結會議
第16周	傳遞項目

項目釋出後，項目該怎麼部署才能滿足需求？

遊戲内置聊天子產品比較特殊，部署需要考慮以下内容

• 使用者數較多：日通路10萬左右，帶寬大，并發能力強
• 存儲容量要求不高：隻負責轉發、不負責存儲消息，但要存儲玩家的工會資訊
• 資料庫：MySQL
• 消息的及時性：高傳輸速率

綜合考慮上述因素選擇以下部署方案

産品類别	機架式
CPU類型	Intel i7
CPU型号	i7-9700
記憶體類型	DDR4
記憶體容量	64GB
硬碟容量	4TB
關系型資料庫	MySQLx3(讀寫分離x2、備份x1)
緩存資料庫	Redisx2(主備)
網絡控制器	NC382i 雙端口千兆網卡x2