記測試流程

DrewBetter發表於2019-07-24

測試流程

 

主要流程概述

說明：專案整體owner作為專案經理

          QA這邊的owner建議由改動比較大的或者提出需求方作為owner

 

1、需求評審

  •     產品對專案內容進行講解，並說明prd中的內容；
  •     測試人員主要是對需求的理解提出疑問，以便才能根據需求寫用例；
  •     開發人員根據需求功能點進行排期，然後將開計劃轉交給測試人員；
  •     測試負責人根據測試用例數目以及功能點評估測試時間；
  •     專案的開發與測試計劃及時釘釘給相關人員。

2、編寫測試用例

  •    閱讀專案prd，與鑽展測試負責人即本次專案的owner明確專案的需求和主要功能點；
  •    編寫測試用例。

3、測試用例評審

            重點大專案： 建議可以先在小組內進行評審

  •  對於XX專案的重點功能進行修改時進行；
  •   在測試用例完成後，上傳Bug管理平臺
  • 以郵件形式將用例傳送給組內人員，以便他們事先了解用例對哪些功能進行驗證以及驗證的細節；
  •  對用例進行評審，補充遺漏的測試功能點。

4、提測

  •  開發對測試相關人員在管理平臺上備註
  •  測試人員需要明確開發完成的內容，如果與prd不符，需要及時與產品溝通確認；
  •  與開發明確專案是否影響其他功能，如果有需要進行相應的迴歸測試；
  •  部署測試環境，準備開始測試

5、測試

  •   根據測試用例進行測試；
  •   發現問題後，記錄到Bug 平臺，並設定提醒進行高效跟進
  •   BUG修改後，進行驗證；
  •   對於前端專案，線下測試完成後，需要部署預發環境進行測試，需要修改domain的配置

 

6、測試日報&報告

         重點專案需要測試日報體現，日常專案釘釘同步進度

  •  冒煙測試打回：在平臺上記上
  • 測試日報郵件內容：

a)    題目：【測試進度】-【XX】- 日期；

b)   測試進度；

c)    測試內容；

d)    存在的BUG；

e)    需要明確的問題。

7、線上回測

  •  專案上線後，一定要第一時間回測；
  •  介面層上線，觀察是否有errorlog

8、專案資料積累

  •  專案測試完，資料的積累
​
​

測試日報模板

Hi all:

【專案名稱】- 2019.04.09-測試日報-XX

 

一、測試進度：

     測試排期：xx側：2019-3-4~2019-3-12（第一輪測試進度90%，見具體）；

                     引擎側：2019-3-5~2019-3-8（測試進度：50%）；

                     演算法側：已開完完成，等待聯調

      重點關注：暫無（如果有，要描述關注啥，誰關注）

     

     BP側第一輪測試進度：90 %，case執行如下：

​
 
 

測試輪次

待執行case

阻塞case

已執行case

第一輪(100)

40

10

50

第二輪

 

 

 
 
 
 
​

case的統計，目前需要將case匯入aone中，統計成本需要考慮

 

 

二、專案bug以及風險

 

風險：1、專案週期長，主要耗時在，定向中心-bug修復；

          2、定向中心-reopen-bug較多，bug修復後引發更嚴重的bug。

               以上兩個原因導致專案上線時間有風險。

 

bug列表：xxxxxxxx  ​@​XX，請關注

​
 
 

Active

Resolved

Closed

Total

1（P1）

 0

17（3P2+14P）

 18
 
 
 
​

 

三、測試內容：

 

  1. 新增定向功能：DB資料check、演算法資料產出、引擎召回  100%
  2. 新增過濾功能：DB資料check、演算法資料產出、引擎召回    80%
  3. 聯調測試：  10%

 

四：測試環境

    140.205.173.181 i.cnblogs.com.com

    indexbp1：daily/0.0.316；indexbp2：daily/0.0.22

​
​

 

​
​

測試報告

【定向二期】本次提測已經完成100%

 

 

