軟件測試基礎知識大全

1. 1.   軟件生命週期(SDLC)的六個階段

一、問題的定義及規劃
      此階段是軟件開發方與需求方共同討論，主要肯定軟件的開發目標及其可行性。

二、需求分析
      在肯定軟件開發可行的狀況下，對軟件須要實現的各個功能進行詳細分析。需求分析階段是一個很重要的階段，這一階段作得好，將爲整個軟件開發項目的成功打下良好的基礎。"惟一不變的是變化自己。"，一樣需求也是在整個軟件開發過程當中不斷變化和深刻的，所以咱們必須制定需求變動計劃來應付這種變化，以保護整個項目的順利進行。

三、軟件設計
      此階段主要根據需求分析的結果，對整個軟件系統進行設計，如系統框架設計，數據庫設計等等。軟件設計通常分爲整體設計和詳細設計。好的軟件設計將爲軟件程序編寫打下良好的基礎。

四、程序編碼
此階段是將軟件設計的結果轉換成計算機可運行的程序代碼。在程序編碼中必需要制定統一，符合標準的編寫規範。以保證程序的可讀性，易維護性，提升程序的運行效率。

五、軟件測試
      在軟件設計完成後要通過嚴密的測試，以發現軟件在整個設計過程當中存在的問題並加以糾正。整個測試過程分單元測試、組裝測試以及系統測試三個階段進行。測試的方法主要有白盒測試和黑盒測試兩種。在測試過程當中須要創建詳細的測試計劃並嚴格按照測試計劃進行測試，以減小測試的隨意性。

六、運行維護
軟件維護是軟件生命週期中持續時間最長的階段。在軟件開發完成並投入使用後，因爲多方面的緣由，軟件不能繼續適應用戶的要求。要延續軟件的使用壽命，就必須對軟件進行維護。軟件的維護包括糾錯性維護和改進性維護兩個方面。

2、軟件生命週期模型

從概念提出的那一刻開始，軟件產品就進入了軟件生命週期。在經歷需求、分析、設計、實現、部署後，軟件將被使用並進入維護階段，直到最後因爲缺乏維護費用而逐漸消亡。這樣的一個過程，稱爲"生命週期模型"（Life Cycle Model）。

典型的幾種生命週期模型包括瀑布模型、快速原型模型、迭代模型。

瀑布模型的特色（文檔是主體），不少的問題在最後纔會暴露出來。迭代模型比瀑布模型問題暴露的要早；快速原型法比瀑布模型直觀。

3.軟件測試概念

廣義概念：指軟件生存週期中全部的檢查、評審和確認工做，其中包括了對分析、設計階段，以及完成開發後維護階段的各種文檔、代碼的審查和確認

狹義概念：識別軟件缺陷的過程，即實際結果與預期結果的不一致

4.軟件測試目的

ü  測試的目的就是發現軟件中的各類缺陷

ü  測試只能證實軟件存在缺陷，不能證實軟件不存在缺陷

ü  測試可使軟件中缺陷下降到必定程度，而不是完全消滅

ü  以較少的用例、時間和人力找出軟件中的各類錯誤和缺陷，以確保軟件的質量

5．軟件測試原則

ü  Good-enough: 一種權衡投入/產出比的原則

ü  保證測試的覆蓋程度，但窮舉測試是不可能的

ü  全部的測試都應追溯到用戶需求

ü  越早測試越好，測試過程與開發過程應是相結合的

ü  測試的規模由小而大，從單元測試到系統測試

ü  爲了儘量地發現錯誤，應該由獨立的第三方來測試

ü  不能爲了便於測試擅自修改程序

ü  既應該測試軟件該作什麼也應該測試軟件不應作什麼

6．軟件測試的的重點

ü  測試用例的設計

–  測試用例的設計是整個軟件測試工做的核心

–  測試用例反映對被測對象的質量要求，決定對測試對象的質量評估

ü  測試工做的管理

