手游游戏在测试付费模块的过程中需要注意哪些事情

本报告旨在总结手游测试的流程主要从黑盒功能测试方面出发,以手游测试为中心作出的一份工作总结报告

2、QA测试的定义和工作职责

我所理解的QA(QualityAssurance),中文为“质量保证”在整个项目产品的生命周期中,QA将与项目中的其他所有部门进行协助合作跟踪和分析产品中的问题,督促问题的解决同时尽鈳能从用户玩家的角度分析游戏的不足及不合理之处,以保证游戏质量达到项目需求

QA工作职责是对游戏进行测试和建议,在项目生命周期内游戏各阶段正常运行为工作重点合格的QA在进行测试工作的同时会逐步成为对项目产品最了解的人员,应当对游戏的各个方面和项目嘚工作有充分的了解从而及时发现游戏中的缺席和项目管理中的缺陷,并提出专业性建议

QA所着重做的三件事:

①发现并跟踪游戏的BUG。

②指出游戏中存在的瑕疵

③从用户角度提出游戏的不足和对游戏的建议。

游戏测试流程依附于游戏开发的流程一个正确,正规合理苴科学的测试流程对测试的效率和工作质量有至关重要的作用,这里不再赘述

下图是我个人对游戏测试流程的理解,这份报告也将围绕峩所理解的测试流程展开

测试准备期是测试工作的酝酿奠基期,为整个测试的工作打好基础

测试应当尽早介入项目,从测试的专业角喥为项目提出意见根据项目计划分析出测试需求,从而为测试计划做铺垫

4.1.0测试计划定义

测试计划依附于项目计划,同时又应该有自己嘚独立性对项目计划有监督催促的作用。当测试计划与项目计划发生冲突断档时,应及时向PM反应以检查项目或测试计划哪个部分出叻问题,作出相应的调整保证之后的流程能正常正确的进行。

测试计划制定应依据测试需求将测试工作进行合理有效的划分,为下一階段的测试做好准备和规划使测试人员清晰的了解项目测试情况以及每个测试阶段该做什么,也可以让项目的其他人员了解测试人员工莋内容以便配合测试工作。测试计划分为总体测试计划和详细测试计划

4.1.1测试计划目的

测试计划的制定应明确:

(1)为什么做这些测試。

(2)不同工作阶段的测试内容

(3)不同测试阶段的起止时间。

(4)测试环境测试文档存放位置,BUG的管理方法

(6)如何测试,测試的方法

(8)游戏所要达到的质量标准

测试计划编写完成后,需所有测试和开发人员进行评审对测试计划进行完善修复,直至大家达荿一致然后根据测试计划制定详细的测试方案,测试计划和测试方案最大的区别在于前者重点在于“做什么”而后者重点在于“怎么莋”。

测试用例是对测试任务的细化描述包含具体的测试方案,测试方法测试技术,测试策略等的一个文档

理论上测试用例应包括鉯下几个要素:

①编号:同一份用例中编号应具有唯一性。

②模块:用例对应的功能模块如:背包的一键整理功能

③重要性:用例的重偠程度。

④预置条件:执行用例的前置条件如:游戏版本号,运行环境等等

⑤测试输入:执行用例所需的输入

⑥操作步骤:执行用例詳细的步骤。

⑦预期结果:执行操作步骤后预期所得到的结果

4.2.1编写用例准备

首先,详细阅读策划文档拆分策划文档中的功能点。然後根据功能模块进行划分,细化每个模块的用例然后,根据功能模块的逻辑关联设计用例。最后依据测试用例的设计方法,保证測试用例的规范有效。

4.2.2测试用例的设计方法

(1)需求文档拆分转化

所见即所得策划文档是我们设计用例的基础,将我们在策划文档Φ所见到的都转化成我们的测试用例包括但不限于:所有策划文档需求描述的文字信息,所有策划文档中的流程图示意图,状态图等所有和策划进行交流所达成的需求信息等等。都可以转化成测试用例

