Unite 2017 Shanghai将于5月11日-13日在上海·国际会议中心举办，国内技术专场演讲中Unity开发工程师蔡元星分享《A Bug’s Life》主题，介绍Unity是如何处理用户提交Bug到解决Bug，到发布Bug整个完整过程。 以下为VR陀螺整理的演讲实录：（略有删减） 蔡元星： 我是Unity开发工程师，我今天给大家讲的题目叫做A Bug’s Life，为什么叫这个名字呢？我想借这个机会给大家讲一下Unity是如何处理用户提交Bug到解决Bug，到发布Bug整个完整过程。 Unity从5.3版本之后投入了大量资源在稳定性上，我们希望和用户一起配合，把产品质量做得更好，所以其实我们是需要大家在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。 Unity工程师只关注bug，你的incident成功转为bug之后会收到邮件通知，我们尽力处理所有的incident，但数量太多时做不到，所以用一个评级系统来确定优先级。 它是从0排到5，0就是你的Bug报告写的不清楚，没有重现步骤，或者垃圾邮件的话就是0；5就是你有完整的重现项目，写了非常详细明确的描述这是5，评级越高就越有可能被处理并转化为bug，企业级支持用户的incident有最高优先级。 接下来，我们内部工程师到底怎么修Bug，一个incident转为bug时，会根据影响的模块分配给相应的工程师团队，我们会计算一个叫做“用户痛苦”指数决定优先级，依据是这个Bug的严重性，潜在影响的用户数量，影响的平台，还有它是否之前的版本是正常的现在坏了，Issue Tracker上面可以投票，投票数越多影响用户越多，还有是否来自企业级支持用户。 报了Bug之后要怎么追踪我们处理的进度。 首先是会有邮件的沟通，你提交bug后会收到确认邮件，告知bug ID。 另外bug被成功重现之后，就是incident转成 bug之后，bug被resolve，你可以回复任何一封通知邮件，附加更多信息，我们内部的QA和工程师收到这封邮件，可以与Unity QA或工程师交流，也可以通过这种形式给你的Bug附加更多的信息。 下面来介绍我们Issue Tracker，当你的incident被转为bug，相关信息有可能会公布在 https://issuetracker.unity3d.com这个网站上面。 这个其实是相当于我们一个对外公开的Bug数据库，所有QA重现的Bug大家在这里可以查到。 另外，如果你在你的Bug报告里面提到你自己的邮件地址、公司名称、项目信息，我们的QA会人工把这些信息过滤掉不会公开，另外你上传的项目文件也不会公开，你收到搜索确认邮件里的bug ID，另外有投票的功能，每个有10票，如果你看到哪一个Bug是你遇到的，你想提高它修复的速度或者机率的话可以给它投票，所以一个Bug在这里面的票数越多，它的优先级越高，就越有可能被修复，大家不报Bug，在这里面看到你的问题，也可以通过投票的方式来加快它被修复的速度。 接下来就是Issue Tracker具体Bug打开的一个界面，可以看到这20个Votes是说20个不同用户遇到相同的问题给它的投票，这个投票越高优先级越高，还可以看到它在哪一个版本发现的，还有这个ID就是刚才说的Bug ID，最后Regression看一下是不是在5.6之前的版本是正常的，在5.6坏了，这个也可以。 另外，Issue Tracker里面大家看到上面黑的是这个Bug目前的状态，用户报告的每一个Bug其实都是有7个状态，Active是说这个Bug正在调查或修复中，新报的Bug默认都是这个状态。 另外六个就是你的Bug被解决之后，会被解决成以下六种不同的状态。 Fixed就是确实是一个Bug，已经修好了 Postponed是说确定是一个问题但目前不打算修复，可以预见的未来之内不打算修复； Duplicate就是你这个Bug和另外一个bug是相同的问题，为了减少大家处理的时间，把相同的Bug直接解决Duplicate； Not Reproducible是Unity的工程师我们尝试修复时此bug已无法再重现。 Won’ t Fix这个比较少见但是也是会出现，由于某些合理的原因我们决定不修这个bug。 By Design不是bug。 如果bug resolve的结果不是Fixed或Duplicate，我们会邮件告诉你具体的原因，为什么结果是这样的。 最后说一下我们Unity如何发布Bug修复。 我们有三种版本，所谓的重要版本比如说5.6.0大的重要版本，这种是包含新功能，以及对已有功能改进以及对bug修复，三个月一次，另外我们有补丁版本，需要到 https://unity3d.com/unity/qa/patch-releases网站直接下载安装文件。 还有一种版本就是所谓的公开版本，就是每四个补丁版本中所有的bug修复，五个星期一次，这种版本在编辑器中Check for Updates会通知。 另外如果大家报的Bug最终是修复状态，肯定想到底是在哪一个具体版本里面修复的，一般情况下Unity的工程师修复的bug会发布在下一个重要版本中，这是一般的Bug；但是我们如果认为这个Bug比较严重，我们会选择后向移植到之前的版本中。 稍微总结一下，我们说到要使用Unity Bug Reporter工具来报告bug，我是我们向Unity提交Bug最主要的方式；还有使用我们提供的工具精简你的项目并发给我们，帮助我们重现bug；另外你提供越多的信息，你的incident就越有可能被重现被转为真正的bug，最后被真正的修复； 另外，我们内部根据bug带给用户的痛苦来决定优先级；还有就是我们Bug修复的进度，如果是你自己报的Bug会通过email跟你沟通；也可以到Issue Tracker鼓励大家多用一些，历史上所有的Bug在里面都有记录，所以你遇到真正的Bug，其实有非常大的可能是在这里面查到的；另外我最后讲到我们发布补丁版本的方式，如果有非常紧急的Bug，可以到那个网站去下载最新的补丁版本。 谢谢大家！