做好测试计划和测试用例的工作的关键是什么？

第一篇：做好测试计划和测试用例的工作的关键是什么？

一、测试计划的有效性和全面性

无论做什么工作，都是计划先行，然后按照所制定的计划去执行、跟踪和控制。软件测试也一样，先要制定测试计划，是做好整个测试工作的前提。所以在进行实际测试之前，应制定良好的、切实可行的、有效的测试计划。软件测试计划的目标是提供一个测试框架，不断收集产品特性信息，对测试的不确定性（测试范围、测试风险等）进行分析，将不确定性的内容慢慢转化为确定性的内容，该过程最终使得我们对测试的范围、用例数量、工作量、资源和时间等进行合理的估算，从而对测试策略、方法、人力、日程等做出决定或安排。

1．测试计划的要点

测试规划与软件开发活动同步进行，在需求分析时，就开始测试策划，确定测试需求、目标、资源等。测试计划可以按不同的测试阶段（集成测试、系统测试等）来组织，也可以为每个测试任务或目标(安全性、性能、可靠性等测试)进行考虑。

测试计划主要集中在测试目标、质量标准、测试策略、测试范围、测试用例设计方法、所需资源和日程安排等，其关键是制定有效的测试策略，界定清楚地测试范围，识别出测试中所存在的各种风险并找出风险回避、监控和管理的方法，针对不同的测试目标或阶段确定测试方法，对测试工作量及所需的资源、时间进行合理的估算。所有这些，都是为了两个根本目的：测试的质量和效率。

2．制定测试策略

制定测试策略主要分析测试的目标和质量指标、确定测试的对象和依据，测试的重点和所采用的方法，包括在规定的时间内哪些测试内容要完成，软件产品的特性或质量在哪些方面得到确认。测试策略可以分为：

基于测试技术的测试策略，根据软件系统的技术构成和层次结构，着重考虑如何分层测试、选择哪些测试工具、如何将白盒测试和黑盒测试有机地结合起来等。

基于测试方案的综合测试策略，根据测试的目标和范围，着重考虑如何更好地满足测试需求、如何让功能测试、适用性测试和兼容性测试等进行有机结合、如何充分利用测试资源、如何更有效地完成回归测试等。

为了更好地制定好测试策略，要做到：

全面细致地了解产品的项目信息：应用领域、测试范围、市场需求、产品特点、主要功能和技术架构；

基于模块、功能、系统、版本、性能、配置和安装等各个因素对产品质量的影响，客观地、全面地展开测试计划；

根据软件单元在系统结构的重要性差异和一旦发生故障将给客户造成的损失大小，来确定软件测试的等级、重点和先后次序；

需要在测试用例数和测试覆盖率上进行权衡而获得一个平衡点，以便能使用尽可能少的有效测试用例去发现尽可能多的程序错误。测试不足意味着让用户承担隐藏错误带来的危险；同时反过来看，过度测试则又会浪费许多宝贵的资源或耽误软件产品的发布时间。

3．确定测试范围

测试主要依据 “产品设计规格说明书”、代码所发生的变化及其影响的区域，来确定哪些功能和特性要测试，哪些功能和特性不需要测试。在确定测试范围时，主要考虑的因素有：

优先级最高的需求功能

新增加的功能和编码改动较大的已有功能

容易出现问题的部分功能

过去测试不够充分的地方

经常被用户使用的功能和配置（占20%）

4．所需资源和日程安排

为了合理、准确地安排日程，对测试工作量要进行正确的估计。除了对工作量的估计之外，还要正确评估参与该项目人员的培训时间、适应过程和工作能力等。由于涉及到不同的项目、不同的测试人员、不同的前期介入方式，要对每人每天能够完成的平均测试用例数目做出一个准确的估计确实很困难，但是可以根据以前一些项目测试的经验或历史积累下来的数据进行判断推理，并适当增加10%-20%的余量，估算结果就比较准确了。

在估算的基础上，进行有效的、合理的资源安排。在不同的测试阶段人力资源的需求是不一样的，所以人力资源的计划要有一定的灵活性和动态性，形成有机的动态平衡，保证测试的进度和资源的使用的效率。

5．编制测试计划的技巧

