測試流程

1.測試流程

　　

1、測試需求分析階段：閱讀需求，理解需求，主要就是對業務的學習，分析需求點，參與需求評審會議。

2、測試計划階段：主要任務就是編寫測試計划，參考軟件需求規格說明書，項目總體計划，內容包括測試范圍（來自需求文檔），進度安排，人力物力的分配，整體測試策略的制定。風險評估與規避措施有一個制定。

3、測試設計階段：主要是編寫測試用例，會參考需求文檔（原型圖），概要設計，詳細設計等文檔，用例編寫完成之后會進行評審。

4、測試執行階段：搭建環境，執行冒煙測試（預測試）-然后進入正式測試，bug管理直到測試結束。

5、測試評估階段：出測試報告，確認是否可以上線。

 

 

2.測試過程中遇到了不能復現的bug的時候怎么辦？

1、遇到問題就要提，測試的工作就是不放過任何一個bug，在提交的Bug描述中需要加上一句話，那就是復現概率，嘗試20次，出現1次或者嘗試10次，出現2次，開發會根據bug的復現概率，調整改bug的優先級。

2、盡量回想發生問題時的復現步驟，不要漏掉任何一個細節，按照步驟的組合嘗試復現。

3、保留發生bug時的log，附加到提交的bug中，希望可以通過log中找到一些蛛絲馬跡。

4、與開發人員配合，讓開發同學對相應地方的代碼進行檢查，看一下是否可以通過代碼層面檢查出問題。

5、在接下來的測試中，時刻保持關注，每次執行同樣或者相近的步驟的時候，看下是否能夠復現之前的bug。

通過以上的方法，仍然無法復現，根據bug的優先級，在上線之前對該bug進行處理，嚴重級別的bug，要召集項目組的成員，集合大家的力量盡可能的復現bug，不嚴重的bug，也不要關掉，上線后及時的關注用戶的使用反饋，如果持續3或者4個版本沒有出現，那么可以將bug暫時關掉了，同時關掉的時候要進行評論說明並不是因為修復，而是經過x個版本后不復現了。

 

3.測試過程中遇到開發不認為是bug的bug時怎么辦？

• 1.通過不同方式或者是不同的測試環境來對bug進行確認
• 2.根據需求文檔對bug來進行判斷
• 3.將bug的出現的頻率，已經出現的方式和對應的操作步驟進行書寫，將結果 截圖或者是錄屏
• 4.找對應的項目經理或者是客戶經理來bug進行評審 5.將bug進行記錄到測試總結中

 

4.經典用例設計

　　1：紙杯

　　　　

結構：用料是否環保?是否能平穩放在桌面上?放了水是否能平穩放在說面上?杯口是否光滑?。。。。。

 

　　功能：到進水是否不漏，是否不變形?拿起來是否能夠不顯著變形?水是不是能倒出來?

 

　　數據：放半杯水，放一整杯水，放冷水，放熱水，放茶葉，放可樂

 

　　平台：能否放在桌子上不倒?手拿着是否不變形，不會感到不舒服?是否能放到杯架、套到別的杯子上?

 

　　操作：倒進水，喝水，再倒水，倒開水，捏變形，彈煙灰，丟棄

 

　　時間：看喝水的時候水是不是很快的能流出來

 

　　2：購物車

　　　　

　　　　1.界面測試

       　　　　界面布局、排版是否合理；文字是否顯示清晰；不同賣家的商品是否區分明顯。

　　　　2.功能測試

        　　　未登錄時：

• • • 將商品加入購物車，頁面跳轉到登錄頁面，登錄成功后購物車數量增加；
    • 點擊購物車菜單，頁面跳轉到登錄頁面。

       　　　　登錄后：

