手机软件测试基础

1、BTX-ST软件测试人员基本素质手机软件测试基本概念手机软件测试内容软件测试的基本方法主要的参考资料良好的个人素质责任心：责任心是做好工作必备的素质之一，测试工程师更应该将其发扬光大。如果测试中没有尽到责任，甚至敷衍了事，这将会把测试工作交给用户来完成，很可能引起非常严重的后果。专心：主要指测试人员在执行测试任务的时候要专心，不可一心二用。经验表明，高度集中精神不但能够提高效率，还能发现更多的软件缺陷，业绩最棒的往往是团队中做事精力最集中的那些成员。细心：主要指执行测试工作时候要细心，认真执行测试，不可以忽略一些细节。某些缺陷如果不细心很难发现，例如一些界面的样式、文字等。耐心：很多测试工作有

2、时候显得非常枯燥，需要很大的耐心才可以做好。如果比较浮躁，就不会做到“专心”和“细心”，这将让很多软件缺陷从你眼前逃过。自信心：自信心是现在多数测试工程师都缺少的一项素质，尤其在面对需要编写测试代码等工作的时候，往往认为自己做不到。要想获得更好的职业发展，测试工程师们应该努力学习，建立能“解决一切测试问题”的信心。“五心”只是做好测试工作的基本要求，测试人员应该具有的素质还很多。例如测试人员不但要具有团队合作精神，而且应该学会宽容待人，学会去理解“开发人员”，同时要尊重开发人员的劳动成果开发出来的产品。正确的思考方式Oracle Heuristics: “HICCUPP” 原则原则Consis

3、tent with History: Present function behavior is consistent with past behavior. Consistent with our Image: Function behavior is consistent with an image that the organization wants to project. Consistent with Comparable Products: Function behavior is consistent with that of similar functions in compa

4、rable products. Consistent with Claims: Function behavior is consistent with what people say its supposed to be. Consistent with Users Expectations: Function behavior is consistent with what we think users want. Consistent within Product: Function behavior is consistent with behavior of comparable f

5、unctions or functional patterns within the product. Consistent with Purpose: Function behavior is consistent with apparent purpose. 更多更好的思考Conjecture and Refutation: reasoning without certainty. 怀疑、驳斥：大胆推理Adductive Inference: finding the best explanation among alternatives. 小心求证：在众多解释中选择最合理的解释Latera

6、l Thinking: the art of being distractible. 水平思考：发散性思维的艺术Forward-backward thinking: connecting your observations to your imagination. 正向、逆向思维：把你观察到的和你想象的联系起来Heuristics: applying helpful problem-solving short cuts. 启发式的思维：问题解决的绝对有效途径De-biasing: managing unhelpful short cuts. 去偏解：管理无效的路径Pairing: two te

7、sters, one computer. 对比：两个测试人员，一台电脑Study other fields. Example: Information Theory. 学习其他领域，比如信息技术良好的技术背景对无线移动通信网络知识,基本的网络协议以及网络工作原理 ,计算机知识, 甚至是摄影知识积累对于软件测试都有很大的帮助掌握必要的软件测试知识和软件工程基本知识对于我们自身的提高也是大有裨益的掌握必要的软件编程知识,对于深入测试, 编写利用自动测试脚本，可以起到事半功倍的效果作为一名测试人员，尽管不能精通所有的知识，但要想做好测试工作，应该尽可能地去学习更多的与测试工作相关的知识。 软件测试的

8、目的软件测试的目的从软件开发者的角度出发，表明软件产品中不存在错误的过程，验证该软件达到要求，确立人们对软件质量的信心? 符合需求设计文档的要求 ? 符合一些应用标准的要求，比如不同国家的用户不同的操作习惯和要求，项目工程中的可维护性、可测试性等要求 从用户角度出发，暴露软件中存在的错误和缺陷。从客户的需求出发，从客户的角度去看产品，客户会怎么去使用这个产品，使用过程中会遇到什么样的问题。只有这些问题都解决了，软件产品的质量才可以说是上去了软件测试人员的任务和目标软件测试人员的任务和目标尽量短的时间尽量多的发现Bug；衡量软件的品质；关注用户的需求。总的目标是：确保软件的质量。软件测试原则软件

9、测试原则测试是需要设计的, 一个好的测试计划和测试用例往往能达到事半功倍的效果。测试是一项具有很大创造性的工作，其工作量一点也不比软件设计小。软件测试的创造性主要表现在测试方案选择、测试计划制定、测试用例设计、测试结果的分析以及测试过程的管理等方面。应当把“尽早和不断的测试”作为开发者的座右铭测试工作应该由独立的专业的软件测试部门来完。一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。对测试错误结果一定要有一个确认的过程，一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短

