Steam上新推出的“游戏测试工具”，有点不用像试玩游戏DEMO的感觉，这样就不需要大家为了抢到测试资格码去参与一些活动或者问卷了，对于玩家来说更加便利了。
详细的说就是可以让游戏开发者在不用管理序号列以及外部邮件列表的情况下，邀请玩家来测试自己的游戏，邀请玩家来测试自己的游戏。有多少玩家能访问游戏、何时加入更多玩家、何时开始测试以及何时结束测试，都由开发者掌握。
其运行原理如下：
这一全新工具让开发者可以直接在自己的Steam商店页面上主持游戏测试报名活动，并直接通过Steamworks来给予访问权限（不需要序列号），如下图所示：
玩家点击按钮以报名，然后就进入队列排队。在后端，开发者可以使用简单易用的界面看到所有的报名，并按照自己的意愿给一定数目的用户放行：
当准备好结束游戏测试时，可轻松将其停用；这会将报名选项从游戏的商店页面中移除，并将游戏测试从玩家的库中移除。
在幕后，这一下载并畅玩的体验是在一个次级的补充性appID上进行的，和Steam上处理试用版的手法颇为类似。因此，游戏测试中玩家的所有权和游玩时间和真正的游戏是分开的。这意味着Steam游戏测试不会在愿望单上抹除真正的游戏，也不会与之竞争，而且Steam游戏测试的所有者也不能撰写用户评测。
个人感觉“Steam游戏测试”在玩家和游戏开发者之间还是非常好的一个桥梁，玩家玩了游戏，开发商也做了测试，真是一个好东西噢~
游戏测试基本流程
功能会议>测试用例书写>冒烟测试>详细测试>回归测试>checklist检查
功能会议
了解功能需求内容
提出可能存在的风险点
思考功能的测试重点和难点，如果需要工具辅助，需提出开发需求
思考可以优化的地方，并提出讨论
测试用例书写
根据需求书写测试用例
关注功能逻辑实现
考虑各种特殊情况，如边界值，网络中断，进程中断等
关注需求变更情况，需求经常发生变更，需要及时调整测试用例
冒烟测试
是详细测试之前的一个环节
快速发现比较明显的bug
快速确保主逻辑流程跑通
快速明确功能开展状态
详细测试
细致的测试每个逻辑分支，资源，配置
尽量模拟玩家的每一种操作可能
测试异常情况，如断网，断点，事件中断，进程中断等情况
测试数据读取，存储，网络等内容
测试该功能对其他功能的影响
回归测试
测试已经被修复的内容
测试需求调整后的内容
再次详细测试各逻辑分支
checklist检查
简要快速的检查功能的主要逻辑点
简要检查与该功能有关联的任何其他功能点
