軟件產品測試

1、 軟件工程：採用工程的概念、原理、技術和方法來開發與維護軟件，把經過時間考驗而證明正確的管理技術和當前能得到的最後的技術方法結合起來。

2、基準配置又稱為基線配置，是經過階段評審後的軟件配置成分

3、軟件工程強調生命週期方法學和各種結構分析及結構設計技術

4、軟件工程的七條基本原理（1983年，由B.W.BOEHM提出）：

(1)用分階段的生命週期計劃嚴格管理。(2).堅持階段評審。(3).實行嚴格的產品控制。(4).採用現代程序設計技術。(5).結果應能清楚的審查。(6).開發小組人員應少而精。(7).承認不斷改進軟件工程實踐的必要性。

5生命週期應該知道嚴格的六類計劃：

（1）.項目概要計劃。（2）.里程碑計劃。（3）.項目控制計劃。（4）.產品控制計劃。（5）.驗證計劃。（6）.運行維護計劃。

6、軟件生命週期由軟件定義（細分三個階段問題定義、可行性研究、需求分析）、軟件開發（細分總體設計、詳細設計、編碼、單元測試、綜合測試）和軟件維護三個時期組成。

7、軟件維護通常有四類維護活動：a.改正性維護。b.適應性維護。c.完善性維護。d.預防性維護。

8、軟件設計文檔包含：構架、數據流示意圖、狀態變化示意圖、流程圖、註釋代碼。

9、軟件測試文檔：測試計劃、測試用例、軟件缺陷報告、歸納、統計和總結。

10、開發進度表：Gantt圖表

11、軟件產品組成：幫助文件、用户手冊、樣本和示例、標籤、產品支持信息、圖標和標誌、錯誤信息、廣告和宣傳材料、軟件的安裝説明、軟件説明文件、測試錯誤提示信息。

12、軟件是計算機系統中硬件相互依存的另一部分，它包括程序、相關數據及其説明文檔。

13、測試人員在軟件開發過程中的任務：尋找BUG；避免軟件開發過程中的缺陷；

衡量軟件的品質；關注用户的需求。

14軟件測試的目的：第一是確認軟件的質量，第二提供信息，第三軟件測試包括軟件產品的測試還有軟件開發過程。

15、軟件與工業產品相比具有的特性：軟件是一種邏輯實體，具有抽象性；軟件沒有明顯的製作過程；軟件在實用過程中沒有磨損，老化的問題；軟件對硬件和環境有着不同程度的依賴性；軟件的開發至今尚未完全擺脱手工式的開發方式生產效率低；軟件是複雜的，以後會更加複雜；軟件的成本相當貴軟件工作的牽涉到很多社會因素

16、軟件危機是計算機軟件在它的開發和維護過程中所遇到的一系列嚴重問題，概括地説，主要包含主要包含兩個方面：如何開發軟件，怎麼滿足日益發展的需求；如何維護數量不斷膨脹的已有軟件。

17、軟件危機的主要表現：

對軟件開發成本和進度的估計常常不準確；用户對已完成的軟件系統不滿意的現象經常發生；軟件產品的質量靠不住；軟件常常是不能維護；軟件通常沒有適當的文檔資料；軟件成本在計算機系統總成本中所佔比例在上升；軟件開發生產率提高的速度跟不上計算機應用迅速普及深入的趨勢。

18、軟件危機的內在原因：軟件生產本身存在着複雜性；軟件開發使用的方法和技術

19、符合下面任一個就是軟件錯誤：軟件未達到產品説明書中已經標明的功能；軟件出現了產品説明書中指明不會出現的錯誤；軟件功能超出了產品説明書指明的範圍；軟件未達到產品説明書雖未指出但應達到的目標；軟件測試員認為軟件難以理解不易使用或者用户認為軟件使用效果不好

20、軟件測試使用人工和自動手段來運行或測試某個系統的過程，其目的在於檢驗它是否滿足規定的需求，或弄清預期結果與實際結果之間的差別。

21、軟件質量的衡量：在正確的時間用正確的方式把一個工作做正確 ；符合一些應用標準的要求；質量本身是軟件達到最開始所設定的要求；質量代表它符合客户的需要。

22、軟件測試的總目標是確保軟件的質量

23、TMM測試成成熟度的5個級別：

Phase 0:.測試和調試沒有區別

Phase 1:測試的目的是為了表明軟件能工作

Phase2:測試的目的是為了表明軟件不能正常工作

Phase3:測試的目的不是為了證明什麼，而是為了把軟件不能正常工作的預知風險減低到能夠接受的程度

Phase4:測試不是行為，而是一種自覺的約束 不用太多的測試投入到產生風險的軟件上

23、測試工程師服務對象有四類人：軟件用户、項目經理、程序員、技術文檔工程師市場開發人員和技術支持工程師

24、軟件測試能做好的三件事：

（1）證明

獲取系統在可接受風險範圍內可用的信心

嘗試在非正常情況和條件下的功能和特性

