手机测试技术

1、手机软件测试技术手机软件测试技术9/072内容内容l软件测试基本理论l研发过程中的软件测试l手机软件测试l软件测试管理3第一讲软件测试理论第一讲软件测试理论1.概念2.理论测试方法及覆盖率3.测试设计4什么是软件测试什么是软件测试l定义：使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的要求或是弄清预期结果与实际结果之间的判别。重要的质量保证活动尽可能多的发现问题l设计l需求l编码l功能5软件测试必要性软件测试必要性l70年代之后的软件危机高级开发语言的引入软件规模扩大及复杂度急剧增加可视化编程环境日益完善的软件分析设计方法l软件开发活动所产生的产品质量越来越不可控有

2、开发就会有错误影响产品利润影响公司声誉6软件测试目的软件测试目的l60年代证明观点获取系统在可接受风险范围内可用的信心尝试在非正常情况和条件下的功能和特性保证一个工作产品是完整的并且可用或者可被集成l70年代检测观点发现缺陷、错误和系统不足定义系统的能力和局限性提供产品和系统的质量信息l90年代预防观点澄清系统的规格和性能提供预防或减少可能制造错误的信息尽早检测错误确认问题和风险，提前确认解决这些问题和风险的途径7软件测试在开发中的角色软件测试在开发中的角色l测试是执行或者模拟一个系统或者程序的操作l测试是为了建立一个信心，即软件是按照它所要求的方式执行的，而不会执行它不被希望的操作l测试是带

3、着发现问题和错误的意图来分析程序的l测试是度量程序的功能和质量的l测试是评价程序和项目工作产品的属性和能力的，并且评估其是否获得了期望和可接受的结果l测试除了包括执行代码测试，还包括检视和结构化同行评审8软件测试理论发展软件测试理论发展需求Error概要设计Error详细设计Error编码阶段Errorn2n3nIBM缺陷修改成本趋势图IBM缺陷放大模型9软件测试理论发展软件测试理论发展l传统意义上的测试调试观点代码完成后期介入l开发活动观点整个开发过程测试始终要完成验证和确认的任务开发模型（瀑布模型、螺旋模型、V模型等）开发规范中明确了各阶段测试任务（CMM、IPD等）10理论测试方法理论测

4、试方法l白盒测试White Box Testing, Glass Box Testing, Open Box Testing, Structured Testing, Code-Based Testing代码级测试基于对系统内部结构及工作原理清楚认知基于编程规范l黑盒测试Black Box Testing, Function Testing功能级测试基于需求及功能实现及可执行过程l灰盒测试基于接口及子系统的测试介于白盒测试及黑盒测试之间l代码审查及文档评审基于编程规范基于文档规范11白盒测试白盒测试l保证软件产品最小单元函数或模块的开发质量函数中的语句均能被有效执行到函数中的逻辑路径的正确性变

5、量边界有效内部数据结构有效内存有效管理（申请、释放）符合编程规范l单元测试为白盒测试应用12白盒测试技术白盒测试技术l静态测试不通过执行程序而进行测试的技术l代码审查（软件检视、走读）l语法分析工具（Logicscope / WhiteBox / C+ test)l没有基本语法错误或逻辑性错误l动态测试对函数或者模块进行模拟测试过程l路径及分支测试l动态测试工具 (C+ test / Logicscope / Jtest)l达到基本覆盖率13白盒测试的覆盖率要求白盒测试的覆盖率要求l代码覆盖率语句覆盖（Statement Coverage)l通过执行测试用例，使程序中的可执行语句至少执行一次分

