RCS客户端测试规范Word文件下载.docx
《RCS客户端测试规范Word文件下载.docx》由会员分享，可在线阅读，更多相关《RCS客户端测试规范Word文件下载.docx（12页珍藏版）》请在冰豆网上搜索。
作者
1.00
初稿Initialdraft
田嘉洪201864
关键词：
RCS规范
摘要：
本文档从RCS客户端测试方法及评估维度等方面进行说明，适用范围为RCS基于智能平台的客户端测试。
缩略语清单：
缩略语
英文全名
中文解释
RCS
RichCommunicationSuite
融合通信解决方案
KPI
KeyPerformanceIndicator
关键指标考核，这里指客户端的关键技术指标
IM
InstantMessage
即时消息
1概述
本文从测试评审、测试设计及测试执行等方面简要描述了客户端测试的规范化操作，不涉及规范落实的具体细节。
具体规范的落实细节需要参考相应的规范文档、模板及指导书。
本文的读者主要为需要提供客户端软件的解决方案人员，包括客户端开发团队，客户端测试团队，一线销服人员，客户等。
2测试评审
2.1低保真评审
2.1.1概念
客户端交互设计的过程一般可以分为提出需求、需求细化、产出低保真、产出高保真几个阶段。
测试人员有义务在低保真产出时介入到设计环节，提出合理的意见和建议。
2.1.2执行策略
1、低保真评审都按页面来开展。
2、结合界面测试准则中的元素划分，挑出低保真每个页面的所有元素。
3、结合界面测试准则中的元素检查点，对低保真中的对应元素进行排查。
4、对于无法从低保真中获取答案的地方一一列出，收集并反馈给UCD及业务设计人员。
5、得到的答复将在用例设计时体现。
6、对于交互式低保真，除了界面元素检查外，交互流程的合理性也是评审的重点。
2.1.3启动策略
1、低保真输出或部分输出时即可组织测试评审，动作要快，反馈意见要快，尽快完善低保真，降低后期修改成本。
2、UCD或业务设计人员宣讲低保真时要确保已完成低保真的评审。
2.2设计规格评审
2.2.1概念
设计规格文档是从原始需求分析得到的，包括了客户的一些想法以及行业的标准。
设计规格文档的质量是后续测试的基础，在此基础上才能写出好的测试方案、测试用例等。
2.2.2执行策略
规格评审可以从以下多方面进行：
a.一致性，检验规格是否能够正确地满足FRS及需求文档的说明
b.可移植性，基线规格重点关注，是否在其它局点能够很好的移植
c.正确性，给开发和测试提供合理争取的实现方案
d.完整性，包扩每个需求的实现工作量、优先级、调用接口、适用平台、性能、异常处理等
e.可验证性，特性可以被验证、分析以示其满足需求
f.无歧义，规格用语是否让读者产生歧义，这个要及时提出，以免开发实现出现偏差
2.2.3启动策略
1、设计规格输出或部分输出时即可组织测试评审。
2、SE宣讲规格前要确保已完成设计规格的首轮评审。
3、用例写作和测试执行时，也可以对规格提出意见或建议，但尽量在首轮评审时保证充分性。
3测试设计
3.1业务用例设计
3.1.1概念
为确保对需求、设计规格、高低保真验证的充分性，需要一份客户端业务用例为测试执行提供保障。
客户端测试准备阶段可以没有详细的测试方案，但必须有详针对性强的用例设计工作。
3.1.2执行策略
1、客户端业务用例有三部分组成：
界面测试、操作场景和后台及网络操作。
2、界面测试准则和操作场景准则是客户端用例写作时强有力的支持，两份准则都是基于以往客户端产品测试经验生成，且在不断的测试中去完善。
3、根据界面测试准则，结合低保真，进行界面测试用例写作。
4、根据操作场景准则，结合设计规格，进行操作场景用例写作。
5、根据设计规格及接口文档，进行后台及网络操作用例写作。
6、迭代story阶段优先满足本阶段的用例设计工作。
7、用例需要分级，level0用例用于预测试使用。
8、用例写作完成后要进行用例评审工作，首先测试内部评审，然后给SE、开发和QA进行评审，并收集评审意见。
3.1.3启动策略
1、仅有FRS或需求列表时不启动用例设计工作。
2、低保真或设计规格，有其一，即可开始写作用例。
3、一个大版本测试工作结束，要对用例进行一次完善工作。
3.2专项用例设计
规范及要求参见各专项测试归档资料。
4测试执行
4.1业务用例执行
4.1.1概念
最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。
需求的覆盖率和测试的充分性，是检验产品是否合格的重要因素，同时也是要在测试报告中呈现的重要数据。
4.1.2执行策略
1、由于用例写作时间等因素并非所有的业务用例都有预期结果，测试执行时对于实际结果无法判断正确与否可与开发或SE进行沟通确定，并刷新到用例的预期结果中。
2、界面测试用例和后台及网络接口用例，在大版本的测试周期内一般只需测试一轮，对于操作场景用例，尤其是用例级别比较高的，需要在多个版本反复执行进行保障。
3、用例执行可采用手动或自动化的形式，也可通过抓包、查看客户端的操作日志、系统资源使用或数据库等操作等辅助手段。
4、在执行界面测试用例每个页面的界面检查内容点时需要完成对高保真和低保真的匹配检查。
4.1.3启动策略
1、过程符合《版本转测试CheckList》所有要求，TC启动冒烟测试，执行预测试用例。
2、冒烟测试通过后，进入Story测试或SDV测试，测试人员执行已选定的业务用例。
3、对于要上线或发布的产品，必须对业务用例进行100%执行且通过。
4.2需求覆盖检查
4.2.1概念
4.2.2执行策略
1、一般来讲，需求覆盖检查的目的是找两类问题，开发实现与需求不一致的问题，测试无法验证的问题。
2、需求检查的过程同时也是对用例基于需求进行核实的过程。
3、发现实现与需求不一致的问题，及时提单，并知会产品经理，抛出风险。
4、测试无法验证的问题，及时与产品经理协商处理措施。
4.2.3启动策略
1、基本功能开发完毕，经过一轮SDV后，可启动需求覆盖检查。
2、对于需求变更比较频繁的产品，可以分阶段多次进行需求覆盖检查。
3、对于要上线的产品，必须经过需求覆盖检查，且覆盖率达到100%。
4.3稳定性测试
4.3.1概念
1、稳定性测试是在保证功能完整正确的前提下，必不可少的一项测试内容。
通过稳定性测试可以观察在一个运行周期内、一定的压力条件下，客户端的出错机率、性能劣化趋势等，进而大大减少上线后的崩溃卡死等现象。
2、不同于服务器端的稳定性测试的是，客户端软件是运行在单机环境下，所以不存在并发用户数的概念，取而代之的是一些多进程长时间的操作，以及各种复杂的并发场景的组合。
一款客户端软件，它的稳定性测试需求包括：
a.长时间各种操作下（含静默），软件的稳定性以及各种主要指标的劣化趋势。
b.多进程或多线程运行即客户端同时进行多个事件处理的稳定性。
c.大数据量业务时的稳定性。
4.3.2执行策略
1、稳定性测试基于场景开展。
2、稳定性测试需要考虑不同机型不同操作系统。
3、自动化测试是稳定性测试的基础，借助自动化工具进行执行并进行结果检验是稳定性测试的常用方法。
4、稳定性测试不同于功能测试，它属于一种概率性的测试，需要长期运行过后才能得出测试结论，即使稳定性测试通过，也不能保证系统实际运行的时候不出问题。
所以要尽可能的提高测试的可靠性，可以通过多次测试，延长测试时间，增大测试压力等手段。
5、按平台开展稳定性测试，测试完毕，输出独立的测试报告。
4.3.3启动策略
1、基本功能开发完毕，经过一轮SDV后，可启动第一轮稳定性测试。
2、当产品架构有较大调整时，必须启动一轮稳定性测试。
3、对于已上线的产品，稳定性指标将作为版本发布的重要依据，尽可能对每个上线版本进行比较全面系统的稳定性测试。
4.4可靠性测试
4.4.1概念
1、客户端的可靠性是指在规定的环境条件下，客户端完成规定功能的能力。
2、客户端的可靠性测试大致分为三类，网络或服务器异常下应用程序的处理、突发事件时应用程序的处理及关键资源异常下应用程序的使用。
4.4.2执行策略
1、可靠性测试基于场景开展。
2、对于在真实环境中较难构造的场景，需要借助工具进行模拟。
3、可靠性通过原则：
出现异常尽量不要影响主要业务和场景，无法避免影响业务时，能够给出详细告警，异常恢复后，业务也能够自动恢复。
4、按平台开展可靠性测试，测试完毕，输出独立的测试报告。
4.4.3启动策略
1、可靠性测试可作为专项，在一轮SDV完成后启动。
2、当产品架构有较大调整时，必须启动一轮可靠性测试。
3、对于要上线的产品，必须要经过正规有效的可靠性测试。
4.5KPI测试
4.5.1概念
1、KPI即可以用来评估的关键指标，对于终端应用来说，可以量化并进行对比的各项指标就是KPI。
2、终端KPI一般包括电量、流量、CPU、内存、安装包大小以及业务性能指标等。
本文中规定对于其它可以量化的指标如操作成功率属于稳定性测试范畴，而操作步骤数则属于用户体验测试范畴，均不属于KPI测试的范围。
3、所谓性能指标，主要指用户操作的时延，而且是端到端的时延。
4.5.2执行策略
1、KPI测试除安装包大小外，其余均基于场景开展。
KPI不同，场景选取可以不同。
2、KPI测试须尽可能提供竞品的比对结果。
竞品的选择同样基于场景，每个场景选取top3竞品。
3、电量和流量需结合用户行为模型进行24小时消耗评估。
4、性能指标如涉及网络交互，测试数据须能体现出不同网络的差异性。
5、按平台开展KPI测试，测试完毕，除安装包外，须输出独立的测试报告。
4.5.3启动策略
1、迭代story测试中一般不启动KPI测试，一到两轮的SDV后，若版本比较稳定且无功能阻塞可启动第一轮KPI测试。
2、当产品架构有较大调整时，必须启动一轮KPI测试。
3、对于已上线的产品，根据版本周期制定KPI测试计划，防止版本间的变动造成体验指标的下降。
4.6可服务性测试
4.6.1概念
1、可服务性是客户端的特性之一，它描述了产品在安装、维护等服务活动中的适应、效率和质量等方面的支撑能力。
2、可服务性测试的范围既要包含产品可服务性DFX需求，也要包含客户端可服务性必检查项。
3、可服务性必检查项包括日志、目录、国际化本地化、自动升级、安装及卸载、故障报告等。
4.6.2执行策略
1、目录的检查对象主要是敏感数据、用户文件、大文件、可能无限增长的文件等的保持路径。
2、日志的检查必须包括日志级别、日志信息、日志大小和日志格式，发布版本和调测版本的要求等，对于客户端组件的日志也在检查范围内。
3、升级的检查必须包括强制升级、非强制升级以及升级前后的兼容性等。
4、安装卸载的检查需要考虑GoogleMarket/AppStore下载安装、SD卡安装、工具安装等，对于工具安装须覆盖业界主流终端管理软件，包括官方及第三方工具。
4.6.3启动策略
1、基本功能开发完毕，经过一轮SDV后，可启动可服务性测试。
2、当产品架构有较大调整时，必须对可服务性测试范围内的部分涉及内容进行测试。
3、对于要上线的产品，版本上线前，必须对可服务性范围内的安装卸载及
升级会员 