• • • 所有鏈接是否跳轉正確；
    • 商品是否可以成功加入購物車；
    • 購物車商品總數是否有限制；
    • 商品總數是否正確；
    • 全選功能是否好用；
    • 刪除功能是否好用；
    • 填寫委托單功能是否好用；
    • 委托單中填寫的價格是否正確顯示；
    • 價格總計是否正確；
    • 商品文字太長時是否顯示完整；
    • 店鋪名字太長時是否顯示完整；
    • 創新券商品是否打標；
    • 購物車中下架的商品是否有特殊標識；
    • 新加入購物車商品排序（添加購物車中存在店鋪的商品和購物車中不存在店鋪的商品）；
    • 是否支持TAB、ENTER等快捷鍵；
    • 商品刪除后商品總數是否減少；
    • 購物車結算功能是否好用。

　　　　3.兼容性測試

        　　　　不同瀏覽器測試。

　　　　4.易用性測試

        　　　　刪除功能是否有提示；是否有回到頂部的功能；商品過多時結算按鈕是否可以浮動顯示。

　　　　5.性能測試

       　　　　壓力測試；並發測試。

 

　　3.電梯

　　　　功能測試—單個功能：
　　　　　　1、電梯內分樓層鍵是否正常
　　　　　　2、電梯內開關門鍵是否正常
　　　　　　3、電梯內的報警鍵是否正常使用
　　　　　　4、電梯外的上下鍵是否正常
　　　　　　5、同時關注顯示屏，電梯內外的顯示屏顯示的電梯層數、運行方向是否正常
　　　　　　6、有障礙物時，電梯門的感應系統是否有效
　　　　功能測試—邏輯業務/功能交互
　　　　　　1、功能與功能模塊間的集成，可根據電梯當前狀態是上行、下行還是停止來設計測試點，以保證覆蓋率
　　　　　　電梯當前狀態是上行時，有人在X樓按下上升/下降鍵，電梯是否會停止
　　　　　　電梯當前狀態是下行時，有人在X樓按下上升/下降鍵，電梯是否會停止
　　　　　　在搭載滿員的情況下，如有人在X樓按下上升/下降鍵，電梯是否會停止
　　　2、功能設備與設備間的集成，關注功能接口，比如：
　　　　電梯和大樓層，電梯和攝像頭，電梯與空調，電梯和對講機（報警裝置），電梯與顯示屏，電梯與其他電梯的協作能力

　　　　例如：一棟樓有2部電梯，一部停在2樓，一部停在4樓，有人1樓按電梯，是否2樓的電梯下降到1樓開
　　　界面測試
　　　　1、查看電梯的外觀，按鈕的圖標顯示，電梯內部張貼的說明（比如報警裝置的說明、稱重量等）
　　易用性測試
　　　　1、樓層按鍵高度（小孩和一些身高矮的用戶會按鍵不方便）
　　　　2、電梯是否有地毯、夏天是否有空調、通風條件、照明條件、手機信號是否通暢
　　　　3、電梯是否有扶手，是否有專針對殘疾人的扶手等等
　　兼容性測試
　　　　1、電梯的整體和其他設備的兼容性，與大樓的兼容，與海地隧道的兼容等等
　　　　2、不同類型的電壓是否兼容
　　安全性測試
　　　　1、下墜時是否有制動裝置
　　　　2、暴力破壞電梯時是否報警，超重是否報警
　　　　3、停電情況下電梯是否有應急電源裝置
　　性能測試
　　　　1、測試電梯負載單人時的運行情況（基准測試）
　　　　2、多人時的運行情況（負載測試）
　　　　3、一定人數下較長時間的運作（穩定性測試）
　　　　4、更長時間運作時的運行情況（疲勞測試）
　　　　5、不斷增加人數導致電梯報警（拐點壓力測試）

 

　　4.登錄框測試

功能測試

 

