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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

完整的大纲应该是：

目录

测试计划标识符

目录表

参考文献

词汇表

介绍

测试项

软件风险问题

待测特征

不予测试的特征

方法

测试项通过/失败准则

挂起准则和恢复需求

测试交付物

测试任务

环境需求

职责

人员安排与培训需求

进度表

计划风险与应急措施

审批

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

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

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

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.总结

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

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

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

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

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。

第五篇：APP测试流程,测试用例,计划,报告可参照（写写帮推荐）

移动APP测试流程及测试点

1.APP测试基本流程

1.1.测试周期

测试周期可按项目的开发周期来确定测试时间，一般测试时间为两三周（即15个工作日），根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向负责人确认项目排期。

1.2.测试资源

测试任务开始前，检查各项测试资源。

--产品功能需求文档；

--产品原型图；

--产品效果图；

--行为统计分析定义文档；

--测试设备（ios7.1-ios9.2；Android4.0-Android6.0；）；

--其他。

1.3.日报、周报及APP上线报告

1）测试人员每天需对所测项目发送测试日报。

2）测试日报所包含的内容为：

--对当前测试版本质量进行分级（高中低）；

--对较严重的问题进行例举，提示开发人员优先修改；

--对版本的整体情况进行评估。

3）APP上线前，测试人员发送APP上线报告。4）上线报告所包含的内容为：

--对当前版本质量进行分级；

--附上测试报告（功能测试报告、兼容性测试报告、性能测试报告以及app可用性能标准结果）；

--总结上线版本的基本情况。若有遗留问题必须列出并记录解决方案。5）周报作为汇总本周所有的情况，以及开发人员修改情况与回归测试。

2.APP测试点

2.1.安全测试

2.1.1.软件权限

1）扣费风险：包括发送短信、拨打电话、连接网络等；

2）隐私泄露风险：包括访问手机信息、访问联系人信息等；

3）对App的输入有效性校验、认证、授权、敏感数据存储、数据加密等方面进行检测；

4）限制/允许使用手机功能接人互联网；

5）限制/允许使用手机发送接受信息功能；

6）限制/允许应用程序来注册自动启动应用程序；

7）限制或使用本地连接；

8）限制/允许使用手机拍照或录音；

9）限制/允许使用手机读取用户数据；

10)限制/允许使用手机写人用户数据；

11)检测App的用户授权级别、数据泄漏、非法授权访问等。2.1.2.安装与卸载的安全性

1）应用程序应能正确安装到设备驱动程序上；

2）能够在安装设备驱动程序上找到应用程序的相应图标；

3）是否包含数字签名信息；

4）JAD文件和JAR包中包含的所有托管属性及其值必需是正确的；

5）JAD文件显示的资料内容与应用程序显示的资料内容应一致；

6）安装路径应能指定；

7）没有用户的允许, 应用程序不能预先设定自动启动；

8）卸载是否安全, 其安装进去的文件是否全部卸载；

9）卸载用户使用过程中产生的文件是否有提示；

10）其修改的配置信息是否复原；

11）卸载是否影响其他软件的功能；

12）卸载应该移除所有的文件。

2.1.3.数据安全性

1）当将密码或其他的敏感数据输人到应用程序时, 其不会被储存在设备中, 同时密码也不会被解码；

2）输人的密码将不以明文形式进行显示；

3）密码, 信用卡明细, 或其他的敏感数据将不被储存在它们预输人的位置上；

4）防止应用程序异常终止而又没有删除它的临时文件, 文件可能遭受人侵者的袭击, 然后读取这些数据信息；

5）当将敏感数据输人到应用程序时, 其不会被储存在设备中；

6）在数据删除之前，应用程序应当通知用户或者应用程序提供一个“取消”命令的操作；

7）“取消”命令操作能够按照设计要求实现其功能；

8）应用程序应当能够处理当不允许应用软件连接到个人信息管理的情况；

9）当进行读或写用户信息操作时, 应用程序将会向用户发送一个操作错误 的提示信息；

10）在没有用户明确许可的前提下不损坏删除个人信息管理应用程序中的任 何内容；

11）应用程序读和写数据正确；

12）应用程序应当有异常保护；

13）如果数据库中重要的数据正要被重写, 应及时告知用户；

14）能合理地处理出现的错误；

25）意外情况下应提示用户。

2.1.4.通讯安全性

1）在运行其软件过程中, 如果有来电、SMS、EMS、MMS、蓝牙、红外等通讯或充电时, 是否能暂停程序，优先处理通信, 并在处理完毕后能正常恢复软件, 继续其原来的功能；

2）当创立连接时, 应用程序能够处理因为网络连接中断, 进而告诉用户连接中断的情况；

