目录
摘要
关于我们生成的用于评估产品质量的数据，已有很多出版物发表。 很少有关于数据测试人员为自己使用而生成的讨论可以帮助我们改善工作的讨论，而关于数据收集的推荐做法的讨论则更少。 测试数据收集，管理并使用所有功能进行前期计划和持续维护。 测试人员可以通过以下方式改进这些做法。
内容
可以肯定地说，所有测试人员有时都嫉妒开发人员。 我不是在谈论关于缺乏尊重或被认为是第二职业的抱怨。 我说的是开发是一种生产活动。
编写代码，创建产品，当产品成功时，开发人员的工作与产品的存在之间存在直接的界限。 那我们的测试人员呢？ 我们创造的是什么？ 在黑暗的时刻，忧郁的到来，似乎我们什么也没创造。 但这是真的吗？
我认为我们创建了两个主要产品：错误报告和数据。 这些是我们工作的切实成果。 可以对它们进行计数，分类和分析。 所有其他术语都属于模糊不清且难以衡量的“产品质量”术语。
质量只能通过间接指标来衡量，即使这些指标有所提高，也很难证明这种改进是由于测试人员的工作所致。 也许是因为建筑师设计了如此出色的产品。 也许是开发人员，他们擅长编写高质量的代码（当然，我指的是修复我们发现的错误的代码...）。
关于编写有效的错误报告的重要性以及我们生成的用于评估产品质量的数据，已经发表了很多文章。 关于我们为自己使用而生成的数据（可以用来帮助我们改善工作的数据）的讨论很少，而关于数据收集的推荐做法的讨论则更少。
数据类型
在最基本的级别上，测试执行会生成一种主要数据类型：通过或失败的测试结果。 但是，还有许多其他信息可以收集：
- 测量：功耗，执行速度，CPU负载或内存使用率
- 测试环境的详细信息：处理器类型，内存大小，屏幕分辨率，硬盘驱动器的类型和大小，网络连接详细信息或操作系统，驱动程序和固件的版本
- 参与人员的详细信息：设置环境，编写测试用例，执行测试用例，检查结果并更新结果的人员
- 测试自动化系统的详细信息：所有框架组成的版本，远程执行测试时控制器PC的详细信息或重新测试的次数
- 测试生成的详细信息：测试时间或测试日志
ps: 业务系统实现的好坏，除了业务功能，稳定性要保证外，对测试人员的影响，端到端自动化实现的难易，甚至拼接入参时的难易
那只是部分清单。 这就是困境的开始：什么才有意义收集，我们应该多久收集一次，以及我们应该在收集上投入多少精力？
第一条规则是仅收集和保留数据，以便我们稍后知道如何处理。 否则，选项是无限的。
确实，这里存在一些风险：我们可能会错过那些看似无关紧要的数据对于某些分析至关重要的异常情况。 但这是例外。 通常，仅仅因为我们希望有一天我们能对它们做些事情而收集成堆的数字是没有意义的。 坦白说：我们没有足够的时间来分析我们清楚知道如何使用的数据，那么我们有什么机会找到时间来分析不知道该怎么做的数据？
话虽如此，如果收集一条信息既简单又便宜，那么我们也可能会收集它。 “简单又便宜”是指数据不会占用太多空间，并且其收集不会影响测试时间，不会加载被测系统，也不需要其他系统来保存和检索数据。 数据。
在测试执行期间，有许多此类数据可用于收集，这只是决定以有序方式保存它们而已。 一个很好的例子是测试执行时间，它很容易收集，并且可以保存在保存测试结果的同一数据库记录中。
一个相反的例子是测试计算机视觉系统。 来自摄像机的图像以每秒30帧的速度到达，有时甚至更快。 作为测试用例的一部分，我们在每个帧上计算一些指标； 对于此示例，假设我们计算了帧的处理时间。 我们应该收集每帧信息，因为在测试过程中已经可用了吗？ 仅一个测试用例，运行一分钟的视频，即可生成3600个结果。 当然，我们运行的不只是一项测试。 保存成千上万的数据点要求安装高速数据库并编写代码以帮助有效地加载数据。
一旦获得了所有这些数字，我们将如何处理它们？ 如果我们仅将它们用于计算平均，最小和最大帧处理时间，那么我们也可以在运行测试时即时计算这些时间，并仅保存这些统计信息。 当然，这是一种妥协。 如果我们确实保存了所有数字，则可以分析处理一系列长帧时处理时间的变化。 仅查看平均值时，我们将无法注意到这一点。 分析可能表明我们的算法很难处理特定类型的图像数据，这可能会导致算法的改进。 听起来确实很棒-如果我们能够进行分析的话。
关于收集和保存什么的决定并非易事。 太少了，我们以后会后悔的； 太多，我们将为收集越来越多的信息而付出昂贵的代价。
数据质量
确保数据正确是很重要的。 这似乎是一个显而易见的要求，但并非总是容易实现的。
首先，在收集数据时，循环中需要安装一些软件。 众所周知，软件不能完美运行。 此外，它是我们编写的软件，由于某种原因，一旦我们谈论我们的代码，我们往往会忘记它需要测试。 即使我们确实测试了代码，我们也从来没有像测试产品那样具有创造性的破坏力。 结果是，在很多情况下，我们的产品（数据）会遇到质量问题。
这是一些这样的例子：
- 测量：测量错误的东西，测量的定义有误（例如，平均值而不是最大值），以错误的频率进行测量或产生“探针效应”
- 测试环境的详细信息：缺少重要数据（例如，保存CPU类型但不保存L1缓存大小，或在受分辨率影响的测试中不保存屏幕分辨率）
- 参与人员的详细信息：记录谁应该执行测试，而不是实际执行测试的人
- 测试自动化系统的详细信息：不认为其中任何一个值得保存
- 测试生成的详细信息：过于冗长或过于神秘的日志，或难以自动分析的日志
数据收集
假设我们成功完成了前两个挑战：收集了所有重要数据，并且质量很高。 下一步是保存此数据。
我跳过了关于使用哪种类型的数据库以及哪种数据收集技术适合工作的讨论（这可能需要数周的激烈辩论）。 我建议不要花时间去弄清楚数据存储技术的细节，而是建议对预期的数据流进行清楚而详细的了解，并准确地定义我们将如何处理数据。 然后让系统人员（或DevOps）找出最能满足我们需求的技术细节。
在考虑技术方面之前，要对预期用途进行良好的定义。 这里有一些问题要问：
- 数据从哪里到达，谁将它们加载到数据库？ 出现问题时应该怎么办？ 我们如何避免数据丢失？ 我们可以容忍一定程度的数据丢失吗？
- 加载到数据库后，我们是否需要对数据进行更改？ 谁将被允许这样做？ 我们期望这种情况多久发生一次？ 我们是否需要对更改进行细致的记录？ 我们需要保留什么历史？
- 我们将如何提取数据？ 一天几次？ 我们将提供手动或自动摘录吗？ 什么音量 提取速度有多关键？
规划数据存储解决方案的另一个方面是与其他系统和数据库的连接性，并避免出现不一致的情况。 例如：
- 数据在许多系统中都是重复的，并且可以在每个这些系统中进行修改。 解决方案是否需要提供同步？
- 数据分布在许多系统上。 我们是否需要从多个来源提取和合并数据？ 可以通过建议的存储设计有效地做到这一点吗？
将数据分散到许多相关系统中会为许多小错误和可避免的小错误打开方便之门，除非从一开始就加以防止，否则它们会困扰并阻碍用户数年。 这是我遇到的两个例子。
一种是将测试结果收集到一个数据库中，然后移植到另一个数据库中。 在第一个数据库中，结果字段称为“结果”，而在第二个数据库中，结果字段称为“状态”。命名差异导致持续的误解和通信错误。
在另一种情况下，错误报告数据库中的字段用于记录发现错误的模块的名称。 该字段使用了模块名称的选择列表。 在测试用例管理系统中，每个测试都与其覆盖的模块相关联，再次使用带有模块名称选择列表的字段。 我将给您一个机会来猜测列表是否已同步，并且每个模块都有一个通用名称。
建立和维护支持系统的系统人员并不总是了解系统之间所需的连接。 作为用户，我们需要注意这些细节。
数据存取
数据收集正在创造我们的“产品”信息。但是，除非我们做一些有用的事情，否则信息本身就没有什么价值。为此，我们需要轻松访问数据。我认为可以肯定地说不会使用难以访问的数据。
有关如何存储数据的决定会影响访问数据的难易程度。从一个方面（例如，存储大小）有效的实施方案从另一方面（例如，数据检索时间）可能是无效的。这是为什么在定义技术解决方案之前定义我们计划对数据进行处理至关重要的另一个原因。
例如，某些数据库通过每次在记录中进行任何更新时都创建新记录来支持历史记录。其他人仅保留一条记录，并保留所有更改的痕迹。从存储的角度来看，第二种实现方式效率更高，但是重新创建过去记录的历史状态并不是一件容易的事。测试自己：在数据库中找到所有在某个时候未能通过确认测试并重新打开的bug，对您来说有多容易？
这是另一个例子。尝试使用大数据方法进行分析时，您需要能够从数据存储库中提取数百万条记录。有多容易？在大数据分析中，我们寻找数据之间不直观的联系，因此我们将希望提取所有可用字段。您的提取系统是否因为系统人员认为不重要的数据而隐藏了某些信息？
除了提取之外，测试人员还需要使用允许操纵大量信息的工具。任何尝试使用Excel对一百万行数据进行分析的人都得出结论，需要使用其他工具。此类工具的可用性是有意义地使用我们收集的数据的前提。
维护
即使我们进行了所有的前期分析并以惊人的细节定义了对数据存储的要求，我们始终会发现我们需要进行更改。我们认为必不可少的信息，而重要的信息却毫无意义。手动输入的数据没有我们希望的那样更新或准确。在选择列表中仔细选择的值对用户来说是模棱两可的。其他字段始终保持空白或使用默认值。即使是自动收集的数据也可能存在缺陷-错误的定义可能会导致准确性下降（例如，在数据为实数时将字段定义为Integer），或者某个日期无法加载或经常丢失。此外，随着时间的流逝，出现了新的需求，提出了新的想法，并且系统人员为添加和更改数据库的请求所淹没。
必须监视和管理所有这些活动。显然，有人需要在启动系统时检查数据是否正确加载，但是需要以一定的频率进行监视，以确保系统按计划继续工作。
有人需要讨论所有请求（有时彼此矛盾），并决定接受什么，系统可以支持什么，以及需要进行较大修改的内容。有人需要检查已定义的数据字段，并删除当时似乎是个好主意但未使用的字段。定义此管理活动非常重要：谁来拥有它，如何处理请求，谁是最终决策者以及谁确保我们收集的数据不仅仅是数字垃圾。
测试数据收集，管理并使用所有功能进行前期计划和持续维护。它不会自己发生，并且确认它正确有效地完成就可以确保测试活动的两个主要产品的有用性。