10、的时间内完成一个高水平的测试。回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见。妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。如何理解这句话却仁者见仁，智者见智软件测试原则软件测试原则Good-enough原则：这是一种权衡投入产出比的原则，测试既不要不充分，也不要过分。不充分和过分都是一种不负责任的表现。Zero-bug是一种理想，Good-enough是我们的原则。Pareto原则：一般情况下，在分析、设计、实验阶段的复审和测试工作能够发现和避免80的bug，而系统的软件测试能够找出其余bug中的80。最后约5%的bug只有在

11、用户大范围、长时间的使用后才会暴露出来。因此测试只能保证尽可能多地发现错误，不能保证发现所有的错误。彻底的测试是不可能的。在测试中不可能穷举所有的路径，但充分覆盖程序逻辑，并确保软件的所有条件是有可能的所有的测试都应追溯到用户需求。软件测试的目的在于揭示错误，而最严重的错误（从用户角度看）是那些导致程序无法满足需求的错误软件测试效率的几点建议软件测试效率的几点建议首先测试程序的核心功能，然后测试辅助功能。 首先测试功能，然后测试性能。 首先测试常见情况，然后测试异常情况。 首先测试经过变更的部分，然后测试没有变更的部分。 首先测试影响大的问题，然后测试影响小的问题。 首先测试必须测试的部分，然

12、后测试可选或没有要求测试的部分 软件测试测略软件测试测略1. Release Test (又名又名BVT Build Verification Test )Purpose: 测试手机的基本功能是否实现，是否有进一步测试的必要性Attention: Release Test的Test Case具有一定的典型性，主要是反映手机最基本功能的Test Case本类测试只需要依据Test Case进行测试，不需要进一步发挥如果有发现与Case无关的Error, 在测试通过后才可以填报Error Report此类测试有一门槛值，即Test Case的Pass率达到一定值（如95%）才能宣布版本发布成功，进

13、入进一步的测试，否则此版本无效。除了门槛值外，如果重要功能模块的Test Case没通过，也会终止这个版本。2. System TestFull Round System TestPurpose对手机的所有功能进行全面的测试(所有语言包) 由于Case不可能包含所有方面，所以测试时应适度发挥，尽力完成全面测试 Common System Test (Medium or Minor)Attention: System Test一般分为两个部分，“跑Case”和Free Test。 当所有Test Case都测完后，就进入Free Test期间。这里的Free Test具有明确的目的性和范围。一般

14、来说，这段时间的Free Test只需要测自己负责的模块。而且Free Test还负责重现前期“跑Case”是遗留的不可重现的Error。 在测试初期，一般只需要按照Test Case测，把一些不可重现的Error都记录下来。同时遇到Test Case的问题或者不充分，应该立即解决（和Team Leader或者Special List讨论，补写Test Case）。在这一阶段结束后，一般要写一个Summary Report。把这一阶段的测试结果和遇到的问题、自己的见解都写在里面（当然是用English）。3. Focus TestPurpose: 集中于一个或几个点进行测试(同System T

15、est) 软件测试策略软件测试策略4 Stress Test Purpose:为了解决市场上发现的重大Error，而进行的有针对性的强度测试主要是利用边缘测试（临界测试）手段Attention: 压力测试，顾名思义，是给手机施加一定压力，从而找出手机软件上的Error。一般来说，对手机施加的压力主要有：存储压力：由于手机采用的是栈式存储，所以当一个存储块满了之后，如果程序员不做相应处理或者处理不好的话，很容易造成其他存储区被擦除，从而在UI上出现问题（其他功能无法正常使用）。边界压力：边界一直是程序员最容易忽略的地方。响应能力压力：有时候某个操作可能处理的时间很长，在处理期间如果测试者再不断地

16、进行其他操作的话，很容易出现问题。网络流量压力（如在接电话时进行短信服务）等等。n 在项目中，Stress Test有时也会用来重现不可重现的Error。由于有不少不可重现的Error是由于Memory Leak(内存泄漏)引起的，所以不停的重复同一个操作是重现一个不可重现的Error的一个好方法5. Free TestPurpose:测试System Test中没有做完的不可重现Error寻找平时没有找到的忽略的ErrorAttention:在System Test阶段所用的Free Test具有明显的目的性和范围平时的Free Test从理论上应该对所测试的范围穷尽所有的测试方法。但是，这

17、是不现实的。在实际项目中，主要有两个方面是Free Test所需要重视的。从UI Spec上找灵感。应为Test Case是依据UI Spec写的，所以从UI Spec上突破是一个行之有效的方法。UI Spec有一定的探索深度，加大探索深度，是一种突破的途径；另外同一个功能用其他不同的方法去实现，也是一种突破途径。多关注不同Feature之间的Interaction。这是手机软件相对比较容易出问题，而Test Case又很少能反映的地方。这是一个很大的Free Test空间软件测试的基本过程软件测试的基本过程一个规范化的软件测试过程通常须包括以下基本的测试活动。拟定软件测试计划编制软件测试大纲