要做好测试计划，测试设计人员要仔细阅读有关资料，包括用户需求规格说明书、设计文档等，全面熟悉系统，并建议注意以下方面：

让所有合适的相关人员参与测试项目的计划制定，特别是在测试计划早期；

测试所需的时间、人力及其它资源的预估，尽量做到客观、准确、留有余地；

测试项目的输入、输出和质量标准，应与各方达成一致；

建立变化处理的流程规则，识别出在整个测试阶段中哪些是内在的、不可避免的变化因素，加以控制。

6．测试项目计划的评审

测试项目的计划不可能一气呵成，而是要经过计划初期、起草、讨论、审查等不同阶段，才能将测试计划制定好。测试计划的评审是完成测试计划关键的一个环节，包括测试组织内部的自我评审、讨论和修改，然后交到评审会进行正式的评审，直至测试计划得到审批。

测试计划的正式评审，项目中的每个人（产品经理、项目经理、开发工程师等）都应当参与。计划的审查是必不可少的，每一个参与者都可能根据其经验及专长提出问题或建议，弥补在测试范围、工作量、风险等各方面的不足，进一步完善测试计划。

二、测试用例在测试活动中的作用：

1.强化测试用例在测试活动中的作用

测试用例在实际中没有起多大作用 , 在实际测试时根本没有按测试用例执行，测试执行后没有把新的测试用例补充到用例库中等等。

为何如此？ 根本原因是对测试用例重要性的认识不够，测试流程不完善，针对测试用例的管理流程更不完善，其实，从三个方面具体来说：

1）测试用例的重要性是毋庸置疑的，它是软件测试全部过程的核心，是测试执行环节的基本依据，如果这个依据不能足够发挥它应起的作用，那是不是说这个依据不明确、依据设计的不合理呢？答案是肯定的！

2）制定了完备有效的测试用例，为什么不按测试用例执行测试呢？首先是因为企业没有严格和良好的机制促使和保证测试执行者这样做；其次是个别测试人员投机取巧心理作祟的表现。

3）测试用例设计得不可能天衣无缝，不可能完全满足软件需求的覆盖要求，测试执行过程里肯定会发现有些 测试路径或数据在用例里没有体现，那么事后该将其补充到用例库里，以方便他人和后续版本的测试；如果没有这样做，那么测试部门负责人和每个测试员都难辞其疚，是该重新坐下来思考一下公司的测试用例管理规范和测试流程了。

2.改进测试用例执行过程

那么究竟如何做，才能尽量避免上述问题呢？

我们不妨从软件开发周期的每个阶段就把这些问题考虑进去，以便从初始就力争将问题缩到最小，将问题扼杀在萌芽阶段。

1）软件需求分析阶段，测试人员从软件生命周期的需求阶段就开始介入。通常测试人员的测试工作开展在开发周期的末尾，如果前期不涉入，如何通晓整个系统的需求和架构而对其充分测试呢？

项目的测试负责人和测试工程师在 需求阶段 的任务有：

a.参与软件需求调研，以测试角度分析需求的可测性，可构思将来对其测试的方法、原则等；更重要的是，对不可测或难以测试性问题要及时与客户或项目经理协调解决。

b.全面了解系统需求，从客户角度考虑软件测试需要达到的验证状态，即何些功能点需重点测试、何些无需，以便将来制定测试计划。

2）软件分析设计阶段：

l 测试人员除制定测试计划书等基本工作外，还有一个相当必要的任务，那就是将系统的可测性落实到书面文档，以备将来编写测试用例。（之所以要这么做，是因为考虑到很多企业编写测试用例直接参考需求规格说明书或者分析流程图，这样跨度大，难度也大，是造成测试用例不完备、覆盖范围小的重要原因）。

l 测试人员更要编写一份《软件功能点测试描述书》，它是软件的详细测试分析文档，其主旨是将系统分析人员的开发分析文档加工成以测试为角度的功能点分析文档，重要的是描述对系统分解后每个功能点逐一的校验描述，包括何种方法测试、何种数据测试、期望测试结果等，这些信息都是描述性的，无须具体数据；它的作用是据此编写测试用例，以及测试执行时的参考依据，基于它直接来源于需求，覆盖当然最全，也最能贴近客户要求。

