在本手動測試教程中，我們將從測試原則開始。

為了測試應用程序，我們需要遵循一些原則來避免產品缺陷，這甚至可以幫助測試工程師花費他們的精力和時間來測試軟件。

讓我們逐一看看這7個不同的測試原則:

1.測試顯示了缺陷的存在

測試工程師將運行程序，以確保它沒有錯誤和故障。在測試過程中，我們隻能確定應用程序或軟件是否有任何缺陷。因為整個測試應該可以追溯到客戶的需求，這意味著要發現任何可能導致產品不能滿足客戶需求的缺陷，測試的主要目標是使用各種方法和測試方法確定未知錯誤的數量。

我們可以通過測試來減少任何程序中的缺陷，但這並不意味著應用程序是沒有缺陷的;事實上，當在上麵運行許多類型的測試時，軟件可能看起來是沒有錯誤的。但是，如果最終用戶發現了在測試過程中沒有發現的缺陷，那麼應用程序將被部署到生產服務器。

2.窮盡測試是不可能的

在實際測試過程中，似乎很難用有效和無效的輸入數據組合來測試所有模塊及其特性。

結果，不是進行全麵的測試，這就需要得出無數的結論，大部分的努力都是徒勞的。因為產品時間表不允許我們做這樣的測試場景，我們可以根據模塊的相關性完成這些類型的變體。

3.早期測試

這裏的早期測試意味著所有的測試活動都應該在軟件開發生命周期的早期階段開始需求分析階段為了識別缺陷，因為如果我們在早期階段發現了錯誤，它將在初始階段本身得到修複，這可能會比在測試過程的未來階段識別出的錯誤花費更少。

為了執行測試，我們將需要需求規範文檔;因此，如果需求定義不正確，那麼它可以直接被修正，而不是在另一個階段(可能是開發階段)修正它們。

4.缺陷聚類

缺陷聚類意味著我們可以在測試過程中檢測到與有限數量的模塊相關聯的問題的數量。對此我們有很多原因，包括模塊可能很複雜，編碼組件可能很困難等等。

這些形式的軟件或應用程序將遵循帕累托原則，該原則聲稱我們可以估計使用它的人數。80%的並發症可以在20%的模塊中找到。我們可以使用這種方法找到不確定的模塊，但是如果定期運行相同的測試，它就有缺點，因為相同的測試將無法檢測到新的錯誤。

5.殺蟲劑悖論

該原則指出，如果我們在一段時間內重複相同的測試用例集，我們將無法識別程序或應用程序中的新缺陷。為了克服這些農藥矛盾，定期評估所有測試用例是至關重要的。此外，必須為應用程序或程序的幾個組件的實現設計新的和不同的測試，這有助於發現進一步的缺陷。

6.測試依賴於上下文

測試是一個依賴於上下文的原則，這意味著我們在市場上有許多可用的領域，比如電子商務網站、商業網站等等。因為每個應用程序都有自己的需求、特性和功能，所以有一種清晰的技術可以同時測試商業和電子商務網站。我們將使用許多類型的測試、不同的技術、方法和許多方法來檢查這種類型的應用程序。因此，測試依賴於應用程序的上下文。

7.錯誤缺失謬誤

我們可以說，一旦應用程序經過了徹底的測試，並且在發布之前沒有發現任何問題，那麼它就沒有99%的錯誤。然而，在不準確的規範中測試程序，識別缺陷，並在設定的時間框架內修複它們是沒有幫助的，因為測試是在不正確的規範上完成的，這與客戶的需求無關。錯誤謬誤的缺乏表明，如果應用程序是不切實際的，不能滿足客戶的需求，那麼檢測和糾正缺陷將是無效的。