3）应能处理通讯延时或中断；

4）应用程序将保持工作到通讯超时, 进而发送给用户一个错误信息指示有连接错误；

5）应能处理网络异常和及时将异常情况通报用户；

6）应用程序关闭或网络连接不再使用时应及时关闭)断开；

7)HTTP、HTTPS覆盖测试

--App和后台服务一般都是通过HTTP来交互的，验证HTTP环境下是否正常；

--公共免费网络环境中（如：麦当劳、星巴克等）都要输入用户名和密码，通过SSL认证来访问网络，需要对使用HTTP Client的library异常作捕获处理。

2.1.5.人机接口安全性

1）返回菜单总保持可用；

2）命令有优先权顺序；

3）声音的设置不影响应用程序的功能；

4）应用程序必需利用目标设备适用的全屏尺寸来显示上述内容；

5）应用程序必需能够处理不可预知的用户操作, 例如错误的操作和同时按下多个键。

2.2.安装卸载测试

验证App是否能正确安装、运行、卸载及操作过程和操作前后对系统资源的使用情况。

2.2.1.安装

1）软件在不同操作系统（Android、iOS）下安装是否正常；

2）软件安装后的是否能够正常运行，安装后的文件夹及文件是否写到了指定的目录里；

3）软件安装各个选项的组合是否符合概要设计说明；

4)）软件安装向导的UI测试；

5）软件安装过程是否可以取消，点击取消后，写入的文件是否如概要设计说明处理；

6）软件安装过程中意外情况的处理是否符合需求（如死机，重启，断电）； 7）安装空间不足时是否有相应提示；

8）安装后没有生成多余的目录结构和文件；

9）对于需要通过网络验证之类的安装，在断网情况下尝试一下；

10）还需要对安装手册进行测试，依照安装手册是否能顺利安装。

2.2.2.卸载

1）直接删除安装文件夹卸载是否有提示信息；

2）测试系统直接卸载程序是否有提示信息；

3）测试卸载后文件是否全部删除所有的安装文件夹；

4）卸载过程中出现的意外情况的测试（如死机、断电、重启）；

5）卸载是否支持取消功能，单击取消后软件卸载的情况；

6）系统直接卸载UI测试，是否有卸载状态进度条提示。

2.3.UI测试

测试用户界面(如菜单、对话框、窗口和其它可规控件)布局、风格是否满足客户要求、文字是否正确、页面是否美观、文字、图片组合是否完美、操作是否友好等。

UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏觅功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

2.3.1.导航测试

1）按钮、对话框、列表和窗口等；或在不同的连接页面之间需要导航；

2）是否易于导航，导航是否直观； 3）是否需要搜索引擎；

4）导航帮助是否准确直观；

5）导航与页面结构、菜单、连接页面的风格是否一致。

2.3.2.图形测试

1）横向比较。各控件操作方式统一；

2）自适应界面设计，内容根据窗口大小自适应；

3）页面标签风格是否统一；

4）页面是否美观；

5）页面的图片应有其实际意义而要求整体有序美观；

6）图片质量要高且图片尺寸在设计符合要求的情况下应尽量小；

7）界面整体使用的颜色不宜过多。

2.3.3.内容测试

1）输入框说明文字的内容与系统功能是否一致；

2）文字长度是否加以限制；

3）文字内容是否表意不明；

4）是否有错别字；

5）信息是否为中文显示；

6）是否有敏感性词汇、关键词；

7）是否有敏感性图片，如：涉及版权、专利、隐私等图片。

2.4.功能测试

根据软件说明或用户需求验证App的各个功能实现，采用如下方法实现并评估功能测试过程： 1)采用时间、地点、对象、行为和背景五元素或业务分析等方法分析、提炼App的用户使用场景，对比说明或需求，整理出内在、外在及非功能直接相关的需求，构建测试点，并明确测试标准，若用户需求中无明确标准遵循，则需要参考行业或相关国际标准或准则。

2)根据被测功能点的特性列丼出相应类型的测试用例对其进行覆盖，如；涉及输入的地方需要考虑等价、边界、负面、异常或非法、场景回滚、关联测试等测试类型对其进行覆盖。

3)在测试实现的各个阶段跟踪测试实现与需求输入的覆盖情况，及时修正业务或需求理解错误。

2.4.1.运行

1）App安装完成后的试运行，可正常打开软件；

2）App打开测试，是否有加载状态进度提示；

3）App打开速度测试，速度是否可观；

4）App页面间的切换是否流畅，逻辑是否正确；

5）注册

--同表单编辑页面--用户名密码长度；

--注册后的提示页面；

--前台注册页面和后台的管理页面数据是否一致；

--注册后，在后台管理中页面提示；