保證產品的完整性

（2） 檢測

發現錯誤和系統不足

定義系統的能力和侷限性

提供組件、工作產品和系統的質量信息

（ 3 ）預防

澄清系統的規格和性能

儘可能減少錯誤的信息

在過程中儘早堅持錯誤

確認問題和風險，並提前發現解決問題

25、軟件測試的原則：從用户角度是希望通過軟件測試能充分暴露軟件中存在的問題和缺陷，從而考慮是否可以接受該產品。從開發者的角度是希望測試能表明軟件產品不存在錯誤，已經正確地實現了用户的需求，確立人們對軟件的信心。

26、達到原則需注意的地方：

（1）應當把“儘早和不斷地測試”作為開發者的座右銘

（2）程序員應該避免檢測自己的程序，測試工作應該由獨立的專業的軟件測試機構來完成。

（3）設計測試用例時應該考慮到合法的輸入和不合法的輸入以及各種邊界條件，特殊情況要製造極端狀態和意外狀態。

（4）一定要注意測試中的錯誤集中發生現象，這和程序員的編程水平和習慣有很大關係。

（5）對測試錯誤結果一定要有一個確認的過程，一般由A測試出來的錯誤，一定要由一個B來確認，嚴重的錯誤可以召開評審會進行討論和分析。

（6）制定嚴格的測試計劃，並把測試時間安排得儘量寬鬆，不要希望在極短的時間內完成一個高水平的測試。

（7）迴歸測試的關係性一定要引起充分的注意，修改一個錯誤而引起更多的錯誤出現的現象並不少見。

（8）妥善保存一切測試過程文檔，

27、軟件測試的對象：需求分析、概要設計、詳細設計以及程序編碼等各段所得到的文檔，包括需求規格説明、概要設計規格説明、詳細設計規格説明以及源程序。所以軟件測試貫穿整個軟件定義與開發期間。

28、軟件測試過程模型

（1）V模型，單元和集成測試應檢測程序的執行是否滿足軟件設計者的要求；系統測試應檢測系統功能、性能的質量特性是否達到系統要求的指標；驗收測試確定軟件的實現是否滿足用户的要求。侷限：他僅僅把測試作為愛編碼之後的一個階段，是針對程序進行的尋找錯誤的活動，而忽略了測試活動對需求分析、系統設計等活動的驗證和確認的功能。

（2）W模型，測試伴隨着整個軟件開發週期，而且測試的對象不僅僅是程序，需求、設計等同樣要測試，也就是説，測試與開發是同步進行的。有利於今早的、全面的發現問題。侷限：無法支持迭代的開發模型。對與當前軟件開發複雜多變的情況，W模型並不能解決管理面臨的困惑。

（3）H模型，軟件測試是一個獨立的流程，貫穿產品的整個週期，與其他流程併發的進行。

29、黑盒測試的定義：黑盒測試又稱功能測試、數據驅動測試或基於規格説明的測試，是一種從用户觀點出發的測試，把測試對象看做一個黑盒子在不考慮程序內部結構和內部特性，測試者只知道該程序輸入和輸出之間的關係或程序功能的情況下，依靠能夠反映這一關係和程序功能需求規格的説明書，來確定測試用例和推斷測試結果的正確性。

30、白盒測試定義：白盒測試又稱結構測試、邏輯驅動測試或基於程序的測試。它依賴於程序細節的嚴密檢驗，針對特定條件和循環設計測試用例，對軟件的邏輯路徑進行測試。在程序的不同點檢驗程序的狀態，來判定其實際情況是否與預期的狀態相一致。

31、最常見的程序覆蓋有：

（1）語句覆蓋。它要求被測試程序的每一條可執行語句在測試中至少執行一次，這是最弱的邏輯覆蓋準則。（2）分支覆蓋或判定覆蓋。要求程序中所有判斷的分支至少執行一次。（3）條件覆蓋。當判斷式中含有多個條件時，要求每個條件的取值至少一次為真。一次為假（4）判定/條件覆蓋。設計足夠的測試用例，使得判定中每個條件的所有可能結果至少出現一次，每個判定本身所有可能結果也至少出現一次。（5）路徑覆蓋。設計測試用例，覆蓋程序中所有可能的路徑 （6）條件組合。設計測試用例，使得每個判定條件結果的所有可能組合至少出現一次。

32、黑盒測試主要發現的錯誤：是否有不正確或遺漏的功能、在接口上輸入是否能正確地接受能否輸出正確的結果、是否有數據結構錯誤或外部信息訪問錯誤、性能上是否能夠滿足要求、是否有初始化或終止性錯誤。

33、白盒測試主要檢查的地方：對程序模塊的所有獨立的執行路徑至少測試一遍、對所有的邏輯判定真假取值各至少測一遍、在循環的邊界和運行的界限內執行循環體、測試內部數據結構的有效性。

34、兩都比較

35、 靜態分析技術：是一種不通過執行程序而進行測試的技術。功能是檢查軟件的表示和描述是否一致，沒有衝突或者沒有歧義。工具有：語法分析器、符號執行器

