可视化发现过程的时间顺序

#1 楼

更新：

我今天（几个月后）的答案是第一个问题，为什么？为了什么目的是的，我看到有人说您的笔记很难看懂。但是，尝试记录“发现过程”似乎并不容易或难以理解。我不确定这是否会给您想要的其他读者带来好处。
我将重点介绍如何使用更具体的指标（如我在下面列出的指标）以您描述的表格和图表形式显示最终结果。

上一个：
在考虑性能时，我并不认为这是一个未知的发现旅程。

我认为指导性能测试的关键因素应该是：


应用程序的响应时间标准是什么？
无线性能有哪些要求？
性能如何与关键指标（例如利润和注册人数）相关？
/>
可视化可以是Jira票证，图表，演示文稿，本地测试以及在CI / CD / Staging环境中进行的性能测试，这些环境被配置为准确表示生产机器和使用负荷。

考虑进行AB测试以了解性能水平如何影响用户。

#2 楼

它使用图形表示而不是表格表示的信息量最大的机制之一，它们可以具有多种格式，并且实际上包括多种格式通常是有用的，例如。维恩图显示为通过的测试次数着色的可能因素有时可以突出显示您尚未知道的因素的组合。同样，针对时间线的测试数量和通过测试数量的图表（带有测试设置的键）可能非常强大，因为可以立即清楚地看到，在给定区域的特定日期之前尚未完成测试/可能。某些3-D图类型也可能是理想的。

理想情况下，您不应为此使用电子表格，因为您将不断手动对其进行更新。我个人比较喜欢使用诸如Jenkins之类的工具进行持续集成和测试，使用SVN / Git / Hg进行版本控制以进行测试以及代码，测试脚本等。您可以在测试中使用python和标签之类的工具脚本和结果输出以生成摘要，例如针对每个标记的测试数量和针对每个结果的测试结果，并将其保存到日期索引文件中，一些测试工具可让您定义可用于此目的的元字段，而其他工具如果使用的工具不允许，则允许您存储/解析标签的注释，如果使用的工具不允许，则应该有一个测试标识符，可以在标签表中使用索引支持这些工具中的任何一个，那么我建议您尽快停止使用该工具，因为它缺乏任何可追溯性。

一旦有了数据，就可以使用matplotlib，bokeh，plot.ly等工具为您的每日/每周/等自动生成图表。报告-如果您使用的是CI，则甚至可以在每次提交的基础上更新图表。

本文还提供了一些有趣的阅读材料。

#3 楼

在将我们项目的测试方法转变为一种我在其他地方看不到但又发现更多有意义的形式之后，我发现，令我高兴的是，它与应用程序的“需求”完全吻合。

我不应该详细介绍该表格，但我的发现似乎是您所做努力的答案。首先，我开始将测试用例中的每个“验证”步骤（无论它们是否是探索性的）都称为“动作-反应”对。下一步是自然地将每个验证定义为“性能目标”，即性能要求。

我现在将每个需求都视为性能需求，我们可以放心地将其称为“需求”。下一步是将性能指标或组分配给“每个”需求。

现在，如果我回到您的问题，我认为测试的“探索性”或有向图结构从尚未确定的需求（这比许多人想的要普遍，或者实际上是设计过程的自然方式）。

最后一个假设，我建议您只返回表格报告（或分层结构，具体取决于需求的结构），然后将探索性测试的任何发现作为新项目添加到该集合中。当然，定义探查的图形结构的需求是真实的，但是与确定产品版本的“质量”无关。

#4 楼

因此，如果我了解您在做什么，我可能会以这种方式看待它：

开始时，您将拥有无限的可能性。您拥有可以使用的不同类型的硬件，可以使用的不同级别的软件，也许不同的后端，也许不同的数据访问模式等。并且您在进行实验时正在缩小可能性，直到找到根据您对最佳的定义，一个或几个是“最佳”的。

所以我会这样介绍。我从这个n维空间开始。在每次实验中，我都以某种方式缩小了空间，或者可能以某种方式扩大了空间。

在尝试做相同的事情时，您可能会看到一种称为模拟退火的东西，它是在许多可能性中找到全局最优值。

#5 楼

事实是（大多数）人们不喜欢阅读冗长的报告。他们想要的只是一个问题的答案。因此，请简要介绍一下，重点是介绍数据的结论和含义，而不是实际数据。您做了什么，如何做，对收集到的数据的结论（即答案），风险，未回答的问题（项目关心的更多需要答案的事物），最重要的错误。

您不会提供任何细节，例如项目结构，您要向谁报告，是否有任何帮助者，您自己可以决定什么是好还是坏的价值，我想知道这些可能或可能无法更好地回答您的问题。