我對測試的思考

提及來人生第一家互聯網公司，教會了我蠻多的東西，雖然比較雜。如運維、測試、實施、開發等。基本上那個時候，哪裏有須要，哪裏就有我。

以前曾寫過這麼一篇文章論單元測試之重要性
這篇文章的背景是我處於創業公司的時期，那個時候作的比較雜，因爲先後端一塊兒作，功能愈來愈多，bug也就愈來愈多。最後發現由於趕着發佈週期，不得不快，快的咱們連單元測試以及自測都懶得弄。最後發佈前，經理測試了一下，發現了一堆bug。因而咱們週末加班改bug。

持續了一段時間後，以爲老這樣也不行，因而就開始寫單元測試。還別說，由於寫了單元測試後，bug率果真降低不少，bug率降低不少後，雖然也有一些bug，但並非很重要，能夠慢慢改。總而言之，咱們不用週末來加班了，能夠有一個美好的雙休。

1、第一家公司專作測試的那段日子

以前個人領導是R哥，後來變成了D姐。D姐教我如何寫測試用例。
根據測試用例，而後界面上進行操做，這樣的測試一般叫功能性測試。
測試有不少種，功能測試是測試人員最基本的，也是最基礎的。

測試分類以下:

• 黑盒測試——不是基於內部代碼和設計的知識，而是基於需求和功能。

• 白盒測試——基於應用程序的內部邏輯的知識，經過語句，分支，路徑和條件的覆蓋率。

• 單元測試——測試中的最小單位，測試特殊的功能或代碼模塊。因爲須要對內部代碼和設計的詳細知識，該測試通常由開發者完成而不是由測試人員完成。該測試的容易程度同代碼設計的好壞直接相關。

• 增量型的集成測試——隨着新功能的增長，不斷的對應用程序進行測試。在程序的全部部分完成以前，須要一個應用程序的各個部分之間可以相對獨立的進行工做。這類型測試能夠有開發者或測試者完成

• 集成測試——測試應用程序結合的部分來肯定它們的功能結合到一塊兒是正確的。在這裏‘部分’的概念多是代碼模塊，獨立的應用程序，在網絡上的客戶端和服務器斷程序等等。這類型測試典型的是於客戶/服務器和分佈式系統相關。

• 功能測試——是一種黑盒測試，同應用程序的功能需求緊密相關。這類型測試應當有測試人員來完成。這並不意味着開發人員在發佈版本以前就不須要檢查他們的代碼。

• 端到端測試——同系統測試相似，包括模擬現實世界對一個完整的應用環境進行測試。例如同數據庫進行交互、使用網絡通訊，或者其餘的軟件、硬件和系統進行交互。

• 理智測試——這是一種典型的原始測試，其目的是要肯定一個新的軟件版本在一些主要的測試努力下表現的足夠好而且能夠接受。例如：若是一個新軟件每五分鐘宕機一次，使系統執行速度極其緩慢，或者破壞系統數據，那麼該軟件就處於不夠‘理智’狀態，必須保證在當前狀態下進行進一步測試。

• 迴歸測試——在軟件或環境被修改後進行的再測試。可能很難肯定咱們須要進行多少的再測試，尤爲接近到開發過程的末期。自動測試工具可能會有很大的幫助。

• 可接受性測試——基於最終用戶的規格進行的最後測試。或者基於最終用戶在必定的時間範圍內的測試。

• 負荷測試——在高負荷條件下進行的測試。

• 壓力測試——該術語一般同負荷測試和性能測試是可交換的。也可用於描述這樣一些測試如：在不正常的負荷狀態下，過度的重複某些動做或輸入狀況下進行的系統功能測試。

• 性能測試——該術語一般同負荷測試和壓力測試是可交換的。理想的性能測試是定義在需求文檔或QA測試計劃中的。

• 安裝和反安裝測試——測試徹底、部分或升級的安裝/反安裝過程。

• 恢復測試——測試當出現崩潰，硬件錯誤或其餘災難性問題時，系統的表現狀況。

• 安全性測試——測試系統對於內部和外部非法入侵、故意損壞時的表現狀況。可能須要複雜的測試技術。

• 兼容性測試——測試系統在不一樣的平臺/硬件/操做系統/網絡上的表現狀況。

• ALPHA測試——在開發進行結束的時候進行的測試。針對測試的結果可能還會進行一些小的設計更改。這類測試典型的是由用戶進行的，而不是由開發者或測試人員進行的。

