可維護性測試

什么是可維護性測試？

維護的主要定義是保持或維持特定狀態(tài)的過程。軟件的可維護性由開發(fā)人員負責，他們定期修改軟件以滿足不斷變化的客戶需求并解決客戶提出的問題。

軟件維護需要增強軟件的功能，以包含客戶需要的新功能，修改代碼以避免將來出現(xiàn)問題，修復代碼中的缺陷或錯誤，并確保不存在安全漏洞。此外，軟件維護通常包括發(fā)布更新，以提高適應性和有效性，并替換不受歡迎的功能。

軟件維護在很大程度上受到軟件和代碼質(zhì)量的影響。質(zhì)量較低的軟件需要更多的維護。對于低質(zhì)量軟件，增加新需求或擴展現(xiàn)有代碼的工作量和成本要高得多。

隨著可維護性的提高，軟件維護的過程也會大大簡化?？删S護性測試可以幫助應用程序的設計更具有容錯性，這反過來又意味著軟件維護對錯誤修復的需求將大大降低；這只是說明可維護性測試必要性的一個例子，本指南中還有更多的例子。

為了讓客戶滿意并保持軟件產(chǎn)品的功能，進行可維護性測試是至關(guān)重要的。

軟件維護的測量指標和類型

任何軟件都可能經(jīng)歷四種不同類型的維護。這些不同形式的維護分別服務于特定的目標。

• 糾正性維護

無論經(jīng)過多么廣泛的測試，軟件產(chǎn)品都可能存在缺陷，而這些缺陷會在沒有太多警告的情況下顯現(xiàn)出來。發(fā)現(xiàn)這些錯誤并進行修復所需的時間可以衡量軟件的可維護性。

• 完善性維護
  這種類型的維護主要是通過改進來優(yōu)化軟件。進行這些改進所需的工作量可以用來衡量軟件產(chǎn)品的可維護性。在軟件中引入新功能所花費的時間和精力可以與預定義的基線或其他以前完成的項目進行比較，以獲得準確的評估。

• 適應性維護
  除了因改進而產(chǎn)生的修改外，軟件產(chǎn)品還經(jīng)常需要因操作系統(tǒng)更新或程序所依賴的其他軟件更新而進行更改。適應性維護包括為保持軟件產(chǎn)品與不斷變化的環(huán)境（如不斷變化的硬件和操作系統(tǒng)）兼容而進行的調(diào)整。為實現(xiàn)更好的兼容性而引入這些變化所需的時間和精力可以作為衡量軟件可維護性的另一個指標。

• 預防性維護

這是對軟件進行的維護，目的是減少將來可能需要進行的維護。

對軟件進行這些更改是為了先發(fā)制人地解決未來的問題，并使軟件對可能出現(xiàn)的問題有更強的承受力。

如何衡量應用程序的可維護性？

衡量一個應用程序的可維護性有幾個屬性。應用程序的可變更性和在變更過程中的穩(wěn)定性是兩個可能的衡量標準。此外，還可以根據(jù)分析應用程序以查找錯誤的難易程度來衡量可維護性。

ISO是國際公認的標準，為系統(tǒng)和軟件質(zhì)量要求和評估（SQuaRE）提供了指南。ISO 25010定義了衡量軟件質(zhì)量的以下特征。

• 模塊化

考察應用程序的模塊化程度。它評估軟件是否由不同的模塊化組件組成，或者是否有非模塊化的、可能相互依賴的組件。

• 重用性

該標準重點關(guān)注已有代碼是否可以重新利用，以便在應用程序的其他地方提供類似功能。重復使用代碼可以降低成本、提高生產(chǎn)率和整體質(zhì)量。

• 可分析性：

意外軟件缺陷被發(fā)現(xiàn)和修復的有效程度。該參數(shù)還可用于評估實施某項變更或軟件升級的效果。

• 可修改性：

評估在不降低或損害最終產(chǎn)品質(zhì)量的情況下，應用程序的可修改程度。

• 可測試性

可測試性是指在多大程度上可以為應用程序制定測試標準，以及是否可以通過運行上述測試來檢驗這些標準是否得到滿足。