–  尤爲是對包含多個子系統的大型軟件系統，其測試工做涉及大量人力和物力，有效的測試工做管理是保證有效測試工做的必要前提

ü  測試環境的創建

–  測試環境應該與實際測試環境一致

7．黑盒測試

ü  什麼是黑盒測試

–  又稱功能測試或數據驅動測試，是針對軟件的功能需求/實現進行測試，經過測試來檢測每一個功能是否符合需求，不考慮程序內部的邏輯結構

ü  黑盒測試方法

–  功能劃分

–  等價類劃分

–  邊界值分析

–  因果圖

–  錯誤推測等

8．什麼是白盒測試

–  白盒測試也稱結構測試或邏輯驅動測試，必須知道軟件內部工做過程，經過測試來檢測軟件內部是否按照需求、設計正常運行

–  白盒測試的主要方法

–  對應於程序的一些主要結構：語句、分支、邏輯路徑、變量；白盒測試的主要方法是：

–  語句覆蓋方法

–  分支覆蓋方法

–  邏輯覆蓋方法

1. 9.   什麼是動態測試

動態測試須要在開發/測試環境或實際運行環境中運行軟件，並使用測試用例去查找軟件缺陷；動態測試包括功能確認與接口測試、覆蓋率分析、性能分析、內存分析等 

10.什麼是靜態測試

靜態測試不實際運行軟件，主要是對軟件的編程格式、結構等方面進行評估.靜態測試包括代碼檢查、程序結構分析、代碼質量度量等。它能夠由人工進行，也能夠藉助軟件工具自動進行

11.手工測試和自動測試

a.手工測試缺點在於測試工做量大，重複多，迴歸測試難以實現

b.自動測試利用軟件測試工具自動實現所有或部分測試工做：管理、設計、執行和報告；節省大量的測試開銷，並可以完成一些手工測試沒法實現的測試

ü  手工完成測試的所有過程沒法保證測試的科學性與嚴密性:

–        修改的缺陷越多，迴歸測試越困難

–        沒有人能向決策層提供精確的數據以度量當前的工做進度及工做效率

–        反覆測試帶來的倦怠情緒及其餘人爲因素使得測試標準先後不一

–        測試花費的時間越長，測試的嚴格性也就越低

ü  自動測試將測試人員從反覆、煩雜的測試執行中解放出來，用更多的時間進行測試設計和結果分析

ü  軟件測試不可能徹底自動化

ü  不能完成全部手工測試任務

ü  無創造性且靈活性差，不能改進測試的有效性

ü  過程當中可能會遇到許多意想不到的問題，特別是當軟件不穩定時

ü  測試腳本的維護高

12. 測試流程

ü  單元測試

ü  集成測試

ü  系統測試

ü  用戶驗收測試

ü  迴歸測試

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

13.單元測試

ü  完成對最小的軟件設計單元—模塊的驗證工做

ü  目標是確保模塊被正確地編碼

ü  使用過程設計描述做爲指南，對重要的控制路徑進行測試以發現模塊內的錯誤

ü  一般狀況下是面向白盒的

ü  對代碼風格和規則、程序設計和結構、業務邏輯等進行靜態測試，及早地發現和解決不易顯現的錯誤

ü  單元測試的內容

–        接口測試

–        內部數據結構

–        全局數據結構

–        邊界

–        語句覆蓋，錯誤路徑

14.集成測試

ü  經過測試發現與模塊接口有關的問題

ü  目標是把經過了單元測試的模塊拿來，構造一個在設計中所描述的程序結構

ü  應當避免一次性的集成（除非軟件規模很小），而採用增量集成

集成測試主要內容

ü  API

ü  API/參數組合

15．系統測試

ü  根據軟件需求規範的要求進行系統測試，確認系統知足需求的要求

ü  系統測試人員至關於用戶代言人

ü  在需求分析階段要肯定軟件的可測性，保證有效完成系統測試工做

ü  系統測試主要內容

ü  全部功能需求獲得知足

ü  全部性能需求獲得知足

ü  其餘需求（例如安全性、容錯性、兼容性等）獲得知足

