可移植性（兼容性）測試指南

可移植性是指應用程序能夠安裝到不同的環境中，在不同的環境中使用，甚至可以移動到不同的環境中。當然，前兩者對所有系統都很重要。就PC軟件而言，鑒于操作系統、共存和互操作應用程序、硬件、帶寬可用性等方面的快速變化，能夠移動和適應新環境也是至關重要的。

在計算機領域剛剛起步的時候，人們對可移植性的概念還很模糊。計算機程序一開始只是一組連接真空管邏輯門的跳線。后來，匯編語言的發展使編程變得更加容易。但仍然沒有可移植性–匯編程序是基于計算機使用的特定CPU和架構。推動高級語言發展的動力來自程序在不同系統和處理器之間可移植的需求。

有多種缺陷會導致可移植性問題，但環境依賴、資源占用和非標準操作系統交互肯定是其中的重點。例如，在安裝過程中更改共享注冊表鍵值或在卸載過程中刪除共享文件是Windows平臺上典型的可移植性問題。

幸運的是，可移植性缺陷可以通過直接的測試設計技術來解決，例如成對測試、分類樹、等價分割、決策表和基于狀態的測試。可移植性問題通常需要大量的測試配置。

有些軟件在設計時沒有考慮可移植性，也不應該考慮可移植性。如果設計實時運行的嵌入式系統，我們希望它的可移植性是最不用擔心的。事實上，在審查中，如果企業有可能使系統的運行邊緣化，我們會質疑為使系統具有可移植性而做出的任何妥協。然而，也許有一天系統必須轉移到不同的芯片、不同的系統上。在這一點上，如果系統內置了一些可移植性功能，可能會很好。

在這里插入圖片描述

適應性

軟件產品適應不同特定環境的能力，而不需要采用其他行動或手段。

可移植性測試

確定軟件產品可移植性的測試過程。

共存性（兼容性）

軟件產品與其他獨立軟件在共享資源的共同環境中共存的能力。

可安裝性

軟件產品在特定環境中的安裝能力。

可替換性

軟件產品在同一環境中替代另一特定軟件產品用于相同目的的能力。

互操作性
本地化

可移植性測試簡介：

可移植性測試是一種非功能性測試方法，用于確定軟件組件或應用程序從一個環境轉移到另一個環境的難易程度。

從可移植性測試中獲得的測試結果有助于了解軟件組件從一個環境到另一個環境的易用性。

所謂 "環境 "是指從一個操作系統到另一個操作系統，從一個瀏覽器到另一個瀏覽器，或者從一個數據庫版本到另一個數據庫版本。

可移植性測試的一個主要原則是，只有當軟件組件從一個環境轉移到另一個環境時，才需要進行可移植性測試。

可移植性的衡量標準是將軟件組件從一個環境移動到另一個環境所需的工作量。衡量可移植性的一個單位是與重新開發軟件的成本相比，將軟件移植到新環境的成本。

本教程將為您全面介紹可移植性測試的含義、目標、屬性、檢查表、優點和缺點，并提供一些簡單的實際案例，便于您理解。

參考資料

軟件測試精品書籍文檔下載持續更新 https://github.com/china-testing/python-testing-examples 請點贊，謝謝！
本文涉及的python測試開發庫謝謝點贊！ 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-softwaretestinghelp-com.translate.goog/what-is-portability-testing/?_x_tr_sl=en&_x_tr_tl=zh-CN&_x_tr_hl=zh-CN&_x_tr_pto=wapp
https://en.wikipedia.org/wiki/Portability_testing

可移植性測試與兼容性測試的區別

以下幾點將簡要區分可移植性和兼容性之間的區別。

兼容性是指兩個或多個組件是否可以同時在同一環境中運行，而不會對彼此的行為產生不利影響。

舉例說明：在Windows 10等相同操作系統上運行的文字處理器和計算器可以說是相互兼容的，因為運行其中一個應用程序不會影響另一個應用程序的行為。

可移植性涉及將組件從一個環境移動到另一個環境。

例如：在Windows XP上運行的游戲，如果可以在Windows 7上運行而不改變游戲的行為，就可以說是可移植的。

簡而言之，可移植性測試涉及軟件組件在多個環境中的運行，而兼容性測試涉及在同一環境中測試兩個不同的應用程序。

測試目標

以下是該測試的目標：

