黑盒測試： 黑盒測試是將程式視為一個黑盒子，測試目標與程式的內部結構完全無關，而是將重點集中放在發現程式不按其規範正確執行的環境條件。黑盒測試不需要去了解程式的內部結構，如果想用黑盒測試來發現程式的錯誤，判定的標準就是窮舉輸入測試，將所有可能輸入條件都作為測試用例。 白盒測試：白盒測試允許我們檢查程式的內部結構，從中獲取測試資料。用的是窮舉路徑測試的方法。 軟體測試的原則： （1）測試中一個必須的部分是對預期輸出或結果進行定義 （2）程式設計師應當避免測試自己編寫的程式 （3）編寫軟體的組織不應當測試自己編寫的軟體 （4）應當徹底檢查每個測試的執行結果 （5）測試用例的編寫不僅僅應當根據有效和預期的輸入情況，而且也應當根據無效和未預料的輸入情況 （6）檢查程式是否“未做其應該做的”，僅是測試的一半，測試的另一半是檢查程式是否做了其不應該做的 （7）避免測試用例後即棄，除非軟體本身就是一個一次性軟體 （8）計劃測試工作時，不應默許假定不會發生錯誤 （9）程式某部分存在更多錯誤的可能性，與該部分已發現錯誤的數量成正比 軟體測試是為發現錯誤而執行程式的過程，一個好的測試用例具有高效的發現某個尚未發現的錯誤的可能性，一個成功的測試用例能夠發現尚未發現的錯誤 測試用例的設計 白盒測試：白盒測試關注的是測試用例執行的程度，或覆蓋程式邏輯結構（原始碼）的結構 邏輯覆蓋測試 語句覆蓋： 判定覆蓋/分支覆 蓋：編寫足夠的測試用例，使得每一個判斷都至少有一個為真和為假的輸出結果，判定覆蓋通常可以滿足語句覆蓋，判定覆蓋是一種比語句覆蓋較強的準則 條件覆蓋：條件覆蓋的準則比判定覆蓋的準則更強，在條件覆蓋情況下，要編寫足夠的測試用例，以確保將每一個判斷中的每條語句的所有可能結果全部執行一遍。 多重條件覆蓋：將每個判定中所有的條件結果的組合以及所有入口點都執行一次，多重條件準則要優於其他準則 等價劃分：使用等價劃分方法，設計測試用例：（1）確定等價類（2）生成測試用例 確定等價類是選取每一個輸入條件，並將其劃分為兩個或更多的組。 有效等價類：對程式的有效輸入 無效等價類：其他任何可能輸入的條件 例：數量可以是從1到999 有效等價類：（1<數量<9999） 無效等價類（數量<1,數量>999） 生成測試用例：（1）為每個等價類設定一個不同的編號，（2）編寫新的測試用例，儘可能多的覆蓋那些尚未被涵蓋的等價類（3）編寫新的用例，覆蓋一個且僅一個尚未被覆蓋的等價類 邊界值分析：所謂邊界條件，指輸入或輸出等價類中，恰好處於邊界，或超過邊界或在邊界以下的狀態。 邊界值分析與等價類劃分的不同： （1）與從等價類中任意挑出一個值作為代表不同，邊界值分析需要選擇一個或多個元素，以便等價類的每一個邊界都經過一次測試。 （2）與僅僅關注輸入條件不同，邊界值分析需要一定的創造性 因果圖：因果圖是一個根據條件的組合，而生成測試用例的系統方法 模組（單元）測試 1、測試用例的設計 設計測試用用例時，需要使用兩種型別的資訊，模組的規格說明和模組的原始碼，模組測試總體上是面對白盒測試的。 模組測試的測試用例過程如下：使用一種或多種白盒測試的方法，分析模組的邏輯結構，然後使用黑盒測試的方法對模組的測試說明以補充測試用例。 增量測試與非增量測試： 增量測試:先將下一步要測試的模組組裝到測試完成的模組集合中然後再進行測試 兩種增量測試的方法： （1）自頂向下測試：從程式的頂部或初始模組開始，測試開始之後，挑選哪一個模組進行增量測試，沒有唯一正確的方法，唯一的原則是要合乎條件的下一個模組，至少該模組的從屬模組事先經過了測試 優點：如果主要的缺陷發生在程式的頂層將會非常有利；一旦引入IO功能，提交測試用例會更容易；早期的程式框架可以進行演示，並可激發積極性 缺點：必須開發樁模組；樁模組要比最初表現的更復雜；在引入IO功能之前，向樁模組中引入測試用例比較困難；建立測試環境可能很難； （2）自底向上測試：從程式的終端模組開始測試，有多個模組時，測試順序由模組關鍵程度決定。 優點：如果主要的缺陷發生在程式的底層將會非常有利，測試環境比較容易建立，觀察測試輸出比較容易。 缺點：必須開發驅動模組，直到最後一個模組新增進去，程式才能形成一個整體。 非增量測試：先獨立的測試每個模組，然後再將這些模組組裝成完整的程式。單獨測試每個模組需要一個驅動模組和一個或多個樁模組。驅動模組是人們編寫的一個模組，用來將測試用例驅動或傳輸到被測模組中 增量測試與非增量測試的區別：（1）非增量測試所需要的工具多（2）如果使用了增量測試，可以較早的發現模組中與不匹配介面，不正確假設相關的程式設計錯誤。（3）使用增量測試，除錯會更容易一些（4）增量測試會將測試進行的更徹底。（5）非增量測試佔用的時間會更少（6）模組測試階段開始時，如果使用的是非增量測試，就會有許多的機會進行並行操作，所有的模組可以同時測試三個 高階測試： 軟體產品開發週期模型：終端使用者->需求->目標->外部規格說明->系統設計->程式結構設計->模組介面規格說明->程式碼 1、將終端使用者的要求轉變成一個書面需求 2、通過評估可行性與成本，消除相互抵觸的使用者需求，將使用者需求轉化為具體的目標 3、將目標轉化為一個準確的產品規格說明，，把產品視為一個黑盒子，僅考慮介面以及其與終端使用者的交付 4、如果產品是一個系統，將系統分割為單獨的程式，部件，或者子系統，並定義它們的介面 5、通過定義每個模組的功能，模組的層次以及模組間的介面，設計程式 6、設計一份準確的規格說明書，定義每個模組的介面與功能 7、將每個模組的介面規格說明轉化為每個模組的程式碼演算法 功能測試：功能測試是試圖發現程式與其外部規格說明之間存在不一致的過程，功能測試是一種黑盒測試。常用的方法是：等價類劃分法，邊界值分析法，因果圖分析法和錯誤猜測法 系統測試：系統測試並非是測試整個系統，而是將系統或程式與其初始目標進行比較 系統測試並不侷限於系統，也可以是一個程式；如果產品沒有書面的，可度量的目標，系統測試也就無法進行 系統測試的測試用例：能力測試,容量測試，強度測試，易用性測試，安全性測試，效能測試，儲存測試，配置測試，相容性/配置/轉換測試，安裝測試，可靠性測試，可恢復性測試，適用性測試，文件測試，過程測試，系統測試的執行 驗收測試：驗收測試是將程式與其最初的需求以及終端使用者當前的需求進行比較的過程，驗收測試最好的方法就是設計測試用例，盡力證明程式沒有滿足合同要求。 安裝測試：為了發現安裝過程中的錯誤 除錯方法：暴力法除錯，歸納法除錯演繹法除錯，回溯法除錯，測試法除錯 測試分類： 按開發階段分 1）單元測試：是對軟體組成單元進行測試。測試的物件是軟體設計的最小單元位：模組。 測試內容：模組介面測試，區域性資料結構測試，路徑測試，邊界測試。 測試方法：白盒測試 2）整合測試：聯合測試，將程式模組採用適當的整合策略組裝起來，對系統的介面及整合後的功能進行正確性檢測的測試工作。 測試內容：模組之間資料傳輸，模組之間功能衝突，模組組裝功能正確性。 測試方法：黑盒測試與白盒測試相結合。 3）系統測試：將軟體系統看成是一個系統的測試。 測試內容：功能，介面，可靠性，易用性，相容性，安全性等。 測試方法：黑盒測試 4）迴歸測試：是指修改了舊程式碼後，重新進行測試以確認修改沒有引入新的錯誤或導致其他程式碼產生錯誤。在整個軟體測試過程中佔有很大的工作量比重。 5）冒煙測試：對一個硬體或一個硬體元件進行更改或修復後，直接給裝置加電，如果沒有冒煙元件就通過了測試。 6）驗收測試（交付測試）： 部署軟體之前的最後一個測試操作。 測試方法：黑盒測試 按測試實施組織 a測試：由一個使用者在開發環境下進行測試，也可以是公司內部的使用者在模擬實際操作環境下進行的測試。 Beta測試：是一種驗收測試，由軟體的終端使用者們在一個或多個客房場所進行。 區別： （1）場所不同：a測試是指把使用者請到開發方的場所來測試，beta測試是指在一個或多個使用者的場所進行測試。 （2）a測試先於beta測試執行，使用者數量相對比較少時間比較集中；beta使用者數量相對比較多時間不集中。 第三方測試：介於開發方和使用者方間的組織的測試。 按是否執行劃分： 1）靜態測試 包含程式碼靜態分析和文件測試 2）動態測試 通過執行被測程式，檢查執行結果與預期結果的差異，並分析執行效率，正確性和健壯效能。 按是否手工劃分： 1）手工測試 2）自動化測試：就是在預設條件下執行系統或應用程式，評估執行結果，預先條件應包括正常條件和異常條件。 按是否檢視程式碼： 1）黑盒測試 把被測軟體當作一個黑盒子，不關心盒子內部結構是什麼，只關心軟體的輸入資料和輸出資料。 2）白盒測試 又稱結構測試，透明盒測試，開啟盒子研究裡面的原始碼和程式結果。 灰盒測試 是介於白盒測試與黑盒測試之間的一種測試，多用於整合測試階段，不僅關注輸出，輸入的正確性，同時也關注程式內部情況。 *黑盒測試：測試人員把軟體產品看作是一個黑盒子，在測試過程中只需要關心對這個軟體黑盒進行操作會得到什麼樣的結果，不必深入瞭解它的內部實現機制所進行的測試活動。 *為什麼做黑盒測試？ 驗證軟體產品是否符合需求文件的設計；證實軟體產品符合終端使用者的需求。 *黑盒測試方法： 輸入值域和輸出值域； 等價類劃分；（對元件的輸入值域和輸出值域進行劃分的模式來設計測試用例） 邊界值分析；（邊界值就是用來界定各個有序集合之間的邊界點，一般都將最大值和最小值作為邊界值） 狀態轉換測試法；（通常用狀態轉換圖，狀態轉換模型，狀態轉換表來描述被測元件各狀態之間的轉換。 因果圖法；（多組因果關係的邏輯組合）。 語法測試； *白盒測試：也稱結構測試或邏輯驅動測試，通過分析被測元件的內部工作原理，通過測試來檢測被測元件內部的執行是否符合產品規格說明書。 *白盒測試方法： 1）語句覆蓋：程式中每一個可執行語句都能執行一次的測試用例。 2）判定覆蓋：判斷語句在設計測試用例時，要設計判斷語句有true和false兩種結果的測試用例。 3）條件覆蓋：設計測試用例針對判斷語句中每個條件表示式true和false各取值一次，不考慮結果。 4）判定條件覆蓋：設計測試用例時，使得判斷語句中每個條件表示式的所有可能結果至少出現一次，每個判斷語句本身的可能結果也至少出現一次。 5）條件組合覆蓋：設計測試用例時，使得每個判斷語句中條件結果的所有可能組合至少出現一次。 6）路徑覆蓋：設計測試用例時，覆蓋程式中所有可能的執行路徑。 覆蓋準則由弱到強依次是語句覆蓋、判定覆蓋（分支覆蓋）、條件覆蓋、判定/條件覆蓋、條件組合覆蓋、路徑覆蓋。 *黑盒測試和白盒測試的區別： （1）黑盒測試 完全不考慮程式內部結構和內部特性；多用於針對軟體介面，軟體功能，效能，安全性等方面進行測試。 黑盒法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使用。 適用於軟體測試的各個階段。 （2）白盒測試 全面瞭解程式內部結構，對所有邏輯路徑進行測試。 多用於軟體內部實現機制的正確性，有效性進行檢驗。 白盒測試是窮舉路徑測試。 多用於軟體測試的單元測試階段。 單元測試是對軟體的最基本組成單元進行測試，它是軟體測試中最低級別的測試。 *為什麼要對程式進行單元測試？ 保證被測程式碼有正確的行為，可以驗證程式碼是否與詳細設計一致。 窺探軟體內部的實現機制，可以發現其他測試階段難以發現的軟體缺陷。 充分的單元測試可以極大地降低軟體的開發成本。 整合測試是對軟體已測試完成的單元或元件之間的介面進行測試，又稱為組裝測試。 為什麼要對程式進行整合測試？ 可以發現單元測試階段難以發現的缺陷； 逐步的整合測試可以有效地定位軟體因整合新的元件所引入的缺陷； 系統測試就是所有子模組完成整合測試後，測試人員按照規格說明書進行的功能驗證測試。 使用者驗收測試：就是交付給使用者，讓使用者執行產品驗收所進行的測試。 迴歸測試:當開發人員對軟體產品的基線版本做出任何改變時，測試人員針對這些改變進行有針對性的測試活動。 冒煙測試：是指對一個硬體或硬體元件進行更改或修復後直接給裝置加電，如果沒有冒煙，則表示該元件通過了測試。軟體測試中指每個開發部門開發出的版本建立後，由測試部門或整合部門對系統的主要基本功能進行簡單測試。 為什麼進行冒煙測試？ 為了節省測試部門的人力。 安全性測試：指有關驗證應用程式的安全級別和識別潛在的安全性缺陷的過程。 相容性測試：是指待測的軟體與硬體之間，與其它軟體之間，軟體新舊版本之間以及在不同網路環境中是否存在衝突的測試。 易用性測試：易用性是一種以使用者為中心的設計概念，易用性設計的重點在於讓產品的設計能夠符合使用者的習慣與需求。