通過了解各種形式的軟件維護和相應的屬性來衡量應用程序的可維護性，可維護性測試可以準確地認識到成功和輕松地修復或更新軟件的潛力。

可維護性是指更新、修改、重用和測試系統(tǒng)的能力。這對大多數(shù)系統(tǒng)都很重要，因為大多數(shù)系統(tǒng)在其生命周期內(nèi)都會被多次更新、修改和測試。通常情況下，系統(tǒng)的各個部分甚至整個系統(tǒng)都會被用于新的和不同的場合。

為什么要對系統(tǒng)進行所有的更改？請記住，當我們討論可靠性時，我們說過軟件不會磨損，但會過時。我們需要新的擴展功能。我們還需要補丁和更新，以使系統(tǒng)運行得更好。我們必須適應新發(fā)布的環(huán)境，互操作系統(tǒng)也將更新，通常需要對我們的系統(tǒng)進行更新。

設計問題。概念問題。符合標準和指南（或不符合標準和指南）。我們有一個很好的方法來發(fā)現(xiàn)這些問題。這就是靜態(tài)測試。從最初的需求到最新的補丁，可能沒有更好的方法來確保系統(tǒng)的可維護性。在這種情況下，一個新工具、幾個腳本測試或相當細心的測試人員并不能神奇地將豬耳朵變成絲綢錢包。

必須讓管理層了解良好的可維護性所需要的投資。這必須被視為一項長期投資，因為大部分的回報都會在未來的道路上出現(xiàn)。而且，這也是最難出售的一種投資，因為它大多是無形的。如果我們很好地建立了一個可維護的系統(tǒng)，我們?nèi)绾我杂行蔚姆绞较蚬芾韺诱故净貓竽兀?/p>

好吧，我們不會有那么多的補丁，但我們無法毫無疑問地證明這是投資的結(jié)果。我們的維護程序員會犯更少的錯誤，導致更少的回歸錯誤，但我們不一定能指出我們沒有犯的錯誤。

參考資料

• 軟件測試精品書籍文檔下載持續(xù)更新 https://github.com/china-testing/python-testing-examples 請點贊，謝謝！
• 本文涉及的python測試開發(fā)庫 謝謝點贊！ https://github.com/china-testing/python_cn_resouce
• python精品書籍下載 https://github.com/china-testing/python_cn_resouce/blob/main/python_good_books.md
• https://www.browserstack.com/guide/maintainability-testing
• https://www.tmap.net/building-blocks/maintainability-testing

如何進行可維護性測試？

在實施可維護性測試時，并沒有硬性的規(guī)則來定義需要遵循的流程。一個軟件應用程序在發(fā)布之前和發(fā)布之后，預計會經(jīng)過多次更新，以糾正錯誤、引入新功能、調(diào)整現(xiàn)有功能和改變非功能性軟件特征。

因此，這種測試可能因具體情況而異，實施方法也可能不同。然而，一般來說，通過自動化測試工具，如Selenium或Percy進行可視化測試，可以極大地支持和加快可維護性測試。

測試選項可維護性測試可以使用靜態(tài)或動態(tài)測試方法。作為軟件開發(fā)過程的一部分，靜態(tài)測試檢查設計文檔和源代碼的組織、結(jié)構(gòu)、復雜性和其他特性。

靜態(tài)測試的一些示例如下

• 某些控制結(jié)構(gòu)（如決策語句）的嵌套深度
• 循環(huán)復雜性

靜態(tài)分析和審查是可維護性測試的適當方法，它們應該在設計文檔可用時就開始，并在構(gòu)建應用程序的整個過程中持續(xù)進行。

靜態(tài)分析和評審是可維護性測試的合適方法，應該從設計文檔開始，貫穿整個應用程序開發(fā)過程。可維護性可以在軟件開發(fā)生命周期的早期進行評估，而不需要等待一個完成的和可運行的系統(tǒng)，因為可維護性已經(jīng)融入到代碼和每個單獨代碼組件的文檔中。

動態(tài)軟件測試是為了檢查代碼的動態(tài)特性并確定其功能。它提供了應用程序在使用中的行為的有價值的信息。

