我對測試的思考
說起來人生第一家互聯網公司，教會了我蠻多的東西，雖然比較雜。如運維、測試、實施、開發等。基本上那個時候，哪裡有需要，哪裡就有我。
之前曾寫過這麼一篇文章論單元測試之重要性
這篇文章的背景是我處於創業公司的時期，那個時候做的比較雜，由於前後端一起做，功能越來越多，bug也就越來越多。最後發現因為趕著發布周期，不得不快，快的我們連單元測試以及自測都懶得弄。最後發布前，經理測試了一下，發現了一堆bug。於是我們周末加班改bug。
持續了一段時間後，覺得老這樣也不行，於是就開始寫單元測試。還別說，因為寫了單元測試後，bug率果然下降很多，bug率下降很多後，雖然也有一些bug，但並不是很重要，可以慢慢改。總而言之，我們不用周末來加班了，可以有一個美好的雙休。
一、第一家公司專做測試的那段日子
之前我的領導是R哥，後來變成了D姐。D姐教我如何寫測試用例。
根據測試用例，然後介面上進行操作，這樣的測試通常叫功能性測試。
測試有很多種，功能測試是測試人員最基本的，也是最基礎的。
測試分類如下:
-
黑盒測試——不是基於內部程式碼和設計的知識，而是基於需求和功能。
-
白盒測試——基於應用程式的內部邏輯的知識，通過語句，分支，路徑和條件的覆蓋率。
-
單元測試——測試中的最小單位，測試特殊的功能或程式碼模組。由於需要對內部程式碼和設計的詳細知識，該測試一般由開發者完成而不是由測試人員完成。該測試的容易程度同程式碼設計的好壞直接相關。
-
增量型的集成測試——隨著新功能的增加，不斷的對應用程式進行測試。在程式的所有部分完成之前，需要一個應用程式的各個部分之間能夠相對獨立的進行工作。這類型測試可以有開發者或測試者完成
-
集成測試——測試應用程式結合的部分來確定它們的功能結合到一起是正確的。在這裡『部分』的概念可能是程式碼模組，獨立的應用程式，在網路上的客戶端和伺服器斷程式等等。這類型測試典型的是於客戶/伺服器和分散式系統相關。
-
功能測試——是一種黑盒測試，同應用程式的功能需求緊密相關。這類型測試應當有測試人員來完成。這並不意味著開發人員在發布版本之前就不需要檢查他們的程式碼。
-
端到端測試——同系統測試類似，包括模擬現實世界對一個完整的應用環境進行測試。例如同資料庫進行交互、使用網路通訊，或者其他的軟體、硬體和系統進行交互。
-
理智測試——這是一種典型的原始測試，其目的是要確定一個新的軟體版本在一些主要的測試努力下表現的足夠好並且可以接受。例如：如果一個新軟體每五分鐘宕機一次，使系統執行速度極其緩慢，或者破壞系統數據，那麼該軟體就處於不夠『理智』狀態，必須保證在當前狀態下進行進一步測試。
-
回歸測試——在軟體或環境被修改後進行的再測試。可能很難確定我們需要進行多少的再測試，尤其接近到開發過程的末期。自動測試工具可能會有很大的幫助。
-
可接受性測試——基於最終用戶的規格進行的最後測試。或者基於最終用戶在一定的時間範圍內的測試。
-
負荷測試——在高負荷條件下進行的測試。
-
壓力測試——該術語通常同負荷測試和性能測試是可交換的。也可用於描述這樣一些測試如：在不正常的負荷狀態下，過分的重複某些動作或輸入情況下進行的系統功能測試。
-
性能測試——該術語通常同負荷測試和壓力測試是可交換的。理想的性能測試是定義在需求文檔或QA測試計劃中的。
-
安裝和反安裝測試——測試完全、部分或升級的安裝/反安裝過程。
-
恢複測試——測試當出現崩潰，硬體錯誤或其他災難性問題時，系統的表現情況。
-
安全性測試——測試系統對於內部和外部非法入侵、故意損壞時的表現情況。可能需要複雜的測試技術。
-
兼容性測試——測試系統在不同的平台/硬體/作業系統/網路上的表現情況。
-
ALPHA測試——在開發進行結束的時候進行的測試。針對測試的結果可能還會進行一些小的設計更改。這類測試典型的是由用戶進行的，而不是由開發者或測試人員進行的。
-
BETA測試——在開發和測試已經全部結束後，並且在最終版本發布之前進行的測試。這類測試典型的是由用戶進行的，而不是由開發者或測試人員進行的。
那段時期做過最多的還是功能性測試。
那段時期也比較苦惱，覺得功能性測試沒有一點技術含量，有過辭職的念頭，於是將自己的苦惱跟導師訴說。導師很快給我回復，雖然現在記不得很清楚他的原話，但內容大概是，測試並不是沒有技術含量的，高級的測試是需要會寫程式碼的，同時你覺得哪些是重複性、單調的工作你可以學習一些自動化工具來提高你的測試效率。
於是我才堅持下來做了一段時期的測試工作。功夫不負有心人，最終我還是成功轉到了開發部門，開始寫我喜愛的Code。
二、創業公司的那段測試時期
在創業公司做我們自己的產品，我在這篇文章較為詳細的說過創業公司這兩年
仔細想想，我們的產品類型分為如下:
- 物聯網產品(既面向B端，又面向C端);
- 電商產品(既面向B端，又面向C端);
- 教育產品(既面向B端，又面向C端)。
我們公司組織結構除了研發就是產品，沒有測試。所以我們研發人員無論是後端還是Android端的，基本上都需要兼任測試職責。
就像我在前面說到的那樣，前期我們不是很注重測試環節甚至過濾掉，導致我們不必要的加班改bug。後期我們形成了一套流程，周一到周四開發階段，周五發版測試，如果沒有問題，周五下班前直接發給經理，由經理再測試驗證，隨後再到老闆那，如果有問題，問題比較嚴重，周五改不過來，那麼我們就需要周六或周日來加班，
最初我們的測試也就是點點，但後來發現這樣不行，因為點點僅僅是確認這個功能是否會報錯如500等之類的，但並不能確保業務流程是對的。
於是我們改進了，寫了幾個業務流程的思維導圖，然後測試，這樣有針對性的測試，讓我們測試就有了方向，不至於東點點西點點浪費不必要的時間。
三、教育SAAS公司的測試時期
教育SAAS有專門的測試人員和完善的測試機制。但是作為開發人員，我們部門明確一點要求，那就是每個人寫的Java程式，必須要有對應的測試程式碼，以確保不必要的錯誤和程式碼品質。
每兩周發版一次，分為開發周和測試周，開發周寫本周產品提出的需求，每周周五開發周將終止，進行內部發版，發到測試環境，周一或者周五下午由測試人員進行冒煙測試。
大家或許對冒煙測試不太了解，其實我之前也不明白。
冒煙測試
1.冒煙測試是什麼
針對每個版本或每次需求變更後，在正式測試前，對產品或系統的一次簡單的驗證性測試。
2.冒煙測試的目的
為正式測試前，驗證是否產品或系統的主要需求或預置條件是否存在bug。
經過冒煙測試驗證Ok沒問題後，然後測試人員才會進行下一步測試如功能性測試。
經過這家公司的洗禮，我才發現測試人員還是要有很強的功底如必須對業務非常熟悉和非常細心和嚴謹，同時還得熟練掌握一些自動化測試工具如LoadRunner或Selenium等。
由於沒待過流程體系較為完善的公司，我在這家公司做的第一個功能就出現了近一百多個bug。那個時候我既要寫後端，也要寫前端。後端bug二十來個，前端bug近一百個。看到禪道上給我指派的bug，我都快哭了。那個時候很想揍那位測試小哥哥。我剛來沒多久，就對我這麼不友好。想了想，先把bug改完再說。改完後，我逐漸意識到也不能怪那位測試小哥哥，畢竟是人家的職責所在。通過這次我發現自身存在很多問題，如程式碼寫的不嚴謹、對一些細節不注重、不細心、對於功能差不多就好等缺點，於是後來我努力改進，雖然寫的功能或多或少會有bug，但基本上控制在個位數上，改起來也不費勁，自那以後我和測試人員就處的很愉快，bug少，我輕鬆，他們也輕鬆。
四、總結
我所待的三家公司里，測試工作的經歷告訴我一個很重要的道理:
無論研發、測試、運維或者是其他行業的工作，做到最後都在圍繞一個人最重要的素養，那就是責任心，同樣這個責任心也是做人最重要的品質之一。
