1.什么是軟體測驗

• 軟體測驗就是驗證軟體是否滿足客戶的需求

2.軟體測驗和開發的區別

2.1軟體測驗和開發中除錯的區別

2.1.1目的不同：

• 測驗：測驗是測驗人員檢測軟體是否實作了軟體他應該實作的功能
• 開發除錯：除錯是程式員檢查代碼是否實作了他想讓代碼實作的

2.1.2角色

• 測驗：測驗人員和開發人員
• 除錯：開發人員

2.1.3階段

• 軟體測驗在軟體開發整個生命周期
• 軟體除錯：在開發階段

2.2技術角度

• 軟體測驗對技術要求廣，但是深度低，要求會使用各種技術工具（語言或者具體工具）
• 軟體開發：對技術要求比較專一，深度會高

3.為什么要選擇軟體測驗（zqsg）

• 興趣
• 技能
• 抗壓力
• 責任感
• 性格特征

4. 需求是什么

• 滿足用戶的期望或正式規定的檔案（合同，標準，規范）所需要的權限和技能，
• 用戶需求：最原始的需求，比較廣，有可能存在不能實作的需求，所以測驗人員需要對需求進行分析和驗證，
• 軟體需求：經過打磨的用戶需求形成的檔案

5.BUG

• 當且僅當，軟體需求規格說明存在且合理的情況下，如果軟體功能和需求規格說明不相符，那說明是軟體錯誤（BUG）；
• 當軟體需求規格說明不存在的情況下，用戶需求存在且合理，如果軟體功能和用戶需求不相符，那說明是軟體錯誤（BUG）；

6.測驗用例

• 測驗用例就是向被測驗系統發起的一組集合，包含測驗環境，測驗步驟，測驗資料，預期結果，標題，測驗功能模塊，優先級，重要性等，

7.開發模型

7.1敏捷模型：

• scrum開發流程：產品發布會議，迭代計劃會議，開發期間的每日站會，演講會議，回顧會議，
• 角色：產品經理（po），專案經理（SM），研發團隊（st）
• 敏捷開發模型中測驗人員怎么測驗？
• 核心人物：找BUG，還需要和開發人員一起找問題產生原因

7.2瀑布模型

• 優點： –強調開發的階段性； –強調早期計劃及需求調查； –強調產品測驗，
• 缺點： –依賴于早期進行的唯一一次需求調查，不能適應需求的變化； –由于是單一流程，開發中的經驗教訓不能反饋應用于本產品的程序； –風險往往遲至后期的測驗階段才顯露，因而失去及早糾正的機會，

7.3螺旋模型

• 優點： –強調嚴格的全程序風險管理， –強調各開發階段的質量， –提供機會檢討專案是否有價值繼續下去，
• 缺點： –引入非常嚴格的風險識別、風險分析和風險控制，這對風險管理的技能水平提出了很高的要求，這需要人員、資金和時間的投入，

7.4增量，迭代模型

• 增量通常和迭代混為一談，但是其實兩者是有區別的，
• 增量是逐塊建造的概念，例如畫一幅人物畫，我們可以先畫人的頭部，再畫身體，再畫手腳
• 迭代是反復求精的概念，同樣是畫人物畫，我們可以采用先畫整體輪廓，再
  勾勒出基本雛形，再細化、著色，

8.軟體測驗模型

8.1V模型

8.2W模型

9.如何描述BUG

• 測驗版本
• 測驗環境（設備，系統）
• 測驗步驟
• 測驗資料
• 預期結果
• 實際結果
• 附件（錯誤截圖，錯誤日志）

9.1 BUG等級

• 1、 Blocker（崩潰）：阻礙開發或測驗作業的問題；造成系統崩潰、死機、死回圈，導致資料庫資料丟失，與資料庫連接錯誤，主要功能喪失，基本模塊缺失等問題，
• 2、 Critical（嚴重）：系統主要功能部分喪失、資料庫保存呼叫錯誤、用戶資料丟失，一級功能選單不能使用但是不影響其他功能的測驗，功能設計與需求嚴重不符，模塊無法啟動或呼叫，程式重啟、自動退出，關聯程式間呼叫沖突，安全問題、穩定性等，
• 3、 Major（一般）：功能沒有完全實作但是不影響使用，功能選單存在缺陷但不會影響系統穩定性，
• 4、 Minor（次要）：界面、性能缺陷，建議類問題，不影響操作功能的執行，可以優化性能的方案等，

9.2面試題