動態(tài)測量的一些示例包括

• 對更新或錯誤修復的持續(xù)時間進行計時。
• 系統(tǒng)在兩次更改之間的穩(wěn)定性。

動態(tài)可維護性測試的重點是為特定的應用程序制定文檔化的維護流程，例如對軟件進行更改或改進。為了確認規(guī)定的服務水平可以通過概述的流程來實現(xiàn)，需要使用各種維護情況作為測試用例。

當支持的基礎設施非常復雜，并且可能有多個部門或組織參與支持程序時，這種類型的測試尤為重要。

可維護性測試最佳實踐

• 在進行可維護性測試時，有必要制定一個可維護性因素清單，如系統(tǒng)的穩(wěn)定性或代碼的復雜性。

• 確保軟件符合數(shù)據(jù)庫、界面和開發(fā)過程的適當標準。例如，驗證軟件是否遵循優(yōu)化算法和代碼重用性等良好實踐。

• 創(chuàng)建一個可維護性衡量標準來表示特定因素的可維護性成本和優(yōu)勢是很有幫助的。對于所評估的每個組件，都可以分配一種加權(quán)分數(shù)，以便進行排序，確定哪些方面需要最大的關(guān)注。這有助于制定行動計劃，優(yōu)先解決得分最高的因素。

• 確保軟件符合前面討論的五個可維護性屬性： 模塊化、可重用性、可分析性、可修改性和可測試性。

易分析性

軟件產(chǎn)品被診斷出缺陷或故障原因的能力，或者被識別出需要修改的部分的能力。換句話說，需要花費多少精力才能診斷出系統(tǒng)中的缺陷，或確定需要修改的地方？

以下是可分析性差的四個常見原因，排名不分先后。

• 沒有模塊化

• 缺乏良好的文檔。

• 標準和指南不完善，或者根本不存在。沒有編程規(guī)范。

• 抽象程度過高

解決大多數(shù)問題的方法都是一樣的。良好、可靠的標準和指南。隨時通過靜態(tài)測試來執(zhí)行，尤其是在時間緊迫的情況下。沒有借口。如果組織明確指出，可分析性差是一類重要的缺陷，是不能容忍的，那么往往就不會出現(xiàn)這個質(zhì)量子特性的問題。

內(nèi)部可分析性指標

• 活動記錄

衡量系統(tǒng)狀態(tài)記錄的詳盡程度。其計算方法是，計算按照規(guī)定寫入活動日志的項目數(shù)，與根據(jù)需求應該寫入的項目數(shù)進行比較。計算公式為X = A / B

其中，A是實際按照規(guī)定寫入活動日志的項目數(shù)量（經(jīng)審核確認），B是按照規(guī)范規(guī)定應寫入日志的項目數(shù)量。該值越接近1，日志記錄就越完整。

• 診斷功能的準備程度

衡量診斷功能提供的全面程度。診斷功能分析故障，并向用戶提供輸出或日志，解釋故障原因。該指標是已實現(xiàn)的診斷功能與技術(shù)規(guī)范中要求的診斷功能數(shù)量的比率，使用相同的公式計算：X = A / B

A是已實施的診斷功能數(shù)量（審查中發(fā)現(xiàn)），B是技術(shù)規(guī)范中要求的數(shù)量。該指標也可用于衡量系統(tǒng)的故障分析能力和因果分析能力。

外部可分析性指標

組織可能希望跟蹤的外部可維護性度量。在測試或維護過程中，當軟件被維護或修改時，這些指標有助于測量維護者、用戶或系統(tǒng)的行為等屬性。

• 審計跟蹤能力

衡量用戶（或維護者）識別導致故障的具體操作的難易程度。ISO 9126-2在解釋如何記錄這一指標時有些抽象：它說要觀察試圖解決故障的用戶或維護者。這似乎與該指標的計算方法相悖，即使用公式X = A / B