• BETA測試——在開發和測試已經所有結束後，而且在最終版本發佈以前進行的測試。這類測試典型的是由用戶進行的，而不是由開發者或測試人員進行的。

那段時期作過最多的仍是功能性測試。

那段時期也比較苦惱，以爲功能性測試沒有一點技術含量，有過辭職的念頭，因而將本身的苦惱跟導師訴說。導師很快給我回復，雖然如今記不得很清楚他的原話，但內容大概是，測試並非沒有技術含量的，高級的測試是須要會寫代碼的，同時你以爲哪些是重複性、單調的工做你能夠學習一些自動化工具來提升你的測試效率。

因而我才堅持下來作了一段時期的測試工做。功夫不負有心人，最終我仍是成功轉到了開發部門，開始寫我喜好的Code。

2、創業公司的那段測試時期

在創業公司作咱們本身的產品，我在這篇文章較爲詳細的說過創業公司這兩年

仔細想一想，咱們的產品類型分爲以下:

• 物聯網產品(既面向B端，又面向C端);
• 電商產品(既面向B端，又面向C端);
• 教育產品(既面向B端，又面向C端)。

咱們公司組織結構除了研發就是產品，沒有測試。因此咱們研發人員不管是後端仍是安卓端的，基本上都須要兼任測試職責。

就像我在前面說到的那樣，前期咱們不是很注重測試環節甚至過濾掉，致使咱們沒必要要的加班改bug。後期咱們造成了一套流程，週一到週四開發階段，週五發版測試，若是沒有問題，週五下班前直接發給經理，由經理再測試驗證，隨後再到老闆那，若是有問題，問題比較嚴重，週五改不過來，那麼咱們就須要週六或週日來加班，

最初咱們的測試也就是點點，但後來發現這樣不行，由於點點僅僅是確認這個功能是否會報錯如500等之類的，但並不能確保業務流程是對的。

因而咱們改進了，寫了幾個業務流程的思惟導圖，而後測試，這樣有針對性的測試，讓咱們測試就有了方向，不至於東點點西點點浪費沒必要要的時間。

3、教育SAAS公司的測試時期

教育SAAS有專門的測試人員和完善的測試機制。可是做爲開發人員，咱們部門明確一點要求，那就是每一個人寫的Java程序，必需要有對應的測試代碼，以確保沒必要要的錯誤和代碼質量。
每兩週發版一次，分爲開發周和測試周，開發周寫本週產品提出的需求，每週週五開發周將終止，進行內部發版，發到測試環境，週一或者週五下午由測試人員進行冒煙測試。

你們或許對冒煙測試不太瞭解，其實我以前也不明白。

冒煙測試

1.冒煙測試是什麼

針對每一個版本或每次需求變動後，在正式測試前，對產品或系統的一次簡單的驗證性測試。

2.冒煙測試的目的

爲正式測試前，驗證是否產品或系統的主要需求或預置條件是否存在bug。

通過冒煙測試驗證Ok沒問題後，而後測試人員纔會進行下一步測試如功能性測試。

通過這家公司的洗禮，我才發現測試人員仍是要有很強的功底如必須對業務很是熟悉和很是細心和嚴謹，同時還得熟練掌握一些自動化測試工具如LoadRunner或Selenium等。

因爲沒待過流程體系較爲完善的公司，我在這家公司作的第一個功能就出現了近一百多個bug。那個時候我既要寫後端，也要寫前端。後端bug二十來個，前端bug近一百個。看到禪道上給我指派的bug，我都快哭了。那個時候很想揍那位測試小哥哥。我剛來沒多久，就對我這麼不友好。想了想，先把bug改完再說。改完後，我逐漸意識到也不能怪那位測試小哥哥，畢竟是人家的職責所在。經過此次我發現自身存在不少問題，如代碼寫的不嚴謹、對一些細節不注重、不細心、對於功能差很少就好等缺點，因而後來我努力改進，雖然寫的功能或多或少會有bug，但基本上控制在個位數上，改起來也不費勁，自那之後我和測試人員就處的很愉快，bug少，我輕鬆，他們也輕鬆。

4、總結

我所待的三家公司裏，測試工做的經歷告訴我一個很重要的道理:
不管研發、測試、運維或者是其餘行業的工做，作到最後都在圍繞一我的最重要的素養，那就是責任心，一樣這個責任心也是作人最重要的品質之一。