6、支覆盖（Branch Coverage)l程序中的各分支至少被执行一次条件覆盖（Condition Coverage）l每个判断中的每个条件可能取值至少满足一次14白盒测试的覆盖率要求白盒测试的覆盖率要求举例判定条件：（A1）（A: 1, =1）判定条件：（B0）（B:0）判定条件：（B0）（B:=0, 0）If ( A 1) AND (B 1) AND (B 1B1B=01,3,41B01,5,6条件覆盖=1B=01,3,401,5,6=1B01,5,615黑盒测试黑盒测试l黑盒测试目标产品功能均被正确执行，符合需求规格要求功能异常均被正确处理产品健状性，不会出现异常情况l被用于发现以下可能

7、发生的错误功能错误或遗漏界面错误初始化或终止错误抗压力性错误性能方面部分错误l功能覆盖率l系统测试为黑盒测试应用16黑盒测试技术黑盒测试技术l功能测试l性能测试l压力测试及可靠性测试l稳定性及安全性测试l文档测试l本地化（Localization)测试l兼容性测试17灰盒测试灰盒测试l基于代码级，但以功能模块划分被测对象的测试方法l所测试对象为接口及子系统接口l关键是确定好被测对象l集成测试为灰盒测试应用18测试设计测试设计l测试方案、策略l测试计划l测试需求及程序插装测试覆盖率测试有效性检测l功能是否可测断言检测l测试用例设计是测试执行的单位与依据依据文档功能描述或特定被测试对象（函数、模块

8、）实现功能来编写19测试用例测试用例l根据输入、预置条件与测试步骤存在的不同，确定符合规格要求的预期输出用例编号用例名称用例级别用例标题预置条件输入测试步骤预期输出实际输出测试员是否问题20测试用例设计方法测试用例设计方法l等价类划分根据需求规格说明书，所有可能的输入集合被分成一个一个的类。同一类中的数据被认为会产生相同的执行结果。l边界值分析基于等价类，对输入域进行测试，等价类边界内、外及边界上的测试大量的错误发生在输入或输出范围的边界上。l判定表l因果图l正交法21等价类划分等价类划分l有效类使产品按规格说明书中要求，正确工作的输入参数值的集合。l无效类不符合产品正确工作的输入参数值的集合

9、。例：1。每条短消息发送最长不允许超过182个字符。2。允许存储50个电话号码有效类：0,182，无效类：（183，）有效类：0,50，无效类：（50，）边界值：0,182,183,0,50,5122第二讲研发过程中的软件测试第二讲研发过程中的软件测试l软件验证与确认lV开发模型l测试在各阶段的活动23V开发模型开发模型l软件工程思想已经成为软件产品开发的主导软件能力成熟度模型CMM（Capability Maturity Model)l软件开发模型1.建构修改循环模型（Build and Fix Model） 瀑布式开发模型（Waterfall Model） 增量模型（Incremental

10、 Model） V形开发模型（V Shape Model） 快速原型模型（Rapid Prototype Model） 螺旋型开发模型（Spiral Model） 极限型开发模型（Extreme Programming Model）l各阶段测试活动24需求分析系统测试概要设计集成测试详细设计单元测试编码需求分析说明书系统测试方案、计划、用例概要设计说明书集成测试方案、计划、用例详细设计说明书单元测试方案、计划、用例系统测试报告集成测试报告单元测试报告V开发模型开发模型25软件验证与确认软件验证与确认l软件验证与确认（Software Verification and Validation)：软

11、件生命周期中对其进行评估的规范化的方法l验证用于在软件开发生命周期中保证前面进行的活动是满足特定需求的用数据证明我们是否在正确的制造产品l能正确执行其被要求的功能l不能执行不被要求的功能l软件测试应被认为是一个验证的过程.l确认l在生命周期阶段结束是否满足了客户的需要。l用数据证明我们是否制造了正确的产品262728测试实施测试实施-需求分析阶段需求分析阶段l测试质量活动参与需求分析讨论熟悉产品功能、规格对开发文档进行评审、检视（统计数据）。Checklist及预审表29测试实施测试实施-需求分析阶段需求分析阶段l测试开发活动提出测试需求。准备测试开发。编写测试文档，确定测试计划、测试工具、测

12、试设备需求。测试文档：系统测试方案、系统测试计划、系统测试用例30系统测试计划系统测试计划l系统测试计划需要明确：人力需求计划系统测试时间安排计划，包括每一轮测试时间多长，要进行几轮测试，才能发布测试环境需求计划测试设备需求计划测试工具需求计划31系统测试方案系统测试方案l系统测试方案需要明确系统测试策略需要明确系统测试的测试模型及测试组网图,测试环境设计。功能测试分组(可以一个人完成，也可以多个人完成)。测试工具需求产品可测试性需求以及其他方面的需求可测试性需求以及其他方面的需求需要进行测试类型（功能测试、性能测试、负载测试、安全性测试等）系统测试通过或者结束标准。32测试实施测试实施-概要

