自动软件测试让您可以在一段时间内运行相同的测试，从而确保您所比较的内容具备真正的可比性。在本文中， Linux Test Project 团队的成员们分享了他们对 Linux? 内核进行压力所使用的测试的方法、原理以及脚本和工具。 在对 Linux 内核版本稳定性的测试中，需要明确地声明并证明为什么版本是稳定的或者是不稳定的。 然而还没有被证明和证实当前现有的系统范围内的压力测试可以测试 Linux 内核整体上的稳定性。 本文给出了一个创建系统范围内 Linux 压力测试并证明其结果正确性的方法。不同的 Linux 开发者、 用户和发行版本会使用他们自己的方法来测试内核的稳定性。不过，关于他们决定运行哪些测试、覆盖的代码、 达到的压力级别等的基础信息都没有发布，这就大大降低了结果的价值。 使用实验室的机器以及来自 Linux Test Project 测试套件的测试，我们基于系统资源的利用率统计开发了一个 测试的组合，为系统提供足够的压力。我们对这个组合测试进行了分析，以确定 Linux 内核的哪些部分在测试 执行中得到了使用。然后，我们修改了组合测试，在保持期望的高强度系统压力的同时提高代码覆盖率的百分比。 最终得到的压力测试涵盖了 Linux 内核的足够多部分，有助于稳定性声明，并且有系统使用情况和内核代码覆盖情况的数据来支持它。 这一组合测试方法的四个步骤是：测试选择、系统资源利用率评价、内核代码覆盖分析以及最终的压力测试评价。
选择测试 测试选择包括选择达成两方面目的的测试： - 测试应该可以得到 CPU（s）、内存、I/O 和网络等主要内核区域的高水平的资源利用率。 - 测试应该充分地覆盖内核代码，以帮助支持自其结果中生成的稳定性声明。 只要有可能，都要使用自动化的或者易于修改的测试，以支持自动操作。自动操作可以使得测试 更快而且可以重复进行，并帮助降低人为错误的风险。选择合适的测试时需要考虑的另一个方面是， 使用可以自由发布结果的应用程序。最好是选择坚决拥护开放源代码方法 和/或 GPL 的测试和测试套件，以助于确保 发布过程的简便。
评价系统资源利用率 所选择的测试的组合必须给系统的资源带来足够的压力。Linux 内核的四个主要方面可以影响系统的 响应和执行时间： - CPU：用于在机器的 CPU（s）上处理数据的时间。 - Memory：用于自真实存储器中读写数据的时间。 - I/O：用于自磁盘存储器读写数据的时间。 - Networking：用于自网络读写数据的时间。 测试设计者应该使用下面这两个著名的且广为应用的开放源代码 Linux 资源监控工具来评价资源利用率水平。 （请参阅本文稍后的 参考资料 以获得下载这些工具的链接。） - top：由 Albert D. Cahalan 维护着的一个开放源代码工具， 包含于大部分 Linux 发行版本中，可用于当前的 2.4 和 2.6 内核。 - sar：另一个开放源代码工具；它由 Sebastien Godard 维护。 这个工具也包含于大部分 Linux 发行版本中，可用于当前的 2.4 和 2.6 内核。 方法中的系统资源利用率评价阶段通常需要多次尝试才能得到合适的测试组合，并得到期望水平的利用率。 当确定测试组合时，过度利用总是一个至关重要的问题。例如，如果选择的组合过于受 I/O 所限，可能会 导致 CPU 的测试结果不好，反之亦然。方法的这一部分主要是大量的试验和出错，直到所有资源达到期望 水平。 top 工具可用于迅速确定每个测试影响哪个资源（CPU、内存或者 I/O），并实时地显示出它们使用了多少资源。 sar 工具用于收集一段时间内的网络利用率统计数据，并将所有利用率数据的快照记录到一个文件。 当选定一个组合后，测试必须长时间运行以准确评价资源的利用率。测试运行的时间长短取决于每个测试的长度。 假如多个测试同时运行，则时间必须足够长以使得这些测试中最长的那个可以完成。在这个评价过程中，sar 工 具也应该在运行。在评价运行的结论中，您应该收集并评价所有四种资源的利用率水平。 下面的例子显示了 sar 输出的 CPU、内存和网络利用率： 清单 1. sar 的输出示例 10:48:27 CPU %user %nice %system %iowait %idle 10:48:28 all 0.00 0.00 0.00 0.00 100.00 10:48:29 all 3.00 0.00 1.00 0.00 96.00 10:48:30 all 100.00 0.00 0.00 0.00 0.00 10:48:31 all 100.00 0.00 0.00 0.00 0.00 02:27:31 kbmemfree kbmemused %memused kbswpfree kbswpused %swpused 02:29:31 200948 53228 20.94 530104 0 0.00 02:31:31 199136 55040 21.65 530104 0 0.00 02:33:31 198824 55352 21.78 530104 0 0.00 02:35:31 199200 54976 21.63 530104 0 0.00 02:27:31 IFACE rXPck/s txpck/s rxbyt/s txbyt/s 02:29:31 eth0 738.79 741.66 76025.55 136941.85 02:31:31 eth0 743.30 744.97 76038.82 136907.77 02:33:31 eth0 744.80 745.02 76135.53 136901.38 02:35:31 eth0 742.35 744.34 75947.45 136864.77
分析内核代码覆盖率 获得足够的内核覆盖率是系统压力测试的另一个职责。尽管所选的测试组合充分地利用了四种主要资源，它 也有可能只是执行了内核的一小部分。因而，您应该对覆盖率进行分析以确保组合可以成为一个系统压力 测试，而不是一个系统负载生成器。当前，有两个开放源代码工具可以帮助进行 Linux 内核的代码覆盖率分析： - gcov：一个由 Linux Test Project 维护的开放源代码工具。 这个工具分析内核代码的覆盖率，并报告哪些行、函数和分支被覆盖以及它们被访问了多少次。 - lcov：另一个由 IBM 开发，由 Linux Test Project 维护的开放源代码工具。 这个工具由一组构建于基于文本的 gcov 输出之上的 Perl 脚本构成，以实现基于 Html 的输出。 输出包括覆盖率百分比、图表以及概述页，可以快速浏览覆盖率数据。您可以自 Linux Test Project（LTP）主页 找到这两个工具（参阅 参考资料 以获得链接）。 gcov 模块加载以后，所有运行于系统压力测试组合中的测试都必须执行。尽管原来的系统压力测试可以同时执行， 也应该同时执行，但是这次运行应该是循环进行的。每个测试都应该运行一次直到结束，一个接一个地运行， 不能重复运行任何测试。单个地、循环地运行，是为了减少在同时运行多个系统压力测试时，内核尝试 去平衡它们的负载而导致的不可预知的和无目的的内核代码执行。您应该在最后一个测试运行结束后再进行 gcov 分析。由于最终是要格式化数据以进行分析，所以运行 lcov 工具并?载 gcov 模块。 lcov 工具会生成一棵完整的 HTML 树，其中包含有内核中代码的每一行以及关于每一行执行了 多少次的数据（如果有的话）。这个工具会量化覆盖率数据并生成关于内核中每一部分和 文件覆盖率的百分比数字。下面的例子展示了一个示例性的代码覆盖率输出： 图 1. gcov 输出示例 lcov 维护者定义了“足够的覆盖”（绿色的），因而这个 lcov 示例仅仅是一种评价。不过，所包括的 原始数据让任何浏览者都可以做出他或她自己的判断。在浏览了覆盖率分析后，测试创建者现在可以修改 测试的组合，以改变 和/或 增加所覆盖的代码的数量。
评价最终压力测试 之所以要执行方法中的这最后一步，是为了对系统压力测试进行核实。在一个被认为是稳定的内核上执行压力测试； 通常，发行版本中的内核可以满足这一要求，但不总是如此。要长时间地执行压力测试（推荐至少 24 个小时），同 时运行 sar 工具，原因有以下两点： - 长时间运行有助于发现组合中的所有问题，否则，在短时间的“取样测试（sniff test）”中这些问题可能会被忽略。 - sar 生成的数据构成以后测试运行中进行比较的基线。 长时间运行结束后，您现在可以基于收集的所有数据来决定这个测试组合是否是系统压力测试的合适候选者。 图 2. 设计过程总结 Linux Test Project 在设计 Linux 内核压力测试脚本 ltpstress.sh 时使用了这一设计方法。 这个应用程序组合了来自 LTP 的测试套件不同方面的多个测试以及内存和网络传输负载生成器。 在执行之前，测试会根据系统中存在多少物理和虚拟内存来调整其总的内存使用情况。这个测试 脚本可以自 LTP 测试套件获得（见 参考资料）。为了确保结果的 准确性，这个脚本创建于受控的实验室条件下。 IBM Linux Technology Center Test 部门使用这个压力测试以及其他工具和测试作为帮助确认 Linux 内核发行版本稳定性的一个相对快速和简便的途径。为帮助确保得到足够的覆盖率，测试既 在实验室条件下也在模拟的用户情形下进行。
[1] [2] 下一页
（出处：http://www.sheup.com）
上一页 [1] [2]