軟件測試基礎，記錄方便本身回頭看

1、軟件測試概述

一、什麼是軟件

定義：計算機系統中與硬件相互依存的一部分（程序+數據+相關文檔）

程序：按事先設計的功能和性能要求執行的指令序列

數據：使程序能正常操縱信息的數據結構

文檔：與程序開發、維護和使用有關的圖文資料

 

二、軟件工程的內容

主要分爲軟件開發技術（方法+過程+工具+環境）和軟件開發管理

 

三、軟件的生命週期

可行性研究和計劃（立項）

需求分析

概要設計（測試計劃）

詳細設計（測試方案）

實現（開發階段；包含單元測試）

組裝測試（集成測試）

確認測試（系統測試，驗收回歸測試）

使用和維護（上線使用及平常更新維護）

 

四、什麼是軟件測試

定義：軟件質量保證的一種手段

目的：發現錯誤以及避免這些錯誤的發生，使產品達到完美

概念：是軟件工程中的一個很是重要的環節，是開發項目總體的一部分。是有計劃有組織的，是伴隨軟件工程的誕生而誕生的，軟件測試不是萬能的，不可能發現所有缺陷，軟件測試是有侷限性的。

 

五、軟件測試的方法

①、用試題檢查法

②、用新舊兩個系統作平行處理檢查

③、軟件測試自動化工具測試

 

六、軟件測試階段有哪些任務

①、制定測試大綱（測試計劃）

②、製做測試數據（測試方案）

③、單元測試（程序測試，通常由開發人員進行）

④、功能測試

⑤、性能測試

⑥、集成測試（子系統測試）

⑦、系統測試

⑧、驗收測試

⑨、測試報告及向下階段提交系統運行、維護用戶手冊

 

七、測試的原則

①、儘早的、不斷地進行測試

②、測試用例由輸入數據和與之對應的輸出結果組成，應包括合理和不合理的輸入條件

③、開發者應儘可能避免檢查本身的程序

④、設計測試用例時，應包括合理和不合理的輸入條件

⑤、充分注意測試中的集羣現象，嚴格執行測試計劃，排除測試的隨意性

⑥、對每個測試結果作全面檢查

⑦、妥善保存測試計劃，方案，用例，BUG記錄及最終分析報告等文檔

 

八、軟件測試工做流程圖

立項階段

需求階段

設計階段

編碼&單元測試階段

集成測試階段

系統測試階段

驗收測試階段

結項總結階段

 

九、自動化測試

概念：爲了提升工做效率，節省人力和成本，把人爲驅動的測試轉化爲機器執行

  

十、自動化測試的過程

需求分析

測試計劃

框架搭建（附帶工具選擇）

測試用例設計（編寫測試用例或開發測試腳本，並文檔化）

測試——調試測試（針對自動化測試腳本）

評估（評估測試結果並改進測試過程）

 

十一、自動化測試的優勢

①、能執行更多更頻繁的測試， 使某些測試任務執行方式更高效

②、能執行一些手動測試困難或者不能作的測試

③、任務自動化，使測試人員投入更多精力設計測試用例，提升測試準確性和人員積極性

④、具備一致和可重複性特色，更客觀，提升軟件信任度，仍存在必定侷限

⑤、不能取代手工測試，不能自動化全部的測試（如只是偶爾執行測試，或需求常常變更，不穩定，或者須要大量手工參與時）

⑥、自動化測試工具只能執行命令，而手工能夠在測試中判斷測試的輸入是否正確，以及改進測試，還可處理意外事件

⑦、對質量依賴較大，在確保質量的前提下，實施自動化纔有意義

⑧、自動化測試須要在整個測試系統成熟穩定後，工做效率纔會隨着測試執行次數的增長而提升

⑨、自動化測試的成本可能高於手工測試

 

十二、自動化測試技術

錄製/回放（依賴工具）

腳本技術

數據驅動（data driven)的自動化測試

關鍵字驅動（keyword driven）的自動化測試

業務驅動

 

1三、自動化測試的級別

①、捕獲和回放

②、捕獲、編程和回放

③、編程和回放

④、數據驅動的測試

⑤、使用動做詞的測試自動化

 

1四、自動化測試方案選擇須要考慮的方面

①、項目的影響（可否幫助項目進度、覆蓋率、風險）

②、複雜度（是否容易實現，包括數據和其餘環境等）

③、時間（實現自動化須要多少時間）

④、早期需求和代碼的穩定性（需求或代碼可否證實是在範圍內變化的）

⑤、維護工做量（代碼可否能長期保持相對穩定）

⑥、覆蓋率（自動化測試可否覆蓋程序的關鍵特性和功能）

⑦、資源（是否擁有足夠的人力、硬件和數據資源來運行自動化測試）

