軟件測試策略與過程答疑解讀

1、軟件測試策略與過程答疑2.1 問：分析軟件測試的復雜性。答： （1）在軟件測試當中，由于測試所需的輸入量太大、測試的輸出結(jié)果太多、 軟件實現(xiàn)的途徑太多、 軟件規(guī)格說明沒有一個客觀標準等原因，無法對軟件進行完全的測試，并找出所有的軟件缺陷。（ 2）通過軟件測試只能報告軟件已被發(fā)現(xiàn)的缺陷和故障，但無法顯示潛在的軟件缺陷和故障。（ 3）經(jīng)測試后的程序中隱含的故障數(shù)目與已發(fā)現(xiàn)的故障數(shù)目成正比。（ 4）軟件測試進行得越多，其程序中缺陷的免疫力就越強。在測試時，即使付出再多的時間和代價， 也不能夠使所有的軟件故障都得到修復。（ 5）如果不能做到去測試軟件所有的情況，則該軟件就是有風險的。軟件測試不可能對軟

2、件使用中所有的情況進行測試， 但有可能客戶會在使用該軟件的時候遇到， 并且可能發(fā)現(xiàn)軟件的缺陷。 等到那個時候，再進行軟件缺陷的修復，代價將是很高的。2.2 問：軟件測試充分性準則的內(nèi)容是什么？答： （1）對任何軟件都存在有限的充分測試集合。（ 2）如果一個軟件系統(tǒng)在一個測試數(shù)據(jù)集合上的測試是充分的，那么再多測試一些數(shù)據(jù)也應(yīng)該是充分的。這一特性稱為單調(diào)性。（ 3）即使對軟件所有成分都進行了充分的測試，也并不表明整個軟件的測試已經(jīng)充分了。這一特性稱為非復合性。（ 4）即使對軟件系統(tǒng)整體的測試是充分的，也并不意味著軟件系統(tǒng)中各個成分都已經(jīng)充分地得到了測試。這個特性稱為非分解性。（ 5）軟件測試的充分

3、性應(yīng)該與軟件的需求和軟件的實現(xiàn)均相關(guān)。（ 6）軟件越復雜，需要的測試數(shù)據(jù)就越多。這一特性稱為復雜性。（ 7）測試得越多，進一步測試所能得到的充分性增長就越少。這一特性稱為回報遞減率。2.3 問：什么是靜態(tài)測試？靜態(tài)測試包括哪些內(nèi)容？答：靜態(tài)測試是指不利用計算機運行被測程序，也就是說，計算機并不真正運行被測試的程序，而是通過其他手段達到檢測的目的。靜態(tài)測試是對被測程序進行特性分析的一些方法的總稱。靜態(tài)測試包括代碼檢查、 靜態(tài)結(jié)構(gòu)分析、代碼質(zhì)量度量等。 其中：代碼檢查又包括代碼走查、桌面檢查、代碼審查等，主要檢查代碼和設(shè)計的一致性，代碼對標準的遵循、可讀性，代碼的邏輯表達的正確性，代碼結(jié)構(gòu)的合理性

4、等方面；靜態(tài)結(jié)構(gòu)分析主要是以圖形的方式表現(xiàn)程序的內(nèi)部結(jié)構(gòu)， 如函數(shù)調(diào)用關(guān)系圖、函數(shù)內(nèi)部控制流圖； 代碼質(zhì)量度量則是以目前已有的幾種度量參數(shù)（ Line 復雜度、 Halstead 復雜度、 McCabe復雜度）來衡量軟件的質(zhì)量。2.4 問：靜態(tài)測試可以完成哪些工作？答： （1）發(fā)現(xiàn)下列程序的錯誤：錯用局部變量和全局變量；未定義的變量、不匹配的參數(shù)；不適當?shù)难h(huán)嵌套或分支嵌套、 死循環(huán)、不允許的遞歸；調(diào)用不存在的子程序，遺漏標號或代碼。（ 2）找出以下問題的根源：從未使用過的變量；不會執(zhí)行到的代碼、從未使用過的標號；潛在的死循環(huán)。（ 3）提供程序缺陷的間接信息： 所用變量和常量的交叉應(yīng)用表；是否

