神秘的游戏测试到底做什么，你知道吗？ - 51Testing软件测试论坛

BUG记录文档定义：对测试过程中产生的问题与优化，进行记录，包括问题描述，验收状态，负责人，紧急程度与截图等。BUG记录文档在测试过程中起到了尤为关键的重要，它不仅能帮助记录所发现的问题方便再次测试，更能够对相应的问题与需求进行记录，方便后来人员查阅或加快回归测试的复盘。记录BUG文档时要求对问题的描述通俗易懂且记录最关键点，这样程序端能够更快地读懂BUG所在，也能方便自己再次复现问题。对于解决的问题标记为绿色，未确认的问题标注黄色，未修复的问题维持白色。负责人的记录则方便后期重现bug找到对应的负责人。截图有时也尤为重要。分为两种截图，一种是BUG截图一种是策划需求截图。BUG截图方便对应记录BUG出现时的截图。策划需求截图则方便策划“推锅”时拿出来“打脸”，虽说用处不大，但必要时还是可以肃清需求来源。

BUG归档与分类从名字开始。文档的命名方式影响着后续的查询。一般BUG文档的命名包括功能名称，测试人员与测试时间。具体模板可以为“【测试】xxx功能测试点-xxx人名-日期”。而功能名称xxx可以具体细分增加类似“精彩活动”或“副本”等标记，这样后面的查询搜索也变得简单。复查类文档与外文版本文档的命名都有各自的格式。复查类文档命名格式为“xxxx功能UI复查”，外文版本文档的命名则一般以“xx服版本更新检查”命名为主。而这里说到的BUG文档分类，其实记录格式都差不多，只是在记录的方式有所不同。一般BUG文档与复查类文档多以文字列举所有BUG，并加以截图说明。外文版本文档则以截图为主，简单的文字告知前端对应的功能所在。归档则是通过不同文件夹对文档进行存放，一般以时间加以分类。不同时间记录着不同开发周期段所产生的的bug文档。如果更加仔细，还可以将所有BUG文档汇总，更加直观的收集全文档。

对于策划的口头需求与“一时兴起”型需求，能及时截图就及时截图，不能截图则用文字记录。这不仅仅方便后期更改需求时的对照，也能够记录对应不同版本的不同需求。截图或文字可放在BUG文档中，对应不同功能也方便查阅。

在测试过程中，每个功能点都会对应相应的功能文档与BUG文档，如何将这些文档更好地归类也是关键。一般如果是手动记录，会利用版本时间作为划分类别的主键，每个版本文件夹里，可以收纳功能文件夹与BUG文件夹，分别存放此版本所有功能相关文件与对应的BUG文档。后面回归测试时会很方便。

外服一般会开启第一轮第二轮等付费或非付费测试。每一次测试如果按照正统流程，都会产生对应的测试记录文档。文档一般包括：用户属性，战力统计，进度统计，付费模块统计，意见与建议，BUG统计等模块，详细与系统地记录测试过程中出现的问题与想象。这些文档有利于数值大佬进行分析，也有利于系统策划对游戏规则进行修正与优化，从而更有利于游戏的优化与下次测试版本的版本质量。

主策划与各功能策划会在游戏内部测试或外部小范围测试时深入体验游戏并得出功能BUG与相应的优化方向。测试结束后项目主管或主策划会对所有收集到的问题进行总结并形成外服策划BUG统计文档。一般这个文档会包含几百条问题描述与相应的功能负责人。如果有条件的情况下，可以要求策划记录下当时出现问题时的状态截图或视频录制。因为有些问题如果没有现场可看，解决起来也会很抽象。所有问题通过对应的程序修复完后，再由测试人员一一检查测试，并标记验收状态。针对无法重现的问题或其他疑难杂症，可以暂时跳过或直接不处理。外服策划BUG统计文档也是重要的回归文档之一，当后面版本迭代出现相同问题或者需求不一致时，可以及时查阅并进行最终需求确定。

当每周的测试任务繁多且经常被“突如其来”的BUG阻碍了测试道路时，可以多创建临时记录文档帮助自己记忆问题与测试状态，同时又可以记录当前重要的信息（测试配置，临时需求等）。好记性不如烂笔头，当事情繁多且杂乱时，再好的记忆都有可能会有犯错的时候，所以通过白纸黑字帮助自己记忆，从来都没有坏处。