⑧、執行（負責執行的人員是否有足夠的技能和時間去運行）

⑨、自動化測試管理

 

1五、自動化測試的重點

①、搭建測試環境，測試場景

②、測試用例

③、測試結果的驗證

④、自動化測試的流程以及執行

 

1六、自動化測試須要解決的問題

①、工具的選擇

②、測試用例腳本編寫

③、測試腳本的管理

 

2、白盒測試

一、什麼是白盒測試

定義：按照程序內部結構，邏輯驅動測試程序

目的：檢測產品內部動做是否按照設計說明書的規範進行，檢驗程序的每條路徑是否都能按照預約要求進行工做

對象：源程序

用代碼內部的分支，路徑，條件，使程序設計的控制結構導出測試用例

 

二、白盒測試方法分類

①、靜態測試

②、動態測試

 

三、白盒測試的原則

①、保證一個模塊中全部路徑至少被測試一次

②、全部邏輯值都要測試真和假兩種狀況

③、檢查程序內部的數據結構是否有效

④、檢查上下邊界及可操做範圍內運行全部循環

 

四、白盒測試的類別

①、軟件共用問題的測試

②、語言測試

③、sql語句測試

④、數據類型測試

⑤、界面測試

⑥、數值隊形測試

⑦、業務對象測試

⑧、數據管理對象測試

 

五、白盒測試依據

①、軟件需求報告

②、軟件需求規格說明

③、程序設計文檔

④、軟件界面設計

⑤、編碼規範

⑥、開發命名標準

 

六、白盒測試流程

①、界面對象測試流程

界面對象（UI）→業務對象（BO）→數據管理對象（DMO）→DBserver端

②、業務對象測試流程

DBserver端→數據管理對象（DMO）→業務對象（BO）→界面對象（UI）

 

七、白盒測試方法

①、儘可能先用自動化工具來進行靜態解析

②、建議先從靜態測試開始（靜態結構分析、代碼走查、靜態質量度量），而後進行動態測試（如覆蓋率測試）

③、以靜態分析結果做爲依據，再使用代碼檢查和動態測試方法對靜態分析結果進行進一步確認，提升測試效率及準確性

④、覆蓋率測試是白盒測試的重要手段，在測試報告中可做爲量化指標的依據，對於軟件的重點模塊，應使用多種覆蓋率標準衡量代碼的覆蓋率

 

八、代碼檢查

概述：主要檢查代碼和流圖設計的一致性、代碼結構的合理性、代碼編寫的標準性、可讀性、代碼的邏輯表達的正確性等方面。包括變量檢查、命名和類型審查、程序邏輯審查、

     程序語法檢查和程序結構檢查等內容。

目的：①、檢查代碼是否按照某種標準或規範編寫的代碼

     ②、檢查代碼以發現程序缺陷

     ③、經過檢查代碼容易發現程序產生的錯誤

     ④、經過檢查代碼來發現代碼是否是流程圖要求的；

     ⑤、經過檢查代碼來發現有沒有遺漏的項目；

     ⑥、要代碼易於移植，代碼常常須要在不一樣的硬件中運行，或者使用不一樣的編譯器編譯；

     ⑦、要代碼易於閱讀、理解和維護。

方式：①、桌面檢查

     ②、走查

     ③、代碼審查

項目：①、目錄文件組織   

     ②、檢查函數

     ③、數據類型及變量

     ④、檢查條件判斷語句

     ⑤、檢查循環體制

     ⑥、檢查代碼註釋

     ⑦、桌面檢查

 

九、靜態結構分析

定義：主要以圖形的方式表現程序的內部結構（例如函數調用關係圖、函數內部控制流圖）；經過應用程序各函數之間的調用關係展現了系統的結構，列出全部函數，用連線表示調用關係和做用。

主要分析：①、能夠檢查函數的調用關係是否正確

        ②、是否存在孤立的函數而沒有被調用

        ③、明確函數被調用的頻繁度，對調用頻繁的函數能夠重點檢查

 

十、SQL語句測試

主要檢查如下兩點：

①、語句檢查

②、類型轉換

 

十一、代碼檢查的分析與評價

主要注意如下兩點：

①、能力（陳述經代碼檢查證明了的本軟件的能力）

②、缺陷和限制

 

十二、白盒測試經常使用技術（7種）

①、邏輯覆蓋法

1.1測試覆蓋率

用於肯定測試所執行到的覆蓋項的百分比；覆蓋項指做爲測試基礎的一個入口或屬性，好比語句、分支、條件等

測試覆蓋率可表示出測試的充分性，在測試分析報告中可做爲量化指標的依據，測試覆蓋率越高效果越好。但覆蓋率不是目標，只是一種手段。