確定系統是否可以移植到每個環境特征

如處理器速度、磁盤空間和內存、顯示器分辨率、操作系統和瀏覽器版本。

確定應用程序在用戶界面和功能特性方面的外觀和感覺是否與多個操作系統和多個瀏覽器相似。

該測試有助于確定系統是否可以發布，特別是當意識到產品的客戶將使用多種操作系統和多種瀏覽器版本時。

這種測試通常是根據預先確定的可移植性要求進行的，有助于發現在應用程序的單元測試和集成測試中遺漏的缺陷。

開發人員需要對測試中發現的缺陷進行修復，并將其作為產品發布的一部分。

這種測試通常在整個軟件開發生命周期中以漸進的方式進行。

與本章討論的其他質量特性相比，可移植性更需要妥協。技術測試分析師應該理解折衷的必要性，但仍要確保設計并交付測試的系統仍然適用于需要它完成的任務。

討論可移植性的最佳方式是查看其每個子特性。這就是 "總和 "與 "部分之和 "的關系。很少有關于可移植性的文章不說明這些子特性：適應性、可替換性、可安裝性、共存性和合規性。

4.6.1 適應性

適應性被定義為系統適應不同特定環境的能力，而不需要采取其他行動。

一般來說，系統設計得越緊密以適應特定環境，它就越適合該環境，而對其它環境的適應性就越差。老實說，為適應性而適應性并不可取。另一方面，出于可靠的業務或技術原因的適應性是一個非常好的主意。了解業務（或技術）情況對于確定哪些權衡是有利的至關重要。

當Jamie還是個孩子的時候，他的母親在書上看到了一種叫做 "夏威夷muumuu "的神秘服裝。他們住在20世紀60年代初的一個小鎮上；她為能訂購到這樣一件異國情調的商品而興奮不已。當她從目錄上訂購時，目錄上寫著 “一碼通用”。杰米從那件罩衫上了解到，雖然 "一刀切 "適合所有的人，但也不適合任何事物。他母親收到的東西非常大，他們開玩笑說要把它當帳篷用。

那么這有什么意義呢？如果我們試圖編寫能夠在任何地方的任何平臺上運行的軟件，那么它很可能無法很好地適應任何環境。有些編程語言，例如Java，應該能夠 “一次編寫，隨處運行”。終極可移植性！然而，Java通過為每個不同的平臺提供自己的運行時虛擬機來實現隨處運行。Java的字節碼是可移植的，但這是在為每個特定平臺設計每個虛擬機的巨大代價下實現的。

你不可能不勞而獲。適應性是有代價的：更多的設計工作、更多的復雜性、更多的代碼膨脹，而這些往往會帶來更多的缺陷。因此，當您的企業正在考慮設計適應性時，請確保您知道目標環境是什么以及業務案例是什么。

在測試適應性時，我們必須檢查應用程序是否能夠在所有預定的目標環境中正常運行。令人困惑的是，這通常也被稱為兼容性測試。正如您所想象的，當有很多選擇時，指定適應性或兼容性測試涉及到成對測試、分類樹和等價分割。

由于您可能需要將應用程序安裝到環境中，適應性和安裝可能同時進行測試。然后在這些環境中運行功能測試。有時，一小部分功能樣本就足以揭示任何問題。更有可能的是，需要進行多次測試才能得到合理的結果。不幸的是，很多時候，少量的測試就是企業所能投資的全部。考慮到這項任務的潛在巨大規模，我們的適應性測試往往是不夠的。在測試過程中，決定測試的程度和深度將取決于風險和可用資源。

適應性的程序性要素也可能需要測試。也許從一個環境遷移到另一個環境需要數據遷移。在這種情況下，我們可能需要測試這些程序以及軟件的適應性。

4.6.1.1 內部適應性指標

適應性度量有助于預測系統適應不同環境所帶來的影響。

數據結構的適應性

衡量產品對數據結構變化的適應程度。該指標的計算公式為: X = A / B

其中，A是經審查確認適應后可正確運行的數據結構的數量，B是需要適應的數據結構的總數。越接近1越好。

硬件環境適應性

衡量軟件對硬件相關環境變化的適應性。該指標特別關注硬件設備和網絡設施。計算公式為X = A / B

其中，A是在指定的多種硬件環境下能夠實現所需結果的已實現功能的數量，經審核確認；B是需要具備硬件適應能力的功能的總數。越接近1越好。

