這是軟件質量的第二篇，上一篇在這裏，主要內容是，需求階段要保證需求的可測試性，開發階段要保證方案和架構本身的可測試性。
稍微複習一下核心要點。
對於軟件的質量保證這件事情有三個原則是可以遵循的。
一件事情越早介入，發現問題和解決問題的成本越低
在成本可控的情況下，對測試目標進行高頻次高強度的測試
永遠有 Plan B
軟件工程作爲一項系統工程，缺陷並不是在測試階段產生的，只能說是在測試階段才被發現出來。但是歷史證明，一個缺陷的出現，常常在設計、編碼階段，甚至在需求階段就已經顯露了必然故障的影子。但是產品經理不關注，開發人員不關注，把這一切都堆積到測試階段，軟件質量可想而知，數據必然是沒那麼好看的。從FB、Goolge 各個廠的質量保證體系的先進經驗來看，其實各個階段測試同學都可以介入，介入的階段以及手段，也是很講究。
需求階段評估需求可測試性。
設計階段評估架構可測試性。
編碼階段要求開發自測。
測試階段進行工具化和平臺化。
上線階段進行預案和監控梳理。
日常階段進行故障梳理和演練。
那麼問題來了，什麼樣的需求才是可測試的？怎麼權衡在需求階段對於測試資源的投入？開發究竟要交付什麼東西，才能讓開發和測試都比較開心？
簡單來說，我就是不想要bug，而且還要輕鬆。
我先說說結論，不想要bug而且要輕鬆的唯一途徑，就是把不必要以及優先級不高以及描述不清晰的需求砍掉，需求尋找其他非軟件方式的解法。
對於測試來說，開發交付的東西越全面越好，越清晰越好。能用圖描述的就不要用文字了。能用結構化的文字描述的就別隻寫在註釋裏。能解耦開的東西就不要寫在一起了。能使用現有成熟方案的，就使用現有成熟方案不需要投入大量測試了。
對於開發來說，無論其他人要求開發交付什麼東西，開發都不會開心。畢竟開發除了代碼其他都不想交付。（代碼都寫不完了還要其他？想啥呢）
但畢竟嘛，需求該做還得做，上線了出問題，大家都得背鍋。需求階段把這幾個問題拋給你的產品經理，自己多想想，多問幾個爲什麼，可以減少你非常多的扯皮時間。
這個一個面向用戶還是面向彙報還是面向kpi項目？
這個需求背後的用戶真正訴求是什麼？
如果我是用戶，我希望這個產品的形態是怎樣的？
不做系統能不能有現成的方案解決用戶的訴求？
這個需求真正實現需要怎樣的成本？
這個需求是不是一定要現在做？
如果一定要現在做，還有哪些點是需要確定的？如何評估階段性成果。
需求是不是已經比較明確了？包括需求的邊界，產品的流程，系統的輸入，系統的邏輯，系統的輸出，團隊的合作模式，已有技術或產品的可行性評估。
多想一下，你會有自己的判斷，當然產品經理會非常討厭你這樣槓他，所以如果一旦有真正需要表達出你自己觀點的場合，請務必帶着你的思考和方案去 diss ，而不要只是籠統的我就覺得這玩意不行，還不夠細，這不是用戶的需求。也就是說，發言之前請掂量掂量自己的份量。
面向用戶，精細做。
面向彙報，漂亮做，好看能跑就行。
面向kpi，砍到極致，能用就行。
至於開發同學應該交付什麼東西，其實也是有一定的標準的。首先開發同學要保證自己接到來自產品經理的需求，是明確不含糊的，而且技術理論上也是可以實現的，纔可以把任務遷移到自己身上。如果存在不明確的，請務必留時間讓產品經理繼續打磨再交付。如果技術還沒有被證明可行的，請務必留時間讓自己做好技術預研。
這個階段應該要互相合作，開發做了一個demo，請馬上聯繫產品經理驗收和確認，多聊聊。產品經理有一個不得不改的需求，請馬上聯繫開發稍微評估一下可行性和變動成本，如果確實緊急，馬上按照需求變更規範進行變更。麻煩不要出現這種情況，開發永遠只說這個需求做不了，產品永遠只說這個需求很緊急。
這裏有個 check list，開發同學在開發設計階段必須要清清楚楚在自己電腦上寫明白的，共不共享看測試同學的訴求。
1、細化到模塊的產品流程文檔
2、核心模塊設計和系統架構圖和業務模型設計。
3、核心系統交互流程圖。
4、產品異常流程圖以及對應的系統交互圖。
5、外部接口對接文檔的詳細解讀。
6、所提供服務的接口文檔。
7、模塊測試用例（測試同學幫忙）
8、數據庫設計詳細ER圖。
9、系統水位預估，是否需要緩存、限流、降級。
10、上線 check list 梳理，部署順序、數據庫、回滾等
能做到這些的，說明你對於穩定服務的意識已經很強了，這時候交付給測試同學的代碼內容，也是比較可信的內容。這麼梳理除了質量會比較高之外，對於開發同學的開發效率其實也是一個非常高的提升，上面這些內容可能只會花掉你一到兩天的時間，這比你將來花更長的時間定位問題處理故障，要好得多得多得多。
當然，如果是面向彙報和麪向kpi編程，怎麼快怎麼來，反正項目死的可能性非常大，你別還沒做出來項目就涼了，那就本末倒置了。
以上，下次繼續聊聊測試工具化和平臺化的事情。