1、軟體測試概述
軟體測試的IEEE定義:使用人工或自動的手段來執行或測量軟體系統的過程,目的是檢驗軟體系統是否滿足規定的需求,並找出與預期結果之間的差異。軟體測試的發展趨勢:
① 測試工作將進一步前移。軟體測試不僅僅是單元測試、整合測試、系統測試和驗收測試,還對需求的精確性和完整性的測試技術、對系統設計的測試技術將成為新的研究熱點。
② 軟體架構師,開發工程師,QA人員,測試工程師將進行更好地融合
④ 設定獨立的軟體測試部門將成為未來軟體公司的共識。
⑤ 測試外包服務將快速增長,和軟體開發外包一樣,軟體測試外包將成為全球化的趨勢。
軟體測試工程師的素質:
責任心;溝通能力;團隊合作精神;耐心、細心和信心;保持懷疑的態度,有缺陷預防的意識;不斷學習的能力。
合格的測試工程師應具有的能力:
① 一般能力:包括表達、交流、協調、管理、質量意識、軟體開發過程方法、軟體工程等;
② 測試技能及方法:包括測試基本概念及方法、對測試工具的掌握、對專業測試標準的熟悉程度等;
④ 測試執行能力:包括測試資料/指令碼/用例的制定能力、測試比較及分析能力、缺陷記錄及處理能力;
⑤ 測試分析、報告和改進能力:包括測試度量、統計技術、測試報告、過程監測及持續改進能力。
測試工程師的職責:
測試人員要了解專案需求內容,從使用者的角度提出自己的測試看法;
測試人員要編寫合理的測試計劃並與專案整體計劃有機地整合在一起;
測試人員要編寫覆蓋率高的測試用例;測試人員要認真仔細地實施測試工作,並提交測試報告以供專案參考;
測試人員要進行缺陷跟蹤和分析。
2、軟體測試基礎軟體的概念軟體是計算機系統中與硬體相互依存的一部分,包括程式、資料、與其相關文件的完整結合。軟體 = 程式 + 資料 + 文件。
軟體的特點:
① 軟體是一種邏輯體,而不是具體的物理體,因而它具有抽象性;
② 軟體的生產與硬體不同,它沒有明顯的製造過程,對軟體質量的控制,必須在開發方面下功夫;
④ 軟體的開發和執行常常受計算機系統的制約,對計算機系統有著不同程度的依賴性,為了解除這種依賴性,在軟體開發過程中提出了軟體移植問題。
⑤ 軟體本身是複雜的,軟體的複雜性可能來自它所反映問題的複雜性,也可能來自程式邏輯結構的複雜性。
⑥ 軟體成本的昂貴。軟體的研製工作需要投入大量的、複雜的、高強度的腦力,它的成本比較高。
軟體的分類:
按照功能劃分:
系統軟體:如作業系統、資料庫管理系統,各種驅動軟體等
應用軟體:如Office、金山詞霸、QQ等
按照技術結構劃分:
單機版本:如Office,畫圖工具等
C/S結構軟體:如QQ、MSN等
按照使用者劃分:
產品軟體:Office、財務處理軟體、金山毒霸等
專案軟體:如為企業定製的OA系統等
按照開發規模劃分:
類別 參與人數 開發時間
小型 10人以下 1-4個月
中型 10-100人 1年以下
大型 100人以上 1年
軟體測試的概念:
軟體測試就是為了發現錯誤而執行程式的過程(狹義觀點)。
使用人工或自動的手段,來執行或測試軟體系統的過程,目的是檢驗軟體系統是否滿足規定的需求,並找出與預期結果之間的差異。(標準定義IEEE )
軟體測試就是為了證明程式有錯,而不是證明程式無錯誤(辨證觀點) 。
測試被定義為“對軟體系統中潛在的各種風險進行評估的活動”。(風險觀點)軟體測試就是“驗證(Verification)”和“有效性確認(Validation)”活動構成的整體,即軟體測試V&V 。(標準觀點)
要完整理解軟體測試,就要從不同方面去審視軟體測試,概括起來,軟體測試就是貫穿整個軟體開發生命週期,對軟體產品(包括階段性產品)進行驗證和確認的活動過程,其目的是儘快儘早地發現在軟體的缺陷。
軟體測試的物件:
① 源程式/目的碼
② 各開發階段的文件(需求規格說明、概要設計說明、詳細設計說明及其它相關文件)
軟體測試的目的:
從使用者角度看的目的:透過軟體測試發現隱藏的錯誤和缺陷,考慮是否可以接受該產品。從開發者角度看的目的:表明軟體產品不存在錯誤,驗證軟體實現了所有使用者的要求。從測試人員角度看的目的:發現錯誤,預測錯誤,提供軟體可靠性錯誤,對軟體做出評價。
① 幫助開發人員、測試工程師發現問題、分析問題。
② 減少軟體的缺陷數目或者降低軟體缺陷的密度。
④ 評估軟體的效能指標。
⑤ 增加使用者對軟體的信心。
⑥ 測試的最終目的是儘快儘早地發現在軟體中的缺陷,透過修正各種錯誤和缺陷提高軟體質量,迴避軟體釋出後由於潛在的軟體缺陷和錯誤造成的隱患所帶來的商業風險。
軟體測試的原則:
① 所有測試的都應追溯到使用者需求。
② 應當把“儘早地和不斷地進行軟體測試”作為軟體測試者的座右銘。
④ 完全測試是不可能的,測試需要終止。
⑥ 測試無法顯示軟體潛在的缺陷:進行測試是可以查詢並報告發現的軟體缺陷和錯誤,但不能保證軟體缺陷和錯誤全部找到。
⑦ 充分注意集試中群集現象(二八定理):經驗表明,在所測試程式段中,若發現的錯誤數目多,則殘存的錯誤數目也較多。缺陷的二八定理指的是,一般情況下,80%軟體缺陷出現在20%的功能區域,在測試過程中,投入主要的人力和精力重點測試這20%的功能區域。
⑨ 儘量避免測試的隨意性:應從工程的角度理解測試,它是有組織、有計劃、有步驟的活動。
軟體測試誤區:
誤區一:如果釋出出去的軟體有質量問題,都是軟體測試人員的錯。
誤區二:軟體測試技術要求不高,至少比程式設計容易多了。
誤區三:有時間就多測試一些,來不及就少測試一些。
誤區四:軟體測試是測試人員的事,與開發人員無關。
誤區五:根據軟體開發瀑布模型,軟體測試是開發後期的一個階段。
3、軟體測試分類單元測試:
單元測試又稱模組測試,針對軟體設計中的最小單位——程式模組,進行正確性檢查的測試工作。單元測試需要從程式的內部結構出發設計測試用例。多個模組可以平行地獨立進行單元測試。
單元定義:
C中指一個函式,Java中指一個類,在圖形化的軟體中,單元一般指1個視窗,1個選單。如何進行單元測試:單元測試主要用白盒測試,先靜態地檢查程式碼是否符合規範,然後動態執行程式碼,檢查其實際執行結果,檢查程式的執行結果是否正確是一個最基本的要求,還要關注容錯處理,程式的邊界值處理等。
整合測試:
整合測試又叫組裝測試,通常在單元測試的基礎上,將所有程式模組進行有序的、遞增的測試。重點測試不同模組的介面部分。
系統測試:
指將整個軟體系統看為一個整體進行測試,包括對功能、效能、以及軟體所執行的軟硬體環境進行測試。
驗收測試:
驗收測試指按照專案任務書或合同、供需雙方約定的驗收依據文件進行的對整個系統的測試與評審,決定是否接收或拒收系統。在系統測試的後期,以使用者測試為主或有測試人員等質量保證人員共同參與的測試。
α測試:指的是指的是由使用者,測試人員、開發人員等共同參與的內部測試。
β測試:指的是內測後的公測,即完全交給終端使用者測試驗收測試的重要性:驗收簽字,收錢。
靜態測試:指不實際執行被測軟體,而只是靜態地檢查程式程式碼、介面和文件中可能存在的錯誤的過程。
動態測試:指實際執行被測程式,輸入相應的測試資料,檢查實際輸出結果與預期結果是否相符。(動態測試方法為結構和正確性測試;動態測試工具Robot、QTP等)
黑盒測試:指的是把被測的軟體看做一個黑盒子,我們不關心盒子裡面的結構是什麼樣子的,只關心軟體的輸入資料和輸出
白盒測試:指的是把盒子開啟,去研究裡面的原始碼和程式結構。軟體公司中,往往採用黑盒測試&白盒測試相結合的方式。
靜態黑盒測試:看文件,看頁面等 靜態白盒測試:開原始碼等 動態黑盒測試:使用軟體等 動態白盒測試:執行原始碼等灰盒測試:是介於白盒測試與黑盒測試之間的一種測試,灰盒測試多用於整合測試階段,不僅關注輸出、輸入的正確性,同時也關注程式內部的情況。
功能測試:是黑盒測試的一方面,它檢查實際軟體的功能是否符合使用者的需求。
邏輯功能測試(functiontesting)
介面測試(UItesting)
易用性測試(usability testing)
安裝測試(installationtesting)
相容性測試(compatibilitytesting)
效能測試:是軟體測試的高階領域,通常我們所說的高階軟體測試工程師一般就是指效能測試或是白盒測試工程師。時間效能(事務響應時間等)空間效能(系統資源消耗)一般效能測試可靠性測試負載測試壓力測試
迴歸測試:指對軟體的新版本測試時,重複執行上一個版本測試時的用例。
冒煙測試:是指在對一個新版本進行系統大規模的測試之前,先驗證一下軟體的基本功能是否實現,是否具備可測試性。
隨機測試:是指測試中所有的輸入資料都是隨機生成的,其目的是模擬使用者的真實操作,並發現一些邊緣性的錯誤。
軟體測試的過程:從軟體開發的過程按階段劃分有:需求驗證、單元測試、整合測試、確認測試、系統測試、驗收測試
4、白盒測試用例設計方法測試用例(英文為TestCase,縮寫為TC):指的是在測試執行之前設計的一套詳細的測試方案,包括測試環境、測試步驟、測試資料和預期結果。測試用例可以針對黑盒測試設計用例,也可以針對白盒測試設計用例。編寫測試用例的唯一標準就是使用者需求,具體的參考資料是《需求規格說明書》。
設計測試用例的原因:軟體測試是一項有組織、有計劃、有步驟的活動,為了將軟體測試的行為轉換為可管理的、具體量化的模式,需要建立和設計測試用例。
測試用例的四性:
代表性:能夠代表並覆蓋各種合理的和不合理合法的和不合法的、邊界的和越界的以及極限的輸入資料、操作等。
針對性:對程式中的可能存在的錯誤有針對性地測試。
可判定性:測試執行結果的正確性是可判定的,每一個測試用例都應有相應的期望結果。
可重現性:對同樣的測試用例,系統的執行結果應當是相同的。
測試用例的基本原則:
利用成熟的測試用例設計方法來指導設計
測試用例的針對性
測試用例的代表性
測試用例的可判定性
測試用例的可重現性足夠詳細、準確和清晰的步驟
測試用例必須符合內部的規範的要求
語句覆蓋:語句覆蓋就是設計若干個測試用例,執行被測試程式,使得每一條可執行語句至少執行一次;
判定覆蓋(也稱為分支覆蓋):設計若干個測試用例執行所測程式使程式中每個判斷的取真分支和取假分支至少執行一次;
條件覆蓋:設計足夠多的測試用例,執行所測程式,使程式中每個判斷的每 條件覆蓋設計足夠多的測試用例 行所測程式使程式中每個判斷的每個條件的每個可能取值至少執行一次;
判定-條件覆蓋:設計足夠多的測試用例,執行所測程式,使程式中每個判斷的每個條件的所有可能取值至少執行一次,並且每個可能的判斷結果也至少執行一次,換句話說,即是要求各個判斷的所有可能的條件取值組合至少執行一次;
條件組合測試:設計足夠多的測試用例,執行所測程式,使程式中每個判斷的所有可能的條件取值組合至少執行一次;
路徑測試:設計足夠多的測試用例,執行所測程式,要覆蓋程式中所有可能的路徑。
主要測試技術:分支條件覆蓋,基本路徑測試5、黑盒測試用例設計方法
主要測試技術:等價類劃分(邊界值分析),因果圖法,(正交實驗法)
6、缺陷管理軟體缺陷軟體缺陷:
是指存在於軟體(程式、資料、文件)中的那些不符合使用者需求的問題。
編碼:純粹是由編碼的問題引起。
其它:可能是系統整合、測試引起。
軟體缺陷的根源:交流不充分(客戶與開發人員、開發人員與測試人員等)軟體的複雜性(功能複雜、開發複雜、測試複雜)開發人員的錯誤(對需求的理解、開發壓力、能力與經驗)需求的變化(需求說明書設計文件 程式的變更)進度壓力(專案週期比較緊)
軟體缺陷的發現手段:同行評審、測試、管理評審、QA發現、專案組內部發現、客戶反饋為了便於缺陷的定位、跟蹤和修改,要對所發現的缺陷,按照缺陷的嚴重程度、優先順序、發現階段、修復階段、缺陷的性質、所屬功能模組、系統環境等方面進行分類和統計。
二八定理:80%的軟體問題總是發生在大約20%的功能模組中。
缺陷密度:基本的缺陷測量是以每千行程式碼的缺陷數(個/KLOC)來測量的,其測量單位是defects/KLOC。
常見尋找bug的方法:色彩、功能結構佈局、圖片、頁面大小、字型、窗體大小、介面文字、容錯處理(也為功能缺陷,所謂容錯,就是容忍錯誤的能力。當用戶在使用軟體過程中發生錯誤後,軟體應該能給出引導資訊,指應使用者進行正確的操作)、資料轉換(增刪改查)、效能缺陷(黑盒測試)。
Web測試:
Web測試即測試網站系統在不同客戶端(瀏覽器)的執行情況及相容性。
Selenium:
Selenium是一個用於Web應用程式測試的工具。Selenium測試直接執行在瀏覽器中,就像真正的使用者在操作一樣。