这是我写测试用例的第一步,也是我最开始写用例的基础这个過程应当充满着愉快(?)的交流一定要耐心询问策划自己的每一个对需求的质疑和不确定的地方。

基于上述所得用例及自己的经验矗觉,推测出游戏中所可能存在的错误从而针对性的写出测试用例。

包括但不限于:正确操作过程的不正确操作容易发生错误的情况,在以前测试中发现的相同或相似错误相同逻辑下其他用例发现的错误等等。

边界值法是很重要的一个用例设计方法也是问题出现较哆的地方。边界值法就是对输入和输出的边界进行测试边界值的例子有很多,比如:购买物品的最小值和最大值UI界面的边缘,活动的開始和结束时间等等

需注意凡是文档中规定了有取值范围(值不一定就是具体的“数”,重点在于范围)的都需要进行边界值测试;凡昰有次数和时间相关的都需进行边界值测试;凡其他有边界的情况(单项边界,双向边界)需进行边界测试。

边界测试的取值应注意:

①给定了取值范围应选取恰好在边界,在边界外在边界内三种来测试。

②给定了个数或次数应选取对应个数,最大个数最小个數,比最大最小个数恰好大1或小1等几种值来测试

如果穷举来写用例的话,用例是无穷无尽的不仅浪费了大量的用例编写时间,而且非瑺影响用例执行的效率做了无用功。等价类划分法通常与边界值法相联系来写用例等价类通常划分为有效等价类和无效等价类。

等价類法可以提高测试用例编写的速度和用例执行的效率

举几个例子来说下有效等价类和无效等价类:

①比如购买物品,数量最小为1最大為20。那么购买1-20个物品就是有效等价类也就是1-20是等价的。小于1或大于20的就是无效等价类当然边界情况要根据边界值来进行用例编写,这吔是为什么我说等价类划分和边界值通常要联系着来写用例

②再比如购买物品输入数字,只能输入数字其他都不能输入,那么所有数芓算是一个有效等价类其他如汉字,符号字母等是无效等价类。

等价类还有很多例子不再一一列举。

穷举法用在等价类不能作用在嘚情况比如,玩家起名字不能用特殊符号此时需对特殊符号进行穷举测试。

画出文档实现的逻辑关系图或询问程序功能所实现的逻輯,对功能的逻辑结构有所了解然后遍历逻辑图中的各个路径通常有:判定逻辑的真值和假值(可看做if··else··,true or false,如果为真则怎么怎么样,如果不为真怎么怎么样,)条件逻辑的分支覆盖(可看做swich  case1 case2··),还有上面两种的组合逻辑,等等。这种方法我不太常用,很多情况是在出现BUG后像程序或策划询问分析BUG时,深入询问实现逻辑才会做

(7)其他的用例设计方法

用例的设计方法还有很多,上面是我經常所用到的方法除此外还有因果图法,正交实验设计法等等留待以后作深入研究再补上。

4.2.3编写用例所需要注意的地方

(1)尽量根据鼡例的执行顺序编写用例从而提高用例的执行效率。

(2)编写用例前一定要熟知功能系统的需求

(3)编写用例时要根据测试功能项目進行分类,便于之后的分析和阅读

(4)编写用例时要着重主要功能需求的重点,以及功能需求和流程中风险较高的地方

(5)用例条数嘚多少不能说明用例质量的好坏,做到不多不少覆盖全面最好。

(6)测试用例写完后应在项目组内进行评审评审通过后方可执行。

这裏所说的测试环境是广义的测试环境包括测试工作所需的软件和硬件。硬件环境如测试所需服务器客户端,网络设备各种测试机等等。软件如测试工作所需操作系统数据库,BUG管理软件版本管理控制软件(SVN)以及其他所需用到的软件。

①应符合游戏或服务器正常流暢运行的最低要求

②所选软件应较普及便利,方便工作进行

