ISTQB 測試的 7 個關鍵原則 | #3 軟件測試的第一步
已發表: 2022-05-31執行精確和正確的軟件測試遵循許多原則。 國際軟件測試資格委員會區分了七個基本的，我們今天要討論的。 想知道嗎？ 閱讀有關關鍵 ISTQB 測試原則的文章！
ISTQB 測試原則 – 目錄：
- 測試揭示了缺陷，但不能證明它們不存在
- 徹底的測試是不可能的
- 早期測試可以節省時間和金錢
- 故障滾雪球效應
- 農藥悖論
- 這取決於上下文
- 廣告完美的軟件是不行的
- 概括
測試揭示了缺陷，但不能證明它們不存在
測試增加了發現錯誤的可能性，這反過來又增加了修復錯誤的機會。 但是，即使發現並修復了絕大多數缺陷，它也不能完全保證軟件沒有所有缺陷。 由於無法創建完美的軟件，許多人認為設計過程是消極的，因為你永遠不會得到積極的結果，而且總是會在程序中發現一些“污垢”。
徹底的測試是不可能的
上述經驗法則表明，檢測軟件的所有故障是徒勞的。 但是，這不適用於簡單的短節目。 反過來，這表明有機會看到輸入和前提條件的所有組合來完全測試某些程序。 在評估複雜的軟件時，即使是最好的 AI 也無法執行所有必要的測量，更不用說手動測試人員了。 自動化評估器將更高效、更準確地運行應用程序，但它們仍然不能保證完美的性能。 為此，您必須著手執行其他任務，例如確定優先級、風險分析以及查找和運行其他測試技術。
早期測試可以節省時間和金錢
許多專業人士也將這一原則稱為“左移”。 越早發現缺陷，就越容易修復它們，因此應盡快開始靜態和動態測試。 簡而言之：
- 靜態測試——在不運行代碼的情況下評估產品。
- 動態測試——在執行期間評估模塊或系統的代碼
在實施的第一階段檢測缺陷有助於進一步診斷。 但是，當軟件的兩個領域相互作用時，由於無法查明存在錯誤的領域，修正缺陷變得很麻煩。 在這種情況下，需要額外的時間、精力和人力來解決。 總而言之，是對鋪面障礙物的快速反應，可以防止裂縫繁殖
故障滾雪球效應
大多數故障往往集中在最關鍵的模塊中，因此它們的深入檢查揭示並充分消除了大多數故障。 這些組成為運行風險分析的主要焦點，以規劃和確定未來的行動行為。 大多數缺陷都是在遵循用戶所採用的路徑後浮出水面的，但在這些情況下，僅憑知識並不能使模塊無可挑剔。
帕累托原理說， 80% 的結果僅來自 20% 的原因。 換句話說，80% 的 bug 存在於 20% 的模塊中。 如果您在一個模塊中遇到許多故障，請繼續挖掘，因為它們會在那裡。
農藥悖論
重複運行相同的測試可能會失敗，因為它們可能一開始就設計不正確，並且永遠不會被證明是有效的。 您必須修改和升級測試以增加在軟件中發現新故障的機會。
創建一個全新的診斷系統也無濟於事。 遵循先前的組合可能會在同一級別停止評估過程。 這一原理被稱為“農藥悖論” ，因為控制害蟲的農藥在使用一定量後也會失去效力。
這取決於上下文
執行測試的方式取決於檢查的對象。 因此，測試會計程序、視頻遊戲或社交網絡應用程序有很大的不同。 這也取決於情況，例如，側重於應用程序實用性的分析，例如檢查其對用戶的吸引力、易用性、可視化層等，也不同於針對程序功能屬性的評估，例如性能正確的計算。
廣告完美的軟件是不行的
應用各種類型的診斷工具並不能保證準確的應用程序。 許多聲稱和宣傳他們的應用程序的人是錯誤的，但可能只是為了他們提出的營銷努力。 您可以執行多個手動和自動測試，以增加發現和修復盡可能多的錯誤的可能性，但仍然不能保證完美的性能。 在某些情況下，障礙與操作軟件有關，例如程序可能無法滿足所有用戶的期望。
ISTQB 測試原則 – 總結
這就是ISTQB在基本層面上如何提出軟件測試人員應該遵循的七個 ISTQB 測試原則。 首先，它們表明完整的軟件診斷不可行，因此修改測試以及對關鍵模塊進行徹底搜索至關重要。 這些行動增強了對大多數缺陷的搜索和清除，從而降低了未來發生故障的可能性。
什麼是軟件測試？ 現在你知道答案了！ 查看我們關於 Python 和 Javascript 的其他系列！
如果您喜歡我們的內容，請加入我們在 Facebook、Twitter、LinkedIn、Instagram、YouTube、Pinterest 上忙碌的蜜蜂社區。
作者：羅伯特·惠特尼
JavaScript 專家和指導 IT 部門的講師。 他的主要目標是通過教其他人如何在編碼時有效合作來提高團隊生產力。
軟件測試的第一步：
- 什麼是軟件測試？
- 1 關於軟件錯誤的大真相
- 七個關鍵的 ISTQB 測試原則
- STLC的6個階段
- 測試與調試
- 軟件測試過程中的驗證和確認