二、白盒测试
黑盒测试与白盒测试
什么叫黑盒测试，我们可以认为一款软件就像一个黑盒子，我们不知道里面发生了什么，但是我们只管设计输入，再去查看输出是不是符合预期，这个就是黑盒测试。
相应的是白盒测试，白盒测试不同的是，盒子内部的逻辑我们都是知道的。
白盒测试的方法
单元测试和集成测试
单元测试和集成测试都是针对于代码的测试，假设一个函数是一个单元的话，我们针对细节的单元逐一测试，最后将所有单元拼在一起，做集成测试。
举个例子：抽卡。抽卡分几步？焚香和祷告，这是玩家的过程。程序代码的过程是什么呢，先扣卡券，再随机，最后发卡。其中随机的过程会生成一个卡池，最后再算概率。那这样各个细分模块就清晰了，整个抽卡的测试就先将每个点单独测一遍，再去测整个抽卡的功能。
白盒测试的工具
静态代码检查和代码覆盖率测试
白盒测试有哪些常用工具呢？静态代码检查和代码覆盖率测试。
什么是静态代码检查？就是在不运行代码的情况静态检查，类似于大家做完作业检查自己的代码，但是这样效率低，且不容易检查出问题。所以大家发明了不同的工具去检测自己的代码是否是正确。?
我们日常交流时，判断一个人说话的语法对不对时，会把语言细分成一个个词，再套到语法公式里。那么代码检查也是类似的。我们把源代码分成单词流，再进行语法分析。这是非常粗浅的原理，但实际是十分复杂的，所以工具就十分重要，可以节约我们大量的时间，也能找出我们不太能发现的问题。
第二种是代码覆盖率的测试，代码覆盖率测试与静态代码检查相反，是在代码运行中去检查问题。
假设有个老套的求婚代码，要求求婚者必须是男性角色，被求婚者为女性角色。那我们要如何测试呢？只要运行代码的时候把所有的代码都run一遍，做到完全覆盖，就没问题。
有些也会要求判定覆盖，甚至是条件覆盖，那么复杂度会稍微高一点。再往上难度更难的就是多重条件覆盖，也就是每一种条件组合都要覆盖到。
当然也有很多地方是工具覆盖不到的，并且并不是达到了某种覆盖的100%就表示代码逻辑没有问题了。这个时候就需要我们大家更花心思，用更多的方法去覆盖及测试，这就涉及到更深一些的内容。
以上就是白盒测试的方法和一些概念。
三、感悟
最后分享一些形而上的东西，做了这么多年测试，给大家分享一点感悟。
完全测试是可能的么？比如一个计算器，能做到完全测试么？那是不可能的，因为计算器的输入和输出是不能穷举的。所以需要设计测试用例来尽可能地发现问题。
另外，并不是所有的软件缺陷都要去修复。理想来说肯定是修复好所有的bug是最好的，但这个在现实中很难实现。我们要考虑成本和收益，成本就是时间、人力以及风险，收益就是质量、安全、体验以及口碑。做了成本和收益和权衡之后才能决定是不是要修复某一个缺陷。
简单举个例子，比如一个副本，只有全服全厉害的人才能玩，那这个副本就是无效的，虽然没有bug，但是不符合可玩性。比如MOBA类游戏，出了一个新英雄非常厉害，无可匹敌，也是不合理的，这个就是平衡性问题。
四、测试的发展趋势
最后和大家分享下测试的发展趋势。一开始是以验证为导向，即只要验证过了就可以。再到破坏行为导向，比如贩卖机，光验证能买到饮料不够，有些买家可能会踢它，还要经历风吹雨晒也不坏，所以要去做这样的暴力测试。
可是后来人们发现，极端情况并不是大家最关心的部分，大家更关心产品的整体质量评估，比如耐用年限，在什么环境下容易出问题等等，所以逐渐地质量保障需要做更全面的质量评估。
再到现在，随着人们普遍认识到问题发现得越早，修复的成本就越小，一个重要的趋势就是通过流程、规范等手段把缺陷扼杀在摇篮里，也就是以缺陷预防为导向。
观察游戏游戏开发模型，我们会发现工作流是从设计师、到开发、再到测试。但是因为测试是下游阶段，越晚发现问题，越难去修改。其实测试应该在更早介入，比如在设计阶段，从数值、从整体架构就能发现问题并提出问题，来降低修复成本，预防更大的问题发生。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