36、 動態分析技術：動態分析技術的主要特徵是計算機必須真正運行被測試的程序，通過輸入測試用例對其運行情況進行分析。

在動態分析技術中，最重要的是路徑和分支測試。路徑測試度量程序的最主要的質量特性是複雜度。分支測試需要程序中的每個分支至少被經過一次

37、軟件測試的過程：單元（模塊）測試、集成（組裝或聯調）測試、確認（合格性）測試、系統測試和驗收測試。

38、軟件質量是與軟件產品滿足明確或隱含需求的能力有關的特徵和特性的總和。

軟件質量可用六個特性來評價：功能性、可靠性、易用性、效率、可維護性和可一致性

39、全面質量管理含義：是一個組織以質量為中心，以全員參與為基礎，目的在於通過顧客滿意和本組織所有成員及社會受益而達到長期成功的管理途徑。

40、全面質量管理特點：全員參加；全過程；全面運用一切有效方法；全面控制質量因素。（三全：全員、全過程、全方位）

41、全面質量管理活的科學程序——PDCA（plan計劃,do實施,check檢查,action處理）

42、單元測試是軟件開發過程中要進行的最低級的測試活動，在單元測試活動中，軟件的獨立單元將在與程序的其他部分像個的情況下進行測試。

在結構化語言編程中，要測試的單元是函數或子過程。面向對像語言中要測試的基本單元是類。第四代語言中測試的基本單元它被典型劃分一個菜單或顯示界面。

43．靜態分析：是對軟件的源代碼進行研讀，查找錯誤或收集一些度量數據，並不需要對代碼進行編譯和執行。

44、動態分析：是通過觀察軟件運行時的動作，來提供執行跟蹤、時間分析以及測試覆蓋度方面的信息。

45.對單元測試認識的誤區

（1）.它浪費了太多的時間。

（2）.它僅僅證明了這些代碼做了什麼。

（3）.一個很優秀的程序員是不是可以不進行單元測試。

（4）.不管怎麼樣，集成測試將會被抓住對方的Bug。

（5）.它的成本效率不高。

46、單元測試的目的

（1）.保證局部代碼質量。

（2）.保證代碼整體結構良好。

（3）單元測試使排除代碼錯誤的成本最小化。

（4）.單元測試大幅度降低了後期測試和升級維護的時間成本。

（5）.單元測試自然的使開發流程變得“敏捷”，可以適應頻繁變動的需求，因為整體結構良好的代碼具有較好的可擴展性，自動迴歸測試又能保證修改不會引入新的錯誤。

47、單元測試工具分類：代碼檢查工具、覆蓋率測試工具、.內存檢查 、性能檢查、質量分析工具

48、Visual Unit,簡稱VU，新一代單元測試工具，功能強大，使用簡單，完全可視化，不需要寫測試代碼。

49、單元測試的內容

1.模塊接口、；測試模塊的數據流。

測試項目有：

（1）調用所測模塊時的輸入參數與模塊的形式參數在個數、屬性、順序上是否匹配；

(2) 所測模塊調用子模塊時，它輸入給子模塊的參數與子模塊中的形式參數在個數、屬性、順序上是否匹配。

（3）.是否修改了只做輸入用的形式參數。

（4）輸出給標準的參數在個數、屬性、順序上是否正確。

（5）.全局量的定義在各模塊中是否一致。

（6）.限制是否通過形式參數來傳送。

2.局部數據結構測試：模塊的局部數據結構是最常見的錯誤來源，應設計測試用例以堅持以下錯誤：

（1）.檢查不正確或不一致的數據類型説明

（2）.使用的未賦值或尚未初始化的變量

（3）。錯誤的初始值或錯誤的默認值

（4）.變量名拼寫錯誤或書寫錯誤

（5）.不一致的數據類型

3.路徑測試；對基本執行路徑和循環進行測試會發現大量的錯誤。根據白盒測試和黑盒測試用例設計方法設計測試用例。

（1）常見的不正確計算.

（2）.常見的比較和控制流錯誤

4.錯誤處理測試

（1）.出錯的描述難以理解

（2）.出錯的描述不足以對錯誤定位和確定出錯的原因

（3）.顯示的錯誤與實際的錯誤不符

（4）.對錯誤的條件處理不正確

（5）.在對錯進行處理之前，錯誤條件已經引起系統的干預等

5.邊界測試

50、進行單元測試的必要性

（1）.即使在沒有工具支持的情況下，單元測試能夠節約時間

（2）.有效的單元測試同時也是在審查軟件的規格説明

（3）.最優秀的程序員也會犯錯誤，也得驚醒單元測試（4）.集成測試不可能解決所有的缺陷

（5）.單元測試的成本效率高

51、單元測試和集成測試的區別

（1）測試對象有所區別。集成測試的被測對象是在概要設計中規劃的模塊及這些模塊間的組合。單元測試的測試對象是這些模塊下實現具體功能的單元，一般是對應詳細設計中所描述的設計單位。

