从零开始学产品第六篇:更强大的测试,自动化测试和性能测试

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/jnshu_it/article/details/84431123
本篇为【从零开始学产品】系列课第1章第5节

欢迎到公众号菜单栏,获取产品经理课程更多资料

测试就是拿点鼠标在电脑上瞎点,或者是用手机随便戳几下么?”

“不,是有计划有意图的测试,比如说,边界测试,随机测试,端到端测试等等。”

明白了,是有计划有意思的瞎点点?”

“.........好吧,也可以这么说,但是随便瞎点点并不是测试的全部:

点哪里,不点哪里,是需要对业务逻辑了解很深入的。”

但它还是瞎点点,对不对?有没有比瞎点点更厉害一点的?”

“emmmm,有,就是自动化的瞎点点和大规模的瞎点点。”

第一章 从木牛流马说起

“懒是推动人类进步的第一动力。”

刚哥写完了一个Windows脚本的批处理程序之后,笑着说。

这个批处理程序很简单,就是切换开发环境,测试环境和线上环境的Host文件,以便本地开发的时候可以直接切换环境。

通常我们都是手动拷贝,更改名字,但是对于熟读《程序员晋级手册》的刚哥来说:

但凡可以重复执行的事情都可以自动化”给了他启发

所以他花了5分钟的时间写了一个脚本,只需要执行脚本就可以自动切换了。

而诸葛大神也是同样的,很早就希望能够“自动化”的做一些事情。

木牛流马(诸葛亮发明的运粮工具)

木牛流马,为三国时期蜀汉丞相诸葛亮发明的运输工具,分为木牛与流马。
史载建兴九年至十二年(231年-234年)诸葛亮在北伐时所使用,其载重量为“一岁粮”,大约四百斤以上,每日行程为“特行者数十里,群行三十里”,为蜀汉十万大军提供粮食。
不过,确实的方式、样貌现在亦不明,对其亦有不同的解释。

不管是真是假,做一些自动化的事情,总是让人乐此不疲。

对测试而言呢?

为什么也需要自动化的测试,又是怎么自动化的。

通过前几章的学习,我们知道了,正常的系统都会有开发,测试和线上三个环境。

测试人员的工作场所就是在测试环境,而Bug的出现,有可能是在测试,也有可能是在线上。

这个看起来很完美的流程其实缺少了一个关键的环节,也是很少被人提到过的。

就是我们总是会持续不断的维护一个项目,这个叫做项目的迭代更新。

在项目的迭代更新过程中,会发什么不一样的情况么?

修真院的开放同学花了一周的时间,终于修复了7个Bug,他开开心心的打了版本号,发布到了测试环境。

测试小姐姐苗苗同学,验收了这些Bug,确认没有问题,就申请发布到了线上环境。

修真院的用户晚上熬夜比较多,所以发布一般都选在清晨7点。

发布之后,按照我们的发布流程,苗苗和开放验证了自己修复的Bug,确认没有问题,就开开心心的补觉去了。

然后9点之后,用户陆续挣脱了被窝的封印,逃出了住宅的魔爪,开始使用官网。

然后,他们发现修真院官网中的一个很重要的“评论”功能无法使用。

发生什么问题了?

定位问题有很多种,但是早上的发布无疑是嫌疑最大的。

定位问题之后快速回滚,评论正常。

最后的结论是,开放同学在修复原来的Bug过程中,不小心改动了之前关于评论的代码,造成评论功能不可用。

为什么会出现这种情况,做为一个非技术人员,有时候很难理解。

在他们眼里,研发团队总是会出现莫名其妙的问题:

总是修复了一个Bug,引起了另一个Bug

或者是这个版本没有问题了,下个版本又复现了。

但解决问题的方案总是有两种:

一种是研发团队提高自己的技术水准,尽可能的避免高耦合

另一种就是,能否有办法提前在测试环境发现问题?

这就是所谓的回归测试。

回归测试的难点在什么地方呢?

一个系统维护了近两年,数百个功能点算是比较正常的。

把这些功能点全部做一遍回归测试,需要多久呢?

每发布一次版本,都要全部做一遍回归测试么?

没有问题,就没有解决方案,有了问题,就自然会有解决方案。

第二章 自动化测试的天下

所以我们把遇到的问题抽象出来:

“我们希望找到一种自动化测试的方法,可以将过去的测试用例而顺序执行一遍,来确认之前的功能可用性

这可以节省测试人员大量的时间,提高发布的效率和确保测试的严谨度。”

再来看什么是自动化测试。

如果你经常玩网游,你会发现网游现在越来越有意思的是,前十分钟可以升很多级,然后剩下的就是各种刷刷,没什么难度 ,就是耗费时间而已。

想要节省时间,可以充值去加快进度。

如果你不想充值,反正时间多的是,但是又不想重复的点击怎么办?

【键盘精灵】,你需要一个键盘精灵,让键盘模拟你的电脑或者是手机的操作,无脑挂机刷。

怎么实现的?

其实道理很简单,记录你鼠标或者是手势的位置,和操作,相当于录制屏幕一样。

这就是自动化测试的最简单的方式。

自动化测试可以通过编写脚本来完成一些【键盘精灵】相似的操作。

简单说,你可以做一些简单的游戏外挂了。

但是对于测试这个神圣的职业来说,并不是用来做游戏外挂,而是用来做回归测试,这个利器就叫做:

selenium

selenium最简单的自动化测试就是录制。

点录制按钮之后,可以记录下来你的动作,然后重放。

除此之外,你如果想要做更多的和更深入的操作, 就需要懂一点编程。

自动化测试,其实仍然存在着很多问题。