5、違背編碼規(guī)則；標識符的使用方法和過程的調(diào)用層次。（ 4）為進一步查找做好準備。（ 5）選擇測試用例。（ 6）進行符號測試。2.5 問：什么是動態(tài)測試？動態(tài)測試包括哪些內(nèi)容？答：動態(tài)測試是指計算機必須真正運行被測試的程序， 通過輸入測試用例，對其運行情況即輸入與輸出的對應(yīng)關(guān)系進行分析， 達到檢測的目的。動態(tài)測試包括功能確認與接口測試、覆蓋率分析、性能分析、內(nèi)存分析等。2.6 問：簡述黑盒測試法和白盒測試法。答：若測試規(guī)劃是基于產(chǎn)品的功能， 目的是檢查程序各個功能是否能夠?qū)崿F(xiàn)，并檢查其中的功能錯誤， 則這種測試方法稱為黑盒測試方法。黑盒測試又稱為功能測試、 數(shù)據(jù)驅(qū)動測試和基于規(guī)格說明的測試。它從用

6、戶觀點出發(fā)的測試。用這種方法進行測試時，把被測試程序當作一個黑盒， 在不考慮程序內(nèi)部結(jié)構(gòu)的內(nèi)部特性、 測試者只知道該程序輸入和輸出之間的關(guān)系或程序功能的情況下， 依靠能夠反映這一關(guān)系和程序功能需求規(guī)格的說明書， 來確定測試用例和推斷測試結(jié)果的正確性。若測試規(guī)劃基于產(chǎn)品的內(nèi)部結(jié)構(gòu)進行測試， 檢查內(nèi)部操作是否按規(guī)定執(zhí)行，軟件各個部分功能是否得到充分使用， 則這種測試方法稱為白盒測試方法。 白盒測試又稱為結(jié)構(gòu)測試、 邏輯驅(qū)動測試或基于程序的測試。它依賴于對程序細節(jié)的嚴密的檢驗。 針對特定條件和循環(huán)集設(shè)計測試用例， 對軟件的邏輯路徑進行測試。 在程序的不同點檢驗程序的狀態(tài)，來進行判定其實際情況是否和預(yù)

7、期的狀態(tài)相一致。黑盒測試法和白盒測試法是從完全不同的起點出發(fā)， 并且這兩個出發(fā)點在某種程度上是完全對立的，反映了測試思路的兩方面情況。這兩類方法在長期的軟 件測試實踐過程中被證明是有效和實用的方法。2.7 問：比較黑盒測試法和白盒測試法。項目黑盒測試法白盒測試法規(guī)劃方面功能的測試結(jié)構(gòu)的測試優(yōu)點方面能確保從用戶的角度出發(fā)進行測試能對程序內(nèi)部的特定部位進行覆蓋測試無法測試程序內(nèi)部特定部位無法檢查程序的外部特性缺點方面無法對未實現(xiàn)規(guī)格說明的當規(guī)格說明有誤，則不能發(fā)現(xiàn)問題程序內(nèi)部欠缺部分進行測試語句覆蓋判斷覆蓋邊界分析法條件覆蓋應(yīng)用范圍等價類劃分法判斷 / 條件覆蓋決策表測試路徑覆蓋循環(huán)覆蓋模塊接口測

8、試2.8 問：簡述軟件測試過程。答：軟件測試過程按測試的先后次序可分為：單元測試、集成測試、確認（有效性）測試、系統(tǒng)測試和驗收 （用戶）測試共 5 個步驟。（ 1）單元測試：針對每個單元的測試，以確保每個模塊能正常工作為目標。（ 2）集成測試：對已測試過的模塊進行組裝，進行集成測試。這項測試的目的在于檢驗與軟件設(shè)計相關(guān)的程序結(jié)構(gòu)問題。（ 3）確認測試：在完成集成測試后，對開發(fā)工作初期制定的確認準則進行檢驗。它是檢驗所開發(fā)的軟件能否滿足所有功能和性能需求的最后手段。（ 4）系統(tǒng)測試：在完成確認測試后，應(yīng)屬于合格軟件產(chǎn)品。但為了檢驗它能否與系統(tǒng)的其他部分（比如硬件、數(shù)據(jù)庫及操作人員）協(xié)調(diào)工作，還需

