《3+1團隊》【Beta】Scrum meeting 3

項目	內容
這個作業屬於哪個課程	任課教師博客主頁鏈接
這個作業的要求在哪裏	作業鏈接地址
團隊名稱	3+1團隊
團隊博客地址	https://home.cnblogs.com/u/3-1group
項目名稱	一起種水果

團隊項目github倉庫地址鏈接

https://github.com/HaiYou667/3-1Growingfruits

1.各個成員今日完成的任務

團隊成員	分工
王雯涵	訂單模塊進行測試
郭佳	對訂單模塊進行測試
麻存滔	對購物車模塊進行測試
鄒立源	對購物車模塊進行測試

2.各個成員今日對項目的貢獻小時數

王雯涵	郭佳	麻存滔	鄒立源
3h	3h	3h	3h

3.提供當天站立式會議照片一張，提供更新的項目燃盡圖一份

4.總結

  團隊項目經過Alpha階段衝刺後，已基本完成項目編碼工作。進入Beta階段衝刺後，需要開發者從用戶使用體驗或典型用戶應用場景測試並完善系統功能，此時，常用黑盒測試技術完成測試工作。
  黑盒測試也稱功能測試，它是通過測試來檢測每個功能是否都能正常使用。在測試中，把程序看作一個不能打開的黑盒子，在完全不考慮程序內部結構和內部特性的情況下，在程序接口進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產生正確的輸出信息。黑盒測試着眼於程序外部結構，不考慮內部邏輯結構，主要針對軟件界面和軟件功能進行測試。
  黑盒測試是以用戶的角度，從輸入數據與輸出數據的對應關係出發進行測試的。很明顯，如果外部特性本身設計有問題或規格說明的規定有誤，用黑盒測試方法是發現不了的。
  墨盒測試法注重於測試軟件的功能需求，主要試圖發現下列幾類錯誤。

●功能不正確或遺漏;

●界面錯誤;

●輸入和輸出錯誤;

●數據庫訪問錯誤;

●性能錯誤;

●初始化和終止錯誤等。

5.測試結果

（1）Beta測試發現的錯誤

在Beta測試階段，我們發現了數據庫訪問錯誤、界面錯誤的bug。
例如，數據庫訪問錯誤，前臺頁面中，我們刪除了購物車中的商品，但是在數據庫中該商品還是存在的。
在檢查了所有的SQL語句還有代碼之後，我們還是沒能改正這個錯誤。
界面錯誤是由於每臺電腦的屏幕分辨率不同，當我們把頁面設置成固定的像素和屏幕分解時設置成百分制，這一錯誤就解決了。

（2）如何進行用戶場景測試（scenario testing）的？
  場景法是很常用的一種測試方法，是一種基於用戶行爲的測試方法，可以簡單理解爲：對於某個功能點用戶可能執行的操作有哪些，測試就需要驗證哪些，如果用戶不可能有某個操作行爲自然也不屬於測試範圍。
  我們常見的用戶行爲包括以下4個部分
　　●用戶將使用進行正常操作
　　●用戶使用該功能進行非法操作
　　●用戶不僅關心功能的正確實現，還關心用戶體驗。
　　●某些特殊情況下的用戶行爲，如環境異常，用戶併發等。
  場景法基於兩個方面：
（1）業務層面（業務的理解更爲重要）：測試人員要熟悉所測軟件的業務邏輯，成爲該行業的“業務專家”
（2）技術層面
●基本流（有效流、正確流）：模擬用戶正確的業務操作流程就是基本流
●備選流（無效流、錯誤流）：模擬用戶錯誤的操作流程就是備選流

項目中的用戶場景測試如下：
步驟一：分析需求，整理業務邏輯，列出基本流和備選流
●基本流：購物車清空過程
●備選流：在清空過程中可能會出現的各種錯誤情形
列出基本流和備選流：
●列出基本流（正確清空購物車過程）：
輸入用戶名——輸入密碼——點擊“購物車按鈕”——點擊“全選”按鈕——刪除成功
●列出備選流：
用戶驗證失敗，無法登錄。
購物車爲空
購物車無法清空

步驟二：根據基本流和備選流生成場景（填寫《場景表》）

場景編號	參加描述
場景1	用戶登錄後刪除成功
場景2	用戶驗證失敗，無法登陸
場景3	用戶登錄後購物車爲空，顯示刪除成功
場景4	用戶登錄後，點擊“”全選“”按鈕購物車無法清空

步驟三：根據場景設置測試用例

場景編號	測試用例
場景1	用戶名：郭佳，密碼：123456
場景2	用戶名：王雯涵，密碼：123456
場景3	用戶名：郭佳，密碼：123456
場景4	用戶名：郭佳，密碼：123456

以場景1爲例：測試流程如下：

測試成功！！

（3）是否有迴歸測試？請給出一到兩個測試用例並解釋。
迴歸測試是指修改了舊代碼後，重新進行測試以確認修改沒有引入新的錯誤或導致其他代碼產生錯誤。
●迴歸測試是指重複以前的全部或部分的相同測試。
●新加入測試的模組，可能對其他模組產生副作用，故須進行某些程度的迴歸測試。
●迴歸測試的重心，以關鍵性模組爲核心。

在項目的每個錯誤產生之後我們都進行了迴歸測試，以用戶模塊爲例：