測試覆蓋率包括功能覆蓋和結構覆蓋：

 

1.2邏輯覆蓋

根據覆蓋目標的不一樣和覆蓋源程序語句的詳盡程度，邏輯覆蓋又可分爲語句覆蓋 、斷定覆蓋、條件覆蓋、條件斷定組合覆蓋、多條件覆蓋、修改條件斷定覆蓋、組合覆蓋和路徑覆蓋。

 

1.3面向對象的覆蓋

面向對象的覆蓋主要討論繼承上下文覆蓋和基於狀態的上下文覆蓋。

 

1.4測試覆蓋準則

測試覆蓋準則主要討論（ESTCA）錯誤敏感測試用例分析和(LCSAJ)線性代碼序列與跳轉。

（1）ESTCA覆蓋準則

（2）現行代碼序列與跳轉LCSAJ線性代碼序列與條狀LCSAJ是指一組順序執行的代碼，以控制流跳轉爲結束點。可產生4層覆蓋

 

 ②、插樁技術

插樁測試是一個被普遍應用的測試方法。插樁測試就是向源程序中插入語句而後執行程序，經過打印語句，得到動態信息（咱們最爲關心的信息）

 

③、基本路徑測試法

基本路徑測試法是在程序控制流圖的基礎上，經過分析控制構造的環路複雜性，導出基本可執行路徑集合，從而設計測試用例的方法。設計出的測試用例要保證在測試中程序的

每一個可執行語句至少執行一次。重點內容以下：

程序的控制流圖：描述程序控制流的一種圖示方法。

程序環形複雜度：McCabe複雜性度量。從程序的環路複雜性可導出程序基本路徑集合中的獨立路徑條數，這是肯定程序中每一個可執行語句至少執行一次所必須的測試用例數目的上界。

 

3.1程序控制流圖

程序控制流圖（可簡稱流圖）是對程序流程圖進行簡化後獲得的，它突出表示程序控

制流的結構。程序控制流圖是描述程序控制流的一種方式。控制流圖圖形符號；

圖形符號：圓圈表明一個結點， 表示一個或多個無分支的語句或源程序語句；

程序控制流邊和點圈定的部分叫作區域。當對區域計數時，圖形外的一個部分也應記爲一個區域；

判斷語句中的條件爲複合條件時，即條件表達式由一個或多個邏輯運算符鏈接的邏輯表達式（a and b），則須要改變複合條件的判斷爲一系列只有單個條件的嵌套的判斷。

基本路徑測試方法是在控制流圖的基礎上，經過分析控制結構的環形複雜度，導出執行路徑的基本集，再從該基本集設計測試用例。基本路徑測試方法包括如下4個步驟：

3.1.1畫出程序的控制流圖。

3.1.2計算程序的環形複雜度，導出程序基本路徑集中的獨立路徑條數，這是肯定程序中每一個可執行語句至少執行一次所必須的測試用例數目的上界。

3.1.3導出基本路徑集，肯定程序的獨立路徑。

3.1.4根據③中的獨立路徑，設計測試用例的輸入數據和預期輸出。

 

④、域測試法

域測試是一種基於程序結構的測試方法，基於對程序輸入空間（域）的分析，選擇測試點進行測試。主要爲：

4.1域錯誤：程序的控制流存在錯誤，對於某一特定的輸入可能執行的是一條錯誤路徑，這種錯誤稱爲路徑錯誤，也叫作域錯誤；

4.2 計算型錯誤：對於特定輸入執行的路徑正確，但賦值語句的錯誤致使輸出結果錯誤，稱爲計算型錯誤；

4.3丟失路徑錯誤：因爲程序中的某處少了一個斷定謂詞而引發的丟失路徑錯誤

 

⑤、符號測試

符號測試基本思想是容許程序的輸入不只僅是具體的數值數據，並且包括符號值，符號值能夠是基本的符號變量值，也能夠是符號變量值的表達式

5.1符號測試執行的是代數運算，能夠做爲普通測試的一個擴充；

5.2符號測試能夠看做是程序測試和程序驗證的一個折衷辦法；

5.3 符號測試程序中僅有有限的幾條執行路徑；

 

⑥、Z路徑覆蓋法

分析程序中的路徑是指檢驗程序從入口開始，執行過程當中經歷的各個語句，直到出口。

Z路徑覆蓋對循環機制進行簡化，減小路徑的數量，使得覆蓋全部路徑成爲可能，簡化循環意義下的路徑覆蓋稱爲Z路徑覆蓋；

循環簡化：限制循環次數，只考慮循環一次或零次狀況；

循環簡化的目的是限制循環的次數，不管循環的形式和循環體實際執行的次數，簡化後的循環測試只考慮執行循環體一次和零次（不執行）兩種狀況，即考慮執行時進入循環體