• 系統新功能上線，發現用戶使用某功能時系統崩潰，并無法修復，這時候測驗人員應該怎么處理？
• 1.回退版本（回退到系統的一個穩定版本）
• 2.抓緊時間修復問題

9.3BUG生命周期中的狀態

• 新建—確認–重新打開–延遲----解決—關閉

9.4bug修復后仍存在

• 開發人員修復了一個bug，你測驗的時候發現這個bug仍然存在，可能是什么原因？
• 1.讓開發檢查是否提交新代碼
• 2.測驗人員沒有重新發布測驗環境的代碼
• 3.確實開發人員沒有修改成功

10.軟體測驗人員和開發人員因為bug產生沖突怎么處理？

• 1.檢查自身bug描述是否清楚
• 2.站在用戶的角度去說服開發人員
• 3.bug定級是否準確按照公司相關檔案
• 4.測驗人員要不斷提高自身技術和業務水平，要能夠發現bug，要定位bug產生原因，以及bug的解決方案
• 5.開三方會議，產品經理，開發人員，測驗人員一起討論BUG的解決方案，

11.測驗用例的依據

• 根據需求檔案設計
• 分析需求，細化需求，從需求當中提取出功能點/測驗點，然后再用設計測驗用例的具體方法去設計測驗用例

12.黑盒測驗設計測驗用例的方法

• 等價類
• 邊界值
• 因果圖
• 場景設計法
• 錯誤猜測法
• 正交法

1.測驗用例

1.1等價類（測驗用例無法窮舉的情況）

1.1.1 定義

• 把輸入（特殊情況下才考慮輸出）劃分成若干個等價類（有效等價類和無效等價類），從每一個等價類當中選一個測驗用例進行測驗，如果這個測驗用例通過，我們就說這個測驗用例代表的等價類通過，

1.1.2實體

• 例如：輸入用戶名（具有一定規則，8–12），進行測驗，不可能全部測驗完，選取一部分
• 使用情況：測驗用例太多，沒有辦法窮舉
• 分類：
• 有效等價類：符合資料規則，有意義（8-12）
• 無效等價類：不符合資料規則，沒意義（<8,>12）
• 測驗的時候有效無效都需要測驗

1.2邊界值（很重要）

• 針對輸入邊界進行測驗的設計，叫做邊界值法
• 例如：7，8，12，13位用戶名
• 等價類和邊界值往往結合在一起進行測驗用例的設計

1.3因果圖

• 邏輯圖：與，或，非，恒等
• 使用情況：當輸入有多個，且不同的輸入對應著不同的輸出，可以用因果圖法進行測驗用例的設計
• 使用因果圖法設計測驗用例的步驟
• 1.找出所有的輸入和輸出
• 2.確定不同輸入組合和輸出的關系
• 3.根據確定出的關系華因果圖
• 4.根據因果圖畫判定表
• 5.寫測驗用例

1.4場景法

1.1.1定義

• 把系統中一個一個孤立的功能點按照一定的邏輯組合起來，形成一個場景/業務，針對這個場景進行測驗，
• 首先確定場景中的每一個功能點，確定功能可能的輸入和不同的輸出，

1.1.2實體： 測驗頁面上一個按鈕：登錄按鈕

1.界面

• 按鈕是否在合理的位置
• 顏色大小是否按照UI設計稿進行設計的
• 按鈕對其他文字或者圖片有沒有遮擋
• 按鈕是否可以點擊
• 點擊按鈕是否呼叫了對應的介面，是否回傳正確的回應
• 呼叫介面進行介面測驗

1.5錯誤猜測法

1.1.1定義

• 根據測驗人員的直覺，經驗，知識去判斷系統的某一個模塊的問題，有針對性的設計測驗用例，
• 是一種補充的測驗用例的方法

1.6正交法

1.6.1定義

• 研究多因素多水平的一種測驗用力的方法，根據鄭僥幸，找出最優的輸入組合，進行試驗，分析實驗的結果，用這些結果來衡量整體實驗的結果

2.按照開發階段劃分

2.1單元測驗

• java單元測驗框架
• Junit
• 白盒測驗框架
• 很重要！！！
• 依據是：詳細設計檔案

2.2集成測驗

• 按照一定的策略把單元功能模塊組裝起來，對組裝起來的模塊進行測驗，
  測驗階段：單元測驗之后
  測驗依據：概要設計檔案
  測驗物件：介面
  測驗方法：黑盒和白盒相結合
  測驗人員：黑盒測驗工程師和白盒測驗工程師
  測驗內容：模塊和模塊之間的借口，全域資料結構的測驗，單模塊缺陷對系統的影響，模塊功能的正確性，沖突