組織環境適應性

衡量軟件對組織基礎設施變化的適應性。該指標的計算公式為X = A / B

其中，A是在多個特定組織和業務環境中能夠實現所需結果的已實施功能的數量，經審核確認；B是需要這種適應性的功能的總數。越接近1越好。

系統軟件環境適應性

衡量軟件產品對與系統軟件相關的環境變化的適應性。該標準特別列出了操作系統、網絡軟件和合作應用軟件的適應性。該指標使用的公式為X = A / B

其中，A是經評審確認，能夠在指定的多個系統軟件環境中實現所需結果的已實現功能的數量，B是需要這種能力的功能的總數。越接近 1 越好。

移植用戶友好性

衡量項目移植操作的輕松程度。該指標使用相同的公式：X = A / B

A 是根據評審判斷為易于移植的功能的數量， B 是要求易于適配的功能的總數。

4.6.1.2 外部適應性度量

適應性指標用于衡量系統或用戶在嘗試將軟件適配到不同環境時的行為。

數據結構的適應性

衡量用戶或維護者在新的環境中如何輕松地使軟件適應數據。該指標的計算公式為X = A / B

其中，A 是由于適應限制而無法在新環境中使用的數據項數量，B是預計可在新環境中使用的數據項數量。數字越大（即越接近1）越好。這里的數據項包括數據文件、數據元組、數據結構、數據庫等實體。計算該指標時，A和B應使用相同類型的數據。

硬件環境適應性

衡量用戶或維護者如何輕松地使軟件適應環境。該指標的計算公式為X = 1 - A / B

其中，A是在新環境硬件運行測試期間未完成或未達到適當工作水平的任務數量，B是測試的功能總數。越大（接近1）越好。ISO 9126-2規定該指標用于參考硬件設備和網絡設施的適應性。這將其與下一個指標區分開來。

組織環境適應性

衡量用戶或維護者如何輕松地使軟件適應環境，特別是對組織基礎設施的適應性。該指標的計算公式與上一個指標類似X = 1 - A / B

其中，A是在用戶的業務環境中進行運行測試時無法完成或未達到適當水平的任務數量，B是測試的功能總數。該指標關注的是用戶組織的業務運營環境。這將它與下一個類似的指標區分開來。越大越好。

系統軟件的環境適應性

這也是衡量用戶或維護者如何輕松地使軟件適應環境的指標，特別是對操作系統、網絡軟件和合作應用軟件的適應性。該指標的計算公式相同：X = 1 - A / B

A是在操作系統軟件或同時運行的應用軟件的運行測試中未完成或未達到適當水平的任務數，B是測試的功能總數。同樣，越大越好。

移植用戶友好性

最后一個適應性指標也是衡量用戶如何輕松地使軟件適應環境。在這種情況下，它的計算方法是，當用戶嘗試安裝或更改設置時，將用戶為完成軟件與用戶環境的適配所花費的所有時間相加。

適應性小結

適應性測試是驗證系統是否適應目標環境的過程。在多個系統之間使用通用的通信標準有助于提高整個系統的適應性。

適應性測試包括以下特點：

硬件依賴性。
軟件依賴性
標準語言。
系統與每個目標環境的通信。
依賴性封裝
跨多個系統的依賴性表示。
本地化

4.6.2 可替換性

可替換性測試是指在相同的環境下，系統/組件可以替代另一個指定的軟件產品用于相同的目的。我們關注的是檢查系統中的軟件組件是否可以與其他組件交換。

微軟的系統架構風格是軟件組件概念的主要驅動力，盡管微軟并沒有發明這一概念。遠程過程調用（RPC）由來已久，它允許在外部CPU上完成系統的部分處理，而不是在一個CPU上完成所有處理。在Windows中，基本設計是將大部分應用程序功能置于EXE文件之外，并將其放入稱為動態鏈接庫（DLL）的可替換組件中。早期的Windows功能主要存儲在三個大型DLL中。對于測試人員來說，拆分功能的想法造成了許多問題；任何測試人員如果曾坐了幾個小時試圖從DLL地獄中解脫出來，都可以證明這一點，因為在DLL地獄中，同一個文件的不兼容版本會導致令人費解的故障。