18、设计和生成测试用例实施测试生成软件问题报告 对整个测试过程进行有效的管理实际上,软件测试过程与整个软件开发过程基本上是平行进行的。测试计划早在需求分析阶段即应开始制定,其它相关工作,包括测试大纲的制定、测试数据的生成、测试工具的选择和开发等也应在测试阶段之前进行。充分的准备工作可以有效地克服测试的盲目性,缩短测试周期,提高测试效率,并且起到测试文档与开发文档互查的作用。软件测试的基本流程软件测试的基本流程(1)测试工程师的工作流程，与公司的整体工作流程，项目的测试要求等因素相关。本文主要讨论测试工程师的一般工作流程。 做好测试准备 1) 明确测试任务的范围 测试文档通常包括测试目的、测试环境、

19、测试方法、测试用例、测试工具等。测试工程师首先要通读文档，对整个测试要求形成整体认识，明确测试目的，以及测试要求和测试重点，明确软件测试方法和使用的测试工具。 2) 明确测试时间 明确测试周期和测试时间进度。如果是多人合作完成一个软件，则要首先明确属于自己的测试内容、根据测试内容和测试周期，估算自己每日应该完成的工作量。此外由于软件测试是群体协作的测试活动，需要明确哪些测试内容要与其他测试工程师协作才能完成。 3) 设置测试环境 根据测试文档要求，设置测试需要的软件和硬件环境，包括操作系统，要测试的软件和其他必要的测试工具软件等。所有这些完成后，分别运行，查看是否能正确运行，保证符合测试文档要

20、求的测试环境。 4) 学习被测试软件 对于不太熟悉的软件，可以通过阅读软件自身的教程和帮助文件，学习本软件的一般操作方法，也可以参照相关的书籍资料等。另外，向熟悉测试软件的其他同事请教软件使用方法，也是学习软件的一条捷径。对软件使用越熟练，测试过程越顺利，测试效果越理想。 5) 确认完全理解测试任务 软件测试最重要的要求就是确实明确了测试任务和要求，这包括正确理解了测试文档，确认可以按照测试进度要求，完成测试。对于测试工具要正确安装，熟练使用。如果有任何不明白之处，向软件测试负责人询问。切忌凭自己的理解和主观推测，自行其事。当然，真正测试中，往往会遇到各种新的小疑难问题，也需要及时向测试负责人

21、请教，以保证测试顺利进行。 软件测试的基本流程软件测试的基本流程(2)执行软件测试任务 1) 按照测试文档要求，逐项认真测试 根据测试文档测试要求，按照测试步骤，逐项进行。通过运行软件，观察测试结果，与软件需求说明书的内容进行比较，找出软件错误。对于需要调用测试用例的测试，保证正确地调用了测试用例，注意观察和分析测试结果。某些不容易重复的错误，需要反复测试，总结重复该错误所需要的测试步骤，直到确认可以重复出现为止。 2) 记录发现的错误，填写软件问题报告 为了纠正软件中的错误，测试工程师要正确记录发现的错误，将错误再现的步骤写入测试报告中，测试报告是程序测试的重要组成部分，正确书写测试报告是对

22、测试工程师的基本要求。采用软件缺陷数据库管理测试中发现的软件缺陷，每一条错误作为数据库的一条记录，方便记录、修改、查询。 3) 填写测试进度表和必要的测试内容记录表 每天将测试内容写入测试进度表文档，可以使测试负责人了解测试进度，控制测试周期内测试的连续性，增强测试过程控制性，保证测试的正常进行。测试记录要准确完整，实事求是，必要时插入测试注释，解释测试中的特殊问题。测试进度表是评价测试质量和工作内容的重要凭证，对于测试后发现的测试错误和失误，可以通过检查测试记录，寻找产生错误的原因。 4) 测试中发现疑难及时请教 测试是一个动态的过程，可能由于自己的错误操作或者测试文档内容的错误，使得测试过

23、程中出现自己不能解释的现象或结果，出现与测试要求不符合的情形，这时可能需要与其他测试者协商或求助，如果问题仍然不能解决，应该及时请教，听取意见和建议，必要时反复讨论直到问题全面解决。 全面检查测试结果 1) 对照测试文档要求，检查测试内容是否完整 测试完成后，要对照测试文档检查测试是否全部完成，保证没有丢失测试内容。如果某些内容，由于测试环境的要求不满足，或者由于测试时间短没有进行，则要写入测试进度表文档。 2) 检验书写的软件问题报告的记录，使之确切、规范 正确书写测试记录是保证迅速定位软件错误，加快改正错误的必要前提。专业规范的软件记录报告是体现公司测试水平和专业实力的外在体现。认真检查书