你所熟悉的軟體測試型別都有哪些？ 功能測試：也叫黑盒測試，所佔比例最大，考慮每個細節，所有可能的功能問題。 效能測試：通過自動化測試工具模擬多種正常，峰值以及異常負載條件來對系統的各項效能指標進行測試。負載測試和壓力測試都屬於效能測試。 介面測試：介面是軟體與使用者互動的最直接的層，合理的介面能給使用者帶來輕鬆愉悅的感覺。 測試與除錯的區別： 目的不同：測試任務是發現程式中的缺陷，除錯任務是定位並且解決程式中的問題。 角色不同：除錯由開發人員來執行，測試主要是由測試人員和開發人員來執行 ，黑盒測試主要由測試人員完成，單元/整合測試主要由開發人員完成。 執行級階段：測試貫穿軟體開發生命週期，除錯一般在開發階段 軟體測試的目的和原則: 目的：驗證軟體有或沒有問題。 原則：以客戶為中心，遵循軟體測試的規範，流程，標準和要求。 軟體的生命週期： 軟體的生命週期是指從軟體產品的設想開始到軟體不再使用而結束的時間。 生命週期：需求分析，計劃，設計，編碼，測試，允許維護。

測試用例和測試指令碼： 實施測試用例是向被測試系統提供輸入資料，操作或者各種環境設定以及期望結果的一個特定的集合。測試指令碼是為了進行自動化測試而編寫的指令碼，測試指令碼的編寫必須對應相應的測試用例。 使用者登入介面測試用例： （1）元件相對大小和位置有序，協調，整齊。 （2）每組元件的字型，風格保持一致。 （3）輸入密碼時密碼不能是明文，應是星號或其它符號代替。 （4）一個視窗移動所有元件都隨之移動。 （5）隨著字元的不斷輸入郵箱地址和密碼域文字框不應隨之拉長。 （6）最大化最小化按鈕不應使用。 （7）提交時郵箱地址和密碼不能為空。 （8）如果輸入不正確，單擊sign in按鈕應有友好而足夠的資訊提示使用者。 （9）參照需求，是否同一使用者可以在多臺機器上同時登入，須進行測試。 網站如何測試： （1）分析設計需求：查詢需求說明，網站設計等相關文件。 （2）制定測試計劃：確定測試範圍和測試策略。 1.功能性測試：連結測試，連線是否正確跳轉，是否存在空頁面和無效頁面 2.介面測試：頁面是否風格統一美觀；頁面佈局是否合理，控制元件是否可以正常使用；文字細節。 3.效能測試：壓力測試；負載測試；強度測試。 4.安全性測試：基本登入功能的檢查；是否存在溢位錯誤導致系統崩潰；如果需要高階的安全性測試，確定獲得專業安全公司的幫助，外包測試。 5.相容性測試：瀏覽器的相容性，作業系統的相容性，軟體平臺的相容性；資料庫的相容性。 測試一個紙杯的過程： 功能性：用水杯裝水看水漏不漏，水能不能被喝到； 安全性：杯子有沒有毒或細菌 可靠性：杯子從不同高度落下的損壞程度 可移植性：杯子在不同地方，溫度等環境下是否可以正常使用 相容性：杯子是否能夠容納果汁，白水，酒精，汽油等。 易用性：杯子是否燙手，是否有防滑措施，是否方便易用。 使用者文件：使用手冊是否對杯子的用法，限制，使用條件等有詳細描述 壓力測試：在針上面不斷加重水杯中水的重量，看壓強多大時會穿透。

