我们从3000个错误报告中学到了什么
原来，下午2点是报告错误的黄金时间。有趣的是，到早上9点，活动一直在增长，然后一直到下午，在下午2点达到顶峰。在5处还有一个局部峰值。很难确定为什么会这样。可能的解释是，有些人在工作日结束之前进行了一系列测试。这将我们带到了下一个点-工作时间。软件开发界是否有像标准工作日这样的事情？事实证明-并非如此。我们比较了常规9到5内上传的录音数量，而不是其他时间。
分裂几乎相等，起初让我们有些惊讶。当您查看之前的K线走势图（按小时报告的错误）时，在正常工作日似乎有更多活动。因此，您不会期望几乎完美的50/50分布。不过，解释非常简单-9比5仅为一天的1/3。因此，剩余时间是小时的两倍，但是错误报告的速度要低两倍。这就提出了一个问题：如今，产品团队中的人员是否更加灵活？还是我们工作时间更长，应该重新考虑我们的习惯？
在星期二提交四分之一的错误报告
我们希望人们在周五和周末提交的错误报告少于一周的其余时间。该假设被证明是正确的。我们没想到的是，前两天的活动量会更高。我们的假设是星期一，星期二，星期三和星期四之间几乎没有差异。
在预生产环境中报告了2/3的错误
根据Capers Jones在2009年进行的一项研究，在代码投入生产之前，已经捕获了85％的错误。今天是这样吗？
在我们的特定样本中，在预生产环境（本地和暂存）中报告了大约2/3的错误。这个数字低于Capers Jones最初的研究。
可能的原因之一可能是不同的用户组。尽管Capers Jones似乎主要专注于软件开发团队，但我们的产品不仅被工程师，质量保证，项目经理和设计师所使用。例如，我们看到客户支持团队的活动在增加。这意味着两件事。首先，业务和运营角色通常不使用登台，因此它们只能报告生产中的错误。其次，他们可能将某些东西报告为错误，实际上并不是错误。即使是一个从内而外地了解产品的人，也无法每次都立即分辨出是否确实存在错误。某些行为可能是由设置难以找到，广告拦截器或连接问题引起的。
我们不能肯定地说，这种假设是否可以正确解释试生产环境中报告的错误数量有20％的差异。影响因素很多：公司规模，开发方法（敏捷/瀑布），质量保证流程，业务逻辑的复杂性，甚至是特定公司如何将其定义为错误。
错误报告中“ Bug”是最常见的词
在该练习中，我们使用了错误报告的标题来创建词云并查看最常见的主题。
结果证明是相当可预测的。诸如Bug，Error，Page，Test之类的词是最常见的。坦率地说，我们并不希望“收藏”和“日期”如此频繁-可能是由于样本所致。
下一步，我们删除了排名最高的7个单词，以更好地理解小组中的其他成员。现在更明显的是，形容词和动词也在列表中。尽管如此，大多数单词还是名词。
我们发现最有趣的，并且以非常积极的方式，是什么单词不在列表顶部。根据个人经验，我们知道有时人们会以非常笼统的术语来描述错误，即“什么都没有用”，“ X损坏了”。为了帮助公司避免这种情况，我们甚至创建了一个错误报告模板，以帮助特别是非技术人员更好地交易所错误。但是，在我们的样本中，这种行为很少见。
大多数错误报告都是使用macOS制作的 
尽管macOS仅占普通市场的17％，但它仍是bug报告者中最受欢迎的选择。使用此操作系统进行的错误报告数量超过Windows和Linux的总和。难道是因为macOS使您生产力更高吗？
最近两个月的大部分使用情况来自以前版本的macOS（Mojave）。最近，尽管您看到了Catalina的更多活动，
我们在Windows上拥有的数据粒度要小得多。我们只能说几乎所有录音都是使用Windows 10上传的。
Google向Chrome用户提供最新软件
目前，我们的产品仅在Chrome上得到正式支持，这就是为什么我们决定排除有关其他浏览器的信息的原因。但是，我们可以说Chrome约占我们网站流量的80％，其次是Firefox和Safari。
我们数据中心化最早的错误报告已有2个月的历史了。同时，其中很少有来自4个月前发布的Chrome版本。 Google似乎在确保用户升级到较新版本方面相当出色。我们只能建议将此策略作为最佳做法-它使调试变得更加容易。它还可以确保更统一的用户基础，这不仅对软件开发团队有积极影响，而且对技术支持也有积极影响。
错误错误。测试收集日期问题。最后，我们决定采用已有的数据并创建您最有可能看到的错误报告。为此，我们将本文中的信息与上图中未包含的数字进行了组合。
这是-今年秋天最“平均”的错误报告。
标题：错误错误。测试收集日期问题。
- 时间：星期二下午2点
- 环境：暂存
- 作业系统：macOS 10.14.6
- 设备供应商：Apple
- 浏览器：Chrome 77
- 屏幕尺寸：1920×1080
- 视窗尺寸：1920×798
- 语言环境：美国