测试方案参考

Posted 杨不羁

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了测试方案参考相关的知识,希望对你有一定的参考价值。

测试方案需包含项是否必选说明或模板
可测性需求准备必选所有有可能影响到功能测试, 接口自动化, UI自动化的项目, 例如暴露内部接口, 前端添加id, 测试账号准备, 域名映射等
需要提前要求开发对代码进行修改和准备.
了解其他角色计划和人力安排必选    需要对方邮件或文档告知项目交付计划和里程碑
    需要和负责的产品经理沟通上线时间点和紧急程度
    需要和研发负责人确认日常工作的沟通渠道和频率
编写测试计划(里程碑管控)必选所有1.0项目启动需要根据项目里程碑管控表对项目总体进行计划:1.0项目里程碑管控总表
并且明确核心迭代、增量迭代1、增量迭代2卡片的明确提测时间点,以及P0 bug的修复时间
质量分级(功能点优先级划分)必选根据目前的人力情况,进行功能点质量的重要程度划分,进行不同的质量保障:质量分级指南
自动化脚本编写必选所有1.0项目都需要在项目开始以后, 根据测试计划进行自动化脚本编写
基本的目标是core迭代接口完成100%自动化, 主干流程P0功能完成40% UI自动化
根据不同项目的不同性质, 后续的自动化覆盖率参考下面文档:
自动化基本策略及成熟度定义
并发性测试可选所有接口都需要开发在提测时按照下面条目进行评估, 如果满足, 并且有潜在并发性风险, 需要提请测试组进行并发性测试

1.是否使用了多线程/线程池
2.使用的集合会不会有多线程进行增删改查, 是否已改为使用线程安全集合(List, Set, Map, Queue)
3.设计的类有没有单例和多例的使用要求
4.使用了哪些锁,为什么要使用,完成了什么功能
5.接口是否有幂等性要求,前端是否屏蔽了重复提交
6.是否使用了MQ,如何确定消息发送数和接收数匹配
7.是否使用了redis,es,hbase缓存数据, 是否和数据库数据有同步问题.
性能测试必选需要产品和开发评估, 是否在实际使用中有大并发量的访问场景, 如果有, 需要提请测试组进行性能测试安排
权限、角色测试必选 
浏览器兼容性测试可选,Web端项目必选同一个web应用, 前端的展示或一些特定的功能在不同的浏览器上有可能有不同的执行结果,
为了避免使用不同浏览器的用户产生异常, 需要使用主流浏览器进行兼容性测试
手机端兼容性测试可选,移动端项目必选由于手机app在不同的手机机型上运行会有很多的不可预测的问题,
需要大面积的对所有主流机型机型回归测试.
用户模拟使用测试可选,2C项目必选上线前, 需要和业务部门(或者产品经理)研究讨论最终用户的使用习惯,
制定出上线当天用户最有可能的几种使用方式, 提前在上线后模拟测试,
最终用户试用测试可选上线切量前, 未避免一次性大规模用户进行新系统使用时, 因为每个人的使用习惯和系统的千差万别,产生比较特殊的bug, 建议通过安排用户试用的方式,逐步切量
健壮性测试必选长时间使用型应用最初使用时可能不会有异常, 但连续多天或超过几周进行运行时,
很小的一些内存泄漏或者数据存储会慢慢累积成系统失败或者崩溃的条件,所有需要对这类应用进行健壮性测试
项目功能使用频率: >6小时/天 >1次/30分钟
运行时间至少3-5天, 持续对主干流程接口或UI界面进行访问
三方联通性测试可选,和第三方系统对接型项目必选提前了解第三方系统的服务器和网络部署情况, 实验我方服务器(测试, 预发, 生产)和对方的连通性, 比如接口相互调用情况, 是否可以访问对方的Redis, MQ, ES等(如有应用场景), 如果有连通性问题, 需要确认部署方案或者提前申请网络专线
设备部署测试可选,特需项目必选如果项目对除浏览器, 手机以外, 还需要其他设备支持, 如耳机, 话筒, 电视, 平板, 摄像头等, 需要提前进行设备申请, 并且安排进行设备可用性或连通性测试
部署环境验证测试可选,对部署环境有特殊需求的项目必选如果项目对代码部署的环境有特殊需求, 比如不是部署在部门常用的环境中, 如公开云, 私有云, 甲方机房, 电信/联通机房等, 需要提前安排人手熟悉第三方环境的使用方式, 必要的时候需要到现场进行试用, 提早在新环境中进行项目部署实验.
收集所有使用方和对接安排可选,中间件类项目或底层项目必选对于这类项目如: 登录类, 网关类, 消息转发类, 基础信息提供类,
需要提前和所有使用方确认他们的对接安排时间点, 是否有延迟对接风险, 对于高优先级对接项目, 需要和对应测试确认测试方案,自己也需要拟定对接时的测试用例,分发给各项目测试负责人
数据比对测试可选,数据统计及报表类项目必选准备性能测试时, 为性能测试脚本准备准确的模拟数据
在运行性能测试时, 分段暂定测试, 比对发送数据和统计数据的数量区别, 观察第三方软件如MQ, redis ,ES中的数据条数和总额
在完成测试后, 对总测试数据和统计数据进行比对
接口测试及自动化可选    严格要求前后端开发对接口文档进行评审, 如果没有评审的情况下, 后端开发交付的接口不建议开始测试
    有完整接口文档的情况下, 可以增加对接口的自动化脚本编写覆盖率(正常core迭代接口覆盖->所有提测的接口覆盖)
    需要有完整的原型文档, 提前了解实际的UI界面, 做到和前端/产品对需求细节达成一致, 当前端开始提测时可以快速入手

以上是关于测试方案参考的主要内容,如果未能解决你的问题,请参考以下文章

测试方案参考

测试方案参考

app测试

app测试

一个小攻略:如何最大化利用青云QingCloud 特价机型

electron打包后win7部分机型打不开的一些优化