一次和跳過循環體這兩種狀況。

 

⑦、程序變異測試法

程序變異是一種錯誤驅動測試。錯誤驅動測試是指該方法是針對某類特定程序錯誤的，要想找出程序中全部的錯誤幾乎是不可能的，解決辦法是將錯誤的搜索範圍儘量地縮小，

以利於專門測試某類錯誤是否存在。

 

3、黑盒測試

一、定義：數據驅動測試或者基於規格說明的測試

只檢查程序功能是否按照規格說明書規定正常使用，是否能接收數據及產生正確的輸出

信息，而且知足數據庫或者外部信息的完整性

 

二、黑盒測試的目的

①、是否有不正確或者遺漏的功能

②、界面是否有誤

③、接口上，輸入輸出是否正確

④、是否有數據結構錯誤或者外部數據庫訪問錯誤

⑤、性能是否知足要求

⑥、初始化或者終止性錯誤

 

三、黑盒測試的優勢

①、最大程度知足用戶需求

②、相同動做可重複執行，枯燥部分可由機器完成

③、根據測試用例針對性的尋找問題，定位更準確，容易生成測試數據

④、測試直接和程序/系統要完成的操做相關聯

 

四、黑盒測試的缺點

①、代碼得不到測試

②、若是規格設計錯誤，很難發現

③、測試不能充分進行

④、結果取決於測試用例的設計

 

五、黑盒設計方法

①、等價類劃分法

②、邊界值分析法

③、因果圖法

④、斷定表驅動法

⑤、場景法

⑥、功能圖法

⑦、錯誤推斷法

⑧、正交試驗設計法

注意點：肯定測試的優先級和測試重點，提升覆蓋率，邊界值分析必須使用

 

六、設計用例的策略

①、首先進行等價類劃分，包括輸入和輸出條件，減小工做量提升效率

②、邊界值分析，發現錯誤的能力最強

③、錯誤推斷法，補充用例（這個憑經驗）

④、對照需求和業務場景邏輯，檢查用例

⑤、若是需求說明含有輸入條件，設計開始就用到因果圖和斷定表驅動法

⑥、參數配置類的軟件，要用正交實驗法

⑦、功能圖法，不一樣時期條件的有效性來設計數據

⑧、業務流清晰的系統，採用場景法

 

6.1等價類

①、將全部可能輸入數據（有效和無效）劃分爲若干個等價類，選取表明性的數據當作  測試用例，保證完整性和表明性

有效等價類：合理的有效的輸入集合

無效等價類：無效的沒有意義的輸入集合，檢查程序異常

②、等價類劃分方法

按照區間、數值、集合、限制條件、處理方式劃分

 

6.2邊界值

對輸入或輸出的邊界值進行設計（5/7原則）

 

6.3因果圖

簡化邏輯關係，操做步驟較複雜

 

6.4斷定表驅動法

針對不一樣存在條件、動做關係或者因果關係的設計用例方法

4大組成部分：條件樁，條件項；動做樁，動做項

 

6.5場景法

事件觸發的情景生成場景（同一件事不一樣觸發順序和處理結果造成事件流）

 

6.6功能圖法

用功能圖（流程圖）形象的表達操做流（狀態遷移圖+布爾函數組成）

須要依靠斷定表因果圖表示邏輯，是黑盒+白盒混合用例的設計方法

 

6.7錯誤推斷法

基於以往的經驗和出現的錯誤，推測軟件可能存在的缺陷和錯誤，針對性的設計用例

 

6.8正交實驗法

從大量數據中挑選適量的有表明性的，合理設計用例

 

七、黑盒測試的原則

一、根據需求和規格要求，明確產品要求的正確性

二、針對性的找問題，正肯定位

三、根據需求重要性肯定測試等級和重點，減小缺陷

四、接口處，輸入是否能正確接收，輸出是否正確

五、站在用戶角度思考，測試

 

八、測試計劃

根據需求中關於功能和性能的要求設計，制定參考範圍

 

4、測試用例

一、什麼是測試用例

一組由前提條件、輸入、執行條件、預期結果等組成，以完成對某個特定需求或者目標測試的數據，體現測試方案、方法、技術和策略的文檔

 

二、爲何要寫測試用例

科學有效的對測試步驟進行組織規劃，方便管理，記錄

 

三、測試用例主要包含哪些內容

編號、日期、設計和測試人員、優先級、標題、目標、環境、輸入數據/動做、預期結果

 

四、編寫測試用例須要什麼

軟件需求設計說明書、軟件模板

 

五、設計測試用例的注意事項

從高到低，獨立性，與功能一一對應，根據需求設計，由有經驗的人員設計

 

