斑竹~手机测试的同行们进啊！里面发大水了！
你可不可以把所有的关于手机测试的内容放在一起啊！那看起来和找起来就方便多了！
可以都放在我这里！谢谢了！
手机测试
来自“测试管理中心”DISCOVERY
http://www.testmanager.com.cn/
我从事手机测试。比较忙，作为这里斑竹，是不合适的，其一，本人经验不是很丰富，其次，本人的水平也不是很高，最重要一点，因为精力有限，不能很好照顾这里。但是我很愿意把一些心得体会，和大家分享。
由于手机测试涉及公司机密，所以在不泄露公司机密前提下，我尽量让大家一起学习，分享我知道的知识和技能。
手机测试是一个很大的题目，涉及到硬件测试和软件测试，还有结构的测试，比如抗压，抗摔，抗疲劳，抗低温高温等，结构上的设计不合理，会造成应力集中，使得本身外壳变形，对于翻盖手机，盖子失效，还有其他严重问题。硬件测试一般都有严格的物理电气指标，也有专门的仪器，这里的仪器，不在多说，一般如果是专业的测试人员，不会对词陌生吧。
因为我们人员编制问题，所以我对于各项测试，都或多或少了解一点，甚至从事过。。
但是手机测试，一般是指软件测试，这个一方面也说明了软件在手机上的重要行。一方面也说明手机测试的难度。因为期他得测试都有明确的指标，严格的操作规程，还有各种仪器。下面说的手机测试一般都是手机软件测试，以后不在重复说明。
因为工作原因，没有及时回复大家要求，这里先回答一点，希望大家一起参与，毕竟我一个人精力有限，知道也少。
这里就作为前言部分吧
在说明手机测试之前，我觉得应该了解一下什么是嵌入市操作系统，这是个时髦的名词，虽然我们已经被嵌入市操作系统的产品所包围，但是却不一定能说清楚，什么是嵌如实操作系统，而学校的课堂上，讲的也不多，所以很多人对此感到云山舞罩。
简单的说，一个嵌入市操作系统就是为完成某中特定功能而专门开发的操作系统。这个操作系统的功能很明确，不象大型操作系统，范围广泛，大千世界，尽在其中，而嵌如操作系统只为完成某一项或者几项功能。
再说一下手机的特殊性，也就是要求对响应时间达到一定限制范围。也就是所谓的实时操作系统，如果一个电话不能在90秒内接听，那么对方会挂掉
而你的操作系统还没反映过来，那么这个操作系统无疑是失败的，这是对嵌如操作系统实时性的要求。
作为一个测试人员，你必须了解这些，可能对一些软件开发人员，他不必很在意这些方面，因为他只要了解自己模块的入口说明和 出口说明就可以。但是测试人员不行。高级测试人员应该了解嵌入操作系统的特点，这个系统不象WINDOWS，有图形界面可以输入输出，也不象D OS用命令行模式，所有这些，都需要自己编写一个编辑器，编写一个交互界面，编写一个输入输出界面，在WINDOWS中，利用一些API和一些M FC，不用考虑硬件的问题，因为系统已经完成，而WINDOWS是讲究和硬件分离的，因为这样可以保护系统不受侵入。而在嵌入市系统里面。这一些都要求和硬件息戏相关。
手机测试中，软件出现的故障不一顶是由于软件的错误，也可能是由于没有考虑到硬件和软件没有完美的结合。
因此我们在了解操作系统同时，也要了解一下其他的手机硬件性能，比如CPU ，比如存储器。
CPU的处理运算能力是以MIPS来衡量的，当然越快越好，但是也是和成本相关的，我不知道现在MOTOROLA T39的CPU，但是，因为是PDA，又是手写屏幕，所以菜单特别的慢。关于存储器需要专门做出说明，因为这里 的存储器很特别，不象PC，手机没有硬盘！
作为一个新来的，可能对嵌入时操作系统游乐 一个大致了解了，那么对他的程序又是如何的呢，难道是和以前的程序不一样？
其实，嵌入时系统的编程语言一般有C，而且也是最多的，也有其他语言。比如C++在最开始时候是用 汇编的，但是汇编难懂，而且也不容易移植，渐渐的被C代替，不过即使如此，在启动程序时候，要启动板子，也就是电路板时候，还是需要用一些汇编语言完成。
作为一个嵌入市系统的程序，和在PC上运行着的程序没有任何不同，唯一不同可能是在PC上运行的程序，你可以看到结果——如果你用输出语句的话，而在这里，你是看布道结果的。除非你加上L CD硬件，然后编写了LCD驱动程序，然后再编写显示 程序。编写嵌入市程序，一切都要自己解决。
我们的手机如果不是认为把电源切断的话，或者在电源消耗到一定程度的话，是会一直在使用的，所以，手机程序是一直在运转的，就是说一直在循环，这个，对于了解嵌入市程序，应该是个好材料——嵌入市程序就是一个无限循环的程序，除非关掉电源和电源因素，这里也有一个测试点：硬件中断是最高级的，它会终止你的程序，即使你现在的程序级别很高，比如通话，如果没电了，一切会o ver.
手机程序就是在一个无限循环的程序，什么时候跳出这个无限循环？你关机吧，如果感到不高兴，把电池卸下来，因为有可能进入死循环，而关机键失效了，——只好通过取下电池了。
这里要专门说明一下存储器，因为很多手机毛病都和存储有关，而且很多问题都和存储相关，计算机的存储是关键，而手机更始关键，因为计算机有硬盘作为存储，而手机所有的都在存储器里
存储器分为几类，RAM 随即存储器，ROM随即只读存储器还有现在出现一些的闪存，以及电子可编程存储和非易失存储起。一个一个到来
RAM 随机存储器，其中又有SRAM（静态RAM）DRAM（动态RAM），
SRAM，只要只要电源开着，就会保存，我们打电话，有些最后拨打的号码，暂时是存在SRAM中的，不会立刻写入通话记录。只有正常关机，才会写入，如果取电池的话，是不会写入手机的通话记录的，如果在通话记录中出现了已经拨打电话，但是没有记录的情况，那么有可能和这个存储器有关，
可能是你的软件上错误，也可能是硬件。
DRAM在手机上用的不多，因为保留数据时间很短，
从价格上看，SRAM是非常昂贵的，而DRAM相比很便宜。
ROM也有几种，PROM可编程ROM 和EPROM可擦除可编程ROM两者区别是，PROM是一次性的，也就是软件灌入后，这个就完蛋了，这种是早期的产品，现在已经不可能使用了，而E PROM则是通用的存储器，这些存储器不符和手机软件产品，一般使用ROM少
其他FLASH
这是近来手机采用最多的存储器，这种存储起结合了ROM和RAM的长处，但是不属于RAM也不属于ROM
手机大量采用的NVRAM 非易失存储器 和SRAM属性差不多，EEPROM 电子可擦出可编程存储器 ，闪存，ROM的后代。手机软件一般放在EEPROM中，EPROM是通过紫外光的照射，擦出原先的程序，而EEPROM是通过电子擦出，当然价格也是很高的，而且写入时间很长，写入很慢，所以前面提到的电话号码，一般先放在S RAM中，不是马上写入EEPROM，因为当时有很重要工作要做——通话，如果写入，漫长的等待是让用户忍无可忍的。
NVRAM 是一个很特别的存储器，它和SRAM相类似，但是价格却高很多，由于一些数据实在重要，断电后必须保持这些数据，所以只能存放在这里，一般和个人信息有关的数据会放在这里，比如和S IM卡相关数据。容量大小也只有几百字节。
闪寸存储器是所有手机的首选，综合了前面的所有优点，不会断电丢失数据（NVRAM）快速读取，电气可擦出可编程（EEPROM）所以现在手机大量采用，
说了这么多存储器，可能比较糊涂了，这么多存储器，究竟采用哪中呢，在手机发展中，各种存储器都用过，至于现在，各种手机采用的存储器是不同的，这个和成本相关，各种存储器价格不一样，本着性价比最优组合，由设计者决定，有些是可选的，有些是必须的，是手机方案决定的，我们了解只是各种存储性能，特点，在测试中判断错误原因。
手机协议站软件的白合测试
手机软件测试单丛测试的内容来看，包括上面的MMI和底下的PROTOCOL
由于MMI的灵活性，和各个厂家的个性化，以及手机本身的用户不同，
MMI的侧重点也就不同，在基本通话、短消息、数据功能完成的基础上
可以五花八门，所以测试的重点不同。测试方法各不相同。
但是协议就不同了，协议是统一的，虽然你实现方法可以不同，但是
完成的功能必须相同，和MMI不同，虽然都是聊天，但是有些用短消息
聊天，有些用PUSH聊天，而协议软件有一个遵守的规范——ETSI指定
的协议规范，有统一的命令规范和统一的标准。消息（术语，不是软件
编程里的消息，是通信术语）是固定的嘛。
针对协议的测试，因为有标准可循，有规范可仪，所以软件测试就
很多工具，公司也多，自动化测试要自动话，否则，按照人的
测试能力，谁也无法保证其绝对可靠性，也没有这么大的人力去仔细做
测试。 一般对于白合测试是比较严格的，而且也是耗费人力的，所以常采用自动
化测试工具。这样节省人力、缩短测试时间。至于谁家的工具比较好，
涉及各取所需吧，也涉及到成本问题。你如果想购买某产品，会给你一个
DEMO版本，给你一个月的评价时期，这个评估版本让你熟悉其产品的优劣
也让你熟悉其操作。
测试工具一般都有二次开发功能，也就是可以自己编写脚本，针对不同的
软件平台做一些改动，这样可以根据自己的需要编写测试CASE测试用列
当然即使是全部用自动化测试，你心理还是没底，你还是要仔细去看代码。
分析流程，读懂其含义，一个很小的问题，出错保护没有作好，一般这个
问题最多，出错保护机制没有作好，会造成崩溃这样严重的问题。
这是针对协议代码的白合测试
如果你是对购买来的协议进行测试，一般有仪器，模拟一个网络基站，进行
测试，不过这样的仪器非常昂贵，而且测试人员要对ETSI协议比较熟悉。
我没有直接参加针对协议的白合测试，不过对评估般的测试软件曾经PRACTISE，
可测试覆盖率，我很奇怪的是，一般打点（跟踪）也是需要消耗CPU时间的
这样程序效率就降低了，而我要测试程序的效率等项目就要考虑CPU，而且
程序的工作运转必须和CPU息息相关，而现在CPU 在保证程序RUN同时，还要
进行打点，是否测试出的指数和实际不符和呢，是否没有达到真实的水平呢
而它这个产品（水牛）介绍说，一般不占用CPU时间，我想了很长时间没有想通
后想咨询，告之这是他们的专利，无可奉告。由于这种测试工具是针对平台
所以如果你平台不支持的，也就没有办法使用了。还有集成测试等等，在软件
的介绍中有详细说明，不再详细说明。
对协议进行白合测试，我想对你的要求就是：熟悉相关的协议，否则白扯；
熟悉开发的语言，否则免谈。
总之，我估计你们公司如果进行白合测试的话，我想测试工具是不可少的，
希望你顺利完成测试任务。早日听到好消息
[ Last edited by tigerzhang on 2005-1-24 at 08:58 ]
大家如果有好东西贴在上面哦！
问:压力测试与性能测试有什么区别呢答:压力测试：对系统不断施加压力的测试，是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。例如测试一个 Web 站点在大量的负荷下，何时系统的响应会退化或失败。
性能测试：在交替进行负荷和强迫测试时常用的术语。性能测试关注的是系统的整体。它和通常所说的强度、压力/负载测试测试有密切关系。所以压力和强度测试应该于性能测试一同进行。
举例说明：针对一个网站进行测试，模拟10到50个用户就是在进行常规性能测试，用户增加到1000乃至上万就变成了压力/负载测试。如果同时对系统进行大量的数据查询操作，就包含了强度测试。
顶一下
Bad User TestingHow can you be sure that an application will behave properly when users perform actions or combinations of actions that were not considered during the development of the functionality? During the testing phase, you have to plan for what is sometimes called "bad user" testing, or negative testing.
Boris Beizer's definition of negative testing in "Software Testing Techniques" is: "Testing aimed at showing software does not work".
In his paper, "A Positive View of the Negative Testing", James Lyndsay stated the objectives of bad user testing to be:
Discovery of faults that result in significant failures; crashes, corruption and security breaches
Exposure of software weakness and potential for exploitation
Observation and measurement of a system's response to external problems
Why Is Bad User Testing Important?
During negative or bad user testing, the tester seeks to abuse the functionality of the product in an effort to create odd program states by exercising functionality that deals with state management, input validation, boundary conditions, fault recovery, and more.
Bad user testing is generally performed as part of integration or system testing and does not have a distinct phase of its own. The basic principle to follow is if the tester can perform bad user tests without error, there is a significantly lower chance that the users will inevitably find such defects later on.
As Lyndsay points out in is his paper, negative testing can find significant failures and also can produce invaluable strategic information about the risk model underlying testing, and allow overall confidence in the quality of the system.
Where To Start?
It is possible to design a bad user test plan starting from the specification documentation. The most important thing to keep in consideration when designing a bad user test plan is to not test what is described, but what is not. The tester should look at the specification documentation as a guide to what the boundaries of the software and then look beyond the boundary to the extreme edges of the software's functionality. Employ your creative destructiveness to take you beyond these boundaries and perform actions and tasks that you are sure will fail, or should be impossible. These are the areas where the most interesting defects can be found.
Of course, each product is specific and all tests cannot be applied in all circumstances. The few brief examples below can be used as a guide when starting a bad user test plan. Use your creativity to add to and expand this list.
Generic Bad User Test Scenarios
What is expected behaviour when you:
Manually shut down, or reboot, the computer while the application is running
Manually restart the computer by pushing the reset button while the application is running
Restart the computer while the application is running using the start menu
Log off while the application is running
Boundary Test Scenarios
What is expected behaviour when you:
Attempt to go below the minimum input limits
Exceed the maximum input limits
Stress Test Scenarios
What is expected behaviour when you:
Run the program concurrently with many other programs
Set memory to a stressed state (low Virtual Memory, low RAM)
Run on slower or older machines
Load large volumes of data
Create large numbers of concurrent connections or open files
Performance Test Scenarios
What is expected behaviour when you:
Test on a system lower than the minimum configuration requirements
Open extremely large files
Attempt to import a corrupt file
Create a situation requiring an error message
Install/Uninstall Test Scenarios
What is expected behaviour when you:
Run the installation script again while the application is running
Cancel the installation midway through the install using the task manager
Install the application onto a hard drive without enough free space
Install the application onto a network drive and disconnect the drive partway through
Uninstall the application when the application is still running
Change or remove the registry settings before trying to uninstall the application
Summary
Bad user testing is performed by the tester to find weaknesses in the design or the code by attempting actions that are likely to occur after deployment. Although it is hard to make predictions about real-world use, real users will find all ways of using the system including those that were considered unreasonable or improbable.
Including this type of testing as part of your project will result in a more robust and user-friendly application and will of course save effort and costs after the product is released.
压力测试
重复原则目标:根据客户通常会重复使用功能.
过程:
测试的重复,就是一遍又一遍地执行某个操作或功能.
简单地扩展功能验证测试来多次重复并不能构成一个有效的压力测试，当与下面的一些原则结合起来使用时.
方法：使用重复时，操作间的时间间隔、重复的次数，或者也可以改变被重复的顺序.
并发原则
目标:并发是同时执行多个操作的行为.
过程:
同一时间执行多个测试.
方法:与重复原则结合在一起,应用许多代码路径和定时条件；并发的服务数目及时间．
量级原则
目标：考虑到了每个操作中的负载量.
过程：操作自身也要尽量给产品增加负担.
E.g: 发送消息，可以输入超长消息,…
方法:单独的高强度操作自身可能发现不了代码错误（或者仅能发现功能上的缺陷），但与其他压力原则结合在一起时.
随机原则
目标：测试软件产品的随机变化性.
过程:
每次测试运行时应用许多不同的代码路径.
方法:使用基于一个固定随机种子的随机变化，这样容易复制问题． 压力测试和负载测试
在性能列表中最常问的问题是：“是否有一种工具可以帮助我对 J2EE 应用程序进行
压力测试？” 在回答这个问题之前，让我们问一问自己：压力测试是什么，为什么
这些开发人员需要它？（我相信你们中相当一部分人曾经遇到一定要在昨天完成测试
这种让您感到压力的情况，但是我们在这里说的不是这个）。压力测试是为了发现在
什么条件下您的应用程序的性能会变得不可接受。这通过改变应用程序的输入以对应
用程序施加越来越大的负载并测量在这些不同的输入时性能的改变来实现的。这种操
作也称为负载测试，但是负载测试通常描述一种特定类型的压力测试——增加用户数
量以对应用程序进行压力测试。
对应用程序进行压力测试最简单的方法是手工改变输入（客户机数量、需求大小、请
求的频率、请求的混合程度，等等）并描绘性能的变化。对于一些应用程序，您需要
做的就是这些。但是如果有许多输入，或者需要在大的范围内改变输入，那么就可能
需要一个自动化的工具。另外，在手工测试中，如果想在进行一些改变后重新测试应
用程序，可能很难精确地重复一组测试。如果是让多个用户测试您的应用程序，那么
几乎不可能一致性地运行手工测试，除非您有很多失业的朋友，否则扩大测试应用程
序的用户数量是非常困难的。
没有一刀切的方案
不幸的是，没有一种通用的压力测试工具，因为每一个应用程序所接受的输入以及对
它们进行处理的方式都是不同的。但是对于许多 J2EE 应用程序来说，从客户机到达
服务器的通信使用的是 HTTP 协议。幸运的是，有许多负载测试工具可以以一种可控
制和重复的方式模拟 HTTP 上的用户活动。它们包括免费工具如 Apache
JMeter、The Grinder 以及 PushToText，和相当昂贵的工具如 Mercury Astraload
。一般来说一分钱一分货——工具越贵，它能做的事情就越多。为了了解它们的差别
，我们首先来看最基本的负载测试工具能做些什么。
如果您想构建自己的负载测试工具，那么您会首先编写一个对每一个模拟客户机运行
一个线程的程序。每一个线程需要与服务器通信，可能使用 java.net.URL 类。这种
方法使您得到基本的 HTTP 客户机模拟，它可以执行 GET 和 PUT。每个线程需要做
的就是发送 HTTP 请求、收集回复、等待一些时间（模拟“考虑时间”），再重复。
这一组行动可以相当容易地抽象到一个单独的配置文件中。很快，您就得到一个基本
的负载测试工具。您可能需要增加一些配置选项以确定运行多少个线程（模拟的客户
机）以及它们是同时开始还是慢慢增加负载。当然，您需要对与服务器的交互计时，
因为这是您要测试的核心内容。
如果这么简单……
那么，对于处理扩展的交互（即一个请求取决于上一个请求的结果）如何呢？对于处
理 cookies 如何呢？cookies 对于许多面向会话的 J2EE 系统是必不可少的。改变
数据输入呢？如果 J2EE 应用程序客户机需要处理一些 JavaScript 以进入下一次通
信呢？在收集了响应时间数据后，如何对它进行分析？其他类型的监视，如 CPU 时
间、网络使用、堆大小、分页活动或者数据库活动呢？
像这样和其他的功能，如用于记录浏览器会话并将它们加入到测试脚本中的工具，是
高端负载测试工具与基本工具的差别所在。如何为自己选择正确的工具呢？当然，这
取决于您的需要、您的计划和您的预算。最重要的是，您需要使用可以正确地模拟您
的应用程序要求的客户浏览器功能的工具。具备了基本功能后，可以考虑工具的生产
率。一般来说，包含的分析工具越多，可以记录的性能数据类型越多，您可以达到的
生产率就越高——您愿意付的钱也就越多。顶级的负载测试程序可以模拟多个浏览器
，与大多数应用服务器集成，收集多个服务器主机的性能数据（包括操作系统、JVM
和数据库统计数字），生成可以在以后用高级的分析工具分析的数据集。另一方面，
低端负载测试程序是免费的。在那些预算有限的日子里，“免费”的意义是不言自明
的。
图 1 展示了免费的负载测试程序 Apache JMeter，它显示了一个自动记录的脚本。
图 1. JMeter 显示一个自动记录的脚本
丰富的功能
我们已经看过了压力测试工具的基本功能，还适合增加什么附加功能呢？不同的负载
测试工具的区别在什么地方呢？当然，您最主要的要求是这个工具必须可以模拟您的
应用程序客户机。如果您的应用程序使用一些不常见的浏览器功能组合或者其他非标
准客户机技术，那么就排除了相当一部分候选者。除此之外，还有其他功能使负载测
试的生产率更高。对于决定适合于自己项目的负载测试工具，下面的列表是一个有用
的出发点：
模拟您的客户机
首要要求一定是负载测试程序能够处理您的应用程序所使用的功能和协议。
运行多个模拟的客户机
这是负载测试程序最基本的功能，它有助于确定哪些是负载测试程序以及哪些不是（
一些框架试图伪装成负载测试程序）。
脚本化执行并能编辑脚本
如果不能编写客户机与服务器之间交互的脚本，那么就不能处理除最简单的客户机之
外的任务东西。编辑脚本的能力是最基本的——小的改变不应该要求您重新生成脚本
。
支持会话
负载测试程序如果不支持会话或者 cookies，那么就不算是真正的负载测试程序，并
且不能对大多数 J2EE 应用程序进行负载测试。
可配置的用户数量
测试程序应该可以让您指定每个脚本由多少个模拟用户运行，包括让您随时间改变模
拟用户的数量，因为许多负载测试应该从小的用户数量开始，并慢慢增加到更多的用
户数量。
报告成功、错误和失败
每一个脚本都必须定义一个方法来识别成功的交互以及失败和错误模式（错误完全不
会有页面返回，而失败可能在页面上得到错误的数据）。
页面显示
如果负载测试程序可以让您检查一些发送给模拟用户的页面，这会很有用，这样您就
可以确保测试工作是正确进行的。
导出结果
您常常希望可以用不同的工具来分析测试结果，这些工具包括电子表格和可以处理数
据的自定义脚本。虽然许多负载测试工具包括大量的分析功能，但是导出数据的能力
使您在以任意的方式分析和编目数据方面具有更大的灵活性。
考虑时间
真实世界的用户不会在收到一页后立即请求另一页——一般在查看一页和下一页之间
会有延迟。 考虑时间 这个标准术语表示在脚本中加入延迟以更真实地模拟用户行为
。大多数负载测试程序支持根据统计分布随机生成考虑时间。
客户机从列表中选择数据
用户一般不会使用同样的一组数据，每位用户通常与服务器进行不同的交互。模拟用
户应该也这样做，如果在交互的关键点，脚本可以从一组数据中选择数据，则可以更
容易地让您的模拟用户表现出使用不同数据的行为。
从手工执行的会话记录脚本
相对于编写脚本，用浏览器手工运行会话并记录这个会话然后再编辑会容易得多。
JavaScript
一些应用程序大量使用 JavaScript 并且需要模拟客户机支持它。不过，使用客户端
JavaScript 可能会增加对测试系统上系统资源的需求。
分析工具
测量性能只是成功的一半。另一半是分析性能数据。谁能比编写测试工具的人能更好
地开发这种分析工具呢？是的，至少理论是这样。无论如何，您的工具箱提供的分析
工具越多，您就能做得越好。
多谢楼主的总结!
手机测试也不是很难,只要做到测而有序就没有问题了,性能很重要,多看这方面的书籍会是提高技能的很好方法!谢谢楼上的!
至于那些帖子不是我的.我只是把那些我看到的,然后总结在一起.如果大家看到有关的东西请贴上去!谢谢拉:p
[ Last edited by tigerzhang on 2005-1-24 at 10:36 ]
谢谢楼主！！
您辛苦啦！ 您辛苦了谢谢啊~:p
不错！
谢谢楼主，辛苦了，希望您能继续支持我们，给大家更多的学习机会：）转载
1、参照手机：GSM制式2、参考标准：
GB/T 18905.5-2002 软件工程产品评价 第五部分 评价者用的过程
BG/T 16260-1996信息技术 软件产品评价质量特性及其使用指南
3、评判依据：
各公司的标准定制的不一样，有些公司可能更细化些，在这里仅作一个粗略依据。产品的好坏由用户说的算，一切为用户服务！
依据：软件研制规范，软件需求说明书，用户手册（罗嗦两句，国外的说明书写的很细，比如不可以用电熨斗烧咖啡，国内的使用说明书绝对不会这么写的，但是使用说明书上具有的功能在产品上如果没有的话，可就是不符合项喽）。
4、基本功能说明：
添加、删除、修改、查找
设置（各MMI不一样，在这里不进行举例）
批量操作：SIM卡记录复制到手机，手机记录复制到SIM卡，SIM卡记录移动到手机，手机记录移动到SIM卡……
5、功能测试：
在这里只讨论名片夹的功能性和可靠性的测试，对名片夹模块的易用性，效率，维护性以及可移植性不做考虑。
按是否通过测试，则分为两种，顾名思意即通过测试和失败测试。通常的失败测试，也就是说要设计测试用例，迫使软件出错。通过测试则是要保证软件实现基本功能。
5.1 基本功能测试：
手机输入法有很多种，比如T9,拼音，字母，数字等等。在编写测试用例的时候，首先要保证各输入法是否能正常输入；能否正常保存；在进行错误输入的时候，是否有响应的提示。在这里举出几个例子：
5.1.1、存储在SIM卡上的记录
5.1.1.1、添加：
1）姓名输入：
i)是否可以使用任意输入法添加汉字、字母、数字，达到姓名允许的最大字节，并能正常保存。
ii)是否可以使用任意输入法添加汉字、字母、数字，在没有进行输入时，是否有警告提示或是否可以正常保存（根据产品要求）。
iii)是否可以使用任意输入法添加汉字、字母、数字，超过姓名允许的最大字节，是否有告警提？是否可以正常保存。
iV)是否可以进行汉字、字母、数字的混合输入，并重复i~iii，是否有异常。
2）电话号码的输入：
i)是否可输入数字至最大值，并可正常保存。
ii）在不输入数字时，进行保存时，是否有告警提示。
iii）是否可以输入汉字，字母，此时是否有告警提示或异常。
iv)是否可以输入特殊字符，如+、P、*、#，是否可以正常保存。这里给介绍个出错的案例：连续输入多个*，P或+，不按电话的号码的正常顺序进行输入，试试，比如"++139***P123",看看是个什么样的效果，是否显示正常。
3）在输入过程中按返回键、挂机键、或翻合翻盖、电源键，是否有告警提示或异常。
4）在各MMI界面下，各按键功能是否正常。
5）待机界面下直接输入数字至最大值，是否可以正常保存。
6）待机界面下直接输入数字即特殊字符（＋，P），是否可以正常保存。
7） 将1），6）步骤进行一下排列组合，查看是否有异常情况。
1对2，2对4，4对16，所以测试用例经常的几千条，几万条根本就不希奇，一个名片夹写上1K条也之是写了个小部分。呵呵，罗嗦话又一堆。继续......
5.1.1.2 修改
1）单条记录的修改：
是否可以对单条记录进行修改，包括姓名和数字，并重复5.1.1.1中的1），2），3），4）各步骤。
2）连续多条记录进行修改
此条的测试目的是对软件进行压力测试。
5.1.1.3 删除
1）对单条记录进行删除
i）删除后，列表显示是否正常；数量是否正确。
ii）SIM卡记录为空时，进行删除时，是否有告警提示。
iii）SIM卡记录仅为一条时，删除后，是否有SIM卡内容为空的提示。
iv)在删除过程中，各功能键是否正常。
v）在删除过程中，进行中断操作，是否正常，比如挂机键，电源键等等。
2）对多条记录进行删除，目的是对软件的进行压力测试。
i）连续对SIM卡的多条记录进行删除，是否出现异常情况。
ii）删除SIM卡记录直至为空时，是否有异常。
iii）在删除过程中，各功能键是否正常。
5.1.1.4 查找
由于各手机的查找功能定制的不同，在这里不做累述。
5.1.2 存储在手机上的记录
存储在手机上的记录和存储在SIM卡上的记录的测试用例基本相同。在测试过程中需要留心的是SIM卡的存储容量以及手机的存储容量，由于软件的定制不同，往往在不同处易出现故障。比如SIM卡的姓名栏可存储5个汉字，或8个字母、数字，电话号码可以存20位，手机的姓名栏目可以存12个汉字，20个字母、数字，电话号码可以存30位。在这个不同点之间就容易出现故障。
5.1.3 批量操作
5.1.3.1 SIM卡记录复制到手机
1） 1条SIM卡的记录复制到手机。要求：
i）姓名为1个字母或数字或一个字，手机号码是1个数字或特殊字符（＋，p）；
ii）姓名为满的字母或数字或字符，手机号码是满的数字或特殊字符（＋，p）。
2）将SIM卡的记录全部复制到手机。前提：SIM卡的容量有限，有的是70（如动感地带，易通卡），有的是大容量卡有200甚至250条的记录容量（如全球通，各地区的SIM卡容量不通，在测试过程中要考虑到对卡的兼容性），保证手机的每条记录是满记录，即姓名栏的字母，数字或汉字为满，号码栏的数字为满。将记录全部复制到手机，查看是否有异常。通产这时候问题就出来了，因为是批量性的复制，和手机的处理能力是有一定关系，此处比较容易出问题。
3）手机记录的容量通常比SIM卡的容量要大许多，这里在谈一下该处的测试要点。
前题条件：SIM卡的每条记录全满，即姓名和电话的容量全满。
i）SIM卡记录全部复制到手机，直至手机记录满，是否有相关的提示，例如：手机记录满，手机空间不足，是否继续进行复制；部分记录将会丢失的字样；
ii）手机是否可以读取大容量的SIM卡，并包括全部的手机记录，并能进行正常的查找。此处，可以连续的单条删除手机或SIM卡记录，直至删空，查看是否有异常。
5.1.3.2 手机记录复制到SIM卡
说明：手机的记录由于设计不同，有的手机是一个姓名对应1条记录，有的是一个姓名对应多条记录，具体根据实际情况。
i）将1条手机记录复制到SIM卡上，是否正确复制。
注意：手机记录中的姓名栏可能和SIM卡姓名栏的字数不相同，这时需要注意异常现象。另有的手机支持的是一个姓名下有若干条手机记录，是否可以将若干条记录全部复制到SIM，且无异常现象。
ii) 将全部满的手机记录，即手机存储的条目数满，姓名栏的字全满，手机号码的字数全满，全部复制到SIM卡，查看是否有异常。
注意：SIM卡的空间和手机空间容量在相等，或不相等的情况下，在复制的过程中均有提示，例如：SIM卡空间满；空间不足；空间不足，如进行复制，会有部分数据丢失等告警提示。
5.1.3.3 SIM卡记录移动到手机
SIM卡记录移动到手机同5.1.3.1 SIM卡记录复制到手机的测试方法基本相同。注意的是在移动后，SIM卡内容清空。
5.1.3.4手机记录移动到SIM卡
手机记录移动到SIM卡同5.1.3.3 SIM卡记录移动到手机的测试方法基本相同。由于各手机设计不同，有一个姓名对应一条记录和一个姓名对应若干条记录的情况，注意在移动过程中出现异常现象。
5.1.3.5 综述
从上面的测试方法已包含了等价测试和边界测试。下面将对测试过程中加入的其它环节进行描述。
1）中断：短信，MMS，来电，闹钟，功能键，挂机键，翻盖等等。在进行上述操作时，在每一个界面下，均需进行中断操作，并根据软件需求说明，对异常情况进行定位。
2）在进行每项操作时，均应有提示，确认是否进行该操作。由于各手机软件需求不同，在测试过程中可根据实际情况或根据用户反馈情况进行。
3）在SIM卡记录或手机记录满的情况下，添加记录，查看是否有相关提示或异常。 楼主的帖,让我想到了,网游的挂机程序也是这样的写出来的 呵呵，好贴，学了不少东西。刚接触手机测试 好贴．楼主，真的是感谢！
这对于手机最后把关的系统测试起到了很大的作用！ thank u！ 好 东西!!收益非浅啊! 这么多项内容，人工测不会死人吗？
我想应该是用工具吧，
哪位师兄，师姐能告诉我，你是怎么测的？/
谢谢
页:
[1]
