1.手工測試
手動測試是一種軟件測試，其中測試用例是手工運行的，而不是使用自動化工具。所有測試用例都是由測試人員從最終用戶的角度手動執行的。它確定應用程序是否滿足需求文檔中指定的需求。為了完成幾乎100%的軟件應用程序，需要創建並實現測試用例。手工創建的測試用例報告也是可用的。
手動測試是最基本的測試方法之一，因為它可以檢測可見和隱藏的軟件缺陷。錯誤是預期輸出與軟件提供的輸出之間的差異。開發人員在將其交給測試人員重新測試之前糾正了缺陷。
在自動測試之前，任何新生成的軟件都必須進行手動測試。這種測試需要花費大量的時間和工作，但它可以確保產品沒有bug。手動測試需要熟悉手動測試程序，但不需要熟悉自動測試軟件。
軟件測試的基本原則之一是“100%自動化是不可能的”。這就需要手動測試。
為什麼我們需要手動測試
當一個應用程序發布到市場上，並且不穩定，有bug，或者在最終用戶使用它時給他們帶來了問題。
如果我們不想處理這些問題，我們應該進行一輪測試，以確保應用程序沒有bug且穩定，並為客戶提供高質量的產品，因為沒有bug的應用程序對最終用戶來說更方便。
當測試工程師執行手動測試時，他或她可能會從最終用戶的角度測試應用程序，並更好地理解產品，這有助於他們為應用程序構建必要的測試用例，並提供及時的反饋。
手動測試的類型
手動測試可以通過多種方式進行。每種方法都是根據其自己的測試需求集來應用的。下麵列出了幾種類型的手動測試:
- 白盒測試
- 黑盒測試
- 灰盒測試
注意:每種類型都在各自的模塊中詳細解釋。
2.自動化測試
現在，我們將學習自動化測試的以下主題:
- 自動化測試概論
- 為什麼我們需要執行自動化測試?
- 自動化測試中使用的不同方法
- 自動化測試過程
- 在自動化測試過程中麵臨哪些不同的挑戰?
- 自動化測試工具
- 自動化測試的好處和缺點。
概述
另一種類型的軟件測試是自動化測試，它使用專門的工具來運行測試腳本，而不需要人工幹預。它是提高軟件測試效率、生產力和測試覆蓋率的最可接受的方法。
在自動化測試工具的幫助下，我們可以快速地接近測試數據，處理測試實現，並將實際輸出與預測的結果進行比較。
測試自動化工程師將編寫測試腳本或利用自動化測試工具在自動化測試中執行應用程序。另一方麵，在手動測試中，測試工程師將開發測試用例，然後基於編寫的測試用例實現產品。
測試工程師可以通過測試自動化自動化重複操作和其他相關職責。在手動測試中一次又一次地執行重複的接管是一項令人厭煩的任務。
方法
- GUI測試
- 代碼驅動
- 測試自動化框架
自動化測試流程
自動化測試過程是一種組織和執行測試操作的方法，這種方法可以用最少的資源獲得最大的測試覆蓋率。測試由多步驟過程構成，該過程支持任務所需的、詳細的和相互關聯的任務
步驟1:決定自動化測試
自動化測試生命周期方法的初始階段。測試團隊在這一點上的主要重點是管理測試期望，並確定正確使用自動化測試的潛在好處。
在實現自動化測試套件時，組織必須應對一係列挑戰，其中一些挑戰概述如下:
- 對於自動化測試，測試工具的專業知識是必不可少的，因此第一個問題是聘請測試設備專業人員。
- 第二個挑戰是確定測試特定功能的最佳工具。
- 自動化測試中設計和開發標準的重要性。
- 評估幾個自動化測試工具，以便選擇最合適的工具進行自動化測試。
- 金錢和時間的問題出現了，因為在測試開始時兩者的使用都是相當大的
步驟2:測試工具選擇
自動化測試生命周期方法論的第二部分是測試工具選擇(ATLM)。這個階段指導測試人員如何評估和選擇測試工具。
盡管測試工具實際上滿足了所有的測試標準，測試人員仍然必須在編製工具評估參數列表之前研究係統工程環境和其他組織需求。測試工程師使用所提供的樣本標準對設備進行評估。
步驟3:範圍介紹
自動化測試生命周期方法論的第三個階段是這個(ATLM)。應用程序的測試區域包含在自動化的範圍中。在確定範圍時要考慮以下因素:
- 由所有軟件應用程序共享的軟件應用程序功能。
- 自動化測試建立了業務組件的可重用集合。
- 自動化測試確定業務組件可以重用的程度。
- 特定於業務的應用程序必須包含特定於業務的特性，並且在技術上是可行的。
- 在跨瀏覽器測試中，自動化測試允許測試用例的複製。
步驟4:測試計劃和開發
因為這裏指定了所有的測試策略，所以自動化測試生命周期方法(ATLM)的第四個也是最重要的步驟是測試設計和開發。這個階段確定了長期測試活動的計劃，標準和指導方針的創建，硬件、軟件和網絡所需組合的配置，以創建測試環境，缺陷跟蹤過程，以及控製測試配置和環境的指導方針。項目的預計工作量和費用由測試人員確定。該階段的可交付成果包括測試策略和工作量評估文檔。
步驟5:測試用例執行
自動化測試生命周期方法的第六個階段是執行(ATLM)。它發生在測試計劃過程成功完成之後。測試團隊在這個級別定義測試設計和開發。測試用例現在可以作為產品測試的一部分運行。在此階段，測試團隊使用自動化工具開始用例開發和執行。測試團隊的同行成員或質量保證領導審查準備好的測試用例。
測試團隊被指示在執行測試程序期間堅持執行時間表。執行階段實施測試計劃中指出的技術，例如集成、可接受性和單元測試。
第六步:審查和評估
自動化測試生命周期的第六個階段也是最後一個階段是評審和評估，但是這個階段的活動在整個生命周期中進行，以確保持續的質量改進。對矩陣的檢查、審查和對行動的評估都是改進過程的一部分。
在評價過程中，審查員關注的是具體措施是否滿足驗收要求;如果有，就可以在軟件生產中使用了。它是徹底的，因為應用程序的每個功能都包含在測試用例中。
測試團隊進行自己的調查，以確定流程的潛在價值;如果預期效益不足，可以改變檢測方法。該團隊還包括一個樣本調查表單，用於從最終用戶那裏獲取軟件功能和管理方麵的信息。
手動測試的類型:
1.白盒測試
軟件測試分為兩類:黑盒測試和白盒測試。這裏討論的是白盒測試，也稱為玻璃盒測試、結構測試、透明盒測試、開盒測試和透明盒測試。它檢查軟件的內部編碼和基礎結構，重點是將預定義輸入與預期和預期結果進行比較。它以內部結構測試為中心，基於程序的內部工作原理。這種測試形式的測試用例的設計需要編程專業知識。白盒測試的主要目的是集中於通過軟件的輸入和輸出流，同時確保其安全性。
由於係統的內部視角，使用了術語“白盒”。術語“透明盒子”、“白盒子”和“透明盒子”指的是通過軟件的外部外殼看到軟件內部工作的能力。
白盒測試由開發人員完成。開發人員將在此步驟中測試程序代碼的每一行。開發人員在將應用程序或軟件發送給測試團隊之前進行白盒測試，測試團隊進行黑盒測試，驗證應用程序是否符合需求，並在將應用程序發送回開發人員之前識別缺陷。
開發人員在將代碼發送給測試團隊之前修補錯誤並執行一輪白盒測試。在這種情況下修複錯誤意味著錯誤已經從應用程序中刪除，相關功能現在是可操作的。
由於以下原因，測試工程師不參與故障處理:
- 修複這個bug可能會導致其他功能停止工作。因此，測試工程師應該始終識別缺陷，而開發人員應該繼續解決它們。
- 如果測試工程師花費大部分時間來修複缺陷，他們可能無法找到應用程序的額外錯誤。
白盒測試的一般步驟
- 創建所有測試場景和測試用例，並為每個場景分配一個高優先級編號。
- 這個階段需要在運行時查看代碼，以查看正在使用哪些資源，代碼的哪些部分沒有被使用，某些過程和操作需要多長時間，等等。
- 在此步驟中測試內部子例程。內部子例程，如非公共方法和接口，可以正確或不正確地處理任何形式的數據。
- 該步驟主要檢查各種數據輸入的循環和條件語句等控製語句的效率和質量。
- 最後，白盒測試涉及到識別任何安全缺陷的安全測試。
白盒測試的原因
- 它可以檢測組織內部的安全漏洞。
- 檢查代碼中的輸入法。
- 檢查條件循環的功能。
- 分別測試每個函數、對象和語句。
2.黑盒測試
黑盒測試是一種軟件測試，它隻查看軟件的功能，而不查看其內部結構或編碼。客戶的需求陳述是黑盒測試最常見的來源。
在這種方法中，測試人員選擇一個函數並輸入一個值來驗證其功能，然後檢查該函數是否產生所需的輸出。如果函數返回預期結果，則通過測試;否則，失敗。在進行下一個功能之前，測試團隊將結果通知開發團隊。如果在所有功能都測試完畢後出現嚴重問題，則將其返回給開發團隊進行修改。
- 因為黑盒測試是基於需求規範的，所以它首先被檢查。
- 在第二階段，測試人員通過選擇合法和無效的輸入值來生成一個正的和負的測試場景，以查看軟件處理它們是正確的還是不正確的。
- 測試人員在第三階段創建大量的測試用例，例如決策表、所有對測試、等效劃分、錯誤估計、因果圖等等。
- 所有測試用例的執行都包含在第四步中。
- 測試人員在第五步中將預期的操作與實際的操作進行比較。
- 如果軟件中存在缺陷，則在最後階段對其進行再次測試。
測試用例
在創建測試用例時需要考慮需求。軟件的工作描述，包括需求、設計參數和其他規範，通常用於構建這些測試用例。為了確定正確的輸出，測試設計人員選擇一個具有合法輸入值的積極測試場景和一個具有錯誤輸入值的不利測試場景。測試用例主要是為功能測試而創建的，盡管它們也可以用於非功能測試。測試團隊負責創建測試用例;軟件開發團隊不參與。
黑盒測試的一般步驟
- 因為黑盒測試是基於需求規範的，所以它首先被檢查。
- 在第二階段，測試人員通過選擇合法和無效的輸入值來生成一個正的和負的測試場景，以查看軟件處理它們是正確的還是不正確的。
- 測試人員在第三階段創建大量的測試用例，例如決策表、所有對測試、等效劃分、錯誤估計、因果圖等等。
- 所有測試用例的執行都包含在第四步中。
- 測試人員在第五步中將預期的操作與實際的操作進行比較。
- 如果軟件中存在缺陷，則在最後階段對其進行再次測試。
測試用例
在創建測試用例時需要考慮需求。軟件的工作描述，包括需求、設計參數和其他規範，通常用於構建這些測試用例。為了確定正確的輸出，測試設計人員選擇一個具有合法輸入值的積極測試場景和一個具有錯誤輸入值的不利測試場景。測試用例主要是為功能測試而創建的，盡管它們也可以用於非功能測試。測試團隊負責創建測試用例;軟件開發團隊不參與。
3.灰盒測試
灰盒測試是一種軟件測試方法，它涉及到在隻部分了解軟件程序內部工作原理的情況下測試軟件程序。因為它涉及到訪問內部編碼來開發測試用例，就像白盒測試一樣，而測試技術是在功能級別上進行的，就像黑盒測試一樣，所以它是兩者的混合體。
GreyBox測試經常用於識別web係統中特定於上下文的問題。例如，如果測試人員在測試過程中檢測到錯誤，他會修改代碼以修複問題，然後實時重新測試。為了增加測試覆蓋率，它將重點放在任何複雜軟件係統的所有層上。它允許您測試顯示層和核心編碼結構。它主要用於集成和滲透測試。
執行灰盒測試的一般步驟是:
- 首先從黑盒和白盒測試輸入中識別並選擇輸入。
- 從你所選擇的輸入中確定預測結果。
- 最後，列出測試過程中所有重要的路徑。
- 為了進行深層測試，第四個目標是識別作為主要功能一部分的子功能。
- 第五項任務是識別子函數輸入。
- 確定子函數的預測輸出是第六項工作。
- 第七項工作需要運行Subfunctions測試用例。
- 第八項任務是確保結果是正確的。
用於Greybox測試的測試用例包括安全相關測試、瀏覽器相關測試、GUI相關測試、操作係統相關測試和數據庫相關測試。
