文章的具體位址如下：
首先一點我得承認，我們做軟體的目的是滿足使用者需求。但是bug是永遠也消滅不完的，軟體中的「黑天鵝」隨時會出來，零缺陷也是個扯淡的說法。
我想與其在乙個迭代內閉門造車式地用各種流程，各種方法，各種流程輸出用例，不如在保證基本功能的前提下，盡早地在使用者的環境下使用軟體，讓「黑天鵝」盡早暴露出來，然後設法消除它。並且將這些「黑天鵝」出現的規律總結成經驗，形成乙個良性的反饋。
只是像在華為這樣的企業中部門牆如此之嚴重，似乎要實現這樣的機制似乎還比較困難，不知道阿里這邊是否有辦法做到這樣的乙個高速反饋。
測試中的 黑天鵝
1 軟體測試中的 黑天鵝 幾年前，我帶領的乙個測試小組遺漏了乙個嚴重的bug到網上，當使用者反饋這個bug後，我們對它進行了深入的分析和重現，最終所有人一致認為，這個bug能夠發生實在是機緣巧合，因為它需要多個條件同時發生才有可能觸發，比如 xx演算法開關必須開啟 xx演算法開關又必須關閉 xx引數...
軟體測試的一些理解
現在大部分軟體企業的生態鏈都是，軟體測試屬於最下游。這也決定了很多情況都必須被動接受。即使某個測試工程師理論知識豐富，辨識風險能力強，但是乙個產品需求的變更就可以讓他傻眼，接著很努力去適應這種節奏。產品運營主導必然是趨勢，測試主導是做不好產品的 還有乙個點爭論了很久，就是關於出現問題承擔責任的問題。...
對軟體架構的一些理解
一說到 架構 這個詞，頓時感覺自己也高大上了不少 架構是個很寬泛的概念，任何專業領域都有自己的架構。軟體行業可分為業務架構 軟體架構 系統架構。業務架構最表層的理解就是對業務模組的粒度劃分。好的業務架構的設計是好的軟體架構的基礎。業務架構要考慮業務粒度的劃分大小，太大，在進行事務管理的時候就會無法區...