9、要進行系統(tǒng)測試。（ 5）驗收測試：檢驗軟件產(chǎn)品質(zhì)量的最后一道工序是驗收測試。驗收測試主要突出用戶的作用， 同時軟件開發(fā)人員也應(yīng)有一定程度的參與。2.9 問：單元測試的主要任務(wù)是什么？答：單元測試針對每個程序的模塊， 主要測試 5 個方面的問題 模塊接口、局部數(shù)據(jù)結(jié)構(gòu)、邊界條件、獨立的路徑和錯誤處理。（ 1）模塊接口測試：檢查進出程序單元的數(shù)據(jù)流是否正確，對模塊接口數(shù)據(jù)流的測試必須在任何其他測試之前進行。（ 2）局部數(shù)據(jù)結(jié)構(gòu)測試：測試其內(nèi)部的數(shù)據(jù)能否保持完整性，包括內(nèi)部數(shù)據(jù)的內(nèi)容、形式及相互關(guān)系不發(fā)生錯誤。（ 3）路徑測試：檢查是否存在由于計算錯誤、不正確的判定或是不正常的控制流而產(chǎn)生的錯誤。（

10、 4）邊界條件測試：是單元測試的最后一步，必須采用邊界值分析方法來設(shè)計測試用例， 測試為限制數(shù)據(jù)處理而設(shè)置的邊界處， 看模塊是否能夠正常工作。（ 5）出錯處理測試：測試模塊在工作中發(fā)生了錯誤時，其中的出錯處理設(shè)施是否有效。2.10 問：簡單說明單元測試中的輔助測試模塊。答：在對每個模塊進行單元測試時，不能完全忽視它們和周圍模塊的相互關(guān)系。為模擬這一聯(lián)系，在進行單元測試時，需要設(shè)置一些輔助測試模塊。輔助測試模塊有兩種：一種是驅(qū)動模塊（Drive ），用來模擬被測試模塊的上一級模塊，相當于被測模塊的主程序。 驅(qū)動模塊在單元測試中接收數(shù)據(jù)， 把相關(guān)的數(shù)據(jù)傳送給被測試的模塊，啟動被測模塊，并打印出相應(yīng)

11、的結(jié)果。另一種是樁模塊（Stub） , 用來模擬被測試模塊工作過程中所調(diào)用的模塊。樁模塊由被測模塊調(diào)用， 它們一般只進行很少的數(shù)據(jù)處理，例如打印入口和返回， 以便檢驗被測模塊與其下級模的接口。 被測模塊、驅(qū)動模塊和樁模塊共同構(gòu)成了一個如下圖所示的單元測試的測試環(huán)境：2.11 問：為什么在單元測試之后要進行集成測試？如何組織集成測試？答：實踐表明，軟件的一些模塊能夠單獨地工作，但并不能保證組裝連接之后也肯定能正常工作。程序在某些局部反映不出來的問題，在全局情況下有可能暴露出來，影響軟件功能的實現(xiàn)。可能的原因有：（1）模塊相互調(diào)用時引入了新的問題； （2）幾個子功能組合后不能實現(xiàn)預(yù)計的主功能； （

12、3）計算的誤差累計達到了不能接受的程度；（4）全局數(shù)據(jù)結(jié)構(gòu)出現(xiàn)錯誤。 因此，在單元模塊完成單元測試后，需要按照設(shè)計的程序結(jié)構(gòu)圖進行組合、 進行集成測試， 檢測與接口有關(guān)的各種故障。組織集成測試的一種方法是先獨立的測試每個模塊， 然后再將它們組合成一個整體進行測試； 另一種方法是先把下一個待測試模塊組合到已經(jīng)測試過的那些模塊上去，再進行測試，逐步完成集成測試。由此產(chǎn)生了兩種集成測試方法：非增量式測試和增量式測試。2.12 問：簡述集成測試中的非增量式測試和增量式測試方法。答：非增量式測試方法是采用一步到位的方法來構(gòu)造測試： 對所有模塊進行個別的單元測試后，按照程序結(jié)構(gòu)圖將各模塊連接起來，把連接后