2.3系統測驗

測驗階段：集成測驗通過之后
測驗物件：整個軟體系統
測驗人員：黑盒測驗工程師
測驗依據：詳細設計檔案
測驗方法：黑盒測驗
測驗內容：功能、界面、可靠性、易用性、性能、兼容性、安全性，可移植性等

2.4回歸測驗(Regression Testing)

• 查看新引入的代碼對舊的功能是否有影響
• 原因：改BUG，系統進行正常迭代增加的功能

2.5冒煙測驗（smoke testing）

• 對系統的主要功能和核心流程進行測驗，是判斷我們測驗人員是否進行系統測驗的依據

2.6驗收測驗

系統檔案：產品設計檔案，用戶功能手冊，產品使用說明書等
測驗階段：系統測驗之后
測驗依據：用戶需求
測驗方法：黑盒測驗
測驗人員：用戶
測驗內容：和系統測驗一致，增加了檔案測驗

3.按照實施組織劃分

3.1α測驗

3.1β測驗

3.1第三方測驗

4.是否手工劃分

4.1手工測驗

4.2自動化測驗

5.是否運行代碼

5.1靜態測驗

5.2動態測驗

6.按照是否查看代碼劃分

6.1黑盒測驗

• 不關心軟體內部代碼的邏輯，結構實作，只關心輸入和輸出
• 等價類劃分法，邊界值分析法 ，因果圖法，正交實驗法，場景設計法，錯誤推測法

6.2白盒測驗

• 測驗程式的內部的邏輯，結構的實作，是否實作了相應的功能，
• Junit框架
• 陳述句覆寫
• 邏輯覆寫（判定覆寫，條件覆寫，判定組合，條件組合，判定和條件組合）
• 路徑覆寫
• 回圈覆寫

7.按照測驗物件劃分

7.1業務測驗

7.2界面測驗

• 布局排版，字體大小，粗細，是否斜體，圖片是否清晰，頁面的控制元件（按鈕，滾動條，checkbox等）

7.3容錯性測驗

• 指的是當系統由于外界的原因發生例外時，能夠自我處理，不把例外直接展示給用戶，給用戶一個友好提示，給用戶很好的使用感受

7.4易用性

用戶體驗測驗，符合常規使用習慣，給用戶可以有多重選擇

7.5舒適性

7.6實用性

7.7兼容性

7.7.1平臺兼容

不同平臺下是否能夠使用

7.7.2資料兼容

這個平臺的資料，另一個平臺是否能夠使用

7.7.3向前向后兼容

開發了新功能，就功能能否正常使用

7.7.4軟體和其他軟體兼容性

• 下載了A軟體，是否還可以下載B軟體
• （國家反壟斷）

7.8檔案測驗

• 術語正確性
• 功能一致性

7.9性能測驗

• 回應時間
• tps（HTTP per second）
• 吞吐量
• 系統運行時占用的系統資源的情況

7.10安全性測驗

• SQL注入
• xss
• 病毒
• 黑客
• 防爬蟲

7.11記憶體泄漏測驗

• 用戶分配了記憶體空間，但是沒有回收，導致系統記憶體占有越來越多，嚴重情況下系統會崩潰

7.selenium

7.1定位元素的方式

• 1.id
• 2.name
• 3.class-name
• 4.tag-name
• 5.link-text
• 6.partial link text
• 7.xpath
• 8.css selector

7.2等待

• 固定等待：time.sleep
• 智能等待：driver.implicity-wait

7.3層級框架處理

• switch-to.frame()去到一個框架
• switch-to.default（）去到默認框架

7.4彈出框處理 alter

• 1.獲得彈出框的操作句柄：switch-to.alter
• 2.關閉彈出框：alter.accept

7.5unittest框架

• 測驗韌體：前setUp（），后tearDown（）
• 組織測驗套件的方式：
• addTest（一個一個加）
• makeSuite（一個類所有的測驗方法）
• TestLoaer（一個類所有的測驗方法）
• discover（一個檔案夾下，某種命名規律的所有檔案里面的測驗方法）
• 測驗方法默認的運行順序：0-9 > A-Z > a-z
• 忽略測驗用例的執行 @unittest.skip（“skipping”）
• 斷言：判斷預期結果和實際結果一致
• 形成http report
• 資料驅動ddt（Data Driven Testing），安裝：pip install ddt，
• @ddt，@data @unpack @file-data
• 資料驅動測驗方法的執行