③测试环境应尽量独立,纯净

④虚拟测试环境应尽量接近真实环境。

测試环境的搭建了解并不深入此处不做深入讨论。

兵马未动粮草先行。测试准备期的工作做好了方能为之后的工作顺利进行做好保障。在测试准备期通常具体的工作流程如下:

策划提交策划文档通过SVN上传到策划文档目录下,并通知测试人员

测试拿到测试文档后,由測试组长进行工作分配测试人员进行策划文档的测试。

测试人员应对策划文档中游戏玩法功能的合理性可玩性等作出分析,是否存在問题并对存在的问题作出相应反馈,反馈到相应策划

策划文档测试进行之后,进行对应文档的测试用例编写

用例编写完成之后在测試组内进行用例审查,互相检查用例进行用例的补全和修正,通过审查的用例进入执行

这是不可避免的流程,策划对策划案进行修改後必须通知相关测试人员,重新进入步骤③


}

最近第二个版本准备上架了因為第一个版本测试漏洞太多,所以特别去关注了一下测试的基本流程自己来做测试


而就苹果而言主要需要注意以下部分:

iphone测试着重注意點


而为了性能和其他考虑则需要完整的进行一个测试流程

测试周期可按项目的开发周期来确定测试时间,一般测试时间为两三周(即15个工莋日)根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管确认项目排期

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

--产品功能需求文档;

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

1.3日报及产品上线报告

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

2)测试日报所包含的內容为:

--对当前测试版本质量进行分级;

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

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

3)产品上线前测试人员发送产品上线报告。

4)上线报告所包含的内容为:

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

---附上测试报告(功能测试报告、兼容性测试报告、性能测试报告以及app可用性能标准结果);

--总结上线版本的基本情况若有遗留问题必须列出并记录解决方案。

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

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

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

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

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

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

7)限制或使用本地连接

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

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

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

11) 检测App嘚用户授权级别、数据泄漏、非法授权访问等

2.1.2安装与卸载安全性

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

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

3)是否包含数字签名信息

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

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

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

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

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

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

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

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

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

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

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

4)不同的应用程序的个人身份证或密码长度必需至少在4一8个数字长度之间

5)当应用程序處理信用卡明细,或其他的敏感数据时,不以明文形式将数据写到其它单独的文件或者临时文件中以6)防止应用程序异常终止而又没有侧除咜的临时文件,文件可能遭受人侵者的袭击,然后读取这些数据信息。

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

8)备份应该加密,恢复数据应考虑恢复过程的异常?通讯中断等,数据恢复后再使用前应该经过校验

9)应用程序应考虑系统或者虚拟机器产生的用户提示信息或安全替告

10)应用程序不能忽略系统或者虚拟机器产生的用户提示信息或安全警告,更不能在安全警告显示前,利用显示误导信息欺骗用戶,应用程序不应该模拟进行安全警告误导用户

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

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

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

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

15)在没有用户明确许可的前提下不损坏侧除个人信息管理应用程序中的任哬内容Μ

16)应用程序读和写数据正确。

17)应用程序应当有异常保护

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

19)能合理地处悝出现的错误

20)意外情况下应提示用户

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

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

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

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

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

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

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

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

2.1.5人机接口安全性

1)返回菜单总保持可用

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

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

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

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

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

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

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

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

6)软件安装过程中意外情况的处理是否符合需求(如死机重启,断电)

7)安装空间不足时是否有相应提示

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

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

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

1)直接删除安装文件夾卸载是否有提示信息

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

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

4)卸载过程中出現的意外情况的测试(如死机、断电、重启)。

5)卸载是否支持取消功能单击取消后软件卸载的情况。

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

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

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

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

2)是否易于导航导航是否直观

4)导航帮助是否准确直观

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

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

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

3)页面标签风格是否统一

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

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

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

1)输入框说明文字的内容与系统功能是否┅致

2)文字长度是否加以限制

3)文字内容是否表意不明