其中，A是運行期間實際記錄的數(shù)據(jù)項數(shù)量，B是為充分監(jiān)控運行期間軟件狀態(tài)而應記錄的數(shù)據(jù)項數(shù)量。與本標準中的許多其他指標一樣，企業(yè)必須自行定義B的確切值。有多少可能發(fā)生的不同錯誤情況應被記錄？X的值越接近1，意味著記錄的所需數(shù)據(jù)越多。組織必須將此視為一種權(quán)衡；我們希望記錄的越多，就需要編寫更多的代碼來監(jiān)控執(zhí)行、評估發(fā)生了什么并記錄下來。

• 診斷功能支持

衡量診斷功能支持因果分析的能力。換句話說，用戶或維護人員能否識別導致故障的特定功能？與上一個指標一樣，應用方法僅指觀察用戶或維護人員試圖使用診斷功能解決故障的行為。計算公式為X = A / B

其中，A是使用診斷功能成功分析的故障數(shù)量，B是登記的故障總數(shù)。越接近1越好。

• 故障分析能力

衡量用戶或維護人員識別導致故障的具體操作的能力。要計算該指標，請使用公式X = 1 - A / B

其中，A是仍未找到原因的故障數(shù)量，B是登記的故障總數(shù)。請注意，這實際上是上一個指標診斷功能支持的反面。這個指標衡量的是我們無法診斷的故障數(shù)量，而上一個指標衡量的是我們診斷出的故障數(shù)量。越接近1.0越好。

• 故障分析效率

衡量用戶或維護人員分析故障原因的效率。這實質(zhì)上是對解決系統(tǒng)故障所用平均時間的衡量，計算公式為X = Sum(T) / N。

其中，T是每次解決故障所需的時間，N是已解決問題的數(shù)量。該指標的標準中有兩個有趣的說明。ISO 9126-2指出，只有成功解決的故障才應包括在此測量中；但是，它接著指出，未解決的故障也應進行測量并一并提交。該標準還指出，在計算這一指標時，可以使用人時而非簡單的小時數(shù)，這樣就可以衡量出努力程度而非簡單的經(jīng)過時間。

• 狀態(tài)監(jiān)測能力

衡量在系統(tǒng)實際運行過程中導致故障的操作是否容易獲得監(jiān)控數(shù)據(jù)。該指標的計算公式為X = 1 - A / B

其中，A是用戶或維護人員試圖獲取監(jiān)控數(shù)據(jù)但失敗的案例數(shù)，B是他們在運行過程中試圖獲取監(jiān)控數(shù)據(jù)的案例數(shù)。越接近 1 越好，這意味著他們在嘗試獲取監(jiān)控數(shù)據(jù)時越成功。

可變更性（易修改性 Changeability | Modifiability）

軟件產(chǎn)品能夠?qū)崿F(xiàn)特定修改的能力。

幾乎所有影響可變更性的因素都是設計和實施實踐。

基于設計的問題包括耦合和內(nèi)聚。耦合和內(nèi)聚是指系統(tǒng)如何被分割成模塊。高耦合度和低內(nèi)聚性對良好的軟件設計是有害的。

耦合是指模塊在執(zhí)行過程中相互依賴內(nèi)部操作的程度。高耦合意味著模塊之間存在大量的依賴關(guān)系和共享代碼。另一種可能是，一個模塊依賴于另一個模塊做某事的方式。如果改變這種依賴關(guān)系，就會破壞第一個模塊。當允許高耦合時，對單個模塊進行修改變得非常困難；這里的修改通常意味著那里和那里的更多修改。低耦合是可取的；每個模塊都有自己的任務，并且基本上是獨立完成的。

有許多不同類型的耦合：

• 內(nèi)容耦合

當一個模塊訪問另一個模塊的本地數(shù)據(jù)時。

• 共用耦合：兩個或多個模塊共享全局數(shù)據(jù)。
• 外部耦合：兩個或多個模塊共享一個外部接口或設備。
• 控制耦合：一個模塊告訴另一個模塊做什么。
• 數(shù)據(jù)結(jié)構(gòu)耦合：多個模塊共享一個數(shù)據(jù)結(jié)構(gòu)，每個模塊只使用其中的一部分。
• 數(shù)據(jù)耦合：數(shù)據(jù)從一個模塊傳遞到另一個模塊--通常通過參數(shù)。
• 消息耦合：模塊之間互不依賴；模塊之間傳遞消息而不傳遞數(shù)據(jù)。
• 無耦合：模塊之間完全不通信。

