軟體測試知識點大全_軟體測試

軟體測試的對象包括：來源程式、目標程式、資料及相關文檔

而如何入門軟體測試並針對找工作呢。

需要以下知識：

測試的理論，還有測試驅動開發是怎麼用的，為什麼要用測試驅動開發、linux和資料庫、電腦網路（可刷牛客網來提升）。

單元測試->整合測試->確認測試->系統測試->驗收測試

（1）單元測試：

 單元測試又稱為模組測試，是針對軟體設計的最小單位程式模組進行正確性檢查的測試工作，單元測試需要從程式內部結構出發設計測試案例，多個模組可以平行地獨立進行單元測試。Junit 測試是程式員測試，即所謂 白盒測試 ，因為程式員知道被測試的軟體如何（ How ）完成功能和完成什麼樣（ What ）的功能。 Junit 是一套架構，繼承TestCase 類，就可以用 Junit 進行自動化的測試了。

 

工件是加工過程中的生產對象。
（2）整合測試
又稱為組裝測試或聯合測試，在單元測試的基礎上，需要將所有模組按照概要設計說明書和詳細設計說明書的要求進行組裝。

（3）確認測試
確認測試的目標是驗證軟體的功能和效能以及其他特性是否與使用者的要求一致。確認測試一般包括有效性測試和軟體配置複查。一般由第三方測試機構進行。
（4）系統測試
 軟體作為電腦系統的一部分，與硬體、網路、外設、支撐軟體、資料以及人員結合在一起，在實際或類比環境下，對電腦系統進行測試，
目的在於與系統需求比較，發現問題
（5）驗收測試
以使用者為主的測試，軟體開發人員和品質保證人員參加，由使用者設計測試案例。不是對系統進行全覆蓋測試，而是對核心商務程序進行測試。

 

Alpha測試在Beta測試之前，由一個使用者在開發環境下進行的測試，也叫做驗證測試。

alpha測試是由一個使用者在開發環境下進行的測試，也可以是公司內部使用者在類比實際作業環境進行的受控測試，不能由程式員或測試員完成。Alpha測試可以從軟體產品編碼結束之後開始，或在模組(子系統)測試完成後開始，也可以在確認測試過程中產品達到一定的穩定和可靠程度之後再開始。

Beta測試：軟體的多個使用者在一個或多個使用者的實際使用環境下進行的測試。開發人員通常不在測試現場，Beta測試不能由程式員或測試員完成。因而，Beta測試是在開發人員無法控制的環境下進行的軟體現場應用。在Beta測試中，由使用者記下遇到的所有問題，包括真實的以及主管認定的，定期向開發人員報告，開發人員在綜合使用者的報告後，做出修改，最後將軟體產品交付給全體使用者使用。Beta測試著重於產品的支援性，包括文檔、客戶培訓和支援產品的生產能力。只有當Alpha測試達到一定的可靠程度後，才能開始Beta測試。由於Beta測試的主要目標是測試可支援性，所以Beta測試應該儘可能由主持產品發行的人員來管理。

區別：A測試是一個使用者，可以是內部人員也可以是使用者，開發人員在場，測試現場立刻反饋給開發人員，由開發人員及時分析和處理。目的是評價軟體產品的功能、可使用性、可靠性、效能和支援。尤其注重產品的介面和特色。

           B測試是多個使用者在一個或多個實際使用環境下進行，完全是使用者，開發人員不在場。著重於產品的支援性，包括文檔、客戶培訓和支援產品的生產能力。

 

針對手機應用軟體的系統測試，我們通常從如下幾個角度開展：功能模組測試，交叉事件測試，壓力測試，容量測試，相容性測試，易用性/使用者體驗測試等.

對手機可以施加的壓力測試類型主要有：儲存壓力、邊界壓力、響應能力壓力、網路流量壓力

 

設計測試案例時，應注意測試案例的代表性、測試結果的可判定性和可重現性。   

1、測試案例的代表性：能夠代表並覆蓋各種合理的和不合理、合法的和非法的、邊界的和越界的、以及極限的輸入資料、操作和環境設定等。

2、測試結果的可判定性：即測試執行結果的正確性是可判定的，每一個測試案例都應有相應的期望結果。

3、測試結果的可再現性：即對同樣的測試案例，系統的執行結果應當是相同的。

 

什麼是靜態測試?

