手机软件测试范本

《手机软件测试范本》由会员分享，可在线阅读，更多相关《手机软件测试范本（23页珍藏版）》请在装配图网上搜索。

1、手机软件测试目录1 手机知识31.1 手机的主要功能31.1.1 通话功能31.1.2 消息功能31.1.3 电话本31.1.4 增值服务31.1.5 其他功能41.1.6 为特定语言定做的功能41.1.7 附件41.1.8 数据连通41.1.9 JAVA 程序41.2 手机的软件结构51.3 手机的硬件结构61.4 Nokia手机相关知识71.4.1 Project Line of Nokia71.4.2 手机类型72 测试基础82.1 测试与开发82.1.1 软件开发的一般流程82.1.2 测试在软件开发中的作用82.1.3 测试与开发对应图92.1.4 Nokia手机软件测试介入开发的时

2、间102.1.5 Nokia手机的开发流程102.2 测试的流程112.2.1 制定测试计划112.2.2 测试准备112.2.3 测试执行112.2.4 测试评估112.2.5 文档收集122.2.6 测试总结报告122.3 测试的方法122.3.1 正确性测试122.3.2 容错性测试122.3.3 边界性测试132.3.4 性能与效率测试132.3.5 易用性测试132.3.6 文档测试132.4 测试的分类132.4.1 按测试的手段分132.4.2 按测试发生的时间和目标分142.4.3 按测试的任务分142.4.4 其他测试142.5 黑盒测试详细介绍142.5.1 Release

3、 Test142.5.2 System Test152.5.3 Focus Test162.5.4 Stress Test162.5.5 Free Test172.6 测试相关文档说明172.6.1 测试计划172.6.2 测试用例182.6.3 错误报告182.6.4 进度报告202.6.5 总结报告203 手机相关213.1 GSM213.2 GPRS213.3 CDMA213.4 3G214 手机软件测试工程师必备素质214.1 Team Leader的任务和必备能力214.2 Error Manager的工作内容224.3 测试工程师职责和应有素质221 手机知识1.1 手机的主要功能

4、1.1.1 通话功能l 对拨入拨出电话的管理l 对通话记录的管理l 呼叫转接、呼叫等待、通话计时计费等方便用户使用的功能1.1.2 消息功能l 文字短消息（SMS）的编辑、发送、接收、转发和存储等；l 多媒体短消息（MMS）的编辑、发送、接收、转发、存储和配置；1.1.3 电话本l 名片的管理l 存在SIM卡上的名片l 存在手机内存中的名片l 一个名字多项内容（如传真、固话、手机、Email等）l 名片的新建、修改、拷贝、转存、删除l 名片以红外或短消息形式发送给其它手机l 单键拨号（Speed Dialing）l 号码分组（Caller Groups）1.1.4 增值服务l Business

5、 cards 的管理 (如发送和接收: 通过红外线或SMS. )l 书签的管理 (如发送和接收: 通过红外线或SMS或书签形式. 以及编辑,存储,新增和进入.)l 服务信箱 (自动存储服务信息. 服务信息有点播铃声,下载彩色图片和COD文件等.)l 服务设置 ( GPRS上网设置,WAP服务设置.)l 多模式浏览器 ( GPRS上网,WAP服务.)l OTA待机图片 (通过无线下载待机图片)l OTA铃声l V-calendarl XHMLl 移动梦网l 动感地带1.1.5 其他功能l 闹钟（Alarm）l 日历（Calendar）l 计算器（Calculator）l 定时器（Count Do

6、wn Timer）l 屏保（Screen Saver）l 待办事项（To-Do List）l 游戏（Games）1.1.6 为特定语言定做的功能l 中文输入（拼音/笔划）l 中文菜单l 农历（Lunar Calendar）1.1.7 附件l 充电器（Charger）l 耳机（Headset）l 车载免提（Car Kit）照相头（Camera）1.1.8 数据连通l GPRS 应用程序l 同步应用程序 (同步应用, 同步设置)l 红外线应用程序l 数据线l 手机Flash程序l Trace Log1.1.9 JAVA 程序l 电子邮件l QQ程序l 应用程序l 游戏程序1.2 手机的软件结构DC

