没有合适的资源?快使用搜索试试~ 我知道了~
资源来着微信号:关荣之路。本人将9篇文章进行整理,文章详细介绍了产品测试流程,其中许多测试点值得学习,欢迎查阅!
资源推荐
资源详情
资源评论
产品测试规范
1.1 产品测试流程
1.1.1 测试流程图
1.1.2 测试流程说明
1. 需求阶段:
测试人员了解项目需求及需求变更,包括需求规格说明书、功能结构及模块划分,根
据需求梳理测试点。
2. 测试计划阶段:
测试计划环节需要考虑测试工具选取,考虑需要测试的业务点,涉及到多业务量测试
团队测试,需考虑人员分配问题,如:哪些人准备测试执行,哪些人准备测试过程中
数据的收集与整理为后面统一分析做准备。测试环境梳理为测试需要部署哪些应用,
应用是单节点部署还是分布式部署,每个应用分配几台机器进行部署,以及测试工具
及监控工具的部署等。测试数据梳理为测试过程中需要考虑可能用到哪些数据如同时
登陆的场景需要不同的用户,测试翻页功能需要的数据量,通过测试数据梳理能够理
清可能需要编写哪些辅助脚本来进行测试。测试场景梳理为根据选取的测试业务点来
设计需要测试的场景。
3. 测试准备阶段:
代码管理为分为开发代码、测试基线、正式基线等,测试代码应在测试基线中进行即
与开发的代码管理库分离,测试合格的代码才可以分支到正式基线中。测试环境的搭
建工作也需要进行管理,哪些服务器用来搭建哪些应用应当有对应的部署文档以及部
署架构图,即测试环境需心中有数且有文档记录,让人一目了然。测试用例编写可以
根据功能测试框架来进行,覆盖到所需测试的模块以及需求中指出的测试点。测试数
据准备为在系统正式测试前就准备好测试时需要的数据,如移动查单需提前准备好手
机号码用来测试查询。测试脚本准备为测试过程中通过手工无法进行或者效率很低可
以通过代码来实现的环节,如:登录用户的准备,千万条用户性能测试同时登录系统 ,
需要编写 sql 脚本来批量生成用户账号数据,又如:接口测试根据接口测试文档预先
编写好所有的接口测试脚本。
4. 测试执行阶段:
功能测试可以通过传统测试用例测试+探索式测试一起执行,提高测试产品的质量,
性能测试将测试准备阶段准备好的脚本和数据以及部署好的工具,按照写好的测试方
案来进行测试,接口测试按照接口测试方案来运行已编写好的脚本。即让所有的测试
有条不紊的运行,不是想到哪是哪,而且所有的测试不是一蹴而就的,测试过程中需
要进行 bug 的跟踪,指派给对应的负责人,把握项目的测试进度。
5. 测试结果分析阶段:
根据测试的结果、日志收集结果、资源收集结果、异常跟踪结果等汇总分析生成测试
分析报告并给出可行性的建议,如果涉及到调优工作,还需对调优结果进行验证,需
要对上线的风险进行评估。
6. 上线准备阶段:
测试人员需要准备线上测试需要用到的数据,需结合生产环境进行,如系统生成订单
测试环境是不需要 uim 卡号的,但是真实的线上环境需要用到 uim 卡号,这就需要提
前准备好线上测试的数据。上线准备需要提供测试合格的发布资料(包括:发布包、数
据库脚本、用户手册、部署文档、维护手册等)、还需要考虑好回滚方案。
7. 上线后测试跟踪阶段:
可以持续构建接口自动化,快速进行一轮接口测试,保证常规接口正常运行,功能测
试可以根据测试用例+探索式测试来进行,如果是更新补丁等,需要重点对上线更新
的功能进行验证测试,当然测试过程中必不可少要进行 bug 的跟踪。
8. 项目总结阶段:
对于项目整体的质量做总结分析,给出总结报告,测试人员需要根据每次的测试、上
线等积累符合项目的 bug 预防体系,总结项目经常出现 bug 的种类、位置、以及可以
提出针对性的规避措施,提高产品质量。
1.2 需求梳理
1.2.1 需求梳理
根据需求文档、需求规格说明书来对需要测试的功能点进行梳理,而且通过需求文档
能够更加了解项目的业务场景,一般情况下,在项目中需求文档有 3 种现状:
1. 有详细的需求文档:
比较严谨负责的团队项目的实施是有详细的需求文档的,我们就可以详阅需求文档来
进行测试点的梳理工作,对于需求中你认为不明确的地方可以找项目领导人进行沟通,
做到对需求整体把握和理解,利于测试更好的进行。
2. 需求文档不明确即有文档但是文档很粗糙:
一般有两种办法,如果开发团队很配合,可以要求开发或者需求分析人员完善需求文
档,如果因为各种原因比如时间紧张或者开发就是不愿意,那么就需要自己去沟通对
于文档中不明确的点问清楚,切记不要含糊不清的测试,于人于己都没有好处。
3. 没有需求文档:
如果你运气很不好遇到了,虽然我很同情你,但是貌似同情没啥用,我们知道做测试
很重要的一点是:我有一个预期,我要把软件运行的实际值跟我的预期去比对,如果
达到了预期,那么就没问题,如果跟预期不一致那就是有问题。那么如果没有需求,
我们该怎么办:
第一种靠嘴去问,大家去协调,协商沟通,然后大家都回答没问题了,我会自己写一
个概要的需求描述,然后让他去确认,他说可以,那咱们就这样测,有问题就不断的
口头沟通;
第二种要基于用户使用的场景和行业的经验来去做判断它是不是合理的。
1.3 测试计划
1.3.1 测试工具选取
测试工具说明:
以上列出了自己在测试过程中所用过的一些工具,每种都有自己的利弊和自适应的测
试场景,可以进行参考和根据实际需求来进行分析选取。
1.3.2 测试人员分配
测试场景敲定以后,对于大业务量的测试工作或者团队合作测试的任务需要分配好各
自的任务,让大家各司其职,如:测试环境梳理和搭建人员、测试数据准备人员、测
试脚本编写人员、测试执行人员、测试日志收集人员、测试结果汇总分析人员,每个
人可以负责一个模块或者多个模块,更甚者有的项目任务量不多,一个人搞定这么多
部分也是大有人在,即一个人搭建环境、一个人准备数据写测试用例准备测试、收集
日志进行分析,这对测试人员的要求比较高才能更好保证产品的输出质量。
1.3.3 测试业务场景选取
根据需求说明文档,梳理需要测试的业务点和场景,比如应用系统的性能测试,需测
试 nginx 负载节点的性能情况,是否可支撑 1000/s 的业务能力,极限环境下支撑 2
万/s 并发,节点接收报文常规为几 byte,大报文可达到 8k,节点支持分布式部署。
则我们根据这些信息可以梳理我们需要测试的场景有:直接压测一台节点观察性能峰
值、nginx 负载一台节点的性能、nginx 负载两台节点的性能、nginx 负载三台节点
的性能、报文场景为 500 字节、1KB、8KB、并发数为依次递增至 1500 并发(保证
1000/s 并发是否可以),看是否满足常规业务处理能力,极限测试下并发数为 2 万,
测试 7*24 小时,观察极限处理能力。
1.3.4 测试环境梳理
根据测试场景以及梳理的被测系统、压力系统、压力机情况、给定的服务器数量,绘
制测试环境搭建图谱即每个应用系统搭建数量、各节点所在机器,如下图梳理了整个
系统部署的流程及每个应用、监控工具、测试工具应该部署的机器情况,让人一目了
然。
1.3.5 测试数据梳理
这里的测试数据内容很广,可包括测试准备和测试执行阶段所需要的一切数据来源,
如:测试脚本、测试参数化文件、测试账号、辅助性测试程序等,即让测试工作更加
有条不紊的进行,而不是等到测试时才发现这个东西要去找,那个东西又没有弄得自
己手忙脚乱,降低测试效率。比如,下面是一段造数据的存储过程脚本:
剩余32页未读,继续阅读
资源评论
lovely_xyx
- 粉丝: 0
- 资源: 1
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功