24、写的每条记录是否符合规范，格式、步骤、内容一一检查，必要时补充或删减。 上述三个阶段，相互联系紧密，其中准备是基础，测试是重点，检查是保证，应该根据测试的软件特点合理安排软件测试配置软件配置管理：软件需求规格说明书，设计规格说明书，源代码等管理。（Rational Clear Case/ Clear Quest）测试配置工具：测试计划，测试用例，测试程序等。（VSS）测试工具：测试数据自动生成程序，静态分析程序，动态分析程序，测试结果分析程序，以及驱动测试的测试数据库， 自动测试工具（Winrunner）其他测试工具 ? Log工具QXDM/QPST/VPST/ETS? 电流测试工具? Now

25、 SMS （可以测试GSM SMS, WAP PUSH,MMS notification 等）? Helix server流媒体测试? Apache WAP server? WSFTP_Pro2006B20050511.exe 流量监控? 声音格式转换工具? 第三方定位工具软件测试内容软件测试不等于程序测试，软件测试应贯串于软件定义和开发地整个期间。需求分析，概要设计，详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明，概要设计规格说明，详细设计规格说明以及源程序，都可以成为软件测试的对象。? 为把握软件开发各个环节地正确性，需要进行各种确认和验证。? 确认：是一系列的活动和过程，目的

26、是想证实在一个给定的外部环境中软件的逻辑正确性。? 验证：试图证明在软件生存期各个阶段，以及阶段间的逻辑协调性，完备性和正确性。对于我们的软件测试， 不仅仅包括手机软件，配套光盘软件，还应该包括：说明书等的测试，需求评审等手机界面测试技巧手机界面测试技巧界面风格是否一致，美观（比如左右软键/菜单风格）名称是否统一(比如说UIM/SIM,电话本/联系人)字体大小、风格是否统一是否有错别字键盘操作是否正常（功能键、快捷键,长按、短按、连续按）屏幕显示是否正常，是否有重叠、切字、乱码（在不同的语言下，快速切换）手机交互测试技巧手机交互测试技巧是各功能不同事件下的处理以矩阵交互表格方式描述用例多重事件

27、可以选择一些资源消耗大的场景选择性展开兼容性测试验证手机对部分外部设备的兼容情况,包括SIM卡，T卡，蓝牙设备也可以是其他手机传送过来的内容,比如说SMS, MMS, vCard, vcalendar否定测试（负面测试）在开发过程中，正常业务处理的代码量只占有效代码量的 10% ，而例外处理的代码量要占有效代码量的 90% 人们也可以通过经验或直觉推测系统中可能存在的各种错误，从而有真对性地编写检查这些错误的例子，这就是错误推测法。错误推测法没有确定的步骤，很大程度上是凭经验进行的。手机性能测试技巧手机性能测试技巧1 时间相关。时间相关。?时间相关的性能测试可分为长时间保持测试和限定时间反应测

28、试。?长时间保持测试主要是测试终端长时间稳定进行某项功能的能力。主要包括长时间待机能力、长时间CS域业务保持能力、长时间PS域业务保持能力、长时间组合业务保持能力等。?长时间待机测试，就是根据手机电池的能力连续不间断待机一定时间（例如4天），之后验证手机是否还能够发起主叫和被叫业务，能够发起主叫，表示终端在长时间待机后自身还处于正常状态，能够发起被叫，说明终端在睡眠模式下可以正常接收寻呼。?长时间CS域业务保持测试，就是根据手机电池的能力连续不间断进行语音通话或者视频通话一定时间（例如2小时），测试通话期间图象声音是否连续、清晰，是否有单通现象出现，是否会有手机板子过热现象。?长时间PS域业务

29、保持测试，主要是通过持续进行WWW业务、ftp业务或者流媒体业务一定时间（例如2小时），测试进行数据业务期间上下行数据传输率是否稳定，网页显示是否流畅，流媒体播放是否连续等。长时间组合业务保持测试，就是同时保持CS和PS域业务一段时间，以验证终端长时间进行组合业务的能力。?限定时间反应测试主要是测试终端在规定时间内对用户的操作作出反应，给出操作结果的能力。主要包括开机驻留时延、关机时延、CS域业务接入时延、PS域业务接入时延、本地应用的操作时延等。?开机驻留时延，是指从用户按下开机键（终端上电、系统引导、启动任务、搜索网络、完成位置更新）到终端进入待机界面，提示用户可以进行正常服务的总时间。?

30、关机时延，是指从用户按下关机键（终端完成网络detach、将RAM中修改过的数据写回flash）到终端完全下电所需的总时间。?CS域业务接入时延，是指在进行语音或视频电话时从按下拨号键到听到对方回铃声所需总时间，由于该过程需要在网络侧分配资源，所以测试结果可能会受到当前网络资源可用程度的影响，例如在网络负荷高的时候申请CS 64k业务时，网络侧需要重新组织或合并无线资源来满足业务要求，所需时间相对会长一些。?PS域业务接入时延，是指在进行数据业务时从开始连接到能正常进行数据业务所需总时间。本地应用的操作时延，是指完成某些本地操作维护功能所需的时间，例如打开电话薄，在电话薄里查找联系人，存储新建

