1、什麼是軟體測試，軟體測試的目的。

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

　　軟體測試的目的：

• 以最少的人力，物力和時間找出軟體中的各種錯誤和缺陷，保證各種錯誤和缺陷得以修復，避免軟體釋出後由於潛在的軟體錯誤和缺陷造成的隱患所帶來的的商業風險。

• 利用測試過程中得到的測試結果和測試資訊，作為後續專案開發和測試過程改進的重要輸入，避免在將來的專案開發和測試中重複同樣的錯誤。

• 採用更加高效的測試管理手段，提高軟體測試的效率和軟體產品的質量。

2、軟體的生存週期及模型。

　　需求分析---概要設計---詳細設計---編碼---測試---驗收

3、軟體測試流程。

　　需求分析---制定測試計劃---制定測試方案---編寫測試用例---評審測試用例---冒煙測試---執行測試---提交缺陷報告與跟蹤---迴歸bug---提交測試總結---準備下個版本測試

4、軟體測試模型。

　　V模型

• 解釋了開發過程與測試過程中各階段的對應關係

• 缺點與不足

  1. v模型僅僅把測試過程作為在需求分析、系統設計及編碼之後的一個階段，忽視了測試對需求分析、系統設計的驗證

  2. 需求的滿足情況一直到後期的驗收測試才被驗證

  3. 沒有體現出“儘早地和不斷地進行軟體測試”的原則

W模型

• 由兩個V字型模型組成，分別代表測試與開發過程，明確表示了測試與開發的並行關係。

• 優點：

  1. 測試的活動與軟體開發同步進行

  2. 測試物件不僅僅是程式，包括需求和設計

  3. 儘早發現軟體缺陷可降低軟體開發的成本

• 侷限性：

  1. 在W模型中，需求，設計，編碼等活動被視為序列的，這樣就無法支援靈活的迭代。

H模型

• H模型將測試活動完全獨立出來，形成了一個完全獨立的流程，將測試準備活動和測試執行活動清晰地體現出來。

• H模型揭示了一個原理：軟體測試是一個獨立的流程！

• H模型指出軟體測試要儘早準備，儘早執行；只要某個測試達到準備就緒點，測試執行活動就可以展開，並且不同的測試活動可按照某個次序先後進行，也可以反覆進行。

X模型

• X模型也是對V模型的改進，X模型提出針對單獨的程式片段進行相互分離的編碼，此後通過頻繁的交接，通過整合最終合成為可執行的程式。

• X模型還定位了探索性測試，這是不進行實現計劃的特殊型別的測試，這一方式往往能幫助有經驗的測試人員在測試計劃之外發現更多的軟體錯誤。

5、軟體測試的分類。

按照開發階段分類：單元測試、整合測試、系統測試、驗收測試。

　　單元測試：單元測試又稱模組測試，是針對軟體設計的最小單位--程式模組進行正確性檢驗的測試工作。其目的在於檢查每個程式單元能否正確實現詳細設計說明中的模組功能、效能、介面和設計約束等要求，發現個模組內部可能存在的各種錯誤。單元測試需要從程式的內部結構出發設計測試用例。多個模組可以平行地獨立進行單元測試。

　　整合測試：整合測試也叫做組裝測試。通常在單元測試的基礎上，將所有的程式模組進行有序的、遞增的測試。整合測試是<u>檢驗程式單元或部件介面關係</u>，逐步整合為符合概要設計要求的程式部件或整個系統，它是一個持續不斷的過程。

　　系統測試：系統測試是在真實的系統執行的環境下，檢查完整的程式系統（包括硬體、外設、網路的系統軟體、支援平臺等）正確配置、連線，並最終滿足使用者需求。

　　驗收測試：是軟體產品檢驗的最後一個環節。按照專案任務書或合同。供需雙方約定的驗收依據文件進行的對整個系統的測試與評審，決定是否接受或拒收系統。

按照測試技術分類：黑盒測試，白盒測試，灰盒測試