（2）集成測試關注的是模塊間的接口，接口之間的數據傳遞關係，以及單元組合後是否實現預計的功能，集成測試組裝的對象比單元測試的對象級別高。

52、單元測試和系統測試的區別

兩者比較明顯，一般來説單元測試屬於白盒測試，關注的是單元的具體實現、內聚的邏輯結構、數據流向等，系統測試屬於黑盒測試，是站在用户角度上面看待系統，對系統進行測試，證明系統是否已經滿足用户要求，其測試是基於需求規格説明書。

53、單元測試的用例設計思路

一個完整的單元測試不僅僅要進行正向測試，即測試被測單元是否做了它應該做的事情，同時還應該做逆向測試，即被測單元有沒有做並不希望它做的事情。

（1）.為系統運行設計用例

（2）.為正向測試設計用例

（3）.為逆向測試設計用例

（4）.為滿足特殊需求設計用例

（5）.代碼覆蓋設計用例

（6）.覆蓋率指標完整設計用例

可使用的測試分析技術:分支測試、條件測試、數據定義使用測試和狀態轉換測試

54、白盒測試的目的：通過檢查軟件內部的邏輯結構，對軟件中的邏輯路徑進行覆蓋測試;再程序不同地方設立檢查點，檢查程序的狀態，以確定實際運行狀態與預期狀態是否一致。

55、白盒測試的特點：依據軟件説明書進行測試，對程序內部細節驚醒嚴密檢驗，針對特定條件設計測試用例，對軟件邏輯路徑進行覆蓋測試。

56、白盒測試實施步驟：測試計劃階段、測試設計階段、設計執行階段、測試總結階段。

57、白盒測試方法：靜態分析法和動態分析法。

58、VU特點

使用VU，黑盒方面，可以輕鬆完成功能測試、邊界測試、速度測試：白盒方面，可以輕鬆完成語句覆蓋、條件覆蓋、分支覆蓋、路徑覆蓋、使用VU隨時可以用迴歸測試檢驗修改是否引入新的錯誤

59、單元測試用例設計方法

（1）規範導出法

規範導出的測試是根據相關的規範描述來設計測試用例的，每一個測試用例用來測試一個或多個規範陳述語句。

（2）等價類劃分

等價類劃分是一種正式的測試用例設計方法，它基於被測單元的輸入，輸出所做的劃分，對每一個劃分中的所有輸入、被測單元有等價的行為，劃分也可以根據軟件所存取的數據確定，包括時間、輸入輸出順序、狀態。

（3）邊界值分析法

邊界值分析使用與等價類測試方法相同的等價類劃分，只是邊界值分析假定錯誤更多地存在於兩個劃分的邊界上，相應地為邊界上及其兩側的情況設計測試用例。

（4）狀態轉移測試法

對於以狀態機為模型或設計為狀態機的軟件，該測試是合適的測試方法。測試用例通過能導致狀態遷移的事件來測試狀態之間的轉換。用這種方法可設計逆向的測試用例，如狀態和事件的非法組合。

（5）分支測試法

在分支測試中，根據單元中的控制流分支或判斷點來設計測試用例，通常用來達到一定的判定覆蓋率

（6）條件測試法

條件測試中包含了許多測試用例設計技術，它們都致力於彌補在遇到複雜邏輯條件時分支測試的弱點

（7）數據定義-使用測試法

（8）錯誤猜測法

它是基於經驗和其他一些測試技術的方法。

60、六種覆蓋方法

:語句覆蓋、判定覆蓋、條件覆蓋、判定條件覆蓋、條件組合覆蓋、路徑覆蓋。

（1）語句覆蓋

主要特點：語句覆蓋是最起碼的結構覆蓋要求，語句覆蓋要求設計足夠多的測試用例，使得程序中每條語句至少被執行一次。

（2.） 判定覆蓋

主要特點、；判定覆蓋又稱分支覆蓋，它要求設計足夠多的測試用例，使得程序每個判定至少執行有一次為真值，有一次為假值，即：程序中每個分支至少執行一次，每個判斷的取真、假至少執行一次。

（3）. 條件覆蓋

主要特點：條件覆蓋要求設計足夠多的測試用例，使得判定中的每個條件獲得各種可能的結果，即每個條件至少有一次為真值，一次為假值、

（4. ）判定條件覆蓋

主要特點：設計足夠多的測試用例，使得判定中每個條件的所有可能結果至少出現一次次。每個判定本身設計有可能結果至少出現一次。

（5）.組合覆蓋

主要特點：要求設計足夠多的測試用列，使得每個判定中的條件結果的梭魚哦肯能組合至少出現一次。

（6.）路徑覆蓋

主要特點： 設計足夠多的測試用例，覆蓋程序中所有可能的路徑

61集成測試（組裝測試）其測試對象包括單元間的接口以及集成後的功能和性能，依據軟件概要設計説明書。

