本篇为【从零开始学产品】系列课第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的课程里见，愿你提前练好金钟罩，告诉研发小伙伴：

砍我可以，砍需求不行。

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

下一届我们进入第二章

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

第一节：

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

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