通常需要一些耦合；模塊通常必須能夠通信。一般來說，消息耦合或數(shù)據(jù)耦合是最佳選擇。

另一方面，內(nèi)聚描述了模塊職責的集中程度。一般來說，模塊應該只做一件事，而且要做得很好。內(nèi)聚性低的指標包括：模塊中的許多函數(shù)或方法做不同的事情，而這些事情是不相關(guān)的，或者它們處理的是完全不同的數(shù)據(jù)集。

一般來說，低耦合度和高內(nèi)聚度是相輔相成的，是可變更性良好的標志。高耦合度和低內(nèi)聚度通常是設計流程不完善的表現(xiàn)，也是可變更性差的標志。

由不恰當?shù)膶崿F(xiàn)方法引起的可變更性問題涉及到我們在編程課上被告知不能做的許多事情。

使用全局變量是最大的問題之一；它導致了高度的耦合，一個模塊中變量的改變可能會對其他模塊產(chǎn)生一系列的副作用。

將變量值硬編碼到模塊中應該被視為一個嚴重的潛在錯誤。對于開發(fā)人員來說，命名常量是一種更好的編寫代碼的方式；當他們決定改變值時，所有的實例都會被一次性改變。當使用硬編碼值（有些人稱之為神奇數(shù)字）時，總會有一些被改變，而另一些不會。

對硬件進行硬編碼設計也是一個問題。為了提高速度，一些開發(fā)人員喜歡按照他們所編寫的平臺的硬件進行編程。這可能意味著使用操作系統(tǒng)、硬件平臺或正在使用的設備的實現(xiàn)細節(jié)。當然，當時間流逝，硬件、操作系統(tǒng)和/或設備發(fā)生變化時，軟件就會出現(xiàn)問題。

系統(tǒng)越復雜，可變性就越差。與往常一樣，有時我們需要對復雜性進行權(quán)衡。

我們前面提到的Jamie參與的項目，即重寫一個中端計算機操作系統(tǒng)，就是軟件工程做得很好的一個例子！每個開發(fā)人員和大多數(shù)測試人員都接受了為期數(shù)周的全職面向?qū)ο箝_發(fā)和設計培訓。他們將2500萬行的PL/MP（一種優(yōu)雅的過程語言）代碼轉(zhuǎn)換為C++，這不是一個補丁，而是一次徹底的重寫。他們花了大量時間制定每個開發(fā)人員都必須遵守的標準和指南。他們在靜態(tài)測試方面進行了大量投資，并對每個人進行了培訓。

低耦合和高內(nèi)聚是當時的流行語。也許 "流行語 "是不正確的；他們真正相信自己正在做的事情?？删S護性是規(guī)則。

他們的經(jīng)驗法則是將任何方法、函數(shù)或代碼限制在打印出來的一頁紙上。也許20到25行代碼。他們使用良好的面向?qū)ο笠?guī)則，包括類、繼承和數(shù)據(jù)隱藏。他們在模塊之間使用消息傳遞來避免任何全局變量。他們讓人編寫類庫，并對其進行測試，從而真正實現(xiàn)了重復使用。

因此，您可能會認為一切都非常順利。最終的結(jié)果是出色的，但一路上也有不少磕磕絆絆。他們有一個操作系統(tǒng)必須提供的特殊功能；他們估計，使用新的處理器，他們必須在7000個CPU周期內(nèi)完成任務。重寫后，他們發(fā)現(xiàn)執(zhí)行該操作需要超過99,000個CPU周期。他們的誤差非常大。而且，由于這個動作每分鐘可能會發(fā)生數(shù)千次，他們的設計需要完全重新考慮。事實上，低耦合、高內(nèi)聚、繼承和數(shù)據(jù)隱藏都有各自的代價。