13、设计阶段概要设计阶段l概要设计阶段参与概要设计方案讨论熟悉软件接口、模块划分、流程对开发文档进行评审、检视（统计数据）测试需求实现设计编写相关测试文档对上一阶段的测试文档进行修改、补充开发文档：概要设计说明书测试文档：集成测试方案、集成测试计划、集成测试用例33集成测试计划集成测试计划l集成测试计划同单元测试计划内容相同，对测试环境要求更为具体。l集成测试计划的内容包括：集成测试时间安排、人力需求计划、环境需求计划、测试工具需求计划、文档输出计划、人员培训计划（包括测试工具使用、测试用例编写等培训）等。l集成测试工具l集成测试计划可以与方案一起编写34集成测试方案集成测试方案l集成测试方案在概

14、要设计阶段进行编写。l方案要明确集成测试的测试策略，包括如何划分集成测试模块(由多个单元组成)；集成测试通过的标准；测试环境配置情况；集成测试工具及测试设备；测试用例设计方法；测试用例的分类；l集成测试测试策略关键是测试模块的设计。一般依据模块间的耦合度按增量式集成方法来划分模块。增量式集成测试方法分为自底向上及自顶向下两种方式。l方案中要明确集成测试模型，即模块划分示意图。l子系统间的集成。35集成测试自顶向下集成集成测试自顶向下集成l自顶向下集成是构造程序结构的一种增量式方式，它从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块集成在一起。 l首先确定各模块

15、间的关系图。然后根据各模块间的耦合度，采用深度或广度设计测试对象。以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代；依据所选的集成策略（深度优先或广度优先），每次只替代一个桩模块；每集成一个模块立即测试一遍；只有每组测试完成后，才着手替换下一个桩模块；为避免引入新错误，须不断地进行回归测试（即全部或部分地重复已做过的测试）。 36集成测试自顶向下集成模型集成测试自顶向下集成模型M1：消息接收模块M2：Msg1解码模块M3：字段处理模块，判断各IE是否正确。M4如果IE都正确，编写新消息或者直接打包发送。M5：Msg2解码模块M6：字段处理模块，判断各IE是否

16、正确。M7如果IE都正确，编写新消息或者直接打包发送。M8：Msg3解码模块M9：字段处理模块，判断各IE是否正确。M10如果IE都正确，编写新消息或者直接打包发送。37集成测试自底向上集成集成测试自底向上集成 l自底向上测试是从“原子”模块（即软件结构最低层的模块）开始组装测试，因测试到较高层模块时，所需的下层模块功能均已具备，所以不再需要桩模块。 自底向上综合测试的步骤分为：1 划分模块之间的关系，确定被测模块划分;2 开发一个测试驱动模块，控制测试数据的输入和测试结果的输出； 3 采取增量方式对每个被测模块进行测试；4 删除测试使用的驱动模块，用较高层模块把模块群组织成为完成更大功能的新

17、模块群。 38集成测试自底向上集成集成测试自底向上集成39集成测试用例集成测试用例l根据方案设计，对各被测模块设计测试用例。l集成测试用例设计方法与单元测试用例设计方法一样，但是测试用例的输出要上升到模块功能级别，观察点要多。l集成测试用例的自动化。在引入自动化测试工具的情况下，集成测试用例设计要适于自动化观察。40测试实施测试实施-详细设计阶段详细设计阶段l详细设计阶段参与详细设计方案讨论熟悉各模块的设计、参数配置等对开发文档进行评审、检视（统计数据）测试需求实现设计编写相关测试文档对上一阶段的测试文档进行修改、补充开发文档：详细设计说明书测试文档：单元测试方案、单元测试计划、单元测试用例4