7、T = Digital Core TechnologyDCT3和DCT4的区别主要在硬件结构和UI上1.3 手机的硬件结构l RF是手机的射频接受和发送设备，是手机本机与无线网络的接口l UEM是手机对外设备联接的接口，包括SIM卡，充电器，电池，RF，数据线借口，红外接口等，并提供对上述数据和信号的处理。无线信号在这里进行调制和解调。l UPP是手机的核心处理模块。其中，DSP负责数字信号和模拟信号的转换。UPP和UEM之间存在着接口，两者之间的通信是通过接口进行的。UPP除了负责整个手机的操作系统外，还负责手机本身设备的运作，如耳机，麦克风，显示屏等。除此之外，还负责缓存和Flash(相当

8、于硬盘)的运作。l Flash是手机的数据存储区，非临时数据都存在这里。一般包括以下几个方面：Core Code, DSP Code, HW data, PPM, PMM。1.4 Nokia手机相关知识1.4.1 Project Line of Nokia1.4.2 手机类型l MEP = Mobile Entry Phonel MP = Mobile Phonel MSW = Mobile Softwarel SWEP = software engineer product2 测试基础2.1 测试与开发2.1.1 软件开发的一般流程l Marketingl Requirement Analy

9、sisl High Level Designl Low Level Designl Coding2.1.2 测试在软件开发中的作用l 由于现在软件的规模越来越大，一个人或者少数几个人已经不可能在一定的时间内完成一个软件，所以软件开发的过程越来越复杂，层次越来越深。这就导致开发人员之间的沟通有了一定的隔阂。所以，软件测试越来越有单立出来的必要和重要性。l 由于软件开发的过程的复杂性，软件必然存在着无数的Bug。而且大多数是在软件上市前必须解决的，而开发者有不定能发现这些问题，故而测试就显得非常必要。测试是开发成功的必要保障。l 由于软件开发的层次性，所以开发的结果很可能与初衷不一样，这就需要测试

10、者去发现这些差异。因此，测试是软件成功的重要保证。l 软件不仅要实现一些功能，更要完善它的性能。这就需要测试人员对软件进行评测，从而不断地完善软件的性能。2.1.3 测试与开发对应图2.1.4 Nokia手机软件测试介入开发的时间l 在制定开发计划的同时就要制定测试计划l 测试在进行结构设计时就已经进行了2.1.5 Nokia手机的开发流程l E-1During this period, an idea box will appear. The ideas in the idea box are collected from Region Marketing and have a certai

11、n priority (The lower the priority number is, the higher the priority is). For example:0, 1, 2.l E0During this period, the HW designer must make out the B0-HW version.That is to say, B0 must be put out after E0 period.l E0.5综合考虑HW, SW and Costl E1From E0 to E1, Design and Test Plan, Risk, Organizati

12、on, Schedule must be discussed and made out. l E1.5全体讨论Design and Test Specificationl E1.9From E1 to E2, Design and Test Specification must be made out.During E1.9, Last version of Specification should be made out and be approved.l E2During E2, The formal draft SW should be made out.l E3From E2 to E

13、3, 对SW进行精美化、完美化测试和改良Purpose: No fatal error (市场部可以接受的Fatal Error不算)l E5From E3 to E5, 进行LCD以及其他HW的改动During E5, 可以让生产工厂进行大批量生产l Before E5, the test stays in the CE (concurrent engineer)After E5, the test goes into PE (production engineer)2.2 测试的流程2.2.1 制定测试计划l 开启测试项目l 在接了一个测试项目后，要在一定的期限内制定好测试的详细计划以及日

14、程安排表2.2.2 测试准备l 在计划制定好之后，在执行之前，必须将测试所需的人力资源，硬件资源，软件资源，文档资源以及环境和人文资源准备充分2.2.3 测试执行l 测试组根据测试计划和测试日程安排进行测试，并输出测试结果2.2.4 测试评估l 有测试结果评估小组或评估人员对测试结果进行评测，分析，并输出分析结果2.2.5 文档收集l 将从测试计划开始到评估结束的所有文档进行整理收集。l 对整个测试过程进行总结，并对测试结果进行总结2.2.6 测试总结报告l 提交测试结果l 归还所借相关资源l 文档入库l 关闭测试项目2.3 测试的方法2.3.1 正确性测试l 正确性测试又称功能测试，它检查软

