軟體產品測試複習資料
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、兩都比較
| 比較內容 | 黑盒測試 | 白盒測試 |
| 規劃方面 | 針對功能的測試 | 針對結構的測試 |
| 優勢方面 | 能確保從用戶的角度出發進行測試 | 能夠對程式內部的特定部位進行覆蓋測試 |
| 欠缺方面 | 無法測試程式內部特定部位如果規劃說明有誤，則無法發現問題 | 無法檢驗程式的外部特性，無法對未來實現規格說明的程式內部欠缺部分進行測試 |
| 套用舉例 | 邊界值分析、等價值劃分、 錯誤推斷法、因果圖法 | 語句覆蓋、判斷覆蓋、條件覆蓋、判斷/條件覆蓋、路經覆蓋 |
軟體檢視
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個級別
| 級別 | 說明 | 優點 | 缺點 | 用法 |
| 一級 | 錄製和回放 | 自動化的測試腳本能夠被 自動的生成，而不需要有 任何編程知識。 | 需要大量的腳本，當需求 和套用發生變化相應的腳 本也需要重新錄製 | 當測試的系統部會發生變化時 實現小規模的自動化。 |
| 二級 | 錄製，編輯 回放 | 減少了腳本的數量和維護 的工作量 | 需要一定的編程知識，頻繁 的變化難於維護 | 回歸測試時，用於被測試的應 用有很小的變化。 |
| 三級 | 編程和回放 | 確定了測試腳本的設計， 在項目的早期就可以開 始自動化的測試 | 要求測試人員具有很好的軟 件技能，包過設計開發 | 大規模的測試套件用於開發， 執行和維護的專業自動化測 試 |
| 四級 | 數據驅動的 測試 | 能夠維護和使用良好的並 且有效的模擬生活中真實 逐句的測試 | 軟體開發的技能是基礎，並 且需要訪問相關的測試數據 | 大規模的測試套件用於開發， 執行和維護的專業自動化測試 |
| 五級 | 使用動作詞 的自動化 | 測試用例的設計被從測試 工具中分離出來。 | 需要一個具有使用工具技能 和開發技能的測試團隊 | 專業的測試自動化將技能的使 用最最佳化的結合起來 |
（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開發人員。
