你們系統真爛。
多麼簡單的一句話，一個系統故障可以把很多很多同學的全部心血付諸東流。這個時候經常是互相甩鍋的時候。
甲方爸爸：你們怎麼搞的？你們今天必須給我一個交代。
老闆：怎麼搞的？問題出在哪裡？趕緊給我解決。
測試：開發的同學趕緊看一下啊，什麼原因。
開發：測試 TMD 的沒測試充分，出問題又要我背鍋。
産品：開發真不靠譜，這點小需求這麼多問題。
流程：嗯，我再增加個釋出卡點。
很多時間，測試同學就是這樣測試。用滑鼠點着螢幕，或者用着手對着螢幕戳戳戳。測試同學忙得要命，很認真很負責，但是很遺憾，故障依然居高不下，開發依然要時刻背鍋，甲方爸爸依然罵。肯定是哪裡出了問題。
對于軟體的品質保證這件事情有三個原則是可以遵循的。
一件事情越早介入，發現問題和解決問題的成本越低
在成本可控的情況下，對測試目标進行高頻次高強度的測試
永遠有 Plan B
軟體工程作為一項系統工程，缺陷并不是在測試階段産生的，隻能說是在測試階段才被發現出來。但是曆史證明，一個缺陷的出現，常常在設計、編碼階段，甚至在需求階段就已經顯露了必然故障的影子。但是産品經理不關注，開發人員不關注，把這一切都堆積到測試階段，軟體品質可想而知，資料必然是沒那麼好看的。從FB、Goolge 各個廠的品質保證體系的先進經驗來看，其實各個階段測試同學都可以介入，介入的階段以及手段，也是很講究。
需求階段評估需求可測試性。
設計階段評估架構可測試性。
編碼階段要求開發自測。
測試階段進行工具化和平台化。
上線階段進行預案和監控梳理。
日常階段進行故障梳理和演練。
[可測試的需求]
很少有測試同學從需求階段就開始介入，往往都是到了設計階段甚至測試階段，才發現這個需求本身就沒法測試。
比如這樣的需求：
生成一個随機數
響應時間要快
實作一個登陸功能
上面的需求基本是無法測試的，那麼怎樣的需求才是可測試的？或者說合格的需求，應該具備怎樣的素質？合格的一個需求，應該至少具備下面五個特質。
一緻性、完整性、無歧義、可量化、可操作
一緻性：一樣的輸入，理論上應該要有一樣的輸出或者可觀察的表現。如果一樣的輸入永遠有随機性，那麼是不可測的。（比如生成一個随機數這個事情，基本就不可測試）
完整性：一個需求是完整的，是可以邏輯自洽的，不缺少某些核心需求描述。（比如，實作一個登陸功能）
無歧義：一個需求描述不應該是歧義的，一個描述永遠隻有一個解釋。（比如，給每個使用者的優惠券，能給多少給多少）
可量化：可測試的需求都需要是可以數字化或者可被明确觀察的。（比如，這個網頁響應速度要快）
可操作性：理論上和實際上都具備可操作性，而且是成本可控的，如果隻是理論上可行，實際不可行或者成本太高，那麼也是不可操作的。（比如，實作一個精确計算中國平均年齡的算法）
從需求階段就介入，是提高一個軟體品質，減少被甲方爸爸罵的最好的時機，也是很多測試同學忽略的時機。但這個階段需求可能變化比較大，如果測試同學過多介入的話需要投入比較多的精力，這就需要産品經理和開發同學本身比較靠譜，這也是後面要講可測試組織的原因。
[可測試的代碼]
需求階段ok之後，其實就把接力棒交到了開發小哥哥手上了，當然這個階段測試同學就不好自己把需求代碼實作了吧。這個階段測試同學要做的事情呢，可能是要介入到開發小哥的方案設計上，并且給開發小哥列舉好需要自測的清單和标準，在移交給測試同學之前必然要有一定的代碼品質把控。
我們通常從以下幾個方面來描述一個技術方案的可測試性：
可控制性：是否可以将待測系統的狀态控制到如測試條件要求。
可觀察性：是否可以觀察（中間或最後的）測試結果。
可隔離性：各個子產品是否可以隔離測試。
關注點分離：各個子產品是否有單一且清楚定義的任務。
易懂性：子產品本身是否有說明文檔，或是本身可讀性很高。
可自動化性：子產品是否可以進行自動測試。
異質性：是否需要不同的測試方法及工具平行測試。
雖然能否寫出高性能的優雅的代碼，那是開發小哥哥的事情。但是否能寫出可測試的代碼，這可能是比較進階别的測試同學需要密切關注的。畢竟，方案如果設計得爛，代碼如果寫得爛，你怎麼測品質都不會好到哪裡去。
想想在測試階段是這樣的情況。
[昨日進度:待解決缺陷130個]
[今日進度:解決缺陷50個，待解決缺陷230個]
欲哭無淚...
今天就先寫到這裡吧。。。太長了，後面有空再聊有空再繼續聊，再會。