l 当然该文档不是非要不可，如果有类似的替代文档或有工具可自动实现此功能，则会倍加受推崇！

3）软件开发阶段： 编写测试用例。应该遵守的原则是：

n 首先，从覆盖率来说，测试用例库的用例要达到最大覆盖软件系统的功能点。编写测试用例时，基本上就是将《软件功能点测试描述书》中的每个功能点进行操作上的细化：一是从步骤上描述到达校验点的方式，二是从内容上描述以何种数据校验功能点；如此可实现趋向最大需求覆盖率。

n 其次，从数量来讲，一个多于半年开发周期（指从编码开始直到提交客户的时间段）的软件系统，它的用例数量不要低于 4000 个，甚至更多！（IBM 等大公司测试过程的人士会认为 4000 还是很少的数目。我们试想，对于一个中小型软件系统，如果设计出 5000 个用例，那它的测试覆盖率还怕不高么）！

n 再次，如此众多测试用例的管理问题。是的，最好是需要测试用例管理工具软件。以 word 或 excel 来编写测试用例也可以。）测试用例 格式上一般内容以外的几个要点：

l 制定适合本公司的测试用例模版；

l 是用例模版里要有关键字索引，以方便按关键字分类查找，如测试方法（分手工 / 自动两种）；

l 是测试用例要有 状态跟踪，可根据用例执行状态索引用例（测试通过、测试失败、测试中断等）；

l 是执行失败的用例要 链接到相应的缺陷报告，如有根据缺陷报告检索测试用例的试图更妙，可评估该缺陷影响范围的大小；

l [FS:PAGE] 是测试用例的修改，以及每个测试周期的运行都有 日志记录，以便后期追踪

和新员工参考；）软件测试阶段，测试负责人划分不同的测试阶段（如集成测试、系统测试、回归测试、性能测试等），再划分不同的子测试周期（如前两个星期做 冒烟测试，测试方式是手工 / 自动，测试版本是 **，测试环境是 **，包括服务器端与客户端等；接着做第一模块功能测试；如此顺次。），再为项目组测试人员分配测试用例（通常原则是每个人负责几块区域的测试任务），测试人员则按照详细的用例文档去执行测试，测试失败则提交软件缺陷报告。这里要遵循的几个原则是：

A）有健全且严格的体制保证测试执行者严格按照测试用例执行测试。这并不妨碍测试者创造力的发挥，因为前期用例的设计和编写就是项目全体测试人员智慧的结晶！我们一直苦苦追寻众多测试工程师加班加点辛苦工作的原因，其实大都发生这一阶段；如此实施，即便没有解决根本问题，也会大大提高测试执行效率。

B）如有对测试用例认识模糊或内容遗漏的地方，可暂做记录待后期解决，或经测试负责人与项目其他管理人员同意方可更新用例库。

C）测试负责人每日负责跟踪本测试子周期或阶段的测试用例执行情况，以及每日提交的缺陷报告，根据执行进展状态以及缺陷数量或严重等级与项目高层或其他人员展开交流，商议解决途径，并确定或调整未来时间的测试任务。

D）测试执行者负责执行自己区域的测试用例，还要负责跟踪该区域软件缺陷的修改进展，根据其状态 不断验证软件功 能点。

E）通过缺陷管理工具来 管理软件缺陷 ；这样的集成工具都提供了清晰的报告模版及强大的追踪功能，测试团队的每一成员按照自己的角色和权限访问缺陷管理工具，并不断跟踪软件缺陷的状态。

F）对于自动测试（包括自动化功能测试和性能、压力测试），有一些特殊要点。是自动化测试无须编写测试用例，只要在编写时将用例库里适合或需要自动测试的用例的测试方法（不同工具可能名称不同）设为自动即可，故而到此阶段才提及自动化测试。自动化测试的实施方案有所不同，每款测试工具的使用和测试流程也不同，但都可以从在这一阶段编写测试脚本，并运行自动测试。这里要提的其他几个基本原则是：

l 是选择恰当的测试工具品牌，并要求提供培训；