62集成測試的含義（組裝測試）：在單元測試的基礎上，應根據概要設計的要求將軟件中的各單元組裝成子系統或系統，在單元的組裝過程中，應對單元進行整體上測試，發現並清除各單元中出現的問題，確保集成到一起的各單元能作為一個整體完成預期的功能。

63集成測試應考慮：a將各模塊組裝起來的過程中穿越模塊接口的數據是否會丟失b各子功能組合起來能否達到預期的父功能c某模塊的功能是否會對另一個模塊的功能產生不利的影響d全局數據結構是否存在問題e單個模塊的誤差累積起來是否會放大到不可接受的程度。

64接口的分類：函數接口，消息接口，其它接口。

65集成測試的優點：a針對性強，較易發現錯誤並找出錯誤的原因和位置。b能有效的模擬幾乎所有的實際執行的流程故能更有效的發現軟件中的錯誤c 發現錯誤的修復成本要遠遠小於系統測試階段的錯誤修復成本。

66、集成測試和系統測試區別：集成測試的的集成過程中對功能和性能的測試，它主要依據是軟件的概要設計説明書。系統測試是對全部模塊集成完畢的軟件進行功能、性能及其他特性的測試，檢測其與系統中其他元素能否協同工作，以滿足用户的各種需求，它主要依據軟件需求規格説明書和相關行業標準。

67灰盒測試：一種介於黑盒測試和白盒測試之間的測試策略，它基於程序運行的外部表現，同時又結合程序內部邏輯結構來設計測試用例。

68灰盒測試的優點：a能夠進行基於需求的測試和基於路徑的覆蓋測試。B可深入被測對象的內部，便於錯誤的識別分析和解決c能夠保證設計的黑盒測試用例的完整性 防止功能或功能組合的遺漏d能夠減小需求或設計不詳細或不完整性對測試有效性造成影響。

69集成測試的策略：a一次性集成（大爆炸集成）b自頂向下集成c自底向上集成d混合式集成e核心系統先行集成f高頻集成g基於消息的集成h基於使用的集成、、

70一次性集成：又稱大爆炸集成，是一種非增值式集成方式；

71一次性集成策略：首先對每個單元進行單元測試然後一次性的將所有單元集成在一起，對它們進行測試，發現並清除在單元連接過程中出現的問題，得到最終要求的軟件系統.

72自頂向下集成方式：根據軟件的模塊結構圖按控制層次從高到低的順序對模塊進行集成，也就是從高到低向下逐步集成，並在集成過程中進行測試，直至組裝成符合要求的的最終軟件系統。

73自頂向下集成的步驟：a以主模塊為被測模塊，主模塊的下屬模塊則用樁模塊代替。b採用深度優先或寬度優先的策略，用實際模塊代替相應的樁模塊，它們的直接下屬模塊則又用裝模塊代替與一側模塊或子系統集成為新的子系統。C對新形成的子系統進行測試。發現和排除模塊集成過程中引起的錯誤，並做迴歸測試d若所有的模塊都已集成到系統中，則結束,否則轉b.

74.自頂向下集成方式的優點：可以及早地發現和修復模塊結構圖中的主要控制點存在的問題，以減少以後的返工；能較早地驗證功能或行性；最多隻需一個驅動模塊，減少了驅動模塊的開發成本；支持故障隔離。

75、自頂向下集成方式的缺點：需要開發和維護大量的樁模塊;由於樁模塊很難模擬實際子模塊的功能，到組裝後期易出錯，會導致大量的迴歸測試;為了在效性地進行集成測試，軟件系統的控制結構應具有較高的可測試性；易導致底層模塊的測試不夠充分。

76高頻集成方式：指同步於軟件開發過程，每隔一段時間開發人員的現有代碼進行一次集成測試。

77自底向上集成方式：根據軟件的模塊結構圖按控制層次從低到高的順序對模塊進行集成，也就是從最底層模塊向最高層逐步集成，並在集成過程中進行測試，直至組裝成符合要求的的最終軟件系統。

78自底向上集成方式的步驟：a為最底層模塊開發驅動模塊對最底層模塊進行測試。B用實際模塊代替驅動模塊，與直屬其子模塊集成一個子系統。C為新形成的子系統開發驅動模塊，對該子系統進行測試。D若該子系統以對應為主控模塊，即最高層模塊，則測試結束。否則轉B。

79自底向上集成方式的優點：a大大減少的驅動模塊的開發，雖然需要開發大量的驅動模塊，但其開發成本畢竟比裝模塊的成本小。B設計複雜算法和真正輸入輸出的模塊往往在底層，它們是最容易出現問題的的模塊，最先對底層模塊進行測試，減少了迴歸測試的成本。C在集成的早期很可能實現對模塊的並行測試，這提高了集成測試的效率。D支持故障隔離。

80、自底向上集成方式的缺點：需開發大量的驅動模塊，幫帶來了一定的測試成本；不能及早地發現和修復模塊結構圖中的主要控制點存在的問題；對底層模塊的異常很難測試到。

