本篇為【從零開始學產品】系列課第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的課程里見，愿你提前練好金鐘罩，告訴研發小伙伴：

砍我可以，砍需求不行。

第一章全五節的內容就到此結束啦

下一屆我們進入第二章

【不積跬步，無以成千里，從公用模塊開始吧】

第一節：

【常用的功能模塊有哪些】，敬請期待

歡迎來交流群與大家一起學習討論，在里面進行實時的溝通答疑