15、件的功能是否符合规格说明。l 测试基本的方法是构造一些合理输入（在定义域内），检查是否得到期望的输出。l 由于定义域是一个连续区间，所以不可能枚举所有可能的值，那么等价测试就很必要了（将定义域分成若干个等价区间）。l 等价区间的概念可表述如下：记（A, B）是命题f(x) 的一个等价区间，在（A, B）中任意取x1进行测试如果f (x1) 错误，那么f (x) 在整个（A, B）区间都将出错。如果f (x1) 正确，那么f (x) 在整个（A, B）区间都将正确。2.3.2 容错性测试l 容错性测试是检查软件在异常条件下的行为（输入不同的数据类型或者定义域之外的值进行测试）。2.3.3 边界性

16、测试l 因为边界一直是比较敏感的地方，而且是程序员最容易忽略的地方，所以，这种测试也往往最容易奏效。2.3.4 性能与效率测试l 性能与效率测试主要是测试软件的运行速度和对资源的利用率。l 性能与效率测试中很重要的一项是极限测试，因为很多软件系统会在极限测试中崩溃。2.3.5 易用性测试l 易用性测试没有一个量化的指标，主观性较强。这主要是从End User的角度去考虑软件是否会有一定的使用缺陷。如果对此有任何看法，可以向Team Leader反应或者与客户负责人直接交流。2.3.6 文档测试l 文档测试主要检查文档的正确性、完备性和可理解性。好多人甚至不知道文档是软件的一个组成部分。l 我们

17、的工作中的文档主要是UI Spec.和Test Case。UI Spec使我们无法改变的，但是Test Case是我们测试的对象。Test Case是我们用来测试手机软件的参考文档，但是它本身也有一定的局限性。所以，在测试的过程中，如果发现Test Case不正确或者不充分，可以直接补充，或者和Team Leader商议后把不足的地方补充起来。2.4 测试的分类2.4.1 按测试的手段分l 黑盒测试(White-box Test)n Release Testn (Full Round)SystemTestn Focus Testn Stress Test-No Test Casen Free

18、Test-No Test Casel 白盒测试(Black-box Test)n Module Testn Sub-System Testn Sub-System Integration Testn System Integration Testn Integration TestThe feature groups for Integration Test are decided by Integrator and provided by SW Component Factory.2.4.2 按测试发生的时间和目标分l 单元测试(Module Test/Unit Test)l 集成测试(In

19、tegration Test)l 系统测试(System Test)2.4.3 按测试的任务分l 现场测试(Field Test)l 互操作测试(Inter-Operatability Test)2.4.4 其他测试l 可接受性测试(Acceptance Test)l a测试 -手机研发公司自己做的测试l b测试 -非手机研发公司做的测试2.5 黑盒测试详细介绍2.5.1 Release Testl Purpose:n 测试手机的基本功能是否实现，是否有进一步测试的必要性l Input:n 测试工程师n Release Test Cases (较少，一般为200左右)n 手机以及相关附件n 测

20、试环境l Output:n Test result of Release Testn No Error reports (Optional)l Attention:n Release Test的Test Case具有一定的典型性，主要是反映手机最基本功能的Test Casen 本类测试只需要依据Test Case进行测试，不需要进一步发挥n 如果有发现与Case无关的Error, 在测试通过后才可以填报Error Reportn 此类测试有一门槛值，即Test Case的Pass率达到一定值（如95%）才能宣布版本发布成功，进入进一步的测试，否则此版本无效。n 除了门槛值外，如果重要功能模块的

21、Test Case没通过，也会终止这个版本。2.5.2 System Testl Full Round System Testn Purposeu 对手机的所有功能进行全面的测试(所有语言包)u 由于Case不可能包含所有方面，所以测试时应适度发挥，尽力完成全面测试n Input:u 测试工程师u Test Cases(较多，一般为25000左右)u 手机以及相关附件u 测试环境u Schedulen Output:u Daily Report of test cases (number & percent of Pass, Error, NA, NT)u Summary Reportu Er