81混合式集成方式：結合了自頂向下集成方式和自底向上集成方式的優點，在對一個軟件的集成測試過程中，綜合使用了此兩種集成方案。

82核心系統先行集成方式：先對核心軟件部件進行測試，在此基礎上在按各外部軟件部件的重要程度逐個集成到核心系統中

83基於消息的集成方式：對於許多基於狀態機的系統如嵌入式系統面向對象方式開發系統，模塊間的接口主要通過消息來實現因而驗證消息路徑的正確性在這類軟件系統的集成測試中具有重要意義。

84、基於使用的集成方式：先對各個類間的依賴關係進行分析，測試獨立的類再測試使用一些服務器類的類，逐步測試具有依賴性的類，直至整個系統構造完成，從而驗證類間接口的正確性。

85、集成測試策略的選取：一次性集成多用於系統規模小的測試項目；自頂向下集成、自底向上集成、混合式集成多用於採用結構化方法開發的軟件項目；基於消息的集成方式用於嵌入式系統、面向對象系統；基於使用的集成方式用於面向對象系統中；核心系統先行集成和高頻集成方式用於許多複雜軟件項目。

86、按以下思路可確定集成模塊：確定當前主要希望測試的模塊：確定與該模塊關係密切的模塊；將該模塊與關係最緊密的模塊進行集成；再依次考慮集成模塊的外圍模塊。

87、在集成測試中合理的模塊劃分的特點：被集成的模塊關係緊密，共同完成某功能：外圍模塊便於屏弊；外圍模塊發給被集成模塊的消息能模擬大部分情況；模擬外圍模塊發給被集成模塊的消息便於構造、修改。

88、關鍵模塊具有的特徵：完成需求規格説明中的關鍵功能：中軟件模塊結構圖中處於較高層次；較複雜，易出錯；有明確的性能要求；被頻繁使用。

89集成測試的的步驟：a計劃集成測試b設計集成測試c執行集成測試d分析測試結果並提交測試報告

90制定集成測試計劃應考慮的因素：a測試的類容b集成測試策略c模塊代碼編制和測試進度是否於集成測試的順序一致d測試過程中需要的軟件工具及硬件設備。

91集成測試完成的標誌：a成功執行了集成測試計劃中所規定的多有測試內容b修正了集成測試中發現的錯誤c測試結果通過了專門小組的審評。

92.確認測試又稱為有效性測試。它的任務是驗證軟件的功能和性能，以及其特性是否與用户

的要求一致。

93.系統測試是將已集成好的軟件系統，作為計算機系統的一個元素，與計算機硬件、外設、

支持軟件、數據和操作人員等其他系統元素結合在一起，在實際使用環境下，對計算機系統

進行一系列的組裝和確認測試。系統測試實際上包含確認測試

94.系統測試的目的在於通過與系統的需求定義作比較，發現軟件與系統定義不符合與之矛盾

的地方，以驗證軟件系統的功能和性能等滿足其規約所指定的要求。測試用例依照需求規格説明書設計。 95、系統測試的種類：功能測試、性能測試、GUI測試

96、功能測試是系統測試中最基本的測試，它不管軟件內部的實現邏輯，主要根據產品的規格説明書和測試需求列表，驗證產品的功能實現是否符合產品的需求規格。

97、功能測試內容：是否有不正確或遺漏的功能：功能實現是否滿足用户需求和系統設計的隱藏需求；能否正確地接受輸入；能否正確地輸出結果；

98、黑盒測試試圖發現一下類型的錯誤：功能錯誤或遺漏；界面錯誤；數據結構或外部數據訪問錯誤；性能錯誤；初始化和終止錯誤

99、黑盒測試的測試用例設計方法：

（1）等價類劃分是把所有可能的輸入數據，即程序的輸入域劃分成若干部分，然後從每一個子集中選取少數具有代表性的數據作為測試用例。

劃分等價類：等價類是指某個輸入域的子集合。

有效等價類：是指對於程序的規格説明來説是合理的、有意義的輸入數據構成的集合

無效等價類：和有效等價類的定義恰巧相反

（2）邊界值分析法

（3）錯誤推測法：列舉程序中所有可能有的錯誤和容易發生錯誤的特殊情況，來設計測試用例。

（4）因果圖方法：因果圖生成測試用例步驟：

A分析軟件規格説明描述中，確定原因和結果，並給每個原因和結果賦予一個標識符

B分析軟件規格説明描述中的語義，找出原因與結果間，原因與原因間的關係，畫出因果圖

C由於語法和環境限制，在圖上用一些記號表明約束或限制條件

D把因果圖轉換為判定表

E把判定表的每一列拿出來作為依據，設計測試用例。

（5）判定驅動分析方法

判定表的組成：

條件樁、動作樁、條件項、動作項

規則：是指任何一個條件組合的特定取值及其相應要執行的操作

判定表的建立步驟：

確定規則的個數；列出所有的條件樁和動作樁；填入條件項；入動作項，等到初始判定表；簡化。