什么都不輸入，直接點擊提交按鈕，看提示信息
輸入正確的用戶名和密碼，點擊提交按鈕，看是否能登錄成功
輸入錯誤的用戶名或者錯誤的密碼，點擊提交按鈕，看提示信息
登陸成功之后能否正確的跳轉到正確的頁面
用戶名太短或者太長時，應該怎么處理
密碼太短或者太長時，應該怎么處理
用戶名若含有特殊字符，字母，數字等不同於漢字的，應該怎么處理
密碼若含有特殊字符，字母，數字，或者混合類型時，密碼強度的變化
用戶名和密碼中間出現空格時，會怎么處理
用戶名和密碼前后出現空格時，會怎么處理
記住用戶名或者記住用戶名和密碼的功能（比如剛剛登陸成功之后退出，再次登陸時是否有記錄 ）
驗證首次打開登錄界面，鼠標的輸入焦點是否在用戶名的輸入框以方便用戶直接輸入
密碼的加密顯示（如星號或者小黑點）
牽扯到驗證碼的登錄時，要考慮圖片上的數字是否扭曲過大導致看不清楚，數字的顏色（考慮色盲患者），驗證碼的刷新按鈕是否有效
登錄界面上的注冊，忘記密碼，退出登錄點擊后，鏈接是否有效
輸入密碼時，切換為大寫時是否有提醒

 

界面測試

 

布局是否合理，兩個文本框的位置是否對齊，按鈕的位置是否合理
文本框的長度寬度是否合理，按鈕的大小是否易於點擊
界面是否簡介易懂，是否有錯別字

性能測試

 

打開該登錄頁面需要多久
登錄成功跳轉到正確的界面時需要多久

安全測試

 

用戶名和密碼是否通過加密的方式發給web服務器
用戶名和密碼是否是在服務端完成驗證的，不能只在客戶端調用JavaScript來進行驗證
兩個文本框應禁止輸入腳本語言，防止XSS攻擊
限制錯誤登錄的次數，防止暴力破解
考慮多用戶在一台機器上登錄
考慮一用戶在多台機器上登錄

 

可用性測試

 

輸入用戶名和密碼時常用快捷鍵在輸入文本框中能否使用（ctrl+c，ctrl+v，ctrl+a等）
輸入正確的用戶名和文本框之后按回車是否可以登錄
輸入用戶名之后按Tab鍵是否可以轉到密碼輸入框

兼容性測試

 

在主流的瀏覽器上是否可以正常使用（如IE，谷歌等）
在不同的平台上是否可以正常使用
在移動設備上是否可以正常使用（iPhone，Android）

 

　　5.視頻播放測試點

 

功能測試

 

什么都不輸入，直接點擊提交按鈕，看提示信息
輸入正確的用戶名和密碼，點擊提交按鈕，看是否能登錄成功
輸入錯誤的用戶名或者錯誤的密碼，點擊提交按鈕，看提示信息
登陸成功之后能否正確的跳轉到正確的頁面
用戶名太短或者太長時，應該怎么處理
密碼太短或者太長時，應該怎么處理
用戶名若含有特殊字符，字母，數字等不同於漢字的，應該怎么處理
密碼若含有特殊字符，字母，數字，或者混合類型時，密碼強度的變化
用戶名和密碼中間出現空格時，會怎么處理
用戶名和密碼前后出現空格時，會怎么處理
記住用戶名或者記住用戶名和密碼的功能（比如剛剛登陸成功之后退出，再次登陸時是否有記錄 ）
驗證首次打開登錄界面，鼠標的輸入焦點是否在用戶名的輸入框以方便用戶直接輸入
密碼的加密顯示（如星號或者小黑點）
牽扯到驗證碼的登錄時，要考慮圖片上的數字是否扭曲過大導致看不清楚，數字的顏色（考慮色盲患者），驗證碼的刷新按鈕是否有效
登錄界面上的注冊，忘記密碼，退出登錄點擊后，鏈接是否有效
輸入密碼時，切換為大寫時是否有提醒

 

界面測試

 

布局是否合理，兩個文本框的位置是否對齊，按鈕的位置是否合理
文本框的長度寬度是否合理，按鈕的大小是否易於點擊
界面是否簡介易懂，是否有錯別字

 