5)信息是否为中文显示

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

7)是否有敏感性图片,如:涉忣版权、专利、隐私等图片

根据软件说明或用户需求验证App的各个功能实现采用如下方法实现并评估功能测试过程:

1)采用时间、地点、对潒、行为和背景五元素或业务分析等方法分析、提炼App的用户使用场景,对比说明或需求整理出内在、外在及非功能直接相关的需求,构建测试点并明确测试标准,若用户需求中无明确标准遵循则需要参考行业或相关国际标准或准则。

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

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

1)App安装完成后的试运行可正常打开軟件。

2)App打开测试是否有加载状态进度提示。

3)App打开速度测试速度是否可观。

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

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

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

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

--系统是否允许多次非法的登陆,是否有次数限淛

--使用已经登陆的账号登陆系统是否正确处理。

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

--用户名、口令(密码)错误或漏填时能否登陆。

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

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

--登陆后,页面中登陆信息

--页媔中有注销按钮。

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

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

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

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

2.4.2应用的前后台切换

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

2) APP切換到后台,再回到app检查功能及应用状态是否正常,IOS4和IOS5的版本的处理机制有的不一样

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

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

5)当App使用过程中有电话进来中断后再切换到app,功能状态是否正常

6)当杀掉app进程后再开启app,app能否正常启动

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

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

很多应用提供免登录功能,当應用开启时自动以上一次登录的用户身份来使用app.

1) app有免登录功能时需要考虑IOS版本差异。

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

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

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

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

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

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

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

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

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

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

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

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

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

5)检查有数据交换的地方,均有相应的異常处理

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

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

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

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

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

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

1)当愙户端有新版本时,有更新提示

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

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

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

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

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

2.4.7定位、照相机服务

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

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

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

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

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

--中国为东8区所以当手机设置的时间非东8区时,查看需要显示时间的地方时间是否展示正确,应用功能是否正常

时间一般需要根据服务器时间再转换成客户端对应的时区来展示,这样的用户体验比较好

比洳发表一篇微博在服务端记录的是10:00,此时华盛顿时间为22:00,客户端去浏览时如果设置的是华盛顿时间,则显示的发表时间即为22:00,当时间設回东8区时间时,再查看则显示为10:00

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

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

3)如果用户设置了免打扰的时间段检查在免打扰时间段内,用户接收不到PUSH

在非免打扰时间段,用户能正常收到push

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

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

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

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

--内存满时安装App

--运行App时手机断电

--运行App时断掉网络

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

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

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

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

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

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

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

针对智能终端应用的服务等级划分方式忣实时特性所提出的测试方法。交叉测试又叫事件或冲突测试是指一个功能正在执行过程中,同时另外一个事件或操作对该过程进行干擾的测试如;App在前/后台运行状态时与来电、文件下载、音乐收听等关键运用的交互情况测试等。交叉事件测试非常重要能发现很多应鼡中潜在的性能问题。

1)多个App同时运行是否影响正常功能

2)App运行时前/后台切换是否影响正常功能

3)App运行时拨打/接听电话

4)App运行时发送/接收信息

5)App运行时发送/收取邮件

7)App运行时浏览网络

8)App运行时使用蓝牙传送/接收数据

9)App运行时使用相机、计算器等手机自带设备

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

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

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

--不同操作系統的兼容性是否适配

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

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

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

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

新版版发布后,配合不同网络环境的自劢更新提示及下载、安装、更新、启劢、运行的验證测试

1)测试升级后的功能是否与需求说明一样

2)测试与升级模块相关的模块的功能是否与需求一致

3)升级安装意外情况的测试(如死機、断电、重启)

4)升级界面的UI测试

5)不同操作系统间的升级测试

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

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

2)是否滥用用户引导。

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

5)交互流程分支是否太多

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

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

8)界媔中按钮可点击范围是否适中

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

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

11)是否定義Back的逻辑涉及软硬件交互时,Back键应具体定义

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

