图形界面的测试一直都是一个麻烦事，一般来说，都是开发人员开发的时候和设计稿比对，测试的时候过一遍，最终产品经理验收。正常的数据一般来说显示都没有问题的，往往是上线后的用户数据产生了特定的corner case，出现了意料之外的视觉效果。
MVVM
MVVM的核心思路，是将界面展示拆分成了VM和V两个部分，甚至很多MVVM的框架，只专注于VM和V的部分，提供双向绑定，把剩下的更新、缓存、业务逻辑都交给开发者自己决定。
而视觉效果的测试，则可以只关注双向绑定的一个方向，即 VM -> V 这个方向，即特定的VM状态，所产生的界面应该是合理的、符合设计规范的。当然双向的测试更为理想，可以测试交互细节，答案略。O__O “…好吧，是我们可以放到后面讨论。
GUI测试
现行的很多自动化UI测试框架，一般给出两种方案，一种是直接用代码检查界面是否正确显示，这里是否有这个字，那里是不是红色；一种是直接给出截图，程序员可以直接看图，甚至在图中标出预期和实际的差别。然而这类框架的一个重要缺陷是，界面改动可能十分频繁，特别是迭代速度非常快的情况下，很多时候逻辑并没有改变多少，但是界面已经迭代了好多版本。这样一来，写好的测试用例基本白搭，又得重头开始写。而视觉相关的测试用例本来就纷繁冗杂……╮(╯▽╰)╭
MVVM + GUI = MGTest测试框架
脚踏实地，我们认为程序员在调试界面的时候仍然愿意去“看”，而不是用代码去检查，那么就可以利用MVVM的特点来达到这一目的。
- MVVM框架保证所有的页面V，是由VM状态直接映射的，即VM -> V
- MGT框架负责遍历所有的VM状态，生成截图
- 程序员/测试/产品通过查看截图判定视觉的正确性
这样做，有很多直接的好处。
首先，可以分离视觉测试和开发工作，相当于视觉的单元测试无需编写额外的单元测试代码，一个不用太懂编码的测试即可完成工作。
其次，查看特定的界面效果，不依赖重现某一个特定业务逻辑。这点在日常开发中，程序员自己“目测”的过程中非常常见，为了看特定状态下是否达到了预期的效果，往往需要多次重复复杂的业务逻辑，才能做一次review，效率很低。而如果是自动遍历所有状态，自然会包括特定业务逻辑的状态在其中。
实现思路
- 深度遍历VM到基本类型
- 提供针对基本类型取值范围的通用配置
- 允许对特定的VM变量进行单独的变量范围配置
- 结合VM框架，自动运行接入的界面，并对不同状态的界面进行截图
- 展示截图，例如网页、邮件、甚至一个测试用portal
中间，第4步需要对VM的各个变量的各个取值进行交叉遍历，有可能会产生大量的数据，例如10个变量，每个变量2个取值就有1024张图了，实际并不需要这么多，应该首先生成能够遍历所有变量的n张图，其中n是这些变量中，最多取值的变量的取值数量。剩下的自由组合可以随机生成一些，以保证生成的图片能够迅速看完，又不会失去检查corner case的机会。