目錄

第14章 質量相關簡答題

第15章 測試實際相關簡答題

第16章 測試基本相關簡答題

---

第14章 質量相關簡答題

1. 簡述基本的測量原則。

• 測量應該基于該應用領域正確的理論之上，并在測量的定義中確定測度的目標；
• 每一個技術測量的定義應該具有一致性和客觀性、無二義性；
• 測量在經驗和直覺上也應該有說服力；
• 測量的方法力求簡單、可計算性；
• 測量應該被剪裁以最適應特定的產品和過程，而且任何時候應盡可能使得收集和分析自動化；
• 應該用正確的統計技術來建立內部產品屬性和外部待測量特征的關系；
• 測量結果應該是可靠的，不會因為一些技術問題導致測量結果很大的偏離；
• 測量應該建立反饋機制。

2. 請指出走查、審查這兩種同行評審方法的不同？

• 走查和審查的區別是其正式性的等級。其中，審查是兩者之中更為正式。
• 走查的發現限于被評審文檔的意見，而審查的發現還同改進開發方法自身的工作相結合。
• 所以和走查相比，審查對一般的SQA做出了更大貢獻。

3. 簡述什么是軟件缺陷。

• 從產品內部看，軟件缺陷是軟件產品開發或維護過程中所存在的錯誤、毛病等各種問題；
• 從外部看，軟件缺陷是系統所需要實現的某種功能的失效或違背。

4. 簡述三種SQA的組織結構以及各自的優缺點。

① 獨立的SQA部門：

在整個企業的組織結構中設立一個獨立的職能和行政部門—SQA部門，該部門和其他職能部門平級。

優點：保護SQA工程師的獨立性和客觀性；有利于資源的共享。

缺點：SQA對流程的跟蹤和控制難于深入，往往流于形式，難于發現流程中存在的關鍵問題；由于和項目組的相互獨立，SQA工程師發現的問題不能得到及時有效的解決。

② 獨立的SQA工程師：

在這種組織結構中，SQA工程師屬于項目成員，向項目經理匯報。 ?

優點：SQA工程師能夠深入項目，較容易發現實質性問題；對于SQA工程師發現的問題，能夠得到較快短的解決。 ?

缺點：項目之間相互獨立， SQA工程師之間的溝通和交流有所缺乏，不利于經驗的共享和SQA整體的培養和發展；由于SQA工程師隸屬于項目組，獨立性和客觀性有所欠缺。

③ 獨立的SQA小組：

該組織結構是前面兩種組織結構的綜合結果。

特點：SQA組雖然不算一個行政部門，但具有相對的獨立性。同時，SQA工程師有隸屬于不同的項目組，在工作上向項目經理匯報。該結構綜合了上面兩種結構的優點，既便于QA融入項目組，又便于部門之間經驗的分享，還利于QA能力的提高。

5. 簡述軟件開發人員和質量保證人員的區別。

• 軟件開發人員負責技術工作，質量保證人員負責質量保證的計劃、監督、記錄、分析及報告工作。
• 軟件開發人員通過采用可靠的技術方法和措施，進行正式的技術評審，執行計劃周密的軟件測試來保證軟件產品的質量。軟件質量保證人員則輔助軟件開發組得到高質量的最終產品。

6. 簡述質量保證人員的主要工作內容。

• 為項目制定SQA計劃。該計劃在制定項目計劃時制定，由相關部門審定。它規定了軟件開發小組和質量保證小組需要執行的質量保證活動。
• 參與開發該軟件項目的軟件過程描述。
• 評審各項軟件工程活動，核實其是否符合已定義的軟件過程。
• 審計指定的軟件工作產品，核實其是否符合已定義的軟件過程中的相應部分。
• 確保軟件工作及工作產品中的偏差已被記錄在案，并根據預定規程進行處理。
• 記錄所有不符合部分，并向上級管理部門報告。跟蹤不符合的部分直到問題得到解決。
• 協調變更的控制與管理，并幫助收集和分析軟件度量的信息。

7. 簡述為什么需要評審？

• 從成本上來衡量：缺陷發現得越晚糾正費用越高，而軟件評審的重要目的就是通過軟件評審盡早的產品中的缺陷，減少大量的后期返工。
• 從技術上來衡量：前一階段的錯誤自然會導致后一階段的工作結果中有相應的錯誤，而且錯誤會逐漸累積，越來越多。
• 從效率上來衡量：