　　黑盒測試：通過軟體的外部表現來發現其缺陷和錯誤。黑盒測試法把測試物件看成一個黑盒子，完全不考慮程式內部結構和處理過程。黑盒測試是在程式介面處進行測試，他只是檢查程式是否按照需求規格說明書的規定正常實現

　　白盒測試：通過對程式內部結構的分析、檢測來尋找問題。白盒測試可以把程式看成裝在一個透明的盒子裡，檢查是否所有的結構及路徑都是正確的，檢查軟體內部動作是否按照設計說明的規定正常進行。白盒測試又稱為結構測試。

　　灰盒測試：介於白盒測試與黑盒測試之間的測試。灰盒測試關注輸出對於輸入的正確性；同時也關注內部表現，但這種關注不像白盒測試那樣詳細、完整，知識通過一些表徵性的現事件、標誌來判斷內部的執行狀態。

6、什麼是測試用例？

　　設計一個情況，軟體程式在這種情況下，必須能夠正常執行並且達到程式所設計的預期結果，如果程式在這種情況下不能正常執行，而且這種問題會重複發生，那就表示軟體程式人員已經測出軟體有缺陷，這時候就必須將這個問題標示出來，並且通知軟體開發人員。軟體開發人員接獲通知後，將這個問題修改完成與下一個版本測試，軟體測試工程師取得新的測試版本後，必須利用同一個用例來測試這個問題，確保該問題已經修改完成

7、你寫過測試計劃嗎？包含什麼內容？測試計劃可以被修改嗎？

　　測試範圍 ：明確測什麼？比如：產品的具體業務需求有哪些？產品是web端的還是移動端的，還是兩者都有？

　　測試策略 ：明確怎麼測？對不同業務需求，具體要有哪些測試型別、測試場景、測試方法。

　　資源安排 ：包括測試人員的安排，測試環境是怎樣的，測試⼯具的選擇等。

　　進度安排 ：在明確測試範圍、方法和人員之後，我們要考慮什麼時候開始測試，預計要測試多久？以便和開發計劃、上線計劃銜接。

　　釋出標準 ：釋出標準是測試完成和產品上線需要滿⾜的條件，以便項⽬內所有⻆⾊都有⼀致認可的目標。怎樣才算是測完了？達到怎樣的標準才可以上線？

　　風險預防 ：最後，我們需要對整個測試過程中可能存在的⻛險，以及當這些⻛險發⽣時的應對措施提前進行⼀些考慮 和準備，並在測試計劃中體現出來。

8、測試用例測要素。

　　測試用例編號、測試項、測試用例標題、優先順序、預置條件、測試輸入、操作步驟、預期結果

9、設計測試用例的作用。

　　有效性：測試用例是測試人員測試過程中的重要參考依據。

　　可複用性：良好的測試用例具有重複使用的功能，是的測試過程事半功倍，提高測試效率。

　　易組織性：即使是小的專案，也可能會有幾千甚至更多的測試用例，測試用例可能在數月甚至你念的測試過程中被建立和使用。

　　可評估性：從測試的專案管理角度來說，測試用例的通過是檢驗程式碼質量的保證。

　　可管理性：測試用例也可以作為檢驗測試人員進度、工作量以及跟蹤、管理測試人員的工作效率的標準。

10、測試用例編寫注意事項。

　　不要設計“窮舉測試用例”

　　在詳細測試用例與有效測試的時間找到平衡點（時間不夠儘可能全面，時間夠儘可能深入）

　　好的測試用例應該多關注“反向測試問題”

　　測試用例庫應該不斷更新和維護

　　測試用例可以複用，但要注意資料有效性與環境變化

　　測試用例式設計出來的，不是寫出來的

　　多去學習經驗豐富的測試工程師所設計的測試用例

　　針對不同的需求型別和測試物件，應該採用不同的測試用例設計方法

11、測試用例的設計方法有哪些？

　　黑盒測試：等價類、邊界值、因果圖、判定表、場景法、正交實驗法、功能圖法、錯誤推測法

　　白盒測試：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、多重條件覆蓋。