1. devops
1.1. QA，QC，QM
1.1.1. QA
概念
Quality Assurance (質量保證)
QA：為了提供足夠的信任表明實體能夠滿足質量要求，而在質量管理體系中實施并根據需要進行證實的全部有計
劃和有系統的活動
職責
QA：最重要的職責在于系統層面的完善，側重于問題的防范及對已發生問題的根源的探究及其對策的實施，從而降
低不良的產生。創建或者制定標準和方法，提高促進軟件開發能力和減少軟件缺陷
技能要求
QA：具備必要資質的 QA 是組織中的高級人才，需要全面掌握組織的過程定義，熟悉所參與項目所用的工程技術。
軟件測試小講堂
5
組織架構
職能結構
在職能結構中，各個職能部門設立自己的 QA 崗位，位于高級經理之下，獨立于項目組。QA 直接對高級經理負
責，但業務上需要向項目經理匯報，屬于項目成員。這種組織結構的優點是 QA 容易融入項目組，易于發現實質性
的問題，解決問題也很快捷。缺點是各職能部門相對獨立，部門之間的經驗缺乏交流和共享，還可能出現對過
程、方法和工具研究的重復性投資。在這種組織結構下，由于高級經理專注于業務的發展，QA 的職業發展容易受
到忽視，難于接受到應有的培訓和提升。
矩陣結構
在矩陣結構中，設立了專門的 QA 部門，與各業務職能部門平級。QA 隸屬于 QA 部，行政上向 QA 經理負責，業務
上向業務部門的高級經理和項目經理匯報。在這種組織結構中，由 QA 部經理對 QA 考評和授權，有利于保證 QA
的獨立性和評價的客觀性，也有利于確保組織的長期利益與項目（或個人）的短期利益之間的平衡。QA 資源為所
有項目所共享，可按照項目優先級動態調配，資源利用更充分，但也可能出現資源競爭沖突。此外，QA 部門對
QA 流程的改進、QA 知識的管理、QA 人員的發展負責，并可集中資源進行 QA 平臺的建設，以防止重復性的投
資。但另一方面，在矩陣結構中，QA 難于融入項目組，發現的問題也很少能得到及時有效的解決。
柔性結構
柔性結構是職能結構和矩陣結構的混合形態，在職能結構的基礎上建立了 QA 組。
軟件測試小講堂
6
專業組
QA 組是一個專業組，不是一個行政機構。QAG Leader 可由質量管理部委派人員擔任或由某業務部門的 QA 兼任。
與職能機構一樣，QA 直接對高層經理負責，但在業務上向項目經理和 QAG Leader 匯報。柔性結構吸收了職能結
構和矩陣結構的許多優點，既便于 QA 融入項目組，又便于部門之間經驗的分享，還利于 QA 能力的提高。QAG
Leader 可以從各部門 QA 匯報中提取出各項目的共性問題，用于組織級過程的改進。企業還可以通過授予 QAG
Leader 不同的權利，比如按照 20/80 原則與高級經理分配 QA 的管理，來促進 QA 專業研究與應用的結合。QA 可
以協助評審和組織會議；在存在外包的情況下，可能需要 QA 在監控外包方方面發揮作用。
QA 工程師
1) 相關體系的認證及完善 （ISO、GMP、CMMI 等等，不同性質企業要求不同 ）。
2）主管技術措施和技術、質量、安全的交底工作。
3）一般性品質工作 。
4）質量培訓工作。
5）做品質就像在給病人看病 ，高手總是能在不良發生之前就解決它 。所以 ，QA ，最重要的是一個預防性作用。
工具
軟件測試小講堂
7
層別法、柏拉圖、特性要因圖、查檢表、直方圖、控制圖和散布圖
關聯圖、KJ 法、系統圖、矩陣圖、矩陣數據分析法、PDPC 法以及箭條圖
1.1.2. QC
概念
Quality Control (質量控制)
Qc：為達到品質要求所采取的作業技術和活動
職責
QC：最重要的職責在于對制成品的監控。盡可能早的找出軟件缺陷，確保得以修復
技能要求
QC：既包括軟件測試設計員等高級人才，也包括一般的測試員等中、初級人才。
步驟
（1） 選擇控制對象；
（2） 選擇需要監測的質量特性值；
軟件測試小講堂
8
（3） 確定規格標準，詳細說明質量特性；
（4） 選定能準確測量該特性值或對應的過程參數的監測儀表，或自制測試手段；
（5） 進行實際測試并做好數據記錄；
（6） 分析實際與規格之間存在差異的原因；
（7） 采取相應的糾正措施。
1.1.3. QM
概念
Quality Manage (質量管理)
QM：確定質量方針、目標和職責，并在通過諸如：質量策劃、質量控制、質量保證和質量改進等，使其實施的全
部管理職能的所有活動。
職責
QM：最重要的職責在于從組織層面上保障質量工作環境。
技能要求
軟件測試小講堂
9
QM：不僅要具備 QA、QC 的技能，還需具備專業管理才能。
實現手段
1. 標準管理--此項是依賴一個統一的標準, 保證質量有個唯一的依據. 這個依據主要定義了一些宏觀的、指標的、框架
性的質量約定。
2. 流程管理--此項是用來保證質量的一個重要手段。如國外有從熱衷于質量體系到管理體系認證的轉變，這就反應了
一種意識，純粹的質量體系（無流程管理）是費時費力但效果不一定好的方式。
3. 產品測試管理--產品測試是保證質量的一個最重要手段，所以對測試的管理又是 QM 的一項核心工作。
4. 產品發布管理--產品發布是產品質量的依附，不同版本的產品可能存在不同的瑕疵，質量管理的一個重要管理部分
就是要清楚這些不同版本產品的質量情況。
1.1.4. 關系
SQA 指產品和過程保證人員，通過過程的方法保證質量達到要求；
SQC 指測試人員，通過驗證的方法提供產品滿足需求的證據；
SQM 指質量管理人員，一般為負責質量方面的管理者，通過制定過程、協調資源等一系列的手段為 QA、QC 工作創造
良好的環境和條件。
軟件測試小講堂
10
如果說質量就意味一個組織"第一次就把事情做對"的能力的話，那么，這種能力需要三個方面的修煉，缺一不可：
一是"控制系統"，
二是"保證系統"，
三則是管理思想。
1.2. Development 和 Operations
1.3. 開發
1.3.1. 規劃
1.3.2. 編碼
1.3.3. 構建
1.4. 測試
1.4.1. 軟件測試基礎
測試定義
軟件測試小講堂
11
通過人工或自動的手段，對被測對象進行檢測的活動，目的在于發現被測對象是否實現用戶的需求，或者弄清實際
結果和預期結果之間的差距
需要理解什么軟件
源代碼
用戶手冊
配置數據
測試目的
發現被測對象與用戶需求之間的差異---俗稱找 bug
通過測試活動，獲取被測對象的質量信息，為決策提供數據依據通過測試活動，預防缺陷，從降低項目或產品的風
險
通過測試活動，獲取被測對象的質量信息，為決策提供數據依據
通過測試活動，預防缺陷，從降低項目或產品的風險
測試原則
軟件測試小講堂
12
測試證明軟件存在缺陷
不可能執行窮盡測試
測試應盡早啟動，盡早介入缺陷存在群集現象
不同的測試活動依賴不同的測試背景
殺蟲劑悖論
不同的測試活動依賴不同的測試背景
不存在缺陷的謬論
測試對象
軟件源代碼
與軟件源代碼匹配的文檔
支撐軟件源代碼運行的配置數據
需求階段
需求階段
軟件測試小講堂
13
測試需求文檔是香正確實現了用戶的需求
系統設計階段
概要設計文檔
詳細設計文檔
是否有設計或邏輯上的錯誤
編碼階段
測試源代碼
發現編程上的錯誤
系統測試階段
被測對象是否滿足用戶需求
1.4.2. 軟件測試級別
單元測試
針對被測系統最小的組成單元實施的測試活動，一般是類或函數，也可能最小的功能單元
軟件測試小講堂
14
集成測試
針對組件、單元與組件、單元之間的接口實施的測試活動，驗證接口設計是否與設計相符
分 3 種集成
數間集成
模塊間集成
子系統間集成
系統測試
將通過集成測試的軟件，部署在真實的用戶環境下執行測試
驗收測試
由用戶在開發環境下執行的測試活動，開發者在測試人員身邊，發現問題及時溝通解決
α 測試
由用戶在開發環境下執行的測試活動，開發者在測試人員身邊，發現問題及時溝通解決
在受控環境下執行測試
軟件測試小講堂
15
β 測試
開發者不在測試人員身邊，發現問題由專人統一收集，再由研發人員進行修改
在不受控環境下執行測試
UAT 測試
用戶接受度測試
一般商業用戶驗證系統可用性進行的測試
維護測試
1.4.3. 系統測試類型
功能測試
在指定使用條件下，使用被測對象，驗證其是否滿足用戶顯性或隱性需求
測試關注點
是否有不正確或遺漏或多余的功能
滿足系統顯性或隱性需求
軟件測試小講堂
16
是否對輸入輸出做出了正確的相應，輸出結果能否正確的顯示
性能測試
通過模擬被測對象運行業務壓力或使用場景，驗證被測對象是否滿足預先設定的性能指標
了解測試系統典型場景，并具有確定的性能目標
驗證系統是否具有宣稱的能力
要求在真實環境下實施
安全性測試
測試被測對象的安全保護機制保護系統不受非法侵入，能夠接受正確授權的操作
兼容性測試
測試被測對象的安全保護機制保護系統不受非法侵入，能夠接受正確授權的操作
1.4.4. 軟件測試方法
黑盒測試
不關注被測對象內部結構，僅從用戶需求考慮，是否滿足用戶顯性或隱性需求
軟件測試小講堂
17
白盒測試
結構測試、邏輯驅動測試
灰盒測試
既關注被測對象的外部特性，又關注其內部設計
靜態測試
不執行被測對象程序，不運行被測對象的測試方法
動態測試
執行被測對象，進行的檢測活動
手工測試
通過測試工程師試用、驗證被測對象是香滿足用戶需求
自動化測試
通過自動化測試工具，或腳本語言自動化完成測試過程
1.4.5. 軟件質量
軟件測試小講堂
18
質量定義
質量是物體本身的屬性，物體的質量與物體的形狀、物態及其所處的空間位置無關，質量是物體的一個基本屬性
軟件產品滿足用戶或規定顯性需求或隱性需求的程度
內部質量
過程質量
外部質量
使用質量
質量特性
功能性
定義
軟件在指定條件下使用時，滿足用戶明確和隱含需求的功能的能力
適合性
軟件為指定的任務和用戶目標提供—組合適功能的能力
軟件測試小講堂
19
準確性
軟件提供具有所需精確度的正確或相符的結果或效果的能力
互操作性
軟件與一個或更多的規定系統進行交互的能力
保密安全性
軟件保護信息和數據的能力，以使未授權的人員或系統不能閱讀或修改這些信息和數據，而不拒絕授權人員或系
統對它們的訪問
功能性依從性
軟件遵循與功能性相關的標準、約定或法規以及類似規定的能力。這些標準要考慮國際標準、國家標準、行業標
準、企業內部規范等
可靠性
定義
軟件在指定條件下使用時，維持規定的性能級別的能力
軟件測試小講堂
20
成熟性
軟件為避免由軟件中錯誤而導致失效的能力
容錯性
在軟件出現故障或者違反指定接口的情況下，軟件維持規定的性能級別的能力
易恢復性
在失效發生的情況下，軟件重建規定的性能級別并恢復受直接影響的數據的能力
可靠性依從性
軟件遵循與可靠性相關的標準、約定或法規的能力
易用性
定義
在指定條件下使用時，軟件被理解、學習、使用和吸引用戶的能力
易理解性
軟件使用戶能理解軟件是否合適，以及如何能將軟件用于特定的任務和使用環境的能力
軟件測試小講堂
21
易學性
軟件使用戶能學習其應用的能力
易操作性
軟件使用戶能操作和控制它的能力
吸引性
軟件吸引用戶的能力
易用性依從性
軟件遵循與易用性相關的標準、約定、風格指南或法規的能力。這些標準要考慮國際標準、國家標準、行業標
佳、企業內部規范等。
效率
定義
在規定條件下，相對于所用資源的數量，軟件可提供適當性能的能力
時間特性
軟件測試小講堂
22
在規定條件下，軟件執行其功能時，提供適當的響應和處理時間以及吞吐率的能力，即完成用戶的某個功能需要
的響應時間
資源利用性
在規定條件下，軟件執行其功能時，使用合適的資源數量和類別的能力
效率依從性
軟件遵循與效率相關的標準或約定的能力
可維護
定義
軟件可被修改的能力。修改可能包括修正、改進或軟件對環境、需求和功能規格說明變定義化的適應性
易分析性
軟件診斷軟件中的缺陷、失效原因或識別待修改部分的能力
易改變性
軟件使指定的修改可以被實現的能力
軟件測試小講堂
23
穩定性
軟件避免由于軟件修改而造成意外結果的能力
易測試性
軟件使已修改軟件能被確認的能力
維護性依從性
軟件遵循與維護性相關的標準或約定的能力
可移植
定義
軟件從一種環境遷移到另外—種環境的能力
適應性
軟件無須采用有別于為考慮該軟件的目的而準備的活動或手段，就可以適應不同指定環境的能力
共存性
軟件在公共環境中同與其分享公共資源的其他獨立軟件共存的能力
軟件測試小講堂
24
易安裝性
軟件在指定環境中被安裝的能力
易替換性
軟件在同樣環境下，替代另一個相同用戶的指定軟件產品的能力
可移植性依從性
軟件遵循與可移植性相關的標準或約定的能力
1.4.6. 系統測試流程
測試報告輸出
測試日報
(1)方便測試工程師學握測試進度和測試情況，用于整條下一天的工作計劃
(2) 測試工程師對被測對象每天給出評估結果，用于調整后續工作中的測試策略
(3)測試經理通過測試日報了解每個測試工程師的工作進度，把握測試整體進度，發
軟件測試小講堂
25
(4)測試經理通過測試日報，了 解各模塊缺陷發展趨勢，判斷測試是否可以退出，通常可利用缺陷管理 T 具的統計
分析功能了解缺陷發展狀況
(5)開發經理根據測試日報了解被測對象質量情況，并可以調整缺陷修改人力資源
(6)如果產品有多個測試組并行測試，測試日報可以提供彼此測試交流的手段
測試報告
(1)軟件測試工程師評估當前被測對象的質量，并對下一階段的測試工作給出建議
(2)測試經理通過測試報告了解被測試產品的質量情況、測試過程的質量
(3)軟件開發項目經理通過軟件測試報告了解開發產品的質量情況，并在下階段的開發工作中采取應對措施
(4)在測試報告中，測試工程師給出的產品質量評估可以作為軟件產品是否商用發布的重要參考依據
測試結束活動
(1)檢查在測試過程中測試計劃中定義的輸出物
(2)缺陷管理是否完成。是否經進入缺陷管理流程
(3)測試實施過程中產生的風險報告需要記錄
軟件測試小講堂
26
(4)測試報告是否給出，相關的經驗教訓是否總結并分享
(5)是否需要移交測試對象
1.5. 運維
1.5.1. 發布
1.5.2. 部署
1.5.3. 維護
1.6. 全員質量共建
1.6.1. 從需求出發
我們只有在全面、深入了解需求的基礎上，才能設計全面、有效的測試用例來進行測試，以滿足對于軟件產品滿足需
求的基本質量保證
1.6.2. 測試依據
測試設計的依據是對于軟件產品需求的全面和深入分析
因為我們不僅要驗證需求，而且要驗證設計
軟件測試小講堂
27
我們根據對需求的全面深入分析和對設計實現的了解，兩相綜合產生的測試設計
1.6.3. 測試人員不只是驗證質量
測試人員無法保證軟件產品的質量，軟件產品的質量是通過參與軟件過程的各方聯合共同保證的
由于軟件測試人員不是產品設計人員和開發人員，所以無法做到比他們更了解產品需求和產品設計，如果他們都無法
保證需求和設計沒有問題，那么測試人員就更無法保證了
軟件測試位于軟件開發生命周期的末端，如果依靠測試人員來發現所有的 bug 來保證質量的話，那么風險就會后置，
導致問題修復的成本增加，同時也增加了修復問題帶來新問題的風險，因為在項目末端是不可能投入過多的成本來進
行那怕接近全面覆蓋的測試的。
測試人員只能根據前期分析的結果，設計出測試用例，來驗證軟件產品在事先設計或后續補充的測試用例上不存在問
題
實際上，如果最終發布的軟件產品出現了問題，那么無論如何我們肯定是有責任的。
1.6.4. 測試的內容一定是確定的
軟件測試只能驗證質量，那么所要驗證的內容必然是確定的，或者說是概率確定的，否則也就無從驗證了
軟件產品的可測性判斷是我們進行需求評審和設計評審時是一定要保證這個基本點的
軟件測試小講堂
28
1.6.5. 測試的目標不是沒有 bug
軟件測試的目標不是通過測試使得軟件產品不存在 bug（這是不可能達成的），而是我們根據確定的需求、確定的設
計和確定的測試用例驗證出的結果不存在 bug
而是運用測試思維，使用一定的測試方法，盡可能早地在需求階段、設計階段將所有的 bug 找出來，真正測試執行階
段只是驗證不存在用例所描述的那樣的 bug，而不是通過用例去發現 bug
2. 思維
2.1. 整體思維也叫框架思維
2.1.1. 從整體的高度去設計測試用例
2.1.2. 首先驗證主流程是否通暢
2.1.3. 五原則
連續性原則
即當思維對象確定后，思維主體就要從許多縱的方面去反映客觀整體，把整個客觀整體視為一個有機延續而不間斷
的發展過程
立體性原則
軟件測試小講堂
29
即當思維對象確立之后，思維主體要從橫的方面，也就是從客觀事物自身包含的各種屬性整體地考察它、反映它，
使整體性事物內在諸因素之間的錯綜復雜關系的潛網清晰地展示出來
系統性原則
即是從縱橫兩方面來對客觀事物進行分析和綜合，并按客觀事物本身所固有的層次和結構，組成認識之網，邏輯再
現客觀事物的全貌。
動態穩定性原則
系統的穩定是相對的
必須會受到外部因素的干擾而變得不再穩定，如政策調整，熱度冷卻，市場條件，財務因素、物理環境等
發散性原則
由一個功能聯想到其他可能存在關聯的功能，由一而二，由二而三
2.2. 逆向思維
2.2.1. 對接口做測試，通過輸入驗證輸出，如果我們使用各種輸入都無法得到接口設計中某一種輸出的情況時，就需要
從輸出來逆向推導輸入
2.3. 兩極思維
軟件測試小講堂
30
2.3.1. 在事情的兩個極端
常說的邊界值問題
2.4. 拆分思維
2.4.1. 拆分成一個個的最小單位去執行測試
2.5. 創新思維
2.5.1. 了解不知道的業務流程
2.5.2. 學習有可能用得上的測試技術
2.5.3. 豐富測試用例
2.5.4. 優化測試方法
2.6. 架構思維
2.6.1. 架構對測試的影響
軟件測試小講堂
31
首先是穩定性。穩定性可以降低在版本更新時擴展系統功能的重復老師，并減少實施過程的總成本。它鞏固了開發團
隊的基礎，使其專注于開發更大價值的特性，而并非浪費精力關注在經常變更的問題上。對于良好的系統架構，會使
測試設計更穩定，減少因變更帶來的測試工作量。
對變更的度和性質。架構決定系統中發生變更的性質。有些變更很容易被察覺，而察覺另一些則很難。在我們為吸引
更多客戶而需要提高客戶滿意度或增加功能時，如果能夠簡單實現預期的變更，那么各種架構通常被認為是好的。系
統的功能需求變更，使系統受影響的部分最小，避免大量的回歸測試。
邊界的決定。在架構的設計過程中，團隊會就哪些應該被加入到系統中，而哪些不應該被加入到系統中做出很多決
定。例如，是團隊自己寫數據庫訪問層，還是購買許可？團隊是使用開源的 Web 服務器還是購買許可？那個子團隊應
該負責用戶界面的設計？成功的解決方案確實能夠創建技術邊界來支持業務的特殊需求。這些邊界選擇可直接影響我
們的測試，例如，服務器監控、服務器性能參數調優等。
可持續的、不可替代的優勢。這一點可以概括前面的幾點，但是一個好的架構能夠使系統在市場競爭由于難于復制而
占據優勢地位。例如在性能和易用性方面獲得優勢。這對于我們測試來說，可以減少缺陷，性能更能達到目標而減少
系統調優后反復測試的過程。
2.6.2. 測試方向
了解并熟悉開發使用的技術及開發框架
理解研發設計的架構及設計思路，并考察開發設計是否滿足業務需求
軟件測試小講堂
32
Review 技術方案時，考察是否滿足易維護性，易擴展以及對性能和安全的要求，并且在關鍵業務出現異常時是否添加
報警等
2.6.3. 對系統架構的理解
邏輯視圖。它提供了系統開發中對象間或實體間相互關系的靜態快照。這種視圖實際上可能有兩個或更多的表現層。
一個概念模型，另一個是數據庫模式中模型的實現。往往現在數據庫架構師使用 PowerDesigner 描述實體的邏輯關
系，所以需要我們測試工程師學會查看數據庫實體描述，從而了解系統中的數據庫設計，例如關鍵字，索引、表實體
之間的關系等。
過程視圖。過程視圖描述設計的并發性和同步性因素。我們了解過程視圖，從而會了解系統中各個模塊之間的時間、
空間關系。原來的結構化編程中經常用流程圖來表示，而現在面向對象的編程經常用一些建模工具描述對象實體。例
如，架構師經常使用 Rose 等建模工具，建立實體的序列圖、狀態圖等來描述過程。而我們測試工程師應該學會看懂序
列圖或狀態圖等
物理視圖。物理視圖描述軟件到硬件的映射，其中包括實現高可用性、可靠性、容錯性和性能等目標的處理部件的分
布情況。常用 Rose 部署圖來描述物理視圖，也可以使用 Visio 等繪圖工具繪制系統架構圖來描述。
開發視圖。開發視圖描述軟件在開發環境中的靜態組織結構。研發團隊通常用 Rose 等建模工具繪制實體關系圖，描述
各個實體之間的靜態關系。
2.7. 用戶思維
軟件測試小講堂
33
2.7.1. 別讓我等
2.7.2. 別讓我想
2.7.3. 別讓我煩
2.7.4. 別讓我找
3. 意識
3.1. 風險意識
3.1.1. 人員風險
現有人員技術不足以支撐新的業務測試模型
人才資源無法滿足新的業務測試需求
3.1.2. 技術風險
技術方案存在風險
開發人員對業務需求理解不到位
開發人員對業務場景認知不完整
軟件測試小講堂
34
3.1.3. 業務風險
業務場景前后矛盾
本期需求與原有需求存在矛盾但沒有被重構
需求反認知
3.1.4. 排期風險
需要根據自己的有效判斷，來提前提出風險預警
需要提示風險范圍，以提前部署規避風險方案或應對方案
有風險不代表不可完成，有意識不代表不需要努力去做
3.2. 團隊協作意識
3.2.1. 合理進行人員分工
3.2.2. 配合完成測試任務
3.2.3. 配合開發重現缺陷
3.2.4. 督促項目整體進度
軟件測試小講堂
35
3.2.5. 協助組員解決問題
3.3. 成本意識
3.3.1. 時間成本
3.3.2. 人力成本
3.3.3. 經濟成本
3.4. 分享意識
3.4.1. 技術分享
3.4.2. 經驗分享
3.4.3. 方案分享
3.5. 懷疑意識
3.5.1. 對產品的質量持有一顆敢于懷疑的心，質量不是開發人員說"我做完了而且也測過了"就可以保證的。直到你測完最
后一輪，最后一個用例之前，你都應該對產品的質量持懷疑態度。這個態度是混口飯吃的最基本技能
3.6. 責任意識
軟件測試小講堂
36
3.6.1. 自認為測試達到 100%的完美后，發起上線流程
3.6.2. 測試產出與時間成本成反比時，發起上線流程
3.6.3. 不能無休止的測試
3.6.4. 對于你測試的產品負責任
3.6.5. 測試沒有真正的 100%，但是要有自己的 100%
3.7. 公因式意識
3.7.1. 合并可以合并的東西
3.7.2. 抽取一致性的東西
3.8. 殺蟲劑悖論
3.8.1. 測試用例需要經常的評審和修改，不斷增加新的不同的測試用例來測試軟件或系統的不同部分，保證測試用例永
遠是最新的，即包含著最后一次程序代碼或說明文檔的更新信息
3.8.2. 軟件中未被測試過的部分或者先前沒有被使用過的輸入組合就會重新執行，從而發現更多的缺陷。軟件測試人員
必須不斷地編寫新的不同的測試來檢驗程序的不同部分從而找出更多的 bug。讓其他的人來測試你的程序將有助于打破”
殺蟲劑悖論”
軟件測試小講堂
37
4. 能力
4.1. 測試核心能力
4.1.1. 測試策略設計能力
測試策略設計能力是指，對于各種不同的被測軟件，能夠快速準確地理解需求，并在有限的時間和資源下，明確測試
重點以及最適合的測試方法的能力。
4.1.2. 測試用例設計能力
測試用例設計能力是指，無論對于什么類型的測試，都能設計出高效地發現缺陷，保證產品質量的優秀測試用例。
要做好測試用例設計，不僅需要深入理解被測軟件的業務需求和目標用戶的使用習慣，還要熟悉軟件的具體設計和運
行環境，包括技術架構、緩存機制、中間件技術、第三方服務集成等等。
測試用例設計能力要求你不僅僅局限于熟悉業務領域的測試用例設計，而是能夠融會貫通，熟練地把系統性的測試設
計方法和具體業務有機結合，對任何被測軟件都可以輸出出色的測試用例。
要想提高測試用例設計能力，你平時就要多積累，對常見的缺陷模式、典型的錯誤類型以及遇到過的缺陷，要不斷地
總結、歸納，才能逐漸形成體系化的用例設計思維。
軟件測試小講堂
38
同時，你還可以閱讀一些好的測試用例設計實例開闊思路，日后遇到類似的被測系統時，可以做到融會貫通和舉一反
三。
4.1.3. 快速學習能力
對不同業務需求和功能的快速學習與理解能力
對于測試新技術和新方法的學習與應用能力
4.1.4. 探索性測試思維
探索性測試是指，測試工程師在執行測試的過程中不斷學習被測系統，同時結合基于自己經驗的錯誤猜測和邏輯推
理，整理和分析出更多的有針對性的測試關注點
4.1.5. 缺陷分析能力
對于已經發現的缺陷，結合發生錯誤的上下文以及后臺日志，可以預測或者定位缺陷的發生原因，甚至可以明確指出
具體出錯的代碼行，由此可以大幅縮短缺陷的修復周期，并提高開發工程師對于測試工程師的認可以及信任度；
根據已經發現的缺陷，結合探索性測試思維，推斷同類缺陷存在的可能性，并由此找出所有相關的潛在缺陷；
可以對一段時間內所發生的缺陷類型和趨勢進行合理分析，由點到面預估整體質量的健康狀態，并能夠對高頻缺陷類
型提供系統性的發現和預防措施，并以此來調整后續的測試策略。
軟件測試小講堂
39
4.1.6. 自動化測試技術
掌握自動化測試技術，可以把你從大量的重復性手工勞動中解放出來，這樣你可以把更多的時間花在更多類型的測試
上
4.1.7. 良好的溝通能力
一方面，你需要對接產品經理和項目經理，以確保需求的正確實現和項目整體質量的達標；
另一方面，你還要和開發人員不斷地溝通、協調，確保缺陷的及時修復與驗證。
4.2. 基礎測試能力
4.2.1. 理解一些流程相關的東西，如 需求分析、測試計劃、缺陷跟蹤等
4.2.2. 測試要具體執行到什么程度；
4.2.3. 測試需要借助于什么工具；
4.2.4. 如何運用自動化測試以及自動化測試框架，以及如何選型；
4.2.5. 測試人員資源如何合理分配；
4.2.6. 測試進度如何安排；
軟件測試小講堂
40
4.2.7. 測試風險如何應對。
4.3. 環境治理能力
4.3.1. 快速部署環境，保證測試環境的持續可用狀態
4.3.2. 臟數據的處理
4.3.3. 環境切換導致的問題回退
4.4. 專項測試能力
4.4.1. 性能測試
4.4.2. 安全測試
4.4.3. 接口測試
4.4.4. 大數據測試
4.4.5. 人工智能測試
4.5. 工具開發能力
軟件測試小講堂
41
4.5.1. 自動化工具是提高測試效率的利器，將一些重復性的工作自動化掉，能夠避免被繁雜的手工測試所拖累，專注于
更核心的測試工作上去
4.6. 溝通協調能力
4.6.1. 測試工作在項目中起到了承上啟下的作用，在這過程中有很多資源需要協調，很多問題需要反復溝通，例如 測試
同學需要推動開發去做一些自測，這樣才能提升交付質量，出現 bug 后，需要推動開發同學快速修復 bug。因此溝通協
調能力也是測試工程師不容忽視的能力
4.7. 用例設計能力
4.7.1. 作用
⒈指導測試的實施
⒉規劃測試數據的準備
⒊編寫測試腳本的"設計規格說明書"
⒋評估測試結果的度量基準
⒌分析缺陷的標準
4.7.2. 設計原則
軟件測試小講堂
42
(1)正確性。輸入用戶實際數據以驗證系統是否滿足需求規格說明書的要求;測試用例中的測試點應首先保證要至少覆蓋
需求規格說明書中的各項功能，并且正常。
(2)全面性。覆蓋所有的需求功能項;設計的用例除對測試點本身的測試外，還需考慮用戶實際使用的情況、與其他部分
關聯使用的情況、非正常情況(不合理、非法、越界以及極限輸入數據)操作和環境設置等。
(3)連貫性。用例組織有條理、主次分明，尤其體現在業務測試用例上;用例執行粒度盡量保持每個用例都有測點，不能
同時覆蓋很多功能點，否則執行起來牽連太大，所以每個用例間保持連貫性很重要。
(4)可判定性。測試執行結果的正確性是可判定的，每一個測試用例都有相應的期望結果。
(5)可操作性。測試用例中要寫清楚測試的操作步驟，以及與不同的操作步驟相對應的測試結果。
4.7.3. 設計格式
預置條件
測試步驟
預期結果
測試數據
4.7.4. 設計方法
軟件測試小講堂
43
等價類劃分法
邊界值分析法
錯誤推測法
判定表法
正交實驗法
4.7.5. 組織結構
業務需求
發散場景
接口分支
數據庫表
4.7.6. 自動化測試用例
4.8. 質量管理能力
4.8.1. 原則
軟件測試小講堂
44
原則 1： 以顧客為關注焦點
原則 2： 領導作用
原則 3： 全員參與
原則 4： 過程方法
原則 5： 管理的系統方法
原則 6： 持續改進
原則 7： 基于事實的決策方法
原則 8： 與供方的互利關系
4.8.2. 管理方法
全面質理管理（TQM）
六西格瑪
QC 七大手法
檢查表
軟件測試小講堂
45
排列圖
散布圖
數據分層法
休哈特控制圖
魚骨圖
直方圖
4.8.3. 工具
1. 控制圖
是用圖形顯示某項重要產品或過程參數的測量數據。在制造業可用軸承滾珠的直徑作為例子。在服務行業測量值可
以是保險索賠單上有沒有列出某項要求提供的信息。依照統計抽樣步驟，在不同時間測量。控制圖顯示隨時間而變
化的測量結果，該圖按正態分布，即經典的鐘形曲線設計。用控制圖很容易看出實際測量值是否落在這種分布的統
計界線之內。上限叫"控制上限"，下限叫"控制下限"。如果圖上的測量值高于控制上限或低于控制下限，說明過程失
控。這樣就得仔細調查研究以查明問題所在，找出并非隨機方式變動的因素。是制造軸承滾珠用的鋼棒太硬？太
軟？還是鋼棒切割機上切割量調節值設得不對？
軟件測試小講堂
46
2. 帕累托圖又叫排列圖
，是一種簡單的圖表工具，用于統計和顯示一定時間內各種類型缺陷或問題的數目。其結果在圖上用不同長度的條
形表示。所根據的原理是十九世紀意大利經濟學家維爾弗雷德.帕雷托（Vilfred Pareto）的研究，即各種可能原因中
的 20%造成 80%左右的問題；其余 80%的原因只造成 20%的問題和缺陷。為了使改進措施最有效，必須首先抓住造
成大部分質量問題的少數關鍵原因。帕雷托圖有助于確定造成大多數問題的小數關鍵原因。該圖也可以用于查明生
產過程中最可能產生某些缺陷的部位。
3.魚骨圖也稱為因果分析圖
它看上去有些像魚骨，問題或缺陷（即后果）標在"魚頭"外。在魚骨上長出魚刺，上面按出現機會多寡列出產生生
產問題的可能原因。魚骨圖有助于說明各個原因之間如何相互影響。它也能表現出各個可能的原因是如何隨時間而
依次出現的。這有助于著手解決問題。
4. 走向圖有時也叫趨勢圖。
它用來顯示一定時間間隔（例如一天、一周或一個月）內所得到的測量結果。以測得的數量為縱軸，以時間為橫軸
繪成圖形。走向圖就象不斷改變的記分牌。它的主要用處是確定各種類型問題是否存在重要的時間模式。這樣就可
以調查其中的原因。例如，按小時或按天畫出次品出現的分布圖，就可能發現只要使用某個供貨商提供的材料就一
定會出問題。這表示該供貨商的材料可能是原因所在。或者發現某臺機器開動時一定會出現某種問題，這就說明問
題可能出在這臺機器上。
軟件測試小講堂
47
5. 直方圖也稱線條圖。
在直方圖上，第一控制類別（對應于一系列相互獨立的測量值中的一個值）中的產品數量用條線長度表示。第一類
別均加有標記，條線按水平或垂直依次排列。直方圖可以表明哪些類別代表測量中的大多數。同時也表示出第一類
別的相對大小。直方圖給出的是測量結果的實際分布圖。圖形可以表現分布是否正常，即形狀是否近似為鐘形。
6. 分布圖
提供了表示一個變量與另一個變量如何相互關聯的的標準方法。例如要想知道金屬線的拉伸強度與線的直徑的關
系，一般是將線拉伸到斷裂，記下使線斷裂時所用的力的準確數值。以直徑為橫軸，以力為縱軸將結果繪成圖形。
這樣就可以看到拉伸強度和線徑之間的關系。這類信息對產品設計有用。
7. 流程圖
有時也稱作輸入-輸出圖。該圖直觀地描述一個工作過程的具體步驟。流程圖對準確了解事情是如何進行的，以及決
定應如何改進過程極有幫助。這一方法可以用于整個企業，以便直觀地跟蹤和圖解企業的運作方式。流程圖使用一
些標準符號代表某些類型的動作，如決策用菱形框表示，具體活動用方框表示。但比這些符號規定更重要的，是必
須清楚地描述工作過程的順序。流程圖也可用于設計改進工作過程，具體做法是先畫出事情應該怎么做，再將其與
實際情況進行比較。
4.8.4. 價值觀
質量第一:
軟件測試小講堂
48
質量是企業的生命，質量是一切的基礎，企業要生存和盈利，就必須堅持質量第一的原則，從始至終能夠為顧客提
供滿意質量的產品和服務，才能在激烈的競爭中利于不敗之地。
零缺陷:
零缺陷是以拋棄缺點難免論，樹立無缺點的哲學觀念為指導，要求全體人員“從開始就正確地進行工作，第一次就把
事情做對”，以完全消除工作缺點為目標的質量經營活動。
源頭管理:
質量管理應以預防為主，將不良隱患消滅在萌芽狀態，這樣不僅能保證質量，而且能減少不要的問題發生，降低變
更次數，使企業整體的工作質量和效率得到提高。
顧客至上:
現代企業掌握在顧客手中，對于我們企業而言，把顧客需要放在第一位，全心全意為顧客服務。企業要樹立好“顧客
至上”的服務理念，把為顧客服務擺在第一位，想顧客之想，急顧客所急。
滿足需要:
質量是客觀的固有特性與主觀的滿足需要的統一，質量不是企業自說自話，而是是否能夠滿足顧客的需求，只有滿
足了顧客需要，顧客才會愿意買單，企業才能實現盈利。
軟件測試小講堂
49
一把手質量:
企業一把手的一言一行從始至終受到全體員工的特別關注，他對質量的認知、觀點與態度很大程度上決定了員工工
作質量的好壞，一把手應確保企業的質量目標與經營方向一致，全面推進質量工作的開展。
全員參與：
現代企業的質量管理需要全員參與，它不僅僅是某個人、幾個質量管理人員或質量管理部門一個部門的事情，它需
要各個部門的密切配合，需要全員的共同參與。
持續改進：
持續改進整體業績是企業永恒的話題，持續改進是質量管理的原則和基礎，是質量管理的一部分，質量管理者應不
斷主動尋求企業過程的有效性和效率的改進機會，持續改進企業的工作質量。
基于事實的決策方法：
質量管理要求尊重客觀事實，用數據說話，真實的數據既可以定性反映客觀事實，又可以定量描述客觀事實，給人
以清晰明確的直觀概念，從而更好的分析和解決問題。
下工序是顧客：
軟件測試小講堂
50
作為企業的員工，工作時不能只考慮自己的方便，要明確自己對上工序的要求，充分識別下工序的要求，及時了解
工序發來的反饋信息，把下工序當做顧客，經常考慮怎樣做才能使下工序顧客滿意。
規則意識：
規則意識是指發自內心的，以規則為自己行動準繩的意識。企業每個人都要樹立規則意識，敬畏規則，規則不合
理，甚至不正確我們可以或者爭取改變，從內心樹立起規則意識，學習、遵循、監督和執行規則。
標準化預防再發生：
問題發生了，就要去解決，并且確保同樣問題不會再因同樣的理由而發生。問題解決后，要標準化解決方案，更新
作業程序，實施 SDCA 循環。
尊重人性：
很多時候，質量工作需要與人溝通，企業經營者為了持續發展和提升質量，就要充分尊重從事的工作人員，使員工
感受到工作的意義與價值，快樂工作才能更好地提供顧客滿意的工作質量。
5. 流程
5.1. 測試執行流程
5.2. 缺陷提交流程
軟件測試小講堂
51
5.2.1. 提交人員
測試人員
研發人員
產品人生
項目人員
5.2.2. 缺陷依據
需求原型
UI 設計
測試用例
接口和數據庫文檔
用戶體驗
5.2.3. 定位缺陷
分析原因
軟件測試小講堂
52
定位代碼
前端缺陷
后臺缺陷
5.2.4. 生命周期
新建
活動
解決
激活
關閉
5.3. 工作監督流程
5.4. 問題收集流程
5.5. 性能測試流程
5.5.1. 需求分析
軟件測試小講堂
53
業務指標
對接產品方
技術方案
對接研發方
服務器架構
對接運維方
5.5.2. 測試計劃
搭建測試環境
真實生產環境
等比測試環境
測試場景設計
關鍵鏈路設計
監控項列舉
軟件測試小講堂
54
測試腳本選型
手動開發
自動錄制
測試計劃執行
數據準備
基礎數據
存量數據
測試監控
業務指標監控
操作系統指標監控
應用中間件監控
前端提標監控
數據庫指標監控
軟件測試小講堂
55
測試執行
單接口壓測
串聯鏈路壓測
全鏈路壓測
測試目標
容量測試
負載測試
壓力測試
性能調優
硬件/規格上的瓶頸
一般指的是 CPU、內存、磁盤 I/O 方面的問題，分為服務器硬件瓶頸、網絡瓶頸
中間件上的性能瓶頸
軟件測試小講堂
56
"①應用服務器、web 服務器等應用軟件，還包括數據庫系統。例如：中間件 weblogic 平臺上配置的 JDBC 連接池
的參數設置不合理，造成的瓶頸
②防火墻、動態負載均衡器、交換機等設備。當前更多的云化服務架構使用的網絡接入產品"
應用程序上的性能瓶頸
JVM 參數不合理，容器配置不合理，慢 SQL，數據庫設計不合理，程序架構規劃不合理，程序本身設計有問題（串
行處理、請求的處理線程不夠、無緩沖、無緩存、生產者和消費者不協調等）
操作系統上的性能瓶頸：
一般指的是 windows、UNIX、Linux 等操作系統
其他調優
"①更換技術實現方案
②調整產品邏輯"
測試結果
分析
軟件測試小講堂
57
系統性能指標
資源指標
數據庫指標
前端指標
穩定性指標
可擴展性指標
交付
測試報告
5.6. 復盤提升流程
5.7. 部門協作流程
6. 自驅
6.1. 專心
6.1.1. 要集中精力，不可一心二用。精力集中不僅能夠提高工作效率，還能發現更多的軟件缺陷。
軟件測試小講堂
58
6.2. 細心
6.2.1. 軟件測試人員必須細致執行，不忽略關鍵詳解。若不細心，有些軟件缺陷將很難被發現。
6.3. 耐心
6.3.1. 軟件測試會很枯燥，需要很大的耐心才需要做好。如果比較浮躁，也不會做到專心和細心，很多缺陷將從眼前逃
掉。
6.4. 責任心
6.4.1. 責任心是做好任何工作的必備素質之一，軟件測試尤其如此。軟件測試往往起到最后把關的作用，如果敷衍了
事，軟件缺陷就會被放進發布版本或最終應用中，很可能造成非常嚴重的后果。
6.5. 自信心
6.5.1. 自信心是很多測試人員缺少的一項素質，遇到困難縮手縮腳，不敢上線。但具備了較強的自信心，才能更好地與
用戶和開發方交談，才能更好地開展測試工作和發現缺陷。軟件測試人員必須建立起能解決一切測試問題的信心。
6.6. 自驅力
6.6.1. 不要輕易背棄你給自己定的目標，不要輕易拋棄屬于你曾經的王者榮耀
7. 技術
軟件測試小講堂
59
7.1. 功能測試
7.1.1. 功能測試是能用
7.1.2. 性能測試是好用
7.1.3. 自動化測試是快點用
7.1.4. 安全測試是放心用
7.2. 接口測試
7.2.1. 什么是接口
接口測試主要用于外部系統與系統之間以及內部各個子系統之間的交互點，定義特定的交互點，然后通過這些交互點
來，通過一些特殊的規則也就是協議，來進行數據之間的交互
7.2.2. 接口類型
程序內部的接口
方法與方法之間，模塊與模塊之間的交互，程序內部拋出的接口
系統對外的接口
軟件測試小講堂
60
接口
webservice 接口
webService 接口是走 soap 協議通過 http 傳輸，請求報文和返回報文都是 xml 格式的，我們在測試的時候都用通過工
具才能進行調用，測試。
http api 接口
http api 接口是走 http 協議，通過路徑來區分調用的方法，請求報文都是 key-value 形式的，返回報文一般都是 json
串，有 get 和 post 等方法，這也是最常用的兩種請求方式
7.2.3. 本質
接口你可以簡單的理解他就是 URL，工作原理就會說 URL 通過 get 或者 post 請求像服務器發送一些東西，然后得到一
些相應的返回值，本質就是數據的傳輸與接收
7.2.4. 接口測試定義
測試系統組件間接口的一種測試。接口測試主要用于檢測外部系統與系統之間以及內部各個子系統之間的交互點。測
試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等
7.2.5. 為什么做
軟件測試小講堂
61
越底層發現 bug，它的修復成本是越低的。
前端隨便變，接口測好了，后端不用變，前后端是兩撥人開發的。
檢查系統的安全性、穩定性，前端傳參不可信，比如京東購物，前端價格不可能傳入-1 元，但是通過接口可以傳入-
1 元。
如今的系統復雜度不斷上升，傳統的測試方法成本急劇增加且測試效率大幅下降，接口測試可以提供這種情況下的
解決方案。
接口測試相對容易實現自動化持續集成，且相對 UI 自動化也比較穩定，可以減少人工回歸測試人力成本與時間，縮短
測試周期，支持后端快速發版需求。接口持續集成是為什么能低成本高收益的根源。
現在很多系統前后端架構是分離的，從安全層面來說：
(1)、只依賴前端進行限制已經完全不能滿足系統的安全要求（繞過前面實在太容易）， 需要后端同樣進行
控制，在這種情況下就需要從接口層面進行驗證。
(2)、前后端傳輸、日志打印等信息是否加密傳輸也是需要驗證的，特別是涉及到用戶的隱私信息，如身份
證，銀行卡等。
7.2.6. 測試點
軟件測試小講堂
62
目的：測試接口的正確性和穩定性
原理：模擬客戶端向服務器發送請求報文，服務器接收請求報文后對相應的報文做處理并向客戶端返回應答，客戶端
接收應答的過程
重點：檢查數據的交換，傳遞和控制管理過程，還包括處理的次數
核心：持續集成是接口測試的核心；
優點：為高復雜性的平臺帶來高效的缺陷監測和質量監督能力，平臺越復雜，系統越龐大，接口測試的效果越明顯
（提高測試效率，提升用戶體驗，降低研發成本）
用例設計重點：通常情況下主要測試最外層的兩類接口:數據進入系統接口（調用外部系統的參數為本系統使用）和數
據流出系統接口（驗證系統處理后的數據是否正常）；
7.2.7. 標準
業務功能覆蓋是否完整
業務規則覆蓋是否完整
參數驗證是否達到要求（邊界、業務規則）
接口異常場景覆蓋是否完整
軟件測試小講堂
63
接口覆蓋率是否達到要求
代碼覆蓋率是否達到要求
性能指標是否滿足要求
安全指標是否滿足要求
7.2.8. 知識點
了解系統及內部各個組件之間的業務邏輯交互
了解接口的 I/O（input/output：輸入輸出）
協議的基本內容
通信原理
三次握手
常用的協議類型
報文構成
數據傳輸方式
軟件測試小講堂
64
常見的狀態碼
URL 構成等
7.2.9. 接口測試工具
jmeter
loadrunner
postman
soapUI
fiddler
python 自動化
7.2.10. 接口文檔要素
接口信息
接口調用方式，常用的 GET/POST 方式，接口地址
功能描述
軟件測試小講堂
65
簡潔清晰的描述接口功能，比如：接口獲取的信息不包括哪些
接口參數說明
每個參數都要和實際中調用的一樣，包括大小寫；參數的含義言簡意賅的說明，格式，是 string 還是 int 還是 long 等
格式
返回值說明
最好有一個模板返回值，并說明每個返回參數的意義；
提供一個真實的調用接口，真實的返回值；
調用限制，安全方面
加密方式，或者自己公司一個特殊的加密過程，只要雙方采用一致的加密算法就可以調用接口，保證了接口調用的
安全性，比如常見的 md5
文檔維護
文檔在維護的時候，如有修改一定要寫上修改日期，修改人，對大的修改要有版本號變更
7.3. 兼容測試
軟件測試小講堂
66
7.3.1. 網絡兼容性
弱網
斷網
有網無數據
7.3.2. 機型兼容性
系統兼容
分辨率兼容
屏幕兼容
7.3.3. 瀏覽器兼容
Trident（也稱 IE 內核）
webkit
Blink
Gecko
軟件測試小講堂
67
7.3.4. 新舊數據兼容性
數據類型轉換
數據格式變換
文件格式轉換
7.3.5. 軟件兼容性
軟件與軟件
軟件與硬件
7.4. 性能測試
7.4.1. 性能測試目的
驗證改進性能效果，需要和以前的測試結果進行比對；
新的業務上線，驗證新系統能夠滿足系統的上線指標。
驗證系統穩定性；
驗證系統的架構是否存在瓶頸。
軟件測試小講堂
68
7.4.2. 性能測試目標
1、 系統新上線、測試明確的數字標準對比情況下，驗證系統是否可以上線。測試系統的極限，如：系統某些資源已
經耗盡，CPU、句柄、內存、數據庫出現大量的 slow query、或者系統有些處理已經變量）或者證明系統能否根據硬件
水平擴展的。
2、 沒有可以比較的測試結果，但是產品已經上線一段時間（一般 3 個月以上），有一些運營數據，則分析運營數據
來作為比對基準，只要測試系統達到 3 個月內系統并發峰值的 4 倍就可以認為是可以接受的。（如果是接口為測試對
象，則需要混合主要的接口來進行性能測試）
3、 有以往測試結果進行對比，只要證明類似的測試條件下，此次的結果比以往的測試結果更好即可（每秒處理個數
更多、單次請求的處理速度更快等）
4、 開發人員提供經驗值作為對比的基準，則被測對象只需要證明滿足開發人員提出的經驗值。
7.4.3. 一般出現瓶頸點
硬件上的性能瓶頸
一般指的是 CPU、內存、磁盤 I/O 方面的問題，分為服務器硬件瓶頸、網絡瓶頸（對局域網可以不考慮）、服務器
操作系統瓶頸（參數配置）、中間件瓶頸（參數配置、數據庫、web 服務器等）、應用瓶頸（SQL 語句、數據庫設
計、業務邏輯、算法等）
軟件測試小講堂
69
應用軟件上的性能瓶頸
一般指的是應用服務器、web 服務器等應用軟件，還包括數據庫系統。
例如：中間件 weblogic 平臺上配置的 JDBC 連接池的參數設置不合理，造成的瓶頸。
應用程序上的性能瓶頸
一般指的是開發人員新開發出來的應用程序。
例如，程序架構規劃不合理，程序本身設計有問題（串行處理、請求的處理線程不夠），造成系統在大量用戶方位
時性能低下而造成的瓶頸。
操作系統上的性能瓶頸
一般指的 Linux 等操作系統，我們用的是 CentOS
例如，在進行性能測試，出現物理內存不足時，虛擬內存設置也不合理，虛擬內存的交換效率就會大大降低，從而
導致行為的響應時間大大增加，這時認為操作系統上出現性能瓶頸
網絡設備上的性能瓶頸
一般指的是防火墻、動態負載均衡器、交換機等設備。
軟件測試小講堂
70
例如，在動態負載均衡器上設置了動態分發負載的機制，當發現某個應用服務器上的硬件資源已經到達極限時，動
態負載均衡器將后續的交易請求發送到其他負載較輕的應用服務器上。在測試時發現，動態負載均衡器沒有起到相
應的作用，這時可以認為網絡瓶頸。
7.4.4. 性能測試原則
情況許可時，應使用幾種測試工具或手段分別獨立進行測試，并將結果相互印證，避免單一工具或測試手段自身缺陷
影響結果的準確性；
對于不同的系統，性能關注點是有所區別的，應該具體問題具體分析；
3）查找瓶頸的過程應由易到難逐步排查：
服務器硬件瓶頸及網絡瓶頸（局域網環境下可以不考慮網絡因素）
應用服務器及中間件操作系統瓶頸（數據庫、WEB 服務器等參數配置）
應用業務瓶頸（SQL 語句、數據庫設計、業務邏輯、算法、數據等）
性能調優過程中不宜對系統的各種參數進行隨意的改動，應該以用戶配置手冊中相關參數設置為基礎，逐步根據實際
現場環境進行優化，一次只對某個領域進行性能調優（例如對 CPU 的使用情況進行分析），并且每次只改動一個設
置，避免相關因素互相干擾；
軟件測試小講堂
71
調優過程中應仔細進行記錄，保留每一步的操作內容及結果，以便比較分析；
性能調優是一個經驗性的工作，需要多思考、分析、交流和積累；
了解“有限的資源，無限的需求”；
盡可能在開始前明確調優工作的終止標準。
7.4.5. 測試環境
一個穩定、可重復的測試環境，能夠保證測試結果的正確保證達到測試執行的技術需求保證得到正確的、可重復的以
及易理解的測試結果
生產環境
衡量的精準度較高，參考效果
更好，但是需要清理相關的測試數據（同時要保證數據刪除的完整性，基礎數據的構造參考后續數據量部分
）或者 BI 統計的時候過濾，或者是全鏈路壓測方式，生產環境的壓測盡量挑選在
低峰期進行，避免對生產業務造成影響
測試環境
軟件測試小講堂
72
風險可控，難點在環境的構建上，規模和生產一致的成本也是最高的，所以一般而言有通過等比構建（1/2，1/4，
1/8 等），甚至是生產環境中部分應用獨立部署測試集群，數據庫共用的方式，此外測試環境需要從生產環境中導入
脫敏的基礎數據，比如至少是最近半年或者 1 年的，保持其整體的數據關聯性，這個對于壓測的準確度和參考性也
很重要。
搭建環境
測試環境架構與生產環境架構完全相同
測試環境機型與生產環境機型盡量相同，云化的資源確保是同規格 ECS 或者容器
測試環境軟件版本與生產環境軟件版本完全相同，版本主要包括：操作系統、中間件相關、數據庫、應用等
測試環境參數配置與生產環境完全相同，參數主要包括：操作系統參數、中間件參數、數據庫參數、應用參數
測試環境基礎數據量與生產環境基礎數據量需在同一個數量級上。
只能減少測試環境機器臺數，并且需要同比例縮小，而不能只減少某一層的機器臺數。
理想的測試環境配置是生產環境的 1/2，1/4。
調研環境
系統架構：系統如何組成的，每一層功能是做什么的，與生產環境有多大差異，主要為后面進行瓶頸
軟件測試小講堂
73
分析服務和生產環境性能評估，這個很重要。
操作系統平臺：操作系統是哪種平臺，進行工具監控。
中間件：哪種中間件，進行工具監控和瓶頸定位。
數據庫：哪種數據庫，進行工具監控和瓶頸定位。
應用：啟動多少個實例，啟動參數是多少，進行問題查找和瓶頸定位。
7.4.6. 性能測試分類
負載測試
容量測試
壓力測試
基準測試
在給系統施加較低壓力時，查看系統的運行狀況并記錄相關數做為基礎參考
7.4.7. 測試指標
資源指標
軟件測試小講堂
74
CPU 資源利用率
CPU 指標主要指的 CPU 利用率，包括用戶態(user)、系統態(sys)、等待態(wait)、空閑態(idle)。CPU 利用率要低于業
界警戒值范圍之內，即小于或者等于 75%;CPU sys%小于或者等于 30%, CPU wait%小于或者等于 5%。單核 CPU 也需
遵循上述指標要求。CPU Load 要小于 CPU 核數。
。CPU Load: 系統正在干活的多少的度量，隊列長度。系統平均負載
內存利用率
現代的操作系統為了最大利用內存，在內存中存放了緩存，因此內存利用率 100%并不代表內存有瓶頸，衡量系統
內有有瓶頸主要靠 SWAP（與虛擬內存交換）交換空間利用率，一般情況下，SWAP 交換空間利用率要低于 70%,太
多的交換將會引起系統性能低下。
磁盤 I/O
指在無磁盤故障的情況下單位時間內通過磁盤的數據量
磁盤指標主要有每秒讀寫多少兆，磁盤繁忙率，磁盤隊列數，平均服務時間，平均等待時間，空間利用率。其中
磁盤繁忙率是直接反映磁盤是否有瓶頸的的重要依據，一般情況下，磁盤繁忙率要低于 70%。
網絡吞吐量
軟件測試小講堂
75
指在無網絡故障的情況下單位時間內通過的網絡的數據數量。單位為 Byte/s。網絡吞吐量指標用于衡量系統對于
網絡設備或鏈路傳輸能力的需求。當網絡吞吐量指標接近網絡設備或鏈路最大傳輸能力時，則需要考慮升級網絡
設備。
網絡吞吐量指標主要有每秒有多少兆流量進出，一般情況下不能超過設備或鏈路最大傳輸能力的 70%。
內核參數
應用指標
空閑線程數
數據庫連接數
GC/FULL GC 次數
函數耗時
前端指標
頁面加載時間
網絡時間
軟件測試小講堂
76
DNS
連接時間
傳輸時間等
業務指標
交易響應時間
指用戶從客戶端發起一個請求開始，到客戶端接收到從服務器端返回的響應結束，整個過程所耗費的時間（ms 毫
秒）
系統處理能力
是指系統在利用系統硬件平臺和軟件平臺進行信息處理的能力。系統處理能力通過系統每秒鐘能夠處理的交易數
量來評價
HPS（Hits Per Second） ：每秒點擊次數，單位是次/秒。
TPS（Transaction per Second）：系統每秒處理交易數，單位是筆/秒。
QPS（Query per Second）：系統每秒處理查詢次數，單位是次/秒。
軟件測試小講堂
77
對于互聯網業務中，如果某些業務有且僅有一個請求連接，那么 TPS=QPS=HPS，一般情況下用 TPS 來衡量整個業
務流程，用 QPS 來衡量接口查詢次數，用 HPS 來表示對服務器點擊請求
并發用戶數
指在同一時刻內，登錄系統并進行業務操作的用戶數量。并發用戶數對于長連接系統來說最大并發用戶數即是系
統的并發接入能力。對于短連接系統而言最大并發用戶數并不等于系統的并發接入能力，而是與系統架構、系統
處理能力等各種情況相關
錯誤率
指系統在負載情況下，失敗交易的概率。錯誤率＝(失敗交易數/交易總數)*100%。穩定性較好的系統，其錯誤率應
該由超時引起，即為超時率
中間件指標
數據庫指標
穩定性指標
最短穩定時間：系統按照最大容量的 80%或標準壓力（系統的預期日常壓力）情況下運行，能夠穩定運行的最短時
間。一般來說，對于正常工作日（8 小時）運行的系統，至少應該能保證系統穩定運行８小時以上。對于 7*24 運行
軟件測試小講堂
78
的系統，至少應該能夠保證系統穩定運行 24 小時以上。如果系統不能穩定的運行，上線后，隨著業務量的增長和長
時間運行，將會出現性能下降甚至崩潰的風險
批量處理指標
指批量處理程序單位時間內處理的數據數量。一般用每秒處理的數據量來衡量。處理效率是估算批量處理時間窗口
最重要的計算指標。關于批量處理時間窗口，不同系統的批量處理時間窗口在起止時間上可以部分重疊。另外，同
一系統內部，也可能存在多個批量處理過程同時進行，其時間窗口相互疊加。長時間批量處理將會對聯機在線實時
交易產生重大的性能影響。
可擴展性指標
指應用軟件或操作系統以群集方式部署，增加的硬件資源與增加的處理能力之間的關系。計算公式為：（增加性能/
原始性能）/（增加資源/原始資源）*100%。擴展能力應通過多輪測試獲得擴展指標的變化趨勢。一般擴展能力非常
好的應用系統，擴展指標應是線性或接近線性的，現在很多大規模的分布式系統的擴展能力非常好
標準
理想的擴展能力是資源增加幾倍，性能就提升幾倍。
擴展能力至少在 70%以上。
可靠性指標
軟件測試小講堂
79
雙機熱備
對于將雙機熱備作為可靠性保障手段的系統，可衡量的指標如下：
節點切換是否成功及其消耗時間
雙機切換是否有業務中斷
節點回切是否成功及其耗時
雙機回切是否有業務中斷
節點回切過程中的數據丟失量在進行雙機切換的同時，使用壓力發生工具模擬實際業務發生情況，對應用保持一
定的性能壓力，保證測試結果符合生產實際情況。
集群
集群中某個節點出現故障時，系統是否有業務中斷情況出現
在集群中新增一個節點時，是否需要重啟系統
當故障節點恢復后，加入集群，是否需要重啟系統
當故障節點恢復后，加入集群，系統是否有業務中斷情況出現
軟件測試小講堂
80
節點切換需要多長時間在驗證集群可靠性的同時，需根據具體情況使用壓力工具模擬實際業務發生相關情況，對
應用保持一定的性能壓力，確保測試結果符合生產實際情況。
備份和恢復
備份是否成功及其消耗時間
備份是否使用腳本自動化完成
恢復是否成功及其消耗時間
恢復是否使用腳本自動化完成指標體系的運用原則
指標項的采用和考察取決于對相應系統的測試目的和測試需求。被測系統不一樣，測試目的不一樣，測試需求也
不一樣，考察的指標項也有很大差別。
部分系統涉及額外的前端用戶接入能力的，需要考察用戶接入并發能力指標。
對于批量處理過程的性能驗證，主要考慮批量處理效率并估算批量處理時間窗口。
如測試目標涉及到系統性能容量，測試需求中應根據相關指標項的定義，明確描述性能指標需求。
測試指標獲取后，需說明相關的前提條件（如在多少的業務量、系統資源情況等）。
軟件測試小講堂
81
7.5. 自動化測試
7.5.1. 接口自動化
7.5.2. UI 自動化
7.5.3. 機械自動化
7.5.4. 前提條件
需求變動不頻繁
測試腳本的穩定性決定了自動化測試的維護成本。如果軟件需求變動過于頻繁，測試人員需要根據變動的需求來更
新測試用例以及相關的測試腳本，而腳本的維護本身就是一個代碼開發的過程，需要修改、調試，必要的時候還要
修改自動化測試的框架，如果所花費的成本不低于利用其節省的測試成本，那么自動化測試便是失敗的
項目周期足夠長
自動化測試需求的確定、自動化測試框架的設計、測試腳本的編寫與調試均需要相當長的時間來完成，這樣的過程
本身就是一個測試軟件的開發過程，需要較長的時間來完成。如果項目的周期比較短，沒有足夠的時間去支持這樣
一個過程，那么自動化測試便不成立
自動化測試腳本可重復使用
軟件測試小講堂
82
7.6. 白盒測試
7.7. 安全測試
7.7.1. 失效的身份驗證機制
只對首次傳遞的 Cookie 加以驗證，程序沒有持續對 Cookie 中內含信息驗證比對，攻擊者可以修改 Cookie 中的重要信
息以提升權限進行網站數據存取或是冒用他人賬號取得個人私密資料（測試對象：可以進行傳參的 URL，提交請求頁
面，登錄后的 Cookie）
7.7.2. 會話管理劫持
檢測 Web 應用程序會話機制是否存在安全隱患，能否被非法利用（會話劫持，偽裝成合法用戶）而影響 Web 應用程
序的安全。
7.7.3. SQL 注入
注入攻擊漏洞,這些攻擊發生在當不可信的 SQL 語句作為命令或者查詢語句的一部分,被發送給解釋器的時候。攻擊者
發送的惡意數據可以欺騙解釋器,以執行計劃外的命令或者在未被恰當授權時訪問數據。
7.7.4. XPath 注入
軟件測試小講堂
83
XPath 注入攻擊是指利用 XPath 解析器的松散輸入和容錯特性，能夠在 URL、表單或其它信息上附帶惡意的 XPath 查詢
代碼，以獲得權限信息的訪問權并更改這些信息。XPath 注入攻擊是針對 Web 服務應用新的攻擊方法，它允許攻擊者
在事先不知道 XPath 查詢相關知識的情況下，通過 XPath 查詢得到一個 XML 文檔的完整內容。
7.7.5. XSS 跨站腳本攻擊
惡意攻擊者往 Web 頁面里插入惡意 html 代碼，當用戶瀏覽該頁之時，嵌入其中 Web 里面的 html 代碼會被執行，從
而達到惡意用戶的特殊目的。
7.7.6. CSRF 跨站請求偽造
攻擊者通過調用第三方網站的惡意腳本來偽造請求，在用戶不知情的情況下，攻擊者強行遞交構造的具有“操作行為”
的數據包。（測試對象：網頁中可進行輸入的表單）
7.7.7. 不安全的直接對象引用
在具有導出/下載功能的頁面參數中修改內容，WEB 服務器便會導出/下載程序源代碼或者指定文件（測試對象：URL
中有用戶參數的地址，可以進行下載操作的地址）或者當開發人員暴露一個對內部實現對象的引用時,例如,一個文件、
目錄或者數據庫密匙, 就會產生一個不安全的直接對象引用。在沒有訪問控制檢測或其他保護時,攻擊者會操控這些引
用去訪問未授權數據
7.7.8. 安全配置錯誤
軟件測試小講堂
84
Config 中的鏈接字符串以及用戶信息，郵件，數據存儲信息等都需要加以保護，如果沒有進行保護，那么就是安全配
置出現了問題。
7.7.9. 不安全的加密存儲
未對需要保護的數據進行加密或者加密算法太弱都是不安全的加密存儲
7.7.10. 沒有限制 URL 訪問
系統已經對 URL 的訪問做了限制，但這種限制卻實際并沒有生效。攻擊者能夠很容易的就偽造請求直接訪問未被授權
的頁面（測試對象：需要身份驗證的頁面）
7.7.11. 傳輸層保護不足
在身份驗證過程中沒有使用 SSL/TLS，因此暴露傳輸數據和會話 ID，被攻擊者截聽。它們有時還會使用過期或者配置不
正確的證書。（測試對象：登錄模塊）
7.7.12. 未驗證的重定向
（redirectUrl）和轉發 攻擊者可以引導用戶訪問他們所要用戶訪問的站點。而最終造成的后果，重定向會使得用戶訪
問釣魚網站或是惡意網站。
7.7.13. 敏感信息泄露
軟件測試小講堂
85
許多 Web 應用程序沒有正確保護敏感數據,如信用卡、稅務 ID 和身份驗證憑據。攻擊者可能會竊取或篡改這些弱保護
的數據以進行信用卡詐騙、身份竊取或其他犯罪。敏感數據值需額外的保護,比如在存放或在傳輸過程中的加密,以及在
與瀏覽器交換時進行特殊的預防措施。
7.7.14. 功能級訪問控制缺失
大多數 Web 應用程序的功能在 UI 頁面顯示之前,會驗證功能級別的訪問權限。但是,應用程序需要在每個功能被訪問時
在服務器端執行相同的訪問控制檢查。如果請求沒有被驗證,攻擊者能夠偽造請求從而在未經適當授權時訪問功能。
7.7.15. 使用含有已知漏洞的組件
組件,比如:庫文件、框架和其他軟件模塊,幾乎總是以全部的權限運行。如果使用含有已知漏洞的組件,這種攻擊可以造
成更為嚴重的數據丟失或服務器接管。應用程序使用帶有已知漏洞的組件會破壞應用程序防御系統,并使一系列可能的
攻擊和影響成為可能。危害比較嚴重
7.7.16. 緩沖區溢出
當計算機向緩沖區內填充數據位數時超過了緩沖區本身的容量，溢出的數據覆蓋在合法數據上。
7.7.17. LDAP 注入
軟件測試小講堂
86
利用 LDAP 注入技術的關鍵在于控制用于目錄搜索服務的過濾器。使用這些技術，攻擊者可能直接訪問 LDAP 目錄樹下
的數據庫，及重要的公司信息。情況還可能比這更嚴重，因為許多應用的安全性依賴于基于 LDAP 目錄的單點登錄環
境。
7.7.18. 篡改輸入
利用一些命令或者工具等篡改一些字段的值，從而達到惡意的效果。例如，篡改商品的單價和數量等。
7.8. 大數據測試
7.8.1. 大數據是指無法在一定時間范圍內用傳統的計算機技術進行處理的海量數據集
7.8.2. 特性
大批量
實時性
可交互
7.8.3. 功能測試步驟
數據預處理驗證
軟件測試小講堂
87
我們數據來源可能是關系數據庫、日志系統、社交網絡等等，所以我們應該確保數據能正確的加載到系統中
我們要驗證加載的數據和源數據是一致的
我們要確保正確的提取和加載數據至 hdfs 中
Map Reduce 編程模型驗證
Map Reduce 過程工作正常
數據聚合、分離規則已經實現
數據 key-value 關系已正確生成
驗證經過 map reduce 后數據的準確性等特性
結果驗證
驗證數據轉換規則是否正確應用
驗證數據的完整性和是否成功持久化到目標系統
驗證無數據損壞
7.8.4. 非功能測試步驟
軟件測試小講堂
88
性能測試
性能是評估一個大數據分析系統的最為關鍵的維度，大數據系統性能主要包括吞吐量，任務完工時間，內存利用率
等多個指標，可反應大數據分析平臺的處理能力，資源利用能力等性能。可通過 hadoop 性能監控器來監測運行狀態
性能指標和瓶頸問題，性能測試采用自動化化方式進行，測試系統在不同負載情況下的性能
容錯性測試
可從部分失效中自動恢復，而且不會驗證的影響整體性能，特別地，當故障發生時，大數據分析系統應該在進行恢
復的同時繼續以可接受的方式進行操作，在發生錯誤時某種程度上可以繼續操作，需根據應用場景來設計解決方案
和具體部署，然后手動測試
可用性測試
高可用性已是大數據分析不可或缺的特性之一，從而保證數據應用業務的連續性.大數據高可用性對很多應用非常關
鍵，需要嚴格進行測試和驗證，以手動測試為主
擴展性測試
彈性擴展能力對于大數據時代的文件系統尤其重要，文件系統擴展性測試主要包括測試系統彈性擴展能力(擴展/回
縮)及擴展系統帶來的性能影響，驗證是否具有線性擴展能力,以手動測試為主
穩定性測試
軟件測試小講堂
89
大數據分析系統通常是不間斷長期運行，穩定性的重要性不言而喻，穩定測試主要驗證系統在長時間
(7/30/180/365*24)允許下，系統是否仍然能夠正常運行，功能是否正常.穩定性測試通常采用自動化方式進行，LTP，
10ZONE，POSTMARK,FIO 等工具對測試系統產生負載，同時需要驗證功能.
部署方式測試
大數據具備 scale-out 的特點，能夠構建大規模，高性能的文件系統集群。針對不同應用和解決方案，文件系統部署
方式會有顯著不同；部署方式測試需要測試不同場景下的系統部署方式，包括自動安裝配置，集群規模，硬件配置
(服務器,存儲，網絡),自動負載均衡等，這部分測試不大可能進行自動化測試，需要根據應用場景來設計解決方案和
具體部署，再進行手動測試
數據一致性測試
這里的數據一致性是指文件系統中的數據與從外部寫入前的數據保持一致，即寫入數據與讀出數據始終是一致的.數
據一致性能夠表明文件系統可保證數據的完整性，不會導致數據丟失或數據錯誤，這是文件系統最基本的功能，測
試可用 diff,md5sum 編寫腳本自動化測試，LTP 也提供了數據一致性的測試工具
壓力測試
大數據分析系統的負載能力是存在上限的，系統過載時，系統就可能存在性能下降，功能異常，拒絕訪問等問題。
壓力測試是驗證系統造大壓力下，包括數據多客戶端，高 OPS 壓力，高 IOPS/吞吐量壓力，系統是否仍然能夠正常
運行，功能是否正常，系統資源消耗情況，從而為大數據運營提供依據
軟件測試小講堂
90
7.8.5. 數據格式
結構化數據
這指的是高度組織的數據。
密碼、電子郵件、電話號碼
它可以輕松地存儲在任何關系數據庫中。
這也意味著可以使用簡單的查詢輕松地檢索/搜索它
半結構化數據
半結構化數據并不是嚴格按照一種便于訪問和搜索的格式組織的。
CSV、XML 和 JavaScript 對象表示法(JSON
半結構化數據通常不存儲在關系數據庫中。
但是，經過一些處理后，它們可以存儲在關系數據庫中，并轉換為結構化格式。
半結構化數據介于結構化和非結構化數據之間。
它們可以包含標簽和其他元數據來實現層次結構和順序。
軟件測試小講堂
91
在半結構化數據中，相同類型的實體可能具有不同順序的不同屬性
非結構化數據
非結構化數據沒有任何預定義的格式。
圖片、視頻、word 文檔、演示文稿、mp3 文件等
它不遵循結構化數據模型。
它沒有組織成預定義的結構。
圖像、視頻、word 文檔、mp3 文件可以被視為非結構化數據，即使它們有一個內部結構
這種結構的缺乏使得從關系數據庫中存儲和檢索這樣的數據變得很困難
在一個組織中產生的多達 80%的數據是非結構化數據
7.9. 流媒體測試
7.9.1. 業務測試
1.測試對流媒體點播，終端提供播放、暫停、繼續、停止、退出操作
2.測試對流媒體點播，終端提供定位播放（即快進、后退）操作
軟件測試小講堂
92
3.測試對流媒體點播，終端提供音量控制和靜音操作操作
4.測試對流媒體直播，終端提供播放、停止、退出、音量控制和靜音操作
5.測試對于視頻下載，終端提供本地回放功能（包括：播放、暫停、繼續、停止、退出、定位播放、音量控制和靜音
操作。
6.測試對于流媒體播放過程中，若當前速率不能滿足流媒體播放時，終端應自動暫停播放并對流媒體內容進行緩存，
在收到足夠信息后繼續播放
7.測試流媒體播放結束后，終端不能保存流媒體文件的部分或者全部的內容，并且播放器的緩存不可以被訪問，視頻
下載的文件可以保存在終端
8.測試如果終端支持所選媒體格式，終端應給出相應的提示，有用戶選擇是否繼續播放其中可支持部分
9.測試在流媒體直播、點播和視頻下載過程中，如果突然出現關機情況，是否正常響應
10.測試在流媒體直播、點播和視頻下載過程中，如果應用程序出現異常，是否正常響應
11.測試在流媒體直播、點播和視頻下載過程中，如果瀏覽器出現異常，是否正常響應
12.測試在流媒體直播、點播和視頻下載過程中，如果網絡出現異常，是否正常響應
13.測試在流媒體終端收到視頻圖像的尺寸如果大于播放器屏幕尺寸時，播放器是否正常響應
軟件測試小講堂
93
14.測試在流媒體終端收到視頻圖像的尺寸如果大于播放器屏幕尺寸時，播放器是否正常響應
15.流媒體窗口全屏和正常之間的切換是否能夠實現
16.測試上傳文件最大值
17.測試上傳文件是否支持中文名稱
18.測試刪除上傳成功的文件
19.測試文件名稱的最大值、最小值
20.測試文件名稱是否支持特殊字符(包括空格)
21.測試上傳過程斷網，等網絡恢復后，是否支持斷點續傳
22.測試上傳時網速很慢
23.測試上傳文件支持的格式
24.測試增加部分功能后系統運行是否正常
25.測試刪除部分功能后系統運行是否正常
26.測試缺陷修改后系統運行是否正常
軟件測試小講堂
94
27.流媒體的播放窗口是否可以單獨從瀏覽器窗口中拖拽出來
28.內存不足時，是否有相應的內存不足的提示
29.當前瀏覽器最小化后，是否停止流媒體的下載過程以節約網絡資源
30.在流媒體的播放定位過程中，是否能夠出現一個小的視頻窗口，以便用戶確認定位位置
31.流媒體播放過程中是否有記憶功能，以便中斷恢復或下次打開后，從上次瀏覽處繼續查看
7.9.2. 性能測試
碼率
指數據傳輸時單位時間傳送的數據位數，單位為 kbps。碼率的大小決定視頻文件的清晰度、流暢度和大小。碼率越
高，畫質越好，文件也越大
幀率
幀率用于測量顯示幀數的量度，單位為每秒顯示幀數（FPS）。高的幀率可以得到更流暢、更逼真的動畫。FPS 越
多，顯示的動作就會越流暢。一般來說 60FPS 可以明顯提升動畫的交互感和逼真感，超過 75FPS 流暢度則不會有明
顯的提升
丟包率
軟件測試小講堂
95
丟包是網絡中數據傳輸的時候出現數據丟失的現象，丟包率是指丟包數據占總傳輸數據的百分比。網絡丟包率越
高，網速越慢，一般丟包率小于 1%屬于正常
平均下載速度
指播放器播放視頻過程中下載視頻資源的速度。平均下載速度=總下載字節數/吞吐用時。建議值：優秀 >180 KB/s，
一般 >70 KB/s，差 ≤ 70KB/s
視頻首包用時
從獲取視頻真實地址到獲取視頻資源第一包之間的時間間隔。建議值：優秀 ≤1s，一般 ≤2.5s，差 >2.5s
視頻首幀用時
從獲取視頻真實地址到開始播放視頻第一幀之間的時間間隔。其中視頻秒開指的是視頻頁面首屏在 1s 左右快速的展
現出來，視頻秒開直接影響著用戶體驗
頁面首屏用時
從開始瀏覽到頁面被渲染出指定高度范圍之間的時間間隔。參考值：優秀 ≤3.5s，一般 ≤7s，差 >7s。
卡頓時間
軟件測試小講堂
96
指視頻在開始播放后出現的卡頓（緩沖）狀態的累計時長（首次緩沖不計算在內）卡頓時間=總緩沖用時-首次緩沖
用時。參考值：優秀 ≤ 6s，一般 ≤12s，差 >12s
St-load
7.10. WEB 測試
7.10.1. 功能測試
跳轉測試
頁面是否有無法連接的內容
頁面是否存死鏈接
圖片是否能正確顯示
視頻是否能夠正常播放
是否有無用的鏈接
圖片鏈接
點擊圖片上的鏈接是否跳轉到正確的頁面
軟件測試小講堂
97
文字鏈接
點擊文字上的鏈接是否跳轉到正確的頁面
點擊文章標題的鏈接
是否可進入相應的文章的詳細頁面
一側導航鏈接
是否可按欄目級別跳轉到相應的頁面
點擊鏈接本身
是否在另一側重新加載相應頁面
表單測試
注冊、登錄功能
能夠正常注冊、登錄
密碼顯示密文
注冊成功、登錄成功有相應的跳轉流程
軟件測試小講堂
98
提交、清空按鈕
能夠正常提交數據
輸入內容與輸出內容保持一致
能夠正常清空當前輸入
再次輸入后提交的輸出內容與輸入內容保持一致
提交的數據是否能正確保存到后臺數據庫中（后臺數據庫中的數據應與前臺錄入內容完全一致，數據不會丟失或被
改變）
表單提交，刪除，修改后是否有提示信息
toast 提示
提示后自動消失
彈框提示
提示后可以手動關閉
提示后可以自動關閉
軟件測試小講堂
99
跳轉提示
跳轉頁面正常
瀏覽器的前進、后退、刷新按鈕，是否會造成數據重現或頁面報錯
提交表單是否支持回車鍵和 Tab 鍵；Tab 鍵的順序與控件排列順序要一致，目前流行總體從上倒下，同時行間從左
到右的方式
下拉列表功能是否實現和數據是否完整
省市區匹配一致
年月日時分秒（大月，小月，尤其是 2 月份的天數）匹配一致
24 小時 12 小時制
表單提交數據的完整性校驗
輸入測試
對于手機、郵箱、證件號等的輸入是否有長度及類型的控制
輸入 html 語言的<head>，是否能正確顯示
軟件測試小講堂
100
是否有必填項的控制
不輸入提交數據時有明顯示提示信息
非必填項與必填項有明確的標識區分
輸入控制
輸入超長字段，頁面是否被撐開
分別輸入大于、等于、小于數據表規定字段長度的數據，是否報錯
輸入中文、英文、數字、特殊字符（特別注意單引號和反斜杠）,enjoy 符號及這五類的混合輸入，是否會報錯
輸入全角、半角的英文、數字、特殊字符等，是否報錯
輸入空格、空格+數據、數據+空格，是否報錯
人名輸入框對小數民族名字的支持（中間點）
輸入非數據表中規定的數據類型的字符，是否有友好提示信息
在文本框中輸入回車鍵，顯示時是否回車換行
非法的輸入或操作應有足夠的提示說明
軟件測試小講堂
101
驗證輸入輸出信息的一致性
輸入框前面的文字提示是否正確
日期控件開始時間和結束時間的邏輯校驗，開始時間必須小于等于結束時間
分頁測試
當沒有數據時，首頁、上一頁、下一頁、尾頁標簽均不可點擊，不可觸發點擊結果和效果
在首頁時，“首頁”“上一頁”標簽置灰；在尾頁時，“下一頁”“尾頁”標簽置灰；在中間頁時，四個標簽均可點擊，且跳
轉正確；
翻頁后，列表中的數據仍按照指定的順序進行了排序；
顯示控制
各個頁面的分頁標簽樣式一致；
是否支持回車鍵的監聽
分頁的總頁數及當前頁數顯示正確；
分頁控制
軟件測試小講堂
102
各個分頁標簽是同一水平線上；
在分頁處輸入非數字的字符（英文、特殊字符等），輸入 0 或超出總頁數的數字，是否有友好提示信息；
能正確跳轉到指定的頁數；
搜索測試
搜索按鈕功能是否實現；
輸入網站中存在的信息，能否正確搜索出結果；
輸入鍵盤中所有特殊字符，是否報錯；特別關注：_？’.?\/--；特殊字符
系統是否支持鍵盤回車鍵、Tab 鍵；
搜索出的結果頁面是否與其他頁面風格一致；
在輸入域輸入空格，點擊搜索系統是否報錯；
本站內搜索輸入域中不輸入任何內容，是否搜索出的是全部信息或者給予提示信息；
精確查詢還是模糊查詢，如果是模糊查詢輸入：中%國。查詢結果是不是都包含中國兩個字的信息；
焦點放置搜索框中，搜索框內容是否被清空；
軟件測試小講堂
103
搜索輸入域是否實現回車鍵監聽事件。
交互性數據測試
前臺的數據操作是否對后臺產生相應正確的影響（如：查看詳細信息時，需扣除用戶相應的授權點數）；
可實現前后臺數據的交互（如：在線咨詢，能否實現數據的交互實時更新）；數據傳遞是否正確；前后臺大數據量
信息傳遞數據是否丟失（如 500 個字符）；多用戶交流時用戶信息控制是否嚴謹；
用戶的權限，是否隨著授權而變化；
數據未審核時，前臺應不顯示；審核通過后，前臺應可顯示該條數據；
小并發連點測試
提交按鈕
連續點擊只能生成一次記錄
后臺接口校驗
前端增加防連點，但同時需考慮用戶體驗
注冊按鈕
軟件測試小講堂
104
同一賬號只能注冊成功一條數據
后臺校驗后進行接口攔截
前端增加防連點操作
7.10.2. 用戶界面體驗測試
圖形測試
要確保圖形有明確的用途，圖片不堆在一起，可以正常顯示，不會出現裂圖
驗證所有頁面字體的風格是否一致.
背景顏色與字體顏色和背景色相搭配.
圖片的大小和質量，清晰，容量越小越好.
各類型的圖片、視頻可以上傳，下載，播放，展示
界面體驗測試
界面圖標
風格一致
軟件測試小講堂
105
背景（顏色，圖片）一致。
操作習慣一致
各個界面布局是否合理：控件，文字，線條位置，數量，顏色是否合理，跟整體風格是否搭配。
界面文字是否有錯別字。各界面文字大小，顏色，位置是否一致。比如：標題文字
圖片
清晰度展示
不可出現模糊效果
大小展示符合設計
注意邊距
各個界面同種圖標是否一致
各種提示框風格是否一致。
提示語是否友好，簡明。
列表型界面是否有上上滑動效果。
軟件測試小講堂
106
功能入口明顯，易找（布局突出主要功能，用戶要找到某個功能很快就能功能，操作簡單）。
UI 界面測試要點
標題欄
檢查標題欄文字描述的正確性。
比較各個界面的標題欄效果是否一致。
文字
文字是否有錯別字。
檢查文字描述正確性。（跟軟件功能相符）
文字的顏色，大小，位置符合 UI 設計效果
文字用語一致。功能相同的地方，檢查使用的文字是否符合產品原型
控件
控件對齊了沒有。
并排關系控件－－左右對齊
軟件測試小講堂
107
同行關系控件－－橫向對齊
控件狀態：選中，未選中，可用，不可用
日期控件
設置完成后提交數據
查看接口輸入輸出數據是否保持一致
頁面布局檢查
字體、顏色、風格是否符合設計標準；
頁面的排版、格式是否美觀一致，是否符合一般操作習慣；
不同的瀏覽器中，顯示效果是否符合設計要求。（需要在需求文檔、測試用例文檔 中，明確支持哪些瀏覽器。如：
某些用戶只需支持 IE7,IE8，有些用戶需支持 IE6-IE8 及 FIREFOX）；
不同分辨率下，顯示效果是否符合設計要求。（如果項目中有分辨率的要求）； 頁面在窗口變化時顯示是否正確、
美觀（在調整瀏覽器窗口大小時，屏幕刷新是否 正確）；
頁面特殊效果顯示是否正確，各個頁面的鏈接情況是否準確，頁面元素是否存在容 錯性。
軟件測試小講堂
108
7.10.3. WEB 兼容性測試
操作系統/平臺兼容性測試
常見的操作系統有 Windows,Unix,Linux 等。
最常用的是 Windows 操作系統。
在確保主流操作系統版本兼容性測試通過的前提下，再對非主流操作系統版本進行測試，盡量保證項目的操作系統
的兼容性測試的
不同瀏覽器之間的兼容性測試
常用的瀏覽器有谷歌、火狐、IE、360 瀏覽器等，
這些瀏覽器同樣存在各個版本。在確保主流瀏覽器的兼容性測試通過的前提下，在對非主流瀏覽器（含版本）進行
測試
盡量保證項目的瀏覽器的兼容性測試的完整性。
分辨率兼容性測試
對于需求規格說明書中規定的分辨率，測試必須保證測試通過
軟件測試小講堂
109
于需求規格說明書中沒有規定分辨率的項目，測試應該在完成主流分辨率的兼容性測試的前提下，盡可能進行一些
非主流分辨率的兼容性測試，在一定程度上保證大部分的分辨率顯示正常
網絡兼容性測試
斷網
提交按鈕和各類功能按鈕保持數據靜止
增加必要的提示
斷網下的數據修改
網絡恢復后提交
應保證數據為最后修改的數據
弱網
增加接口超時回饋
數據保持原子性
提交數據保持整體有效
軟件測試小講堂
110
防止出現重復提交
7.10.4. 安全測試
用戶權限測試
用戶權限控制
用戶權限控制主要是對一些有權限控制的功能進行驗證
用戶 A 才能進行的操作，B 是否能夠進行操作（可通過竄 session，將在下面介紹）
只能有 A 條件的用戶才能查看的頁面，是否 B 能夠查看
直接敲 URL 訪問時是否被攔截
頁面權限控制
必須有登陸權限的頁面，是否能夠在不登陸情況下進行訪問
必須經過 A——B——C 的頁面，是否能夠直接由 A——C？
URL 安全測試
URL 參數檢查
軟件測試小講堂
111
對 URL 中參數信息檢查是否正確
如：URL 中的訂單號、金額允許顯示出來的話，需要驗證其是否正確
對于一些重要的參數信息，不應該在 URL 中顯示出來
如：用戶登陸時登錄名、密碼是否被明文顯示出來了 ，
Session 測試
Session 互竄
用戶 A 的操作被用戶 B 執行了。
驗證 Session 互竄，其原理還是基于權限控制，如某筆訂單只能是 A 進行操作，或者只能是 A 才能看到的頁面，
但是 B 的 session 竄進來卻能夠獲得 A 的訂單詳情等。
Session 互竄測試方法：
多 TAB 瀏覽器，在兩個 TAB 頁中都保留的是用戶 A 的 session 記錄，然后在其中一個 TAB 頁執行退出操作，登陸
用戶 B，此時兩個 TAB 頁都是 B 的 session，然后在另一個 A 的頁面執行操作，查看是否能成功。預期結果：有
權限控制的操作，B 不能執行 A 頁面的操作，應該報錯，沒有權限控制的操作，B 執行了 A 頁面操作后，數據記
錄是 B 的而不是 A 的
軟件測試小講堂
112
Session 超時
基于 Session 原理，需要驗證系統 session 是否有超時機制，還需要驗證 session 超時后功能是否還能繼續走下去
測試方法：
打開一個頁面，等著 10 分鐘 session 超時時間到了，然后對頁面進行操作，查看效果。
多 TAB 瀏覽器，在兩個 TAB 頁中都保留的是用戶 A 的 session 記錄，然后在其中一個 TAB 頁執行退出操作，馬
上在另外一個頁面進行要驗證的操作，查看是能繼續到下一步還是到登錄頁面。
接口安全檢查
證書對接
數據泄漏
7.10.5. 接口測試
模塊接口測試
它主要測試模塊的調用與返回
檢查接口返回的數據是否與預期結果一致。
軟件測試小講堂
113
檢查接口的容錯性，假如傳遞數據的類型錯誤時是否可以處理。例如支持整數，傳遞的是小數或字符串
接口參數的邊界值。例如，傳遞的參數足夠大或為負數時，接口是否可以正常處理。
接口的性能，接口處理數據的時間也是測試的一個方法。牽扯到內部就是算法與代碼的優化。
接口的安全性，如果是外部接口的話，這點尤為重要。
web 接口測試
服務器接口測試
是測試瀏覽器與服務器的接口
外部接口測試
第三方登錄
請求是否正確，默認請求成功是 200，如果請求錯誤也能返回 404、500 等。
檢查返回數據的正確性與格式；json 是一種非常創建的格式。
接口的安全性
鑒權
軟件測試小講堂
114
認證
第三方調用
解密
接口性能
返回時延
上傳超時
7.11. 移動端測試
7.11.1. 兼容測試
機型兼容性
系統兼容
android
大版本升級
IOS
軟件測試小講堂
115
大版本升級
HarmonyOS
其他系統
分辨率兼容
高分辨率
低分辨率
屏幕兼容
劉海屏
水滴屏
開孔屏
全面屏
非常規寬高比屏
新舊數據兼容性
軟件測試小講堂
116
接口傳參新舊版本兼容
新口返回的新舊版本兼容
網絡兼容性
弱網
接口重加載
斷網
友好頁面提示
續網自動重連
有網無數據
網絡切換
wifi 切換到移動數據
有數據提示
移動數據切換到 wifi 數據
軟件測試小講堂
117
無數據提示
有網切換到無網
緩存
停止加載
友好頁面提示
無網切換到有網
恢復正常
圖形兼容
不同格式的圖片顯示
不同格式的視頻播放
加載時長控制在允許范圍內
人機接口測試
返回鍵保持可用
軟件測試小講堂
118
不可屏蔽設備物理按鍵功能
7.11.2. 性能測試
CPU
查看 CPU 占用率
使用命令 adb shell top -m 10 -s cpu（-t 顯示進程名稱，-s 按指定行排序，-n 在退出前刷新幾次，-d 刷新間隔，-m
顯示最大數量）
通過 proc 獲取 CPU 信息
adb shell cat /proc/stat | grep cpu > totalcpu0
Android Studio 自帶 CPU 檢測功能
內存
adb shell dumpsys meminfo 或 adb shell dumpsys meminfo
Android Studio 中對應進程的 Heap
內存泄露工具 LeakCanary
軟件測試小講堂
119
電量
電量的測試方法
adb shell dumpsys batterystats
初始化 batterystats 數據
adb shell dumpsys batterystats --reset
上面的操作執行完畢后，拔掉手機，操作你的 App，操作完成后，重新連接手機，執行下面的命令，收集 Battery
數據:
adb shell dumpsys batterystats > batterystats.txt
dumpsys batterystats
命令里面會輸出各個應用的耗電情況，但該命令對手機的系統版本有要求，且應用內使用時需要有 root 權限。
流暢度測試
Android Studio 自帶 GPU 測試功能
FPS Meter
軟件測試小講堂
120
系統自帶功能，GPU 呈現模式分析
7.11.3. 數據安全測試
敏感信息加密
接口采用加密傳輸，不可被攔截，不可被抓取
身份證、手機號采用半覆蓋展示
反編譯
安裝包具備加殼加固，不可被反編譯，可使用反編譯工具，解殼工具
APP 前端不可以出現代碼類數據提示，以防數據泄漏
手動設置手機的時區和時間，檢查接口校驗
尤其是在一些活動中
按鈕的 enable 屬性與時間掛鉤時，要注意使用服務器時間
7.11.4. push 測試
開關機
軟件測試小講堂
121
關機情況下推送，開機后可以收到
APP 活動或進程死亡
殺死 APP 且禁止后臺運行，啟動 APP 后可以收到
網絡斷開及接續
網絡斷開情況下推送，恢復網絡后可以收到
通知權限
開啟后可以收到 push 推送
關閉后，按系統行為收到或不通知
7.11.5. 權限測試
存儲權限
開
關
網絡權限
軟件測試小講堂
122
是否允許網絡
是否允許移動網絡
移動網絡時，對于大流量數據交換是否有相應的提示
定位權限
默認地圖中展示位置正確
關閉定位權限
僅一次使用
在 APP 內使用
始終允許使用
先允許后關閉
關閉定位后的緩存位置使用
通信權限
涉及到的隱私協議相關說明
軟件測試小講堂
123
不同意時不影響 APP 功能的正常使用
同意時需要拿到相應的手機信息
錄音權限
不同意
不能啟動相應的錄音功能
不能展示錄音權限開啟時才能展示的頁面
同意
錄音功能正常使用
個別機型需要注意狀態欄里的錄音提示圖標
相機權限
關
正確提示用戶無法使用相機
個別機型讀取相冊功能
軟件測試小講堂
124
開
照片、錄像的清晰度
可以使用相冊
通訊錄權限
默認為關
關閉
不能讀取通訊錄
開啟
通讀錄可讀
剪切板權限
7.11.6. 傳感器測試
光敏感應器
軟件測試小講堂
125
通常用于調節屏幕自動背光的亮度，白天提高屏幕亮度，夜晚降低屏幕亮度，使得屏幕看得更清楚，并且不刺眼。
也可用于拍照時自動白平衡。還可以配合下面的距離傳感器檢測手機是否在口袋里防止誤觸。
視頻亮度的自動調整
直播亮度的自動計整
AI 識別時的智能增強
距離傳感器
檢測手機是否貼在耳朵上正在打電話，以便自動熄滅屏幕達到省電的目的。也可用于皮套、口袋模式下自動實現解
鎖與鎖屏動作
視頻播放類的距離檢測的自動暫停與播放
AI 識別類的體位校正提示（一般通過語音提示）
陀螺儀
體感、搖一搖（晃動手機實現一些功能）、平移/轉動/移動手機可在游戲中控制視角、VR 虛擬現實、在 GPS 沒有信
號時（如隧道中）根據物體運動狀態實現慣性導航
重力感應器
軟件測試小講堂
126
手機橫豎屏智能切換、拍照照片朝向、重力感應類游戲
全屏半屏的自動切換
磁場傳感器
指南針、地圖導航方向、金屬探測器 APP
加速度傳感器
計步、手機擺放位置朝向角度
GPS
地圖、導航、測速、測距
指紋傳感器
加密、解鎖、支付
霍爾感應器
翻蓋自動解鎖、合蓋自動鎖屏
氣壓傳感器
軟件測試小講堂
127
GPS 計算海拔會有十米左右的誤差，氣壓傳感器主要用于修正海拔誤差（將至 1 米左右），當然也能用來輔助 GPS
定位立交橋或樓層位置
心率傳感器
運動、健康
血氧傳感器
運動、健康
紫外線傳感器
運動、健康
7.11.7. 交互測試
人機操作交互（系統級交互）
APP 切換到后臺，再回到 app，檢查是否停留在上一次操作界面。
APP 切換到后臺，再回到 app，檢查功能及應用狀態是否正常、
軟件測試小講堂
128
App 切換到后臺，再回到前臺時，注意程序是否崩潰，功能狀態是否正常，尤其是對于從后臺切換回前臺數據有自
動更新的時候。
手機鎖屏解屏后進入 app 注意是否會崩潰，功能狀態是否正常，尤其是對于從后臺切換回前臺數據有自動更新的時
候。
當 App 使用過程中有電話進來中斷后再切換到 app，功能狀態是否正常
當殺掉 App 進程后，再開啟 App，App 能否正常啟動。
出現必須處理的提示框后，切換到后臺，再切換回來，檢查提示框是否還存在，有時候會出現應用自動跳過提示框
的缺陷。
對于有數據交換的頁面，進行前后臺切換、鎖屏的測試，
視頻、音頻播放中音頻交互
外放類
來電鈴聲（包含來電，視頻軟件來電等）的交互
鬧鈴（包含手機鬧鐘，日程提醒等）
免提通話（包含語音通話，視頻通話，視頻軟件通話）
軟件測試小講堂
129
消息通知類提醒（短信，郵件，消息等）
各類提示音（觸摸，截屏，鎖屏，撥號等）
視頻類軟件播放視頻（當前軟件后臺）
語音類
通話（包含語音通話，視頻通話，視頻軟件通話）
藍牙通話，耳機通話
優先級（產品必須明確需求）
通話：語音通話和視頻通話（手機自身而不是第三方軟件）
鈴聲：來電鈴聲，通知提醒
通話類軟件如微信，QQ 等
流媒體之類
交互方式
多語音同時在前端觸發
軟件測試小講堂
130
按語音優先級進行覆蓋或中斷
后到先播序列
暫停，打斷，滅屏，亮屏
7.11.8. 內容測試
輸入框說明文字的內容與系統功能是否一致
是否有錯別字
是否有敏感性詞匯、關鍵詞
是否有敏感性圖片，如：涉及版權、專利、隱私等圖片
內容檢查，不能用反黨，反國、臺獨、第一、最好等敏感詞匯
后臺服務器異常時，APP 前端應該給予正確的提示和引導，不要出現代碼類詞匯，更不能出現泄密性內容
覆蓋安裝后的帳號不能掉線
確定數據展示部分的處理邏輯，是每次從服務端請求，還是有緩存到本地，這樣才能有針對性的進行相應測試
7.11.9. APP 更新測試
軟件測試小講堂
131
非強制升級
可跳過
退出后每次進入都會提示
本次瀏覽過程中不再提示
強制升級
不可跳過
退出后每個進入都會提示
覆蓋升級
登錄狀態不發生改變
已保存數據不會丟失
7.11.10. 流媒體測試
業務測試
測試對流媒體點播，終端提供播放、暫停、繼續、停止、退出操作
軟件測試小講堂
132
測試對流媒體點播，終端提供定位播放（即快進、后退）操作
測試對流媒體點播，終端提供音量控制和靜音操作操作
測試對流媒體直播，終端提供播放、停止、退出、音量控制和靜音操作
測試對于視頻下載，終端提供本地回放功能（包括：播放、暫停、繼續、停止、退出、定位播放、音量控制和靜音
操作。
測試對于流媒體播放過程中，若當前速率不能滿足流媒體播放時，終端應自動暫停播放并對流媒體內容進行緩存，
在收到足夠信息后繼續播放
測試流媒體播放結束后，終端不能保存流媒體文件的部分或者全部的內容，并且播放器的緩存不可以被訪問，視頻
下載的文件可以保存在終端
測試如果終端支持所選媒體格式，終端應給出相應的提示，有用戶選擇是否繼續播放其中可支持部分
測試在流媒體直播、點播和視頻下載過程中，如果突然出現關機情況，是否正常響應
測試在流媒體直播、點播和視頻下載過程中，如果應用程序出現異常，是否正常響應
測試在流媒體直播、點播和視頻下載過程中，如果瀏覽器出現異常，是否正常響應
測試在流媒體直播、點播和視頻下載過程中，如果網絡出現異常，是否正常響應
軟件測試小講堂
133
測試在流媒體終端收到視頻圖像的尺寸如果大于播放器屏幕尺寸時，播放器是否正常響應
測試在流媒體終端收到視頻圖像的尺寸如果大于播放器屏幕尺寸時，播放器是否正常響應
流媒體窗口全屏和正常之間的切換是否能夠實現
測試上傳文件最大值
測試上傳文件是否支持中文名稱
測試刪除上傳成功的文件
測試文件名稱的最大值、最小值
測試文件名稱是否支持特殊字符(包括空格)
測試上傳過程斷網，等網絡恢復后，是否支持斷點續傳
測試上傳時網速很慢，上傳中傳測試
測試上傳文件支持的格式
測試增加部分功能后系統運行是否正常
測試刪除部分功能后系統運行是否正常
軟件測試小講堂
134
測試缺陷修改后系統運行是否正常
流媒體的播放窗口是否可以單獨從瀏覽器窗口中拖拽出來
內存不足時，是否有相應的內存不足的提示
當前瀏覽器最小化后，是否停止流媒體的下載過程以節約網絡資源
在流媒體的播放定位過程中，是否能夠出現一個小的視頻窗口，以便用戶確認定位位置
流媒體播放過程中是否有記憶功能，以便中斷恢復或下次打開后，從上次瀏覽處繼續查看
性能測試
碼率
指數據傳輸時單位時間傳送的數據位數，單位為 kbps。碼率的大小決定視頻文件的清晰度、流暢度和大小。碼率
越高，畫質越好，文件也越大
幀率
幀率用于測量顯示幀數的量度，單位為每秒顯示幀數（FPS）。高的幀率可以得到更流暢、更逼真的動畫。FPS 越
多，顯示的動作就會越流暢。一般來說 60FPS 可以明顯提升動畫的交互感和逼真感，超過 75FPS 流暢度則不會有
明顯的提升
軟件測試小講堂
135
丟包率
丟包是網絡中數據傳輸的時候出現數據丟失的現象，丟包率是指丟包數據占總傳輸數據的百分比。網絡丟包率越
高，網速越慢，一般丟包率小于 1%屬于正常
平均下載速度
指播放器播放視頻過程中下載視頻資源的速度。平均下載速度=總下載字節數/吞吐用時。建議值：優秀 >180
KB/s，一般 >70 KB/s，差 ≤ 70KB/s
視頻首包用時
從獲取視頻真實地址到獲取視頻資源第一包之間的時間間隔。建議值：優秀 ≤1s，一般 ≤2.5s，差 >2.5s
視頻首幀用時
從獲取視頻真實地址到開始播放視頻第一幀之間的時間間隔。其中視頻秒開指的是視頻頁面首屏在 1s 左右快速的
展現出來，視頻秒開直接影響著用戶體驗
頁面首屏用時
從開始瀏覽到頁面被渲染出指定高度范圍之間的時間間隔。參考值：優秀 ≤3.5s，一般 ≤7s，差 >7s。
卡頓時間
軟件測試小講堂
136
指視頻在開始播放后出現的卡頓（緩沖）狀態的累計時長（首次緩沖不計算在內）卡頓時間=總緩沖用時-首次緩沖
用時。參考值：優秀 ≤ 6s，一般 ≤12s，差 >12s
St-load
7.11.11. 帳號切換測試
注冊
密碼需要以密文展示
重復注冊需要給出明確提示
驗證碼發送次數限制
驗證碼有效期限制
驗證碼輸入次數限制
驗證碼輸入正確與否判斷
驗證碼驗證后失效性
登錄
軟件測試小講堂
137
是否有次數限制
使用已經登陸的賬號登陸系統是否正確處理
單點登錄
使用禁用的賬號登陸系統是否正確處理
有效登錄
一鍵登錄
人臉識別登錄
7.11.12. 按鈕連點（小并發）專項
提交訂單按鈕的連續點擊
允許重復訂單
庫存足夠時
不允許重復訂單
庫存不足時
軟件測試小講堂
138
支付按鈕的連續點擊
同一訂單不允許重復支付
重復支付后的訂單處理
注冊按鈕的連續點擊
是否有正確的攔截方式
后臺對于重復注冊有正確校驗
關注類按鈕的連續點擊
是否同時生成兩條關注記錄
后臺的正確處理
前端防連點
有上限條件的提交按鈕
人數上限
達到人數時的提交邏輯處理
軟件測試小講堂
139
庫存上限
多余訂單的處理
8. 技巧
8.1. 溝通技巧
8.1.1. 技術溝通
平等待人，以理服人
8.1.2. 產品溝通
可以提意見，不要做決定
8.1.3. 會議溝通
言簡意賅，總結領悟
8.1.4. 向上匯報
事情，原因，解決
8.1.5. 向下溝通
軟件測試小講堂
140
以理服人，以德服人，以權壓人
8.2. 控制技巧
8.2.1. 控制測試是為了驗證控制是否按照設計要求被一貫和有效執行的一種測試程序
8.2.2. 測試集中在關鍵控制上
8.2.3. 詢問
即通過口頭或書面形式確認控制存在，并且應該詢問多人以確定結果一致
8.2.4. 觀察
即觀察員工執行控制步驟，該方法可能需要其他跟進測試，并且需要結合突襲檢查，在員工無準備的情況下獲得控制
活動執行的真實記錄
8.2.5. 檢查
這種方法是獲得資產存在證據的最簡單的方法，主要是通過審閱相關文檔記錄或報告來對控制活動執行情況進行判
斷，需要注意的是，在這種方法中需要員工提供詳細內容從而可以重復測試步驟并檢驗結果
8.2.6. 重新執行
軟件測試小講堂
141
如采用獨立的數據重新進行對賬，按系統的計算公式重新計算，在系統中輸入測試數據來查看結果等
8.3. 偷懶技巧
8.3.1. 學會使用一切可以為測試服務的工具
8.3.2. 學會利用一些集合簡單命令的腳本，并不一定需要什么編程基礎
8.3.3. 學會提取公因式-不僅僅指操作，更是一種測試意識
9. 標準
9.1. 缺陷關閉標準
9.1.1. 正常缺陷的生命周期
創建
解決
回歸
關閉或激活
9.1.2. 需要評審類的缺陷的生命
軟件測試小講堂
142
提交無法正常關閉的理由
提交評審會議
三態
關閉
待定
迭代
9.2. 用戶體驗標準
9.2.1. 功能測試
定義
根據產品特性、操作描述和用戶方案，測試一個產品的特性和可操作行為以確定它們滿足設計需求
功能測試只是由 QA 驗證是否滿足功能的設計要求，是否能完成當初的功能設計，滿足功能即可
傾向于站在開發的角度
9.2.2. 用戶體驗測試
軟件測試小講堂
143
ISO 定義
用戶在使用一個產品或系統之前、使用期間和使用之后的全部感受，包括情感、信仰、喜好、認知印象、生理和心
理反應、行為和成就等各個方面。該說明還列出三個影響用戶體驗的因素：系統，用戶和使用環境
測試人員在將產品交付客戶之前處于用戶角度進行的一系列體驗使用，如：界面是否友好（吸引用戶眼球，給其眼前
一亮）、操作是否流暢、功能是否達到用戶使用要求等
用戶體驗涵蓋的面更廣，良好的用研不僅僅只是滿足用戶提出的功能，而且還要設法滿足用戶的潛在需求，達到良好
的生理（視覺，操作）以及心理體驗（易用性，可感知，可學習，可記憶性等等），同時也要兼顧效率以及開發成
本，是一個比較全面性的指標系統
傾向于站在用戶的角度
滿足用戶需求，超出用戶期望
測試過程（中間可能隨需求和開發的不斷修改）會花費部分成本，用戶體驗測試也不例外（用戶體驗環境從時間耗時
和資源上都能體現）。考慮實際收益，用戶體驗測試的設計需要慎之又慎，他需要對測試的目的、介入時間、測試的
周期、場景、人員的選型都要做出深入的分析和界定
用戶體驗測試介入時間一定要盡可能的早，試想如果在系統快要發布前才進行該項測試，非常可能因為在用戶體驗測
試時發現頁面結構不合用戶操作習慣，或有些功能對于用戶而言需要強化，或操作步驟過繁，在不推遲發布時間的情
況下，此時對代碼進行修改和優化，誰都知道這樣的行為無疑是危險的。因此，較為合理的做法是當頁面的 demo 定
軟件測試小講堂
144
稿時我們就需進行用戶體驗測試，不過由于此時的測試是靜態的，所以還不足以確保用戶實際的操作感受，我們還需
要在系統提交功能測試后，當功能測試人員驗證主流程已能正常流轉，用戶體驗測試就能再次介入進來，此時的用戶
體驗測試不必像功能測試那樣關注細節的實現，更重要的是收集用戶的操作習慣和使用感受。
9.2.3. 本質上用戶體驗差和缺陷等級較低的 bug 沒有什么區別。
9.3. 性能測試標準
9.3.1. 前端性能
系統啟動時長
流暢度檢測（FPS）
流量測試分析
用戶等待時長
系統能耗
電池
發熱
軟件測試小講堂
145
設備兼容
分辨率
系統操作
9.3.2. 接口性能
用戶等待時長
網絡切換
弱網
斷網
wifi 和數據切換
9.3.3. 服務器性能
TPS
QPS
error
軟件測試小講堂
146
HPS
CPU
內存
網關
負載均衡
容量
限流
擴容
9.4. 風險評估標準
9.4.1. 生死線
9.4.2. 風險預判
9.4.3. 漏洞
9.5. 成本管理標準
軟件測試小講堂
147
9.5.1. 業務邏輯是否存在不合理的費用支出
9.5.2. 業務邏輯是否存在可以節省的費用支出
9.5.3. 測試階段需要花費的財力
10. 過程
10.1. 測試計劃和控制
10.1.1. 識別測試任務、定義測試目標以及為了實現測試目標和任務確定必要的測試活動
10.1.2. 測試控制是持續進行的活動：通過對測試實際進度和測試計劃之間的比較，報告測試的狀態，包括與計劃之間存
在的偏差。測試控制包括在必要的時候采取必要的措施來滿足測試的任務和目標。需要在項目的整個生命周期中對測試
活動進行監督，以達到控制測試過程的目的
10.1.3. 測試計劃的制定也需要考慮測試監控活動的反饋信息
10.2. 測試分析和設計
10.2.1. 將概括的測試目標轉化為具體的測試條件和測試用例的一系列活動
10.2.2. 評審測試依據(比如需求、軟件完整性級別(風險等級)、風險分析報告、系統架構、設計和接口說明)
軟件測試小講堂
148
10.2.3. 評估測試依據和測試對象的可測性
10.2.4. 通過對測試項、規格說明、測試對象行為和結構的分析，識別測試條件并確定其優先級
10.2.5. 設計測試用例并確定優先級
10.2.6. 確定測試條件和測試用例所需要的測試數據
10.2.7. 規劃測試環境的搭建和確定測試需要的基礎設施和工具
10.2.8. 創建測試依據和測試用例間的雙向可追溯性
10.2.9. 軟件完整性級別：為了向軟件利益相關者反映軟件重要性所定義的軟件遵守的或必須遵守的一系列利益相關者選
定的軟件和/或軟件系統特性的級別。(例如，軟件復雜度、風險評估、產品安全性級別、產品防止對程序和數據未授權
訪問的能力級別、預期性能、可靠性、成本)
10.3. 測試實現和執行
10.3.1. 測試實現和執行階段的主要活動包括：通過特定的順序組織測試用例來完成測試規程和腳本的設計，并且包括測
試執行所需的其他任何信息，以及測試環境的搭建和運行測試。
10.3.2. 測試實現和執行階段的主要任務：
10.3.3. 測試用例的開發、實現并確定它們的優先級。(包括識別測試數據);
軟件測試小講堂
149
10.3.4. 開發測試規程并確定優先級，創建測試數據，同時也可以準備測試用具和設計自動化測試腳本;
10.3.5. 根據測試規程創建測試套件，以提高測試執行的效率;
10.3.6. 確認已經正確搭建了測試環境;
10.3.7. 確認并更新測試依據和測試用例間的雙向可追溯性;
10.3.8. 根據計劃的執行順序，通過手工或使用測試執行工具來執行測試規程;
10.3.9. 記錄測試執行的結果，以及被測軟件、測試工具和測試件的標識和版本;
10.3.10. 將實際結果和預期結果進行比較;
10.3.11. 對實際結果和預期結果之間的差異，作為事件上報，并且進行分析以確定引起差異的原因(例如：代碼缺陷、具
體測試數據缺陷、測試文檔缺陷、或測試執行的方法有誤等);
10.3.12. 缺陷修正后，重新進行測試活動。比如通過再次執行上次執行失敗的用例來確認缺陷是否已經被修正(確認測
試)。執行修正后的測試用例或執行一些測試用例來確保缺陷的修正沒有對軟件未修改的部分造成不良影響或對于缺陷的
修正沒有引發其他的缺陷(回歸測試)。
10.4. 評估出口準則和報告
軟件測試小講堂
150
10.4.1. 評估出口準則是將測試的執行結果和已經定義的測試目標進行比較的活動。這個活動在各個測試級別上都需要進
行。
10.4.2. 評估測試出口準則的主要任務：
10.4.3. 按照測試計劃中定義的測試出口準則檢查測試日志;
10.4.4. 評估是否需要進行更多的測試，或是否需要更改測試的出口準則;
10.4.5. 為利益相關者提供一個測試總結報告。
10.5. 測試結束活動
10.5.1. 測試結束活動就是從已完成的測試活動中收集和整合有用的數據，這些數據可以是測試經驗、測試件、影響測試
的因素和其他數據。在以下幾種情況下需要執行測試結束活動，例如：當軟件系統正式發布、當一個測試項目完成(或取
消)、當達到一個里程碑或當一個維護版本完成時。
10.5.2. 檢查提交了哪些計劃的可交付產品;
10.5.3. 事件報告是否關閉、或對未關閉的事件報告提交變更需求;
10.5.4. 記錄系統的驗收;
10.5.5. 記錄和歸檔測試件、測試環境和測試基礎設備，以便以后的重復使用;
軟件測試小講堂
151
10.5.6. 移交測試件到維護部門;
10.5.7. 分析和記錄所獲得的經驗教訓，用于以后的項目和測試成熟度改進;
10.5.8. 使用為測試成熟度的提高所收集的信息
?

總結

以上是生活随笔為你收集整理的软件测试知识体系图谱的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。