本篇为【从零开始学产品】系列课第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的课程里见，愿你提前练好金钟罩，告诉研发小伙伴：
砍我可以，砍需求不行。
第一章全五节的内容就到此结束啦
下一届我们进入第二章
【不积跬步，无以成千里，从公用模块开始吧】
第一节：
【常用的功能模块有哪些】，敬请期待
欢迎来交流群与大家一起学习讨论，在里面进行实时的沟通答疑