六、設計測試用例的原則

有模板，正確性，表明性，可判斷性，重現性，詳細準確清晰的步驟，符合規範

 

七、用例的管理工具

市場上的用例缺陷管理工具不少：蟄了列舉幾個：mantis、redmine、jira、bugzilla、禪道等

 

八、用例的管理過程

編寫→評審（修改→再次評審）→使用→保存管理→維護/升級

 

九、測試用例內容

目標的描述、環境、輸入輸出數據/動做、步驟、預期結果、備註等

      

5、單元測試

一種驗證行爲，程序中每一項都須要驗證

一、目的

①、檢查單元模塊內部錯誤，爲軟件評審提供依據

②、測試模塊內重要的路徑，以程序設計說明書和測試數據爲依據，以檢查出錯誤

③、檢查信息可否正確流入和流出單元

④、內部數據的完整性、數據形式相互關係的正確性，以及全局變量在單元中的處理和影響

⑤、數據在邊界處可否正常工做

⑥、單元的運行可否知足特色的邏輯覆蓋

⑦、錯誤處理機制是否有效

 

二、主要任務

程序語法檢查、程序邏輯檢查、模塊接口測試、局部數據結構測試、路徑測試、邊界條件測試、錯誤處理測試、代碼書寫規範檢查

 

2.1程序語法檢查

①.編譯語言對程序進行檢查

②.人工檢查

 

2.2程序邏輯檢查

①.檢查程序邏輯是否正確

②.程序中的循環語句上下項以及循環次數是否有問題

③.函數或子模塊是否有自我調用問題

 

2.3模塊接口測試

模塊接口是模塊內核模塊外聯繫的關鍵部位；當模塊經過外部調用時，數據必須正確流入，當模塊結束問題的處理返回調用模塊時，數據必須能正確流出

 

2.4局部數據結構測試

局部數據結構是爲了保證臨時存儲在模塊內的數據，模塊錯誤根源每每是局部數據結構

表現形式以下：

①.局部數據結構測試最多見的積累錯誤

②.不適合或者不相容的類型說明

③.變量無初值

④.變量初始化或者缺省值有錯

⑤.不正確的變量名或者不正確的截斷

⑥.出現上溢、下溢或者地址異常

 

2.5路徑測試

對模塊中的重要的執行路徑進行測試，路徑錯誤主要由錯誤的計算，不正確的比較或者不正常的控制流致使

 

2.6邊界條件測試

容易出錯的因素：

①.程序內有一個n次循環，這個n次循環應該是1~n，而不是0~n

②.由小於、小於等於、等於、大於、大於等於、不等於肯定的比較值出錯

③.出現上溢、下溢和地址異常問題

 

2.7錯誤處理測試

完善的模塊設計要求能預見出錯的條件，並設置適當的出錯處理，以便在一旦程序出錯時，能對出錯程序重作安排，保證其邏輯上的正確性

 

2.8代碼書寫規範檢查

①.模塊設計程序框架流程圖

②.代碼書寫規範，對齊方式

③.代碼的註釋

④.參數類型，數據長度,指針，數組長度   大小

⑤.輸入輸出參數和結果

 

三、單元測試的步驟

單元測試是針對每一個程序的單體調試，主要步分爲程序語法檢查和程序邏輯檢查

 

6、功能測試

定義：功能測試就是對產品的各功能進行驗證，根據功能測試用例，逐項測試，檢查產品是否達到用戶要求的功能；只須要考慮它的功能點不須要考慮軟件的內部結構及代碼等

WEB：

1、功能測試

1.1連接測試

  連接是web應用系統的一個很重要的特徵，主要是用於頁面之間切換跳轉，指導用戶去一些不知道地址的頁面的主要手段，連接測試通常關注三點：

①.連接是否按照既定指示那樣，確實連接到了該連接的界面

②.測試該連接所連接的頁面是否真的存在

③.保證系統中沒有單獨存在的頁面（即沒有連接指向，只能經過正確的URL地址才能訪問）

 

1.2表單測試

也能夠理解爲數據落地；當用戶在web應用系統上向服務器提交信息時，就須要使用表單操做，好比，用戶註冊，登陸，信息變動等等；這種狀況下，咱們必須測試提交信息的完整性，

以檢驗提交給服務器的數據的正確性，固然，這還涉及到一些常理性的邏輯，好比出生日期和職業、工做年限是否恰當，所在地省份城市區域間的匹配等，若是設定使用默認值，也須要測試。

 

1.3導航測試

做爲測試，不少時候都要站在用戶的角度去思考，大部分用戶都是目的驅動的，當他訪問一個網站或者web系統時，會很快的瀏覽系統，找不到知足本身需求的信息時，會很快離開，不多有