18、1单元测试计划单元测试计划l单元测试计划与测试方案重点需要确定单元测试策略多少行以上代码的函数单元需要进行测试需要达到的覆盖率标准要求装模块及驱动程序策略42测试实施测试实施-编码阶段编码阶段l编码阶段进行代码审查-C语言编程规范对上一阶段的测试文档进行修改、补充准备测试工具进行代码静态测试。-静态测试工具43测试实施测试实施-单元测试阶段单元测试阶段l单元测试阶段进行单元测试编写单元测试报告单元测试由谁完成？测试人员还是开发人员？44单元测试执行单元测试执行驱动模块被测模块桩模块桩模块桩模块测试用例l单元测试用例执行前一般需要设计桩模块与驱动模块。驱动模块是用来模拟被测试模块的上级调用模块。

19、驱动模块使被测模块可以有效获得输入，并能够产生输出。桩模块则用来代替被测试模块所调用的模块。 45单元测试报告单元测试报告l根据测试结果输出单元测试报告。执行用例数，是否达到覆盖率要求，测试用例执行率，问题数目，问题回归情况。对本次测试结果分析。l为什么没有达到覆盖率要求。l问题种类，以及问题产生原因等。l测试报告评审。46单元测试停止标准单元测试停止标准l1) 单元测试用例、报告通过评审 l2) 按照单元测试计划完成了所有规定单元的测试 l3) 达到了测试计划中关于单元测试所规定的覆盖率的要求，一般要求语句覆盖率达到100%，其他覆盖率可以不做要求。l4) 被测试的单元每千行代码必须发现至少

20、3 个错误 l5) 软件单元功能与设计一致 l6) 在单元测试中发现的错误已经得到修改， 各级缺陷修复率达到标准47测试实施测试实施-集成测试阶段集成测试阶段l集成测试阶段进行集成测试完成集成测试报告，评估是否达到测试目标。48集成测试集成测试l集成测试属于灰盒测试。l集成测试的对象是一个概念：即由多个单元组成的模块。l介于单元测试与系统测试之间。所测试的内容包括单元间的接口以及集成后的模块功能。此处模块功能一般不是整个产品的功能，而只是相关单元组合后的逻辑模块所完成的功能，比如只实现某条消息的编码或者解码，或者消息打包等。l目的是确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为

21、正确。l集成测试发现的是什么类型的问题？49集成测试执行集成测试执行l如果采用自顶向下测试方法，需要首先设计桩模块。采用增量方式，对不同的被测模块进行测试。l如果采用自底向上的测试方法，需要首先设计驱动模块，然后采用增量方式，对不同的被测模块进行测试。l完成测试后，出具集成测试报告。l测试报告评审。50集成测试停止标准集成测试停止标准l1) 集成测试用例设计已经通过评审l2) 按照集成构件计划及增量集成策略完成了整个系统的集成测试l3) 达到了测试计划中关于集成测试所规定的覆盖率的要求，集成测试代码语句覆盖率一般要求达到40%60%。l4) 被测试的集成工作版本每千行代码必须发现2 个错误l5

22、) 集成工作版本满足设计定义的各项功能、性能要求l6) 在集成测试中发现的错误已经得到修改， 各级缺陷修复率达到标准51测试实施测试实施-系统测试阶段系统测试阶段l系统测试阶段进行系统测试完成系统测试报告系统测试由测试工程师完成系统测试内容，评估是否达到测试目标。52系统测试系统测试l系统测试主要是指对整个产品功能性的测试，不仅要对软件实现的功能进行验证（验证测试），尤其需要对异常流程进行测试，通常，系统测试是用来发现产品存在缺陷的主要手段。l一般系统测试需要进行三个轮次的测试。每一轮测试均是针对不同的版本进行。l经过系统测试的产品在达到系统测试结束标准后，可以发布。53系统测试可测试性需求系

23、统测试可测试性需求l由于系统测试属于黑盒测试，所以需要根据系统测试（包括功能、性能等）的需要观察验证的内容来确定软件的可测试性需求。在单元与集成测试时，均可以用开发工具来观察内存分配情况，但在系统测试时，该测试方法失效，因此需要从开发方面能够提供有效信息。l可维护性需求也属于系统测试需求之一。比如系统在运行期间，出现错误，如何进行定位，以及是否能够进行远程定位等。54第三讲手机系统测试第三讲手机系统测试l手机测试过程l功能测试lField Trial 测试l兼容性测试lLocalization Test55测试流程测试流程l项目Kick offl根据项目Schedule制定测试计划l理解项目需