13、的程序當作一個整體進行測試。增量式測試的集成是逐步實現(xiàn)的： 逐次將未曾集成測試的模塊和已經(jīng)集成測試的模塊（或子系統(tǒng)）結(jié)合成程序包，再將這些模塊集成為較大系統(tǒng)，在集成的過程中邊連接邊測試， 以發(fā)現(xiàn)連接過程中產(chǎn)生的問題。按照不同的實施次序， 增量式測試又可以分為自頂向下增量式測試和自底向上增量式測試：（ 1）自頂向下增量式測試表示逐步集成和逐步測試是按照結(jié)構(gòu)圖自上而下進行的，即模塊集成的順序是首先集成主控模塊（主程序），然后依照控制層次結(jié)構(gòu)向下進行集成。從屬于主控模塊的按深度優(yōu)先方式（縱向）或者廣度優(yōu)先方式（橫向）集成到結(jié)構(gòu)中去。其中，深度優(yōu)先的集成首先集成的是在結(jié)構(gòu)中的一個主控路徑下的所有模塊，

14、主控路徑的選擇是任意的； 廣度優(yōu)先的集成首先沿著水平方向，把每一層中所有直接隸屬于上一層的模塊集成起來，直到底層。（ 2）自底向上增量式測試表示逐步集成和逐步測試的工作是按結(jié)構(gòu)圖自下而上進行的， 即從程序模塊結(jié)構(gòu)的最底層模塊開始集成和測試。由于是從最底層開始集成，對于一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經(jīng)集成并測試完成，所以不再需要使用樁模塊進行輔助測試。 在模塊的測試過程中需要從子模塊得到的信息可以直接運行子模塊得到。圖見 P49 圖 2.3 所示2.13 問：比較幾種不同的集成測試方法。答： （1）非增量式集成測試與增量式集成測試的比較：非增量式測試的方法是先分散測

15、試， 然后集中起來再一次完成集成測試。假如在模塊的接口處存在錯誤， 只會在最后的集成測試時一下子暴露出來。與此相反， 增量式測試是逐步集成和逐步測試的方法，把可能出現(xiàn)的差錯分散暴露出來，便于找出問題和修改。而且一些模塊在逐步集成的測試中，得到了較多次的考驗，因此，可能會取得較好的測試效果。 總之，增量式測試要比非增量式測試具有一定的優(yōu)越性。（ 2）自頂向下與自底向上增量式測試的比較：自頂向下增量式測試的主要優(yōu)點在于它可以自然的做到逐步求精，一開始就能讓測試者看到系統(tǒng)的框架。 它的主要缺點是需要提供樁模塊，并且在輸入 / 輸出模塊接入系統(tǒng)以前，在樁模塊中表示測試數(shù)據(jù)有一定困難。同時，觀察和解釋測

16、試的輸出常常也比較困難。自底向上增量式測試的優(yōu)點在于，由于驅(qū)動模塊模擬了所有調(diào)用參數(shù)，即使數(shù)據(jù)流并未構(gòu)成有向的非環(huán)狀圖， 生成測試數(shù)據(jù)也無困難。 如果關(guān)鍵的模塊是在結(jié)構(gòu)圖的底部， 那么自底向上測試具有優(yōu)越性。 它的主要缺點在于，直到最后一個模塊被加進去之后才能看到整個程序（系統(tǒng)）的框架。2.14 問：確認測試的準則是什么？答：確認測試也稱為合格性測試， 是檢驗所開發(fā)的軟件是否能按用戶提出的要求進行。 經(jīng)過確認測試， 應(yīng)該為已開發(fā)的軟件給出結(jié)論性評價：（ 1）經(jīng)過檢驗的軟件的功能、性能及其他要求均已滿足需求規(guī)格說明書的規(guī)定，則可被認為是合格的軟件。（ 2）經(jīng)過檢驗發(fā)現(xiàn)與需求說明書有相當?shù)钠x，得

