本篇為【從零開始學產品】系列課第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年+產品開發經驗，高屋建瓴

冰秀大神：出身搜狐，連續創業，創業者的產品即是公司：一家被收購，一家上市，匠心獨運

 

想進群的請加大師姐微信邀請進群：

記得備註學產品喲