RCS客户端测试规范Word文档格式.docx
《RCS客户端测试规范Word文档格式.docx》由会员分享，可在线阅读，更多相关《RCS客户端测试规范Word文档格式.docx（12页珍藏版）》请在冰豆网上搜索。
关键词：
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、对于要上线的产品，版本上线前，必须对可服务性范围内的安装卸载及自动升级功能进行验证，未测试或未通过不能发布。
4.7安全性测试
安全性评估需要严格依据公司安全红线进行，并输出安全红线认证报告，同时对设计规格中的安全性设计还需要做一个全面的验证。
详见安全测试用例。
4.7.1概念
1、客户端的安全性包括两个层面：
一类是由软件漏洞导致的安全性问题。
这些漏洞可以是设计上的缺陷或是编程上的问题，甚至是开发人员预留的后门。
一类是是客户端的数据安全。
数据安全包括数据存储安全和数据传输安全两个方面。
2、安全性测试是验证客户端的安全服务和识别潜在安全性缺陷的过程。
4.7.2执行策略
1、由于攻击者没有闯入的标准方法，因而也没有实施安全性测试的标准方法。
目前客户端产品安全性测试范围主要依据公司级安全红线和客户端安全设计规格。
2、根据测试对象的可测试性不同，安全性测试方法包括人工测试和访谈确认。
3、安全测试中使用的工具必须是业界普遍采用并认可的。
4、对于不符合安全红线的内容要责令整改，并在版本发布前整改完成并验证通过。
5、按平台开展安全性测试，测试完毕，输出独立的安全测试报告。
4.7.3启动策略
1、迭代story测试中一般不启动安全性测试，经过一轮SDV后，可启动安全性测试。
2、当产品架构有较大调整时，必须启动一轮安全性测试。
3、对于要上线的产品，版本上线前，必须要经过正规有效的安全性测试，违反安全红线版本不能发布。
4.8兼容性测试
4.8.1概念
客户端的兼容性主要考虑软件之间、软硬件之间的配合程度、及与多平台互通、网络相关的配合程度。
兼容性测试能尽可能的保证客户端存在的价值，它是衡量客户端质量的重要指标。
4.8.2执行策略
1、依据FRS中适配机型和适配系统进行测试。
2、兼容性测试包括兼容性覆盖测试和问题案例库检查。
3、兼容性覆盖测试包括终端设备兼容，客户端与操作系统、第三方软件兼容，多平台互通测试，网络兼容测试。
4、兼容性问题案例库，在日常的客户端测试中进行积累，在兼容性测试中进行检查。
4.8.3启动策略
1、兼容性测试计划应该在SDV之前制定好，对不同平台、终端等做好规划，并在功能测试过程同步开展，做好记录。
2、对于要上线的产品，必须要经过正规有效的兼容性测试，且完全覆盖FRS中适配机型和适配系统。
4.9用户体验
4.9.1概念
1、这里的用户体验，包括体验活动的发起、问题收集与处理等。
至于用户调研、问卷调查、邀请目标用户进行1对1体验等工作一般由UCD设计人员主导，不在本文讨论范围。
2、本文中提到的用户体验涉及从体验启动、版本准出、问题收集、处理到闭环的全过程。
3、体验者一般分为总部体验者、一线销服务体验者和客户体验者，而总部体验者包括不限于LM、PL、TPM、UTE等。
4.9.2启动策略
1、交付项目上线前必须经过体验测试环节。
2、体验测试负责人组织发起各项体验测试活动，负责人可以是专人，也可以是TC兼任。
3、所有版本体验活动的启动须与项目经理商讨后制定。
4、非上线版本如基线版本只对总部体验者开放体验，上线版本对一线销服务体验者开放体验，视具体情况给客户开放体验。
5、体验版本必须满足版本准出原则才能交给体验者，不同类型的体验者采用不同的准出标准。
6、不管是非上线还是上线版本，迭代story开发阶段，即可发起体验，不过体验范围仅限总部体验者。
7、上线版本，经过第一轮SDV后，可对一线销服务体验者开放体验。
8、体验活动须随着版本的发布持续开展。
当有新需求合入版本且对用户使用产生较大影响时，可以发起一轮体验。
4.9.3版本准出标准
1、提供给总部体验者的版本，冒烟测试通过，主功能已实现且没有重大阻塞。
2、提供给一线销服务体验者或客户体验者的版本，除了冒烟测试通过外，还须对待体验特性做一轮完整测试，版本新增特性的功能实现必须正确，且没有致命缺陷。
另外由于一线体验者终端设备的多样性，为确保体验质量，体验版本还需满足以下标准，任一条不满足均不具备体验发起条件，如出现此类情况，测试TC需与项目经理商讨体验对策。
a.确保安装、卸载、升级、登录、注册功能正常，须覆盖测试人员手中所有机型，Android系统至少覆盖4.0和2.3，iOS系统至少覆盖6.0和5.1；
b.登录成功后操作深度三步内不能出现必现crash；
c.已开发功能无重大功能阻塞，在服务器不影响的情况下各功能可正常使用。
4.9.4闭环要求
1、《SCS客户端体验问题记录表》中问题状态分为open和close，问题闭环即问题均为close状态。
open和close定义参见《SCS客户端体验问题记录表》“表格填写说明”一页的“问题状态解释”。
2、一般在新的体验活动启动前，之前收集到的问题需要及时闭环。
3、对于上线版本，上线前，体验问题必须全部闭环。
4.9.5流程指引
用户体验活动中的问题是否闭环是关键，这就需要合理的流程来支撑，一般流程如下图所示，其中体验测试负责人扮演很关键的角色。
流程详细分解如下：
1、测试TC与项目经理就版本新需求合入情况明确体验版本计划。
2、版本冒烟测试通过，并且符合体验版本准出标准，版本体验工作启动，否则知会项目经理，刷新体验版本计划。
3、体验测试负责人刷新《SCS客户端体验问题记录表》的“版本信息”一页，对于当前版本可体验范围及新特性须填写清楚完整。
4、体验测试负责人可采用邮件、espace等方式知会体验者版本获取方式，并将《SCS客户端体验问题记录表》传递到体验者。
对于一线体验，传递到体验接口人。
5、体验者首先阅读《SCS客户端体验问题记录表》“表格填写说明”一页的“体验者注意事项”，然后按要求将问题填入中的“体验问题记录”一页。
6、体验测试负责人负责收集《SCS客户端体验问题记录表》，一线体验接口人安排大家将问题填入表格，汇总后反馈至测试TC。
7、体验测试负责人安排所有组员对体验问题进行处理，将问题梳理为bug、服务器问题、未重现、非问题、描述不清晰、业务设计问题、功能未实现等。
具体要求参见《SCS客户端体验问题记录表》“表格填写说明”一页中的“测试人员注意事项”。
8、根据测试人员处理的结果，体验测试负责人进行沟通和转交处理。
未重现、非问题与描述不清晰，负责人了解清楚后，直接与内部体验者沟通，掌握更多的信息，对测试的处理达成一致意见，一线的问题与接口人沟通清楚让其协助处理；
服务器问题，由测试TC转交给UTE处理，不在表格中跟踪；
业务设计问题，负责人转交给UCD/SE等设计人员处理，后者给出意见，是否接受，如接受是开发直接修改还是走需求变更流程等。
9、体验测试负责人将以上获得的信息填入《SCS客户端体验问题记录表》，并刷新问题状态。
10、体验测试负责人将体验问题的初步处理情况进行公示，一般从收集反馈到处理结果公示，控制在2个工作日以内。
11、体验测试负责人跟踪体验记录表中的问题状态，并敦促各方加快处理，尽早闭环。
升级会员 