1．在提交高通前务必要检查文档与实际程序的功能表现是否相同，比如说，客户端新增了快捷键，等操作必须在相应的帮助性文档中详细描述其使用的方便之处，引导用户形成预定的操作习惯。这样做可以增强程序的易用性。

2．在模拟器上视频的处理速度较快，所以不会出现画面移动的图像变模糊的现象，但是由于手机的分辨率相对低，处理速度也远比不上计算机的处理速度，所以一般在模拟器显示正常的速度，到了手机就应该让开发人员适当调慢，否则将会出现移动物体变模糊不能清晰辨认的情况。

3．有些系统中使用了很多的图片资源，当在两个界面之间(例如在主菜单界面和帮助界面之间，主界面菜单是由许多图片组成的，帮助界面是一个html文件的浏览显示)，连续按若干次使其在两个界面之间连续切换，会出现图像重叠现象，其原因是手机的CPU处理速度跟不上刷新速度，而且主界面的图片资源一直没有释放，导致图像的残留。一般可模拟Grinder把这些类似的问题测出来。

4．是否正确处理来电。如果没有适当正确的来电处理，有些来电会使播放器画面变乱，有些直接退出，甚至死机。Brew程序员往往会在来电处理后的恢复中忘了对音乐的处理，比如说原先选择了关闭音乐的，来电处理后音乐又自动开始播放了。有时候需要模拟两个或以上的连续的来电以发掘程序深层的逻辑错误，这些错误大多是来电处理后的恢复过程的错误。另外短信，电量不足等一些事件警告的出现也有可能导致程序出错，也要作出相应的处理。

5．注意确保系统的说明和帮助的完整清晰，检查系统提示信息，确保在系统中出现的文字的正确拼写，没有错别字。要尽量用敬称“您”而不用“你”。

6．标题，菜单等的文字显示要尽量用小字体，尽量缩短文字，能用简短文字说明清楚的就不要用长句，例如“按2，4键可以左右移动图片”就可改成“按2，4键左右移动图片”，或者甚至改成“按2，4键移动图片”。因为不同的手机显示屏幕宽度不一样，在一款手机上显示正确不代表在其他款式都能正确显示，然而用小字体，短句子就能适应大多数手机的屏幕宽度。

7．线程的处理，有些系统设有多个线程，如果没有处理好线程的调用释放问题的话，就很可能出现线程争用的问题。例如一个宠物系统，宠物死亡后，会调用一个新的线程循环播放哀吊音乐，有些程序员由于粗心大意忘记了释放这个线程，当重新开始系统时，就会出现这个线程播放的音乐与系统过程的背景音乐交替播放的情况。

8．文件处理。当涉及文件读写操作的时候，要特别注意测试文件操作带来的内存问题。比如说，有些系统需要用文件记录系统最高分或分值等，要注意测试第一次运行程序时的退出操作(此时没有最高分记录或其他分值记录)，程序是否申请了文件指针或文件资源而没有释放。如果是的话，则会导致退出时的内存错误。另外对于Brew，应用程序的文件包中不得包含零字节的文件，每个文件至少有一个字节，同时还要求不能包含无用的文件或文件夹，目的是节省手机上有限的存储资源。

9．颜色的搭配，有些背景色跟文字或图片的颜色搭配在模拟器可以较清晰的显示出来，但是到了手机由于其分辨率问题就不那么明显了。颜色搭配要以清晰美观为基础，还要适当考虑系统的种类，用户心理等问题。

10．用模拟器模拟网络不通的情况。目的是测试软件的网络连接，网络资源请求，缓冲区存储等模块的性能，看看内存是否有正确释放等。可以通过断开网络连接的方法模拟手机网络不通的情况，具体就是把本地连接的状态设成禁用或者直接拔掉网络连接线。

11．数据请求或传输等需时较多的过程要确保有提示界面，最好有动画显示数据在传输过程中，请用户耐心等待。另外要注意在这个过程中对重复按键予以忽略，因为等待时间过长或响应迟钝时，用户趋向于重复按手机按钮。

12．不要忽略了对后台数据正确性的测试。输入特殊字符或异常字符，看后台有没有相应的容错处理(当然这些也可由手机端处理)。多个客户端同时发出请求，测试后台的多线程处理能力，看能同时处理多少用户的同时请求，平均响应时间是多少，是否在可接受范围内。

13．来电，短信，电量不足等一些事件警告的出现也有可能导致程序出错，也要作出相应的处理。有些网络程序由于设置了数据通讯时不处理来电，这时候就要在低电量情况下测试，用电量不足的警告事件来触发程序的suspend和resume处理事件，看是否做了恰当的处理。

版权声明：本文出自 qiuteng258 的51Testing软件测试博客：http://www.51testing.com/?178314

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。