31、的联系人，存储短信，存储多媒体文件，打开浏览器，播放多媒体文件等所需时延，这些时延如果过长，也会极大地降低用户体验的满意度。手机性能测试技巧手机性能测试技巧 2 次数相关次数相关? 次数相关的性能测试是测试终端重复稳定地进行某项功能的能力。?包括开关机成功率、小区初搜成功率、小区重选成功率、CS域业务成功率、PS域业务成功率、组合业务成功率、切换成功率、本地应用的成功率等。这种重复操作包括很多对象被多次创建和释放，因此可能会发现潜在的内存泄漏等问题。?开关机成功率测试，主要是检验多次开机是否会有物理层不能正确收到初搜命令的情况，关机不完全也可能会导致下一次开机失败，以及在某些情况下系统死机后只

32、能通过插拔电池板来重新开机。?CS域业务成功率的测试，是指通过进行一定次数的主叫或者被叫，统计失败的次数，对失败原因进行归类，分析是否能够找到和终端相关的失败原因。PS域业务成功率、组合业务成功率、切换成功率的测试方法也类似。?本地应用的成功率包括多次存储再删除文件、联系人、短信等操作，以及多次打开某个应用或执行某类操作来对该应用的稳定性进行测试，找出瓶颈。3 并发业务并发业务?并发测试主要是测试终端同时进行多项业务时表现出的处理能力。?例如同时进行CS域语音业务和PS域下载业务，或者在MP3播放的同时进行WWW上网业务，以测试协议栈、操作系统和处理器对并发业务的支持能力。 4 负载测试负载测

33、试?负载测试主要是验证系统的负载工作能力。?系统配置不变的条件下，在一定时间内，终端在高负载情况下的性能行为表现。?例如同时进行多个ftp下载，使下行传输率接近极限值，观察终端是否可以正常工作。需求及文档评审技巧需求及文档评审技巧(1)IEEE认为好的需求规格说明应该达到以下标准：正确：每项需求都反映了一种需要。完整：包含了所有必要的需求。无歧义：各方在需求的含义上意见一致。一致：所有部分都相符，如E/R模型与事件清单相符。确定重要性、稳定性的等级：每项需求的优先级以及预期的修改。可更改：易于修改且保持一致性。可验证：能够检查是否满足了需求。可追踪：由需求至目标/目的，至设计/代码。其它：可由

34、目标追踪至需求；能为客户、开发人员所理解。需求及文档评审技巧需求及文档评审技巧(2)1、兼容性 界面需求是否使软硬件系统具有兼容性？2、完备性 需求定义是否包含了有关文件（指质量手册、质量计划以及其他有关文件）中所规定的需求定义所应该包含的所有内容？ 需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有需求？ 功能性需求是否覆盖了所有非正常情况的处理？ 是否已对各种操作模式（如正常、非正常、有干扰等）下的环境条件都作规定？ 是否识别出了所有与时间因素有关的功能？它们的时间准则是否都明了？时间准则的最大、最小执行时间是否都定义了？ 是否识别定义了在将来可能会变化的需求？ 是否定义了系统

35、的所有输入？ 是否标识清楚了系统输入的来源？ 是否识别了系统的输出？ 是否说明了系统输入、输出的类型？ 是否说明了系统输入、输出的值域、单位、格式等？ 是否说明了如何进行系统输入的合法性检查？ 是否定义了系统输入、输出的精度？ 在不同负载情况下，系统的生产率如何？ 在不同的情况下，系统的响应时间如何？ 系统对软件、硬件或电源故障必须作什么样的反应？ 是否充分定义了关于人机界面的需求？需求及文档评审技巧需求及文档评审技巧(2)3、一致性 各个需求之间是否一致？是否有冲突和矛盾？ 所规定的模型、算法和数值方法是否相容？ 是否使用了标准术语和定义形式？ 需求是否与其软硬件操作环境相容？ 是否说明了软

36、件对其系统和环境的影响？ 是否说明了环境对软件的影响？4、正确性 需求定义是否满足标准的要求？ 算法和规则是否有科技文献或其它文献作为基础？ 有哪些证据说明用户提供的规则或规定是正确的？ 是否定义了对在错误、危险分析中所识别出的各种故障模式和错误类型所需的反应？ 是否参照了有关标准？ 是否对每个需求都给出了理由？理由是否充分？ 对设计和实现的限制是否都有论证？5、可行性 需求定义是否使软件的设计、实现、操作和维护都可行？ 所规定的模式、数值方法和算法是否对待解问题合适？是否能够在相应的限制条件下实现？ 是否能够达到关于质量的要求？需求及文档评审技巧需求及文档评审技巧(3)6、易修改性 对需求定