答:通過運行程式測試軟體稱為動態測試.通過評審文檔、閱讀代碼等方式測試軟體稱為靜態測試,在動態測試中,通常使用白盒測試和黑箱測試從不同的角度設計測試案例,尋找軟體代碼中的錯誤.ddddddd                    

靜態測試方法是指不運行被測程式本身，僅通過分析或檢查來源程式的文法、結構、過程、介面等來檢查程式的正確性。對需求規格說明書、軟體設計說明書、來源程式做結構分析、流程圖分析、符號執行來找錯。靜態方法通過程式靜態特性的分析，找出欠缺和可疑之處，例如不匹配的參數、不適當的迴圈嵌套和分支嵌套、不允許的遞迴、未使用過的變數、null 指標的引用和可疑的計算等。靜態測試結果可用於進一步的查錯，並為測試案例選取提供指導。

 

什麼是白盒測試?

答:白盒測試(White-box Testing，又稱邏輯驅動測試,結構測試),它是知道產品內部工作過程，可通過測試來檢測產品內部動作是否按照規格說明書的規定正常進行，按照程式內部的結構測試程式，檢驗程式中的每條通路是否都有能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅動、基路測試等，主要用於軟體驗證。
對開發語言的支援：白盒測試載入器是對原始碼進行的測試，測試的主要內容包括詞法分析與文法分析、靜態錯誤分析、動態檢測等。

 

白盒測試主要應用在單元測試階段，主要是對代碼級的測試，針對程式內部邏輯結構，測試手段有：語句覆蓋、判定覆蓋、條件覆蓋、路徑覆蓋、條件組合覆蓋

1.語句覆蓋：可執行語句至少被執行一次；
2.判斷覆蓋：每個判斷的取真分支和取假分支至少經曆一次；
3.條件覆蓋：每個條件的取值至少滿足一次；

4.路徑測試：執行所有可能的執行路徑；
5.條件組合覆蓋：每個條件的所有可能都至少出現一次，並且判定結果至少出現一次 ；

6.判斷/條件覆蓋：判斷和條件都滿足；
與條件覆蓋的區別：他不是簡單要求每個條件出現“真”和“假”兩種結果，而是要求這些結果所有可能至少出現一次；
7.基本路徑測試：路徑測試執行了每個路徑，每個判定的結果肯定經曆過一次

 

黑盒技術設計測試案例的方法有：等價類別劃分、邊界值分析、錯誤推測、決策表和綜合策略。

 

設計系統測試計劃需要參考的項目文擋有：軟體測試計劃、軟體需求規範、反覆項目計劃

 

系統測試有負載測試、易用性測試、強度測試、安全性測試。

(1)負載測試：資料在超負荷環境中運行，看程式是否能承擔。目的是確定並確保系統在超出最大預期工作量的情況下仍能正常運行。

(2)強度測試：在一定的負荷條件下，在較長時間跨度內的系統連續運行給系統效能所造成的影響。

(3)容量測試：容量測試目的是通過測試預先分析出反映軟體系統應用特徵的某項指標的極限值（如最大並發使用者數、資料庫記錄數等），系統在其極限值狀態下沒有出現任何軟體故障或還能保持主要功能正常運行。面向資料的，並且它的目的是顯示系統可以處理目標內確定的資料容量。

 

單元測試能發現約80%的軟體缺陷。

 

邏輯測試覆蓋中，測試覆蓋最強的是條件組合覆蓋。

 

測試方法可以分成個人複查、抽查和會審、黑箱測試、白盒測試。

 

軟體測試的原則之一是測試應該儘早進行，最好在需求階段就開始介入。

 

    測試驅動開發(Test-DrivenDevelopment)是敏捷開發中的一項核心實踐和技術，也是一種設計方法論。TDD得原理是在開發功能代碼之前，先編寫單元測試用例代碼，測試代碼確定需要編寫什麼產品代碼。TDD雖是敏捷方法的核心實踐，但不只適用於XP（Extreme Programming），同樣可以適用于敏感詞開發方法和過程。TDD得基本思路就是通過測試來推動整個開發得進行，但測試驅動開發並不只是單純的測試工作，而是把需求分析，設計，品質控制量化的過程。TDD的重要目的不僅僅是測試軟體，測試工作保證代碼品質僅僅是其中一部分，而且是在開發過程中協助客戶和程式員去除模稜兩可的需求。TDD首先考慮使用需求（對象、功能、過程、介面等），主要是編寫測試案例架構對功能的過程和介面進行設計，而測試架構可以持續進行驗證。