一、測試結果：測試通過


       遺留問題：暫無，如果有，描述問題+解決時間+跟進人

 

二、提測質量：

提測質量： 提測次數2次；

測試質量： bug總數:1個，其中P1級1個，P2級0個，P3級0個。

 

三、測試環境：

    140.205.173.181 i.cnblogs.com.com

    indexbp1：daily/0.0.316；indexbp2：daily/0.0.22

 

四：程式碼分支

    cnblogs：26bd7fdc151ce688fc7444e3e1013a3f50dd69fd

 

五：測試時間

 

測試開始時間2019-3-4   測試結束時間：2019-3-12

測試所用時間：5天

非測試消耗時間：2天（等待bug修復）
測試執行輪次：2輪

 

五：測試內容

​
 
 

檢查項

子項

指標

測試內容

測試結果

備註

基礎功能

新功能

case通過率100%
  1. 新增定向功能：DB資料check、演算法資料產出、引擎召回 
  2. 新增過濾功能：DB資料check、演算法資料產出、引擎召回   
  3. 演算法&引擎均聯調通過

pass

  

影響功能

case通過率100%

核心功能

case通過率100%

全功能

case通過率100%

聯調功能

     case通過率100%

相容性

介面相容

介面無bug，頁面互動正常

無

不涉及

 

web相容

互動正常，樣式美觀，無bug

第三方依賴

呼叫第三方服務返回錯誤（資料，順序）

服務可用，有降級或重試方案，提示友好

無

不涉及

  

呼叫第三方服務超時

服務可用，有降級或重試方案，提示友好

呼叫第三方服務不可用

服務有損可用，有容災或降級方案，提示友好

網路異常

服務有損可用，有容災或降級方案，提示友好

上線步驟

上線和回滾方案

上線和回滾過程無損，使用者感知小

正常上線。

pass

  

基礎效能

吞吐量

不低於穩定環境效能

無

不涉及

  

響應時間

不低於穩定環境效能

錯誤率

不低於穩定環境效能
 
 

 

 PS 設計測試用例：

http://www.testclass.net/post/about_interview
 
 
重點：

有的候選人是這麼回答的。

假如是一袋鹽，那麼要看看裝鹽的袋子是不是會漏？

這時候我一般會反問，那應該是要漏還是不要漏？很多候選人這時候會愣住，可能完全意識不到我為什麼會這麼問。

我這麼問是因為我有個怪癖，那就是我希望測試用例都是可以執行的。可以執行的意思是，你要告訴我你究竟是希望袋子漏還是不漏。如果你希望袋子是不漏的，那麼袋子漏的時候測試用例就是不通過的，反之也成立。如果你告訴我看看袋子漏不漏，那麼因為我是很笨的，我不知道如何去執行這個用例，因為我不知道袋子究竟是需要漏呢還是不能漏。

與之類似的，在測試衣服的時候，有的候選人會回答要看衣服的尺碼是不是合適。那麼我會反問，對於L號，衣服多長是合適，多長又是不合適呢？這是因為合適不合適是沒有執行標準的，對於一個身高不高的人——比如1米49家窮人醜的我——來說，L號是不合適的，太長了。而對於身材勻稱的其他人來說，L應該是合適的。所以合不合適沒法量化，加上又有模稜兩可的是不是這樣的詞語推波助瀾，這種用例執行起來是相當困難的。

所以寫用例，要想可執行，首先的第一條原則是，不要包含一些似是而非的詞語，比如是不是，要不要，有沒有之類的。換句話說，就是用例裡大概率要麼包含是，要麼包含不是這樣的詞。

比如

  • 裝鹽的袋子不能（不是）漏

  • 衣服的顏色是紅的

  • 衣服的材料是80%的棉，20%的滌綸

像這樣的是或者不是的句型，我們可以稱之為斷言。

上面是最基本的用例設計，主要考察的是思維的全面程度，以及設計用例的最基本要求——可以執行，沒有歧義。另外我還喜歡根據候選人的經歷去問一些稍微有技術深度的問題。

​

 

相關文章