軟件測試類型
1）回歸測試
回歸測試: (regression testing): 回歸測試有兩類：用例回歸和錯誤回歸；用例回歸是過一段時間以后再回頭對以前使用過的用例在重新進行測試，看看會重新發現問題。錯誤回歸，就是在新版本中，對以前版本中出現並修復的缺陷進行再次驗證，並以缺陷為核心，對相關修改的部分進行測試的方法。
2）黑盒測試
已知產品的功能設計規格，可以進行測試證明每個實現了的功能是否符合要求。
也叫功能測試，是把測試對象看作一個黑盒子。利用黑盒測試法進行動態測試時，需要測試軟件產品的功能，不需測試軟件產品的內部結構和處理過程。采用黑盒技術設計測試用例的方法有：等價類划分、邊界值分析、錯誤推測、因果圖和綜合策略。
3）白盒測試
已知產品的內部工作過程，可以通過測試證明每種內部操作是否符合設計規格要求，所有內部成分是否以經過檢查。
黑盒測試又叫功能測試或數據驅動測試。黑盒測試主要是為了發現以下幾類錯誤：
1、是否有不正確或遺漏的功能？
2、在接口上，輸入是否能正確的接受？能否輸出正確的結果？
3、是否有數據結構錯誤或外部信息（例如數據文件）訪問錯誤？
4、性能上是否能夠滿足要求？
5、是否有初始化或終止性錯誤？
白盒測試又稱為結構測試或邏輯驅動測試。白盒測試主要是想對程序模塊進行如下檢查：
1、對程序模塊的所有獨立的執行路徑至少測試一遍。
2、對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。
3、在循環的邊界和運行的界限內執行循環體。
4、測試內部數據結構的有效性，等等。
Q: 黑盒測試和白盒測試各自的優點和缺點
黑盒測試的優點有：比較簡單，不需要了解程序內部的代碼及實現；與軟件的內部實現無關； 從用戶角度出發，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；基於軟件開發文檔，所以也能知道軟件實現了文檔中的哪些功能；在做軟件自動化測試時較為方便。
黑盒測試的缺點有：不可能覆蓋所有的代碼，覆蓋率較低，大概只能達到總代碼量的30%；自動化測試的復用性較低。
白盒測試的優點有：幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質量，發現代碼中隱 藏的問題。
白盒測試的缺點有：程序運行會有很多不同的路徑，不可能測試所有的運行路徑；測試基於代碼，只能測試開發人員做的對不對，而不能知道設計的正確與否，可能會漏掉一些功能需求；系統龐大時，測試開銷會非常大。
4）單元測試（模塊測試）
是開發者編寫的一小段代碼，用於檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用於判斷某個特定條件（或者場景）下某個特定函數的行為。
單元測試是由程序員自己來完成，最終受益的也是程序員自己。可以這么說，程序員有責任編寫功能代碼，同時也就有責任為自己的代碼編寫單元測試。執行單元測試，就是為了證明這段代碼的行為和我們期望的一致。
內容包括 模塊接口測試、局部數據結構測試、路徑測試、錯誤處理測試、邊界測試
策略包括邏輯覆蓋、循環覆蓋、同行評審、桌前檢查、代碼走查、代碼評審、景泰數據流分析
Q: 單元測試策略
單元測試策略主要有三種方式：
1) 自頂向下的單元測試策略：從頂層調用的單元做成樁模塊; 對第二層測試，使用上面已測試的單元做驅動模塊; 依次類推，直到全部單元測試結束。(比孤立單元測試的成本高很多)
2) 自底向上的單元測試策略：先對模塊調用的最底層模塊進行測試，模擬調用該模塊的模塊為驅動模塊; 其次，對上一層模塊進行單元測試，用已經被測試過的模塊做樁模塊，依次類推，直到全部單元測試結束。(比較合理的單元測試策略，但測試周期較長)
3) 孤立測試的單元測試策略：無需考慮每個模塊與其他模塊之間的關系，分別為每個模塊單獨設計樁模塊和驅動模塊，逐一完成所有單元模塊的測試。(最好的單元測試策略)
Q: 單元測試主要內容
單元測試大多數由開發人員來完成，測試人員技術背景較好或者開發系統軟件時可能會安排測試人員進行單元測試，大多數進行的單元測試都是開發人員調試程序或者開發組系統聯合調試的過程。討論這個問題主要是擴充一下讀者的視野。
單元測試一般包括五個方面的測試：
模塊接口測試
模塊接口測試是單元測試的基礎。只有在數據能正確流入、流出模塊的前提下，其他測試才有意義。模塊接口測試也是集成測試的重點，這里進行的測試主要是為后面打好基礎。測試接口正確與否應該考慮下列因素：
-輸入的實際參數與形式參數的個數是否相同；
-輸入的實際參數與形式參數的屬性是否匹配；
-輸入的實際參數與形式參數的量綱是否一致；
-調用其他模塊時所給實際參數的個數是否與被調模塊的形參個數相同；
-調用其他模塊時所給實際參數的屬性是否與被調模塊的形參屬性匹配；
-調用其他模塊時所給實際參數的量綱是否與被調模塊的形參量綱一致；
-調用預定義函數時所用參數的個數、屬性和次序是否正確；
-是否存在與當前入口點無關的參數引用；
-是否修改了只讀型參數；
-對全程變量的定義各模塊是否一致；
-是否把某些約束作為參數傳遞。
如果模塊功能包括外部輸入輸出，還應該考慮下列因素：
-文件屬性是否正確；
-OPEN/CLOSE語句是否正確；
-格式說明與輸入輸出語句是否匹配；
-緩沖區大小與記錄長度是否匹配；
-文件使用前是否已經打開；
-是否處理了文件尾；
-是否處理了輸入/輸出錯誤；
-輸出信息中是否有文字性錯誤。
-局部數據結構測試；
-邊界條件測試；
-模塊中所有獨立執行通路測試；
局部數據結構測試
檢查局部數據結構是為了保證臨時存儲在模塊內的數據在程序執行過程中完整、正確，局部功能是整個功能運行的基礎。重點是一些函數是否正確執行，內部是否運行正確。局部數據結構往往是錯誤的根源，應仔細設計測試用例，力求發現下面幾類錯誤：
-不合適或不相容的類型說明；
-變量無初值；
-變量初始化或省缺值有錯；
-不正確的變量名（拼錯或不正確地截斷）；
-出現上溢、下溢和地址異常。
邊界條件測試
邊界條件測試是單元測試中最重要的一項任務。眾所周知，軟件經常在邊界上失效，采用邊界值分析技術，針對邊界值及其左、右設計測試用例，很有可能發現新的錯誤。邊界條件測試是一項基礎測試，也是后面系統測試中的功能測試的重點，邊界測試執行的較好，可以大大提高程序健壯性。
模塊中所有獨立路徑測試
在模塊中應對每一條獨立執行路徑進行測試，單元測試的基本任務是保證模塊中每條語句至少執行一次。測試目的主要是為了發現因錯誤計算、不正確的比較和不適當的控制流造成的錯誤。具體做法就是程序員逐條調試語句。常見的錯誤包括：
-誤解或用錯了算符優先級；
-混合類型運算；
-變量初值錯；
-精度不夠；
-表達式符號錯。
比較判斷與控制流常常緊密相關，測試時注意下列錯誤：
-不同數據類型的對象之間進行比較；
-錯誤地使用邏輯運算符或優先級；
-因計算機表示的局限性，期望理論上相等而實際上不相等的兩個量相等；
-比較運算或變量出錯；
-循環終止條件或不可能出現；
-迭代發散時不能退出；
-錯誤地修改了循環變量。
模塊的各條錯誤處理通路測試：程序在遇到異常情況時不應該退出，好的程序應能預見各種出錯條件，並預設各種出錯處理通路。如果用戶不按照正常操作，程序就退出或者停止工作，實際上也是一種缺陷，因此單元測試要測試各種錯誤處理路徑。一般這種測試着重檢查下列問題：
-輸出的出錯信息難以理解；
-記錄的錯誤與實際遇到的錯誤不相符；
-在程序自定義的出錯處理段運行之前，系統已介入；
-異常處理不當；
-錯誤陳述中未能提供足夠的定位出錯信息。
5) 集成測試（組裝測試，聯合測試）
是單元測試的邏輯擴展。它的最簡單的形式是：兩個已經測試過的單元組合成一個組件，並且測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。在現實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，並最終擴展進程，將您的模塊與其他組的模塊一起測試。最后，將構成進程的所有模塊一起測試。
Q: 集成測試主要內容
（1）在把各個模塊連接起來的時候，穿越模塊接口的數據是否會丟失；
（2）一個模塊的功能是否會對另一個模塊的功能產生不利的影響；
（3）各個子功能組合起來，能否達到預期要求的父功能；
（4）全局數據結構是否有問題；
（5）單個模塊的誤差累積起來，是否會放大，從而達到不能接受的程度。
Q: 集成測試策略
1、大爆炸集成：屬於非增值式集成的一種方法，也稱為一次性組裝或整體拼裝。這種集成策略的做法就是把所有通過單元測試的模塊一次性集成到一起進行測試，不考慮組件之間的互相依賴性及可能存在的風險。（適應於一個維護型項目或被測試系統較小)
2、三明治集成：一種混合增量式測試策略，綜合了自頂向下和自底向上兩種集成方法的優點，因此也屬於基於功能分解的集成。這種方法樁和開發工作都比較小，但增加了定位缺陷的難度。
3、自頂向下集成：就是按照系統層次結構圖，以主程序模塊為中心，自上而下按照深度優先或者廣度優先策略，對各個模塊一邊組裝一邊進行測試。又可分為深度優先集成和廣度優先集成兩種方式。
(適應於產品控制結構比較清晰和穩定；高層接口變化較小；底層接口未定義或經常可能被修改；產口控制組件具有較大的技術風險，需要盡早被驗證；希望盡早能看到產品的系統功能行為。)
4、自底向上集成：從依賴性最小的底層模塊開始，按照層次結構圖，逐層向上集成，驗證系統的穩定性。
(適應於底層接口比較穩定；高層接口變化比較頻繁；底層組件較早被完成。)
5、高頻集成：高頻集成測試是指同步於軟件開發過程，每隔一段時間對開發團隊的現有代碼進行一次集成測試。
6、分層集成、分布式集成、基於路徑、功能、進度、風險、事件、使用等的集成等13種。
基於進度的集成
優點：具有較高的並行度；能夠有效縮短項目的開發進度。
缺點：樁和驅動工作量較大；有些接口測試不充分；有些測試重復和浪費。
6) 系統測試
是將經過測試的子系統裝配成一個完整系統來測試。它是檢驗系統是否確實能提供系統方案說明書中指定功能的有效方法。（常見的聯調測試）
系統測試的目的是對最終軟件系統進行全面的測試，確保最終軟件系統滿足產品需求並且遵循系統設計。
6.1) 安全性測試
屬於軟件測試的哪個階段?並試闡述安全測試的概念和用以評判系統安全性性能的主要指標。
是系統測試的一種類型，測試系統是否存在安全隱患和漏洞。
安全性測試就是要驗證系統內的保護機制能否抵御入侵者的攻擊。安全性測試的測試人員需要在測試活動中，撒氣不同的入侵方式來攻擊系統的安全機制，想盡一切辦法來獲取系統內的保密信息。
系統安全性性能的指標：
有效性：啟動嚴格的安全性性能所花費的時間占啟動整個系統所花費時間的比例。
生存性：當錯誤發生時，系統對緊急操作的支持，對錯誤的補救措施以及恢復到正常操作的能力，即抗挫能力。
精確性：衡量系統安全性控制的精度指標，圍繞所出現的錯誤數量、發生頻率及其嚴重性判斷。
反應時間：出錯時系統響應速度的快慢，一個安全性較強的系統要具備快速的反應速度。
吞吐量：用戶和服務請求的峰值和平均值。
Q: 軟件的安全性應從哪幾個方面去測試？
(1) 用戶認證機制：如數據證書、智能卡、雙重認證、安全電子交易協議
(2) 加密機制
(3) 安全防護策略：如安全日志、入侵檢測、隔離防護、漏洞掃描
(4) 數據備份與恢復手段：存儲設備、存儲優化、存儲保護、存儲管理
(5) 防病毒系統
6.2) 恢復性測試
屬於軟件測試的哪個階段?並試闡述恢復性測試的概念和進行恢復性測試分析時主要應考慮的問題。
恢復性測試使系統測試階段的一種方法，也叫容錯測試，用來檢查系統的容錯能力。通常若計算機系統出現錯誤，就必須在一定時間內從錯誤中恢復過來，修正錯誤並重新啟動系統。在進行恢復性測試時，要考慮的主要問題有：恢復期間的安全性過程。恢復處理日志方面的能力。當出現供電問題時的恢復能力。恢復操作后系統性能是否下降。 常用的恢復測試用例的設計方法：規范導出法、錯誤猜測法、基於故障的測試。
Q: 單元測試、集成測試、系統測試的側重點是什么？
單元測試針對的是軟件設計的最小單元--程序模塊（面向過程中是函數、過程；面向對象中是類。）, 進行正確性檢驗的測試工作, 在於發現每個程序模塊內部可能存在的差錯. 一般有兩個步驟: 人工靜態檢查\動態執行跟蹤
集成測試針對的是通過了單元測試的各個模塊所集成起來的組件進行檢驗,其主要內容是各個單元模塊之間的接口,以及各個模塊集成后所實現的功能.
系統測試針對的是集成好的軟件系統，作為整個計算機系統的一個元素,與計算機硬件\外設\某些支持軟件\數據和人員等其他系統元素結合在一起,要在實際的運行環境中,對計算機系統進行一系列的集成測試和確認測試.
（1）集成測試的主要依據概要設計說明書，系統測試的主要依據是需求設計說明書；
（2）集成測試是系統模塊的測試，系統測試是對整個系統的測試，包括相關的軟硬件平台、網絡以及相關外設的測試。
7) 驗收測試
是部署軟件之前的最后一個測試操作。驗收測試的目的是確保軟件准備就緒，並且可以讓最終用戶將其用於執行軟件的既定功能和任務。
驗收測試是向未來的用戶表明系統能夠像預定要求那樣工作。經集成測試后，已經按照設計把所有的模塊組裝成一個完整的軟件系統，接口錯誤也已經基本排除了，接着就應該進一步驗證軟件的有效性，這就是驗收測試的任務，即軟件的功能和性能如同用戶所合理期待的那樣。
包括正式驗收測試、alpha測試、beta測試三種測試。
7.1) Beta testing (β測試)
測試是軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。開發者通常不在測試現場
7.2)Alpha testing (α測試)
是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的受控測試
8) 兼容性測試
也稱“Configuration testing（配置測試）”，測試軟件是否和系統的其它與之交互的元素之間兼容，如：瀏覽器、操作系統、硬件等。驗證測試對象在不同的軟件和硬件配置中的運行情況。兼容測試主要是檢查軟件在不同的硬件平台、軟件平台上是否可以正常的運行，即是通常說的軟件的可移植性。
兼容的類型，如果細分的話，有平台的兼容，網絡兼容，數據庫兼容，以及數據格式的兼容。
包括向下兼容和交錯兼容，向下兼容是測試軟件新版本保留它早期版本功能的情況，交錯兼容是驗證共同存在的兩個相關但不相同的產品之間的兼容性。
Q: 配置和兼容性測試的區別是什么？
配置測試的目的是保證軟件在其相關的硬件上能夠正常運行，而兼容性測試主要是測試軟件能否與不同的軟件正確協作。
配置測試的核心內容就是使用各種硬件來測試軟件的運行情況，一般包括：
（1）軟件在不同的主機上的運行情況，例如Dell和Apple；
（2）軟件在不同的組件上的運行情況，例如開發的撥號程序要測試在不同廠商生產的Modem上的運行情況；
（3）不同的外設；
（4）不同的接口；
（5）不同的可選項，例如不同的內存大小；
兼容性測試的核心內容：
（1）測試軟件是否能在不同的操作系統平台上兼容；
（2）測試軟件是否能在同一操作系統平台的不同版本上兼容；
（3）軟件本身能否向前或者向后兼容；
（4）測試軟件能否與其它相關的軟件兼容；
（5）數據兼容性測試，主要是指數據能否共享；
配置和兼容性測試通稱對開發系統類軟件比較重要，例如驅動程序、操作系統、數據庫管理系統等。具體進行時仍然按照測試用例來執行。
9) 性能測試
系統在大並發下的響應速度和健壯性
通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試，兩者可以結合進行。通過負載測試，確定在各種工作負載下系統的性能，目標是測試當負載逐漸增加時，系統各項性能指標的變化情況。壓力測試是通過確定一個系統的瓶頸或者不能接收的性能點，來獲得系統能提供的最大服務級別的測試。包括負載測試、強度測試、數據庫容量測試、基准測試等類型。
10) 界面測試
界面是軟件與用戶交互的最直接的層，界面的好壞決定用戶對軟件的第一印象。而且設計良好的界面能夠引導用戶自己完成相應的操作，起到向導的作用。同時界面如同人的面孔，具有吸引用戶的直接優勢。設計合理的界面能給用戶帶來輕松愉悅的感受和成功的感覺，相反由於界面設計的失敗，讓用戶有挫敗感，再實用強大的功能都可能在用戶的畏懼與放棄中付諸東流。
區別在於，功能測試關注產品的所有功能上，要考慮到每個細節功能，每個可能存在的功能問題。性能測試主要關注於產品整體的多用戶並發下的穩定性和健壯性。界面測試更關注於用戶體驗上，用戶使用該產品的時候是否易用，是否易懂，是否規范（快捷鍵之類的），是否美觀（能否吸引用戶的注意力），是否安全（盡量在前台避免用戶無意輸入無效的數據，當然考慮到體驗性，不能太粗魯的彈出警告）？做某個性能測試的時候，首先它可能是個功能點，首先要保證它的功能是沒問題的，然后再考慮該功能點的性能測試
11) 易用性測試
界面的友好性，操作方便性等。
12) 需求測試的注意事項
是否使用了公司的模板、
文檔內容是否符合規范、
所有的需求是分級是否清析適當、
所有的需求是否具有一致性、
需求是否可行（即，該需求組合有解決方案）、
需求可否用己知的約束來實現、
需求是否足夠（即，可以把它送到一個規范的開發組織，並有一個生產出所需要產品的合理的可能性）、
所有的其它需求是交叉引用是否正確、
用戶描述是否清楚、
是否用客戶的語言來描述需求、
每個需求描述是否清楚沒有岐義，可以移交給一個獨立的組去實現時也能理解、
是否所有的需求都是可驗證的、
是否每條需求都具有獨立性，即使發生了變化也不會影響其它需求、
性能指標是否明確、
非功能性需求是否得到充分表現、
是否完整列出適用的標准或協議、
標准和協議之間是否存在沖突