100.WinRunner是一種用於檢驗應用程序能否如期運行的企業級軟件功能測試工具。

101、WinRunner的特點在於：與傳統的手工測試相比，它能快捷、批量地完成功能點測試；能針對相同測試腳本，執行相同的動作，從而消除人工測試所帶來的理解上的誤差；

102.WinRunner的工作流程大致可以分為六個步驟

①識別應用程序的GUI ②建立測試腳本 ③對測試腳本出錯 ④在新版應用程序執行測試腳本 ⑤分析測試結果 ⑥回報缺陷

103.GUI測試指測試用户界面的風格是否滿足客户要求，文字是否正確，頁面美工是否好看，

文字、圖片組合是否完美，背景是否美觀，操作是否友好等等。

104、性能測試是通過自動化的測試工具模擬多種正常、峯值以及異常負載條件按來對系統的

各項性能指標進行測試。

105性能測試目的是驗證軟件系統是否能夠達到用户提出的性能指標，同時發現軟件系統中存在的性能瓶頸，優化軟件，最後起到優化系統的目的。主要包括以下幾個方面：

。評估系統的能力

。識別體系中的弱點

。系統調優

。檢測軟件中的問題

。驗證穩定性和可靠性

106.性能測試主要測試軟件的性能，包括負載測試，強度測試，數據庫容量測試，基準測試

以及競爭測試等。

107、負載測試指數據在超負荷中運行，查程序是否能承擔

108、強度測試指在系統資源特別低的情況下軟件系統運行情況

18、數據庫容量測試指通過存儲過程往數據庫表中插入一定數量的數據，看相關頁面的顯示。

109、基準測試與現有系統比較，檢驗是否與類似的產品有競爭性

110、競爭測試指使用各種資源，看其與其他相關係統對資源的爭奪能力

111、系統測試的過程

（1）完成系統測試計劃

（2）完成系統測試用例的設計

（3）評審/審批系統測試計劃

系統測試計劃的目的是對系統測試全過程的組織、資源、原則等進行描述和約束，並制

定系統測試過程的各個階段的確認和驗證任務以及時間進度安排，並提出對各項任務的評

估、風險分析和管理需求。

為了保證系統測試質量，必須在測試設計階段就對系統進行嚴密的測試設計。這就需要

我們在測試設計中，從多方面來綜合考慮系統規格的實現情況。通常需要從以下幾個層次

來進行設計：用户層、應用層、功能層、子系統層、協議層。

112、WinRunner是功能測試工具

113.WinRunner的測試過程分六個步驟

①教WinRunner識別被測軟件中的對象 ②錄製腳本 ③調試測試 ④執行測試

⑤查看測試結果 ⑥報告發現的錯誤

114、軟件測試文檔就是為將軟件測試當作一個項目一樣實施計劃和管理而引入的，它為測試項目的組織、規劃和管理提供了一個規範化的架構。

115、軟件測試文檔主要包括測試計劃、測試用例、測試規程、測試事件報告、測試總結報告等。測試文檔總所規定的內容可以作為對測試過程完備性的對照檢查表，有助於提高測試工程每個階段的能見度，極大地提高了測試工作的可管理性。

為了統一測試文檔的書寫標準，IEEE/ANSI制定了829-1983標準，還有其他的一些也用於指導軟件測試文檔的編寫，如我國制定的《計算機軟件測試文件百年之規範（GB/T 9386-1988）》

116、 測試文檔編寫規範（GB/T 9386-1988）簡介

（1）.引用標準

該規範的引用標準為：

GB/T 11457 軟件工程術語

GB 8566 計算機軟件開發規範

GB 8567 計算機軟件產品開發文件編制指南

（2）.關鍵術語定義

設計層：軟件項的設計分解（如系統，子系統，程序，模塊）

通過準則：一個軟件項或軟件特性的測試是否通過的判別依據

軟件特性：軟件項的顯著特性（如功能，性能或可移植性）

軟件項：源代碼，目標代碼，作業控制代碼，控制數據或這些項的集合。

測試項：作為測試對象的軟件項

（3）.規範的主要內容

該規範確定了各個測試文件的格式和內容，所提出的文件類型包括測試計劃，測試説明和測試報告。

測試計劃免除測試活動的範圍，方法，資源和進度，他規定被測試的項，被測試的特性，應完成的測試任務，擔任各項工作的人員職責及與本計劃有關的風險等。

117、測試説明包括三類文件

測試設計説明：詳細描述測試方法，規定該設計及其有關測試所包括的特性，還規定完成測試所需的測試用例和測試規程，並規定特性的通過準則。

測試用例説明：列出用於輸入的具體值以及預期的輸出結果，並規定在使用具體測試用例時，對測試規程的各種限制。將測試用例與測試設計封開，可以使它們用於多個設計並能在其它情形下重複使用。

測試規程説明：規定對於運行系統和執行指定的測試用例來實現有關測試設計所要求的所有步驟。

118、測試報告則包括四類文件：