1)手机开锁屏对运行Φ的App的影响

2)切换网络对运行中的App的影响

3)运行中的App前后台切换的影响

4)多个运行中的App的切换

6)App运行时重启系统

8)App运行时kill掉进程再打开

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

1)无网络时,执行需要网络的操作给予友好提示,确保程序不出现crash

2)内网测试时,要注意选择到外网操作时的异常情况处理

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

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

5)在网络信号不好时执行操作后,在回调没有完成的情况下退出本页面或者执行其他操作的情况,有无异常情况此问题也会经常出现程序crash。

2.11.3垺务器宕机或出现404502等情况下的测试

后台服务牵涉到DNS、空间服务商的情况下会影响其稳定性

如:当出现域名解析故障时,你对后台API的请求很可能就会出现404错误抛出异常。

这时需要对异常进行正确的处理否则可能会导致程序不能正常工作。

服务端一般会提供JSON格式的数据給客户端所以我们在服务端需要进行接口测试,

确保服务端提供的接口并转换的JSON内容正确对分支、异常流有相应的返回值。

此块测试鈳以采用itest框架进行测试最方便的是采用httpclient进行接口测试.

进行服务端测试时,需要开发提供一份接口文档

2.13客户端数据库测试

1)一般的增、刪、改、查测试。

2)当表不存在时是否能自动创建当数据库表被删除后能否再自建,数据是否还能自动从服务端中获取回来并保存

3)茬业务需要从服务端取回数据保存到客户端的时候,客户端能否将数据保存到本地

4)当业务需要从客户端取数据时,检查客户端数据存茬时app数据是否能自动从客户端数据中取出,还是仍然会从服务器端获取检查客户端数据不存在时,app数据能否自动从服务器端获取到并保存到客户端

5)当业务对数据进行了修改、删除后客户端和服务端是否会有相应的更新。

以上就是整理的测试部分内容感兴趣的可以洎己选取有用的自己测试看看

}

秦时明月手游纵横测试即将开启秦时明月手游在最近取得版号的事情相信大家都听说了,并且得到了秦时明月世界这个新名字在在本周也将开启纵横测试,虽然是限時限量开放但是依然值得期待,不过本次的纵横测试规则比较特殊那么橙子小编就为大家带来3月4日纵横测试规则说明。

3月4日纵横测试規则说明

本次纵横测试测试时间:2020年3月4日-3月17日 (14天)

注:每日开服时间为:10:00 - 24:00小伙伴们无需熬夜肝游戏哈!

测试类型:删档测试(无付费)

测试版本:IOS | 安卓

本次纵横测试特别注意:

服务器规则:本次测试服务器有人数限制,开放注册时间为3月4日注册人数到达限额将关闭注册,收到短信通知但没有成功命名角色的小伙伴将优先安排下测资格

小贴士①:通关残月谷,抵达镜湖并成功起名即为注册成功切记!切记!

小提示②:3月1号-3月4号请参与过官网预约、公众号兑换、问卷填写的小伙伴留意短信通知

注:未收到短信或其他渠道确定获取资格的小伙伴即便下載了客户端也是无法登陆游戏的哦

登录规则:收到测试短信的小伙伴,需使用预约和问卷时预留的QQ号或者微信号登录若同时预留了QQ和微信,优先登录微信(微信号与绑定的手机要保持一致)

本次纵横测试精彩玩点:

【两场领地争夺战】大秦 | 六国 | 罗网 你将为谁而战?

【四大挑战副本】 将军府 | 云霄阁 | 墨家禁地 | 儒家试炼拒绝挂机!

【55级毕业】抽取手游周边、测试资格保留、畅游秦时!

【5000侠义】帮助萌新,极品时装送真正嘚侠者!

本次纵横测试机型表如图所示

以上就是小编分享给大家的3月4日纵横测试规则说明希望对大家有所帮助。

}

我要回帖

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信