下面小编接着和大家介绍一下如何在游戏测试中引入深度学习和测试平衡：
1、游戏测试中的深度学习
>>>> AlphaGo的学习过程分为两大步骤:
（1）基础学习：
第一步是学习3万多幅专业棋手对局的棋谱来训练策略网络和快速走棋网络。
（2）深度学习：
通过大量的自我对弈和强化训练，建立自我对弈棋谱(3000万盘棋局), 增强了策略网络并且创建了价值网络来评估棋局。
由此可以看出，深度学习鼓励学习者积极地探索、反思和创造，而不是反复的记忆。我们可以把深度学习理解为一种基于理解的学习。它强调学习者批判性地学习新思想和知识，把它们纳入原有的认知结构中，将已有的知识迁移到新的情境中，从而帮助决策、解决问题。
游戏测试过程中，不仅需要通过基础学习了解基本的产品知识，行业知识和测试技术，更需要通过深度学习（学习->实践->总结->提高），建立适用于自己的知识体系和经验数据库.
>>>> 游戏测试的学习范围
针对游戏测试，学习内容分为两大部分四大区域：
（1）游戏测试的基础学习:
知识: 包括产品知识(游戏类型，游戏玩法等)和行业知识
技术: 基本的测试技术，比如黑盒测试技术，白盒测试技术，探索式测试，等。
（2）游戏测试的深度学习:
经验: 测试经验与教训，线上Bug分析与学习，脚本执行的指南以及技巧，测试策略，等。
创新: 建立新的测试模型，尝试业内流行的更多测试方法，改进测试流程，开发更多的测试工具等
>>>> 游戏测试深度学习的过程
深度学习的整个过程其实就是从学到用，然后通过总结与改进，提高实用性的一个过程。以下是作者总结的深度学习的四个步骤:
步骤一: 知识储备
学习适用于博彩游戏测试的测试理论，测试技术，测试模型，测试经验与教训。
步骤二: 探索实践
探索和实践学到的测试理论，技术，模型和经验。
步骤三: 总结提炼
评估实践结果；
总结成功经验与失败教训；
分析原因并提出针对博彩游戏测试的改进方案。
步骤四: 改进创新
实施改进方案，提高实用性和适用性；
提出新的测试理论或者创建新的测试模型；
建立针对游戏测试的理论，技术和实践数据库。
2、目标驱动的平衡测试
AlphaGo在下棋过程中有两处落子精度和速度之的平衡：
（1）策略网络 vs 快速走棋策略
策略网络速度较慢，但精度较高；快速走棋策略反之，效率高但是精度偏低。AlphaGo正是充分利用两者的互补性，在精度和速度之间找到一种平衡，保证赢棋的情况下尽快下棋。
（2）价值网络 vs 快速走棋策略:
AlphaGo在对弈的过程中利用价值网络和快速走棋网络分别判断局势，两个局势得分相加为此处最后走棋获胜的得分。价值网络对局势的判断速度更快，但是由于其训练样本还远远不足，离准确判断当前局势还有不小的差距。这个时候为了提高局势判断的精度，不得不牺牲一定速度，依靠快速走棋策略来更精确地判断局势。
测试中也会有类似情况发生。比如说有的游戏需要提前发布，这时候就需要在缩短测试周期的前提下平衡测试质量，测试范围和测试成本以达到测试目的；另外一种情况可能是由于design改动的原因需要增加测试范围，在保证按时发布的前提下也需要牺牲一定的测试质量和测试成本以取得项目成功。
>>>> 游戏测试中如何平衡4要素
项目管理有四个要素:工作范围、时间、质量、成本。测试管理作为项目管理的一个具体实例，同样包含4要素: 测试范围、测试时间、测试质量、测试成本。
对于游戏测试而言最理想的情况就是“多、快、好、省”。“多”指测试范围广，“快”指游戏测试完成的日期早，“好”指测试质量高，“省”指实际测试时间少。但是，这4者之间是相互关联的，提高一个指标的同时会降低另一个和多个指标，所以实际上这种理想的情况很难达到。
1) 第一步：明确测试中的关键要素
在讨论测试管理中如何平衡四要素之前，需要首先明确测试成功的最主要的判断标准以及测试的首要目标。对于游戏测试而言，主要目标是如何提高测试效率，节省更多的测试时间。那么平衡的标准是基于降低测试成本而对测试范围，测试质量以及测试完成日期进行调整。因此，平衡的难点在于如何找到测试时间节省最多而且测试风险降到最低的关键点。
2) 第二步: 基于关键要素选择最佳平衡点
下图是游戏质量，测试成本随测试时间变化的曲线图。不难看出，最理想的平衡点，也是结束测试的时间点，在游戏质量与测试成本曲线交叉点附近。
3) 第三步，确定策略以及对应的方法
假设我们设定目标减少测试时间25%，为了实现目标，我们必须牺牲一定的测试质量，减少测试范围或者在一定范围内调整测试周期。为了把测试风险降到最低，我们必须鉴定出相应的测试策略以及测试方法，争取在提高测试效率的同时仍然取得项目的成功。
以下是基于减少测试时间25%的目标而分析出的测试策略与方法。
（1）提高测试效率
通过探索式测试提高测试效率和灵活性。
尽量多的执行自动化测试以及任何适用的测试工具去提高测试效率。
（2）减少测试范围
运用基于风险的测试模型去尽量减少拥有同样逻辑的游戏属性的重复测试。
减少公共测试用例与新创建的测试用例的重复测试。
通过SDET对游戏代码的分析帮助减少没有必要或者风险低的测试区域（界定更准确的测试范围）。
把游戏测试与Paytable的测试合并在一起执行。这样不仅可以节省熟悉游戏特性的时间，更可以减少两种测试的重叠区域的测试效率。
（3）调整测试周期
减少测试人员，在一定范围内推迟测试周期。
通过尽早测试来尽量减少对测试周期的影响。