每個設計決策都需要權(quán)衡利弊。對于許多系統(tǒng)來說，好的設計和技術(shù)值得我們?yōu)橹ㄙM每一分錢。但是，當執(zhí)行速度是最重要的時候，這些技術(shù)往往不能很好地發(fā)揮作用。為了使系統(tǒng)正常運行，他們不得不拋棄所有的規(guī)則。在這個模塊中，他們重新使用了龐大的函數(shù)、直接的過程代碼、全局變量、低內(nèi)聚性和高耦合性。而且，他們做得足夠快。然而，正如您所期望的那樣，它非常容易出問題；花了相當長的時間才穩(wěn)定下來。

糟糕的文檔會對可變更性產(chǎn)生不利影響。如果維護程序員必須猜測如何進行修改，推斷原始程序員的想法，那么可變更性就會受到很大影響。文檔包括內(nèi)部文檔（代碼中的注釋，通過良好的命名方式實現(xiàn)代碼的自文檔化等）和外部文檔，包括高層和低層的設計文檔。

內(nèi)部可變更性度量

• 變更可記錄性

對規(guī)范和程序模塊的變更如何完整記錄的度量。ISO 9126-3將其定義為代碼或其他文檔中的變更注釋。該指標的計算公式為X = A / B

其中，A是有注釋的變更數(shù)量（經(jīng)評審確認），B是變更總數(shù)。該值應為0 <= X <= 1，越接近1越好。接近 0 的值表示變更控制不佳。

• 外部可變更性指標

外部可變更性度量有助于衡量當您試圖對系統(tǒng)實施變更時所需要的努力。

• 變更周期效率

衡量在可接受的時間內(nèi)解決用戶問題的可能性。該指標通過監(jiān)控用戶與維護者之間的交互，并記錄從最初的用戶請求到問題解決之間的時間來衡量。該指標的計算公式為Tav = Sum(Tu) / N

其中，Tav為平均時間，Tu為用戶從發(fā)送問題報告到收到修訂版之間的時間，N為發(fā)送的修訂版數(shù)量。Tav越短越好；但是，大量的修訂可能會對組織產(chǎn)生反作用，因此應取得平衡。

• 變更執(zhí)行時間

用于衡量維護人員為解決故障而更改軟件的難易程度。計算公式為Tav = Sum(Tm) / N

其中，Tav是平均時間，Tm是檢測到故障到找到故障原因之間的時間，N是登記和刪除的故障數(shù)量。如前所述，有兩點需要注意。應排除尚未發(fā)現(xiàn)的故障，并且可以使用努力（人-小時）來代替經(jīng)過時間。時間越短越好。

• 修改復雜性

衡量維護者為解決問題而修改軟件的難易程度。計算公式為T = Sum(A / B) / N

其中，T是修復故障的平均時間，A是更改特定故障所花費的工作時間，B是更改的大小，N是更改的次數(shù)。變更的大小可以是變更的代碼行數(shù)、變更的需求數(shù)、變更的文檔頁數(shù)等。這個時間越短越好。顯然，如果變更的次數(shù)過多，企業(yè)就應該關(guān)注。

• 軟件變更控制能力

衡量用戶識別軟件修訂版本的難易程度。這也被列為維護者如何輕松地更改系統(tǒng)以解決問題。其測量公式為X = A / B

其中，A是實際寫入變更日志的條目數(shù)，B是計劃的變更日志條目數(shù)，這樣我們就可以跟蹤軟件的變更。越接近1越好，但如果變更很少，該值將趨向于0。

穩(wěn)定性（Stability，并入Modifiability）

注意ISO25010沒有此項。穩(wěn)定性多和可靠性同義。

系統(tǒng)避免軟件修改帶來意外影響的能力。當我們對系統(tǒng)進行修改后，會產(chǎn)生多少缺陷？

這個子特性本質(zhì)上是我們在可變更性中處理的所有問題的副作用。內(nèi)聚度越低，耦合度越高，編程風格和文檔越差，系統(tǒng)的穩(wěn)定性就越低。

此外，我們還需要考慮需求的質(zhì)量。如果需求定義明確、理解透徹、管理得當，那么系統(tǒng)往往會更加穩(wěn)定。如果需求不斷變化，并且沒有被很好地記錄和理解，那么系統(tǒng)的穩(wěn)定性就會大打折扣。