37、义的描述是否易于修改？例如是否采用良好的结构和交叉引用表等等？ 是否有冗余的信息？是否一个需求被定义多次？7、健壮性 是否有容错的需求？8、易追溯性 是否可以从上一阶段的文档查找到需求定义中的相应内容？需求定义是否明确地表明前阶段中提出的有关需求的设计限制都已被覆盖？ 例如，使用覆盖矩阵或交叉引用表？ 需求定义是否便于向后继开发阶段查找信息？9、易理解性 是否每一个需求都只有一种解释？ 功能性需求是不是以模块方式描述的，是否明确地标识出其功能？ 是否使用了形式化或半形式化的语言？ 语言是否有歧义性？ 需求定义是否只包含了必要的实现细节而不包含不必要的实现细节？是否过分细致了？ 需求定义是否足够

38、清楚和明确使其已能够作为开发设计规约和功能性测试数据基础？ 需求定义的描述是否将对程序的需求和所提供的其它信息分离开来?10、易测试性和可验证性 需求是否可以验证？ 是否对每一个需求都指定了验证过程？ 数学函数的定义是否使用了精确定义的语法和语法符号？本地化测试技巧本地化测试技巧(1)本地化软件的错误类别，可以归结为四种类型：翻译错误，功能错误，界面错误，双字节错误 翻译错误：产生原因： ?1) 翻译人员不熟悉翻译要求。 ?2) 翻译人员工作疏漏。 ?3) 用户界面的翻译与标准词汇表不一致。表现特征：?1) 应该翻译而没有翻译的英文字符。?2) 不应该翻译而翻译的中文字词。 ?3) 错误翻译的

39、字词。 ?4) 只在本地化版本中存在该类型错误。 ?5) 较多隐含在对话框各控件以及帮助文档中。 测试要求： ?1) 明确需要翻译和不需要翻译的内容。 ?2) 明确正确的翻译方式。 ?3) 根据术语表，确认术语翻译的正确性与一致性。 测试方法：?1) 主要同时打开中英文版本，执行相同的操作。?2) 结合标准界面词汇翻译表，参照对比。说明： ?1) 对于对话框，如果含有下拉列表框，要打开列表框查看全部项。 ?2) 特别要注意选项中开关类翻译错误。本地化测试技巧本地化测试技巧(2)功能错误：功能错误：产生原因： 1) 软件编码错误。 2) 错误本地化，如将程序中的变量进行了翻译等。 表现特征： 1

40、) 不能实现设计要求的功能 2) 产生与设计要求不符合的结果。 3) 英文和中文都存在同样的错误。 4) 可能隐含在软件的任何位置或任何操作步骤中。 测试要求： 1) 保证输入数据正确，或者打开了正确的测试用例。 2) 明确正确的输出结果和中间数据数值及格式。 测试方法： 1) 对于菜单项或工具栏按钮，通过全面测试各个选项，认真观察每一步是否正确执行，输出结果（包括格式和数值）是否正确。 2) 对于一个命令中的多个并列选项，采用路径跟踪法，按分支顺序测试嵌套的全部子项。 3) 对于对话框，可以逐个执行各按钮，各个列表选项等观察执行结果。 说明： 1) 特别注意不同选项、不同按钮相互操作的影响。

41、 2) 注意检查快捷键是否遗漏，是否多余，是否不同，是否起作用。本地化测试技巧本地化测试技巧(3)布局错误：布局错误：产生原因： 1) 软件本地化后，由于源语言和本地化语言的表达方式不同，本地化后的字符数与源语言不同，每个字符所占空间尺寸不同，使得在英文版本正确显示的控件字符，可能在本地化版本显示不正确。 2) 本地化人员调整程序资源不当引起，例如，对话框及其控件高度或宽度的不正确调整。 表现特征： 1) 控件相互重叠或排列不均匀。 2) 控件中字符显示不完整。 3) 主要出现在本地化版本的对话框中。 测试要求： 1) 对话框中控件布局均匀，字符显示完整正确 2) 对话框中控件数量相等，没有多

42、余或丢失的控件 测试方法： 1) 执行将要打开对话框的菜单或工具栏按钮，观察打开对话框中的控件布局。 2) 对比检查源语言软件和本地化软件对应的对话框中控件的数量 说明： 1) 可能在执行不同的操作后，如选择了不同菜单或选按钮后，编辑框显示重叠等。 2) 执行后带省略号的菜单或命令按钮，将会显示对话框。 本地化测试技巧本地化测试技巧(4)双字节错误双字节错误：产生原因： 1) 源程序在设计时没有考虑双字节语言的支持。 2) 软件本地化后，单字节字符向双字节字符转化过程中，由于单字节和双字节之间的差别，可能使得某些本地化后的双字节字符的显示乱码。 3) 软件本地化后，对程序中控制符号如换行键“n