詳細描述一個測試活動完整的過程： 1）專案經理和客戶交流完成需求文件，由開發人員和測試人員共同完成需求文件的評審，評審的內容包括：需求描述不清楚的地方和可能有明顯衝突或者無法實現功能的地方。 2）專案經理綜合他們的意見，完成專案計劃。然後進入專案開始跟蹤。 3）開發人員根據需求文件完成需求分析文件，測試人員進行評審，審評主要內容有是否有遺漏或者雙方理解不同的地方。測試人員完成測試計劃文件。 4）測試人員根據修改好的需求文件開始寫測試用例，同時開發人員完成概要設計文件，詳細設計文件，兩份測試文件成為測試人員撰寫測試用例的補充材料。 5）測試用例完成後，測試和開發需要進行評審。 6）測試人員搭建環境，開發人員提交版本，測試人員進行測試，一般2-3個版本後BUG數量減少，達到出貨要求。 7）如果有客戶反饋問題，需要測試人員協助重現並重新測試。 為什麼做測試？最大的興趣？測試職業的發展目標？ 通過測試工作能使軟體產品越來越完善，從而體會到收穫效果的樂趣。 測試入門容易，但是做好很難，測試的精華在於測試用例的設計上，在測試一個新的任務時，需要花一定的時間去消化業務需求和技術基礎，業務需求通過溝通交流就可以達到目的，而技術基礎可能沒那麼簡單，這需要一定的自學能力和挑戰性。 測試經驗越多，測試能力越高，職業發展需要時間的積累，不斷更新和提升自己，向著高階測試工程師奔去。 自己做測試的優勢在哪裡？ 有耐心，喜歡總結，較強的溝通能力 如果有機會轉成開發人員，會做開發嗎？ 如果公司確實需要我可以從事開發，但相對來說我更喜歡測試，我認為我更適合做測試。 假設有一個文字框要求輸入6個字元的郵政編碼，對於該文字框應該怎樣劃分等價類？ 特殊字元；英文字元；小於十個字元；大於十個字元；數字和其他混合；空字元；保留字元。