在測試過程中發現了多少bug？
你是怎麼進行場景測試（scenario testing）的？包括你預期不同的使用者會怎樣使用你的軟體？他們有什麼需求和目標？你的軟體提供的功能怎麼組合起來滿足他們的需要？
在alpha階段已經提到的使用者型別，此處不再提及。此處提及預期使用者會如何使用我們的新功能。
經常忘記ddl的冒失同學
使用者資訊
使用者情況
姓名廣瀨康一
使用者身份
對日期和ddl不敏感的同學
使用者動機
希望能有一款產品時刻檢視、提醒自己作業ddl，且無需手動匯入
使用者困難
課程中心沒有手機相關的適配，且電腦端訪問課程中心比較麻煩
典型場景
通過手機端直接收到了作業ddl的截止資訊，立馬投入工作
場景測試：廣瀨康一
你是否有回歸測試確保新功能的加入沒有影響已有功能？請給出一到兩個測試用例並解釋。
典型的回歸測試用例有如下幾個例子：
給出你的測試矩陣（test matrix），也即在什麼樣的平台、硬體配置、瀏覽器型別……上對你的軟體進行測試？
測試機型
android版本號
登入功能
alpha版本各項功能
校歷功能
空教室查詢功能
課程評價搜尋功能
課程評價功能
小公尺 max 2
7.1.1
正常正常
正常正常
正常正常
小公尺 8
8.1.0
正常正常
正常正常
正常正常
紅公尺 k20 pro
10正常
正常正常
正常正常
正常oppo r11 plus
7.1.1
正常正常
正常正常
正常正常
魅族 16th
8.1.0
正常正常
正常正常
正常正常
華為 honor 99正常
正常正常
正常正常
正常同時登陸使用者數
伺服器狀態6正常
10偶爾出現連不上教務
15穩定出現一兩個連不上教務
此處出現的連不上教務的情況，我們判斷可能是伺服器的出口頻寬已經到達限制，也有可能是給了教務伺服器過大的壓力，但考慮到總使用者數只有百人級別，所以並沒有很大的影響。這部分登入失敗的同學會收到正常的錯誤提示，只需錯開登入高峰期，即可成功登陸。
你的軟體beta版本的出口條件（exit criteria）是什麼？也即在什麼條件下，認定你的軟體已經足夠好，可以發布beta版本？
軟工頂級理解組 Beta階段事後分析
目錄和上乙個階段相比，團隊軟體工程的質量提高了麼？在什麼地方有提高，具體提高了多少，如何衡量的？使用者量，使用者對重要功能的接受程度和我們事先的預想一致麼？我們離目標更近了麼？有什麼經驗教訓？如果歷史重來一遍，我們會做什麼改進？團隊在計畫階段是如何解決同事們對於計畫的不同意見的？你原計畫的工作是否最...
軟工頂級理解組 Alpha階段團隊貢獻分評分
下述 適用於前端 後端 爬蟲開發者的評分，基礎分數為50分，在此基礎上進行增減。類別程度 加減分準時性 提前完成 0 按時完成 0延後完成，遲交時間一天內或未延誤進度 2延後完成，遲交時間一天以上或延誤進度 4質量 質量較高，可讀性好，可擴充套件性好 2質量過關或者bug極其微小 0質量較差，有非架...
軟工頂級理解組 無人轉會申請
我們是軟工頂級理解團隊，經過長達乙個月的alpha階段緊張刺激的開發，我們希望能夠提交無人轉會申請，其理由如下 下面我們將詳細闡述我們的申請條件。人員崗位 職責喬璽華 單彥博 張藝璇 前端進行android軟體介面開發 胡彬彬 李嘉鋮 後端進行伺服器互動邏輯 編寫 杜博瑋爬蟲 負責從教務獲取學生資料...