l 是项目的自动化测试工作有专人负责跟踪，以保证工作质量，他们可不参与日常测试；l 是确定自动化测试成员在项目中的角色，一般自动化测试成员隶属于项目测试负责人，负责人同样跟踪其工作状态；

l 是选择最简单、最重用的测试用例使用自动测试方法；

l 是使用工具厂商提供的测试框架编写脚本，千万别采用单纯录制回放的方式，要开发出健壮且重用性强的测试脚本 ；

l 是有专人更新脚本，也有专人跟踪自动测试结果；

l 一般选择的测试工具品牌和缺陷管理工具品牌是同一厂商，以方便不同类型缺陷的集中管理；

l 是在多人协作开发测试脚本、代码量相对较大情况下，应考虑使用配置管理工具来管理测试脚本。）由于不同公司开发产品的特殊性，也许需要特殊类型的测试，如安全测试、甚至代码级单元测试等，这些内容需要酌情考虑测试用例的编写，以及测试的执行。）软件验收阶段 ：除了提交软件测试评估报告（各种类型测试结果的评估都应有报告）这些基本工作外，对于测试用例，此时要集中时间更新，更新整个测试周期中一切需要更新的内容，以方便未来新版本的测试。即便您开发的是项目软件--提交客户后没有新版本--那也需要后期维护，维护阶段需要重新测试某功能点，然而用例如果不准确，碰巧又是一个

新员工来做，那就死翘翘了！）其他说明：加强测试部门内部人员的培训教育很重要，包括工作技能与个人素质两方面，可通过国内主要的培训机构，也可是购买工具厂商的直接培训。应该说，很多测试新人对于测试用例的书写还存在问题，更别提及测试用例的管理或执行；以此可见，我们的测试工程师需要培训的空间还很大。

3.总结

综上所述，我们得出结论--测试用例在测试中没起到应有的作用，是因为测试用例编写质量不高，覆盖不够，执行不利；测试执行时不遵循测试用例，执行后不更新用例库，是测试部门的整体工作流程不健全、不规范。

第二篇：做好测试计划和测试用例工作的关键

做好测试计划和测试用例的工作的关键

做好测试计划和测试用例的工作的关键（转）

对于目前大部分公司存在的状况，很多测试计划文档只是一种形式而已

所以我的理解是：怎样让测试计划对整个测试工作真正具有指导作用

这里把测试计划和测试方案分开来讲（计划对应于管理层面的问题，方案对应于技术方面的问题）

测试计划中最重要的内容包括： 进度安排；人力、物力资源分配（包括组织结构等）、风险假设和规避措施。（其他像软件版本号之类的，只要是个人都会写，这里不列了）写好测试计划的关键在于：充分了解你的团队的整体实力和团队中每个成员的特点充分理解为当前软件制订的整个研发活动过程

带过项目的人都知道：在实际项目中，往往进度才是第一位的，但是对进度的把握和估算却是极其困难的。只有做到这两点才有可能对进度有比较准确的把握，对人员有一个合理的分配。否则所谓的进度，所谓的资源分配，都是拍脑袋得出的结果，风险假设更是无从谈起，这样的测试计划文档只能流于形式也就不足为奇了。

写好测试方案的关键在于：有一个合理的测试计划熟悉相关业务深入体会用户的实际需求

这个不想多解释了，不难理解。

至于测试用例，看到上面不少朋友认为关键在于理解用户需求。

其实理解用户实际需求是一切的根本，并且对于有些测试（比如像单元测试）对应的测试用例通常和用户需求之间的关系可能并不直接或是十分密切。

当然，如果有一份好的需求和设计文档的话，什么事情都解决了。可是现实往往是不存在这样的文档的。

所以我的看法是：对业务理解的深入程度经验有自己的文档

前两条不解释了。自己的文档包括两方面：一个是常用的特殊测试数据，比如一些特殊字符，极限长度的输入等等。这个在项目时间紧迫的时候是非常有帮助的（有的时候甚至可以当成check list）。另一个就是自己测试模块对应的相关需求和设计文档。服务器上的标准文档拖到本地来并且记得及时更新。然后在测试过程中，需要什么内容文档上没有，最直接的方法是和开发人员沟通。（其实我很反对这么做。你想，按开发人员自己说的标准

