可移植性（兼容性）测试指南

可移植性是指应用程序能够安装到不同的环境中，在不同的环境中使用，甚至可以移动到不同的环境中。当然，前两者对所有系统都很重要。就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越好。