然而，隨著時間的推移，情況有所好轉。從組件對象模型（COM）到分布式組件對象模型（DCOM），再到面向服務的體系結構（SOA），將任務從中央可執行文件中移除的想法變得越來越流行。現在很少有企業會考慮構建一個包含所有功能的單一可執行文件。現在，許多復雜的系統都是由商業現貨（COTS）組件和一些連接代碼封裝在一起的。HELLOCARMS就是一個很好的例子。

微軟Office套件的設計就是一個很好的可替換/可重復使用組件的例子–盡管它看起來并不是這樣。Office的大部分功能都存儲在COM對象中；這些對象可以單獨更新，而無需替換整個EXE。這種架構允許Office組件共享、升級和即時擴展功能。它還便于在應用程序之間使用宏和自動執行任務。

現在，許多應用程序都能夠使用不同的主要數據庫管理系統（DBMS）包。展望未來，許多業內人士預計這一趨勢只會加速發展。

測試人員在考慮如何進行測試時，必須考慮整個可替換組件的范圍。考慮分布式組件架構（從RPC到COTS包）的最佳方法是考慮松散耦合的功能，其中良好的接口設計至關重要。從本質上講，我們需要考慮接口來了解要測試什么。因此，大部分測試都是集成類型的測試。

我們應該從界面的靜態測試開始。我們如何調用分布式功能，模塊之間如何通信？在集成測試中，我們希望測試所有我們期望使用的不同組件。在系統測試中，我們當然應該考慮我們期望在生產中看到的不同配置。

低耦合是可替換性成功的關鍵。在設計系統時，如果設計的目的是允許使用多個組件，那么與任何一個接口耦合過緊都會導致不可替換性。此時，系統將依賴于外部模塊，而這些外部模塊很可能不受我們組織的控制。

這是管理層在發展基于組件的系統時必須考慮的問題。當所有東西都在一個可執行文件中時，我們可以負責任地測試所有功能。隨著組件可替換性帶來的分散化的增長，誰負責測試什么的問題變得至關重要。這個問題我們留待《高級測試管理》一書，《高級軟件測試》，第二卷來討論。

4.6.2.1 內部可替換性指標

可替換性度量有助于預測軟件對用戶工作的影響，用戶試圖在特定的環境和使用背景下使用該軟件來替代其他指定的軟件。

數據的持續使用

對軟件替換后預計保持不變的原始數據量的度量。計算公式為X = A / B

其中，A是經審核確認的預計在更換后仍可使用的數據項數量，B是要求在更換后仍可使用的舊數據項數量。越接近1越好。

功能兼容性：衡量預計在替換后保持不變的功能數量。計算公式為X = A / B
其中，A是新軟件中與舊軟件中相同功能產生類似結果的功能數量（經審核確認），B是舊功能的數量。越接近于 1 越好。

4.6.2.2 外部可替換性指標

可替換性度量衡量的是系統或用戶試圖用軟件替代其他指定軟件的行為。

繼續使用數據

衡量用戶在更換軟件后繼續使用相同數據的難易程度。從本質上講，該指標衡量軟件遷移的成功與否。計算公式為X = A / B

其中，A 是軟件更換后能夠持續使用的數據項數量，B是預計能夠持續使用的數據項數量。越接近1越好。該指標既可用于軟件的新版本，也可用于全新的軟件包。

功能包容性：衡量用戶在更換軟件系統后繼續使用類似功能的方便程度。該指標的計算方法相同，使用公式為

X = A / B
其中，A是在新軟件中無需更改即可產生類似結果的功能數量，B是新軟件與舊軟件相比提供的類似功能數量。該值越接近1越好。

用戶支持功能一致性

衡量新組件與現有用戶界面的一致性。其測量公式為X = 1 - A / B

其中，A是用戶發現與用戶期望不一致而無法接受的功能數量，B是新功能的數量。越大越好，意味著被認為不一致的新功能越少。

可替換性小結

可替換性是指用一個軟件組件替換另一個軟件組件的能力。替代先前組件的組件必須在所有目標環境下產生與先前組件相同的結果。理想情況下，它應與被替換的組件具有相同的用途。

同一領域的競爭產品將是可替換性的理想候選者，因為被替換的產品可能比競爭對手的現有產品便宜得多。

4.6.3 易安裝性

易安裝性是指系統被安裝到特定環境中的能力。測試人員必須同時考慮可卸載性。

