一：測試流程

• 整體流程圖：

需求提取 -> 需求分析 -> 需求評審 -> 更新后的測試需求跟蹤xmind

• 分析流程：

1. 需求提取：

• 分析依據(jù)（包括：需求矩陣、產(chǎn)品交互圖、需求說明書）
• 獲取需求的緯度
• 客戶價值
• 可以為客戶帶來哪些價值？
• 可以解決哪些問題？
• 根據(jù)以上問題定位功能是否合理
•  UI功能 - 展示功能
• 模塊關(guān)聯(lián)-歷史模塊
• 新功能模塊關(guān)聯(lián)
• 考慮是否關(guān)聯(lián)？耦合部分是否需要支持？
• 客戶使用場景-部署方式
• 網(wǎng)絡(luò)特性
• 客戶使用服務(wù)器常見外設(shè)
• 性能參數(shù)-性能要求
• 網(wǎng)卡最低速率
• 硬件支持
• 輸出（提取最原始的測試需求）

2. 需求分析：

• 分析依據(jù)（五維分析）
• 用戶場景

1. 功能是否和場景強關(guān)聯(lián)
2. 網(wǎng)絡(luò)拓?fù)淠芊駶M足客戶需求
3. 和競爭對手比較差異
4. 功能是否能滿足客戶實際應(yīng)用場景
5. 是否考慮了用戶的實際操作

• 明確性

1. 范圍明確性（參數(shù)、類型長度范圍）
2. 清晰性限制等范疇
3. 無法預(yù)知影響的需求提出進行確定，風(fēng)險

• 二義性

1. 概念模糊【大概念、第三方支持、與上個版本相同】
2. 支持與不支持等范疇
3. 一個需求描述能出現(xiàn)多種理解

• 完整性

1. 需求一致性【用戶需求、需求規(guī)格、需求矩陣三者是否同意】
2. 需求完整【隱形需求】
3. 關(guān)聯(lián)性【與新老功能、與外置軟件設(shè)備】

• 可測試性

1. 實現(xiàn)測試需要的工具、方法【調(diào)試、接口命令】
2. 定位方式【日志等形式觀察】
3. 復(fù)雜環(huán)境、容量邊界、操作時過程不可見

• 輸出

1. 測試需求跟蹤
2. 缺陷預(yù)防bug
3. 工具需求
4. 整理出明確的需求點
5. 測試地圖

• 分析思路誤區(qū)：需求和實現(xiàn)的區(qū)別【現(xiàn)有需求才有代碼實現(xiàn)，不能把代碼實現(xiàn)當(dāng)作需求】
• 需求分析的意義

1. 明確產(chǎn)品給客戶帶來的價值
2. 明確產(chǎn)品支持和不支持的功能
3. 明確產(chǎn)品各個功能的約束性
4. 知道開發(fā)實現(xiàn)功能
5. 知道測試分析和產(chǎn)出測試

二：測試過程中遇到不能復(fù)現(xiàn)的bug的時候你怎么辦?

　　　　遇到問題就要提，在提交的Bug描述中需要加上一句話，那就是復(fù)現(xiàn)概率，嘗試10次，出現(xiàn)1次或者嘗試10次，出現(xiàn)5次，開發(fā)會根據(jù)bug的復(fù)現(xiàn)概率，調(diào)整改bug的優(yōu)先級盡量回想發(fā)生問題時的復(fù)現(xiàn)步驟，不要漏掉任何一個細(xì)節(jié)，按照步驟的組合嘗試復(fù)現(xiàn)保留發(fā)生bug時的log，附加到提交的bug中，希望可以通過log中找到一些相關(guān)的，或使用錄屏工具將操作步驟錄下來與開發(fā)人員配合，讓開發(fā)同學(xué)對相應(yīng)地方的代碼進行檢查，看一下是否可以通過代碼層面檢查出問題
在接下來的測試中，時刻保持關(guān)注，每次執(zhí)行同樣或者相近的步驟的時候，看下是否能夠復(fù)現(xiàn)之前的bug通過上述的辦法，仍然無法復(fù)現(xiàn)，根據(jù)bug的優(yōu)先級，在上線之前對該bug進行處理，嚴(yán)重級別的bug，要召集項目組的成員，集合大家的力量盡可能的復(fù)現(xiàn)bug，不嚴(yán)重的bug，也不要關(guān)掉，上線后及時的關(guān)注用戶的使用反饋，如果持續(xù)3或者4個版本沒有出現(xiàn)，那么可以將bug暫時關(guān)掉了，同時關(guān)掉的時候要進行評論說明并不是因為修復(fù)，而是經(jīng)過x個版本后不復(fù)現(xiàn)了。

