软件测试的基础知识
1.1測試的方法
| 測試方法 | 內容描述 |
| 系統測試 | 系統測試是通過與系統的需求規格作比較-，發現軟件與系統需求規格不相符合或與之矛盾的地方。它將通過確認測試的軟件，作為整個基于計算機系統的一個元素，與計算機硬件、外設、某些支持軟件、數據和人員等其他系統元素結合起來，在實際運行（使用）環境下，對計算機系統進行的測試。 |
| ? 功能測試 | 就是對產品的各功能進行驗證，根據功能測試用例，逐項測試，檢查產品是否達到用戶要求的功能。是基于用戶觀點出發的測試，主要是驗證功能是否符合需求，包括原定功能的檢驗、是否有冗余功能、遺漏功能。功能測試也叫黑盒測試。通常又將黑盒測試叫做：基于規格的測試、輸入輸出測試、功能測試或數據驅動測試。 |
| 安全測試 | 主要是測試系統在沒有授權的內部或者外部用戶對系統進行攻擊或者惡意破壞時如何進行處理，是否仍能保證數據的安全。測試人員可以學習一些黑客技術，來對系統進行攻擊。 |
| 壓力測試 | 對系統不斷施加壓力的測試，是通過確定一個系統的瓶頸或者不能接收的性能點，來獲得系統能提供的最大服務級別的測試。例如測試一個Web?站點在大量的負荷下，何時系統的響應會退化或失敗。 |
| 接口測試 | 程序員對各個模塊進行系統聯調的測試，包含程序內接口和程序外接口測試。這個測試，在單元測試階段進行了一部分工作，而大部分都是在集成測試階段完成的。建議由開發人員進行。 |
| 兼容性測試 | 兼容性測試是指測試軟件在特定的硬件平臺上、不同的應用軟件之間、不同的操縱系統平臺上、不同的網絡等環境中是否能夠很友好的運行的測試。 |
| 性能測試 | 在交替進行負荷和強迫測試時常用的術語。性能測試關注的是系統的整體。它和通常所說的強度、壓力/負載測試有密切關系。所以壓力和強度測試應該于性能測試一同進行。 |
| 可靠性測試 | 這里是比較狹義的可靠性測試，它主要是對系統能否穩定運行進行一個統計，在實際工作中如果沒有條件可以不必特意去做。重點做好與之緊密相關的功能測試、健壯性測試就可以了。 |
?
?
?
?
1.1.1?系統測試
??系統測試的概念
?
系統測試就是將已經集成好的軟件系統，作為整個計算機系統的一個元素，與計算機硬件、外設、某些支持軟件、數據和人員等其它系統元素結合在一起，在實際運行（使用）環境下，對計算機系統進行一系列的組裝測試和確認測試。
?
??系統測試的目的
?
系統測試的目的在于通過與系統的需求定義比較，檢查軟件是否存在與系統定義不符合或與之矛盾的地方，以驗證軟件系統的功能和性能等滿足其規約所指定的要求。發現缺陷并度量產品質量，按照系統的功能和性能需求進行的測試。
一般使用黑盒測試技術
一般由獨立的測試人員完成
是檢驗所開發的軟件是否按軟件需求規格說明中確定的軟件功能、性能、約束及限制等技術要求進行工作
從用戶的角度出發進行測試
?
??系統測試的意義
1）系統測試的環境是軟件真實運行環境的最逼真模擬。系統測試中，各部分研制完成的真實設備逐漸替代了模擬器，是軟件從未有過的運行環境。有關真實性?的一類錯誤，包括外圍設備接口、輸入/輸出、或多處理器設備之間的接口不相容，整個系統的時序匹配等，在這種運行環境下能得到比較全面的暴露。?
2）通常系統測試的困難在于不容易從系統目標直接生成測試用例。而系統測試由系統人員組織，從系統完成任務的角度測試，軟件在系統測試下獲得了系統任務下直接的“測試實例”，這對檢驗軟件是否滿足系統任務要求是非常有意義的。
?
1.1.2?功能測試
??功能測試的目的和內容
?
2??程序安裝、啟動正常，有相應的提示框、錯誤提示等
2??每項功能符合實際要求
2??系統的界面清晰、美觀
2??菜單、按鈕操作正常、靈活，能處理一些異常操作
2??能接受正確的數據輸入，對異常數據的輸入有提示、容錯處理等
2??數據的輸出結果準確，格式清晰，可以保存和讀取
2??功能邏輯清楚，符合使用者習慣
2??系統的各種狀態按照業務流程而變化，并保持穩定
2??支持各種應用的環境
2??能配合多種硬件周邊設備
2??軟件升級后，能繼續支持舊版本的數據
2??與外部應用系統的接口有效?
?
如：
???1.頁面鏈接檢查???
???2.相關性檢查?
???3.檢查按鈕的功能是否正確?
???4.字符串長度檢查
???5.字符類型檢查?
???6.標點符號檢查?
???7.中文字符處理? ??
???8.檢查帶出信息的完整性
???9.信息重復? ??
???10.檢查刪除功能
???11.檢查添加和修改是否一致?
???12.檢查修改重名?
???13.重復提交表單
???14.檢查多次使用back鍵的情況?
???15.?search檢查?
???16.輸入信息位置
???17.上傳下載文件檢查
???18.必填項檢查
???19.快捷鍵檢查
???20.回車鍵檢查
1.1.3?性能測試
??性能測試的概念
?
性能測試通常會使用特定的測試工具，來模擬超常的數據量、負載等，監測系統的各項性能指標，如CPU和內存的使用情況、響應時間、反應速度等。?
?
??性能測試的目的?
為了驗證系統是否達到用戶提出的性能指標，同時發現系統中存在的性能瓶頸，起到優化系統的目的。
?①?能力驗證
?②?能力規劃
?③?性能調優
?④?缺陷發現
如，一般用戶登錄系統都是小于3S
?
??性能測試指標的來源
用戶對各項指標提出的明確需求；如果用戶沒有提出性能指標則根據用戶需求、測試設計人員的經驗來設計各項測試指標。（需求+經驗）
?
??主要的性能指標
服務器的各項指標（CPU、內存占用率等）、后臺數據庫的各項指標、網絡流量、響應時間。
響應時間
從應用系統發出請求開始，到客戶端接收到最后一個字節數據為止所消耗的時間。
合理的響應時間取決于實際的用戶需求。
并發用戶數
一般是指同一時間段內訪問系統的用戶數量。
???系統用戶數，在線用戶數
吞吐量
單位時間內系統處理的客戶請求數量。
性能計數器
描述服務器或操作系統性能的一些數據指標，比如Windows系統資源管理器。
如：
中指標CPU占用率（CPU?utilization），如果該值持續超過95%，表明瓶頸是CPU。可以考慮增加一個處理器或換一個更快的處理器?。合理使用的范圍在60%至70%。
?
??性能測試要點
?
（1）測試環境應盡量與產品運行環境保持一致，應單獨運行盡量避免與其他軟件同時使用。
（2）性能測試一般使用測試工具和測試人員編制測試腳本來完成。
（3）性能測試的重點在于前期數據的設計與后期數據的分析。
（4）性能測試的用例主要涉及到整個系統架構的問題，所以測試用例一旦生成，改動一般不大，所以做性能測試的重復使用率一般比較高。
?
??性能測試的過程
如：
對于LMS項目，我們至少需要可以測試這些性能指標：服務器響應速度、客戶端上傳下載文件的速度和文件大小、能同時支持的在線人數、系統運行的可靠性（穩定性）、郵箱容量、郵件收發速度、審批的響應時間。
1.1.4?壓力測試
??壓力測試的概念
?
壓力測試是指在正常資源下使用異常的訪問量、頻率或數據量來執行系統。在一種需要反常（如長時間的峰值）數量、頻率或資源的方式下，執行可重復的負載測試，以檢查程序對異常情況的抵抗能力，找出性能瓶頸。
在壓力測試中可執行以下測試：
?
①如果平均中斷數量是每秒一到兩次，那么設計特殊的測試用例產生每秒十次中斷。
②輸入數據量增加一個量級，確定輸入功能將如何響應。
③在虛擬操作系統下，產生需要最大內存量或其它資源的測試用例，或產生需要過量磁盤存儲的數據。
?測試壓力估算?
?測試環境準備?
?問題的分析?
?累積效應?
?
??壓力測試的類型
??壓力測試的目的
?
壓力測試一般用于測試系統的穩定性。
如果一個系統能夠在壓力環境下穩定運行一段時間，那么該系統在普遍的運行環境下就應該可以達到令人滿意的穩定程度。
在壓力測試中，通常會考察系統在壓力下是否會出現錯誤等方面的問題。
?
??壓力測試和性能測試的區別
1.1.5?安全測試
安全測試用來驗證系統內部的保護機制，以防止非法侵入。要驗證系統內的保護機制能否抵御入侵者的攻擊。在安全測試中，測試人員扮演試圖侵入系統的角色，采用各種辦法試圖突破防線。因此系統安全設計的準則是要想方設法使侵入系統所需的代價更加昂貴。
如：
??用戶ID及密碼的設立限制是否有效
??登陸失敗次數的限制是否有效
??用戶ID及密碼的存儲是否加密
??用戶密碼是否可以剪貼
??登陸后空機時間控制是否有效
??登陸后是否按用戶資格規定在授權范圍內操作
??登陸完畢退出后，是否仍可以利用瀏覽器“退回”按鈕回到登陸才可以進入的網頁而不需要重新登陸
??登陸后將任意一網頁的URL存起，然后退出，再將該URL貼上瀏覽器地址欄，看是否可以繞道進入而不需登陸
??如果測試的軟件包含數據庫，則所有以用戶輸入數據作為數據庫查詢語句組成部分的地方，都要找出是否允許一些SQL語言中有特殊意義的字符（如’，”，；，*，%，_等）在輸入數據中出現，以保護數據庫所有數據的完整性
??專門開發軟件來破壞系統的保護機制
???故意導致系統失敗，企圖趁恢復之機非法進入
???試圖通過瀏覽非保密數據，推導所需信息
??網頁顯示出錯信息時不應顯示一些敏感的資料。如向用戶顯示出錯的某個文件存放處。
例如：File?Not?Found:?\\MachineName\SecretDir\SomeSubDir\xFile
?
評價標準：有效性；生存性；精確性；出錯反應時間；吞吐量
?
v?特別聲明：
理論上講，只要有足夠的時間和資源，沒有不可進入的系統。因此系統安全設計的準則是，使非法侵入的代價超過被保護信息的價值，此時非法侵入者已無利可圖。
?
1.1.6?容錯性測試
??容錯性測試的概念
?
也叫做健壯性測試
主要用于測試系統抵御錯誤的能力。這里的錯誤通常指的是由于設計缺陷而帶來的系統錯誤。測試的重點為當出現故障時，是否能夠自動恢復或忽略故障繼續運行。
?
??容錯性測試有兩層含義
?
2?一是高可靠性
?
它體現了軟件系統的質量；
需要根據符合規格說明的數據選擇測試用例，用于檢測在正常情況下系統輸出的正確性。
2?二是從錯誤中恢復的能力
?
它體現了軟件系統的適應性；
需要在異常數據中選擇測試用例，檢測非正常情況下的系統行為。
1.1.7可用性測試
可用性測試是面向用戶的系統測試。
進行可用性測試時，測試人員應該關注如下幾個方面：
2?系統中是否存在繁瑣的功能以及指令；
2?安裝過程是否復雜；
2?錯誤信息提示內容是否詳細；
2?GUI接口是否標準；
2?登錄是否方便；
2?需要用戶記住內容的多少；
2?幫助文本是否詳細；
2?頁面風格是否一致；
2?是否會造成理解上的歧義。
2?執行的操作是否與預期的功能相符，如點擊保存按鈕時記錄是否存入數據庫。
?
1.1.8?GUI測試
v?GUI----Graphical?User?Interface，圖形用戶界面
?
2?GUI測試是對圖形用戶界面進行的測試。一般來說，當一個軟件產品完成GUI設計后，就確定了它的外觀架構和GUI元素。
2?GUI測試主要核實用戶與軟件之間的交互，驗證用戶界面中的對象是否按照預期的方式進行，并符合國家或行業的標準。
2?優秀的用戶界面（UI）應具有7個要素：
符合標準和規范：
?
是否具有良好的可操作性和友好的界面效果，界面測試的目的是否能最大程度的滿足用戶的使用要求，通過測試，把系統的不足之處，并加以改進
?
1.1.9?兼容性測試
??兼容性測試目的
?
就是檢驗被測應用對其他應用或者系統的兼容性，比如在對一個共享資源（數據、數據文件或者內存）進行操作時，檢測兩個或多個系統需求能否正常工作以及相互交互使用。
?
在做兼容性測試時，要主要關注如下幾個問題：
①當前系統可能運行在哪些不同的操作系統環境下？
②當前系統可能與哪些不同類型的數據庫進行數據交換？
③當前系統可能運行在哪些不同的硬件配置的環境上？
④當前系統可能需要與哪些軟件系統協同工作？這些軟件系統可能的版本有哪些？
⑤是否需要綜合測試？
1.1.10?恢復測試
??恢復性測試的目標
?
就是驗證系統從軟件或者硬件失敗中恢復的能力。在測試過程中會采取各種人工干預方式使軟件出錯，而不能正常工作，進而檢驗系統的恢復能力。
????在進行恢復性測試時，同樣首先要進行恢復性測試分析，經常要考慮的主要問題有如下幾個：
1）恢復期間的安全性過程；
2）恢復處理日志方面的能力；
3）當出現供電問題時的恢復能力；
4）恢復操作后系統性能是否下降。
1.1.11?回歸測試
??回歸測試的概念
?
回歸測試是在軟件發生變動時保證原有功能正常運作的一種測試策略和方法。
回歸測試不需要進行全面的測試，而是根據修改的情況進行有選擇性的測試。
這里所說的保證軟件原有功能正常運作，可以從兩方面來理解：
??回歸測試的目的?
?
2?所做的修改達到了預期的目的，例如缺陷得到了修改，新增加的功能得到了實現；
2?軟件的修改沒有引入新的缺陷，沒有影響原有的功能實現。
2?不影響軟件原有功能的正確性。
?
???回歸測試的方法
1．測試用例庫的維護
(1)?刪除過時的測試用例?
(2)?改進不受控制的測試用例?
(3)?刪除冗余的測試用例
(4)?增添新的測試用例?
2．回歸測試包的選擇?
(1)?再測試全部用例?
(2)?基于風險選擇測試?
(3)?基于操作剖面選擇測試?
(4)?再測試修改的部分?
1.1.12?驗收測試
??驗收測試的概念和目的
?
驗證系統是否達到了用戶需求規格說明書（可能包括項目或產品驗收準則）中的要求，測試試圖盡可能地發現軟件中存留的缺陷，從而為軟件進一步改善提供幫助，并保證系統或軟件產品最終被用戶接受。主要包括易用性測試、兼容性測試、安裝測試、文檔（如用戶手冊、操作手冊等）測試等幾個方面的內容。?
驗收測試是將程序與其最初的需求及最終用戶當前的需要進行比較的過程，是部署軟件之前的最后一個測試操作。
?
??驗收測試的步驟
?
2?制定測試計劃，測試項，測試策略及驗收通過準則，并經過客戶參與的計劃評審。
2?建立測試環境，設計測試用例，并經過評審。
2?準備測試數據，執行測試用例，記錄測試結果。
2?分析測試結果，根據驗收通過準則分析測試結果，作出驗收是否通過及測試評價。
l?測試項目通過；
l?測試項目沒有通過，并且不存在變通方法，需要很大的修改；
l?測試項目沒有通過，但存在變通方法，在維護后期或下一個版本改進；
l?測試項目無法評估或者無法給出完整的評估。此時必須給出原因。如果是因為該測試項目沒有說明清楚，應該修改測試計劃。?
2?提交測試報告
驗收測試報告，也稱為發布報告（Release?Report）
??驗收測試完成標準
?
完全執行了驗收測試計劃中的每個測試用例。
在驗收測試中發現的錯誤已經得到修改并且通過了測試或者經過評估留待下一版本中修改。?
完成軟件驗收測試報告。
?
注意事項：
必須編寫正式的、單獨的驗收測試報告
驗收測試必須在實際用戶運行環境中進行
由用戶和測試部門共同執行。如公司自開發產品，應由測試人員，產品設計部門，市場部門等共同進行。
v?特別說明：
實際上，以上多種測試內容并不是都要進行的，而是在制定測試策略和測試計劃的時候有不同的側重點，這與測試目標、測試資源、軟件系統特點和業務環境有關。
?
?
1.2測試人員的職責
1.2.1測試人力的資源
??測試團隊
?
l?測試團隊一般4-5人，還可細分為測試組
l?測試經理/測試組長
2?制定測試計劃和測試方案
2?分配測試任務并檢查測試進度
2?代表測試團隊與開發、產品、用戶溝通
2?實際測試
l?測試員
2?設計測試用例
2?執行測試用例并填寫缺陷報告
2?檢查缺陷處理結果
?
1.2.2測試員的效率
2?平均每個工作日發現3-5個Bug
2?平均每修正3個Bug，會引進1個新的Bug
2?平均75%的Bug會在單元測試階段解決掉
2?平均20%的Bug會在集成測試和系統測試階段解決掉
2?平均5%的Bug會被交付給用戶
2?普通大型民用軟件平均錯誤率5個/10,000LOC
2?電信/銀行/操作系統等軟件平均錯誤率5個/100,000LOC
?
v?說明：
l?軟件規模代碼行（LOC,?Line?of?Code）是軟件規模的一種量度，它表示源代碼行數。
l?對于圖片、Flash等非文本文件統計文件數量、文件大小；
l?對于文本文件統計文件數量、文本行數、字符數；
1.2.3測試和開發的人員比例
與產品大小、復雜度、質量要求相關
?
調查結果顯示：
測試人員最貧乏的：20個開發人員對1個測試人員?
測試人員最豐富的：15個開發人員對8個測試人員?
也有一個異常數據：4個開發人員對0個測試人員
平均比率是?4.52個開發人員對1個測試人員
最常見的情況是：3個開發人員對1個測試人員
其次是：2.5?個開發人員對1個測試人員??
多數是開發人員與測試人員比率是3:1?或更低（即2.5:1?或?2:1?）?
通常是1：3，即一個測試人員對3個開發人員。不同的公司、不同的團隊這個比例相差還是很多的。?
?
?比如微軟：微軟公司的測試人員與開發人員比例一般為1:1，甚至在Windows?2000開發團隊中，有1800個測試人員，900個開發人員，測試人員與開發人員比例為2:1。但是微軟的測試是包含了單元測試、自動化測試、測試工具開發、手工測試、本地化測試等多項測試內容。他們的軟件都經過了N多道測試工序的。如果單純指手工測試的話，比例就低很多了。
?國內的一些小企業，比例可能只有1：10；那是因為公司還在起步階段，市場影響力還不大，質量要求還不高的情況下。如果質量要求提升了，這個比例就遠遠不能達到要求了。
在Google(谷歌)公司，則測試人員與開發人員比例則很低，據谷歌公司的測試經理介紹，為1:10。
因此測試與開發的比例要基于幾個條件來確定：
·?項目要求的可靠性
·?必須測試的可配置的范圍
·?軟件的易測試程度
·?工具的可用性
·?測試人員和開發人員的經驗
·?必須堅持的質量標準
1.開發能力基線；開發能力強，產出質量好，測試的效率就高了，所需要投入的測試人頭就可以少些；即在相同的質量標準前提下，測試與開發的比例與開發能力基線成反比。
2.測試能力基線；測試人員能力強，一個抵三個，當然所需測試人頭就可以少些了；即在相同的質量標準前提下，測試與開發的比例與測試能力基線成反比。
3.公司對產品的質量要求；質量要求高，當然測試投入就要多些，質量要求低，測試投入就可以少些；即在開發測試能力相同的前提下，測試與開發的比例與質量要求成正比。
???所以談論測試與開發的比例都不能離開這幾個條件：公司對產品的質量要求；開發人員的能力；測試人員自身的能力。
1.3軟件文檔的分類
1.4測試等級的劃分
1.4.1?Bug嚴重程度分為四個級別
?
級別一：死機，數據丟失，主要功能喪失，系統懸掛
級別二：主要功能喪失，導致嚴重的問題，或致命的錯誤聲明
級別三：次要功能喪失，不太嚴重，如提示信息不太準確
級別四：微小的問題，對功能幾乎沒有影響，產品及屬性還可使用，如有錯別字
?
1.4.2優先級別分為四個級別：
?
級別一：必須立即修改
級別二：一天內修改
級別三：三天內修改
級別四：短期內無須解決或在下一版本中解決
說明：驗證程度越高，優先級越高，原有錯誤優先級高于新版本錯誤
同樣的bug重復修改的次數，是衡量開發人員工作效率的重要依據
?
1.4.3缺陷類型定義
本規范定義以下五類缺陷：
??A類——嚴重錯誤，包括：
1.?由于程序所引起的死機,非法退出
2.?死循環
3.?導致數據庫發生死鎖
4.?數據通訊錯誤
5??嚴重的數值計算錯誤
??B類——較嚴重錯誤，包括：
1.?功能不符
2.?數據流錯誤
3.?程序接口錯誤
4.?輕微的數值計算錯誤
??C類——一般性錯誤，包括：
1.?界面錯誤(詳細文檔)
2.?打印內容、格式錯誤
3.?簡單的輸入限制未放在前臺進行控制
4.?刪除操作未給出提示
??D類——較小錯誤，包括：
1.?輔助說明描述不清楚
2.?顯示格式不規范
3.?長時間操作未給用戶進度提示
4.?提示窗口文字未采用行業術語
5.?可輸入區域和只讀區域沒有明顯的區分標志
6.?系統處理未優化
??E類——其它（非缺陷）
1.光標跳轉設置不好，鼠標定位錯誤
2.一些建議性的問題
1.5測試的標準
1.5.1測試的標準
??第一種：以缺陷類型做為標準
軟件測試合格須符合以下標準
以上比例為錯誤占總測試模塊的比例。
軟件產品未經測試合格，不允許投運。
v?特別說明：
表格中的A.B.C.D.E類是指缺陷的類型
?
??第二種：以測試用例作為標準
一般有“基于測試用例”和“基于缺陷密度”兩種評比準則，在這里我們采用前者。
準則如下：
??功能性測試用例通過率達到100％；
??非功能性測試用例通過率達到95％；
??沒有高于優先級3以上的問題；
??一般是3-4個版本后bug數量減少，達到出貨的要求
備選通過辦法：
???根據實際情況由軟件開發部門的經理、項目經理和測試負責人等共同討論確定本階段是否結束。?
?
??第三種：以測試用例作為標準
?
測試停止的標準：
（1）.各個模塊或各個模塊下的各個功能的測試用例覆蓋為100%；
（2）.測試用例執行覆蓋率為100%，通過測試的測試用例所占必需在90%以上；
（3）.bug走勢圖中，系統錯誤、功能錯誤、數據處理錯誤在連續3個工作日內未出現bug，其他錯誤在連續3個工作日內未出現合計5個以上（含5個）錯誤。此時可對軟件停止測試。
1.5.2驗收測試停止的標準
2?軟件需求分析說明書中定義的所有功能已全部實現，性能指標全部達到要求。
2?在驗收測試中發現的錯誤已經得到修改，各級缺陷修復率達到標準
2?需求分析文檔、設計文檔和編寫實現一致
2?驗收測試工件齊全（測試計劃、測試用例、測試日志、測試通知單、測試分析報告，待驗收的軟件安裝程序）
1.5.3測試的修復率和覆蓋率標準
??缺陷修復率標準：
2?A.B級修復率應達到100%
2?C.D修復率應達到90%以上
2?E錯誤修復率應達到60%以上
?
??覆蓋率標準
2?語句覆蓋率最低不能小于80%（白盒測試時的語句覆蓋率）
2?測試用例執行覆蓋率應達到100%（功能測試用例均已執行）
2?測試需求執行覆蓋率應達到100%（業務測試用例均已執行）
第二章?測試的流程與規范
2.1測試-開發流程
2.1.1開發流程
2.1.2開發-測試流程圖
2.1.3測試流程圖
2.1.3.1計劃與設計階段
2.1.3.2實施測試階段
2.1.3.3測試總結
總結
- 上一篇： FFmpeg在Linux下搭建
- 下一篇： 时间序列信号处理（三）——局部均值分解L