24、求及功能需求l根据需求文档编写测试用例l手机测试版本发布l执行测试l编写测试报告56Test category definitionSanity Test Release TestlPre-CTTL testlUG&SW crossing checklCU WAP testlCU IMAP test57Test category definitionlRUIM Compatibility testlFull Feature testlSFT testinglRegression TestlInput method TestlFree test58Software Development

25、 stagelTA: Type approval.This is a certification stage. It contains: SAR, FCC EMC, SRRD, CTTL, WTS, TMC, etc.lPA: Product Acceptance. This is a certification stage. The testing for each carrier acceptance. Such as CU Lab entry.lLaunch: Software release to end user.59TA PhaseLaunch PhaseSWTPA Phase1.

26、Sanity Test2.EV Test3.Release Test 4.Feature TestAdd feature TestFull Feature Test (level 1/level 2)WAP/IMAP/DRM middleware Test Zi Input Test Accessory TestRUIM Compatibility TestPre-CTTL Test5.TA Regression Test1.Sanity Test2.EV Test3.Release Test4.Feature TestFull Feature Test (level 1/level 2/le

27、vel 3)WAP/IMAP/DRM Middleware Test Protocol (PRI) TestStress Test5.CCS Test6.PA Regression Test7.True Test1.Sanity Test2.EV Test3.Feature TestFull Feature Test (level 1/level 2/level 3)WAP/IMAP/DRM Middleware Test Protocol (PRI) TestStress Test4.CCS Test5.All Regression Test6.True Test60Sanity Testl

28、Sanity Test is the first pre-test process when the new software version released. lSanity Test the general features, make sure software maturity and stability for planning test.lSanity Test is a pre-testing step before each software release to customer.61Error Verification (EV) TestlEV test is the s

29、econd pre-test process when the new software version released. lSoftware RD should provide fixed error list in Release Notes. SWQA verify whether these errors are fixed in the new software release.lEV is also a pre-testing step before each software release to customer.62Release TestlRelease test is

30、the basic test process when the new software version released. lThe test is based on all the major and important functions of each module. The coverage is more extensive than SSC.lThe test purpose is making sure the simple and critical problem can be found as early as possible. 63UG&SW cross che

31、cklUG (User Guide) &SW cross check is a TA test item. lUG testing is a CTTL requirement.lThe testing is based on the description of UG, to check the UI and function about the software. It is also a cross testing about all software functions. 64Full feature testlFull Feature Test is the comprehen

32、sive test process.lThe testing will cover all the functions and UI displays of the phone, SWQA can find most of the bugs through the testing. 65Error Regression TestlError Regression Test is a testing for the errors.lThere are many bugs detected, study and fixed along the testing, the testing make s

33、ure that all of the fixed bugs will not come out again. lThe testing will be started for each milestone, TA, PA and Launch. 66Test Case Development ProcessStudy Spec Analysis function items Compose test requirementEstablish test plan (test case)依据需求文档，根据测试用例设计方法设计系统测试用例。更新Test case 库。67SWT Process68

34、Error ReportlError report 需要包含详细的信息标题、优先级、发现者、软硬件版本号、发现日期、错误编号Bug描述（预置条件、输入、预期输出、实际输出、是否能够重现）69Test Reportl测试完毕，提交本版本测试报告l总结本次测试用例执行情况，错误发现情况，并对产品成熟度进行一定评估70手机功能测试手机功能测试lUI功能测试与实际网络环境不相关，手机不在网的情况下仍然能够运行的功能项lGame, Camera, Setting, Contact etc.lReal net 功能测试与实际网络环境相关，须在网情况下才能使用的功能项lCall, message, 数据业务Wap/IMaplInteraction 功能测试各功能模块间的交互性测试lGame 与Call, Message 与Calll压力测试某此功能项的压力值测试l多次开关机、收发足够短消息（20）l用户手册（User Guide）测试71Field Trial 外场测试外场测试l手机与基站间的兼容性测试l手机移动情况下Real net 基本功能测试lLong Call 性能测试l呼叫、接听成功率性能测试l入网测试项测试l与协议相关内容测试72兼容性测试兼容性