16.用戶驗收/確認測試

ü  Alpha測試

–        是由用戶在開發者的場所來進行的，Alpha測試是在一個受控的環境中進行的

ü  Beta測試

–        由軟件的最終用戶在一個或多個用戶場所來進行的，開發者一般不在現場，用戶記錄測試中遇到的問題並報告給開發者

17．壓力測試VS性能測試
  性能測試的目的不是去找bugs,而是排除系統的瓶頸，以及爲之後的迴歸測試創建一個基準。而性能測試的操做，實際上就是一個很是當心受控的測量分析過程。在理想的狀況下，被測軟件在這個時候已是足夠穩定了

性能測試是爲了檢查系統的反映，運行速度等性能指標，他的前提是要求在必定負載下，如檢查一個網站在100人同時在線的狀況下的性能指標，每一個用戶是否都還能夠正常的完成操做等。
歸納就是：在不一樣負載下（負載必定）時，經過一些系統參數（如反應時間等）檢查系統的運行狀況；

壓力測試是爲了發現系統能支持的最大負載，他的前提是要求系統性能處在能夠接受的範圍內，好比常常規定的葉面3秒鐘內響應；歸納就是：在性能能夠接受的前提下，測試系統能夠支持的最大負載。

舉例說明：針對一個網站進行測試，模擬10到50個用戶就是在進行常規性能測試，用戶增長到1000乃至上萬就變成了壓力/負載測試。若是同時對系統進行大量的數據查詢操做，就包含了強度測試。

18. 主流測試工具的測試流程

========winrunner
1　啓動時選擇要加載的插件
2　進行一些設置（如錄製模式等）
3　識別應用程序的GUI，即建立map(就是學習被測試軟件的界面）
4　創建測試腳本（錄製及編寫）
5　對腳本除錯及調試（保證可以運行完）
6　插入各類檢查點（圖片，文字，控件等）
7　在新版應用程序中執行測試腳本
8　分析結果，回報缺陷
　
=========quicktestpro========
1　準備錄製
打開你要對其進行測試的應用程序，並檢查QuickTest中的各項設置是否適合當前的要求。
2　進行錄製
打開QuickTest的錄製功能，按測試用例中的描述，操做被測試應用程序。
3　編輯測試腳本
經過加入檢測點、參數化測試，以及添加分支、循環等控制語句，來加強測試腳本的功能，使未來的迴歸測試真正可以自動化。
4　調試腳本
調試腳本，檢查腳本是否存在錯誤。
5　在迴歸測試中運行測試
在對應用程序的迴歸測試中，經過QuickTest回放對應用程序的操做，檢驗軟件正確性，實現測試的自動化進行。
6　分析結果，報告問題
查看QuickTest記錄的運行結果，記錄問題，報告測試結果。

＝＝＝＝TestDirect============
安裝好後，先進入站點管理
1　建立域及工程
2　添加用戶
3　編輯licenses及本服務器
4　編輯數據庫
－－TD
1　選擇新建的工程進行定製(列表，用戶，組，版本等)
2　在require中增長需求
3　把需求轉化爲plan
4 在testlab中由計劃新建測試具體用例與執行

5　發現bug，在defect中提交bug
（每一部分均可以相對獨立地使用）

======loadrunner 1　制定負載測試計劃 (分析應用程序， 肯定測試目標，計劃怎樣執行LoadRunner） 2　開發測試腳本 （錄製基本的用戶腳本，完善測試腳本） 3　建立運行場景 （選擇場景類型爲Manual Scenario，選擇場景類型，理解各類類型，場景的類型轉化） 4　運行測試 5　監視場景 （MEMORY 相關，PROCESSOR相關，網絡吞量以及帶寬，磁盤相關，WEB應用程序 ，IIS5.0，SQL SERVER，NETWORK DELAY等) 6　分析測試結果 (分析實時監視圖表,分析事務的響應時間,分解頁面,肯定WEBSERVER的問題,其餘有用的功能)