如何跟踪性能测试
我目前做的性能和复杂的多层次的系统研究的不同变化的影响的负载测试，但我有藏在心里的跟踪问题：如何跟踪性能测试
-
有不同的组件
- Orignally释放组件
- 正式发布的修补程序
- 组件是我的许多副本已经建立含有其它附加修复
- 装配体，我已经含有额外的诊断日志记录或跟踪构建
- 有许多数据库补丁，上述某些组件的依赖于某些数据库补丁施加
- 存在许多不同的日志记录级别，在不同的层次（应用程序日志记录，应用程序性能统计，SQL服务器分析）
- 有许多不同的情况，有时仅测试1个场景很有用，其他时间我需要测试不同场景的组合。
- 负载可以在多台机器或仅单个机器
- 存在于数据库中的数据被分割可以与从拍摄数据稍后更改，例如某些测试可能与所生成的数据来完成，然后现场系统。
-
有每个测试后收集潜在的性能数据的巨量，例如：
- 许多不同类型的应用程序特定的日志记录
- SQL事件探查器跟踪
- 事件日志
- DMV
- Perfmon计数器
- 数据库有几个千兆位的大小因此，如果我将使用备份恢复到以前的状态，我倾向于在最后一次测试后对所存在的任何数据库应用更改，这使我很快无法跟踪事情。
我收集了尽可能多的有关每次测试的信息（测试场景，哪些补丁应用了数据库中的数据），但由于结果不一致，我仍然发现自己必须重复测试。例如，我只是做了一个测试，我认为它与我几个月前运行的测试完全相同，但是数据库中有更新的数据。我知道一个事实，即新数据应该会导致性能下降，但结果却显示出相反的结果！
与此同时，我发现自己在分配这些所有这些细节的时间数量不成比例。
我考虑的一件事是使用脚本来自动收集性能数据等，但我不确定这是一个好主意 - 不仅是花时间开发脚本而不是测试，但是我的错误脚本可能会导致我更快地追踪事物。
我对如何更好地管理测试环境提出了一些建议/提示，尤其是如何在收集所有东西之间取得平衡并实际完成一些测试，以避免丢失重要的东西？
脚本化测试参数+环境的集合是一个很好的办法。如果你在几天内进行测试，并且脚本需要一天的时间，那么花费时间。如果过了一天，你会发现它不会很快完成，重新评估并可能停止追求这个方向。
但你欠它自己去尝试一下。
我倾向于同意@orip，脚本至少部分工作量可能会节省您的时间。您可能会考虑花一点时间来问一下，在您的劳动力方面哪些任务是最耗时的，以及他们对自动化的适应性如何？脚本特别擅长收集和汇总数据 - 通常比人们更好。如果您的表现数据需要大量的解释，那么您可能会遇到问题。
对这些任务进行脚本编写的一个好处是，您可以在源代码/补丁程序/分支中检查它们，并且您可能会发现自己受益于系统复杂性的组织结构，而不是像你一样努力追赶它现在。
如果您只能测试一些可以让管理员变得简单的设置配置，就可以避开测试。它也可以让一个虚拟机可以快速重新部署，以提供干净的基线。
如果你真的需要你描述的复杂性，我建议建立一个简单的数据库，让你查询你有多元的结果。为每个重要因素设置一个列将允许您查询“什么样的测试配置具有最低的延迟变量？”等问题。和“哪个测试数据库允许提高大多数错误？”。对于这种轻量级集合，我使用sqlite3（可能是通过Python包装器或Firefox插件），因为它使维护开销相对较低，并且允许您避免让被测系统过分干扰，即使您需要运行同一个盒子。
脚本化测试将使他们更快地执行并允许以已经排序的方式收集结果，但听起来您的系统可能太复杂而难以实现。