qianchi0012020-10-16

。軟體測試的目的是儘可能多的找出軟體的缺陷。

程式碼評審員一般由開發人員擔任。

2。自底向上整合是從最低層的模組開始整合，因測試到較高層模組時， 所需求的下層模組功能均已具備，所以不再需要樁模組，測試用例的設計也相對簡單，缺點是程式最後一個查勘塊加入時才具有整體形象。

自底向上整合測試的步驟為：

1。把底層模組組織成實現某個子功能的模組群；

2。開發一個測試驅動模組，控制測試資料的輸入和測試結果的輸出；

3。對每個模組群進行測試；

4。刪除測試使用的驅動模組，用較高層模組把模組群組織成為完成更大功能的新模組群。

自底向上整合需要測試員編寫驅動程式。

3。（1）單元測試：

單元測試又稱為模組測試，是針對軟體設計的最小單位程式模組進行正確性檢查的測試工作，單元測試需要從程式內部結構出發設計測試用例，多個模組可以平行地獨立進行單元測試。

（2）整合測試

又稱為組裝測試或聯合測試，在單元測試的基礎上，需要將所有模組按照概要設計說明書和詳細設計說明書的要求進行組裝。

（3）確認測試

確認測試的目標是驗證軟體的功能和效能以及其他特性是否與使用者的要求一致。確認測試一般包括有效性測試和軟體配置複查。一般有第三方測試機構進行。

（4）系統測試

軟體作為計算機系統的一部分，與硬體、網路、外設、支撐軟體、資料以及人員結合在一起，在實際或模擬環境下，對計算機系統進行測試，

目的在於與系統需求比較，發現問題

（5）驗收測試

以使用者為主的測試，軟體開發人員和質量保證人員參加，由使用者設計測試用例。

不是對系統進行全覆蓋測試，而是對核心業務流程進行測試。

所以軟體測試型別按開發階段分為單元測試，整合測試，確認測試，系統測試，驗收測試。

4。α測試是指軟體開發公司組織內部人員模擬各類使用者對即將面市軟體產品（稱為α版本）進行測試，試圖發現錯誤並修正。α測試的關鍵在於儘可能逼真地模擬實際執行環境和使用者對軟體產品的操作並盡最大努力涵蓋所有可能的 使用者操作方式。經過α測試調整的軟體產品稱為β版本。 β測試是由軟體的多個使用者在實際使用環境下進行的測試，這些使用者返回有關錯誤資訊給開發者。測試時，開發者通常不在測試現場。因而，β測試是在開發者無法控制的環境下進行的軟體現場應用。在β測試中，由使用者記下遇到的所有問題，包括真實的以及主觀認定的，定期向開發者報告。β測試主要衡量產品的FLURPS，著重於產品的支援性，包括文件，客戶培訓和支援產品生產能力。 只有當α測試達到一定的可靠程度時，才能開始β測試。它處在整個測試的最後階段。同時，產品的所有手冊文字也應該在此階段完全定稿。

alpha測試與beta的區別：

alpha測試是在使用者組織模擬軟體系統的執行環境下的一種驗收測試，由使用者或第三方測試公司進行的測試，模擬各類使用者行為對即將面市的軟體產品進行測試，試圖發現並修改錯誤。

Beta測試是使用者公司組織各方面的典型終端使用者在日常工作中實際使用beta版本，並要求使用者報告異常情況，提出批評意見。

beta測試的環境是不受開發方控制的，誰也不知道使用者如何折磨軟體，使用者數量相對比較多，時間不集中。

5。條件覆蓋CC（Condition Coverage），設計足夠多的測試用例，執行被測程式，使得每一判定語句中每個邏輯條件的可能取值至少滿足一次。條件覆蓋率的公式：條件覆蓋率=被評價到的條件取值的數量/條件取值的總數X100%1 條件覆蓋的缺點：只考慮到每個判定語句中的每個表示式，沒有考慮到各個條件分支（或者涉及不到全部分支），即不能夠滿足判定覆蓋。

條件組合覆蓋，也稱多條件覆蓋MCC （Multiple Condition Coverage），設計足夠多的測試用例，使得每個判定中條件的各種可能組合都至少出現一次（以數軸形式劃分區域，提取交集，建立最少的測試用例）。這種方法包含了“分支覆蓋”和“條件覆蓋”的各種要求。滿足條件組合覆蓋一定滿足判定覆蓋、條件覆蓋、判定條件覆蓋。條件組合覆蓋率的公式：條件組合覆蓋率=被評價到的條件取值組合的數量/條件取值組合的總數條件組合覆蓋的缺點：判定語句較多時，條件組合值比較多。

