TA的每日心情 | 无聊 昨天 09:12 |
---|
签到天数: 517 天 连续签到: 4 天 [LV.9]测试副司令
|
集成测试
按照模块上下集关系,进行从上到下或者从下到上的集成测试方法进行集成测试,单元测试与集成测试主要考虑功能性测试。同时也要对模个模块或者集成模块进行非功能性的抽样测试。
系统测试
对整合系统进行整合测试,这时的测试主要测试系统的整体功能和全部非功能性的需求。
测试的主要工作
测试人员的工作开展是在需求下发后,需求下发后,测试人员要先熟悉需求,根据需求设计文档设计相关的测试案例,测试案例需要覆盖所有业务场景,包括功能方面以及业务方面的。
测试案例设计
(1) 首先针对页面的功能设计功能测试案例,常见的方法有:等价类划分方法、边界值分析方法、错误推测方法、因果图方法、正交实验设计方法。
(2) 充分掌握业务知识,业务流程以及业务的数据流向。站在用户的角度思考,而不仅仅考虑在系统中如何操作业务流程;搞清楚每一项业务中的详细流程和各个环节涉及的角色,一项比较复杂的业务其详细流程往往比较多,只有了彻底掌握了这项业务,才能对当前业务环节进行全方位的测试,才能设计完整的测试案例。
(3) 从需求人员或者客户那里了解到各业务流程的重要程度和使用频率。(这点对把握测试重点很重要),设置好用例的优先级
(4) 了解业务流程在系统中对应的功能。(建立业务与系统的映射,为编写测试用例做好准备)
(5) 绘制业务流程图(对于较简单的流程,也可以用文字描述的形式,但流程图比较直观,也便于进行路径的分析)。
测试执行
测试过程中主要分成两种类型,一种是系统的功能性测试,一种是对需求实现的业务流程测试。
功能测试
(1) 页面链接检查,每一个链接是否有对应的界面
(2) 相关性检查,删除/增加一项会不会对其他项产生影响,如果产生影响,是否正确
(3) 检查按钮功能是否正确
(4) 字符串长度检查,输入超出需求所说明的字符串长度的内容,看系统是否检查,会不会出错。
(5) 字符类型检查
(6) 标点符号检查
(7) 中文字符处理,乱码或出错
(8) 检查带出信息的完整性,在查看信息和update信息时,查看所填写的信息是不是全部带出,带出信息和添加的是否一致。
(9) 信息重复,在一些需要命名,且名字唯一的信息输入重复的名字或ID,看系统有没有处理,重名包括是否区分大小写,以及在输入内容的前后输入空格,看系统是否处理。
(10) 检查删除功能,在一些可删除多个的地方,不选任何内容按删除按钮看系统如何处理
(11) 选择一个或多个时又如何处理
(12) 检查添加修改是否一致,检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.
(13) 检查修改重名,修改时把不能重名的项改为已存在的内容,看会否处理,报错,同时看会否报和自己重名的错。
(14) 重复提交表单,一条已成功提交的记录,back后在提交,看系统是否进行处理。
(15) 检查多次处理back键的情况
(16) Search检查:在有search功能的地方输入系统存在和不存在的内容,看结果是否正确;
(17) 如果可以输入多个search条件,同时可以添加合理和不合理的条件,看系统是否处理正确。
(18) 输入信息的位置,输入信息时,光标的位置
(19) 上传和下载文件的检查,上传下载的功能是否实现,上传文件是否能打开,上传文件的格式规定,系统是否有解释信息。
(20) 必填项检查,必填项是否有提示信息
(21) 快捷键检查,是否支持常用快捷键检查
(22) 回车键检查,在输入结束后直接按回车键,看系统处理如何,会否报错。
业务流程测试
业务流程测试是测试人员把系统各个模块连贯起来运行、模拟真实用户实际的工作流程,满足用户需求定义的功能来进行测试的过程。
业务流程测试过程中可以通过以下几点:
(1)站在用户的角度:优秀的需求应该是站在用户的角度来思考问题,是用户能够利用系统完成什么,而不是系统自己完成。因此在需求理解时要多和App的最终用户进行交流,了解他们的诉求,以便有针对性的进行测试。
(2)重视业务的连贯性,整个业务流程:尽可能全面的收集需求要点、了解整体的业务流程、分析主体业务流程和重点业务流程等,将整个业务流程全量进行测试。
(3)相关联业务测试:工作上业务实现过程中,有可能会影响到相关联的业务,在进行当前需求的业务流程测试时,需要对相关联的业务进行测试。
缺陷管理
App测试的主要目的在于发现App存在的错误(Bug),对于如何处理测试中发现的错误,将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误,才能消除App错误,保证要发布的App符合需求设计的目标。在实际App测试过程中,对于每个Bug都要经过测试、确认、修复、验证等的管理过程,这是App测试的重要环节。
Bug管理的流程
(1) 测试人员提交新的Bug入库,错误状态为New。
(2) 高级测试人员验证错误,如果确认是错误,分配给相应的开发人员,设置状态为Open。如果不是错误,则拒绝,设置为Declined状态。
(3) 开发人员查询状态为Open的Bug,如果不是错误,则置状态为Declined;如果是Bug则修复并置状态为Fixed。不能解决的Bug,要留下文字说明及保持Bug为Open状态。
(4) 对于不能解决和延期解决的Bug,不能由开发人员自己决定,一般要通过某种会议(评审会)通过才能认可。
(5) 测试人员查询状态为Fixed的Bug,然后验证Bug是否已解决,如解决置Bug的状态为
(6) Closed,如没有解决置状态为Reopen
基于全球首创的对象识别技术,TestBird可以为客户提供深入到移动App&游戏内部所有功能的深度解析能力。通过自助App功能测试、远程真机调试、真机兼容性测试、真人体验测试、 真人压力测试和崩溃分析等产品,TestBird建立了云手机、云测试和云分析三大测试平台,为移动应用提供从研发到上线再到运营的一站式质量管理服务,帮助移动应用企业建立完善的质量管理体系和能力,全面提高移动应用的DAU、留存率以及付费情况。
|
|