性能測試

 

打開該登錄頁面需要多久
登錄成功跳轉到正確的界面時需要多久
安全測試
用戶名和密碼是否通過加密的方式發給web服務器
用戶名和密碼是否是在服務端完成驗證的，不能只在客戶端調用JavaScript來進行驗證
兩個文本框應禁止輸入腳本語言，防止XSS攻擊
限制錯誤登錄的次數，防止暴力破解
考慮多用戶在一台機器上登錄
考慮一用戶在多台機器上登錄

 

可用性測試

 

輸入用戶名和密碼時常用快捷鍵在輸入文本框中能否使用（ctrl+c，ctrl+v，ctrl+a等）
輸入正確的用戶名和文本框之后按回車是否可以登錄
輸入用戶名之后按Tab鍵是否可以轉到密碼輸入框

 

兼容性測試

 

在主流的瀏覽器上是否可以正常使用（如IE，谷歌等）
在不同的平台上是否可以正常使用
在移動設備上是否可以正常使用（iPhone，Android）

 

 

本地化測試

 

不同語言環境下能否正常運行

 

　　6.三角形的測試點

一、等價類划分：三角形三條邊A、B、C的數據類型不同
二、邊界值分析：由於三角形的邊長可以是正整數或正小數，所以就不對長度進行測試，那么邊界值分析就不用了
三、因果圖法：三角形的三條邊數據輸入組合
我們看一下三角形的流程圖：

我們再分析一下三角形的等價類：
有效等價類：
輸入3個正整數或正小數：
1、兩數之和大於第三數，如A<B+C；B<C+A；C<A+B
2、兩數之和不大於第三數
3、兩數相等，如A=B或B=C或C=A
4、三數相等，如A=B=C
5、三數不相等，如A！=B，B！=C，C！=A
無效等價類：
1、空
2、負整數
3、非數字
4、少於三個數
三角形測試用例類別
輸入條件 有效等價類 無效等價類
是否是三角形
(A>0) (1)
(B>0) (2)
(C>0) (3)
(A+B>C) (4)
(B+C>A) (5)
(C+A>B) (6) (A<=0) (7)
(B<=0) (8)
(C<=0) (9)
(A+B<=C) (10)
(B+C<=A) (11)
(C+A<=B) (12)
是否是等腰三角形
(A=B) (13)
(B=C) (14)
(C=A) (15) (A!=B)and(B!=C)and(C!=A) (16)
是否是等腰直角三角形 :
(A=B)and(A^2+B^2=C^2) (17)
(B=C)and(B^2+C^2=A^2) (18)
(C=A)and(C^2+A^2=B^2) (19)
是否是等邊三角形 :
(A=B)and(B=C)and(C=A) (20)
(A!=B) (21)
(B!=C) (22)
(C!=A) (23)
三角形測試用例：
序號 [A,B,C] 覆蓋等價類 輸出
1 [3,4,5] (1)(2)(3)(4)(5)(6) 是三角形
2 [0,1,2] (7) 非三角形
3 [1,0,2] (8) 非三角形
4 [1,2,0] (9) 非三角形
5 [1,2,3] (10) 非三角形
6 [1,3,2] (11) 非三角形
7 [3,1,2] (12) 非三角形
8 [3,3,4] (1)(2)(3)(4)(5)(6)(13) 等腰三角形
9 [3,4,4] (1)(2)(3)(4)(5)(6)(14) 等腰三角形
10 [3,4,3] (1)(2)(3)(4)(5)(6)(15) 等腰三角形
11 [2√2,2√2,4] (1)(2)(3)(4)(5)(6)(17) 等腰直角三角形
12 [4,2√2,2√2] (1)(2)(3)(4)(5)(6)(18) 等腰直角三角形
13 [2√2,4,2√2] (1)(2)(3)(4)(5)(6)(19) 等腰直角三角形
14 [3,4,5] (1)(2)(3)(4)(5)(6)(16)(20)(22)(23)(24) 是三角形
15 [3,3,3] (1)(2)(3)(4)(5)(6)(16)(21) 等邊三角形
16 [,,,] 無效等價類 錯誤提示
17 [-3,4,5] 無效等價類 錯誤提示
18 [a,3,@] 無效等價類 錯誤提示
19 [3,4] 無效等價類 錯誤提示

 