用戶願意花時間去熟悉系統的結構；導航測試，就是在不一樣的頁面跳轉之間，或者按鈕，對話框，列表以及窗口等，經過考慮這些因素，去判斷一個應用系統是否易於導航：是否直觀？系統的

主要模塊是否能夠經過主頁訪問或者到達？站點是否須要站內地圖或者搜索引擎等其餘幫助？web系統導航的另一個重點就是頁面結構、導航、菜單、風格等是否一致，確保用戶能夠憑藉

直覺或者簡單的判斷就能夠找到本身想要的內容。

 

 

1.4圖形測試

能夠理解爲UI測試，其中包括圖片、動畫、邊框、顏色、字體、背景、按鈕等等。

其中要考慮如下幾個重點：

①.圖片要有明確的用途，表明；圖片尺寸儘可能小，通常採用JPG或者GIF壓縮

②.頁面總體風格是否和系統的用途一致

③.背景顏色，字體，搭配是否合理

 

1.5內容測試

主要用來檢測web系統提供信息的準確性、相關性，好比：商品的價格，文字描述；信息的準確性，是否有拼寫錯誤；信息的相關性，好比不少網站的「相關文章列表，視頻列表等」

 

1.6總體界面測試

也就是咱們常說的用戶體驗。用戶瀏覽時是否感受溫馨，總體風格等等通常作一個相似問卷調查的形式，來斷定用戶的反饋信息，最好有最終用戶的參與

 

2、兼容性測試

2.1平臺兼容

如今有不少的操做系統，好比Windows、Unix、Linux、macintosh等；用戶使用哪一個系統取決於用戶，所以，系統兼容測試就頗有必要。

 

2.2瀏覽器兼容

瀏覽器是web客戶端最核心的組件，不一樣的瀏覽器，對Java，JavaScript，css或者HTML的規格都有不一樣的支持；另外，採用的框架和結構風格在不一樣瀏覽器中也存在不一樣的

顯示甚至不顯示，不一樣的瀏覽器對安全性的設置也是不一樣的。

測試瀏覽器兼容，有個方法就是建立一個兼容性矩陣，來測試不一樣廠商不一樣版本的瀏覽器兼容。

好比測試IE瀏覽器，能夠經過一個叫作IEtester的工具來測試兼容，或者能夠經過F12控制檯來切換瀏覽器版原本測試兼容之前一些前端元素的顯示等

 

3、安全測試

安全測試的主要區域有如下幾點：

3.1用戶名和密碼的有效無效性，注意大小寫敏感，次數限制，是否能夠不登陸而瀏覽某些頁面等

3.2是否有超時限制

3.3測試用戶操做時相關信息是否寫入了日誌文件、是否可追蹤等

3.4若是使用了安全套字，須要測試加密是否正確，加密先後的信息完整性，正確性

3.5沒有通過受權，是否能夠在服務器端或者前端放置和編輯腳本的問題

 

4、輸入框測試

下面就是一些注意點：

4.1驗證輸入輸出信息的一致性

4.2輸入框前面的文字提示是否正確

4.3對特殊字符的處理、識別：單雙引號，括號，逗號、分號等等，以及大小寫狀態，半角全角狀態下的狀況

4.4輸入框的大小、長度、邊框等

4.5不一樣字符的輸入，以及字符組合狀況的處理（數字+字母+字符等）

4.6對空格、tab換行鍵的處理機制

4.7密碼輸入框字符星號或者其餘星號的轉行，加密

4.8輸入框輸入字符長度是否有限制

4.9字符自己顯示的顏色，規格等

4.10有些輸入框須要加以限制，如輸錯，是否有提示？提示是否簡單合理？

4.11輸入狀態，某種狀況下輸入框出於不可編輯，當再次處於編輯狀態，輸入框的輸入狀態是否有變化

4.12輸入類型：是否容許複製黏貼剪切等輸入操做

4.13關鍵字是否支持通配符，以及關鍵字的搜索能力，敏感字等狀況

4.14輸入框輸入空格的狀況

4.15好比登錄註冊，各項輸入條件的斷定：是否輸入，輸入是否正確等

 

5、用戶權限測試

用戶權限，就是該帳號擁有哪些執行操做的權利

5.1給某帳號賦予權限後，登錄該帳號，查看是否擁有已賦予的權限，以及權限設置是否正確（權限是否超過或者不足）

5.2刪除或修改已經登錄而且正在執行操做的帳號權限，程序可否正確處理，驗證

5.3從新註冊系統變動登錄身份後再登錄，程序可否正確執行，以前所擁有的權限可否繼續使用

5.4在用工做分配或者角色管理狀況下，刪除包含用戶的工做組或者角色，程序可否正確處理