系統(tǒng)時序?qū)Ψ€(wěn)定性很重要。在實時系統(tǒng)中，或者當定時非常重要時，變化往往會使定時鏈發(fā)生偏移，從而在其它地方造成故障。

內(nèi)部穩(wěn)定性指標

穩(wěn)定性指標幫助我們預測系統(tǒng)在修改后的穩(wěn)定性。

• 變更影響

系統(tǒng)修改后不良反應發(fā)生頻率的度量。該指標的計算公式為：將系統(tǒng)修改后發(fā)生的不利影響次數(shù)與實際修改次數(shù)進行比較X = 1 - A / B

其中，A為不利影響的數(shù)量，B為所做修改的數(shù)量。越接近1越好。請注意，由于馬虎的變更管理方式可能會帶來多種不利影響，因此該指標實際上可能為負值。例如，假設進行了一次變更，但出現(xiàn)了三次不良反應。使用該公式計算如下：X = 1 - 3/1 ==> -2.

• 修改影響定位

衡量修改對系統(tǒng)的影響程度。該值通過計算受修改影響的變量數(shù)量，并將其與產(chǎn)品中的變量總數(shù)進行比較，計算公式為X = A / B

其中，A為審查確認的受影響變量數(shù)量，B為變量總數(shù)。受影響變量的定義是代碼行或計算機指令中被更改的任何變量。該值越接近零，說明修改的影響可能越小。

外部穩(wěn)定性指標

• 修改成功率： 衡量用戶在維護后操作軟件系統(tǒng)而不會再出現(xiàn)故障的程度。有兩個公式可用于衡量該指標：

X = Na / Ta
Y = {(Na / Ta) / (Nb / Tb)}

Na是軟件更改后用戶遇到故障的次數(shù)，Nb是軟件更改前用戶遇到故障的次數(shù)，Ta是軟件更改后的運行時間（規(guī)定的觀察時間），Tb是軟件更改前的時間（規(guī)定的觀察時間）。越小越好，越接近0越好。從本質(zhì)上講，X 和 Y 代表軟件更改后遇到故障的頻率。指定的觀察時間用于使指標正常化，這樣我們就可以更好地比較不同版本的指標。此外，ISO 9126-2還建議，組織可能希望區(qū)分同一模塊/功能修復后出現(xiàn)的故障和其他模塊/功能出現(xiàn)的故障。

• 修改對本地化的影響

這也是衡量用戶在維護后能夠在不發(fā)生進一步故障的情況下操作系統(tǒng)的程度。計算公式為X = A / N

其中，A 是系統(tǒng)修改后（在特定時期內(nèi)）出現(xiàn)的故障數(shù)，N 是解決的故障數(shù)。該標準建議跟蹤故障的 連鎖情況；也就是說，組織應區(qū)分因先前故障而歸因于變更的故障和似乎與變更無關(guān)的故障。越小越好，越接近零越好。

可測試性

可測試性是指軟件產(chǎn)品在發(fā)生變更后的驗證能力。這當然應該是所有技術(shù)測試分析師關(guān)注的問題。

許多問題都會對系統(tǒng)的可測試性提出挑戰(zhàn)。

我們最喜歡的問題之一就是文檔。代碼中缺乏注釋和糟糕的命名習慣，這使得理解代碼到底應該做什么變得更加困難。

實施獨立的測試團隊可能會導致無意的（甚至有時是有意的）溝通中斷。在處理可測試性問題時，測試團隊和開發(fā)團隊之間的良好溝通非常重要。

某些編程風格會使代碼更難測試。例如，面向?qū)ο笤O計的主要目標之一就是數(shù)據(jù)隱藏。當然，數(shù)據(jù)隱藏也會使測試是否通過變得非常困難。多層次的繼承使其變得更加困難；您可能不知道事情發(fā)生的確切位置，也不知道哪個類（對象）真正負責要采取的行動。

代碼中缺乏工具導致可測試性問題。許多系統(tǒng)都具有自我診斷的能力；編寫了額外的代碼來確保任務正確完成，并記錄發(fā)生的問題。不幸的是，這些工具通常被視為花哨的東西，而不是必需的。