開發工程師：減少修訂缺陷的時間，提高編程效率；減少測試和調試時間

項目負責人：縮短開發周期；減少維護費用；項目風險和質量問題得到很好控制

測試工程師：可以將更多精力放到測試用例的設計上，提高測試效率

維護人員：維護工作減少；產品的可維護性增強

8. 什么是質量管理體系?

質量管理體系是在質量方面指揮和控制組織的管理體系。組織為了實現所確定的質量方針和質量目標，經過質量策劃將管理職責、資源管理、產品實現、測量、分析和改進等相互關聯或相互作用的過程有機的組成一個整體，構成質量管理體系。

9. 如何辨證的看待質量和客戶的關系？

• 客戶與質量的基本關系是相互依賴的關系。
• 客戶是質量的接受者，可以直接觀察或感覺到質量的存在。
• 質量相對于客戶存在，服務于客戶，而且由客戶判定。

10. 簡單評價ISO模型、McCall模型和Boehm模型3種軟件質量模型。

• 存在差別：軟件質量特性、影響因素或質量指標的定義不完全一致；總體上要表達的思想非常接近；
• 目的相同：構造軟件質量因素-準則-度量，3者綜合的軟件質量結構模型；
• ISO模型第一層（質量特性）和第二層（準則）的關系非常清楚，不像McCall模型和Boehm模型那樣存在交叉關系。

11. 請詳細描述軟件質量費用的經典模型？

在經典軟件質量費用模型中，軟件質量費用可以劃分為控制費用、控制失效費用。

其中，控制費用被進一步細化為預防費用和評價費用；

控制失效費用進一步細化為內部失效費用、外部失效費用。

（1）預防費用包括建立軟件質量基礎設施、更新并改進基礎設施以及完成其運行所需的常規活動的投資。

（2）評價費用花在特定項目或軟件系統中軟件錯誤的檢測上。

（3）內部失效費用是指改正在顧客現場安裝軟件之前實施設計評審、軟件測試及驗收測試時檢測到的錯誤而產生的費用。

（4）外部失效費用限定為改正由顧客或維護組在顧客現場安裝軟件系統之后檢測到的失效的費用。

第15章 測試實際相關簡答題

1. 什么是性能測試？性能測試主要包括什么內容？

是指通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試。

主要包括以下三個方面：應用在客戶端性能的測試，應用在網絡上性能的測試和應用在服務器端性能的測試

2. 簡單對比白盒測試與黑盒測試。

① 白盒測試
已知產品的內部工作過程，可以對程序每一行語句、每一個條件或分支進行測試
適合單元測試、集成測試
不適合系統測試

② 黑盒測試
不考慮程序內部結構和內部特性，而是從用戶觀點出發，針對程序接口和用戶界面進行測試
適合功能測試、易用性測試，驗收測試、確認測試；
不適合單元測試、集成測試

3. 測試用例設計

有函數f(x,y)，其中x∈[100,200]，y∈[5,15]。

請寫出該函數采用一般邊界值分析法計（自己百度）的測試用例（提示：共9個測試用例）。

參考答案

(100,Y),(200,Y),(101,Y),(199,Y),(X,5),(X,15),(X,6),(X,14),(X,Y)共9組

其中(101<X<199)，(6<Y<14)

4. 單元測試、集成測試、系統測試的側重點是什么？

① 單元測試是在軟件開發過程中要進行的最低級別的測試活動，在單元測試活動中，軟件的獨立單元將在與程序的其他部分相隔離的情況下進行測試，測試重點是系統的模塊，包括子程序的正確性驗證等。

② 集成測試，也叫組裝測試或聯合測試。在單元測試的基礎上，將所有模塊按照設計要求，組裝成為子系統或系統，進行集成測試。測試重點是模塊間的銜接以及參數的傳遞等。

③ 系統測試是將經過測試的子系統裝配成一個完整系統來測試。它是檢驗系統是否確實能提供系統方案說明書中指定功能的有效方法。測試重點是整個系統的運行以及與其他軟件的兼容性。

5. 簡述負載測試，容量測試和強度測試。

