3

我目前正在对复杂的多层系统进行性能和负载测试，以调查不同更改的影响，但我在跟踪所有内容时遇到了问题：

  • 有许多不同程序集的副本
    • 最初发布的组件
    • 正式发布的修补程序
    • 我构建的包含更多附加修复的程序集
    • 我构建的包含附加诊断日志记录或跟踪的程序集
  • 有许多数据库补丁，上面的一些程序集依赖于正在应用的某些数据库补丁。
  • 存在许多不同的日志记录级别，位于不同的层（应用程序日志记录、应用程序性能统计信息、SQL 服务器分析）
  • 有很多不同的场景，有时只测试一种场景很有用，有时我需要测试不同场景的组合。
  • 负载可以分布在多台机器上，也可以只分布在一台机器上
  • 数据库中存在的数据可能会发生变化，例如，一些测试可能会使用生成的数据进行，然后使用从实时系统中获取的数据。
  • 每次测试后都会收集大量潜在的性能数据，例如：
    • 许多不同类型的特定于应用程序的日志记录
    • SQL 事件探查器跟踪
    • 事件日志
    • 车管所
    • 性能计数器
  • 数据库有几个 Gb 大小，所以我会使用备份恢复到以前的状态，我倾向于在上次测试后对任何存在的数据库应用更改，这导致我很快就失去了对事物的跟踪。

我尽可能多地收集关于我所做的每个测试的信息（测试的场景，应用了哪些补丁，数据库中有哪些数据），但由于结果不一致，我仍然发现自己不得不重复测试。例如，我刚刚做了一个测试，我认为它与几个月前运行的测试完全相同，但是数据库中的数据已更新。我知道新数据应该会导致性能下降，但结果却恰恰相反！

与此同时，我发现自己花费了不成比例的时间来记录所有这些细节。

我考虑过的一件事是使用脚本来自动收集性能数据等......，但我不确定这是一个好主意 - 不仅花时间开发脚本而不是测试，而且我的脚本中的错误可能会导致我更快地追踪事物。

我正在寻求一些关于如何更好地管理测试环境的建议/提示，特别是如何在收集所有内容和实际完成一些测试之间取得平衡，以免遗漏一些重要的东西？

4

3 回答 3

0

编写测试参数集合+环境的脚本是一个非常好的检查方法。如果您要进行几天的测试，而脚本编写需要一天时间，那么就值得花时间。如果一天后您发现它不会很快完成，请重新评估并可能停止追求这个方向。

但你应该自己尝试一下。

于 2009-09-09T21:31:47.437 回答
0

我倾向于同意@orip，至少编写部分工作量的脚本可能会节省您的时间。您可能会考虑花点时间询问哪些任务在您的劳动力方面最耗时，以及它们对自动化的适应性如何？脚本特别擅长收集和总结数据——通常比人好得多。如果性能数据需要您进行大量解释，您可能会遇到问题。

为其中一些任务编写脚本的一个优点是，您可以将它们与源/补丁/分支一起签入，您可能会发现您从系统复杂性的组织结构中受益，而不是像现在这样努力追逐它。

于 2009-09-10T16:17:06.453 回答
0

如果您可以仅针对一些设置配置进行测试，这将使管理员保持简单。它还可以更轻松地在多个虚拟机中的每一个上放置一个，这些虚拟机可以快速重新部署以提供干净的基线。

如果您真的需要您描述的复杂性，我建议您构建一个简单的数据库，以允许您查询您拥有的多变量结果。为每个重要因素设置一列将允许您查询诸如“什么测试配置的延迟差异最小？”之类的问题。和“哪个测试数据库允许引发大多数错误？”。对于这种轻量级集合，我使用 sqlite3（可能通过 Python 包装器或 Firefox 插件），因为它使维护开销相对较低，并且允许您避免过多地干扰被测系统，即使您需要运行同一个盒子。

编写测试脚本将使它们更快地执行并允许以已经排序的方式收集结果，但听起来您的系统可能太复杂而无法轻松完成。

于 2009-09-11T06:37:03.927 回答