43、”的处理错误而引起乱码。 表现特征： 1) 控件或对话框中显示不可辩识的字符。 2) 控件或对话框中显示无意义的明显错误的字符。 3) 不支持双字节字符的输入，包括双字节的文件名和路径名。 4) 仅出现在本地化后的版本中。测试要求： 1) 本地化后的软件字符显示正确完整，无乱码或明显错别字。 测试方法： 1) 执行菜单或按钮，检查对话框中的字符。 2) 打开帮助文档，检查所有需要翻译的字符。 说明： 1) 注意检查对话框下拉列表中需要拖动滚动条才能显示的内容。 手机场地测试基本技巧手机场地测试基本技巧1. Field Test（又称路测、场测）主要是为了了解手机在现网环境下的真正使用情况而展开

44、一项测试，侧重于网络相关功能，可以说也是一种模拟最终用户使用的测试。2. 场测任务展开的时间，主要是放在系统测试阶段后期。在场测的前提条件满足后（RF测试和无线灵敏度测试通过后，项目部可以向测试部经理提交场测试申请，在获得通过后，安排场测试。 3. 对于新平台，正常情况下必须要安排场地测试，场测试结果将作为出场判定依据。4. 目前，场测分两部分：PART A 与 PART B 这两部分分别有所侧重，A部分偏重无线与通讯方面的综合测试。B部分，偏重与实网环境中各项网络功能的测试。5. 产品上市后，如果平台有通信相关的重大升级，测试负责人，必须安排重新安排场测。小概率问题处理小概率问题处理尽量发现

45、出现小概率问题的前提条件合理使用辅助测试工具,包括Trace, QXDM等尽量给出概率问题的概率讨论讨论手机测试例编写原则手机测试例编写原则熟悉需求,设计,了解业务测试例命名规则清晰,明了.模块划分,测试例编写具有较强的通用性测试例有明确的测试目的,测试前提条件，优先级别,预期结果测试例编写的详细程度应该有限详细.? 有限详细的定义：测试例的主要读者是测试人员，而不是所有人在测试中尽量避免使用操作某个按键出来什么结果的如果确实需要，尽量强调其测试的目的比如说，检查对话框状态下，左右软键的显示是否正常(居中显示/字符串无切字/无拼写错误）? 好的测试例的其他几点要求能够尽量的覆盖典型的，常用的，

46、异常的场景尽量避免重复测试测试例并非越多越好，测试例的数量应该是，尽可能的发现问题与尽可能的覆盖功能的最小公倍数? 测试例的编写与测试本身一样，没有最好，只有更好，是一个可以不断完善的过程。手机测试例编写要求手机测试例编写要求1. 准确: 按所设计的去测试.对需求及设计理解准确,理解软件及功能特点,积极设想软件如何才能失败,做到尽可能发现错误2.不冗余: 好的测试例子没有不必要的步骤,每一个测试都应该有不同的用途, 不会太简单，也不会太复杂。通常每个测试例应独立执行。多个测试例组合，有可能屏蔽错误。最大操作步骤最好控制在10-15步之间,每个测试步骤应该有一个清晰的输入或者测试任务,不排除单个

47、测试例子有多个逻辑输入,需要逐一列举输出结果.3.清晰: 描述清晰,步骤条理清晰,测试层次清晰(由简而繁,从基本功能测试到破坏性测试).4.可复用: 无论何时何人测试都能得到同样的结论,方便移植.5.可追溯性: 针对特定的需求测试.6.适 当: 测试例应该适合特定的测试环境 以及符合整个团队的测试水平7.可维护性: 好的测试用例应该是可维护的,维护包括添加,删除,更改,特别是对应需求及功能等变更的维护.象代码一样,不需要维护的测试例是不存在的,在变更过程中未做维护的测试例将失去它应有价值,甚至带来危害.备注: 以上内容来自毛宏才怎样编写高质量测试用例设计测试用例应注意的事项设计测试用例应注意的

48、事项 不仅要选用合理的输入数据作为测试用例（即肯定测试用例），还应选用不合理的输入数据作为测试用例（即否定测试用例）。许多人往往只注意前者而忽略了后者。为了提高系统的健壮性，输入数据不合理的各种情况是应该认真检查的（在开发过程中，正常业务处理的代码量只占有效代码量的 10% ，而例外处理的代码量要占有效代码量的 90% ），所以测试工作量也是如此，即肯定测试用例占总用例的 10% ，否定测试用例占总用例的 90% ）。除了检查系统是否做了它应该做的工作之外，还应检查系统是否做了它不应该做的事情。应该长期保留所有的测试用例，直至这个系统被废弃不用为止。这是因为：设计测试用例是很费人工的，如果将用

49、过的测试用例丢弃了，以后一旦需要再测试这个系统（例如因为系统内部作了某些修改）就需要再花很多人工，人们往往懒得再次认真地设计测试用例，因而“再测试”很少像初次测试那样“彻底”。如果系统的修改使得前面已测试过的部分产生了错误，“再测试”往往就不能发现这些错误。设计测试用例方法设计测试用例方法 白盒法白盒法 白盒法是以系统内部的逻辑为基础设计测试用例，所以又称为逻辑覆盖法。白盒法考虑的是测试用例对系统内部的覆盖程度，最彻底的白盒法是覆盖系统中的每条路径，但是由于系统中一般含有循环，所以路径的数目极大，要执行每条路径是不可能的，所以只能希望覆盖的程度尽可能高些。我们可以从以下几点考虑：（ 1 ）语句

50、覆盖 “语句覆盖”是一个很弱的测试覆盖，它的含义是：选择足够的测试用例，使代码中每个有效语句（即注释语句除外）至少都能被执行一次。顺序语句覆盖率是 100% 。（ 2 ）分支覆盖 比“语句覆盖”稍强的测试覆盖是“分支覆盖”。这个标准是执行足够的测试用例，使代码中每个分支至少都获得一次“真”值和“假”值，或者说使得代码中的每个分支至少都通过一次。分支覆盖率是 80% 。（ 3 ）循环覆盖 “循环覆盖”的含义是：执行足够的测试用例，使得循环中的每个条件都得到验证。循环语句覆盖率是 80% 。设计测试用例方法设计测试用例方法 黑盒法黑盒法 设计测试用例的另一种方法是黑盒法。与白盒法不同，黑盒法不关心

51、系统内部的逻辑，而只是根据系统的功能说明、预期结果、数据流程或业务流程等来设计测试用例。黑盒法测试的依据是需求说明书或功能说明书。我们常常采用的方法是A 、划分等价类 B 、 边界值分析法 C 、因果图法 D 、错误推测法 划分等价类划分等价类等价列划分设计方法是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少量具有代表性的数据作为测试用例。等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并合理地假定：测试某等价类的代表值就等于对这一类其他值的测试。等价类划分有两种不同的情况：有效等价类和无效等价类。设计时要同时考虑这

52、两种等价类。下面给出6条确定等价类的原则：在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，则可以确立一个有效等价类和一个无效等价类。 在输入条件是一个布尔量的情况下，可以确立一个有效等价类和一个无效等价类。 在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可以确立n个有效等价类和一个无效等价类。 在规定了输入数据必须遵守的规则的情况下，可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。 在确知已划分的等价类中各元素在程序处理中的方式

53、不同的情况下，则应再将该等价类进一步的划分为更小的等价类。 在确立了等价类后，可建立等价类表，列出所有划分出的等价类。然后从划分出的等价类中按以下的3个原则设计测试用例：为每一个等价类规定一个唯一的编号 设计一个新的测试用例，使其尽可能多的覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止。 设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。 例：程序规定；输入三个整数作为三边的边长构成三角形。当此三角形为一般三角形、等腰三角形、等边三角形时，分别作计算。用等价类划分方法为该程序进行测试用例设计。解：设a、b、c代表

54、三角形的三条边。1）分析题目中给出的和隐含的对输入条件的要求：a) 整数b) 3个数c) 非零数d) 正数e) 两边之和大于第三边f) 等腰g) 等边 2）列出等价类表并编号3）列出覆盖上述等价类的测试用例，如下表： B 、 边界值分析法边界值分析法使用边界值分析方法设计测试用例的步骤，首先：应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。其次，应但选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。基于边界值分析方法选择测试用例的原则：如果输入条件规定了值的范围，应取刚达到这个范围的边界值，以及刚刚超过这个范围边界的值作