語句覆蓋 SC（Statement Coverage），就是設計若干個測試用例，執行被測程式，使得程式中每一可執行語句至少執行一次。這裡的“若干個”，意味著使用測試用例越少越好。語句覆蓋在測試中主要發現缺陷或錯誤語句。

判定條件覆蓋CDC（Condition/ Decision Coverage），設計足夠多的測試用例，使得判定中的每個條件的所有可能（真/假）至少出現一次，並且每個判定本身的判定結果也至少出現一次。1 判定條件覆蓋率的公式：條件判定覆蓋率=被評價到的條件取值和判定分支的數量/（條件取值總數+判定分支總數）。判定條件覆蓋的缺點：沒有考慮單個判定對整體結果的影響，無法發現邏輯錯誤。

條件組合覆蓋的測試覆蓋最強！

6。測試設計員的職責有：設計測試用例，設計測試過程、指令碼。

7。測試驅動開發，英文全稱Test-Driven Development，簡稱 TDD ，是一種不同於傳統 軟體開發流程 的新型的開發方法。它要求在編寫某個功能的程式碼之前先編寫測試程式碼，然後只編寫使測試透過的功能程式碼，透過測試來推動整個開發的進行。這有助於編寫簡潔可用和高質量的程式碼，並加速開發過程。

TDD的原理是在開發功能程式碼之前，先編寫單元測試用例程式碼，測試程式碼確定需要編寫什麼產品程式碼。

TDD的基本思路就是透過測試來推動整個開發得進行，但測試驅動開發並不只是單純的測試工作，而是把需求分析，設計，質量控制量化的過程。

TDD的重要目的不僅僅是測試軟體，測試工作保證程式碼質量僅僅是其中一部分，而且是在開發過程中幫助客戶和程式設計師去除模稜兩可的需求。

TDD首先考慮使用需求（物件、功能、過程、介面等），主要是編寫測試用例框架對功能的過程和介面進行設計，而測試框架可以持續進行驗證。

8。軟體測試計劃評審會需要參加的人員有：專案經理，SQA 負責人，配置負責人，測試組。

9。軟體驗收測試的合格透過準則是：

1、軟體需求分析說明書中定義的所有功能已全部實現，效能指標全部達到要求。

2、所有測試項沒有殘餘的一級二級三級的錯誤。

3、立項審批表、需求分析文件、設計文件和編碼實現一致。

4、驗收測試工件齊全（測試計劃，測試用例，測試日誌，測試通知單，測試分析報告）

10。設計系統測試計劃需要參考的專案文擋有：軟體測試計劃，軟體需求規範，迭代計劃。

11。邊界值法既可以用於黑盒測試用例，也可以用於白盒測試用例。

基本路徑法用於白盒測試。

正交試驗設計法用於黑盒測試。

邏輯覆蓋法用於白盒測試用例設計。

12。系統測試計劃屬於專案階段性關鍵文件，因此需要同行評審。

同行評審目的：發現小規模工作產品的錯誤。

13。軟體測試一般分α、β、λ三個階段，α是第一階段，一般只供內部測試使用；β是第二個階段，已經消除了軟體中大部分的不完善之處，但仍有可能還存在缺陷和漏洞，一般只提供給特定的使用者群來測試使用；λ是第三個階段，此時產品已經相當成熟，只需在個別地方再做進一步的最佳化處理即可上市發行。

β測試就是在軟體公司外部展開的測試，可以由非專業的測試人員執行的測試 α測試就是在軟體公司內部展開的測試，由公司專業的測試人員執行的測試

14。測試用例是測試程式正確性與否的關鍵。一個覆蓋完全的測試用例可以測試出程式是否正確執行，是否有bug等等，是最重要的。

測試的關鍵問題是如何選擇測試用例。

15。CMM是指“能力成熟度模型”，其英文全稱為Capability Maturity Model for Software，英文縮寫為SW-CMM，簡稱CMM。它是對於軟體組織在定義、實施、度量、控制和改善其軟體過程的實踐中各個發展階段的描述。CMM的核心是把軟體開發視為一個過程，並根據這一原則對軟體開發和維護進行過程監控和研究，以使其更加科學化、標準化、使企業能夠更好地實現商業目標。此外還是化妝品的名字。CMMI（Capability Maturity Model Integration，能力成熟度模型整合）將各種能力成熟度模型（即：Software CMM、Systems Eng-CMM、People CMM和Acquisition CMM）整合到同一架構中去，由此建立起包括軟體工程、系統工程和軟體採購等在內的諸模型的整合，以解決除軟體開發以外的軟體系統工程和軟體採購工作中的迫切需求。這兩種方法屬於測試驅動開發的方式。

測試驅動開發式是一種敏捷開發方法。

TDD需求開發人員學習測試相關知識。

測試驅動開發可以和結對程式設計結合使用。