这是个人成长的进步。 测试人员需要跟踪报告的错误数量，错误的严重程度以及报告的日期。 这有助于跟踪他们所覆盖区域的模式，每周的最高生产率以及他们对项目的贡献量。
他们需要跟踪的主要事情是报告的许多错误与返回的“需要更多信息”或“问题” 的许多错误 。 这将有助于跟踪报告的错误的质量。 这在测试人员的生活中很重要，因为它揭示了两件重要的事情：
- 该错误没有道理
- 测试人员不知道这是错误还是功能
第二部分是更大的担忧，因为测试人员没有知识转移，因此他/她没有游戏权。 作为测试人员，我们有望成为游戏和与之合作的工具的大师。 这方面的任何问题都显示出弱点，并没有激发开发人员的信心。
这必须是测试人员和开发人员最具挑战性的辩论。 即使A类错误很重要，也无需修复。 现在，假设玩家进入了汽车，将其开到港口，乘船，将角色钩在飞机上，跳下并偷了一辆自行车，然后撞到了撞墙的游戏。 此错误的严重性为A类。 但是，请考虑有多少游戏玩家在重现此错误时会尝试相同的特技。 这将少于错误发现此问题的游戏玩家的8％。 如果他们重新加载游戏，并且保存进度仍保持原样，那么他们甚至不必理会这个问题。 考虑所有具有严格时间表或时间表的游戏。 当游戏即将发行时，这种可能性很小的问题将被忽略。 在频谱的另一端，如果玩家选择桥的左侧越过，屏幕将保持空白5秒钟，那么玩家仍然有50％的概率面对它。 这不是A类问题，但由于游戏者面临该问题的可能性仍然很高。 对于最终用户的整体游戏体验而言，此问题尤为重要。
因此，问题的优先级确实迈出了第一步。 整个开发团队都致力于在发布日期发布产品，同时保持最高质量。 我们需要尊重一个事实，即每个人都在特定的时间表上工作。 作为质量检查成员，我们需要关注会改变最终用户体验的问题 。 这并不意味着测试人员不会报告所有极端情况问题 。 作为测试人员，我们的主要职责是报告遇到的任何问题。
当我们发现错误时，不一定是发现错误的最佳方法。 遇到错误时，我们可能正在测试游戏中的其他功能。 测试人员必须足够了解错误的最终原因， 然后追溯导致错误的实际步骤 。 在这种方法中，我们遇到了导致此问题的其他几种可能性。 我们可以采用最简单的形式来重现该错误。 这还将教会我们该错误的根本原因。
示例：在计算器应用程序上，如果我执行2 * 5，则崩溃了。 尽管这种情况可能是正确的，但它可能仅在此计算中修复了该错误。 但是如果我做了10 + 0、20-10、200-190、20 / 2等，我会发现同样的问题。 最终结果证明该应用程序有问题，结果是10，而不是2 * 5。 因此，请对该问题进行研究并提出替代方案。 这将始终有助于缩小问题的范围 。
这很重要，不仅可以简短地解释该错误，而且还可以帮助其他测试人员检查是否记录了错误。 大多数数据库搜索字符串都涉及先查看摘要 。 如果对摘要进行了优化，则测试人员将花费更少的时间来查找问题，而不是记录问题。 摘要必须清晰，准确，并在句子中包含所有重要信息。
在编写摘要时，要知道问题始终优先于其他因素，例如位置，游戏模式，用户级别等。这将有助于缩小问题范围，并为要查找该问题的任何其他测试人员创建参考点。
大多数测试人员都忽略了这一点。 对于我来说必须要强调这一点，以上提到的替代复制率至关重要。 仅仅因为发现问题并不意味着它取决于代码或艺术。 还有其他一些因素。 后台的硬件或任何软件可能存在问题，会引起干扰。 这似乎不是您所希望的错误，但它的重量是黄金的10倍。 任何导致正在运行的游戏出现问题的后台应用程序/硬件，开发人员都将花费更多的时间来解决此问题，因为他们不希望用户被剥夺任何其他应用程序来容纳游戏。 这可能是一件大事，因为大多数用户会归咎于游戏，而将其留给应用程序。 这可能会对游戏造成巨大的负面影响，大多数开发人员倾向于避免处于这种状态。
相关：进一步了解我们的游戏测试服务
由于此博客倾向于集中讨论编写错误时需要解决的问题，因此不一定强制执行错误的编写方式。 测试人员可以完全控制错误中需要传达的内容。 本文所要覆盖的全部事实是，在传递正确的消息时，错误可能会更加强大。 请遵循以下步骤并相信它，因为它可以作为展示思想过程的有用方法。 它不仅可以帮助您编写错误，而且可以帮助您提出想法。
喜欢博客吗？
请不要忘记发表评论