比如说,一旦需求变更,自动化测试的脚本就必须跟着改。

这对于测试人员来说,也是一件压力很大的事。

特别是对需求更新频率的互联网公司来说,更大的可能性是每周一遍,很多功能是无法做自动化测试的。

而相对稳定的功能,自动化测试的意义也不会特别大,基本上模块都比较清楚了:

有改动的地方可以通过开发人员和测试团队有意识的测试来完成。

所以要不要用自动化测试,用到什么程度,由你来决定。

 

第三章 性能测试的归属

做为测试的收尾一章,还要讲最后一个很重要的性能测试。

测试整体来讲,可以分成三大部分,功能测试,性能测试和自动化测试。

自动化测试重不重要,说不好,大家各有自己的见解,实际情况不一样,也没有办法。

性能测试一定是非常非常关键的测试。

确切的说,在我们另一个专栏里聊到的【从零开始学敏捷开发】中会说,性能测试不通过,是无法进行Demo的。

小编注:

从零开始学敏捷开发】致力于将一套可落地执行的敏捷开发流程分享给大家

该流程面向项目团队全体成员,定位了每个职业在敏捷开发流程中扮演的角色,以及在项目研发不同阶段的流程规范

无论是对团队协作开发一无所知的项目新手,还是想要提高团队开发效率,减少BUG数量的技术总监,都能从自己的角度有所收获。

欢迎扫码关注

性能测试是必须要有的,这一点不要有任何的疑问,问题就在于是,谁来做性能测试?

很多人会认为这应该交给测试团队来处理,在测试环境上跑压测。

但是对于大多数中小型公司(100研发团队以下,日活1000万以下)来说,都不必单独为压测搭一个环境出来。

放在测试环境跑,让测试团队来做性能测试的问题就在于,发现了性能的问题怎么办?

测试团队需要跟研发团队沟通

研发团队需要看到测试结果,还有可能需要重现步骤和场景

等研发团队做完之后还需要再重新部署,再重新演示。

这就是我们一直都觉得很有意思的问题,为什么性能测试不让研发团队在开发环境自己来呢?

我们说过开发环境是不稳定的

但是在项目研发的后期,抽出来半个小时或者是一个小时的稳定测试时间,是没有问题的。

压测不是简单的给出结果,还是要找出原因,只有开发团队才会清楚性能的瓶颈,可能需要反复的测试。

这和我们之前说到的【功能测试】是同样的道理:

我们鼓励研发团队自测,但是边界测试或者是复杂情况下的测试,是需要一个稳定的测试环境的

性能测试通常包括后端和前端两种。

前端的性能测试,主要是就是看网页的大小响应的速度 。

如果修真院的官网,首屏打开时间是1分钟,做为PM的你,能接受么?

手机上打开一个Banner图,发现图片是12兆,做为PM的你,能接受么?

一个动画卡的怀疑人生,你能接受么?

不可以的。

那么后端也是一样的。

1个人使用,好像没问题。100个人使用,就直接返回系统错误了,怎么办?或者是直接卡死了。

后端的性能测试的主要参数就是TPS,每秒钟支持多少个请求,基本上可以推算出来可以支持多少人同时在线。

举例说明,在修真院里,获取任务列表这个接口的TPS是100:

这表示,一秒钟之内,我可以同时响应100个请求

那么,多少人在线,会可能100个人同时点击任务呢?

可能100个人在线,同一时间只有一个人会点任务。

大致我们认为,10000个人在线,才会达到TPS100的效果。

所以简单推算,如果TPS是100,我们能够支持10000个人在线,再多了就不行了。

这些具体的数据,其实都不用推送,通过数据采集和日志分析就可以得到。

但对于PM来讲,除了知道这些基础的概念和知识外,最关键的就是要理解,项目中的分工是什么样子。

第四章 不情愿的结尾

这几天因为一些特殊的事情,专栏的进度有所延误。

但是关于测试的介绍,已经算是七七八八八九不离十了。

为什么PM一定要懂测试,已经讲的很清楚了,顺带也讲了一下性能和回归测试。

对于PM来说,功能测试是必须要掌握的。

再回顾一下测试的内容,我希望你能理解到:

1.测试用例的写法
2.Bug的优先级
3.Bug的生命周期
4.开发环境,测试环境和线上环境的区别
5.发布流程和角色分工
6.性能测试和自动化测试的归属

当你确定这些都理解了之后

(最好的理解方式就是去修真院的官网做任务,没有什么比亲自完成任务更能检验你学习成果的方式了

就可以准备进入我们的PM之门了。

这是一个令人期待的事情。

产品调研,竞品分析,通用模块的设计,敏捷开发流程,MVP等等各种东西即将打开在你眼前

到底你是乔布斯,还是雷布斯,还是伽汝布斯,学了就知道了。

好了~我们在PM的课程里见,愿你提前练好金钟罩,告诉研发小伙伴:

砍我可以,砍需求不行。

第一章全五节的内容就到此结束啦

下一届我们进入第二章

【不积跬步,无以成千里,从公用模块开始吧】

第一节:

常用的功能模块有哪些】,敬请期待

欢迎来交流群与大家一起学习讨论,在里面进行实时的沟通答疑

微信分享人:

暗灭,出身搜狐,葡萄藤创始人/CEO,10年敏捷开发最佳实践

驻场大神:

搜狐产品大神张春源:10年+产品开发经验,高屋建瓴

冰秀大神:出身搜狐,连续创业,创业者的产品即是公司:一家被收购,一家上市,匠心独运

想进群的请加大师姐微信邀请进群:

记得备注学产品哟

猜你喜欢

转载自blog.csdn.net/jnshu_it/article/details/84431123