最后一點，數(shù)據(jù)問題本身也會導致可測試性問題。在這種情況下，更好的安全性和良好的加密可能會降低系統(tǒng)的可測試性。如果無法找到、測量或理解數(shù)據(jù)，系統(tǒng)就更難測試。與軟件中的許多情況一樣，必須做出明智的權(quán)衡。

內(nèi)部可測試性度量

內(nèi)部可測試性指標衡量測試修改后系統(tǒng)所需的預期工作量。

• 內(nèi)置測試功能的完整性

衡量內(nèi)置測試功能的完整性。計算方法是：計算已實現(xiàn)的內(nèi)置測試功能的數(shù)量，并與規(guī)范要求的數(shù)量進行比較。計算公式為X = A / B

其中，A是已實施的內(nèi)置測試功能的數(shù)量（經(jīng)審核確認），B是技術(shù)規(guī)范要求的數(shù)量。越接近1，越完整。

• 可測試性的自主性

衡量軟件系統(tǒng)可獨立測試的程度。該指標的計算方法是：計算使用存根或驅(qū)動程序模擬的其他系統(tǒng)的依賴項數(shù)量，并將其與其他系統(tǒng)的依賴項總數(shù)進行比較。與許多其他指標一樣，計算公式為X = A / B

其中，A是使用存根或驅(qū)動程序模擬的依賴關(guān)系數(shù)，B是其他系統(tǒng)的依賴關(guān)系總數(shù)。越接近1越好。數(shù)值為1意味著可以模擬所有其他依賴系統(tǒng)，因此軟件（基本上）可以自行測試。

• 測試進度可觀察性

測試過程中內(nèi)置測試結(jié)果的完整顯示程度。計算公式為X = A / B

其中，A是審查中確認的已執(zhí)行檢查點的數(shù)量，B是規(guī)范中要求的數(shù)量。越接近1越好。

外部可測試性度量

可測試性度量衡量測試修改系統(tǒng)所需的工作量。

• 內(nèi)置測試功能的可用性

衡量用戶或維護者在沒有額外的測試設施準備的情況下對系統(tǒng)進行操作測試的難易程度。該指標的計算公式為X = A / B

其中A是維護者可以使用內(nèi)置測試功能的案例數(shù)，B是測試機會數(shù)。越接近1越好。

• 重新測試效率

衡量用戶或維護者執(zhí)行操作測試并確定軟件是否準備好發(fā)布的難易程度。該指標是一個平均值，計算公式為
X = Sum(T) / N

其中，T是在故障解決后確保系統(tǒng)已做好發(fā)布準備所花費的時間，N是已解決故障的數(shù)量。從本質(zhì)上講，這是故障解決后的平均重新測試時間。請注意，未解決的故障不包括在此測量中。越小越好。

• 測試重啟性

衡量用戶或維護人員在維護后使用檢查點執(zhí)行操作測試的難易程度。計算公式為X = A / B

其中，A是維護者可以在所需位置暫停并重新啟動正在執(zhí)行的測試用例的測試用例數(shù)，B是正在執(zhí)行的測試用例被暫停的測試用例數(shù)。越接近 1 越好。

符合性

內(nèi)部符合性指標

可維護性合規(guī)性是對系統(tǒng)在多大程度上符合適用法規(guī)、標準和慣例的一種度量。已實施的合規(guī)項目（基于審查）與規(guī)范中要求合規(guī)的項目之間的比率使用以下公式計算X = A / B

其中，A是與可維護性合規(guī)性相關(guān)的正確執(zhí)行項目，B是要求的數(shù)量。越接近 1，系統(tǒng)的符合性越高。

外部符合性指標

可維護性合規(guī)性度量可衡量系統(tǒng)在多大程度上遵守了各種標準、慣例和規(guī)定。合規(guī)性的測量公式為X = 1 - A / B

其中，A是測試期間未實施的可維護性符合性項目的數(shù)量，B是已定義的可維護性符合性項目的總數(shù)。越接近 1 越好。

文章來源地址http://www.zghlxwxcb.cn/news/detail-569472.html

到了這里，關(guān)于可維護性測試指南的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！