資料結構
網路
關係資料庫管理系統 (RDBMS)
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C語言程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
時尚研究
法律研究軟體測試的六大原則
本指南介紹了任何軟體測試人員和質量保證專業人員都應瞭解的七個基本的軟體測試原則。
軟體測試的六大原則
- 窮舉測試是不可能的
- 儘早測試
- 缺陷聚集
- 殺蟲劑悖論
- 測試依賴於上下文
- 沒有錯誤的謬誤
背景
進行軟體測試時，必須在不偏離目標的情況下獲得最佳測試結果。但我們如何知道自己是否使用了最佳的研究策略呢？為此，我們必須遵守某些基本的研究標準。
考慮以下情況：我們將檔案從資料夾 A 傳輸到資料夾 B。考慮我們可以測試此操作的多種方法。
除了標準示例外，您還可以設定以下條件進行測試：
- 嘗試傳輸正在開啟的檔案。
- 我們沒有將檔案貼上到資料夾 B 的必要安全許可權。
- 資料夾 B 位於共享磁碟上，並且其儲存空間已滿。
- 資料夾 B 也包含同名檔案，等等。
- 如果您有 15 個輸入欄位需要比較，每個欄位有 5 個可能的值，則需要測試的總變體數量為 5^15。
如果您測試了每種可能的組合，專案的處理時間和費用將激增。因此，我們需要一些概念和技術來增強研究，同時最佳化工作量。
以下是六大原則：
1. 窮舉測試是不可能的
是的！沒有必要進行窮舉測試。相反，我們需要根據應用程式的風險評估進行儘可能少的測試。
最重要的是，如何計算這種潛在的風險？讓我們做一個實驗來解決這個問題。
您認為哪項活動最有可能導致您的作業系統崩潰？
我希望你們都能猜對，那就是同時開啟十個單獨的應用程式。
因此，如果您正在測試此作業系統，您會注意到在多工活動中更容易檢測到錯誤，並且必須仔細測試這些錯誤，這使我們想到了下一個概念：缺陷聚集。
2. 缺陷聚集
根據缺陷聚集原則，發現的大多數缺陷都集中在少數幾個單元中。帕累託原則應用於軟體測試：大約 80% 的問題在 20% 的單元中被發現。
這些有問題的模組可以透過實踐來識別。但是，這種策略有一些缺點。
如果反覆進行相同的實驗，相同的測試用例最終將無法檢測到新的缺陷。
3. 殺蟲劑悖論
在農業中重複使用相同的殺蟲劑組合來殺死昆蟲，會導致昆蟲隨著時間的推移獲得殺蟲劑抗性，從而使殺蟲劑對昆蟲無效。軟體測試也是如此。如果執行相同的重複檢查序列，則該過程將無法有效檢測新的缺陷。
為了解決這個問題，必須定期測試和更新測試用例，並加入新的和不同的測試用例來發現新的缺陷。
測試人員不能僅僅依賴於當前的測試方法。他們必須不斷努力改進現有技術，以提高研究效率。然而，即使在研究中付出了所有努力，也不能說最終結果是完全無錯誤的。為了強調這一點，讓我們重點介紹災難性的 Windows 98 公開發布計劃。在釋出活動中，演示者向公眾演示作業系統時，作業系統崩潰了。您認為像微軟這樣的公司不會仔細檢查其作業系統，並且會為了讓其作業系統在公開發布期間失敗而危及其聲譽嗎？
4. 沒有錯誤的謬誤
測試哲學認為 - 測試討論的是缺陷的存在，而不是缺陷的缺乏。也就是說，軟體測試降低了軟體中存在未發現缺陷的可能性，但即使沒有發現缺陷，這也不能證明 100% 的準確性。
但是，如果您非常努力地工作，並小心謹慎地確保技術產品沒有錯誤呢？而程式未能滿足客戶的需求和期望。
這使我們想到了我們的下一個理論，它指出沒有錯誤是很重要的。
5. 儘早測試
應該在軟體開發生命週期的早期開始測試，以便儘早發現規範或設計階段的任何缺陷。在測試的早期階段修復缺陷的成本也更低。但是，從何時開始測試呢？建議您在指定規範後立即開始尋找錯誤。
6. 測試依賴於上下文
測試依賴於上下文，這意味著測試電子商務平臺可能與測試商業應用程式不同。所有構建的軟體都不相同。根據應用程式的形式，您可以使用特定的方法、方法論、方法和測試形式。例如，在零售店中測試 POS 裝置與測試 ATM 機不同。
誤區：“原則只是指導方針。它們實際上無法實現。”
這是完全錯誤的。測試原則將幫助您制定成功的測試策略並編寫能夠捕獲錯誤的測試用例。但是，掌握測試概念就像第一次學習駕駛一樣。
當您第一次開始學習駕駛時，您會密切注意所有事情，例如換擋、轉速、離合器操作等等。但是，隨著練習，您只需要專注於駕駛，其餘的都會自然而然地發生。以至於您還在與車裡的其他人交談。
測試原則也是如此。經驗豐富的測試人員已經將這些原則內化到他們毫不費力地採用它們的程度。
軟體測試中的 V 模型
**V 模型**是一個高度組織的 SDLC 模型，除了每個生產階段外，還包括一個測試階段。V 模型是瀑布模型的演變，其中研究是在每個階段與設計和開發同時進行的。它被稱為**驗證或確認模型。**
關鍵詞
- **SDLC：**SDLC 是軟體開發生命週期的縮寫。它是程式設計師為了設計和建立高質量應用程式而執行的一系列任務。
- **STLC：**STLC 是軟體測試生命週期的縮寫。它包含測試人員系統地執行的一套工作，以驗證軟體產品。
- **瀑布模型：**瀑布模型是一個順序模型，它將軟體開發操作劃分為不同的階段。每個階段都旨在用於特定操作。在瀑布模型中，測試過程僅在滿足系統的規範後才開始。
理解 V 模型的示例
假設您已承擔為客戶開發定製應用程式的任務。無論您的技術經驗如何，您都會採取以下一系列步驟來完成任務。
| 軟體開發生命週期的不同階段 | 執行的活動 |
|---|---|
| 收集階段 | 儘可能多地從客戶那裡收集有關所需程式的詳細資訊和配置的輸入。這僅僅是規範收集點。 |
| 設計階段 | 規劃程式語言（例如 Java、PHP、.NET）和資料庫（例如 Oracle、MySQL 等），這些語言和資料庫適合該專案，以及某些高階功能和架構。 |
| 構建階段 | 在概念階段之後是構建階段，這只不過是簡單地編寫軟體程式碼。 |
| 測試階段 | 之後，您驗證應用程式以確保它符合客戶的要求。 |
| 部署階段 | 在適當的環境中安裝程式。 |
| 維護階段 | 程式執行後，您可能需要根據客戶的輸入修改程式碼。 |
這就是所謂的軟體開發生命週期的瀑布方法。
瀑布模型的問題
如您所見，**該模型中的測試僅在安裝完成後才開始。**
但是，如果您正在處理一個具有動態結構的大型專案，則有可能在收集過程中忽略重要資訊。在這兩種情況下，客戶都可能獲得完全錯誤的產品，您可能必須重新開始任務。相反，如果您正確地說明了規範但在測試設計中犯了重大錯誤，您可能必須重新開始工作。為了修復應用程式建立和設計中的缺陷，您將不得不重建整個軟體。
數千個專案評估表明，**在規範和構建過程中引入的缺陷佔總錯誤數量的一半以上。**
此外，**修復缺陷的成本在開發生命週期中會增加。在生命週期中越早發現缺陷，修復它的成本就越低。**俗話說，“及時一針，省去九針”。
解決方案——V 模型
為了解決這個問題，引入了**V 模型**測試，其中**開發生命週期的每個步驟都對應一個測試階段。**
這張圖是為了向您展示為什麼它被稱為“V 模型”。
- 模型的左側顯示“軟體開發生命週期”——**SDLC**
- 模型的右側顯示“軟體測試生命週期”——**STLC**
- 整個結構/流程圖看起來像一個 V，因此得名**“V 模型”**。
除了V模型之外，還存在迭代開發模型。在這種模型中，開發工作分階段進行，每一步都會為程式新增新的功能。每個過程都包含其自身的一系列實現和測試練習。
快速應用開發（RAD）和敏捷開發是迭代開發生命週期的兩個很好的例子。
結論
軟體開發生命週期有多種模型。為專案選擇的開發模型取決於專案的具體目標和優先順序。
- 測試不是一項獨立的動作；它必須根據專案的增長方式進行調整。
- 在任何模型中，測試都可以在所有階段進行，從需求收集階段到維護階段。
瀏覽量：1K+