• 負載測試：在一定的工作負荷下，系統的負荷及響應時間。
• 強度測試：在一定的負荷條件下，在較長時間跨度內的系統連續運行給系統性能所造成的影響。
• 容量測試：是通過測試預先分析出反映軟件系統應用特征的某項指標的極限值，系統在其極限值狀態下沒有出現任何軟件故障或還能保持主要功能正常運行。

6. 白盒測試的重點以及相應的對策是什么？

1、模塊接口測試，重點檢查進出模塊的數據是否正確

2、模塊局部數據結構測試，重點檢查局部數據結構能否保持完整性

3、模塊邊界條件測試，重點檢查臨界數據是否正確處理

4、模塊獨立執行路徑測試，重點檢查由于計算錯誤，判定錯誤，控制流錯誤導致的程序錯誤

5、模塊內部錯誤處理測試，重點檢查內部錯誤處理設施是否有效

7. 什么是回歸測試？回歸測試的目的是什么？

① 回歸測試是指在修改了源代碼后，用原有的測試用例進行重新進行測試以確認修改沒有引入新的錯誤或導致其他代碼產生錯誤。

② 回歸測試的目的是所做的修改達到了預定的目的，如錯誤得到了改正，新功能得到了實現，能夠適應新的運行環境等，不影響軟件原有功能的正確性。

第16章 測試基本相關簡答題

1. 什么是樁模塊，什么是驅動模塊？

樁模塊是在進行單元測試時所設置的一種輔助測試模塊，它用來模擬被測試模塊工作過程中所調用的模塊。

樁模塊由被測模塊調用，它們一般只進行很少的數據處理，以便檢驗被測模塊與其下級模塊的接口。

驅動模塊是在進行單元測試時所設置的一種輔助測試模塊，它用來模擬被測試模塊的上一級模塊，相當于被測模塊的主程序。

驅動模塊在單元測試中接收數據，把相關的數據傳送給被測試的模塊，啟動被測模塊，并給出相應的結果。

2. 簡述驅動程序以及如何構建測試驅動程序。

• 測試驅動程序是一個運行測試用例并收集運行結果的程序。
• 測試驅動程序的設計應該相對簡單。
• 測試驅動程序必須是嚴謹的、結構清晰、簡單，易于維護。
• 對所測試的類說明變化具有很強的適應能力。
• 理想情況下，在創建新的測試驅動程序時，應該能夠復用已存在的驅動程序的代碼

3. 什么是軟件測試？

• 軟件測試是為了發現錯誤而執行程序的過程。
• 軟件測試是根據軟件開發各階段的規格說明和程序的內部結構而精心設計一批測試用例（即輸入數據及其預期的輸出結果），并利用這些測試用例去運行程序，以發現程序錯誤的過程。

4. 軟件測試和軟件開發過程具有怎么樣的關系？

• 軟件測試貫穿在軟件的開發過程中，在每個開發階段具有不同的任務，
• 在需求分析階段，主要測試需求分析，以及進行系統測試計劃的制定。
• 在詳細設計和概要設計階段，主要確保集成測試計劃和單元測試計劃完成。
• 在編碼階段，主要由開發人員測試自己負責開發的模塊的代碼。對于大型項目則需要有專門人員進行編碼階段的測試任務。
• 在測試階段，主要對系統進行測試，并提交相應的測試結果報告和測試分析報告。

5. 什么是測試用例？

• 測試用例是為特定的目的而設計的一組測試輸入、執行條件和預期的結果。
• 測試用例是執行的最小實體。

6. 軟件測試與調試有什么區別？

• 軟件測試與調試在目的、技術和方法等方面存在很大的區別
• 測試是為了發現軟件中存在的錯誤；調試是為了證明軟件開發的正確性。
• 測試以已知條件開始，使用預先定義的程序，且有預知的結果，不可預見的僅是程序是否通過測試；調試一般是以不可知的內部條件開始，除統計性調試外，結果是不可預見的。
• 測試是有計劃的，需要進行測試設計；調試是不受時間約束的。
• 測試經歷發現錯誤、改正錯誤、重新測試的過程；調試是一個推理的過程。
• 測試的執行是有規程的；調試的執行往往要求開發人員進行必要推理以至知覺的"飛躍"。
• 測試經常是由獨立的測試組在不了解軟件設計的條件下完成的；調試必須由了解詳細設計的開發人員完成。
• 大多數測試的執行和設計可以由工具支持；調式時，開發人員能利用的工具主要是調試器。