三：測試過程中遇到 開發(fā)不認(rèn)為的bug的bug你怎么辦？

　　1.首先明確開發(fā)說不是bug的理由

　　2.如果是需求變更，找產(chǎn)品經(jīng)理確認(rèn)是否是需求變更

　　3.如果開發(fā)說測試環(huán)境問題，讓他說明清楚測試環(huán)境問題是什么，按照他說的驗證一遍，如果確實如他所說，關(guān)閉bug，但是不是他說的那樣，繼續(xù)激活bug給開發(fā)解決，確保產(chǎn)品質(zhì)量。 

　　4.如果開發(fā)說用戶不存在這種使用場景，但是我們不認(rèn)可他說的，把這個bug知會到測試經(jīng)理，讓測試經(jīng)理去判定。

四：經(jīng)典用例設(shè)計

　　一：.微信發(fā)紅包的測試點　

1. 群發(fā)紅包的個數(shù)，以及數(shù)字

2. 紅包的封面背景

3. 紅包的最大金額以及最小金額

4. 紅包發(fā)出的時間 在沒有接收時 多長時間會自動退回

5. 群發(fā)紅包每個人指定金額

6. 群發(fā)紅包時 輸入的金額是否合格

7. 群發(fā)紅包時 使用密碼支付

8. 群發(fā)紅包時使用指紋支付

9. 發(fā)紅包時 寫入祝福語時可不可以用表情包

10. 安卓和蘋果是否兼容

11. 網(wǎng)絡(luò)速度

12. 外部來信息是否能發(fā)紅包

　　二：測試紙杯的用例點

　　　　測試一個帶廣告圖案的花紙杯  
　　　　二相關(guān)背景：  
　　　　1.杯子特性：  
　　　　(1)杯子的容量：能裝多少升水，空杯，半杯，滿杯  
　　　　(2)杯子的型狀：圓型，上面口大，下面小。  
　　　　(3)杯子的材料：紙杯  
　　　　(4)杯子的抗摔能力：風(fēng)吹是否會倒，摔一次是否會摔壞，摔多次是否會摔壞 (5)杯子的耐溫性：裝冷水，冰水，熱水 

　　　　2.廣告圖案：  
　　　　(1)廣告內(nèi)容與圖案碰水是否會掉色  
　　　　(2)廣告內(nèi)容與圖案是否正當(dāng)  
　　　　(3)廣告內(nèi)容與圖案是否輕易剝落  
　　　　三影響范圍：  
　　　　1.可用性：  
　　　　(1)裝進液體多久后會漏水  
　　　　(2)裝進熱水多久后可以變溫，裝進冰水多久后可以融化  
　　　　2.安全性：  
　　　　(1)裝進不同液體，是否會有化學(xué)反應(yīng)。比如：可樂，咖啡等飲料  
　　　　(2)裝進熱水杯子是不是會變型和異味

　　　　3.性能：  
　　　　(1)不同人群是否能適合杯子的型狀，包括握杯的感覺和喝水的感覺  
　　　　(2)不同人群是否能接受杯子的廣告內(nèi)容與圖案  

　　三：購物車測試用例點

　　　　1.界面測試

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

　　　　2.功能測試

        　　　　未登錄時：

• 　　　　將商品加入購物車，頁面跳轉(zhuǎn)到登錄頁面，登錄成功后購物車數(shù)量增加；
• 　　　　.點擊購物車菜單，頁面跳轉(zhuǎn)到登錄頁面。

     　　  登錄后：

• 　　　　所有功能是否能跳轉(zhuǎn)；
• 　　　　商品是否可以加入購物車；
• 　　　　.購物車商品總數(shù)是否有限制；
• 　　　　.商品總數(shù)是否正確；
• 　　　　全選功能是否好用；
• 　　　　.刪除功能是否好用；
• 　　　　價格總計是否正確；
• 　　　　商品文字太長時是否顯示完整；
• 　　　　店鋪名字太長時是否顯示完整；
• 　　　　購物車中下架的商品是否有特殊標(biāo)識；
• 　　       購物車中下架的商品是否能進行購買；
• 　　　　新加入購物車商品排序；
• 　　　　商品刪除后商品總數(shù)是否減少；
• 　　　　購物車結(jié)算功能是否好用。

　　　　3.兼容性測試

        　　　　不同瀏覽器測試。

　　　　4.易用性測試

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

　　　　5.性能測試

       　　　　壓力測試；并發(fā)測試。

　　四：登錄的測試點　　　

　　　　功能測試(Function test)

　　　　　　1.    輸入框空值測試：保持輸入框為空，點擊登錄。（非空檢查）

　　　　　　2.    空格測試：

　　　　　　　　　　（1）用戶名和密碼前后有空格的處理

