突變測試或程式突變是一種白盒測試技術，可説明公司開發一系列新的軟體檢查，同時審核專案的當前流程。 這是一種相對較新的方法，可確保開發人員和測試人員都以高標準工作。
應用程式的成功或好壞取決於其自身的質量保證程式 – 這意味著組織必須採用多種類型的測試技術。
瞭解突變測試可以幫助測試團隊提高他們的技能和一般技能 – 使他們能夠提高這些檢查的可靠性。 突變測試是一個複雜而敏感的過程，因此測試人員必須徹底研究可以保證成功實施的好處、挑戰和第三方計劃。
在本文中，我們將介紹突變測試及其如何提高質量保證，以及軟體測試團隊的其他關鍵考慮因素。
什麼是軟體測試中的突變測試？
在軟體環境中，突變測試是指品質保證團隊故意在應用程式代碼中引入錯誤或「突變」，以查看團隊如何回應。 目標是創建一個錯誤，並確保 測試套件 能夠識別對應用程式的每次更改。
編輯程式代碼時，突變測試人員可能會切換真/假錶示式、刪除語句或簡單地更改值。 在其他軟體檢查期間，這些錯誤可能以多種方式表現出來;所有這些都很容易被熟練且經驗豐富的測試團隊檢測到。
突變本身通常非常小，允許突變代碼的測試人員觀察團隊如何發現這些變化。 即使粗略一眼，重大變化也是顯而易見的 – 因此小錯誤通常是確保公司採用強大測試實踐的最佳方式。
此技術專門研究團隊測試用例的有效性;包含測試資訊的文件。 該團隊還可以使用第三方 自動化軟體 來運行這些檢查，在這種情況下，突變測試著眼於該平臺如何檢測程序代碼中的錯誤。
1. 什麼時候需要做突變測試？
由於突變測試的目的是驗證和改進當前的 品質保證檢查，因此團隊必須在測試階段的早期進行此操作。 這意味著如果測試套件無法識別和「殺死」突變體，則有足夠的時間對組織的測試程序進行任何規模的徹底更改。
由於這是一種高度通用的方法，突變測試幾乎適用於任何類型的軟體，包括 Web， 移動和 桌面 程式。 這在 單元測試 階段（檢查應用程式的最小組件）效果最好。
2. 當您不需要進行突變測試時
在某些情況下，突變和一般白盒測試不適合程式;這可能是由於各種原因造成的。
例如，如果測試人員只打算檢查黑盒測試，在這種情況下，他們將專注於該會話的前端甚至整個測試階段。
有些公司認為白盒測試既乏味又耗時，這可能會導致他們跳過該過程。 強大、經過良好檢查的測試用例也可以避免對突變測試的需求，因為這顯示了團隊對準確測試程式的勤奮和承諾。
3. 誰參與突變分析？
突變分析涉及許多不同的角色，包括：
• 突變測試儀
他們通過引入各種小缺陷來改變代碼，以確保測試過程按預期工作。 這些測試人員通常是品質保證團隊的預先存在的成員。
• 應用測試人員
他們定期檢查代碼是否存在任何問題，識別並糾正他們發現的任何突變。 他們進行白盒測試以查找編碼錯誤 – 但也使用其他技術。
• 應用程式開發人員
他們設計程式的功能並編寫初始代碼。 它們還修復了測試人員發現的任何問題，確保軟體處於穩定的發佈狀態。
• 項目經理
他們為應用提供方向，並可能與突變測試人員一起工作，以查看自己團隊的功效。 他們確保在每個開發階段都達到嚴格的標準。
我們用突變測試測試什麼？
突變測試更側重於測試過程而不是應用程式。 為此，它審查了以下內容：
1. 測試用例
測試案例是包含每個測試的詳細資訊的文件，包括測試人員期望從每個單獨檢查中獲得的結果。 一致且準確的測試用例使 QA 團隊成員瞭解應用程式的運行狀況以及其性能如何滿足公司的期望。
這些測試用例中的資訊可以確定測試人員發現某些缺陷的能力，包括突變測試引起的缺陷。
2. 測試標準
突變測試會仔細檢查當前的測試程式，以確保團隊成員能夠識別可能影響使用者對軟體感知的小問題。
測試人員的勤奮和能力甚至可能是企業通過這些檢查評估的主要因素。 如果在每個階段都非常注重細節，測試人員可能會錯過程式中存在的嚴重突變。
3. 單個代碼單元
突變測試在開發的單元測試部分很常見。 這會查看單個元件，以保持對每個測試的強烈關注，通過確保測試人員僅使用相關的代碼行來顯著優化整個過程。
由於突變測試通常處於品質保證階段的早期階段，並且可能是全面測試的前兆，因此這種方法可以在不影響準確性的情況下提高速度。
4. 程式更新
軟體更新通常涉及重新啟動測試過程，以確保沒有新的故障，並且以前的錯誤不會再次出現。
重複突變測試是其中的關鍵部分，有助於在重大軟體更改后促進一致的測試標準。
測試團隊可能認為沒有必要進行徹底的更新后檢查，但代碼更改可以確保他們了解在開發的每個階段進行測試的重要性。
5. 自動化軟體
公司還進行突變測試，以檢查其自動化測試套件，並確保他們能夠注意到突變的代碼等問題。
如果第三方測試應用程式可以識別程式的外部更改，甚至可能修復它，這意味著組織可以信任該軟體來自動執行測試。
公司必須驗證其自動化方法;這讓每個測試人員都高枕無憂。
6. 自動化策略
公司如何將 自動化集成到 其流程中與他們使用的軟體一樣重要;例如，它可能決定實施 超自動化。 這使公司能夠智慧地決定要自動化的突變和軟體測試。
如果沒有強大的自動化策略來適應應用程式代碼中存在的絕對多樣性，某些測試可能與自動化不相容，這限制了平臺的能力。
7. 申請
雖然突變測試更側重於測試團隊而不是應用程式，但它可能仍然突出顯示有關此程式的重要資訊。
例如，突變測試顯示了軟體如何回應其代碼中的更改，包括它是否以團隊期望的方式指示這些問題。
這種方法不是一種 軟體測試 技術，但仍然能夠提供有關其內部操作的有趣數據。
突變測試的生命週期
突變測試的通常生命週期如下：
1. 需求分析
任何突變測試生命週期的第一步都是準確確定需要驗證的內容，以及應用程式的哪些代碼片段將從這些測試中受益最大。
團隊可能會與開發人員和高管交談，以確定他們的顧慮並開始解決這些問題。
2. 測試計劃
然後，測試人員開始開發他們打算實施的確切檢查 – 在這種情況下，突變將提供最佳洞察力。
此階段確定整體突變測試策略以及團隊將如何有效地實現其預期的代碼突變。
3. 測試用例開發
突變測試涉及其自己的單獨測試文檔，包括有關突變代碼的資訊以及他們期望測試人員如何解決問題。
良好的記錄保存可確保測試按計劃進行，並可以幫助團隊保持對高測試標準的承諾。
4. 測試環境設置
測試人員確保應用程式已準備好供他們更改 – 並且如果其他團隊成員無法檢測到這些問題，他們有一個程式來解決這些問題。
作為其中的一部分，突變測試人員建立一個測試伺服器，並將其用作其突變的畫布。
5. 測試執行
完成準備工作后，測試人員在應用程式的多個元件之間更改代碼;然後，他們等待其他測試人員注意到並解決問題。
突變測試人員和應用程式測試人員都必須廣泛記錄這一點，以確保他們的記錄是可靠的。
6. 測試周期結束
測試完成後，突變測試人員會仔細檢查他們所做的所有更改是否由應用測試人員或他們自己修復。
然後，他們結束測試週期並分析結果，討論測試人員如何應對各種錯誤以及糾正錯誤的能力。
7. 重複考試
關閉測試週期后，可能需要在將來的軟體更新後重新啟動它。
對應用程式的每次更改都會以某種方式改變其功能，從而產生團隊必須考慮的新可能性，以確保他們的測試過程足夠細緻。
突變測試的好處
進行突變測試有很多好處，包括：
1. 驗證測試過程
突變測試的主要好處是它能夠顯示公司的測試人員如何處理軟體 – 以及他們識別編碼問題的能力。 這也確保了團隊的測試用例足夠全面，並涵蓋了所有必要的測試。
突變測試檢查 組織的整體測試過程 ，以確保其按預期工作。
2. 確保強大的自動化
突變測試可幫助團隊檢查其第三方測試自動化平臺是否能夠充分識別代碼中的錯誤並以正確的方式解決它們。
如果該軟體即使在必要的校準后仍無法檢測到這些，則可能值得將平臺更換為可以輕鬆通過這些測試的平臺。
3. 良好的覆蓋率
每個軟體測試過程都必須能夠廣泛涵蓋整個應用程式，以確保每個方面都得到必要的關注。
突變測試人員可以更改程式碼的任何部分;良好的實現允許這些測試包含每個主要功能。 這教會測試人員在整個應用程式中搜索問題。
4. 檢查原始程式碼
由於突變測試涉及使用代碼並在適當的情況下進行直接更改，因此此方法還可以強調應用程式中存在的未優化腳本。
軟體測試人員只有在軟體代碼足夠的情況下才能授權程式並進行正常輪次的測試;這些檢查允許測試人員突出顯示潛在的未來問題。
5. 帶來更好的軟體
突變測試有助於確保應用程式的測試過程符合程式的要求。
如果突變分析顯示品質保證團隊沒有遵循正確的程式或測試用例不足，測試人員可以努力改進這一點。 如果沒有這種盡職調查，組織可能會在不知不覺中發佈有缺陷的產品。
6.對不同語言有效
無論測試團隊在其應用中使用哪種語言，都有可用的軟體選項可以提供高品質的突變分析。
這包括許多特定於該語言的生活品質功能，簡化了檢查以提高可靠性。 針對不同語言的定製方法可以提高每個單獨測試的品質。
7. 高度可訪問的工具
許多頂級突變平臺都是完全開源的——這意味著它們免費或以更低的成本提供更多的定製和全面的功能。
與許多其他形式的測試相比，代碼突變的障礙更少，是企業評估甚至改進其質量保證方法的有用且方便的方法。
突變檢測的挑戰
這個過程也帶來了許多挑戰，例如：
1. 需要程式設計知識
對於要執行這些檢查的測試人員，他們必須對程序和代碼有全面的瞭解，這使得經驗不足的測試人員很難做出貢獻。
企業只能以適合測試人員現有技能的方式測試軟體;具體來說，他們能夠編輯應用程式並創建可修復的編碼錯誤。
2. 不適合黑盒測試
黑盒測試主要涉及查看應用程式的前端而不檢查其內部工作原理和代碼——這實際上與突變測試不相容。
因此，與其他方法相比，這些檢查僅對某些測試有用;其中許多可以提供整個測試階段的更大覆蓋範圍。
3. 設計突變測試非常耗時
代碼突變可能是一個繁瑣的過程，因為團隊需要找到值得更改的單個元件。 決定實施哪些突變本身可能需要很多時間;當其他測試類型有效地等待這些檢查以完全驗證公司的測試方法時，這可能會有問題。
4. 可能需要許多代碼突變
同樣，複雜的專案自然需要更多的突變體，以確保全面的測試方法。 這會增加突變階段的時間，並且可能涉及對應用代碼進行許多手動更改。
如果沒有具有程式突變功能的高品質測試自動化軟體，測試人員可能很難成功實施。
5. 測試人員可能不會注意到錯誤
突變測試人員和專案經理在實施這些檢查時經常擔心的最大問題是軟體測試人員（手動或自動）可能根本沒有注意到這些問題。
這可能需要對公司的測試程序進行全面改革 – 儘管這可能仍然為測試人員提供有關其品質保證標準的重要資訊。
6. 可能是記憶體密集型的
突變測試通常需要大量的處理能力，儘管這可能取決於測試人員使用的應用程式。
如果組織的機器數量有限，或者這些設備的規格較低，則它們可能難以同時運行太多突變。 這會影響他們在測試階段結束之前可以執行的檢查次數。
7. 報告可能資訊密集
雖然這主要取決於團隊突變測試工具的介面，但他們生成的報告可能難以解析。
這意味著手動對它們進行分類並找到正確的測試結果需要時間;一些程式允許使用者自定義實際的報告過程;這因應用程式而異。
突變測試的特徵
有效突變測試的主要特徵是：
1. 全面
這些檢查涵蓋了軟體的每個主要方面;擁有足夠資源的公司甚至可以為每個常規測試用例設計一個突變測試。
雖然確切的數位取決於組織的能力和偏好，但有效的突變測試涵蓋了廣泛的編碼特徵。
2. 戰略
程式突變同樣應遵循清晰且計劃周密的結構，以促進組織的整體測試目標。
例如，它們產生的錯誤可能接近實際的測試失敗，這使得測試人員能夠預測這些問題（如果它們自然發生），從而顯著改善公司的測試過程。
3. 建設性
突變測試的目的是識別測試中的不足之處——展示團隊如何改進檢查並在出現小錯誤時修復它們。
突變測試人員必須優先考慮影響軟體功能的“無效”突變體，從而在整個專案中進行更清晰的測試改進。
4. 先發制人
這些檢查的存在是為了驗證團隊的整體策略;這意味著突變測試在開發的早期階段效果更好。
如果測試人員發現他們的質量保證方法有任何重大缺陷，這給了他們必要的時間來更改他們的測試用例，以確保它們是足夠的。
5. 一致
跨應用程式不同反覆運算的突變測試應返回一致的結果，同時還添加更多檢查以適應軟體更改。
後續檢查必須包括對細節的同樣關注，以保持其有效性 – 如果沒有這種精度，突變測試可能會變得不那麼準確。
6. 微妙
突變測試旨在檢查品質保證團隊通過其測試和第三方平臺識別代碼缺陷的能力。
這意味著測試不應該對每個檢查軟體的人都一目了然;目的是檢查測試人員如何回應次要代碼問題。
7. 協作
與任何軟體測試一樣，代碼突變是一個通常需要團隊合作和溝通以確保其成功的過程。 保持協作氛圍有助於避免可能導致溝通不暢的資訊孤島——這也保證了每個測試人員都專注於手頭的任務。
突變測試的類型
突變測試的三種主要類型是：
1. 價值突變
值突變直接更改代碼中的值，以影響應用程式功能的方式將一個數位或字母更改為另一個數位或字母。
例如，測試人員可以更改程式的確切參數，例如它響應的數位。 突變測試儀可能專門針對軟體的常量值，因為這些值在正常操作期間始終保持不變。
2. 決策突變
決策突變修改算術和邏輯運算元，有效地改變應用程式對特定情況的回應方式。
例如，將大於運算符 （） 與小於運算子 （><） 切換自然會影響程序的輸出。 測試人員還可以將“or”換成“and”，反之亦然，從根本上改變該軟體以及它如何解釋其他測試人員和可能使用者提供的資訊。
3. 語句突變
語句突變會更改代碼的實際語句，從而修改應用程式用於做出決策的規則。 測試人員可以更改這些行的內容，複製它們，甚至刪除它們，以檢查突變程式如何影響軟體的功能。
這些突變會改變程式的構建塊，可能會刪除整個功能或以其他方式阻止它們工作。
消除一些困惑
– 突變測試與回歸測試
突變 和回歸 測試都是軟體測試的有用方法 – 了解這些技術中的每一種都可以提高公司的整體質量保證。
1. 什麼是回歸測試？
回歸測試是指測試人員在不同的反覆運算之間檢查軟體，以確保儘管代碼發生了變化，它仍然能正常工作。
即使是微小的更改也可能導致嚴重的問題，而無需進行這些檢查，這可能會導致以前的錯誤再次出現。 由於重新測試每個元件的複雜性，這通常需要自動化;許多公司因此放棄了回歸測試。
測試人員可以對單個單元、單個元件或整個產品進行這些檢查——所需的確切測試主要取決於專案及其規模。
2. 突變測試和回歸測試有什麼區別？
回歸測試主要側重於檢查程式 及其功能，而代碼突變則著眼於測試人員如何響應問題。
前者也主要發生在程式的多次反覆運算之後，而突變檢查可以在開發的任何階段進行 – 儘管通常在測試階段的早期階段。
回歸和突變測試都可以處理單個編碼單元，以及微小的變化如何導致測試人員必須努力糾正的重大問題。
3. 結論：突變測試與自動化測試
由於檢查和 單元 的廣度，自動化通常是突變測試的關鍵部分 – 這使得它有時對於成功和全面的測試過程至關重要。
公司通常使用代碼突變來檢查其第三方自動化平臺以及它識別有問題的腳本的能力。
將全面的突變檢查目錄與自動化軟體相結合可以顯著增加公司的覆蓋範圍並確保更強大的結果。
雖然這是兩種獨立的測試實踐，但它們不需要相互對立。 例如，集成 機器人過程自動化可以促進公司的突變測試策略。
在軟體工程中開始突變測試需要什麼？
全面突變檢測的通常要求包括：
1. 明確的測試策略
測試團隊必須建立突變測試策略，包括哪些元件和單元是最重要的檢查。
例如，代碼的某些方面對於應用程式的成功和功能可能更不可或缺;測試人員應確保有足夠的突變來適應這種情況。
該公司的突變測試時程表也是一個重要的考慮因素，因為這可確保測試人員有足夠的時間來研究代碼。
2. 無範圍蠕變
即使制定了全面的策略來闡明公司的突變測試方法，測試的數量也可能明顯高於必要的數量。
在整個過程中，效率至關重要，特別是當其他測試階段可能正在等待團隊找到並殺死突變時。 測試人員在開始改變代碼之前必須明確定義其範圍;這確保了一切都可以在實際的時間範圍內進行管理。
3. 嚴格的文件
每個測試過程都受益於完整的文檔 – 通常以測試用例的形式詳細說明單個檢查和任何相關的突變體。
這說明了團隊在測試中的當前進度，這對經理和高管特別有用。 記錄每個代碼突變還有助於測試人員保持有關他們所做的更改的清晰記錄。
如果質量保證團隊在測試時難以找到這些突變，這些文件實際上可以作為答案。
4. 熟練的測試人員
改變代碼的測試人員必須對軟體有深刻的理解——包括他們可以改變甚至破壞它的多種方式。
突變測試人員大致知道他們的更改將如何影響應用程式，以及其他品質保證團隊成員如何識別突變代碼。
這通常需要良好的程式設計知識水準。 為了使突變分析有效，軟體的測試人員還應具有完善的技能和測試經驗。
5. 自動化軟體
在突變測試之前，第三方自動化軟體可能是必需的，因為此過程通常需要進行大量檢查。 對於具有更多代碼和功能供質量保證團隊檢查的複雜應用程式尤其如此。
公司可以專門制定這些檢查來測試自動化軟體如何響應編碼錯誤。 這可以是公司試驗過程的核心部分，以確定哪些程式最有用。
突變測試過程
測試人員在進行突變分析時通常遵循的步驟是：
1. 準備測試
準備是任何測試過程的第一步。 這包括協商實施的確切檢查並獲得任何必要的批准——例如公司高管和利益相關者的批准。
測試人員必須以一種適應項目時程表的方式開發這些檢查，同時仍然涵蓋每個主要元件。 團隊的計劃可以確定其代碼突變的有效性。
2. 引入突變體和故障
準備工作完成後，測試團隊開始更改代碼，根據他們的計劃對其進行更改以引入特定故障。 這些錯誤應該相對較小，因為這允許測試人員衡量團隊識別編碼問題的其他能力。
小故障還可以幫助組織檢查其第三方自動化軟體的敏感性。
3. 應用測試用例
測試用例必須考慮應用程式中每個可能的故障點——如果突變程式能夠正常運行而沒有任何錯誤，則可能需要重寫。
程序的測試用例代表了測試人員執行的全部檢查範圍;每一個都應該幫助測試人員發現任何隱藏的突變，並成為應用程式可用性不可或缺的一部分。
4. 比較結果
在向程式添加突變錯誤並應用團隊的測試用例后，團隊必須比較原始程式和突變程序的結果。
希望原版中每成功檢查一次，突變體申請中也會出現錯誤。 這展示了測試人員和他們使用的工具的能力。
5. 根據不同的輸出採取行動
如果原始程式和突變程式之間存在測試人員期望的不同輸出，這意味著測試用例可以通過證明其存在來成功殺死突變體。
然後，測試人員可以對他們的方法和識別編碼問題的能力充滿信心。 對於這些特定測試，無需更改測試用例。
6. 必要時更改案例
某些代碼突變可能會導致不同程式得出相同的結論，這表明測試用例無法成功突出顯示應用程式中的每個可能錯誤。
在這些情況下，突變體保持「活著」 ，並可能繼續以測試人員沒有框架解決的方式影響軟體 – 這導致創建更好的測試用例。
如何創建突變程式
突變程式實際上與原始程式相同，除了一個微小的更改可能會以微小但明顯的方式影響應用程式的功能。
全面而詳細的測試用例可幫助測試人員或軟體套件查明這些更改及其產生的故障。 公司正在檢查的每個案例都需要一個原始程式和變異程式，孤立地顯示每個變化的影響。
這些程式通常會複製實際錯誤，例如編碼拼寫錯誤。 對於測試人員來說，避免阻止應用程式執行的“死產”突變體也很重要——這對測試人員來說太明顯了。
在突變程式中要更改什麼？
與許多軟體測試變數一樣，測試人員所做的確切更改取決於應用程式及其代碼。
包含大多數突變測試的類別有三類：操作數、表達式和語句。 改變其中任何一個都可以創建一個有效的突變程式——顯示不同的值或規則如何影響程式使用的邏輯。
這些類別與測試人員調查的三種主要類型的突變有關;這些分別是決策、值和語句突變。 更改應該是次要的，並且不得完全阻止測試的執行。
突變檢測的最佳實踐
在軟體測試環境中進行突變測試時，有一些做法值得遵循，以確保獲得強大的結果，例如：
1. 最大化突變評分
程式的突變數是團隊或應用程式可以成功識別或「殺死」的突變體的百分比。
例如，如果一輪突變測試有 40 個突變體，而測試人員發現 36 個突變體，則突變數為 90%——團隊的目標始終是確保得分為 100%。
2. 隨機選擇突變體
雖然它可以幫助確定某些元件的優先順序並更徹底地測試它們，但對於測試人員來說，隨機選擇要添加的突變體也很有用——尤其是在緊迫的截止日期下。
只要這些檢查代表了每種重要的突變類型，品質保證團隊就可以驗證其整體軟體測試策略。
3. 保持較小的變化
代碼突變應表示與原始程式的微小偏差，因為這說明了測試人員識別某些錯誤的可能性;小的編碼問題也表明他們的軟體有多敏感。
至關重要的是，突變測試人員要找到一種平衡，使這些微小的變化仍然產生明顯的錯誤。
4. 每個程式一個突變
突變測試孤立地查看單個測試用例，以檢查它們的全面程度。 為了幫助解決這個問題，每個突變的程式應該只對原始程序進行一次更改。
具有多個突變的程式可能無法與測試用例有效配對;突變可能相互衝突。
5. 仔細考慮自動化軟體
公司經常使用代碼突變來驗證團隊對自動化軟體的使用，並確保它能夠像人類測試人員一樣有效地識別錯誤。
這意味著選擇合適的自動化平臺可能是一個重要的考慮因素，以及集成 機器人過程自動化的可能性。
6. 使用測試驅動開發
測試驅動開發 （TDD） 是指在開發的每個階段都考慮測試要求的特定技術。
這有助於確保測試用例與軟體完全相容 – 使其能夠輕鬆通過突變測試，並製作與質量保證流程同步的更好程式。
突變測試的輸出類型
突變測試會生成多個輸出，包括：
1. 突變體程式
突變程式是這些檢查的自然輸出;測試人員創建這些測試以反映他們當前的測試用例以及他們幫助檢測的問題。 這些程式通常只以一種微小但重要的方式偏離其原始對應程式，以確保更高的可靠性。
2.活或死的突變體
測試后，突變要麼被「殺死」，要麼保持「存活」——這僅指測試人員（或他們的軟體）是否成功識別編碼問題。
如果突變體保持活力，測試用例可能需要進行重大更改。
3. 突變測試用例
質量保證團隊使用單獨的特定於突變的測試用例來記錄有關其突變程序的資訊。
這有助於確保團隊對每次檢查都有全面的記錄;這些檔包括有關突變及其對程序的影響的詳細資訊。
4. 突變評分
任何突變測試的最終目標是達到100%的突變數，公司的測試程式成功地定位並殺死每個突變體。 任何低於此值的內容都表明他們的測試用例和一般流程需要改進以識別有問題的代碼。
突變測試範例
以下是突變測試的三個範例：
1. 價值突變示例
值突變涉及更改常量或參數，這可能會改變程式的限制。 例如，自動結帳機的軟體可能會使用食品的重量來確定其價格。
測試人員可能會改變該程式背後的代碼以更改重量參數，從而使每盎司或每磅的食物更加昂貴。 測試人員或測試平臺應該能夠識別不同值對此程序的影響。
由於此錯誤改變了軟體的主要功能之一，因此測試用例應注意到此錯誤並提醒團隊。
2. 決策突變示例
決策突變涉及更改算術或邏輯運算符，反轉或以其他方式更改此應用程式回應使用者輸入的方式。 回到自助結帳的例子，這些機器可以標記一個重量出乎意料的高專案，可能是由於用戶錯誤。
機器的代碼可以通過“if （a b）”決策來做到這一點——“b”代表預期權重，“a>”對應於實際權重。 團隊可能會將其更改為「if （a≤b）」，從而更改結帳的回應方式;即使在預期重量下，它也會標記該專案。
3. 語句突變示例
語句突變涉及更改規則或輸出 – 這甚至可能包括從應用程式中完全刪除語句。 這些突變可能比其他突變更明顯，具體取決於特定陳述的頻率;測試人員明智地選擇語句至關重要。
例如，如果使用者嘗試購買有年齡限制的商品，自助結帳機可能會顯示警告。 如果沒有相應的語句，機器可能會崩潰或允許任何客戶購買任何物品。
通過改變語句並將其突出顯示給團隊，測試人員可以驗證他們的方法是否適應了這些問題。
通過突變測試檢測到的錯誤和錯誤類型
突變測試主要發現測試過程本身的問題。 考慮到這一點，以下是這些檢查可以幫助識別的一系列問題：
1. 測試用例不明確
如果突變分析顯示突變數較低（甚至任何低於 100% 的分數），這表明團隊的測試用例無法解釋可能影響應用程式的所有可能故障。
它們可能不夠具體或廣泛，無法滿足團隊的要求。 這些文件應包含團隊在測試軟體時可能遇到的各種可能性，以確保可靠性。
2. 未經培訓的測試團隊
突變測試還可以說明團隊的能力，包括他們個人識別突變和其他故障的能力。 如果儘管測試用例清晰詳細，但他們仍無法在程式中定位突變體，這可能是由於測試人員沒有正確應用這些用例。
突變程式可以在整個測試過程中顯示問題——這也可能包括不熟練或未經培訓的測試人員。
3. 測試軟體不足
如果一家公司使用這些檢查來檢查自己的測試平臺，它可能會發現該軟體無法準確識別或殺死突變代碼。
公司可能會通過調查其他選擇來做出回應，直到他們找到與他們的測試用例相容的選擇。 如果自動化軟體無法找到有問題的代碼，它可能很難識別影響軟體的其他問題。
4. 未優化的代碼
突變測試可以揭示軟體中已經存在的問題。 例如，測試人員可能會嘗試改變代碼，但自己會發現關鍵缺陷。
這是該計劃的另一個重要視角，表明代碼突變提供了超越測試過程的好處。 測試人員以任何身份檢查此代碼的次數越多，團隊在整個測試階段發現和修復的問題就越多。
常見突變測試指標
突變測試使用的主要指標包括：
1.被殺死的變種人
這是指測試人員或軟體能夠識別的突變體數量，標記它們的存在以確保員工能夠找到諸如此類的小故障。
測試人員殺死的突變體數量取決於其測試用例的強度。
2. 活著的突變體
活突變體是測試人員或軟體無法識別的突變體 – 顯示團隊質量保證策略中可能存在的任何差距。 如果發生這種情況，測試人員應該重新校準他們的過程和測試用例，以適應這些突變體並在未來的檢查中殺死它們。
3. 有效突變體
該指標確定程式能夠成功包含的突變數量，而不會發生運行時錯誤使測試無效及其有效性。
有效的突變體是測試人員和自動化軟體可以檢查的突變體;這是由於突變相對較小。
4. 無效突變體
顯著的突變可能會影響應用程式，使測試變得不切實際甚至不可能 – 因此它有助於跟蹤突變程式中存在多少“無效”突變體。
識別這些允許測試人員編輯甚至刪除它們，確保檢查僅包含有效的突變。
5. 突變體總數
無論其有效性如何，突變的數量是測試人員跟蹤的另一個指標;這使他們能夠監控突變體並記錄他們的狀態。
由於每個突變通常涉及單獨的測試，因此總數也可以作為總體代碼突變數的計數。
6. 突變評分
突變分析最有用的指標通常是突變數，它實際上是測試人員或自動化套件能夠檢測到的有效突變體的百分比。
任何低於 100% 的檢測都可能是測試程式不當的跡象。
實施突變體測試的 7 個錯誤和陷阱
突變測試是一個複雜的過程，公司必須明智地實施，以避免嚴重的問題或錯誤。 以下是測試人員在進行突變測試時應避免的七個陷阱：
1. 突變縮放不當
規模是突變分析過程中的一個重要考慮因素，因為此過程的存在是為了確保測試人員識別應用程式中的小故障。 如果突變對測試人員來說太明顯了，這可能不是檢查他們注意到或應對軟體問題的能力的有效方法。
2. 無效或活著的突變
即使在正確的規模下，許多突變也只能提供有限的有效性 – 例如，如果它們不會導致故障，或者它們導致導致應用程式停止工作的問題。
測試人員應注意任何編碼更改如何影響整個軟體。
3. 不相容的測試用例
測試用例和突變必須完美地配對在一起，以確保一致和和諧的測試。 在決定添加哪些突變時，甚至在設計初始測試用例時，品質保證團隊可能會努力確保這些突變組合在一起，並導致整體上更流暢的測試。
4. 截止日期和時程表
測試階段的長度各不相同，但應始終遵守公司內部的最後期限。 未能正確安排突變測試的公司可能無法及時完成該過程。
在專案進入測試階段之前，團隊必須確保測試計劃適當全面。
5. 測試覆蓋率不足
企業可能會選擇隨機實施其代碼突變 – 但它們涵蓋廣泛的問題仍然很重要。
為了確保測試人員和軟體都能檢測到每種類型的突變體，檢查應至少包括幾個值、決策和語句突變。
6. 使用突變體測試軟體
儘管突變測試為應用程式提供了新的視角，但團隊只能使用此方法來檢查自己的測試過程。 公司需要瞭解突變測試的確切功能和局限性;這種技術只能與其他軟體檢查一起成功。
7.突變體太多
公司確保廣泛的測試覆蓋範圍至關重要，但他們可能會在此過程中實施太多突變體。 每個突變程式都需要大量的計算能力 – 限制組織可以同時執行的數量。
運行過多的突變也會使滿足測試截止日期變得更加困難。
突變測試清單、提示和技巧
還有許多其他技巧可以説明任何團隊提高其突變測試過程的成功率，例如：
1. 檢查程式設計語言相容性
免費和付費的突變測試工具通常都專注於一種編碼語言，因此測試人員選擇與應用程式和軟體測試平臺相容的工具非常重要。
測試團隊應該調查許多選項，以確保他們使用適合其預算和首選編碼語言的程式。
2. 明智地分配測試
測試團隊的不同成員可能會查看應用程式的不同方面，通常與他們的特定優勢、劣勢和整體經驗相關。
當團隊為每個測試人員分配突變測試時，他們應該牢記這一點以了解他們的熟練程度;這表明進一步的測試可能會有多好。
3.慎重選擇故障
如果軟體的最近反覆運算存在涉及值或語句的錯誤，則複製此錯誤並檢查團隊或程式的回應方式可能會有所説明。
這有助於保證應用程式的使用壽命，並說明團隊在以前的錯誤再次出現時注意到它們的能力 – 這是 回歸測試的關鍵組成部分。
4. 最大化計算能力
由於突變檢查可能需要大量的計算能力才能運行，因此它有助於充分利用公司的硬體。
例如，如果某些機器具有更強的規格，則在這些設備上運行突變體可能會有所説明。 這使公司能夠避免較慢的機器可能導致的任何重大延誤。
5.不要忽視活突變
即使有嚴格的時程表，測試人員也應該努力修改和擴展他們的測試用例，以對抗任何在此過程中倖存下來的突變體。
雖然如果軟體或測試人員沒有發現這些錯誤，這些錯誤可能看起來並不重要，但它們仍然代表測試用例無法識別所有編碼問題。
6. 研究新的自動化軟體
如果團隊的測試用例足夠詳細，但他們的自動化測試套件無法成功地使用它們來識別每個突變，他們可能會從不同的軟體中受益。
有許多免費和付費平臺可用，公司應該檢查每個選項，以確保他們擁有最適合其測試用例的軟體。
7. 同步每個測試過程
協作是每個測試策略的核心組成部分 – 這有助於確保每個流程都能按照團隊的意圖輕鬆組合在一起。
例如，測試團隊可以在開發測試用例時考慮到突變，以確保更高水準的相容性，使測試人員更容易驗證他們的策略。
8. 使用單元測試
單元測試允許品質保證團隊單獨檢查代碼片段，從而大規模簡化測試並使團隊更容易識別問題。
如果測試人員擔心截止日期，這種組合特別有用，讓他們有機會簡化檢查並提高整體覆蓋率 – 從而進行更強大的軟體測試。
9. 編寫詳細的測試案例
突變測試用例應包含有關突變體及其對程序的影響以及測試團隊或平臺如何定位這些故障的充分資訊。
通過提供盡可能多的細節，測試人員可以親自驗證測試用例，並確保團隊確切地知道如何確保測試順利進行。
5 種最佳突變測試工具
有多種工具可以説明公司滿足其突變測試要求。 與軟體測試應用程式一樣，價格和功能因平臺而異，因此組織選擇最適合其需求的平台至關重要。
其中一些程式可以提供免費的對應程式或完全開源;儘管通常需要為更大的便利付費。
考慮到這一點，以下是用於突變測試的五種最佳工具。
1. 史崔克
Stryker 專注於 JavaScript 突變，大大簡化了這一過程，以保證沒有誤報，並降低測試人員需要申請所有突變檢查的總體工作量。
Stryker平臺智慧地評估軟體，並使用它收集的資訊來找出將從突變中受益的代碼字串或片段。 該應用程式帶有一個明文報告器，可以輸出突變體的摘要，包括Stryker是否能夠殺死它。
2. 最容易
PITest是世界上非常受歡迎的選擇，因為它能夠更改Java位元元組碼並每秒進行數千次突變。 此應用程式使用測試用例覆蓋率數據來立即瞭解哪些測試可以殺死突變體。
它只運行它知道相關的測試，從而限制了此過程通常消耗的計算能力。 PITest 還與大多數形式的 Surefire 單元測試外掛程式相容，但在有效管理測試順序依賴關係方面可能很困難。
3. 保險++
Insure++具有許多測試功能，包括突變分析，使平臺能夠發現程式中的歧義。 與傳統的突變測試不同，Insure++放棄了產生有缺陷的突變體，而是創建與項目原始程式碼匹配的功能等效突變。
這是為了避免隱含的假設，這些假設可能會無意中限制測試過程，並且可能無法反映實際的測試環境。 顧名思義，該平臺主要相容C++程序，並且每個功能都針對該語言進行了校準。
4. 混亂
此應用程式專門研究 JUnit JavaScript 框架，具有代碼如何回應突變分析的全面可視化指標。 Jumble是一個開源平臺，在JaVA應用程式的位元元組碼中工作，以減少每個測試周期的時間。
專門使用程式原始程式碼的類似應用程式有時可能需要更長的時間來執行這些檢查，因為它們的重新編譯過程。
Jumble 還利用啟發式方法進一步優化突變測試，使後續測試運行更簡單。
5. 多派
MutPy支援基於Python的應用程式的突變測試，提供對高階突變的全面支援以及全面的覆蓋分析。 該程式的介面在輸出階段易於使用，清楚地向使用者展示了團隊突變測試的每個基本細節。
MutPy為測試人員提供了許多定製選擇-允許他們根據自己的要求專門校准該軟體。 該平臺使用抽象語法樹，提供應用程式原始程式碼的清晰結構，使測試人員對他們的突變更有信心。
結論
代碼突變幾乎適用於任何軟體測試過程，為實施該技術的公司提供了許多明顯的好處 – 特別是在質量保證階段的早期。
沒有一種方法是沒有挑戰的;這意味著組織必須明智地考慮突變分析的優勢，同時確保它符合他們通常的軟體開發時程表。
這些突變使測試團隊有機會檢查自己的方法，並確定其定位和糾正原始程式碼中錯誤的有效性。 這種技術與自動化程序特別相容，讓公司驗證他們信任的軟體來處理他們的檢查。
突變測試為品質保證團隊提供了一種全面的方式來更好地了解他們自己的流程和軟體，包括他們原本無法檢測到的問題。
因此，測試團隊必須仔細研究這種技術，以評估它是否符合組織的需求——包括他們選擇的突變工具是否與他們的程式設計語言完全相容。 ZAPTEST 自動化測試軟體擁有許多功能，使其能夠通過突變測試，確保團隊對其能力充滿信心。
免費版和企業版都提供了高品質的測試過程，可以輕鬆適應代碼突變。
常見問題和資源
1. 突變測試的最佳課程
在線課程 可以説明首次測試人員學習代碼突變的基礎知識，或加強經驗豐富的品質保證人員的現有技能。 一般軟體測試課程也可以為測試人員提供許多好處。 突變測試人員的最佳在線課程包括：
PluralSight的“使用PITest進行Java突變測試”專門研究了如何更改Java代碼以及這種方法如何使實際軟體測試過程受益。
• Udemy 的“完整的 2023 年軟體測試訓練營”是一門特別最新的課程，它說明瞭軟體測試的每個關鍵組成部分，包括白盒測試。
• Alison的“軟體測試——條件覆蓋和突變測試策略”是免費的，它仔細研究了如何明智地實施突變測試。
• PluralSight 的「單元測試基礎」探討了單元測試的好處和功能，有助於確保學生瞭解編寫強單元測試的確切過程。
• Udemy的「單元測試簡介」是另一門免費課程，它提供了單元測試的清晰細分以及測試驅動開發策略的重要性。
2. 關於突變測試的前 5 個面試問題是什麼？
公司可以在面試中向候選人提出許多問題，以驗證他們對突變測試及其核心原則的經驗或理解。 這使公司能夠確保他們聘請合格的測試人員，可以輕鬆處理不同的突變相關場景。
確切的問題各不相同，但可能包括詢問他們自己的意見或他們的代碼突變技能的例子。
前五個突變測試面試問題是：
• 您以前有使用過哪些突變測試工具的經驗（如果有的話）？ 該軟體的主要功能是什麼？
• 在進行代碼更改時，您將如何確保測試速度和深度之間的健康平衡？
• 在哪些情況下無法進行突變分析？ 在這些情況下，您將如何檢查測試過程？
• 如果價值突變設法在測試過程中倖存下來，你會採取什麼行動來防止這種情況再次發生？
• 您會在突變測試用例中包含哪些資訊，以確保您的同事擁有所需的數據？
3. 關於突變測試的最佳 YouTube 教程
YouTube 上提供免費教程、網路研討會和其他視頻，以幫助測試人員加深對突變測試的理解。 關於該主題的一些最有用的視頻和系列包括：
軟體測試的「程式突變測試」 它提供了代碼突變如何説明程式的實際範例，以及如何編寫完整的測試用例。
• Devoxx的「突變測試：我的測試是否破壞了我的代碼？“，該文章著眼於突變分析如何改進各種軟體專案的整體測試程式。
• NDC 會議「殺死所有變種人！突變測試簡介“，它調查了測試套件如何能夠從代碼突變及其幫助創建的故障中受益。
• GOTO Meetings的“Mutation Testing in Python”，專門研究基於Python的應用程式如何應用突變分析來實現特定的測試目標。
Diego Pacheco的“使用PITest進行Java突變測試”，同樣說明瞭JavaScript軟體使用代碼突變 – 重點是PITest突變程式。
4. 如何維持突變測試？
將突變分析與回歸測試和其他長期策略相結合，使公司即使在發佈后也能確保嚴格的品質保證標準。
後續更新可能會導致需要進一步檢查的代碼更改。 突變測試表明，自動化軟體和測試人員在同一軟體的不同版本中是一致的，重新驗證了他們的特定方法。
新功能需要更新的測試用例，特別是當這些功能與預先存在的測試用例交互時。
除此之外，測試驅動開發的使用允許團隊成員規劃軟體的壽命和測試相容性，作為其自身開發週期的一部分。
