正文
不同的测试人员，可能存在这不同的测试用例设计风格。但也不外乎以下几种共性：
-
合理的组织结构：
用良好的测试用例结构框架，聚焦到不同的关注模块，清晰且可延展。
-
精简的用例条例：
用较少的测试用例，描述清楚测试点的覆盖，全面而不冗余。
-
稳定的测试方法：
在一定的执行条件、顺序下，有明确的执行结果。
在进行测试用例设计的时候，建议像写论文一样，由提纲契领到逐步细化。在基本功能点的基础上逐步增加细节，不要过早陷入细节描述。同时，测试用例的粒度，要根据测试效率和效果来综合评估。
考虑到移动端平台及系统的多样化、功能需求的复杂化，使用传统的用例组织方式（例如等价类划分、边界值分析、因果分析等）而将测试仅仅停留在基本功能上，目前看来已经远远不够，测试人员还需要从面向问题发现的角度来组织测试用例。即由Bug可能的分布点来考虑测试内容。
因此，在实际的项目
中，移动端测试大致分为以下几点：
（1）基础测试：
基本功能、数据交互（边界值、异常数据等）基本功能测试，可以通过功能分析、因果分
析方法，将功能分层，逐级细化，先画出框架、草图，再文字细化。这一部分在一轮完整的测试后，通常即可保证该功能基本是完备的，之后的问题一般是出现在基本功能之上的特殊状况中。因此，这一环节中，可以暂不考虑功能实现的好坏、特殊场景及特殊操作的影响，也就将基本功能测试点和其他特殊测试内容进行了分离。这样组织，也有利于裁剪测试用例，将更多的精力放在容易发生问题的部分，而这一部分的基本功能则可以通过特殊状况的检验而覆盖到。
（2）数据交互测试：
主要是在基本功能的基础上，考虑各种输入输出。一般基本功能容易在边界附近出现问题。这里可以根据梳理
初的基本功能草图，确定哪些部分可能存在相应的问题，然后加以构造。例如，输入的
数值范围、字符长短、内容缺失、字符/数字类型是否支持等。
（3）
性能测试：
响应速度、资源占用（CPU、电量等）、流量消耗、稳定性
测试人员在进行产品测试过程中，对于响应速度、资源占用、流量消耗、CPU占用的测试，会有明确的用户主管感受。而判断产品性能是否符合预期，不能只凭主管感受，需要对合适的竞品进行分析，从竞品的核心用例得出一个benchmark。因此，立项初期，测试人员对预期的目标应该有一个清晰的认识。
