一：測試流程

• 整體流程圖：

需(xu)求提(ti)取(qu) -> 需(xu)求分析 -> 需(xu)求評(ping)審 -> 更新(xin)后(hou)的測試需(xu)求跟(gen)蹤xmind

• 分析流程：

1. 需求提取：

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

2. 需求分析：

• 分析依據（五維分析）
• 用戶場景

1. 功能是否和場景強關聯
2. 網絡拓撲能否滿足客戶需求
3. 和競爭對手比較差異
4. 功能是否能滿足客戶實際應用場景
5. 是否考慮了用戶的實際操作

• 明確性

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

• 二義性

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

• 完整性

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

• 可測試性

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

• 輸出

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

• 分析思路誤區：需求和實現的區別【現有需求才有代碼實現，不能把代碼實現當作需求】
• 需求分析的意義

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

二：測試(shi)過程中(zhong)遇到不能(neng)復現(xian)的bug的時候(hou)你怎(zen)么辦(ban)?

　　　　遇到問題就要提，在提交的Bug描述中需要加上一句話，那就是復現概率，嘗試10次，出現1次或者嘗試10次，出現5次，開發會根據bug的復現概率，調整改bug的優先級盡量回想發生問題時的復現步驟，不要漏掉任何一個細節，按照步驟的組合嘗試復現保留發生bug時的log，附加到提交的bug中，希望可以通過log中找到一些相關的，或使用錄屏工具將操作步驟錄下來與開發人員配合，讓開發同學對相應地方的代碼進行檢查，看一下是否可以通過代碼層面檢查出問題
在接下(xia)(xia)來的(de)(de)(de)(de)(de)測試(shi)中，時刻保(bao)持關(guan)注，每次執行(xing)同樣(yang)或者(zhe)相近的(de)(de)(de)(de)(de)步驟的(de)(de)(de)(de)(de)時候，看下(xia)(xia)是否能夠(gou)復(fu)(fu)(fu)(fu)現(xian)(xian)之前(qian)的(de)(de)(de)(de)(de)bug通過上(shang)述的(de)(de)(de)(de)(de)辦法，仍然無法復(fu)(fu)(fu)(fu)現(xian)(xian)，根據(ju)bug的(de)(de)(de)(de)(de)優先級(ji)，在上(shang)線(xian)之前(qian)對(dui)該bug進(jin)行(xing)處理，嚴重(zhong)級(ji)別的(de)(de)(de)(de)(de)bug，要(yao)召集項目組的(de)(de)(de)(de)(de)成員，集合大(da)家的(de)(de)(de)(de)(de)力量盡可能的(de)(de)(de)(de)(de)復(fu)(fu)(fu)(fu)現(xian)(xian)bug，不(bu)嚴重(zhong)的(de)(de)(de)(de)(de)bug，也不(bu)要(yao)關(guan)掉(diao)，上(shang)線(xian)后及時的(de)(de)(de)(de)(de)關(guan)注用戶(hu)的(de)(de)(de)(de)(de)使用反饋，如(ru)果持續(xu)3或者(zhe)4個(ge)版本(ben)沒有出現(xian)(xian)，那(nei)么可以將bug暫時關(guan)掉(diao)了(le)，同時關(guan)掉(diao)的(de)(de)(de)(de)(de)時候要(yao)進(jin)行(xing)評(ping)論說明并不(bu)是因(yin)為修復(fu)(fu)(fu)(fu)，而是經過x個(ge)版本(ben)后不(bu)復(fu)(fu)(fu)(fu)現(xian)(xian)了(le)。

三：測試(shi)過程中遇到 開發(fa)不認為的(de)bug的(de)bug你怎么辦？

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

　　2.如(ru)果是(shi)需(xu)求變(bian)更，找產品經理確認(ren)是(shi)否是(shi)需(xu)求變(bian)更

　　3.如果開發說測試環(huan)境(jing)問(wen)題(ti)，讓他說(shuo)明清楚測(ce)試(shi)環(huan)境(jing)問(wen)題(ti)是什么，按照他說(shuo)的驗(yan)證一遍，如(ru)果確實如(ru)他所(suo)說(shuo)，關閉bug，但是不是他說(shuo)的那(nei)樣，繼續激活bug給(gei)開發解(jie)決，確保(bao)產品(pin)質量。 

　　4.如(ru)果開(kai)發說用戶不存在這(zhe)種使(shi)用場(chang)景，但是我們不認可他(ta)說的，把這(zhe)個(ge)bug知(zhi)會到測試(shi)經理，讓測試(shi)經理去判定。

四：經典用例設計

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

1. 群發(fa)紅(hong)包(bao)的(de)個數，以(yi)及數字

2. 紅包的封面背景

3. 紅(hong)包的最大金(jin)(jin)額以(yi)及最小金(jin)(jin)額

4. 紅(hong)包發出(chu)的時間 在(zai)沒有接(jie)收時 多長時間會自動退回

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

6. 群發(fa)紅包(bao)時(shi) 輸入的金額(e)是否合格

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

8. 群(qun)發(fa)紅(hong)包時使用指(zhi)紋支付

9. 發(fa)紅包時(shi) 寫(xie)入祝福語(yu)時(shi)可(ke)不(bu)可(ke)以用表(biao)情包

10. 安卓和蘋果是否兼容

11. 網絡速度

12. 外部來信息是否(fou)能發(fa)紅(hong)包

　　二(er)：測(ce)試紙杯的(de)用(yong)例點

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

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

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