　　6.朋友圈點贊的測試點

功能測試

1.給某個好友點贊，點贊數+1，點贊欄顯示具體點贊人的名字 ，該用戶手動點贊回饋
2.點完贊后，共同好友在點贊區能看到該人是不是點贊
了，非共同好友看不到
3.兩個頭像一樣的人點贊，能否正確顯示
4.點完贊后，在點擊點變成點贊取消
5.取消點贊--不通知用戶
6.點贊后，通知用戶，取消，在點贊，此時不通知用戶
7.多個用戶同時對其點贊，點贊數正常
8.最多能點多少個贊--邊界值測試
9.可以從點擊點贊區頭像，進入相應人的主頁查看
10.點贊是否按照時間順序排序
11.點贊后是否能夠正常評論

app端測試

1.弱網情況下，點贊能否實時更新
2.點贊時，有短信或者電話進來，能否顯示點贊情況
3.耗電量，耗流量關注

性能測試

1大量用戶並發點贊時，該接口的響應時間，最大承受的qps
2.大量用戶並發點贊時，此時界面進行點贊，點贊功能是否正常

兼容性測試

1.不同手機型號，點贊功能，顯示功能是否正常

 

　　7.微信發紅包測試

1、功能測試

1）發給單個好友
①　正確的金額+無留言+無表情
②　錯誤的金額+無留言+無表情
③　正確的金額+有留言+無表情
④　錯誤的金額+有留言+無表情
⑤　正確的金額+無留言+有表情
⑥　錯誤的金額+無留言+有表情
⑦　正確的金額+有留言+有表情
⑧　錯誤的金額+有留言+有表情
其中，金額（0.01-200）可以測試以下數據

數字：測試0, 0.009, 0.01，0.011, 01， 199.99, 200, 200.01這些邊界值
中文、英文、特殊字符或者這幾種的組合
是否支持復制黏貼
為空/包含空格
金額的增刪查改
留言可以測試以下數據

數字、中文、英文、特殊字符、表情或者他們的組合
輸入超長文本時，是否會給出相應的限制或提示
包含空格
是否支持復制黏貼
留言的增刪查改
表情可以測試以下數據

選擇收藏的表情測試（動圖/靜圖）
選擇下載的表情測試（動圖/靜圖）
錄制表情，並添加進行測試
表情的增刪查改
⑨　點擊塞錢進紅包，選擇零錢付款，此時需要考慮金額＞零錢，金額＜零錢，金額=零錢三種情況
⑩　點擊塞錢進紅包，選擇已添加的銀行卡付款，此時同樣需要考慮金額＞銀行卡余額，金額＜銀行卡余額，金額=銀行卡余額三種情況
⑪　點擊塞錢進紅包，選擇使用新卡付款，按照流程添加新卡，此時同樣需要考慮金額＞新卡余額，金額＜新卡余額，金額=新卡余額三種情況
⑫　使用指紋確認付款（正確的/不正確的指紋）
⑬　使用密碼確認付款（正確的/不正確的密碼 ）
⑭　發送成功之后，對應的途徑會減少相應的金額
⑮　發送者/接受者可以點擊紅包查看到紅包的具體信息，且金額，留言，表情均能正確顯示
⑯　好友點擊紅包之后，零錢中將增加相應的金額，再次點擊之后，只能查看到紅包的信息
⑰　24小時之內沒有領取的紅包，將退回原賬戶，此時原賬戶的零錢將增加相應金額的金錢。24小時后好友點擊紅包，顯示紅包已過期，無法查看到紅包的余額
⑱　右上角的紅包記錄中，可以查看剛剛發出的紅包的金額
⑲　檢測幫助中心中鏈接是否均可以正常跳轉，查看
20 當紅包超過24小時之后，則無法查看紅包被每個人領取的詳細信息