去测他们自己开发的模块能测出因为需求或者设计错误导致的问题么„„应该是和客户和designer去沟通，可惜一般没有这条件-_-）任何标准文档上缺少的内容，只要是和你有关的，一定要记得做记录。当然你有时间有精力把整个系统的需求和设计文档都捣鼓出来最好，不过通常是没这可能性的。

补充说明：lz最后提到的“完全凭借自己的经验在执行测试活动”不如说是完全凭借自己的感觉在执行测试活动。

项目需要的用例详尽程度可以商量，但是必须要有。如果进度很紧，可以用一部分用例加上check list进行测试活动（比如很多日本外包项目的UI测试，相当一部分可以用check list来代替具体的用例，效果并不差)

完整的大纲应该是：

目录

测试计划标识符

目录表

参考文献

词汇表

介绍

测试项

软件风险问题

待测特征

不予测试的特征

方法

测试项通过/失败准则

挂起准则和恢复需求

测试交付物

测试任务

环境需求

职责

人员安排与培训需求

进度表

计划风险与应急措施

审批

第三篇：编写测试用例和测试计划

第六章 编写测试用例和测试计划

主要内容：软件测试计划；软件测试方案；软件风险分析

1.软件测试计划

1.1 软件测试计划的简介

1测试计划概念：测试计划在测试中处于中心位置，它阐述了测试准备工作和执行测试的必要条件，同时也形成了测试过程质量保证的基础。

2测试计划的作用：组织和管理测试；使测试工作和整个开发工作整合起来；资源和变更事先最为一个可控制的风险。

1.2 如何编写软件测试计划

1认识测试项目不仅仅只有单一测试计划

2避免不分析直接进行测试阶段日程安排

3避免测试任务的安排超前于开发任务

4避免有些系统测试类型无法按期进入测试

5不正确的变更测试计划

6测试计划里明确更新周期和暂停测试原则

7测试计划不是一成不变的1.3 测试计划包括：简介，目的，范围，测试策略，进度，缺陷的严重程度的定义，风

险分析。

2.软件测试方案

2.1 软件测试方案的概念

软件测试方案描述测试的特征，测试的方法，测试环境的规划，测试工具的设计和选择，测试用例的设计方法，测试代码的设计方案。即包括以下几点：

 明确测试策略（黑盒，白盒，灰盒等）

 细化测试特征

 测试用例的规划

 测试环境的规划

 自动化测试框架的设计

 测试工具的设计和选择

2.2 软件测试计划于软件测试方案的区别

 测试计划是组织管理层面的文档。测试方案是技术层面的文档。

 测试方案需要在测试计划的指导下进行，测试计划提出“做什么”，测试方案明确“怎么做”

 回报的对象不同，测试计划向领导汇报，测试方案是组员共享该文档

3.软件测试的风险

 软件需求风险

 人员的风险

 测试环境的风险

 测试工程师对产品的业务不熟悉

补充：

回归测试：把以前检查过的已经修复好的缺陷，拿来另测看有无带来新的缺陷 反侧：把开发人员已经处理的缺陷拿来测，看是否修复

第四篇：工作时长测试用例5.4

1.目的测量手机各状态纯工作时长是否符合设计规范和用户正常使用。

2.适用范围

适合移动产品试产及相关变更的验证。

3.内容

3.1 手机待机时长（测试用例编号:5.4.1）

3.1.1 测试条件和说明

1）被测机1台装SIM卡、TF卡，测试前手机需至少上电2小时保证后备电池充

满电（以保证关机漏电流不是测了后备电池充电电流），测试过程中手机背光等级/时长、键盘锁与音量级等均为默认；

2）测试用移动卡2张、测试用电脑1台、程控电源1台（3.8V）、假电池1个、SkyworksLabteststudio电流分析软件（设置：Sample interval：

1996.8uS,Sample points：501, Sample length：3600S），如没特别说明，电流值均由电流分析软件读取；

3）手机开关机时长规定：开机时长15小时(早上7:30~晚上22:30)，关机时

长9小时(晚上22:30~早上7:30)；

4）用户使用时长参考营销部调查结果，在计算手机待机时长时引用。