17、到一個各項缺陷清單。對于這種情況，往往很難在交付期之前把發(fā)現(xiàn)的問題糾正過來。這就需要開發(fā)部門與用戶進行協(xié)商，找出解決的辦法。2.15 問：為什么要進行系統(tǒng)測試？答：由于軟件只是計算機系統(tǒng)中的一個組成部分， 軟件開發(fā)完成之后，最終還要和系統(tǒng)中的硬件系統(tǒng)、某些支持軟件、數(shù)據(jù)信息等其他部分配套運行。因此，在投入運行前要完成系統(tǒng)測試，以保證各組成部分不僅能單獨的得到檢驗， 而且在系統(tǒng)各部分協(xié)調(diào)工作的環(huán)境下也能正常工作。2.16 問：系統(tǒng)測試的內(nèi)容包含哪些？簡單說明每一種測試的要點。答：系統(tǒng)測試的內(nèi)容包括恢復測試、安全測試、強度測試、性能測試、正確性測試、可靠性測試、兼容性測試、 Web網(wǎng)站測試等。盡管

18、每一種測試有特定的目標， 然而所有的檢測工作都要驗證系統(tǒng)中每個部分均已得到正確的集成，并能完成指定的功能。（ 1）恢復測試是通過各種手段，強制性地使軟件出錯，使其不能正常工作，進而檢驗系統(tǒng)的恢復能力。如果系統(tǒng)恢復是自動的（由系統(tǒng)自身完成），則應(yīng)該檢驗重新初始化、檢驗點設(shè)置機構(gòu)、數(shù)據(jù)恢復以及重新啟動是否正確。 如果這一恢復需要人為干預(yù)， 則應(yīng)考慮平均修復時間是否在限定的、可以接受的范圍之內(nèi)。（ 2）安全測試的目的在于驗證安裝在系統(tǒng)內(nèi)的保護機制能否在實際中保護系統(tǒng)且不受非法入侵， 不受各種非法干擾。 在安全測試過程中，測試者扮演著試圖攻擊系統(tǒng)的個人角色， 因此要設(shè)置一些測試用例試圖突破系統(tǒng)的安全保

19、密措施，檢驗系統(tǒng)是否有安全保密的漏洞。（ 3）強度測試（也稱壓力測試）的目的是要檢測非正常的情形，測試是想要破壞程序。 強度測試需要在反常規(guī)數(shù)據(jù)量、 頻率或資源的方式下運行系統(tǒng)，以檢驗系統(tǒng)能力的最高實際限度。（ 4）性能測試用來測試軟件在系統(tǒng)集成中的運行性能，特別是針對實時系統(tǒng)和嵌入式系統(tǒng)， 僅提供符合功能需求但不符合性能需求的軟件是不能被接受的。 性能測試常常和強度測試結(jié)合起來進行，而且常常需要硬件和軟件測試設(shè)備， 這就是說，常常有必要在一種苛刻的環(huán)境中衡量資源的使用。（ 5）正確性測試檢查軟件的功能是否符合規(guī)格說明。正確性測試基本的方法是構(gòu)造一些合理輸入， 檢查是否得到期望的輸出， 這是枚

20、舉法。還有一種有效的測試方法是邊界值測試， 即采用定義域或者等價區(qū)間的邊界值來進行測試。 因為程序設(shè)計容易疏忽邊界情況， 程序也容易在邊界值處出錯。（ 6）可靠性測試是從驗證的角度出發(fā)，檢驗系統(tǒng)的可靠性是否達到預(yù)期的目標， 同時給出當前系統(tǒng)可能的可靠性增長情況。 可靠性測試需要從用戶角度出發(fā)， 模擬用戶實際使用系統(tǒng)的情況， 設(shè)計出系統(tǒng)的可操作視圖。 在這個基礎(chǔ)上， 根據(jù)輸入空間的屬性及依賴關(guān)系導出測試用例，然后在仿真的環(huán)境或真實的環(huán)境下執(zhí)行測試用例并記錄測試的數(shù)據(jù)。（ 7）兼容性測試是檢測各軟件之間能否正確地交互和共享信息，其目標是保證軟件按用戶期望的方式進行交互， 使用其它軟件檢查軟件操作的

