【测试沉思录】5. 测试人员如何快速熟悉新业务?
欢迎订阅我的新专栏《现代命令行工具指南》,精讲目前最流行的开源命令行工具,大大提升你的工作效率。
作者:陈爱娇 编辑:毕小烦
身处职场,学习新业务在所难免,尤其是测试人员,具备良好的业务知识是我们做好质量保障的前提,不管是职场「新人」还是「老人」,快速熟悉业务的能力都是不可或缺的,这是我们安身立命的根本。
但,这样的能力并不是很显性,笔者有着十几年的测试经验,负责过 C 端、B 端和 G 端的业务,本文尝试梳理出一些快速熟悉新业务的方法,希望能够带给大家一些启发。
有两种学习模式
在学习新业务时,通常有两种模式:
- 授课式: 老师/师兄/师姐带着你学习,言传身教划重点,苦口婆心加考试;
- 自学式: 自己看一堆的学习资料、测试沉淀、业务文档,有问题再找人问;
授课式是被别人带着走,自学式是按自己的方式走。从人性的角度来讲,显然有人教更好,也更快,直接告知重点,躲避深坑,有老师傅带着一路过关斩将,打怪升级,✌!
可事实上,专家没那么多,也没那么闲。因此,大部分情况下,我们都处于第二种:自学式, 师傅领进门,修行在个人,按自己的方式学习,方法就尤为重要了。
要学会打怪升级
当个人修行时,学习跟打怪升级似有异曲同工之处。
不停重复打怪的过程,就是积累经验的过程。业务中的新怪层出不穷,都带有新的技能,那么,要想打败它,就得提升自己的技能。不同级别,你面临的怪是不同的,晋级之后,再遇新怪,我们总要问一下: 这是个什么? 我要怎么打败它?打败它之后,我会获得什么技能?
这很像保安师傅的哲学三问: 你是谁?从哪儿来?到哪去?
如果是唐僧,他会这样回答:贫僧法号三藏,自东土大唐而来。要往西天取经去。
如果是我们的「新业务」,应该思考的更多一些:
- 你是谁?
- 新业务是什么?在公司那么多产品里面处于一个什么样的位置?前台?中台?后台?
- 它依赖谁?谁依赖它?它面向的用户是 B 端?C 端?还是 G 端?
- 它的产品形态是 APP?小程序?网站?H5?PC客户端?公众号?还是接口?
- 从哪儿来?
- 为什么会有这项新业务?它的定位是什么?
- 价值是什么?衍变路径是什么?
- 到哪里去?
- 新业务的目标是什么?
- 发展路径是什么?
- 阶段性目标是什么?
所以,学习新业务就像打怪升级,搞清楚这三个业务背景问题,会让你接下来进入业务细节更加胸有成竹。
熟悉业务三部曲
1. 看懂业务:由表及里
① 看功能:从直观的角度来看,新业务展现的产品功能和业务规则是什么?
比如电商大促,各种优惠商品直接打折降价,再叠加平台的满减活动,再叠加 88 会员的折扣等等,你首先得理解这些产品功能和业务规则。
② 看结构:从业务的结构来看,新业务在公司的整个业务板块中处于哪一层,它依赖的上下游业务是什么?
③ 看细节:从产品的细节来看,每个操作步骤都会包含很多的系统交互。
比如上面提到的优惠业务,包括了:单品优惠、商家优惠、平台优惠。 那么大促期间,这些其实是混合在使用的,每一种优惠都会有不同的应用场景; 那么,每一种优惠它的操作入口, 它涉及到的交互系统有哪些, 他们通过什么接口进行交互等等,都是要去熟悉和学习的。
④ 从用户角度看:不同的用户对产品的功能会有不一样的诉求,也决定了我们在进行业务测试的时候,除了业务的准确性外, 测试重点也不同。
比如电商大促, 对于招商系统而言,它是 To B 的业务,主要的诉求在于:系统稳定、便于操作,用户量可能在百万级别, 用户的主要使用场景是通过 Web 端来操作;
对于交易系统而言,它是 To C 的业务, 主要的诉求在于:系统稳定、实时性要求高(各种优惠及时更新、库存更新等)、并发量高,用户量在千万及亿级别,用户的主要使用设备是通过手机 APP 端来操作;
当了解我们的用户人群后,在做基本的业务功能验证后,还需要验证非功能性的需求,比如高并发如何保证系统的可靠性, 比如大促期间的实时性(库存、优惠等),如何来保证准确性?不同的客户端,需要做哪些兼容性验证?
⑤ 从业务价值看: 谈业务价值,其实就是谈我们这块业务存在的目的,它能带来什么价值,它的目标是什么?是补充公司的业务空白,扩大商业版图,还是为公司增加营收。
当一个产品的目的是为了快速占有市场, 那么,我们就需要快速迭代, 测试的侧重点,就会在效率上,如何在保证质量的基础上,快速发版, 可能会忽略一些并发性,或者是用户体验的功能; 如果是一个稳定的业务,比如电商大促,这么几年走下来,它就是个稳定的业务,那如何提升用户的体验,保证实时性,就会成为我们的测试重点;
⑥ 从盈利模式看:在资本市场中,不盈利的产品很容易就被淘汰掉。
我们要熟悉的新业务的盈利模式是什么?是卖产品?卖服务?还是卖广告?于测试人员而言, 根据不同的盈利模式来进一步了解产品的价值,反向驱动我们去思考业务的测试重点,这是一件很有价值的事情;
2. 看透业务:系统剖析
看懂业务之后,我们需要看透业务,通过解剖系统来加深对系统的理解。
在这个过程中, 我们需要了解到:
- 所负责业务的系统交互: 系统如何和上下游系统交互,这种更直白的是,看一下时序图,清晰的了解各个系统之间是通过什么接口进行交互的,交互的出入参是什么? 带着业务验证的目的来了解系统;
- 系统内部各个模块的划分,哪些是公共模块,哪些是业务实现层?
从上面俩张图都可以看出应用中各个模块所承担的功能,以及一些公共的服务及流程,我们所负责的业务流程是不是也是这么走的,一旦改动到公共模块或者公共服务的话,我们除了验证当前的业务流程外,还需要验证哪些关联流程;
- 数据流向怎么走? 数据如何变更?
每一条数据都有它存在的意义,每一个字段都有它的特定含义,不同的表代表不同的含义,不同的字段也有不同的业务逻辑。 我们需要将业务流和背后的数据流关联起来,以便更好的理解每一次的数据变更,更好的为后续做功能测试打下基础,知道哪些是关键验证字段, 避免功能场景遗漏。
如果很有幸,你一进来,跟进的就是一个纯新的系统,从需求到方案设计到系统上线的话,那你真的很幸运,可以从头了解这个系统的搭建,按上面的方式来了解你即将负责的系统及业务;
假如你负责的是一个老的业务系统,要在老的系统上做迭代,那么, 你仍然可以遵循上面的 3 个方面来梳理你对业务的理解。同时,找历史资料,找资深的同学来了解系统架构、系统模块功能、数据流等, 请多问、问、问!
这个阶段,还有一个问题没讲:问题排查的方案及手段,这些内容接下来我们会讲到。
3. 看好业务:动手实践
在看懂业务、看透业务之后,我们就需要履行本职:看(kān)好业务了,假设我们要独立测试这块业务,要怎么测试,怎么设计测试用例,用什么方式来进行测试,如何验证功能的准确性,遇到错误,如何排查呢?
基于上述问题,我们需要做的事情:
- 测试用例设计: 基于产品的 PRD,研发的设计方案及我们自己对系统的了解、时序图等进行用例设计,考虑基本的:正常流、分支流、异常流三类。 对于本次的改动范围要评估是否需要做老功能的回归, 对于一些新增的开关、或缓存等,要做对应的专项验证;
- 测试方法: 手工验证 or 自动化验证?
- 数据准备: 是否已有现成的工具或脚本可以快速生成测试数据? 如果没有的话,怎么造测试数据? (造数据的过程?)
- 结果验证: 业务展示是否符合预期,DB 中的数据是否符合预期?
- 是否需要做非功能性验证: 兼容性、安全性、性能压测等;
- 问题排查: 遇到问题,如何排查?(定位根因,积累经验的最快速的方法)
- 系统现象: 页面报错、服务调用失败等这一类都是直观的展示,还有一类是流程链路比较长,看起来页面都是正常的, 但是 DB 数据不符合预期,会导致下一个环节报错的场景;
- 日志排查: 根据业务操作,看下后台日志访问,有无错误日志打印,日志告诉你错在哪一行,根据日志的错误提示,去对应的分支代码中查看对应行的代码;
- 数据排查: 根据数据反查, 根据你对系统的了解, 梳理哪里会涉及到这块 DB 数据的变更,反查回去看看具体的代码逻辑,看具体走到哪个分支里去,再参照对应的系统日志,跟踪定位到具体的出错的代码行;
- 翻看代码: 不管是从日志排查还是根据数据排查, 都需要去翻代码看看, 有时候,这一行报错,不是因为这一行有错,而是中间过程中,由于入参问题,导致走到其他分支了,这种时候就需要深究下去,到底是从哪里开始出错。
于测试人员而言,不一定要完整的定位出根因,但是希望通过这样的排查过程,对系统的实现有所了解,在后续的业务改动中,也能够了解到改动影响的范围,有自己的判断,而不是等待他人的输入。
当我们能完整的走过上面的三步,再回过头来看业务,可能会有一种恍然大悟的感觉,会有一种“原来如此”的感悟。 但我们可能仍然只是处于刚入门的阶段,后续需要通过不断的重复、加深记忆的过程来不断的完善我们对业务的了解。
我们的脑海中对业务的构建,是不断具象的过程,其实,也可以同步思考下:我们原来的测试模式有没有可以优化的地方? 我们有哪些步骤是可以通过工具化的手段来实现的?假设要你来做一个提效的工具或者要提升你负责模块的项目质量, 你会从哪些方面入手,你需要做哪些的知识储备。。。等等,通过不断深入业务,深入系统,深入思考,才能更好的激发创意,为工作带来持续的正反馈!
总结
新业务的学习,是一个不断积累的过程,只有在经过不停的学习、实践、问题排查,这样的重复之后,才能加深我们对业务的理解。随着对业务知识、系统架构等方面认知的提升,也能反哺我们对业务的理解,从而达到陌生到熟悉的进化。
最后,再送大家一句话:好记性不如烂笔头,随时记录,思考,梳理,重构,会有惊喜噢!
如果文章对你有帮助,记得留言、点赞、加关注哦!
(完)
【测试沉思录】5. 测试人员如何快速熟悉新业务?相关推荐
- 推荐必读:测试人员如何快速熟悉新业务?
身处职场,学习新业务在所难免,尤其是测试人员,具备良好的业务知识是我们做好质量保障的前提,不管是职场「新人」还是「老人」,快速熟悉业务的能力都是不可或缺的,这是我们安身立命的根本. 但,这样的能力并不 ...
- 测试员入职新公司如何快速熟悉新业务?
身处职场,学习新业务在所难免,尤其是测试人员,具备良好的业务知识是我们做好质量保障的前提,不管是职场「新人」还是「老人」,快速熟悉业务的能力都是不可或缺的,这是我们安身立命的根本. 但,这样的能力并不 ...
- 测试人员如何快速熟悉产品业务
针对人员 软件测试行业小白.业务短板群体 针对项目中问题点 1.项目中完全就没有统一标准的文档可查阅 2.项目中文档内容缺失不规范或(产品人员时间上紧迫)文档更新不同步 以企业管理学习系统为例,系统大 ...
- 【测试沉思录】18.如何测试微信小程序?
作者:雷远缘 编辑:毕小烦 一. 先知道小程序是什么 啥是小程序? "小程序是一种不需要下载安装即可使用的应用,它实现了应用 "触手可及" 的梦想,用户扫一扫或者搜一下即 ...
- 研发新人如何快速熟悉新项目和业务
进入一家新公司后,最头疼的就是如何快速了解公司的业务和项目架构. 如果碰到一个特别热心的老员工,事无巨细地给你讲,随时在你身边答疑解惑,那可能还好.但很可惜,我没有碰到这样的人,在加入新公司后,带我的 ...
- 【测试沉思录】2. 如何保障需求质量(下):你应该做到的
欢迎订阅我的新专栏<现代命令行工具指南>,精讲目前最流行的开源命令行工具,大大提升你的工作效率. 上一篇文章我们介绍了保障需求质量需要知道的一些基本内容,接下来,我们看保障需求质量的具体措 ...
- 【测试沉思录】17. 性能测试中的系统资源分析之四:网络
作者:马海琴 编辑:毕小烦 计算机网络,就是通过光缆.电缆.电话线或无线通讯将两台以上的计算机互连起来的集合,包括广域网.城域网.局域网和无线网. 计算机网络是传输信息的媒介.我们常说的千兆网,是指网 ...
- 【测试沉思录】22. 前端性能测试怎么做?
作者:张丹青 编辑:毕小烦 普通用户如何评价一个网站的体验好不好呢? 除了满足他的功能需求以外,用得爽不爽可能是最大的评估因素.这个爽不爽可以简单理解为快不快,好不好看,是不是符合他的操作习惯等等.而 ...
- 【测试沉思录】1. 如何保障需求质量(上):你应该知道的
欢迎订阅我的新专栏<现代命令行工具指南>,精讲目前最流行的开源命令行工具,大大提升你的工作效率. 每个测试人员都知道保障需求质量非常重要,那到底为什么这么重要?又如何来保障需求质量呢?如果 ...
- 【测试沉思录】11. 如何进行基准测试?
欢迎订阅我的新专栏<现代命令行工具指南>,精讲目前最流行的开源命令行工具,大大提升你的工作效率. 作者:刘洪初 编辑:毕小烦 基准测试(benchmarking)其实就是一种性能测试,只不 ...
最新文章
- linux查看文件安全权限,Linux系统下如何查看及修改文件读写权限
- 实现框架页面iframe的背景透明方法
- Record和PL/SQL表
- 从 保龄球得分计算方法 浅析 深度学习
- ttf能改成gfont吗_中国废弃轮胎,被非洲人买去做成凉鞋!15元一双,至少能穿10年...
- oracle report builder 6i下载,oracle report builder 6i - 数据模型中的SQL查询代码
- web安全之CSRF
- rust盖错了怎么拆除_细说Rust错误处理
- 信息学奥赛C++语言: 将字符串中的小写字母转换成大写字母
- linux脚本awk,如何在awk脚本中使用shell变量?
- C语言异常处理之 setjmp()和longjmp()
- DevExpress中XtraGrid控件对GridView每行的颜色设置 zt
- NYOJ 取石子总结
- SQLiteDev与.NET日期格式,该字符串未被识别为有效的 DateTime
- 纯电动两档箱实际项目模型,本模型基于Cruise软件和搭建完成,本资料包包含所有源文件
- 怎么安装64位JAVA,大师来详解
- html 向左箭头图标css,使用css实现箭头图标
- vue父与子组件,子与子组件间的方法调用和通信
- win10 cortana 搜索失效
- HTML5期末大作业:电影在线网站设计——漫威电影(2页) 免费大学生网页设计制作作业作品下载dreamweaver制作静态html网页设计作业作