　　　　　　　　　　（2）是否過濾掉輸入字符前后和中間輸入的空格

　　　　　　3.    無效數(shù)據(jù)測試：

　　　　　　　　　　（1）輸入正確的賬號，錯誤的密碼

　　　　　　　　　　（2）輸入不存在的賬號，注冊過的密碼

　　　　　　　　　　（3）輸入注冊過的賬號與密碼不匹配

　　　　　　4.    有效性測試：輸入正確注冊的賬號、密碼

　　　　　　5.    密碼輸入框：

　　　　　　　　　　（1）不能明文顯示

　　　　　　　　　　（2）是否區(qū)分大小寫

　　　　　　　　　　（3）輸入框是否可復(fù)制粘貼

　　　　　　　　　　（4）修改密碼后再次登陸驗證老密碼和新密碼是否能登陸成功

　　　　　　6.    輸入框長度限制：邊界值測試

　　　　　　7.    溢出測試：輸入很長長度的字符看頁面是否會蹦

　　　　　　8.    登錄成功后能否能否跳轉(zhuǎn)到正確的頁面

　　　　　　9.    記住用戶名的功能

　　　　　　10. 登陸失敗后，不能記錄密碼的功能

　　　　　　11. 密碼是否加密顯示

　　　　　　12. 登錄頁面中的注冊、忘記密碼，登出用另一帳號登陸等鏈接是否正確

　　　　　　13. 一臺設(shè)備登陸多個賬號

　　　　　　14. 密碼輸入錯誤的登陸次數(shù)限制

　　　　　　15. 成功登陸后，退出再次登陸是否需要重新登陸

　　　　　　16. 登陸按鈕禁止多次點擊

　　　　　　17. 手機設(shè)置不同的語言看界面是否顯示正常

　　　　安全性測試：

　　　　　　1.    登錄成功后生成的Cookie，是否是httponly (否則容易被腳本盜取)

　　　　　　2.    cookie 緩存問題，sql語句注入

　　　　　　3.    設(shè)備的兼容性：不同機型（Android、iOS）、不同型號（屏幕大小）的界面顯示問題，（華為的虛擬鍵盤）

　　　　　　4.    用戶名和密碼是否通過加密的方式，發(fā)送給Web服務(wù)器

　　　　　　5.    用戶名和密碼的驗證，應(yīng)該是用服務(wù)器端驗證， 而不能單單是在客戶端用javascript驗證

　　　　　　6.    用戶名和密碼的輸入框，應(yīng)該屏蔽SQL注入攻擊

　　　　　　7.    用戶名和密碼的的輸入框，應(yīng)該禁止輸入腳本 （防止XSS攻擊）

　　　　　　8.    錯誤登陸的次數(shù)限制（防止暴力破解）

　　　　性能測試：

　　　　　　1.    打開登錄頁面時間

　　　　　　2.    登錄進入頁面時間

　　　　　　3.    支持多少人同時在線

　　　　　　4.    輸入正確的用戶名和密碼后，登錄成功后能否跳轉(zhuǎn)到新的頁面

　　　　可用性測試:

　　　　　　1.    是否可以全用鍵盤操作，是否有快捷鍵

　　　　　　2.    輸入用戶名，密碼后按回車，是否可以登陸

　　　　兼容性測試（Compatibility Test）:

　　　　　　1.    不同的分辨率

　　　　本地化測試（Localization test）

　　　　　　1.    不同語言環(huán)境下，頁面的顯示是否正確。

五：token  session cookie 三者之間的區(qū)別？

　　1.cookie 數(shù)據(jù)存放在客戶的瀏覽器上，session數(shù)據(jù)存放在服務(wù)器上

　　2. cookie  不是很安全

　　3.token 的安全性比session好  可以防止監(jiān)聽或者攻擊

六：部門負(fù)責(zé)人的簡稱？

　　1.開發(fā)總監(jiān)：CDO

　　2.評估總監(jiān)：CVO

七：性能測試的指標(biāo)有哪些？

　　RT：響應(yīng)時間
TPS：每秒完成事務(wù)數(shù)
CPU性能指標(biāo)：利用率、負(fù)載
Mem：內(nèi)存性能指標(biāo)，可用物理內(nèi)存、虛擬內(nèi)存使用率
Disk：磁盤性能指標(biāo)，Disk Time、IO等待
NetWork：網(wǎng)絡(luò)指標(biāo)，帶寬使用率、任務(wù)隊列長度
TCP連接數(shù)，可以用netstat命令統(tǒng)計得到
中間件建立的線程池，監(jiān)控線程狀態(tài)
JVM性能指標(biāo)，GC情況、Heap使用情況
CPU負(fù)載隊列長度