5.5不一樣權限帳號登錄同一個系統，權限範圍是否正確

5.6可否給信息爲空、長用戶名的帳號添加權限

5.7是否容許刪除系統管理員或者修改管理員權限？刪除或者修改後的實際狀況

5.8已登陸的用戶可否修改或者刪除本身或者他人的權限，信息

5.9添加用戶（有編號或者標識），不一樣用戶名標識的組合狀況下，權限可否處理正確

5.10修改用戶權限或者信息後，對其餘模塊是否有影響

5.11若是修改用戶信息和已存在的其餘用戶信息相同，可否修改爲功？是否有對應提示

5.12修改某些設置，是否會對與該帳號權限相同或者高於/低於該帳號的其餘帳號的權限形成影響

5.13同一用戶是否能夠同時屬於其餘組，各個組的權限可否交叉

WEB端功能測試連接：

WEB端功能測試總結（一）

Web端功能測試總結（二）

推薦連接：Web測試究竟是在測試什麼？

 

 

APP： 

一、安全測試（權限）

①.軟件權限：其中包括髮送信息，撥打電話，連接網絡，訪問手機信息，聯繫人信息等

②.數據在本地的存儲、傳輸等

③.執行某些操做時致使的輸入有效性驗證、受權、數據加密等方面

④.基於各類通訊協議或者行業標準來檢查

 

二、安裝運行卸載測試

①.驗證app可否正確安裝運行卸載，以及操做過程和操做先後對系統資源的佔有狀況

②.安裝運行卸載的提示，報告等

③.檢查安裝路徑，文件是否合理，組件是否正確註冊等

 

三、UI測試

①.用戶界面（菜單、對話框、窗口）等佈局，風格是否知足用戶需求，文字位置，描述是否正確，界面美觀程度，文字圖片組合是否合理

②.用戶友好性、人性化、便於操做等

 

四、功能測試

①.評審需求，多方面考慮，整理出內在外在以及非功能性的直接間接功能點，對比需求，提取測試點

②.根據經常使用的一些分析方法，等價類邊界值斷定表因果圖場景法等方法，設計測試用例，對提取的功能點進行覆蓋

③.測試各個階段不斷跟蹤缺陷，作好用例的更新迭代和不斷變動需求所帶來的業務或者需求的錯誤

 

五、性能測試

①.極限測試：各類邊界狀況下驗證app的響應能力

如：低電量、儲存滿。弱網等狀況

②.響應能力測試：驗證各類狀況下不一樣操做可否知足用戶響應需求

③.壓力測試：反覆長期操做下，系統該資源的使用狀況

 

六、中斷測試（干擾）

好比：先後臺運行時來電話，短信，下載文件，聽音樂看電影等不一樣狀況下的表現

 

七、兼容測試

①.不一樣網絡環境（WiFi、2G、3G、4G等）

②.各類設備品牌機型系統版本等兼容：蘋果、安卓（不一樣品牌，不一樣安卓系統版本）等

八、迴歸測試

bug修復後的迴歸測試，上線交付前進行所有的迴歸，驗證

 

九、升級更新測試

每次app版本迭代更新時，配合不一樣網絡環境，及不一樣更新權限（強制更新，不強制更新），進行下載、安裝、更新、啓動運行等測試

 

十、支付測試

①.支付結果的確認，數據庫查詢

②.請求報文是否加密

③.不一樣場景的支付

金額足夠、金額不足、重複支付、無網支付、弱網支付、同帳號多平臺一塊兒支付、餘額寶微信信用卡多種支付方式、不一樣支付方式的組合、密碼正確/錯誤、支付上限等狀況

App端功能測試連接：

App測試總計

 

7、集成測試

一、定義

也稱爲組裝測試，聯合測試，主要針對軟件高層設計進行測試，通常以模塊和子系統爲單位進行測試

 

二、集成測試的層次

①.模塊內集成，主要測試各個接口的交互

②.子系統內集成，子系統內各個模塊的交互

③.系統集成，測試系統內各個子系統和模塊的交互關係

 

三、集成測試的本質

不只僅代碼編譯經過就算集成，而是全部模塊子系統能正常運轉，通常採用的方法是數據驅動，集成測試不看系統表象，而是對數據流進行分析，可分爲自頂向下、自下向上、核心集成、分層集成等方法   

 

四、集成測試方法和步驟

①.肯定子系統的模塊組成，保證這些模塊都已經過單元測試

②.由開發組裝這麼模塊，生成子系統，保證模塊內功能儘量發揮出來

③.設計測試用例，以一個關鍵模塊爲核心展開，圍繞功能和性能，測試接口

④.搭建測試環境，按照用例進行測試

⑤.記錄測試結果，總結問題  

 

8、系統測試

