游戏葡萄5月12日消息，Unite2017开发者大会今日在上海召开。会上，Unity开发工程师蔡元星分享了主题为《A Bug’s Life》的演讲，详细剖析了Unity是如何处理用户提交Bug到解决Bug，到发布Bug整个的完整过程。

以下是演讲实录：

蔡元星：先自我介绍一下，我名字叫蔡元星，我是Unity开发工程师，我今天给大家讲的题目叫做A Bug’s Life，为什么叫这个名字呢？我想借这个机会给大家讲一下Unity是如何处理用户提交Bug到解决Bug，到发布Bug整个完整过程。

开始之前，我想问一个问题，大家在座有谁用Unity的Bug Reporter给Unity提交过Bug？你们可以尝试多去报一下，你半天找不到解决方案的话，这个你提供的步骤够详细的话我们是可以解决的。

Unity从5.3版本之后投入了大量资源在稳定性上，但没有哪个软件是完美的，所以你无论是什么版本，你在使用中还是会遇到Unity的bug，我们希望和用户一起配合，把我们Unity的产品质量做得更好，所以其实我们是需要大家在Bug上面的反馈。

这个就是一个用户报告的Unity bug的完整生命周期，我会教大家如何报告bug，Unity是如何处理bug报告以及修复bug的，然后用户如何追踪bug修复的进度，以及最后我们Unity是如何发布bug fix的。

首先，这一页是向大家介绍一下用户如何向Unity报告bug，我们有一个叫做Unity Bug Reporter的工具，从 Help 到Report a Bug启动，编辑器崩溃它会自动启动。大家看一下这个界面，我们要报一个Bug的话，带星号的这些选项都是要填的。

首先是What is the problem related to，Crash bug - Unity编辑器或者发布的游戏崩溃，A problem with the Editor - 编辑器使用中的问题，A problem with the Player - 发布游戏运行中的问题。

第二个是This is the first time - 当你不知道如何重现问题时选择，Sometimes but not always - 偶尔发生或者随机发生，Always - 100%重现。

另外你需要填你的email地址，因为我们会通过邮件联系你告知bug处理的进度，或者询问有关这个bug的更多信息。

接下来是一个Bug的描述，这是一句话，要用英语写，第一个是说你觉得你的Bug你认为的错误行为是什么，以及什么时候它发生。这里有一个例子，这个是数据库里面已经有的一个Bug，叫做Editor crashes when adding text component to game object in play mode via script，自动建议可能相关的问题。

当你输入的时候，下面会建议一些官网的各种，无论是论坛还是Bug追踪工具已经有的Bug和你输入的关键字匹配的话相关会列在这里，你在这里面发现你这个问题别人已经遇到的话你可以参考，也许就不用报了。

下面最重要的是Bug呈现的步骤，这个你要尽量写的详细，每一步如何最终触发这个Bug，你要写清楚你期待的它的正确行为是什么，它实际（错误）的行为是什么。

另外很重要的一步是，我们需要一个你可以重现Bug的项目，如果你的bug是和项目中具体的资源或者脚本相关的，所以需要大家的项目文件，这个仅需包含重现bug所必须的文件，不要包含Library文件夹。另外我们保证是对用户上传的文件绝对保密的，所以不会用作重现bug之外的其他用途，所以大家这一点可以放心，除了项目文件本身，你还可以上传一些描述重现步骤的视频或者视频、截图，最后点击Send。

我们讲到最后有一个上传重现项目的步骤，如果大家的项目比较大的话，传起来可能非常慢，我们官方有两个很小的工具帮助大家精简项目，第一个叫做Repro Project Wizard，是你导入package后选择Window->Repro Project Wizard，原理很简单，就是把发生bug的场景加入到Assets to Copy中，场景中引用的其他资源会自动添加，加入其他运行该场景所必须的文件，纹理尺寸可以选择缩小纹理尺寸，最后按Create Project会在指定路径创建出新的一个文件。

这个Project Stripping Tool比较简单，有选择的把特定类型的资源从项目中删除，操作可撤销，导入package后在任意文件或文件夹上右键单击。在这个网站上面有详细的文档，大家想用可以仔细看。