6）登录

--使用合法的用户登录系统；

--系统是否允许多次非法的登陆，是否有次数限制；--使用已经登陆的账号登陆系统是否正确处理；

--使用禁用的账号登陆系统是否正确处理；

--用户名、口令（密码）错误或漏填时能否登陆；

--删除或修改后的用户，原用户登陆；

--不输入用户口令和用户、重复点（确定或取消按钮）是否允许登陆；

--登陆后，页面中登陆信息；--页面中有注销按钮；--登陆超时的处理；

7）注销

--注销原模块，新的模块系统能否正确处理；

--终止注销能否返回原模块，原用户；

--注销原用户，新用户系统能否正确处理；

--使用错误的账号、口令、无权限的被禁用的账号进行注销。

2.4.2.APP前后台切换

1)APP切换到后台，再回到app，检查是否停留在上一次操作界面；

2)APP切换到后台，再回到app，检查功能及应用状态是否正常，安卓和IOS的版本的处理机制有的不一样；

3)app切换到后台，再回到前台时，注意程序是否崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候；

4)手机锁屏解屏后进入app注意是否会崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候；

5)当App使用过程中有电话进来中断后再切换到app，功能状态是否正常； 6)当杀掉app进程后，再开启app，app能否正常启动；

7)出现必须处理的提示框后，切换到后台，再切换回来，检查提示框是否还存在，有时候会出现应用自动跳过提示框的缺陷；

8)对于有数据交换的页面，每个页面都必需要进行前后台切换、锁屏的测试，这种页面最容易出现崩溃。

2.4.3.自动登陆

很多应用提供自动登录功能，当应用开启时自动以上一次登录的用户身份来使用app.1)app有免登录功能时，需要考虑IOS与安卓版本差异；

2)考虑无网络情况时能否正常进入免登录状态；

3)切换用户登录后，要校验用户登录信息及数据内容是否相应更新，确保原用户退出；

4)根据MTOP的现有规则，一个帐户只允许登录一台机器。所以，需要检查一个帐户登录多台手机的情况。原手机里的用户需要被踢出，给出友好提示；

5)app切换到后台，再切回前台的校验；

6)切换到后台，再切换回前台的测试

7)密码更换后，检查有数据交换时是否进行了有效身份的校验；

8)支持自动登录的应用在进行数据交换时，检查系统是否能自动登录成功并且数据操作无误；

9)检查用户主动退出登录后，下次启动app，应停留在登录界面

2.4.4.数据更新

根据应用的业务规则，以及数据更新量的情况，来确定最优的数据更新方案。

1)需要确定哪些地方需要提供手动刷新，哪些地方需要自动刷新，哪些地方需要手动+自动刷新；

2)确定哪些地方从后台切换回前台时需要进行数据更新；

3)根据业务、速度及流量的合理分配，确定哪些内容需要实时更新，哪些需要 定时更新；

4)确定数据展示部分的处理逻辑，是每次从服务端请求，还是有缓存到本地，这样才能有针对性的进行相应测试；

5)检查有数据交换的地方，均有相应的异常处理。

2.4.5.离线浏览

很多应用会支持离线浏览，即在本地客户端会缓存一部分数据供用户查看。

1)在无网络情况可以浏览本地数据；

2)退出app再开启app时能正常浏览；

3)切换到后台再切回前台可以正常浏览；

4)锁屏后再解屏回到应用前台可以正常浏览；

5)在对服务端的数据有更新时会给予离线的相应提示

2.4.6.APP更新

1)当客户端有新版本时，有更新提示；

2)当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动app时，仍能出现更新提示；

3)当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出客户端。下次启动app时，仍出现强制升级提示。

4)当客户端有新版本时，在本地不删除客户端的情况下，直接更新检查是否能正常更新；

5)当客户端有新版本时，在本地不删除客户端的情况下，检查更新后的客户端功能是否是新版本；

6)当客户端有新版本时，在本地不删除客户端的情况下，检查资源同名文件如图片是否能正常更新成最新版本。如果以上无法更新成功的，也都属于缺陷。

2.4.7.定位、照相机服务

1)App有用到相机，定位服务时，需要注意系统版本差异；

2)有用到定位服务、照相机服务的地方，需要进行前后台的切换测试，检查应用是否正常；

3)当定位服务没有开启时，使用定位服务，会友好性弹出是否允许设置定位提示。当确定允许开启定位时，能自动跳转到定位设置中开启定位服务；

4)测试定位、照相机服务时，需要采用真机进行测试。

2.4.8.时间测试

客户端可以自行设置手机的时区、时间，因此需要校验该设置对app的影响。