測試項傳遞包括：指明在開發組和測試組獨立工作的情況下或者在希望正式開始測試的情況下為進行測試而傳遞的測試項。

測試日誌：測試組用於記錄測試執行過程中發生的情況。

測試事件報告：描述在測試執行期間發生並需進一步調查的一切事件。

測試總結報告：總結與測試設計説明有關的測試活動。

119.對規範的實施

使用該規範的每個單位，要規定測試階段所應有的特性文件，並在測試計劃中規定測試完成後所能提交的全部文件。

使用該規範的每個單位應該補充規定對內容的要求和約定，及便反映總結在測試，文件控制，配置管理和質量保證方面所用的特定方法，設備工具。

一下是規範中的文件編制實施及使用指南

（1） 實施指南

在實施測試文件編制的初始階段可先編寫測試計劃於測試報告文件。測試計劃將為整個測試過程提供基礎。測試報告將鼓勵測試單位以良好的方式記錄整個測試過程的情況。

（2） 用法指南

在項目計劃及單位標準中，指明在那些測試活動中需要那些測試文件，並可在文件中加入一些內容，使各個文件適應一個特定的測試項及一個特定的測試環境。

120《軟件測試文件編制規範》中的內容要求

以下是規範中各個測試文件的書寫格式及內容。

a測試計劃

(1) 測試計劃名稱（該計劃的第1章）

(2) 引言（該計劃的第2章）

(3) 測試項

(4) 被測試的特性

(5) 不被測試的特性

(6) 方法

(7) 項通過的準則

(8) 暫停標準和再啓動要求

(9) 應提供的測試文件

(10) 測試任務

(11) 環境要求

(12) 職責

(13) 人員和訓練要求

(14) 進度

(15) 風險和應急

(16) 批准

b測試設計説明

（1） 測試設計説明名稱

（2） 被測試的特性

（3） 方法詳述

（4） 測試用例名稱

（5） 特性通過準則

c測試用例説明

（1） 測試用例説明名稱

（2） 測試項

（3） 輸入説明

（4） 輸出説明

（5） 環境要求

（6） 特殊的規程要求 （7）用例間的依賴關係

d測試規程説明

（1） 測試規程説明名稱

（2） 目的

（3） 特殊要求

（4） 規程步驟

e測試項傳遞報告

(1) 傳遞報告名稱

(2) 傳遞項

(3) 位置

(4) 狀態

(5) 批准

f測試日誌

（1） 測試日誌名稱

（2） 描述

（3） 活動和事件條目

g測試事件報告名稱

（1） 測試事件報告取一個專用名稱

（2） 摘要

（3） 事件描述

（4） 影響

h測試總結報告

1. 規定該報告必須由哪些人（姓名和職務）審批，併為簽名和日期留出位置。

121、自動化測試就是通過自動化測試工具或其他手段，按照測試工程師的預定計劃進行自動的測試，其目的是減輕手工測試的的勞動量，並且提高軟件質量 。

自動化的5個級別

122、軟件測試自動化的優點：

（1） 提高軟件測試的工作效率

（2） 對新版本執行迴歸測試

（3） 解決測試的沉悶，耗時的問題

（4） 替代手工測試的困難

（5） 具有一致性和可重複性

（6） 更好的利用資源 （7）解決測試與開發之間的矛盾 （8）增加軟件的信任度

123、RPT是IBM公司基於Eclipse平台及開源的測試和監控框架Hyades,開發的性能測試解決方案，它可以幫助測試人員和性能工程師驗證系統的性能，識別和解決各種性能問題。

RPT對系統的性能測試進行分析的過程包括四個步驟：測試記錄，測試調度，測試運行，測試結果分析。

124、軟件測試自動化的侷限性：

（1） 不能期望自動測試能取代人工測試

（2） 自動化測試部能發現新缺陷

（3） 自動化測試工具本身不具有想象力

（4） 技術問題，組織問題，腳本維護的阻力

（5） 自動化測試並不適合於所有公司，所有項目

125、測試自動化要關注的幾個問題：

（1） 測試個例的生成

（2） 測試的執行和控制

（3） 測試結果與標準的輸出的對比

（4） 不吻合的測試結果的分析，分類，記錄和通報

（5） 總測試狀況的統計報表的產生

（6） 自動測試與開發中產品每日構建的配合

126、自動測試工具簡介：

功能測試工具：Winner QuickTest Pro Rational XDE Tester QARun Slik Test e-tester

WebFT PureTest

性能測試工具:LoadRuner Astra LoadTest Rational Robot( 性能和功能測試) QAload

SilkPerformer e-Load Web Applivation Stress Tool Webload

測試管理工具:Test Diorector QAdirector SlikCentral Test/Issue Manger e-Monitor

白盒測試工具：Rational Purifyplus Jtest(JAVA白盒) C++(C++白盒)

Test（NET白盒）

127、RFT是一款先進的，自動化的功能和迴歸測試工具，它適用於測試人員和GUI開發人員。