3.1.2 测试步骤

1）关机漏电流：

手机关机状态时的电流，在程控电源上直接电流值，关机时长为9H（上面3.1.1第3)点规定）。

2）待机省电平均搜网电流：

手机开机待机省电/后台挂Q（不收到消息)，正常环境里的30秒平均搜

网电流；

用户使用时长＝15*3600-T1-„T17=54000-6410=47590秒（备注：

T1...T17为以下第3到第17项各项用户使用时长）。

3）关机响闹铃电流：

手机关机期间响闹铃(闹钟响0db_1Khz.mp3、响铃方式：响铃+振动）30

秒手动停止选择开机后进入省电过程中的平均电流；

用户使用时长＝30秒。

4）开机响闹铃电流：

手机待机省电期间响闹铃(闹钟响0db_1Khz.mp3、响铃方式：响铃+振动）

30秒后手动停止后进入省电过程中的平均电流；

用户使用时长＝30秒

5）来电响铃电流：

正常环境手机待机省电期间外线来电响铃（响铃0db_1Khz.mp3、响铃方

式：响铃+振动）10秒平均电流（每天来电4次）；

用户使用时长＝10*4＝40秒。

6）手柄通话电流：

正常环境手机手柄通话5分钟本方挂断后进入省电过程中的平均电流（每天3个手柄通话）；

用户使用时长＝5*3*60＝900秒。

7）免提通话电流：

正常环境手机免提通话5分钟本方挂断后进入省电过程中的平均电流（每天1个免提通话）；

用户使用时长＝5*60＝300秒。

8）编辑/发送短信息电流：

正常环境手机待机省电期间按键点亮屏幕进入信息编辑，以正常的速度

编辑60个汉字后发送信息，发送成功后返回待机自动进入省电过程中的平均电流（信息编辑至发送成功时长为2分钟，每天发送4条信息）；用户使用时长＝2*4*60＝480秒。

9)接收/查看短信息电流：

正常环境手机待机省电期间收到短信后按键点亮屏幕查看完信息再返回

待机自动进入省电过程中的平均电流（接收到信息至查看完信息时长为30秒钟，每天接收4条信息）；

用户使用时长＝4*30＝120秒。

10)FM自动搜寻电台/聆听广播电流：

正常环境手机待机省电期间按键点亮屏幕进入收音机/插耳机FM自动搜

寻电台/聆听广播10分钟后关闭收音机拔掉耳机返回待机进入省电过程中的平均电流；

用户使用时长＝10*60＝600秒。

11)MP3耳机聆听电流：

正常环境手机待机省电期间按键点亮屏幕/插入耳机快捷进入MP3播放器

/最大音量循环播放＜0db_1kHz.mp3＞音乐20分钟后按键停止播放拔掉耳机返回待机进入省电过程中的平均电流；

用户使用时长＝10*60＝600秒。

12)MP3外放电流：

正常环境手机待机省电期间按键点亮屏幕快捷进入MP3播放器/最大音量

外喇叭循环播放＜0db_1kHz.mp3＞音乐10分钟后按键停止播放返回待机进入省电过程中的平均电流；

用户使用时长＝10*60＝600秒。

13)MP4外放电流：

正常环境手机待机省电期间按键点亮屏幕进入电影播放器/最大音量外

喇叭全屏播放＜妃子笑.mp4＞电影5分钟后按键停止播放返回待机进入省电过程中的平均电流；

用户使用时长＝5*60＝300秒。

14)WAP上网电流：

正常环境手机待机省电期间按键点亮屏幕进入WAP浏览器登陆新浪网/流

浪5个子网页如新闻、财经、体育、军事、房产等5分钟后退出浏览器返回待机进入省电过程中的平均电流；

用户使用时长＝5*60＝300秒。

15）QQ聊天电流：

正常环境手机待机省电期间按键点亮屏幕进入移动QQ聊天（声音/振动开

启）10分钟后退出返回待机进入省电过程中的平均电流；

用户使用时长＝10*60＝600秒。

16）QQ斗地主电流：

正常环境手机待机省电期间按键点亮屏幕登陆QQ斗地主游戏10分钟后退

出返回待机进入省电过程中的平均电流；