--中国为东8区，所以当手机设置的时间非东8区时，查看需要显示时间的地方，时间是否展示正确，应用功能是否正常。时间一般需要根据服务器时间再转换成客户端对应的时区来展示，这样的用户体验比较好。比如发表一篇微博在服务端记录的是10：00，此时，华盛顿时间为22：00，客户端去浏览时，如果设置的是华盛顿时间,则显示的发表时间即为22:00,当时间设回东8区时间时，再查看则显示为10：00。（另：如果时间不统一，由于semp服务器的缘故，会导致APP无法正常使用，遇到这种情况，请及时更新手机时间，或者通知开发人员修改服务器时间，谢谢大家配合）。2.4.9.PUSH消息推送测试

1)检查push消息是否按照指定的业务规则发送；

2)检查不接受推送消息时，检查用户不会再接收到push；

3)如果用户设置了免打扰的时间段，检查在免打扰时间段内，用户接收不到PUSH。在非免打扰时间段，用户能正常收到push；

4)当push消息是针对登录用户的时候，需要检查收到的push与用户身份是否相符，没有错误地将其它人的消息推送过来。一般情况下，只对手机上最后一个登录用户进行消息推送；

5)测试push时，需要采用真机进行测试。

2.5.性能测试

评估App的时间和空间特性：

1)极限测试：在各种边界压力情况下，如电池、存储、网速等，验证App是否能正确响应。

--内存满时安装App；

--运行App时手机断电；

--运行App时断掉网络；

2)响应能力测试：测试App中的各类操作是否满足用户响应时间要求。

--App安装、卸载的响应时间；

--App各类功能性操作的影响时间；

3)压力测试：反复/长期操作下、系统资源是否占用异常。

--App反复进行安装卸载，查看系统资源是否正常；

--其他功能反复进行操作，查看系统资源是否正常；

4)性能评估：评估典型用户应用场景下，系统资源的使用情况。

2.6.兼容测试

主要测试内部和外部兼容性：

1）与本地及主流App是否兼容；

2）基于开发环境和生产环境的不同，检验在各种网络连接下(WiFi、GSM、GPRS、EDGE、WCDMA、CDMA1x、CDMA2000、HSPDA等)，App的数据和运用是否正确；

3）与各种设备是否兼容，若有跨系统支持则需要检验是否在各系统下，各种行为是否一致；

--不同操作系统的兼容性，是否适配；

--不同手机屏幕分辨率的兼容性；

--不同手机品牌的兼容性。

2.7.回归测试

1）Bug修复后且在新版本发布后需要进行回归测试。

2）Bug修复后的回归测试在交付前、要进行全量用例的回归测试。

2.8.用户体验测试

以主观的普通消费者的角度去感知产品或服务的舒适、有用、易用、友好亲切程度。通过不同个体、独立空间和非经验的统计复用方式去有效评价产品的体验特性修改意见提升产品的潜在客户满意度。

1）是否有空数据界面设计，引导用户去执行操作；

2）是否滥用用户引导；

3）是否有不可点击的效果，如：你的按钮此时处于不可用状态，那么一定要灰掉，或者拿掉按钮，否则会给用户误导；

4）菜单层次是否太深；

5）交互流程分支是否太多；

6）相关的选项是否离得很远；

7）一次是否载入太多的数据；

8）界面中按钮可点击范围是否适中；

9）标签页是否跟内容没有从属关系，当切换标签的时候，内容跟着切换；

10）操作应该有主次从属关系；

11）是否定义Back的逻辑。涉及软硬件交互时，Back键应具体定义；

12）是否有横屏模式的设计，应用一般需要支持横屏模式，即自适应设计

2.9.硬件环境测试

2.9.1.网络环境测试

手机的网络目前主要分为2G、3G、4G、wifi。目前2G的网络相对于比较慢，测试时尤其要注意此块的测试。

1)无网络时，执行需要网络的操作，给予友好提示，确保程序不出现crash； 2)内网测试时，要注意选择到外网操作时的异常情况处理；

3)在网络信号不好时，检查功能状态是否正常，确保不因提交数据失败而造成crash；

4)在网络信号不好时，检查数据是否会一直处于提交中的状态，有无超时限制。如遇数据交换失败时要给予提示；

5)在网络信号不好时，执行操作后，在回调没有完成的情况下，退出本页面或者执行其他操作的情况，有无异常情况。此问题也会经常出现程序crash。2.9.2.服务器垒机或者出现404、500的情况下测试

后台服务牵涉到DNS、空间服务商的情况下会影响其稳定性，如：当出现域名解析故障时，你对后台API的请求很可能就会出现404错误，抛出异常。这时需要对异常进行正确的处理，否则可能会导致程序不能正常工作。是否有友好的提示。