55、为测试输入的数据。 如果输入条件规定了值的个数，应用最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试输入的数据。 根据规格说明的每个输出条件，使用前面的原则1。 根据规格说明的每个输出条件，使用前面的原则2。 如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例数据。 如果程序中使用了一个内部数据结构，应当选择这个内部数据结构边界上的值作为测试用例。 分析规格说明，找出其他可能的边界条件。 D 、错误推测法 人们也可以通过经验或直觉推测系统中可能存在的各种错误，从而有真对性地编写检查这些错误的例子，这就是错误推测法。错误推测法没有确

56、定的步骤，很大程度上是凭经验进行的。 手机测试例优先级别的定义手机测试例优先级别的定义(1)测试用例的优先级别测试用例的优先级别首先，你必须确定什么是你优先级别的类型和其暗示着什么。就我们的目的来说， 我们将用一个假设开始，那就是我们可能发现的缺陷的严重程度和那些相应测试用例的优先级别之间是平行的。 1 小版本确认测试（Build Verification Tests (BVTs)：也叫做“冒烟测试”，一组你想先运行的以确定这个给出的小版本是否可以测试的测试用例。如果你不能访问每一个功能区域或执行其他测试用例依赖的基本操作，那么在执行这个优先的测试用例之前，试图做其他任何的测试 都是没有意义的，因为他们大多数肯定要失败。 2 高（Highs）：最常执行以保证功能性是稳定的，目标的行为和能力可以正常的工作，和重要的错误和边界被测试的测试用例的集合 3 中（Mediums）：这是使给出的功能区域或功能变得更详细，检查功能的多数方面包括边界，错误和配置测试的测试用例 4 低（Lows）：这是通