關于可安裝性測試有好消息也有壞消息。從概念上講，它是簡單明了的。這是好消息。我們必須使用標準的安裝、更新和補丁設施將軟件安裝到目標環境中。這有多難呢？這是個壞消息。在測試過程中可能出現的問題幾乎無窮無盡。

以下是一些必須考慮的風險：

我們安裝一個系統，安裝成功與否取決于新系統所依賴的所有其他軟件是否正常工作。所有共同安裝的系統是否都能正常工作？它們都是正確的版本嗎？安裝程序是否檢查過？

我們發現，通常參與安裝的人員都不知道如何正確安裝，因此他們感到困惑、沮喪，并犯下許多錯誤（導致系統處于未定義、崩潰甚至完全損壞的狀態）。這類問題應該在安裝文檔的可用性測試中暴露出來。您在測試安裝的可用性，對嗎？

我們不能按照安裝手冊或用戶手冊中的說明或通過安裝向導來安裝軟件。這聽起來很簡單，但請注意，這需要在足夠多的不同環境中進行測試，以確保您有信心在大多數（如果不是全部）最終環境中都能正常工作，同時還要查看各種安裝選項，如部分安裝、典型安裝或完全安裝。請記住，安裝本身就是一個軟件系統，必須進行測試。

我們觀察到安裝過程中出現的故障（如無法加載特定的DLL），這些故障沒有被正確清理，因此系統處于損壞狀態。這種可能性的變化是一個挑戰。

我們發現無法部分安裝、無法中止安裝或無法卸載。

我們發現安裝過程或安裝向導無法保護我們免受無效硬件、軟件、操作系統或配置的影響，甚至可能無法檢測到這些硬件、軟件、操作系統或配置。這很可能與安裝過程中或安裝后的故障有關，導致系統處于未定義、崩潰甚至完全損壞的狀態。

我們發現，試圖卸載和清理機器會破壞系統軟件負載。

我們發現安裝耗時過長，甚至根本無法完成。

無論安裝成功與否，我們都無法降級或卸載。

我們發現某些錯誤信息既無意義也無參考價值。

卸載時，刪除的模塊太少或太多。

順便提一下，對于我們剛才提到的每種風險類型，我們不僅要考慮安裝問題，還要考慮更新和補丁的類似問題。

這些測試不僅需要監控安裝、更新或補丁的過程，還需要在事后進行一定的功能測試，以發現任何可能被悄悄引入的問題。因為，歸根結底，最重要的問題是：當我們完成安裝后，系統能否正常工作？

此外，我們還必須考慮安全問題。在安裝過程中，我們需要有較高的訪問權限才能執行所有任務。我們是否會打開一個安全漏洞，讓別人鉆進來？

我們如何知道安裝成功了？所有的功能都能正常工作嗎？所有的互操作系統都能正常工作嗎？

在開始討論可安裝性時，我們說這是一個好消息和壞消息的場景，好消息是安裝在概念上是簡單明了的。我們撒謊了。事實并非如此。我們所知道的處理安裝測試的最佳方法是確保將其作為一個完全不同的組件進行測試。有些組織有單獨的安裝測試團隊；這對我們來說很有意義。

最后一點。作為一個自動化專家，Jamie曾經想過，如果能把我們剛才談到的所有東西都自動化，只需按下按鈕就能完成整個測試過程，那該有多好。不幸的是，我們從來沒有親眼見過這樣做。

在最近的一次會議上，Jamie與一位自動化專家進行了交談，她聲稱她的團隊已經成功實現了所有安裝任務的自動化。然而，她對如何實現自動化的細節卻語焉不詳，因此我們不知道該如何相信她的故事。

在嘗試測試安裝和卸載時，可能會遇到各種問題，也可能會有各種不同的失敗方式，這都需要人腦來處理。在我們的工具和方法變得更好之前，我們認為我們將繼續手動完成大部分測試工作。

在Jamie第一次擔任一個項目的首席測試員期間，他決定與測試團隊和支持團隊共進午餐，以促進他們之間更好的溝通。他們正在測試一個非常復雜的系統，其中包括一個AS/400主機模塊、一個定制的ODBC驅動程序和一個完整的Windows應用程序。我們負責測試我們銷售的所有產品。

