自测试系统

Question

我有个想法，我正在和一些同事商量。我们都不知道它现在是否存在。

基本前提是系统具有100%的正常运行时间，但可以动态地提高效率。

这里是这样的场景：*，所以我们快速地将系统分解到指定的一组接口上，它具有零的优化，但是我们确信它是100%稳定的，尽管(不确定，但为了这个场景，请配合)*然后我们分析原始类，并开始对瓶颈进行程序替换。*原始和替换同时启动并同步进行。*原件允许运行至完成:如果替换尚未完成，则系统将其否决为对原件的替换。*更换时必须在指定的次数和特定的数值范围内，始终返回与原值相同的值，然后才可作为原始值的替换。*如果在采用替换后发生异常，系统将自动尝试对被替换的类进行相同的操作。

你在实践中见过类似的概念吗?请评论.

下面的是关于帖子的最初问题之后写的评论：*系统演示了一种达尔文式的系统进化方法。*原始和替换将并行进行，而不是串联进行。*种族状况是多线程应用程序固有的问题，我对此表示感谢。

Answer 1

我认为这是一场有趣的理论辩论，但由于以下原因并不十分实际：

1. 为了确保新版本的代码运行良好，您需要进行出色的自动测试，这是一个很难实现的目标，也是许多公司无法开发的目标。只有在这样的自动测试就绪之后，您才能继续实现系统。
2. 这个系统的全部要点是性能调优，也就是说，一个特定版本的代码将被一个在性能上取代它的版本所取代。对于今天的大多数应用程序来说，性能是次要的。也就是说，大多数应用程序的总体性能都足够了--想想看，你可能很少会发现自己抱怨“这个应用程序太慢了”，相反，你通常会发现自己抱怨自己缺乏具体的功能、稳定性问题、UI问题等等。即使你抱怨速度慢，它通常是你的系统的整体缓慢，而不仅仅是一个特定的应用程序(当然也有例外)。
3. 对于性能是一个大问题的应用程序或模块，改进它们的方法通常是识别瓶颈，编写新版本，并且首先使用某种基准测试独立于系统进行测试。当然，对整个应用程序的新版本进行基准测试也是必要的，但总的来说，我认为这个过程只会发生很小的次数(遵循20%-80%的规则)。在这些情况下，“手动”执行此过程可能比所描述的系统更容易，成本效益更高。
4. 当您添加特性、修复与非性能相关的bug等时，会发生什么？你不能从系统中得到任何好处。
5. 同时运行这两个版本来比较它们的性能所遇到的问题比您想象的要多得多--不仅您可能有竞争条件，而且如果输入不是一个适当的基准，您可能会得到错误的结果(例如，如果您得到大量的小数据包，并且在90%的时间内输入是大数据包)。此外，这可能是不可能的(例如，如果实际的代码更改了数据，则无法联合运行它们)。

唯一的“环境”，这听起来有用，实际上是“必须”是一个“遗传”系统，产生新版本的代码本身，但这是一个完全不同的故事，并没有真正广泛适用.

Answer 2

在运行过程中运行性能基准的系统将比不运行的系统要慢。如果目标是优化速度，那么一旦证明运行速度更快，为什么不独立测试并导入最快的例程呢？

同时启动例程的想法可以引入种族条件。

另外，如果目标是确保100%的正常运行时间，您将不希望引入未经测试的例程，因为它们可能会生成不可捕获的异常。

也许您的想法作为基准测试的工具，而不是操作系统，有其优点？

Answer 3

在实践中，我有否见过类似的概念？不是的。但无论如何我还是会提议一个办法。

似乎您的大部分目标都是由某种超级源代码控制系统来实现的，它可以用CruiseControl实现。

CruiseControl可以运行单元测试以确保新版本的正确性。

您必须编写一个CruiseControl构建器插接，它将针对一系列现有的基准测试执行系统的新版本，以确保新版本是一个改进。

如果CruiseControl构建循环通过，那么新版本将被接受。这一进程需要相当大的努力才能实施，但我认为这是可行的。单元测试和基准构建程序必须相当精巧。