21、過程。 兼容性的測試通常需要解決以下問題： 新開發(fā)的軟件需要與哪種操作系統(tǒng)、 Web瀏覽器和應(yīng)用軟件保持兼容，如果要測試的軟件是一個平臺， 那么要求應(yīng)用程序能在其上運行； 應(yīng)該遵守哪種定義軟件之間交互的標準或者規(guī)范；軟件使用何種數(shù)據(jù)與其它平臺、與新的軟件進行交互和共享信息。（ 8）Web 網(wǎng)站測試不但需要檢查和驗證是否按照設(shè)計的要求運行，而且還要評價系統(tǒng)在不同用戶的瀏覽器端的顯示是否合適， 以及從最終用戶的角度進行安全性和可用性測試。通常Web 網(wǎng)站測試包含文字測試、鏈接測試、圖形圖像測試、表單測試、動態(tài)內(nèi)容測試、數(shù)據(jù)庫測試、服務(wù)器性能及負載測試、安全性測試。2.17 問：面向?qū)ο蟮能浖y試與

22、傳統(tǒng)軟件測試有什么不同？答：面向?qū)ο蟮能浖赜械睦^承、 封裝和動態(tài)綁定等特性與傳統(tǒng)的軟件有了較大的區(qū)別， 這給軟件測試帶來一系列新的問題。 在傳統(tǒng)的面向過程的程序中， 通?？紤]的是函數(shù)的行為特征； 而在面向?qū)ο蟮某绦蛑校托枰紤]基類函數(shù)、繼承類函數(shù)的行為特征。面向?qū)ο蟮某绦蚪Y(jié)構(gòu)已不再是傳統(tǒng)的功能模塊結(jié)構(gòu)。 封裝是面向?qū)ο筌浖囊粋€重要特征， 將數(shù)據(jù)及對數(shù)據(jù)的操作封裝在一起， 限制了對象屬性對外的透明性和外界對它的操作權(quán)限， 在某種程度上避免了對數(shù)據(jù)的非法操作，有效的防止了故障的擴散。但同時，封裝的機制也給測試數(shù)據(jù)的生成、 測試路徑的選取以及測試結(jié)構(gòu)的分析帶來了困難。繼承和動態(tài)綁定機制是面向?qū)?/p>

23、象實現(xiàn)的主要手段。 繼承實現(xiàn)了共享父類中定義的數(shù)據(jù)和操作， 同時也可定義新的特征。 子類是在新的環(huán)境中存在，所以父類的正確性不能保證子類的正確性。 繼承使代碼的重用率得到了提高，但同時也使故障的傳播幾率增加。因此，繼承關(guān)系的測試方法及策略是面向?qū)ο鬁y試工作的重點和難點。 動態(tài)綁定也增加了系統(tǒng)運行中可能的執(zhí)行路徑， 而且給面向?qū)ο筌浖砹烁鼮閲乐氐牟淮_定性，使得測試覆蓋率的進行帶來新的困難。與傳統(tǒng)軟件相比，由于存在諸如繼承、關(guān)聯(lián)、動態(tài)綁定等關(guān)系，面向?qū)ο筌浖哂懈鼜碗s的依賴關(guān)系， 一個類將不可避免的依賴于其它的類，從而增加了面向?qū)ο筌浖y試的難度。 傳統(tǒng)軟件中存在的依賴關(guān)系有：變量間的數(shù)據(jù)依賴；模塊間的調(diào)用依賴；變量與其類型間的定義依賴；模塊與其變量間的功能依賴。 而面向?qū)ο筌浖舜嬖谏鲜鲆蕾囮P(guān)系外，還存在以下的依賴關(guān)系：類與類間的依賴；類與操作間的依賴；類與消息間的依賴；類與變量間的依賴；操作與變量間的依賴；操作與消息間的依賴；操作與操作間的依賴。2.18 問：簡述面向?qū)ο蟮膯卧獪y試與集成測試的思路策略。答：與傳統(tǒng)的單元不同， 面向?qū)ο筌浖y試中的單元是封裝的類和對象。類包含一組不同的操作， 并且某個或某些特殊操作可能作為一組不同的類的一部分而存在， 測試時不再測試單個孤立的操作， 而是測試操作類及類的一部分， 單元測試的意義發(fā)生了較大的變化。 對面