22、ror list and Error reportsl Common System Test (Medium or Minor)n Purpose:u 对手机的一部分的功能进行全面的测试u 由于Case不可能包含所有方面，所以测试时应适度发挥，尽力完成全面测试n Input:u 测试工程师u Test Cases(较多，取决于测试的目的和范围)u 手机以及相关附件u 测试环境u Schedulen Output:u Daily Report of test cases (number & percent of Pass, Error, NA, NT)u Summary Reportu Erro

23、r list and Error reportsl Attention:n System Test一般分为两个部分，“跑Case”和Free Test。n 在测试初期，一般只需要按照Test Case测，把一些不可重现的Error都记录下来。同时遇到Test Case的问题或者不充分，应该立即解决（和Team Leader或者Special List讨论，补写Test Case）。在这一阶段结束后，一般要写一个Summary Report。把这一阶段的测试结果和遇到的问题、自己的见解都写在里面（当然是用English）。n 当所有Test Case都测完后，就进入Free Test期间。这里的

24、Free Test具有明确的目的性和范围。一般来说，这段时间的Free Test只需要测自己负责的模块。而且Free Test还负责重现前期“跑Case”是遗留的不可重现的Error。2.5.3 Focus Testl Purpose:n 集中于一个或几个点进行测试(同System Test)l Input:n 测试工程师n Test Casesn 手机以及相关附件n 测试环境l Output:n Test Resultn Error Reports2.5.4 Stress Testl Purpose:n 为了解决市场上发现的重大Error，而进行的有针对性的强度测试n 主要是利用边缘测试（临

25、界测试）手段l Input:n 测试工程师n 手机以及相关附件n 测试环境n Focus List of Phone Featuresl Output:n Expected result: find out the reproducible steps of these errorsn Decrease the steps as possible as we canl Attention:n 压力测试，顾名思义，是给手机施加一定压力，从而找出手机软件上的Error。一般来说，对手机施加的压力主要有：u 存储压力：由于手机采用的是栈式存储，所以当一个存储块满了之后，如果程序员不做相应处理或者处理

26、不好的话，很容易造成其他存储区被擦除，从而在UI上出现问题（其他功能无法正常使用）。u 边界压力：边界一直是程序员最容易忽略的地方。u 响应能力压力：有时候某个操作可能处理的时间很长，在处理期间如果测试者再不断地进行其他操作的话，很容易出现问题。u 网络流量压力（如在接电话时进行短信服务）等等。n 在项目中，Stress Test有时也会用来重现不可重现的Error。n 由于有不少不可重现的Error是由于Memory Leak(内存泄漏)引起的，所以不停的重复同一个操作是重现一个不可重现的Error的一个好方法。2.5.5 Free Testl Purpose:n 测试System Test

27、中没有做完的不可重现Errorn 寻找平时没有找到的忽略的Errorl Input:n 测试工程师n 手机以及相关附件n 测试环境n Error List of System Test (especially the irreproducible errors)l Output:n Error List and Error Reportsl Attention:n 在System Test阶段所用的Free Test具有明显的目的性和范围n 平时的Free Test从理论上应该对所测试的范围穷尽所有的测试方法。但是，这是不现实的。在实际项目中，主要有两个方面是Free Test所需要重视的。u

28、 一是从UI Spec上找灵感。应为Test Case是依据UI Spec写的，所以从UI Spec上突破是一个行之有效的方法。UI Spec有一定的探索深度，加大探索深度，是一种突破的途径；另外同一个功能用其他不同的方法去实现，也是一种突破途径。u 二是多关注不同Feature之间的Interaction。这是手机软件相对比较容易出问题，而Test Case又很少能反映的地方。这是一个很大的Free Test空间。2.6 测试相关文档说明2.6.1 测试计划l 测试的任务即需要测试什么和不需要测试什么；l 工作量估算需要多少人，测试多少天，测试几个周期；l 日程表每人每天需要做什么；l 测试

29、方法和流程采用什么方法，遵循哪些流程；l 测试资源需要多少人、设备、工具、文档等资源，以及对上述资源都有哪些要求。l 测试输出测试中需完成的错误报告（Error Report）和进度报告（Progress Report），测试完成后需完成的总结报告（Summary Report）。2.6.2 测试用例l Title标题一般会描述出当前要执行的case是哪个功能模块的，能实现怎样的一个操作。标题下面有当前case的ID号和软件的版本号，如Phonebook-Memory Save-Selected memory is Phone and SIMID:EK20010829094907Version

