JUnit的特征
A、使用断言方法判断期望值和实际值差异，返回Boolean值。
B、测试驱动设备使用共同的初始化变量或者实例。
C、测试包结构便于组织和集成运行。
D、支持图型交互模式和文本交互模式。 （MicroUnitTesting可以将测试结果显示到手机屏幕上，个人认为是鸡肋功能）
JUnit框架组成
A、对测试目标进行测试的方法与过程集合，可称为测试用例(TestCase)。
B、测试用例的集合，可容纳多个测试用例(TestCase)，将其称作测试包(TestSuite)。
C、测试结果的描述与记录。(TestResult) 。
D、测试过程中的事件监听者(TestListener)。
E、每一个测试方法所发生的与预期不一致状况的描述，称其测试失败元素(TestFailure)
F、JUnit Framework中的出错异常（AssertionFailedError）。
可行性分析
从JUnit的应用来分析
A、 测试驱动开发的重要组成部分，应该在代码编写之前编写测试用例。
B、 单元测试实际上是用穷举法列出所用可能性，针对每一种可能都有测试用例。（AI怎么测？能穷举吗？）
C、 对于drawImage这样的方法，只靠断言（Assertion）不能得到我们期望的测试结果（断言图片画出来没有？不如直接用肉眼看来的快。那么如何断言图片是否显示正确？目前没有发现相应的框架，还是直接用肉眼看来的快。）
从移动游戏应用的特殊性来分析
A、 面对对象特性不强（非常非常非常的差！！！），主要是游戏的性能和容量的限制。
B、 类方法功能不够明确，针对一个方法设计用例十分困难。比如AI的状态机，状态之间的切换牵涉到太多的变量，参数。各种变量参数之间的组合可能有上百种，无法设计用例。
C、 游戏应用的重要部分在显示部分，目前没有发现测试显示部分的框架。
文章来源于领测软件测试网 https://www.ltesting.net/