一、什麼是系統測試

定義:檢查系統是否能完成需求說明的內容，對系統能正常、完整的運行；其中包括軟件、硬件和相關聯的設備、測試數據

 

二、系統測試的目的

目的：模擬真實系統工做環境下經過與系統需求做比較，檢驗完整的軟件配置項可否和系統正確鏈接，發現軟件與系統/子系統之間與需求設計文檔不符合或矛盾的地方

 

三、系統測試的目標

目標：功能是否達到規格說明書要求，是否存在其餘缺陷，是否有完善到缺陷記錄及跟蹤等

 

四、系統測試的測試類型

功能測試

性能測試

負載測試

容量測試

安全性測試

用戶界面測試

配置測試

安裝測試

迴歸測試

 

五、測試環境

開發環境

測試環境

用戶環境

 

六、經常使用方法

①.黑盒測試

多任務測試：同一時間內運行多個應用程序

臨界測試：系統臨界和應用系統臨界

中斷測試：軟件在工做過程當中被其餘任務或意外事件終止當前正在進行的程序

1.人爲中斷

2.硬件異常中斷

3.程序執行中斷

4.意外中斷                

②.自動化測試

以前已介紹過，此處略過

 

七、結果分析

①.響應時間的性能測試

②.可靠性分析

③.強度測試

④.安裝測試

⑤.恢復測試

 

9、驗收測試

一、驗收測試的首要條件

①.軟件開發已完成，而且已修復已知缺陷

②.驗收測試計劃已被批准

③.對軟件需求說明文檔審查已完成

④.全部關鍵模塊的代碼審查已完成

 

二、驗收測試的目的

①.驗收系統是否按照需求文檔開發，用戶體驗是否達到用戶要求，與設計要求差距大小，完成的功能水平

②.驗收系統是否達到了雙方共識

③.驗收系統的可靠性和維護性

④.驗收系統的業務運行處理能力

 

三、驗收測試的過程

①.驗收人員要熟悉軟件的功能和性能要求、軟硬件環境要求，以及質量和驗收要求

②.要有相應的驗收要求文檔，規格要求

③.根據驗收要求進行驗收測試，結果要出具報告，就行評審

 

四、驗收測試的主要內容

①.軟件是否知足需求文檔規定的全部功能和性能的要求

②.文檔資料等是否完整？

③.對功能測試、集成測試、系統測試、性能測試、安全測試等用例進行迴歸

 

五、驗收測試的原則

①.審查提供驗收的各種文檔的正確性、完整性和統一性

②.審查項目功能是否達到設計需求說明書規定的要求

③.審查項目有關指標是否達到要求

④.審查項目實施進度

⑤.對項目技術等水平作評估，得出項目的驗收報告

 

六、驗收測試的要點

①.流程測試

②.邊界值測試

③.容錯性測試

④.異常測試

⑤.安裝配置測試

 

10、迴歸測試

在軟件開發的各個階段，均可能進行若干次迴歸測試，其在整個測試過程當中佔很大比重

一、什麼是迴歸測試

只要軟件發生修改，那麼久須要從新測試，以肯定修改的軟件功能是否達到了預期目的，以及修改可能產生的新的問題（已修改部分對原功能產生影響）

 

二、迴歸測試的目的

確認軟件通過修改或變動後是否仍知足全部的需求

迴歸測試是重複測試，要求使用相同的方法、測試用例和數據，在相同的環境下測試

 

三、迴歸測試的範圍

①.測試全部修改或修正過的功能模塊

②.測試與被修改模塊相關的模塊

③.測試全部新增長的模塊

④.測試整個模塊

 

四、發生在何時

每次有改動或者需求迭代變動時候

 

五、爲何作迴歸測試

驗證新功能，保證舊功能不被影響

 

11、配置測試

一、什麼是配置測試

測試驗證被測軟件在不一樣軟件和硬件條件中運行的狀況，覆蓋各類軟件、硬件環境，其實質就是測試軟件是否與其餘與之交互元素之間的兼容（好比瀏覽器、操做系統、硬件）

 

二、爲何要作配置測試

測試軟件的容錯性、發現隱藏的bug，以及其對產品的影響，獲得最佳的配置

 

三、硬件環境配置測試

①.不一樣主機的配置測試

②.不一樣組件的配置測試

③.不一樣外設的配置測試

④.不一樣接口的配置測試

⑤.可選項的配置測試

 

四、軟件環境配置測試

①.不一樣操做系統平臺兼容性測試

②.同一操做系統不一樣版本兼容性測試

③.軟件自己向前向後兼容測試

④.軟件自己與其餘軟件兼容測試

⑤.數據兼容測試

 

轉載至：http://www.cnblogs.com/imyalost/p/6144862.html