用户使用时长＝10*60＝600秒。

17)玩手机游戏电流：

正常环境手机待机省电期间按键点亮屏幕进入游戏,玩俄罗斯方块（声音

/振动开启）10分钟后退出到待机进入省电过程中的平均电流；

用户使用时长＝10*60＝600秒。

18)蓝牙传输文件电流：

正常环境手机待机省电期间按键点亮屏幕进入蓝牙选项，搜索并与另一

台手机配对成功后发送文件给对方，5分钟后停止发送返回待机进入省电过程中的平均电流；

用户使用时长＝5*60＝300秒。

19)关机电流：

正常环境手机待机省电期间按键点亮屏解锁或开盖后手动关机至屏灭过

程中的平均电流；

用户使用时长＝10秒。

20)手机待机时长计算方法：

a>关于用户每天各功能使用时长,引用营销部调查数据：通话20分钟+短信10分钟+游戏20分钟+MP3耳机播放20分钟+外放10分钟+闹钟1个+上

网5分钟+蓝牙5分钟+FM10分钟+来电4次+待机；在此基础上我们合理增加了：MP4外放5分钟+QQ聊天10分钟、1个闹钟及关机时长10秒钟，以

此计算手机待机使用时长；

b>通话20分钟分解为手柄通话3个、免提通话1个（每个通话5分钟）；短信10分钟分解为接收/发送短信息各4条（接收查看1条信息30秒钟，编辑发送1条信息2分钟）；游戏20分钟分解为QQ斗地主和玩俄罗斯方块

各10分钟；闹钟使用时长为30秒钟/个；

c>最后根据公式手机待机时长T=电池容量*24H*3600S/〔I关机漏电流

*Ta+I省电平均搜网电流*Tb+I1*T1+„+I17*T17〕

计算出手机总待机时长T。

说明：

“I关机漏电流*Ta”为手机关机9小时里的单项耗电,Ta=9*3600=23400S；“I省电平均搜网电流*Tb”为手机开机15小时里除去其他功能耗电总和的省电平均搜网单项耗电,Tb=15*3600-T1-„-T17=54000-6410=47590S（T1...T17为以上第3到第17项各项用户使用时长）；

“I3*T3+„+I19*T19”为手机开机期间各项功能操作的耗电总和。

3.1.3 预期结果

手机的待机时长T应大于等于3天（72小时）。

3.2 通话时长（测试用例编号：5.4.2）

3.2.1 测试条件:

准备手机2台、程控电源、假电池、电流测试软件、CMD55/CMU200（62CH，5级功率，BS-API:-70dbm）、测试白卡；

3.2.2 测试步骤

1）手机接白卡连接CMD55/CMU200手柄耦合通话，测试省电状态的通话平均

电流；

2）计算方法：电池容量乘以90%除以平均通话电流，即得出通话时长（乘以

90%的原因是算电池容量的有效值）。

3.2.3 预期结果

通话时长：一般大于或等于4H，相应型号说明书标注的通话时长作为一

个参考。

3.3 MP3外放时长（测试用例编号：5.4.3）

3.3.1 测试条件:

准备手机2台、程控电源、假电池、电流测试软件、CMD55/CMU200（62CH-5

级功率-BS-API:-70dbm）、测试白卡；

3.3.2 测试步骤

1）手机接白卡连接CMD55/CMU200，待网络注册成功后，最大音量播放《倩

女幽魂》，测试省电状态的外放平均电流；

2）计算方法：电池容量乘以90%除以MP3外放的平均电流，即得出MP3外放时

长。

3.3.3 测试预期结果

MP3外放时长：一般大于或等于4H。

3.4 耳机播放MP3时长（测试用例编号：5.4.4）

3.4.1 测试条件:

准备手机2台、原配耳机、程控电源、假电池、电流测试软件、CMD55/CMU200

（62CH-5级功率-BS-API:-70dbm）、测试白卡；

3.4.2 测试步骤

1）手机接白卡连接CMD55/CMU200，待网络注册成功后，耳机最大音量播放

《倩女幽魂》，测试省电状态耳机播放MP3平均电流；

2）计算方法：电池容量乘以90%除以耳机播放MP3的平均电流，即得出耳机

