1、测试用例的常见分类
1.1 基本功能测试
基本功能是指手机软件向手机用户提供的最小的、可以进行的所有简单操作的集合。对基本功能的测试是指测试工程师在被测试的手机上进行实际操作，来验证操作是否可以，操作的结果是否满足设计的要求，如果不满足，就要报告错误，由开发者来改正错误。具体操作如：接一个电话，打一个电话等等。
1.2 交互测试
所谓交互测试是指当手机不同的两个或者多个功能之间有交互的时候，对手机对应该处的状态或者行为进行测试，被测手机的状态或者行为应该与需求设计中的要求相一致。如果有错误，同样应该由开发人员来进行改正。具体的操作例如：打电话时接受短信，看短信内容时候进来一个电话等等。
1.3 临界测试
所谓的临界测试是指当手机的某些可用资源达到或者超过理论允许的极大值时，在手机上继续进行某种操作时候的测试。此时手机的行为一个是友好的，可被使用者接收的，应该与需求分析的要求相符合。具体的操作例如：内存满时拨打电话，内存满时启动浏览器，内存满时启动音乐播放器，数据库满时拨打电话等等。
1.4 压力测试
压力测试一般是指在比较短的一段时间内，被测手机执行比较多的任务或者操作，来检测被测手机承受压力的能力。例如：在短时间内发送大量的短信，同时并接受大量的短信，发送和接收的数量都在50条以上。短信的群发（包括超长短信），查看接收和发送的成功率，接通一个电话并且保持很长一段时间（大于10个小时）等等。
2、测试用例设计注意事项
对于测试用例的设计来说，操作步骤的描述总体上要求尽量笼统化，含糊化。为了表述一个概念或者操作，不必说清楚怎么样具体的完成这个操作，只需一带而过地说要进行什么操作即可。比如说，只需要什么“启动计数器应用”，而不必说先进到主菜单，再到某某选项下面找到“计算器”之类的话。再比如，只需要说“接通一个电话，然后接收一条短信”而不必说如何如何接通电话，如何从别的手机或者软件发送一条短信。
同时为了防止测试工程师在执行测试用例的时候不清楚某些操作的具体实现方法，还需要在相应测试用例的联机帮助文档中对可能引起混淆的操作或者比较笼统的描述做出进一步详细的说明。
这样的好处是测试用例没有同十分具体的某一款产品绑定的太紧密。在实际的商业模式中，经常是一个手机软件平台会衍生出一系列的不同产品。这些产品的功能基本相同，只是具体的操作界面有所不同。新开发的测试用例应该是面向整个平台，而不是针对具体的某一款产品的。否则无形中会大大增加额外的劳动力。所以无论从商业成本的考虑还是从开发周期成本角度来说，开发针对平台的测试用例无疑是最正确的选择。
其实，为了能够使开发出的测试用例能够快速地被新来的测试工程师理解和掌握，为了能使这些测试用例有更多的可使用者，也应该尽可能地把对操作步骤的描述详细化和具体化，因为只有这样，才能使测试用例更加通俗易懂，节省更多的新手的熟悉和适应的周期。
所以，这就需要找到一个“笼统”与“详细”之间的平衡点，只有适当地掌握了详细的分寸与火候，才能使得测试用例具有更高的认可度和质量。