優點：在任意一個開發節點都可以拿出一個可以使用，含少量bug並具一定功能的產品。

缺點：增加代碼量。測試代碼是系統代碼的兩倍或更多。

 

什麼是驅動模組。

答:驅動模組在大多數場合稱為"主程式"，它接收測試資料並將這些資料傳遞到被測試模組.單元測試一個函數單元時，被測單元本身是不能獨立啟動並執行，需要為其傳送資料，為此寫驅動
驅動模組主要完成以下事情：
1、接受測試輸入;
2、對輸入進行判斷;
3、將輸入傳給被測單元，驅動被測單元執行;
4、接受被測單元執行結果，並對結果進行判斷;
5、將判斷結果作為用例執行結果輸出測試報告。

 

什麼是樁模組?

答:比如對函數A做單元測試時，被測的函數單元下還包括了一個函數B，為了更好的錯誤，定位錯誤，就要為函數B寫樁，來類比函數B的功能，保證其正確。

 

需求文檔測試：測試需求中是否存在邏輯矛盾以及需求在技術上是否可以實現;

設計文檔測試: 測試設計是否符合全部需求以及設計是否合理。

 

測試載入器：

loadrunner 包括指令碼編輯工具、測試執行工具、結果分析工具

 

效能測試：主要檢驗軟體是否達到需求規格說明書中規定的各類效能指標，並滿足一些效能相關的約束和限制條件。

目的是通過測試，確認軟體是否滿足產品的效能需求，同時發現系統中存在的效能瓶頸，並對系統進行最佳化。

壓力測試：類比巨大的工作負載，以查看系統在峰值使用方式下是否可以正常運行，以此來獲得系統效能提供的最大服務等級的一種測試。

負載測試：通過逐步增加系統工作量，測試系統能力的變化，並最終確定在滿足功能指標的情況下，系統所能承受的最大工作量的測試。壓力測試實質上就是一種特定類型的負載測試。

自動化測試和手工測試的適用情境：

自動化測試適用情境：

1.產品需求變更較少。

2.項目開發週期較長。

3.測試案例執行頻繁。比如大量的迴歸測試工作

4.手工測試無法勝任。比如高並行作業，持續收集裝置資源，長時間穩定性測試，多使用者操作等手工操作或測試無法勝任的工作。

5.人物財力資源充足。

手工測試適用情境：

1.產品需求變更較多。

2.項目開發週期較短，需要迅速交付。

3.測試案例執行不是很頻繁，需要人為觀察，需要靈活測試。

自動化測試和手工測試的優缺點：

自動化測試的優點：

1、對迴歸測試更方便：周期較長的迴歸測試工作量大，測試比較頻繁，適合自動化測試。由於測試的指令碼和用例都是設計好的，測試期望的結果也可以預料，將迴歸測試自動化可以極大的提高效率縮短迴歸時間。
2、類比真實情況：可以執行手工測試無法執行的測試，比如同時並發上千使用者測試系統的負載量，測試人員無法達到測試目的，而使用自動化測試載入器可以類比多使用者的並發過程。
3、有效利用人力物力資源：頻繁地機器化的動作可以用自動化測試執行，減少錯誤的發生，更好的利用人力資源。
4、測試的重複利用：由於自動化的測試通常使用的是自動化指令碼技術，這樣就可以只需要做較少的甚至是不修改就可以實現在不同的測試過程中使用相同的用例。
5、減少人為的錯誤：自動化測試是機器完成，不存在執行過程中人為的疏忽和錯誤。

自動化測試的缺點：

1、自動化測試是工具執行，沒有思維，無法進行主觀判斷，對介面色彩、布局和系統的奔潰現象無法發現，這些錯誤通過人眼很容易發現。
2、自動化測試載入器本身是一個產品，在不同的系統平台或硬體平台可能會受影響，在運行時可能影響被測程式的測試結果。
3、對於需求更改頻繁的軟體，測試指令碼的維護和設計比較空難。
4、自動化測試是機器執行，手工測試比自動化的測試發現的缺陷更多。
5、自動化測試要編寫測試指令碼，設計情境，這些對測試人員的要求比較高，測試的設計直接影響測試的結果。

綜上所述，可以歸結自動化完成不了的，手工測試都能彌補，兩者有效結合是測試品質保證的關鍵。