1.3.1　Linux环境中SOE的好处示例

在Linux环境中有共同点指组成SOE的服务器都共享一些属性和特性。例如，它们可能都是基于Ubuntu Linux构建的，或者它们都用Apache作为其Web服务器。

我们可以用一个例子来探讨这个概念。假设在负载均衡器后面有10台Linux Web服务器，它们都提供简单的静态内容。一切正常，但随后必须进行配置更改。也许这是为了更改每个Web服务器的文档根目录，使其指向另一个团队已部署完成的新代码版本。

由于整个解决方案是负载均衡的，所以所有服务器都应该提供相同的内容。因此，每台服务器都需要进行配置更改。这意味着，如果你手工更改的话，需要更改10个配置。

手工完成这项工作将是一项乏味的工作，对于熟练的Linux管理员来说，这肯定不是最佳的方式。它也很容易出错——在10台服务器中的一台上可能会出现打字错误，但不会被发现。或者管理员可能会被其他事情中断，最后只更改了服务器配置的一部分。

更好的解决方案是编写一个脚本来进行更改。这正是自动化的基础，几乎可以肯定的是，在10台服务器上运行一次单个脚本要比在10台服务器上手动进行相同的更改更节省时间。它不仅效率更高，而且如果在一个月内需要进行相同的更改，那么只需稍加调整就可以重用脚本。

现在，让我们把计划打乱。如果由于未知的原因，有人在CentOS 7上使用Apache构建了5个Web服务器，而在Ubuntu 18.04 LTS上使用nginx构建了另外5个服务器，会怎么样？最终的结果是相同的，毕竟，在一个基本的水平，它们都是网络服务器。但是，如果要在CentOS 7上的Apache中更改文档根目录，则需要执行以下操作：

1.在/etc/httpd/conf.d中找到相应的配置文件。

2.对DocumentRoot参数进行所需的更改。

3.使用systemctl reload httpd.service重新加载Web服务器。

如果必须在Ubuntu18.04 LTS上对nginx执行相同的操作，你可以执行以下操作：

1.在/etc/nginx/sites-available中找到正确的配置文件。

2.对root参数进行所需的更改。

3.确保已使用a2ensite命令启用站点配置文件。否则，Apache将看不到配置文件。

4.使用systemctl reload apache2.service重新加载Web服务器。

从这个相当简单（尽管是人为的）的例子中可以看出，缺乏通用性是自动化的敌人。为了应对这种情况，你需要执行以下操作：

1.检测每台服务器上的操作系统。没有一种方法可以检测Linux操作系统，因此你的脚本必须经过一系列检查，包括以下内容：

1）/etc/os-release的内容（如果存在）。

2）lsb_release的输出（如果已安装）。

3）/etc/redhat-release的内容（如果存在）。

4）/etc/debian_version的内容（如果存在）。

5）如果上述步骤没有产生有意义的结果，则根据需要提供其他操作系统所需的特定文件。

2.在不同的目录中运行不同的修改命令以影响更改，如前所述。

3.运行不同的命令来重新加载Web服务器，同样如前所述。

因此，脚本变得复杂，更难编写和维护，当然也更难使其可靠。

尽管这个特殊的例子在现实生活中不太可能出现，但它确实有助于说明一个重要的问题：当环境按照给定的标准构建时，自动化更容易实现。如果决定所有Web服务器都基于CentOS 7且都运行Apache 2，并以服务名称命名站点配置，那么自动化就变得简单多了。实际上，你甚至可以运行一个简单的sed命令来完成更改。例如，假设新的Web应用程序部署到/var/www/newapp:

根本不需要环境检测，只需两个简单的shell命令。这是一个非常简单的自动化脚本的基础，可以依次在10台服务器上运行，也可以通过SSH远程运行。不管是哪种方式，我们的自动化任务现在都非常简单，并且显示了通用性的重要性。重要的是，SOE在本质上提供了这种通用性。缺乏通用性不仅使自动化变得困难，而且还会妨碍测试，常常会扭曲测试结果，因为如果环境不同，测试结果可能不具有代表性。

下面我们将在这些知识的基础上演示SOE如何为软件测试过程带来好处。