　　三：購物(wu)車測試用(yong)例點

　　　　1.界面測試

      　　　　 界(jie)面布(bu)局、排版是(shi)否(fou)合理；文(wen)字(zi)是(shi)否(fou)顯示清晰；不同賣(mai)家(jia)的商(shang)品是(shi)否(fou)區分明顯。

　　　　2.功能測試

      ;  　　　　未登錄時(shi)：

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

     　　  登錄后：

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

　　　　3.兼容(rong)性測試

        　　　　不同瀏(liu)覽器測試。

　　　　4.易用性測試

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

　　　　5.性能測試

       　　　　壓力測(ce)試；并發測(ce)試。

　　四：登(deng)錄(lu)的測試點　　　

　　　　功能測試(Function test)

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

　　　　　　2.    空(kong)格(ge)測試：

　　　　　　　　　　（1）用戶(hu)名和密碼(ma)前(qian)后有(you)空格的處理

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

　　　　　　3.    無效數(shu)據測試(shi)：

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

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

　　　　　　　　　　（3）輸入(ru)注冊過的賬號與密碼(ma)不匹(pi)配

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

　　　　　　5.    密碼輸(shu)入(ru)框：

　　　　　　　　　　（1）不能明文顯示(shi)

　　　　　　　　　　（2）是否(fou)區分(fen)大小寫

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

　　　　　　　　　　（4）修改密碼后再次登(deng)陸驗證老密碼和新密碼是否(fou)能(neng)登(deng)陸成(cheng)功(gong)

　　　　　　6.    輸入(ru)框長度(du)限(xian)制：邊界值測試

　　　　　　7.    溢出(chu)測(ce)試(shi)：輸入很長長度(du)的(de)字符看頁面是否(fou)會(hui)蹦

　　　　　　8.    登(deng)錄(lu)成功后能否能否跳轉(zhuan)到正確(que)的(de)頁面

　　　　　　9.    記(ji)住用戶名(ming)的功(gong)能

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

　　　　　　11. 密(mi)碼(ma)是否加密(mi)顯示

　　　　　　12. 登(deng)錄(lu)頁面(mian)中的(de)注冊(ce)、忘記密(mi)碼，登(deng)出用(yong)另一帳號登(deng)陸等鏈接是(shi)否(fou)正確

　　　　　　13. 一臺設備(bei)登陸(lu)多個賬號(hao)

　　　　　　14. 密碼輸入(ru)錯誤的登陸次(ci)數限(xian)制

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

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

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

　　　　安全性測試：

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

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

　　　　　　3.    設備(bei)的(de)兼容性：不(bu)同機型(xing)（Android、iOS）、不(bu)同型(xing)號（屏幕大小）的(de)界面顯(xian)示問題，（華(hua)為的(de)虛擬(ni)鍵(jian)盤）

　　　　　　4.    用戶名(ming)和密碼是(shi)否通過加(jia)密的方式，發送給(gei)Web服(fu)務(wu)器

　　　　　　5.    用戶(hu)名和(he)密(mi)碼的驗(yan)證(zheng)，應該是用服務器端驗(yan)證(zheng)， 而(er)不(bu)能單單是在客戶(hu)端用javascript驗(yan)證(zheng)

　　　　　　6.    用戶名(ming)和(he)密碼的輸(shu)入(ru)框(kuang)，應該(gai)屏蔽SQL注入(ru)攻擊

　　　　　　7.    用戶名和(he)密碼的(de)的(de)輸入(ru)框，應該禁(jin)止輸入(ru)腳本 （防止XSS攻擊）

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

　　　　性能測試：

　　　　　　1.    打開登錄頁面時間

　　　　　　2.    登錄(lu)進入頁面時間

　　　　　　3.    支(zhi)持多少人同時在線

　　　　　　4.    輸(shu)入正確的(de)用戶名(ming)和密(mi)碼后(hou)，登錄成功后(hou)能(neng)否跳(tiao)轉到新的(de)頁面

　　　　可用性測試:

　　　　　　1.    是否可(ke)以全(quan)用(yong)鍵盤(pan)操(cao)作，是否有快捷鍵

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

　　　　兼容(rong)性測試（Compatibility Test）:

　　　　　　1.    不(bu)同的分辨率

　　　　本(ben)地化測試（Localization test）

　　　　　　1.    不同(tong)語言環境下，頁面的顯示(shi)是否正確(que)。

五：token  session cookie 三(san)者之間的區(qu)別(bie)？

　　1.cookie 數據存(cun)放(fang)(fang)在客戶的瀏覽器(qi)上，session數據存(cun)放(fang)(fang)在服務器(qi)上

　　2. cookie  不是很安全

　　3.token 的安(an)全性(xing)比session好  可(ke)以防止監聽(ting)或者攻擊

六：部門負責人的簡(jian)稱？

　　1.開(kai)發(fa)總監：CDO

　　2.評估總(zong)監(jian)：CVO

七：性(xing)能測試的指標有哪些？

　　RT：響應時間
TPS：每秒完成事務數
CPU性能指標：利用率、負載
Mem：內存性能指標，可用物理內存、虛擬內存使用率
Disk：磁盤性能指標，Disk Time、IO等待
NetWork：網絡指標，帶寬使用率、任務隊列長度
TCP連接數，可以用netstat命令統計得到
中間件建立的線程池，監控線程狀態
JVM性能指標，GC情況、Heap使用情況
CPU負載隊列長度