手机APP测试
注：以下内容来自网络：
一、手机APP测试类型
1.1 接口协议测试
在APP客户端开发设计时，一般服务端会提供相应的接口协议文档，接口协议文档的质量，决定了APP的开发进度。此部分的测试，应首先检测接口的完整性， 根据APP需求，检查是否所有数据都有相应的接口返回；其次正确性验证，验证返回的接口信息是否正确，提示代码是否符合要求；第三：可采用Postman 等工具，对设计的测试用例进行测试。
1.2 易用性测试
易用性测试可分为UI原型和高保正图检测和APP测试。UI原型和高保真图可通过评审会议的形式检测；APP易用性是APP开发完成之后，可发布Beta版给公司内部员工或客户，并收集使用者的反馈信息。
1.3 功能测试
APP的开发模型一般为敏捷开发模型，所以测试也应是敏捷测试。测试过程我设计为三个阶段（1）冒烟测试（2）探测性测试->用例（3）回归测试； 首先对每个提交的功能模块快速进行冒烟测试，到可组合成完整功能模块时，进行探测性测试，当所有功能模块完成之后，进行相应的系统测试。若是运营级的产 品，可适当利用Robotium等自动化工具实现功能自动化测试。
1.4 终端适配测试
因为手机操作系统类型，版本较多，生产厂家也五花八门的，所以对手机APP进行终端适配测试决对是个体力活。对这部分的应试，应选择一定的策略，我一般分内部测试、云测试和用户测试三方面进行，具体如下：
1.5 性能测试
手机APP对平台的性能要求较严格，若存在性能问题，可能会出现严重的Crash问题，因此，对APP进行性能检测试很有必要的。进行性能测试时，我们 可分五个阶段进行（1）Monkey压力测试，（2）手机内存泄漏检测，（3）手机CPU使用率检测，（4）手机缓存检测，（5）服务器性能测试。
1.6 网络测试
此部分测试，主要目的是发现各业务模块的业务流量，当添加第三方管理模块时，是否大量增加流量，可通过Sniffer+虚拟机工具进行检测。
1.7 其他测试
输入参数测试：针对输入的参数进行测试，也可以说是假定接口参数的不正确性进行的测试，确保接口对任意类型的输入都做了相应的处理：输入参数合法，输入参数不合法，输入参数为空，输入参数为null，输入参数超长；
功能测试：接口是否满足了所提供的功能，相当于是正常情况测试，如果一个接口功能复杂时推荐对接口用例进行结构划分，这样子用例具有更好的可读性和维护性。
逻辑测试：逻辑测试严格讲应为单元测试，单元测试应保持内部逻辑的正确性，可单元测试和接口测试界限并不是那么清楚，所以我们也可以从给出的设计文档中考虑内部逻辑错误的分支情况和异常；
异常情况测试：接口实现是否对异常情况都进行了处理，接口输入参数虽然合法，但是在接口实现中，也会出现异常，因为内部的异常不一定是输入的数据造成的，而有可能是其他逻辑造成的，程序需要对任何的异常都进行处理。
1、什么是手机软件测试
手机作为专用的消费类电子产品需要进行以下测试：可靠性测试(对于硬件则是RQT;对于软件则是field trial);标准符合性测试(FTA);互操作性测试(IOT);安全性测试(安规测试);强度测试等。
2、性能测试
性能测试强调长时间、重复或者高强度的进行某些操作，来验证产品在各种极限条件下的表现。性能测试隶属于软件测试中的系统测试，它对软件在集成系统中运行的性能行为进行测试，旨在及早确定和消除软件中与构架有关的性能瓶颈。
3、手机中的性能测试分类
(1)时间相关的性能测试可分为长时间保持测试和限定时间反应测试
(2)次数相关的性能测试是测试终端重复稳定地进行某项功能的能力
(3)并发测试主要是测试终端同时进行多项业务时表现出的处理能力，例如同时进行CS域语音业务和PS域下载业务，或者在MP3播放的同时进行WWW上网业务，以测试协议栈、操作系统和处理器对并发业务的支持能力
(4)负载测试主要是验证系统的负载工作能力。例如同时进行多个ftp下载，使下行传输率接近极限值，观察终端是否可以正常工作
4、手机性能测试的方法
手机性能测试的方法按照自动化程度不同可分为手工测试和自动测试。
(1)手工测试主要是通过测试人员手动操作，并借助某些监测仪器和工具，来验证手机性能
5、白盒测试、黑盒测试
白盒测试(White-box Testing，又称逻辑驱动测试,结构测试)是把测试对象看作一个打开的盒子。利用白盒测试法进行动态测试时，需要测试软件产品的内部结构和处理过程，不需测试软件产品的功能。白盒测试又称为结构测试和逻辑驱动测试。
任何工程产品(注意是任何工程产品)都可以使用以下两种方法之一进行测试。
黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。
软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：
1、是否有不正确或遗漏的功能?
2、在接口上，输入是否能正确的接受?能否输出正确的结果?
3、是否有数据结构错误或外部信息(例如数据文件)访问错误?
4、性能上是否能够满足要求?
5、是否有初始化或终止性错误?
软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：
1、对程序模块的所有独立的执行路径至少测试一遍。
2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。
3、在循环的边界和运行的界限内执行循环体。
4、测试内部数据结构的有效性，等等。
6、测试用例是什么
7、软件测试中的功能测试用例的书写方式
测试的来源，即测试的需求
测试用例的主要来源有：
1) 需求说明”及相关文档
2)相关的设计说明(概要设计，详细设计等)
3)与开发组交流对需求理解的 记录(可以是开发人员的一个解释)
4)已经基本成型的UI(可以有针对性地补充一些用例)
简而言之，所有你能得到的项目文档，都尽量拿到。 从所得到的资料中，分解出若干小的“功能点”，理解“功能点”，编写相应的测试用例。
一个优秀的测试用例，应该包含以下信息：
1) 软件或项目的名称
2) 软件或项目的版本(内部版本号)
3) 功能模块名
4) 测试用例的简单描述，即该用例执行的目的或方法
5) 测试用例的参考信息(便于跟踪和参考)
6) 本测试用例与其他测试用例间的依赖关系
7) 本用例的前置条件，即执行本用例必须要满足的条件，如对数据库的访问权限
8) 用例的编号(ID)，如可以是 软件名称简写-功能块简写-NO.。
9) 步骤号、操作步骤描述、测试数据描述
10)预期结果(这是最重要的)和实际结果(如果有BUG管理工具，这条可以省略)
11)开发人员(必须有)和测试人员(可有可无)
12)测试执行日期
窗体顶端
4个常见手机软件测试面试题及答案
什么是手机软件测试?手机作为专用的消费类电子产品需要进行以下测试:可靠性测试(对于硬件则是RQT;对于软件则是field trial);标准符合性测试(FTA);互操作性测试(IOT);安全性测试(安规测试);强度测试等。
什么是性能测试?性能测试强调长时间、重复或者高强度的进行某些操作,来验证产品在各种极限条件下的表现。性能测试隶属于软件测试中的系统测试,它对软件在集成系统中运行的性能行为进行测试,旨在及早确定和消除软件中与构架有关的性能瓶颈。
手机中的性能测试分类是什么? (1) 时间相关的性能测试可分为长时间保持测试和限定时间反应测试 (2) 次数相关的性能测试是测试终端重复稳定地进行某项功能的能力 (3) 并发测试主要是测试终端同时进行多项业务时表现出的处理能力,例如同时进行CS域语音业务和PS域下载业务,或者在MP3播放的同时进行WWW上网业务,以测试协议栈、操作系统和处理器对并发业务的支持能力(4) 负载测试主要是验证系统的负载工作能力。例如同时进行多个ftp下载,使下行传输率接近极限值,观察终端是否可以正常工作
手机性能测试的方法?手工测试主要是通过测试人员手动操作,并借助某些监测仪器和工具,来验证手机性能。但由于手机功能众多,并且性能测试工作量大,如果单个测试工程师靠手动按键来执行所有测试用例,花费的时间少则几小时,多则需要几天的时间,这样耗费大量测试时间的同时也容易让测试工程师产生疲倦甚至是厌倦心理,很容易造成测试的遗漏。手机测试中常碰到很多重复性高的工作,如发送数条 SMS 或者 MMS 以验证其收发成功率以及稳定性、连续进行多次呼叫、多次对文件系统进行添加删除操作、多任务多进程情况下的冲突测试以及极限测试等等,都是重复性高的工作,手动执行的话费时费力,如果能有一套自动执行的机制,将能大大提高测试的效率。由此产生了对手机自动化测试工具的需求。手机这种板机的MMI功能测试不同于基于PC上的MMI测试,后者借助PC平台,目前市场上已有非常多功能强大且通用的自动测试工具支持其测试,如比较典型的有Winrunner, Robot, Loadrunner等等,但这些工具通常不能兼容到象手机这种嵌入式系统中来。这就要求测试人员能够基于当前平台进行二次开发,来满足自动化测试的需求。
手机软件测试面试题 软件测试面试题
问题一：为什么要在一个团队中开展软件测试工作？
任何软件在开发过程中都会留下缺陷，带有缺陷的软件产品如果提交出去，可能会给公司带来不可估量的损失，我们必须在客户之前发现尽可能多的问题，从而保障客户满意。而发现问题的这个过程称之为测试。
问题二：简述你在以前的工作中做过哪些事情，比较熟悉什么。
此问题每个人都不一样。我自己的答案如下。
我主要的工作是系统测试和自动化测试，也曾少量涉及性能测试。在系统测试中，主要是对BOSS系统的业务逻辑功能，以及软交换系统的Class 5特性进行测试。性能测试中，主要是进行的压力测试，在各个不同数量请求的情况下，获取系统响应时间以及系统资源消耗情况。自动化测试主要是通过自己写脚本以及一些第三方工具的结合来测试软交换的特性测试。
问题三：你所了解的的软件测试类型都有哪些，简单介绍一下。
1. 基本功能验证。主要是对发布的版本进行一些最主要功能的测试。英文常见叫法是Smoking Test, Basic Verification Test或者Sanity Check。
2. 功能测试。主要是依据需求或者需求分析文档，对所发布的版本进行测试，看看是否满足需求，是否出现了不必要的功能。
3. 单元测试。是开发人员进行的测试之一，一般是开发人员对很小的模块，比如函数进行测试，一般来说，开发人员还需要开发相应的测试桩来进行此类测试。
4. 集成测试。在大型的开发过程中，软件是模块化进行开发的，将不同的模块揉合在一起的话，需要进行的测试就是集成测试。
5. 系统测试。当软件提交给测试组后，是对整个系统的所有功能进行测试，一般来说，功能测试是系统测试的一个部分。
6. 压力测试。主要是在很大性能的情况下，这个性能已经接近了系统的极限，看看系统运转的情况。
7. 负载测试。主要是用各种不同的性能去检测系统，采集各个数据在这些性能情况下的数据。
8. 黑盒测试。指系统对你来说是完全不透明的，只给你留下了输入和最终输出，这个是功能测试的方法之一。
9. 灰盒测试。指在了解部分系统内部工作机制的情况下，对于系统进行的覆盖性测试。
10. 白盒测试。主要是在单元测试和集成测试的情况下，开发人员已知代码，对这一段的代码进行全路径的覆盖测试。
11. 界面测试。主要是看用户界面的友好性和易用性，是否有文字或者排版错误，是否有输入限制等等。
12. 回归测试。一般是系统发现BUG，开发人员修改后，和BUG直接相关以及可能相关的功能进行的测试。
13. 安装和卸载的测试。
14. 恢复测试。主要是一个系统在发生了灾难的情况下，从错误中是否容易恢复。
15. 兼容性测试。一个系统在不同的语言，操作系统下的系统测试。
16. 安全测试。系统在遇到攻击或者类似情况下的表现。
17. Alpha测试。系统在给最终用户前，测试人员在实验室中模拟最终用户的测试。
18. Beta测试。由部分最终用户通过使用来进行的测试。
19. 比较测试。和其他具有相同或者类似功能的系统进行对比的测试。
20. 验收测试。一般是最终用户在接受产品前，依据自己所提出的要求进行的测试，很多情况下，验收测试可能委托第三方机构完成。
问题四：测试计划工作的目的是什么？测试计划文档的内容应该包括什么？其中哪些是最重要的？
软件测试计划是指导测试过程的纲领性文件。
包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法（最好是能先评审）。
问题五：你认为做好测试计划工作的关键是什么？
1. 明确测试的目标，增强测试计划的实用性
编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确
2. 坚持“5W”规则，明确内容与过程
“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
3. 采用评审和更新机制，保证测试计划满足实际需求
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
4. 分别创建测试计划与测试详细规格、测试用例
应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术
问题六：常见的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
1. 等价类划分
划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
2. 边界值分析法
边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
3. 错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.
4. 因果图方法
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.
5. 正交表分析法
有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。
6. 场景分析方法
指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。
问题七：您认为做好测试用例设计工作的关键是什么？
白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题
问题八：详细的描述一个测试活动完整的过程。
1. 项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后SQA进入项目，开始进行统计和跟踪
2. 开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。
3. 测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。
4. 测试用例完成后，测试和开发需要进行评审。
5. 测试人员搭建环境
6. 开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现BUG后提交给BugZilla。
7. 开发提交第二个版本，包括Bug Fix以及增加了部分功能，测试人员进行测试。
8. 重复上面的工作，一般是3-4个版本后BUG数量减少，达到出货的要求。
9. 如果有客户反馈的问题，需要测试人员协助重现以及回归测试。
问题九：以往是否曾经从事过性能测试工作？请尽可能的详细描述您以往的性能测试工作的完整过程。
曾经做过一套网管系统的性能测试，主要测试该软件在同时管理大量终端的情况下，在响应时间，CPU/磁盘/内存等参数是否满足要求。
也曾经做过软交换系统的呼叫性能测试，主要是测试软交换系统在有大量呼叫的情况下，响应时间，呼叫成功率，CPU/磁盘/内存等参数是否满足设计要求。
问题十：您在从事性能测试工作时，是否使用过一些测试工具？如果有，请试述该工具的工作原理，并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。
测试网管系统中，使用的Mimic来模拟终端，能够大量的节省成本。
测试软交换系统的时候，使用的Prolab来模拟终端并发送呼叫软交换，他完成了同时数百人才能完成的摘机拨号工作，主要工作原理是产生一些符合要求的IP包并发送给软交换系统，同时对软交换系统的回应进行处理，决定下一步动作。
问题十一：您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？
主要是保障在大量用户的情况下，服务能正常使用。
问题十二：在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？
1. 在传统的BugZilla中，BUG描述应该包括以下的信息
2. 和BUG产生对应的软件版本
3. 开发的接口人员
4. BUG的优先级
5. BUG的严重程度
6. BUG可能属于的模块，如果不能确认，可以用开发人员来判断
7. BUG标题，需要清晰的描述现象
8. BUG描述，需要尽量给出重新Bug的步骤
9. BUG附件中能给出相关的日志和截图。
高质量的BUG记录就是指很容易理解的BUG记录，所以，对于描述的要求高，能提供的信息多且准确，很好的帮助开发人员定位。
问题十二：BUG管理工具的跟踪过程
用BugZilla为例子
测试人员发现了BUG，提交到Bugzilla中，状态为new，BUG的接受者为开发接口人员
开发接口将BUG分配给相关的模块的开发人员，状态修改为已分配
开发人员和测试确认BUG，如果是本人的BUG，则设置为接收；如果是别的开发人员的问题，则转发出去，由下一个开发人员来进行此行为；如果认为不是问题，则需要大家讨论并确认后，拒绝这个BUG，然后测试人员关闭此问题。
如果开发人员接受了BUG，并修改好以后，将BUG状态修改为已修复，并告知测试在哪个版本中可以测试。
测试人员在新版本中测试，如果发现问题依然存在，则拒绝修改；如果已经修复，则关闭BUG。
问题十二：您认为在测试人员同开发人员的沟通过程中，如何提高沟通的效率和改善沟通的效果？维持测试人员同开发团队中其他成员良好的人际关系的关键是什么？
尽量能有面对面的沟通，如果做不到，那么尽量能直接通过电话沟通，如果只能通过Email等非及时沟通工具的话，强调必须对特性的理解深刻以及能表达清楚。
一是真诚，二是团队精神，三是在专业上有共同语言，当然也可以通过直接指出一些小问题，而不是进入BUG Tracking System来增加对方的好感。
问题十三：在您以往的测试工作中，最让您感到不满意或者不堪回首的事情是什么？您是如何来对待这些事情的？
某次性能测试覆盖不足，造成系统崩溃。
问题十四：你对测试最大的兴趣在哪里？为什么？
最大的兴趣就是测试有难度，有挑战性！做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章，是关于如何做好一名测试工程师。一共罗列了11，12点，有部分是和人的性格有关，有部分需要后天的努力。但除了性格有关的1，2点我没有把握，其他点我都很有信心做好它。
刚开始进入测试行业时，对测试的认识是从无忧测试网上了解到的一些资料，当时是冲着做测试需要很多技能才能做的好，虽然入门容易，但做好很难，比开发更难，虽然当时我很想做开发（学校专业课我基本上不缺席，因为我喜欢我的专业），但看到测试比开发更难更有挑战性，想做好测试的意志就更坚定了。
我觉得做测试整个过程中有2点让我觉得很有难度（对我来说，有难度的东西我就非常感兴趣），第一是测试用例的设计，因为测试的精华就在测试用例的设计上了，要在版本出来之前，把用例写好，用什么测试方法写？（也就是测试计划或测试策略），如果你刚测试一个新任务时，你得花一定的时间去消化业务需求和技术基础，业务需求很好理解（多和产品经理和开发人员沟通就能达到目的），而技术基础可就没那么简单了，这需要你自觉的学习能力，比如说网站吧，最基本的技术知识你要知道网站内部是怎么运作的的，后台是怎么响应用户请求的？测试环境如何搭建？这些都需要最早的学好。至少在开始测试之前能做好基本的准备，可能会遇到什么难题？需求细节是不是没有确定好？这些问题都能在设计用例的时候发现。
第二是发现BUG的时候了，这应该是测试人员最基本的任务了，一般按测试用例开始测试就能发现大部分的bug，还有一部分bug需要测试的过程中更了解所测版本的情况获得更多信息，补充测试用例，测试出bug。还有如何发现bug？这就需要在测试用例有效的情况下，通过细心和耐心去发现bug了，每个用例都有可能发现bug，每个地方都有可能出错，所以测试过程中思维要清晰（测试过程数据流及结果都得看仔细了，bug都在里面发现的）。如何描述bug也很有讲究，bug在什么情况下会产生，如果条件变化一点点，就不会有这个bug，以哪些最少的操作步骤就能重现这个bug，这个bug产生的规律是什么？如果你够厉害的话，可以帮开发人员初步定位问题。
问题十五：你的测试职业发展目标是什么？
测试经验越多，测试能力越高。所以我的职业发展是需要时间累积的，一步步向着高级测试工程师奔去。而且我也有初步的职业规划，前3年累积测试经验，按如何做好测试工程师的11，12点要求自己，不断的更新自己改正自己，做好测试任务。
问题十六：你自认为测试的优势在哪里？
有韧性
有能力面对挑战
有信心做好每一件事情
有比较好的教育背景
从以前的经理处都得到了很好的评价表明我做的很好
问题十七：当开发人员说不是BUG时，你如何应付？
如果确实是自己理解错误，则承认错误，没什么大不了
如果是需求不明，请项目经理补充清楚
如果双方理解不一致，且都不能互相说服，则请项目经理判断。
问题十八：你为什么想离开目前的职务？
问题十九：你对我们公司了解有多少？
问题二十：你找工作时，最重要的考虑因素为何？
工作的性质和内容是否能让我发挥所长，并不断成长。
问题二十一：为什么我们应该录取你？
您可以由我过去的工作表现所呈现的客观数据，明显地看出我全力以赴的工作态度。
问题二十二：请谈谈你个人的最大特色。
我的坚持度很高，事情没有做到一个令人满意的结果，绝不罢手。
问题二十三：一个测试工程师应具备那些素质和技能？
问题二十四：集成测试通常都有那些策略？
自上而下，自下而上，平面集成
问题二十五：测试结束的标准是什么？
从微观上来说，在测试计划中定义，比如系统在一定性能下平稳运行72小时，目前Bug Tracking System中，本版本中没有一般严重的BUG，普通BUG的数量在3以下，BUG修复率90%以上等等参数，然后由开发经理，测试经理，项目经理共同签字认同版本Release。
如果说宏观的，则是当这个软件彻底的消失以后，测试就结束了。
问题二十六：软件验收测试除了alpha,beta测试以外,还有哪一种?
第三方验收测试
问题二十七：为什么选择测试这行？
最开始么，公司安排的，然后么，干一行爱一行，发现测试中间还是有很多东西需要学习的，再就是测试中有很多东西值得改进和研究。
问题二十六：为什么值得他们公司雇用？
用自己的经验和其他同事一起发现更多的问题，同时不同行业的观点可以互相借鉴。
问题二十七：如果我雇用你，你能给部门带来什么贡献？
分享我的测试经验和测试技能，提高测试部门技术水平
3、给出了一个窗口界面 界面中有8处错误，要求标出着8出错误。
4、你现在用的是什么型号的phone？
你为什么选择这个phone？现在使用的phone有哪些主要的error？
二、面试（往届）
1、你做过手机游戏测试说说你做过的项目
2、说说你游戏测试时的测试流程
3、你在测试中发现过什么Bug
4、之前的手机游戏测试中涉及过自动化测试吗
5、你为什么要转成做手机测试
6、你还有什么其他问题
三、面试（应届）
1、你实习时的主要工作职责
2、无线通信协议GSM，GPRS，CDMA…了解吗
3、手机测试主要分为哪几个领域
4、如果你是Team Leader。如何考核员工绩效
5、你认为你的知识背景能对我们的工作有什么帮助
6、你对自己在测试领域有什么具体规划
7、如果我们录用你，你准备怎样提升自己在手机测试领域的技术水平
手机自动化测试的原理是什么?
手机自动化测试的原理为PC上一个控制端（测试工具）与手机上的一个agent端，通过串口、USB或者无线方式将PC与手机终端相连，然后应用测试工具向手机发送请求或者命令，手机收到命令或者请求后，交给agent端解析，然后agent将这些解析的命令下发给手机的各个功能模块所能识别的命令，调用那些功能模块模拟操作。完成这些操作后，手机会返回一些信息，agent可以抓取这些信息，然后传回给PC端，这样就完成了一个完整的手机自动化测试。
2、关键点在于agent，有的公司是向自己的手机终端的软件功能模块中植入测试程序响应代码，有的公司可以利用MMI_Command的方式来控制手机终端；原理就是给手机提供一个响应的接口。
3、而对于PC控制端，这个测试脚本用各种编程语言都可以，看如何定义
4、而又的自动化测试设计成录制的机制，说通俗点，就是记录手工操作的键盘信息或者LCD的操作信息（LCD需要用到智能识别机制）
5、自动化测试框架的搭建方法是通用的，你需要有一套自己的测试框架才能保证自动化测试的顺利开展
手机测试
手机测试是一个很大的题目，涉及到硬件测试和软件测试，还有结构的测试，比如抗压，抗摔，抗疲劳，抗低温高温等，结构上的设计不合理，会造成压力集中，使得本身外壳变形，对于翻盖手机，盖子失效，还有其他严重问题。硬件测试一般都有严格的物理电气指标，也有专门的仪器。
手机测试是一个很大的题目，涉及到硬件测试和软件测试，还有结构的测试，比如抗压，抗摔，抗疲劳，抗低温高温等，结构上的设计不合理，会造成应力集中，使得本身外壳变形，比如翻盖手机，盖子失效，还有其他严重问题。硬件测试一般都有严格的物理电气指标，也有专门的 仪器，这里的仪器，不再多说，一般如果是专业的测试人员，不会对这词陌生。手机测试
手机测试，一般是指软件测试，这个一方面也说明了软件在手机上的重要性。一方面也说明手机测试的难度。因为其他的测试都有明确的指标，相应的测试用例，严格的操作规程，还有各种仪器，一定的测试软件。下面说的手机测试一般都是手机软件测试，以后不在重复说明。
在说明手机测试之前，觉得应该了解一下什么是嵌入式操作系统，这是个时髦的名词，虽然我们已经被嵌入式操作系统的产品所包围，但是却不一定能说清楚，什么是嵌操作系统，在学校的课堂上，讲的也不多，所以很多人对此感到云山雾罩。
简单的说，一个嵌入式操作系统就是为完成某种特定功能而专门开发的操作系统。这个操作系统的功能很明确，不像大型操作系统，范围广泛，大千世界，尽在其中，而嵌操作系统只为了完成某一项或者几项功能。
手机的特殊性要求对响应时间达到一定限制范围。也就是所谓的实时操作系统，如果一个电话不能在90秒内接听，那么对方会挂掉。而你的操作系统还没反映过来，那么这个操作系统无疑是失败的，这是对嵌入式操作系统实时性的要求。
作为一个测试人员，你必须知道这些，可能对一些软件开发人员，他不必很在意这些方面，因为他只要了解自己模块的入口说明和出口说明就可以。但是测试人员不行。高级测试人员应该了解嵌入操作系统的特点，这个系统不象WINDOWS，有图形界面可以输入输出，也不象DOS用命令行模式，所有这些，都需要自己编写一个编辑器，编写一个交互界面，编写一个输入输出界面，在WINDOWS中，利用一些API和一些MFC，不用考虑硬件的问题，因为系统已经完成，而WINDOWS是讲究和硬件分离的，因为这样可以保护系统不受侵入。而在嵌入式系统里面。这一些都要求和硬件息息相关。手机测试中，软件出现的故障不一定是由于软件的错误，也可能是由于没有考虑到硬件和软件没有完美的结合。手机测试
因此我们在了解操作系统的同时，也要了解一下其他的手机硬件性能，比如CPU ，比如存储器。
CPU的处理运算能力是以MIPS来衡量的，当然越快越好，但是也是和成本相关的，我不知道现在MOTOROLA T39的CPU是怎么样的，但是，因为是PDA，又是手写屏幕，所以菜单特别的慢。关于存储器需要专门做出说明，因为这里的存储器很特别，不象PC，手机没有硬盘！
嵌入式系统的编程语言一般有C，而且也是最多的，也有其他语言，比如C 在最开始时候是用汇编的，但是汇编难懂，而且也不容易移植，渐渐的被C代替，不过即使如此，在启动程序时候，要启动板子，也就是电路板时候，还是需要用一些汇编语言完成。
作为一个嵌入式系统的程序，和在PC上运行着的程序没有任何不同，唯一不同可能是在PC上运行的程序，你可以看到结果——如果你用输出语句的话，而在这里，你是看不到结果的。除非你加上LCD硬件，然后编写了LCD驱动程序，然后再编写显示程序，编写嵌入式程序，一切都要自己解决。
我们的手机如果不是人为把电源切断的话，或者在电源消耗到一定程度的话，是会一直在使用的，所以，手机程序是一直在运转的，就是说一直在循环，这个，对于了解嵌入式程序，应该是个好材料——嵌入式程序就是一个无限循环的程序，除非关掉电源和电源因素，这里也有一个测试点：硬件中断是最高级的，它会终止你的程序，即使你现在的程序级别很高，比如通话，如果没电了，一切会over.
手机程序就是在一个无限循环的程序，什么时候跳出这个无限循环？你关机吧，如果感到不高兴，把电池卸下来，因为有可能进入死循环，而关机键失效了，——只好通过取下电池了。
这里要专门说明一下存储器，因为很多手机毛病都和存储有关，而且很多问题都和存储相关，计算机的存储是关键，而手机的更是关键，因为计算机有硬盘作为存储，而手机所有的都在存储器里。存储器分为几类，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卡相关的数据，容量大小也只有几百字节。
3G手机离市民越来越近了！从昨天（6日）起，按照3G国产标准TD-SCDMA制式生产的3G手机开始在青岛、保定、厦门和北京四地放号测试，测试手机号码以“188”开头。本月15日前后，国产3G手机也将在上海小范围放号，进行为期两个月左右的测试。
上述五个城市的测试结果，将决定我国3G市场的进程，中国的3G到底用什么标准、3G手机什么时候大规模商用和3G网络究竟由谁来运营，最快都将在明年揭开谜底。
闪寸存储器是所有手机的首选，综合了前面的所有优点，不会断电丢失数据（NVRAM）快速读取，电子可擦除可编程（EEPROM）所以现在手机大量采用。
说了这么多存储器，可能比较糊涂了，这么多存储器，究竟中采用哪种呢，在手机发展中，各种存储器都用过，至于现在，各种手机采用的存储器是不同的，这个和成本相关，各种存储器价格不一样，本着性价比最优组合，由设计者决定，有些是可选的，有些是必须的，是手机方案决定的，我们了解只是各种存储性能，特点，在测试中判断错误原因。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
3 白盒测试
手机协议站软件的白盒测试手机测试
手机软件测试单从测试的内容来看，包括上面的MMI和底下的PROTOCOL。由于MMI的灵活性，和各个厂家的个性化，以及手机本身的用户不同。MMI 的侧重点也就不同，在基本通话、短消息、数据功能完成的基础上可以五花八门，所以测试的重点不同。测试方法各不相同。但是协议就不同了，协议是统一的，虽然你实现方法可以不同，但是完成的功能必须相同，和MMI不同，虽然都是聊天，但是有些用短消息聊天，有些用PUSH聊天，而协议软件有一个遵守的规范——ETSI指定的协议规范，有统一的命令规范和统一的标准。消息（术语，不是软件编程里的消息，是通信术语）是固定的嘛。针对协议的测试，因为有标准可循，有规范可仪，所以软件测试就很多工具，公司也多，自动化测试要自动话，否则，按照人的测试能力，谁也无法保证其绝对可靠性，也没有这么大的人力去仔细做测试。
一般对于白盒测试是比较严格的，而且也是耗费人力的，所以常采用自动化测试工具。这样节省人力、缩短测试时间。至于谁家的工具比较好，涉及各取所需吧，也涉及到成本问题。你如果想购买某产品，会给你一个DEMO版本，给你一个月的评价时期，这个评估版本让你熟悉其产品的优劣也让你熟悉其操作。测试工具一般都有二次开发功能，也就是可以自己编写脚本，针对不同的软件平台做一些改动，这样可以根据自己的需要编写测试CASE测试用列。当然即使是全部用自动化测试，你心理还是没底，你还是要仔细去看代码。分析流程，读懂其含义，一个很小的问题，出错保护没有作好，一般这个问题最多，出错保护机制没有作好，会造成崩溃这样严重的问题。 这是针对协议代码的白盒测试。如果你是对购买来的协议进行测试，一般有仪器，模拟一个网络基站，进行测试，不过这样的仪器非常昂贵，而且测试人员要对ETSI协议比较熟悉。我没有直接参加针对协议的白盒测试，不过对评估般的测试软件曾经PRACTISE，可测试覆盖率，我很奇怪的是，一般打点（跟踪）也是需要消耗CPU时间的这样程序效率就降低了，而我要测试程序的效率等项目就要考虑CPU，而且程序的工作运转必须和CPU息息相关，而现在CPU 在保证程序RUN同时，还要进行打点，是否测试出的指数和实际不符和呢，是否没有达到真实的水平呢？而它这个产品（水牛）介绍说，一般不占用CPU时间，我想了很长时间没有想通后想咨询，告之这是他们的专利，无可奉告。由于这种测试工具是针对平台，所以如果你平台不支持的，也就没有办法使用了。还有集成测试等等，在软件的介绍中有详细说明，不再详细说明。 对协议进行白合测试，我想对你的要求就是：熟悉相关的协议，否则白扯；熟悉开发的语言，否则免谈。
4 测试内容
手机测试主要测试什么？手机测试
一.软件压力测试:用自动测试软件连续给手机拨打1000个电话,检查手机是否会发生故障.
二.抗摔性测试:抗摔性测试由专门的PRT可*性实验来进行.半米的微跌落测试要做300/面(手机有6个面).而2米的跌落测试每个面需各做一次.还有模拟人把手机扔到桌面的测试.
三.高温低温测试:让手机处于高低不同的温度来检测手机的适应性.
四.高湿度测试:用一个专门的箱子来操作滴水测试,模拟人出汗的情况(水里面掺有一定比例的盐)
五.百格测试:用专用刀片在手机的外壳画100个格子10*10,用专用胶带粘其表面,看看外壳会不会掉油漆.
六.翻盖测试:对翻盖手机进行翻盖10万次,检查壳体的损耗情况.
七.扭矩测试:直板机,用夹具夹住两头,一头左拧,一头右拧.测试壳体和手机里面大型器件的强度.
八.静电测试:北方天气干燥,手摸金属的东西容易产生静电,击穿手机电路,有些设计不好的手机就是这么突然坏的.有专门的静电枪和铜板来测试.
九.按键测试:借助机器以给定的力量击打键盘10万次.
十.沙尘测试:手机放入特定的箱子,细小的沙子被鼓吹起来.数小时后,察看手机里面是否有沙子进入,如果是,那么手机密闭性不好,结构设计有待重新调整.
5 内容标准
手机测试
目前，绝大多数国内定点的CDMA手机生产企业都选择采用SKD（sack knock down）散件组装的方式来生产手机，这是因为与OEM（orignal equipment manufacture）贴牌或CKD（completed knock down）的方式相比较，采用SKD方式具有投资少、见效快、技术风险低、项目启动快、容易组织规模生产、可在一定程度上降低成本、产品上市时间迅速的优势。在SKD生产方式条件下，如何进行CDMA手机的测试和性能评估中，保证产品质量和测试速度，这是国内许多CDMA手机生产企业面临的一个技术问题。如何解决好该问题对于生产厂家来说具有重要的工程意义和现实意义。笔者现把一些经验和想法与同行作一交流。
1 SKD测试方案的指导思想
（1）满足相关的技术规范和测试标准
手机测试
（2）具有足够的测试速度和精度
（3）在满足生产线产能要求的前提下，设备投入要经济，这包括购买CDMA手机综合测试仪、传输带设备、测试夹具、其他的测试设备，生产线统计管理设备等。
（4）拟购买测试仪器的技术指标、型号、规格、数据等项要求，既要能满足现阶段的综合要求、也要考虑到未来的可扩充性、可升级性、可维修性。
（5）尽量少占用公司的各类资源，包括人力、物力、财力、生产场地、空调、电力、压缩空气等。
（6）尽可能地充分利用现有的GSM手机生产线条件（若有的话）来对生产线进行改进、调整和优化，以进一步降低生产手机的成本。
2 CDMA手机功能测试项分类、测试规模和相关的标准
（1）RF收发信机指标测试（测试发射功率、发射频谱、接收灵敏度等等）：测试标准为中华人民共和国通信行业标准YD/T1050-2000；美国TIAIS-98双模移动台最低性能标准；800MHzCDMA数字蜂窝移动通信网空中接口技术要求。
（2）音频指标测试：检查或测试发送音频灵敏度、振铃响度、受话器响度、失真度、侧音、免提功能等等。
（3）LCD和菜单功能的检查：看是否与说明书中所述内容相一致。
（4）各按键触觉和力度的检查。
（5）电池质量的检查：检查电池与主板的电气连接质量是否可靠，测量电池容量、输出电压、短路保护等指标。
（6）充电器质量检查：检查充电器与主板的电气连接质量是否可靠，测试输入特性、输出特性、充电特性、充电时来电、充电时去电、对地泄漏电流等指标。
（7）可靠性测试：通过对手机施加一定的外界环境应力（高温、低温、振动），来检查产品的可靠性指标。这一点很重要，它可以发现不少产品质量问题。测试标准为GB/T2423.8-1995：电工电子产品环境试验。
（8）在实际CDMA通信网络中的外场测试：该项测试需在不同的时间、不同的地点/地貌、与不同网络中的用户进行互连互通等环境条件下进行测试和检查。测试标准为CDMA（IS-95A）数字移动电话机进网检验实施细则2001年5月信息产业部。
（9）手机壳体质量的检查
（10）软件、MMI操作可靠性与稳定性检查。
（11）DC功耗指标：关机电流、待机电流、通话电流、待机时间的测试。
上述CDMA手机SKD生产测试方案中的大部分内容也可以用于GSM手机的SKD生产中。
如何对一部完整手机进行质量测试（doc 1）摘要
如何对一部完整手机进行质量测试
一部完整手机的功能检测步骤主要可分为三大部分：
1、界面（根据对不同的机型作步骤调整）
首先要看开机时有无异常，显示是否有无缺行、乱屏、色彩不均等现象，此次对铃声、震动做进一步的试听禁止有铃声小、铃失真、无铃声、无震动、震动不良等现象发生，按键主要检测有无作用、是否串键、手感、有无背光灯（包括大小屏），再次检查手机的相关软件，将软件标签贴在相应位置。
2、呼叫（GPRS卡）
先将8960仪器调试到人工手动或仪器自动呼叫的模式下，然后再对手机进行通话测试。在手机呼叫接通之后，首先看电脑上是否显示合格、通话的时间是否走或走的慢、8960上显示的IMIEL号不能为零更不能重号，此次试侧键的作用和手感同时调试通话音的大小，是否有音杂、电流声、回音等情况，再次如有需要还要用耳机来对声音进行调试。
3、恢复出厂
浅谈手机软件测试用例设计方法
2011-09-06 17:10
手机产品和用户交互非常紧密，手机的软件质量就显得尤其重要。要使最终用户对手机软件感到满意, 必须要在手机软件发布之前进行充分的测试。而不完全、不彻底是软件测试的致命缺陷，但是我们又不可能进行穷举测试，任何程序只能进行少量而有限的测试。为了节省时间和资源，提高测试效率，我们必须要从数量极大的可用测试数据中精心挑选出具有代表性或者特殊性的测试数据进行测试。测试用例在此情况下产生。测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。简单地说，测试用例就是设计一个场景，使软件程序在这种场景下，必须能够正常运行并且产生程序所设计的执行结果。
Grenford J. Myers在《The Art of Software Testing》一书中提出：一个好的测试用例是指很可能找到迄今为止尚未发现的错误的测试，由此可见测试用例设计工作在整个测试过程中的重要地位。测试用例设计的好坏直接影响到测试的效果。目前很多公司的测试用例都是依据需求或者规范规格，测试用例设计人员根据经验来写测试用例，这种情况就会导致测试用例覆盖面不全、测试用例规划不合理，甚至存在测试用例冗余的情况。测试用例覆盖面不全会导致出现漏测少测，将问题直接流向用户；测试用例规划不合理、测试用例冗余会造成人力浪费，导致测试效率低下。因此不能只凭借一些主观或直观的想法来设计测试用例，应该以一些比较成熟的测试用例设计方法为指导，再加上设计人员个人的经验积累来设计测试用例。
目前业界比较成熟的测试用例设计方法主要有：等价类划分法，边界值分析法，错误推测法，因果图法，正交实验设计法等。
等价类划分法
等价类划分法是测试用例设计中一种重要而常用的设计方法，它将不能穷举的测试用例进行合理分类，从而保证设计出来的测试用例具有完整性和代表性。等价类划分是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。
边界值分析法
边界值分析法就是对输入或输出的边界值进行测试设计的一种方法。通常边界值分析法是作为对等价类划分法的补充。长期的测试工作经验告诉我们，大量的错误发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值而不是中间值作为测试数据。
错误推测法
错误推测法是指在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法。错误推测方法的基本思想是列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据它们选择测试用例。例如, 在单元测试时曾列出的许多在模块中常见的错误、以前产品测试中曾经发现的错误、输入数据和输出数据为0的情况、输入表格为空格或输入表格只有一行等。这些都是容易发生错误的情况，可选择这些情况下的例子作为测试用例。
因果图法
因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。等价类划分法和边界值分析方法都是着重考虑单个输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。而如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图来设计。
正交试验设计法
正交试验设计法。利用因果图来设计测试用例时,作为输入条件的原因与输出结果之间的因果关系,往往因果关系非常庞大,以至于据此因果图而得到的测试用例数目多的惊人，给软件测试带来沉重的负担。为了有效地、合理地减少测试的工时与费用,可利用正交试验设计方法进行测试用例的设计。正交试验设计方法依据Galois理论, 它是根据正交性,按照 “均匀分散，齐整可比”的特点从大量的（试验）数据（测试例）中挑选适量的,有代表性的点（例）,从而合理地安排试验（测试）的一种科学实验设计方法。它简单易行，计算表格化，使用者能够迅速掌握，是一种高效率、快速、经济的试验设计方法。
以上这些方法各有优缺点，在设计过程中可以叠加使用，取长补短，使得设计出来的测试用例规划合理，裁剪得当，既能保证覆盖面，又能保证测试的效率，所以在测试用例的设计过程中得到了广泛的应用。
OPhone测试团队在测试用例的设计阶段充分运用这些方法，在测试用例的设计过程中极大的减少主观因素的影响，并在保证测试用例完备性和有效性的前提下，对测试用例进行有效裁剪，减少无效测试用例和冗余，在很大程度上提高了测试效率，从根本上确保测试的质量。
从哪些角度进行手机软件测试？
对于当前背景下的手机软件测试来说,要做好手机软件测试,主要从以下几个角度进行测试:UI测试,功能模块测试,交叉事件测试,容量性测试,用户手册测试等。
UI测试用户界面测试指测试用户界面的风格是否满足客户要求,文字是否正确,页面美工是否好看,文字,图片组合是否完美,背景是否美观,操作是否友好等等,UI测试用于核实用户与软件之间的交互。UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外,UI测试还可确保UI中的对象按照预期的方式运行,并符合公司或行业的标准。包括用户友好性,人性化,易操作性测试。
功能测试功能测试指测试软件各个功能模块是否正确,逻辑是否正确。对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。此类测试基于黑盒技术,该技术通过图形用户界面(GUI)与应用程序进行交互,并对交互的输出或结果进行分析,以此来核实应用程序及其内部进程。功能测试的主要参考为类似于功能说明书之类的文档。
交叉事件测试交叉事件测试是指一个功能正在执行过程中,同时另外一个事件或操作对该过程进行干扰的测试。例如在运行手机软件程序的过程中接收到短信或来响闹。应该以执行干扰的冲突事件不会导致手机死机或花屏等严重的问题出现为Pass的标准。
容量性测试容量性测试主要测试软件测试的性能,包括负载测试,强度测试,基准测试以及基准测试
负载测试是一种性能测试指数据在超负荷环境中运行,程序是否能够承担。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。强度测试是一种性能测试,他在系统资源特别低的情况下软件系统运行情况。这类测试往往可以书写系统要求的软硬件水平要求。实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。
用户手册测试手机软件的用户手册测试主要是看软件功能介绍是否准确、简洁地描述该软件功能,且不会让用户产生误解。
怎么测试手机对存储卡的读写速度
读写速度90MB/s 超高速CF存储卡面世
2009年9月，SanDisk Extreme Pro CF存储卡隆重推出，全球领先的闪存供货商SanDisk为专业级闪存设定了新的标杆，将读写速度提高到90MB/s，容量从16GB至64GB。
为了满足其严格的用户所需的耐久性和稳定性，SanDisk在极端的条件下对各批次存储卡进行了测试，如许多专业摄影师在拍摄期间会遇到的酷热、严寒、高湿度以及存储卡意外坠落等情况。
“咔嚓”按下快门
以往在相机使用胶卷而非存储卡时，人们很容易通过马达卷片器的快速“咔嚓咔嚓咔嚓”声来分辨出谁是专业摄影师。而今天的专业级数字单反相机能够提供同样的功能，并可在连续拍摄中通过按住快门按钮来拍摄快速连续的图像。这种相机设置通常设定为连续拍摄模式或突发模式。
当按住相机快门时，光线射向图像传感器，并将摄影师捕捉的视觉信息转化为电子信号。电子信号被传送到模拟至数字信号转换器中，转换器再将这些信号转换成二进位的数字，由相机内的芯片进行处理，最后形成图像文件。在今天的标准数字单反相机中，这一流程通常仅是一瞬间的事情。
文件生成后存储在相机的内部缓存中。在突发模式中，这种流程是以快速连续的方式发生的，直到缓存装满为止。它的功能像是一个“收费站”，等待数据从相机内部缓存的“高速路”上下来，直到存储卡被写满。随着时间的推移，SanDisk的工程师们开发出一种将相机内部缓存卸载到存储卡的方法，使存储卡内的数据存储单元可以同时工作，从而加快了存储速度。SanDisk Extreme系列产品中使用的高性能闪存不是单单坐在“收费站”中，而是能够“调节引擎”从而产生更高的数据传输速度。
SanDisk Power Core控制器和ESP技术使存储卡性能大大提高
当使用SanDisk Extreme Pro存储卡拍摄图像时，数据将首先到达SanDisk Power Core控制器，该控制器是专为快速处理数据而设计的。为了支持更快速的数据处理，SanDisk运用了双通道技术，用来有效提高一个控制器能处理的数据量。
一旦数据到达像”高速公路”般的SanDisk Power Core控制器，数据就被转移到两个“出口匝道”中，这样能在同一时间处理更多的图像。在数据从“高速公路”转移到两个“出口匝道”后，它就被处理并储存在多个闪存区块的其中一个里。SanDisk Power Core控制器将数据分配到不同的存储通道中，帮助数据找到最快捷的存储路线, 提高了存储速度。这种通过SanDis Power Core控制器写入和存储多个图像的处理过程被称为“ESP”。
ESP读写操作结合快速闪存数据传输架构, 使数据能够以更快的速率进行传输，快于目前读/写速度为45MB/s的存储卡。此外，ESP技术通过先进的硬件自动化来简化数据的读写运行,并有效地解决了数据存储的瓶颈。摄影师得益于ESP技术，能更快地捕捉高解像度图像并更快地传输到电脑。
SanDisk Power Core控制器的的新一代“错误修正码”的硬件引擎速度在上一代速度的基础上，进一步得以提高，使存储卡能够在不影响性能的基础上保持数据的完整性。错误修正码技术实现了SanDisk Extreme Pro存储卡速度和稳定性的完美结合。
平均读写存储区块技术增强了存储卡的可靠性
SanDisk同时开发出了闪存控制器和存储芯片。SanDisk的工程师们对闪存控制器和闪存存储媒介之间的兼容性进行了全方位的测试，并做出相应调整以确保存储卡的高性能和可靠性。SanDisk闪存控制器利用“平均读写存储区块技术”将数据在多次读写时间里分配到不同存储模块中，提高了卡片的可靠性；这一技术对数据进行有效地处理，确保了数据删除和重新读写能够均匀地分配到整个媒介中。
为了增强SanDisk Extreme Pro存储卡的整体可靠性，新的SanDisk Power Core控制器的设计更注重整合性，在卡片的印刷电路板（PCB）上使用了较少量的组件，这样也就降低了个体组件损坏的可能性。
从内到外对存储卡的耐用性进行极限测试
SanDisk的内部稳定性测试是其专业存储卡得到公司检验通过的最后一关。SanDisk Extreme存储卡必须要经受住相机使用的恶劣环境的考验。在照相机的快门被按下之前，厂家花费了大量的时间来进行测试，以保证名副其实。多批次样品在下列标准下进行测试：
• 极限温度防护：SanDisk Extreme存储卡经过了在85oC的烤箱及-25oC的冷库中的测试。
• 高湿度：SanDisk Extreme存储卡经过了90%湿度的测试。
• 意外撞击：SanDisk Extreme存储卡经过了从9英尺高坠落的测试。
经过烘烤、冷冻、坠落和高湿度测试的存储卡样品必须在测试后能够正常使用一定时间。
鉴于存储卡在高端照相机拍摄时所占的重要地位，需要谨记：并不是所有的存储卡都能够担当如此大任。SanDisk正在不断挑战专业级存储卡的极限。由于存储卡不仅仅可以帮助专业人士捕捉影像，而且捕捉下的内容都源自于专业摄影师的生活，所以SanDisk的存储卡设计和测试都是弥足珍贵的。