30、:1.1.0l Description整体地描述这个case的测试目的，能实现什么功能。例如：The purpose of this test case is check out that the phone number can be saved to phonebook when selected memory is Phone and SIM.l Required test environment and accessories必需的测试环境和附件。测试环境包括硬件环境和软件环境。例如：HW, ESIM，Headset.l Precondition描述执行case的前提条件。例如：Sel

31、ect memory in use to be Phone and SIM. Return to the Idle State.l Action详细描述执行case时的每一步操作。一般每一步操作都对应着一个期望中的结果。执行时可参照下面的期望结果。例如：Start the procedure to add a new item to the Phonebook.Enter some name and press Ok.Enter some number such as 12345 and press Ok.l Expected result描述执行该case的期望中的结果，与上面的操作Acti

32、on是相对应的。例如：Name: query is displayed.Number: query is displayed.Saved to phone memory information note is shown. Phone goes to detailed memory screen.2.6.3 错误报告l Title:标题是Error Report中非常重要的一部分，它要求简单明了地对Error作一个整体的描述，让不知道这个Error的人看了之后能够很清楚地知道这是个怎样的Error。记得曾经有人提过“3W1H”的概念。也就是说，标题里面应该包括What is the error

33、, When will the error appear, Wheremay the error appear and Howto make the errorappear. 在Title后面，一般要写上Feature Group的名字。例如：Title: Call register: The phone doesnt remain in the same state after rejecting a call when viewing items under full window choice items in call register.l Severity (Fatal/Severe

34、/Minor):Severity用来描述Error的严重程度，有三个级别：较小的、严重的、致命的。Fatal Error一般来说是指影响手机系统工作的Error；Server Error指的是影响用户操作的或者某些功能实现的Error；Minor Error指的是微小的、不影响手机功能正常使用的Error。一般的Error如中文界面中的某个字不正确，或者是英文界面中的某个单词拼写不正确；左右功能键显示有误等等都属于Minor。若手机的某个功能不能实现，如不能发短信，不能存电话号码，不能进行充电等等都属于Severe；若手机开不了机，或经常死机、重启等则是Fatal。Severe和Fatal两种

35、Error对手机来说都是很严重的问题，这个具体在做项目时可请示项目经理。例如：Minorl Reproducible Error? (Yes/No, if No, how many times?) in English UI or Chinese UI?描述Error是否可再现，如果每次操作都能出现，就是可再现的。如果只是某一次操作才会出现这个Error，则是不可再现的。如果是不可再现错误，要记录一共出现过多少次，是在英文界面还是在中文界面。每个Error都有发生的前提条件和操作步骤。严格的说，每个Error都是可重现的。但是，发现这个Error的人可能没有能够找到这个error的完整的前提条

36、件或者完整的操作步骤。所以，现实中就有了很多不可重现的Error。对于一个手机而言，硬件，软件，语言包和SIM卡都是其重要的组成部分。所以，在一个手机中用某种SIM卡在某种语言的UI上发现了某个Error，有可能在同样的手机，同样的SIM卡，不同的语言的UI上就没有这个Error;也有可能在同样得手机上用不同的SIM卡也会没有这个Error；同样，在不同的手机上也有可能发现不了这个Error。总之一句话，是否可重现，要考虑手机硬件、软件版本、SIM卡类型、UI类型等等相关的影响，不能简单的说某个Error可重现，有的时候要加上注释。例如：Yes, both in English UI and

37、Chinese UIl Precondition:这里写的是在错误发生之前，手机的状态。为了保证步骤的简洁，这里要尽可能的详细。当然，也不要写的很罗嗦。l How did you get to the state just before the error:详细描述在错误发生之前你是如何到达这个状态的，要具体到每一步的操作。在这个部分，步骤一定要清晰、简洁，让别人能够轻松的理解并完成操作这个可以分成几个步骤来写，如步骤1、步骤2、步骤3等。例如：1. Menu - Call register - enter one of full window choice items;2. Receive