午餐期間，Jamie要求支持團隊列出10大客戶投訴。結果發現，10大投訴中有7大與安裝有關。哎呀！我們甚至沒有測試安裝，因為Jamie認為這不是什么大問題。他來自一個測試操作系統的組織–在那里，安裝是由另一個州的另一個組織測試的。

通常情況下，安裝投訴在向支持部門報告的所有問題中名列前茅。

4.6.3.1 內部可安裝性指標

可安裝性度量有助于預測用戶將軟件安裝到指定環境時受到的影響。

安裝重試的難易程度

衡量重復安裝操作的難易程度。計算公式為X = A / B

其中，A是在審查中確認的已執行的設置重試操作數，B是所需設置操作的總數。越接近1越好。

安裝工作量

衡量安裝系統所需的工作量。該指標的計算公式為X = A / B

其中，A是經審核確認的自動安裝步驟數，B是所需安裝步驟的總數。越接近1（即全自動）越好。

安裝靈活性：衡量安裝能力的可定制程度。計算公式為X = A / B
其中，A是經審核確認的已實施的可定制安裝操作的數量，B是所需的總數量。越接近 1，安裝越靈活。

4.6.3.2 外部可安裝性指標

可安裝性度量指標衡量的是用戶在嘗試將軟件安裝到指定環境時所受到的影響。

安裝的難易程度

衡量用戶將軟件安裝到運行環境中的難易程度。計算公式為X = A / B

其中，A是用戶為了自己的方便而成功更改安裝操作的案例數，B是用戶試圖更改安裝程序的案例總數。越接近1越好。

設置重試的難易程度

衡量用戶重試安裝軟件的難易程度。該標準并未明確說明為何需要重試，只是說明可以嘗試重試。該指標的計算公式為X = 1 - A / B
其中A為用戶重試安裝失敗的次數，B為重試安裝的總次數。越接近1越好。

易安裝性小結

可安裝性是對需要安裝在目標環境中的軟件進行的測試。

作為可安裝性測試的一部分，需要驗證以下特性：

安裝所需的操作系統要求。
應用程序使用的瀏覽器要求。
內存或RAM要求。
安裝程序
卸載程序
安裝中斷的例外情況
軟件安裝的前提條件。

4.6.4 共存性

我們需要討論的可移植性的第四個子特性稱為共存性測試，也稱為社會性或兼容性測試。這被定義為在共享資源的共同環境中與其它獨立軟件共存的能力。通過這種類型的測試，我們檢查在同一環境中運行的一個或多個系統是否沒有沖突。請注意，這與互操作性測試不同，因為這些系統可能不會直接交互。在前面，我們把這些系統稱為 "同居 "系統，盡管這個短語有點誤導，因為人類的同居通常涉及相當數量的直接交互。

我們很容易忘記共存測試，而只對應用程序本身進行測試。這個問題經常出現在組織成孤島的組中，應用開發在不同的組中單獨進行。然而，一旦所有的東西都安裝到數據中心，您就會在生產中進行事實上的兼容性測試，這并不是一個好主意。有時，我們可能需要與其他項目團隊共享測試，以盡量避免共存問題。

在共存測試中，我們要尋找以下問題：

當應用程序加載到同一環境中時，會對彼此的功能產生不利影響，可能是直接影響（相互崩潰），也可能是間接影響（消耗所有資源）。資源爭用是常見的故障點。

應用程序起初工作正常，但由于未定義的依賴關系，補丁和其他應用程序的升級會損壞應用程序。

DLL地獄。共享資源不兼容，最后安裝的資源可以正常工作，而其他資源則被破壞。

假設我們剛剛安裝了這個系統。我們怎么知道該系統上還有哪些其他應用程序，更不用說哪些應用程序會無法正常運行了。這是另一個必須考慮的安裝問題。在沒有共享功能的系統中（即沒有DLL的系統），這個問題就不那么重要了。

一個越來越普遍的解決方案是虛擬機的概念。我們可以在虛擬機中控制一切，因此可以避免進程間的直接資源爭用。

4.6.4.1 內部共存指標

共存度量有助于預測軟件對共享相同運行硬件資源的其他軟件產品可能產生的影響。

可用共存

衡量系統在與其他產品共享環境而不會對其產生不利影響方面的靈活性。計算公式為X = A / B

式中，A為預期與產品共存的實體數量，B為生產環境中需要共存的實體總數。越接近1越好。