2）發送群紅包（與發給好友的測試點相似，以下僅寫出不同的部分）
①　選擇為拼手氣紅包時，群中每個人收到的金額隨機（但加起來為紅包的總金額），為普通紅包時，群中每個人收到的金額相同
②　紅包個數（1-100）：0，1，2，大於群成員人數，小於群成員人數，等於群成員人數，99，100，101，小數，中文、英文、特殊字符、表情或者他們的組合
③　但紅包沒有被搶完時，此時首次點擊該紅包的人可以搶到一定金額的紅包，不是首次點擊該紅包的人只能查看該紅包的信息；當紅包搶完時，所有人只能查看該紅包的信息。
④　在24小時之內紅包的金額被完全搶完，且此時為拼手氣紅包時，金額最多的人會顯示為最佳手氣（若有兩個人取得紅包的最大值時，則只有一個人會顯示為最佳手氣）；若沒有被完全搶完，則沒有最佳手氣，且余額會退還到原賬戶
⑤　群中所有人均可以搶紅包（包括自己），每個人最多只有一次搶該紅包的機會
⑥　測試當紅包個數使得每個紅包分到錢小於0.01，即總金額為0.02，而紅包個數為3時的情況

 

2、兼容性測試

 

1）蘋果手機和安卓手機
2）蘋果手機的不同版本
3）安卓手機不同的機型
4）不同分辨率

 

3、性能測試

 

1）打開紅包的響應時間不能超過三秒，高並發場景下不能超過5秒
2）耗電量
3）消耗流量的多少
4）所占內存
等

4、UI測試&易用性測試

 

1）界面的設計風格是否統一
2）界面中文字是否簡潔，沒有錯別字
3）是否易操作，易學習，易理解

5、中斷測試：前后台切換，網絡異常，低電量，斷電，來電，短信等
6、網絡測試

1）網絡兼容性：2g/3g/4g，WiFi，熱點，移動/聯通/電信
2）無網測試
3）弱網：延時&丟包

 

 

　　8.token cookie session 三者的區別？

cookies

用戶登錄以后，在瀏覽器端生成一個文件，保存在瀏覽器的客戶端
一般存儲用戶的身份信息
可以刪除，刪除后重新登錄可以再次生成
使用不同的瀏覽器，電腦登錄同一網站，會產生不同的cookies
有的系統會通過cookies存儲用戶行為習慣
session

登錄后服務器端發送一個隨機的ID值，來進行用戶身份的識別
session的有效性，是在代碼中進行設計的，一般是30分鍾
session只針對一個應用服務器有效
token

登錄后，服務器端發送一個token令牌
token也有時效性
token可以支持多平台訪問

 

　　9.性能測試的指標有哪些？

　　RT：響應時間
TPS：每秒完成事務數
CPU性能指標：利用率、負載
Mem：內存性能指標，可用物理內存、虛擬內存使用率
Disk：磁盤性能指標，Disk Time、IO等待
NetWork：網絡指標，帶寬使用率、任務隊列長度
TCP連接數，可以用netstat命令統計得到
中間件建立的線程池，監控線程狀態
JVM性能指標，GC情況、Heap使用情況
CPU負載隊列長度
服務器與中間件之間建立的連接數及連接狀態
一般性能分析的過程
序號 步驟名稱 說明
1 檢查RT 客戶端響應時間
2 檢查TPS TPS大時RT小， 說明性能良好
3 檢查負載機資源消耗 檢查CPU使用率
4 檢查被壓服務器的資源消耗 CPU 、 內存、磁盤IO、帶寬、響應時間
5 檢查中間件配置 確定是否有配置參數問題
6 數據庫服務器 CPU、內存、IO繁忙程度、數據庫監控。