下面告诉大家怎样才是优质的Bug报告，可重现性是最重要的，如果能重现，我们敢保证有99%的把握可以修复bug，另外如果上传项目文件的话对我们修复Bug有非常大的帮助，你们可以提供更好的相关信息帮助我们更好的修复Bug。另外必须要用英语，因为我们没有人力处理非英语的报告，其实你不需要用词十分准确，可以容忍语法错误，他们也可以看懂，多用图片或视频来描述。

下面介绍一下，你们提交Bug以后，我们Unity如何处理bug报告以及修复bug，这里面提到一个概念是incident，这是我们内部的一个概念，我们理解它很重要，用户每发送一个bug报告，我们的系统中就会自动创建一个对应的incident的一个东西，这个其实不是我们认为真正的Bug，真正的Bug是我们的QA成功重现后才转叫做bug，所以还是重现很重要，重现不了会被忽略。

Unity工程师只关注bug，你的incident成功转为bug之后会收到邮件通知，我们尽力处理所有的incident，但数量太多时做不到，所以用一个评级系统来确定优先级。它是从0排到5，0就是你的Bug报告写的不清楚，没有重现步骤，或者垃圾邮件的话就是0；5就是你有完整的重现项目，写了非常详细明确的描述这是5，评级越高就越有可能被处理并转化为bug，企业级支持用户的incident有最高优先级。

接下来，因为这是我们内部流程，我简单快速过一下，我们内部工程师到底怎么修Bug，一个incident转为bug时，会根据影响的模块分配给相应的工程师团队，我们会计算一个叫做“用户痛苦”指数决定优先级，依据是这个Bug的严重性，潜在影响的用户数量，影响的平台，还有它是否之前的版本是正常的现在坏了，Issue Tracker上面可以投票，投票数越多影响用户越多，还有是否来自企业级支持用户。

这是我们修Bug的一个过程，有很多的步骤，我就不再细说，大家稍微看一下，总之有非常繁杂的步骤，不是改完就完的。

然后我要给大家说一下报了Bug之后要怎么追踪我们处理的进度。首先是会有邮件的沟通，你提交bug后会收到确认邮件，告知bug ID，这个ID在以后我们的追踪系统里面可以查，还有几个情况大家会收到邮件通知，第一就是这个Bug写的不太清楚，我们需要更多信息，我们QA会主动发邮件联系你，另外bug被成功重现之后，就是incident转成 bug之后，bug被resolve，你可以回复任何一封通知邮件，附加更多信息，我们内部的QA和工程师收到这封邮件，可以与Unity QA或工程师交流，也可以通过这种形式给你的Bug附加更多的信息。

下面我们来介绍我们Issue Tracker，当你的incident被转为bug，相关信息有可能会公布在 https://issuetracker.unity3d.com这个网站上面，大家有访问过吗？有去看过这个吗？没有。

这个其实是相当于我们一个对外公开的Bug数据库，所有QA重现的Bug大家在这里可以查到，我们设这个公开的Bug数据库原因就是为了帮助遇到相似问题的用户，可以在这个上面查，也许别人遇到的问题他已经报了Bug或者已经解决了，你通过这个方式知道有这样一回事儿，在哪一个版本修复了，都可以查到。

另外，如果你在你的Bug报告里面提到你自己的邮件地址、公司名称、项目信息，我们的QA会人工把这些信息过滤掉不会公开，另外你上传的项目文件也不会公开，你收到搜索确认邮件里的bug ID，另外有投票的功能，每个有10票，如果你看到哪一个Bug是你遇到的，你想提高它修复的速度或者机率的话可以给它投票，所以一个Bug在这里面的票数越多，它的优先级越高，就越有可能被修复，大家不报Bug，在这里面看到你的问题，也可以通过投票的方式来加快它被修复的速度。

接下来就是Issue Tracker具体Bug打开的一个界面，可以看到这20个Votes是说20个不同用户遇到相同的问题给它的投票，这个投票越高优先级越高，还可以看到它在哪一个版本发现的，还有这个ID就是刚才说的Bug ID，最后Regression看一下是不是在5.6之前的版本是正常的，在5.6坏了，这个也可以。