38、a call;3. Reject it or remote end terminats the call.l Description of the error:对发生错误的描述，用简明易懂的话详细地把这个Error描述清楚。注意几个要点：“详细”、“简明”、“清晰易懂”。例如：After rejecting a call or having a missed call when viewing items under full window choice items in call register. The phone goes back to the full window choice

39、items under call register.l Description of expected result:描述期望的操作结果，这个在case中一般都有说明，一般情况下，case的执行结果就是期望的操作结果。这里描述的是，期望情况下，“应该”是什么结果.例如：The phone should remain in the same state just as before receiving a call.l SIM card used:所用的SIM卡是中国移动（CMCC）还是中国联通(CHN-CUGSM)。例如：CMCCl SW version and Language packag

40、e:所测手机软件的版本号可通过在待机状态下按“*#0000#”来获得。我们现在所测的手机语言包大部分都是C包，语言包可通过下面的方法来获得：把手机恢复出厂设置，进入短信的编辑窗口，此时默认的输入法如果是“拼音”，则语言包为C包。例如：V5.20C2.6.4 进度报告l 工作时间（小时数）；l 测试用例执行情况：n Total:已经完成的测试用例数目；n Fail:其中出错的测试用例数目；n Pass:通过的测试用例数目；n Not Test:未测的测试用例数目；n Not Available:无法测试的测试用例数目；l 发现的所有错误的列表；l 执行的所有测试用例及其结果的列表。2.6.5 总

41、结报告l 测试活动的时间l 测试投入的人力l 测试效果和结论l 测试用例通过情况列表l 发现所有错误的列表l 所有仍未关闭的错误报告列表3 手机相关3.1 GSM3.2 GPRS见上面文件。3.3 CDMA3.4 3G 4 手机软件测试工程师必备素质4.1 Team Leader的任务和必备能力l 熟悉本组成员，包括知识、能力、经验、爱好等等l 是客户方和本组成员的接口，负责两者之间的沟通l 负责分配本组的任务，包括制定计划和日程安排l 总结每天的工作结果，若有重要的Error须汇报客户方负责人l 新进测试工程师的培训l 回答本组内其他测试人员的问题l 制作工作进度表，随时报告本组工作进度l

42、监督协调本组成员的工作l 收集本组成员的建议和要求l 部分测试工作l 检查测试条件是否满足l 控制工作质量4.2 Error Manager的工作内容l 确认Error的真实性l 确定Error的Priority和Severityl 遇到问题时需要和客户方负责人商量l The daily work of an error manager is handling errors and answer questions asked by testers, engineers.To finish the work well, an error manager must have the follow

43、ing skills. 1. An error manager must be more familiar with the UI spec than the others. 2. An error manager must be familiar with the process of handling errors. For example: If there is an error needing to be handled, the error manager should do the following things. a. Check whether the error repo

44、rt is complete or not. b. Make sure the error report is clear and clean. c. Using all the related knowledge to judge whether it is a real error. d. If not, set it to be ignored. If yes, search all the errors in the database to find whether it is a known error. e. If yes, set it to be duplicated. If

45、not, try to reproduce it and add more information to the report. f. During the above steps, a manager should keep more communication with the reporter. g. Finally, check who is the SCF that the error should be sent to. 3. An error manager must be familiar with the process of an errors living. 4. Be

46、familiar with the tools, such as Lotus Notes, PC suite, Phoenix and so on.4.3 测试工程师职责和应有素质l Read UI Specificationl 学习数据库里的Error Report（格式、内容和别人的思路）l 测试工作l 写Error Report和Test Casel 熟练使用相应的软件和工具l 态度明确、端正，有责任心，严谨的工作作风l 良好的沟通和协调能力，积极主动地与别人交流l 技术能力n 测试知识和技术n 编程知识和技术n 无线协议知识n 软件知识n 硬件知识l 语言水平英语水平精品资料网（http:/）成立于2004年，专注于企业管理培训。提供60万企业管理资料下载，详情查看：http:/map.htm提供5万集管理视频课程下载，详情查看：http:/zz/提供2万GB高清管理视频课程硬盘拷贝，详情查看：http:/shop/2万GB高清管理视频课程目录下载：http:/12000GB.rar高清课程可提供免费体验，如有需要请于我们联系。咨询电话：020-39603888值班手机：13726708999网站网址：n