播放MP3的时长。

3.4.3 测试预期结果

耳机播放MP3时长：一般大于或等于30H。

3.5 播放MP4时长（测试用例编号：5.4.5）

3.5.1 测试条件:

准备手机2台、程控电源、假电池、电流测试软件、CMD55/CMU200（62CH-5

级功率-BS-API:-70dbm）、测试白卡；

3.5.2 测试步骤

1）手机接白卡连接CMD55/CMU200，待网络注册成功后，最大音量外放MP4

《步步高新广告》，测试外放MP4的平均电流；

2）计算方法：电池容量乘以90%除以外放MP4的平均电流，即得出外放MP4的工作时长。

3.5.3 测试预期结果

播放MP4时长：一般大于或等于4H。

3.6 录像时长（测试用例编号：5.4.6）

3.5.1 测试条件:

准备手机2台、程控电源、假电池、电流测试软件、CMD55/CMU200（62CH-5

级功率-BS-API:-70dbm）、测试白卡；

3.5.2 测试步骤

1）手机接白卡连接CMD55/CMU200，待网络注册成功后，对着纯白色背景录

像，测试录像时的平均电流；

2）计算方法：电池容量乘以90%除以录像时的平均电流，即得出录像的工作

时长。

3.5.3 测试预期结果

录像时长：一般大于或等于4H。

第五篇：组队测试用例样式

1.入队（默认可以自由组队）

-被邀请

-被邀请人状态

-不在同一个地图、GS上

-同一个地图的同一区域、不同区域，即同步范围

-不在线、传送

-处于别的玩家队伍中

-处于系统队伍中，如战场

-被邀请后收到提示

-被邀请人做出选择后的响应

-被邀请人没有选择时的响应

-被邀请人收到提示后下线

-被邀请人收到提示后切换地图、GS

-被两个、多个玩家邀请

-提示界面相关

-邀请别人

-邀请人状态

-邀请人没有队伍

-邀请人已经组建了一个队伍

-是不是队长

-邀请人队伍已满

-邀请人队伍未满

-在玩家回应前，继续邀请多个玩家

-发出邀请后

-对方未响应前，队伍已满

-对方未响应前，队伍已解散

-对方拒绝邀请是否提示

-对方接受邀请时的提示

-申请入队

-申请进入的目标队伍状态

-申请目标没有队伍

-申请目标队伍人数已满，是否继续进入申请名单

-申请目标是队长

-申请目标是队员

-向多个队伍发起申请

-申请目标（队长）接到的响应

-队长同意申请

-同意申请时，发起人已经离线

-同意申请时，发起人已有队伍

-同意申请时，发起人已经切换地图、GS

-同意申请时，发起人可以正常入队

-同意申请时，队伍人数已满

-队长拒绝申请

-发起人收到的提示

-其他队员不可操作

-队长能收到申请信息的数量

-队长重新组队后是否清空申请名单

-申请界面相关 2.队伍中（默认即时战斗游戏）

-需要同步的信息是否正确

-玩家的状态，如HP、等级、职业等

-玩家的位置

-同一个地图

-不同地图、GS

-队员上线/离线

-以上信息发生改变时能否同步/实时刷新

-队长/全队离线后的处理

-移交队长

-移交给不在线、不同地图、GS的玩家

-移交后新队长拥有的权限

-移交后原队长的权限

-是否需要确认框提示

-确认框弹出后目标玩家离队

-奖励的分配方式

-击杀奖励，如EXP

-同步范围外的玩家能否分配到

-是否需要队员参与击杀

-每一个分配到的玩家得到的数值

-玩家参与击杀中途死亡/离队，是否能分配到

-拾取奖励

-同步范围外的玩家能否参与分配

-是否需要队员参与击杀

-参与击杀队员中途下线/离队/死亡，上线后是否能参与分配

-其他几种分配方式

-战斗关系

--具体需要考虑技能与PK规则相关

-队伍界面相关

-其他功能

-任务共享

-队伍聊天

-标记 3.离队

-队长解散/离开队伍

-队员离开队伍

-离队后可以重新组建队伍

-离队后需要检查

-战斗关系

-地图上的位置标记