下面就是Bug具体的一些描述，可以不看了。

另外，Issue Tracker里面大家看到上面黑的是这个Bug目前的状态，用户报告的每一个Bug其实都是有7个状态，Active是说这个Bug正在调查或修复中，新报的Bug默认都是这个状态。

另外六个就是你的Bug被解决之后，会被解决成以下六种不同的状态，Fixed就是确实是一个Bug，已经修好了，而且告诉你具体在哪一个版本修的；Postponed是说确定是一个问题但目前不打算修复，可以预见的未来之内不打算修复；Duplicate就是你这个Bug和另外一个bug是相同的问题，为了减少大家处理的时间，把相同的Bug直接解决Duplicate；

Not Reproducible是Unity的工程师我们尝试修复时此bug已无法再重现，为什么出现这种情况？可能这个工程师尝试修复的时候，比如说我们代码库有一些别人的提交已经把这个无意间把这个Bug修掉了这也是有可能的，你在重现的时候发现这是好的重现不了，这个时候也会成了Not Reproducible。

Won’ t Fix这个比较少见但是也是会出现，由于某些合理的原因我们决定不修这个bug，举个例子这个Bug我们认为已经是deprecated的功能或操作系统引起的问题，因为这个功能我们本身已经停止维护了，出了Bug也不修了，另外你这个Bug是非Unity自身的原则，比如说是操作系统的问题等等，我们本身无能为力，最后也会Won’ t Fix；By Design不是bug。

另外，我们刚才说了六种状态，如果bug resolve的结果不是Fixed或Duplicate，我们会邮件告诉你具体的原因，为什么结果是这样的。

最后说一下Unity如何发布Bug修复，这一页黎明已经说的比较清楚，我这个地方用的术语不太一样，我们有三种版本，所谓的重要版本比如说5.6.0大的重要版本，这种是包含新功能，以及对已有功能改进以及对bug修复，三个月一次，另外我们有补丁版本，比如说版本号以P结尾，比如说5.6.0p1，只有bug修复，每周一次持续四周，就是p1-p4，这种Bug在编辑器中用Check for Updates检查的话是不会收到通知的 ，需要到 https://unity3d.com/unity/qa/patch-releases网站直接下载安装文件。

还有一种版本就是所谓的公开版本，就是每四个补丁版本中所有的bug修复，五个星期一次，这种版本在编辑器中Check for Updates会通知。

另外如果大家报的Bug最终是修复状态，肯定想到底是在哪一个具体版本里面修复的，一般情况下Unity的工程师修复的bug会发布在下一个重要版本中，这是一般的Bug；但是我们如果认为这个Bug比较严重，我们会选择后向移植到之前的版本中。

举个例子，比如说我们修了一个Bug，然后默认是说要发布在2017.1下一个大版本中，如果这个版本很严重的话，我们会把这个代码复制到一份到目前的5.6基础之上，就是被后向移植，就是通过补丁版本发布。另外企业级支持用户可以要求我们提交的Bug要后向移植他们项目正在使用的版本，这个也是有可能的；另外Issue Tracker会告诉你bug修复的确切版本；还有我们每个版本发布有Release Notes，这里面会列出这一个版本修复的Bug ID，可以在这里面查找自己的Bug ID确认自己要的Bug是不是在这个版本里面修复。

现在我因为过的很快，可能还有时间，稍微总结一下，我们说到要使用Unity Bug Reporter工具来报告bug，我是我们向Unity提交Bug最主要的方式；还有使用我们提供的工具精简你的项目并发给我们，帮助我们重现bug；另外你提供越多的信息，你的incident就越有可能被重现被转为真正的bug，最后被真正的修复；

另外，我们内部根据bug带给用户的痛苦来决定优先级；还有就是我们Bug修复的进度，如果是你自己报的Bug会通过email跟你沟通；也可以到Issue Tracker鼓励大家多用一些，历史上所有的Bug在里面都有记录，所以你遇到真正的Bug，其实有非常大的可能是在这里面查到的；另外我最后讲到我们发布补丁版本的方式，如果有非常紧急的Bug，可以到那个网站去下载最新的补丁版本，我就讲这么多，谢谢大家！