寫了第一篇關于軟件測試的文章，覺得還是有讀者的，讓我覺得特別欣慰。
我自己對軟件測試的了解不算深入，文章也很入門級，起初的感覺最好的是寫測試用例（TestCase），特別是使用mindmanager+excel，寫出感覺的時候那真是分分鐘的事兒。不過寫出用例后問題來了，用例執行時間與用例數量基本是成正比的，往往執行用例會很耗時，那時就要開始合理的刪減用例了。
整理用例常用的方法無非是什么等價類、邊界值、因果圖、判定表、正交法等常用的，究其根本，是通過一些邏輯推理的方式將相同路徑的用例合并，從而達到事半功倍的效果。不過這里有坑，因為寫用例時，大部分測試人員基本不了解開發實現的過程，這也會導致看上去可以合并的用例背后邏輯有所區別，從而引發漏測。而一旦漏測的點屬于關鍵路徑，觸發幾率高，那么產生的線上問題足夠整個團隊喝上一壺了。另一方面，如果項目前期測試與團隊的溝通不足，很有可能出現推卸責任的問題，雖然從職業素養上不提倡，但關系到個人或小組利益時，往往不得已而為之。
以上的內容有點暗黑，但是并非不存在。
自己接觸軟件測試的理由比較“單純”，開發能力不行，代碼勉強讀懂，畢業時看著軟件工程的一些理論知識，眼前一亮——“就是他了！！！”
現在再觀察一下國內的軟件企業，對于80%的企業軟件測試崗位更像個雞肋。沒有的話覺得特別low，產品質量怎么保證呢？說產品高質量自己都心虛啊。但有了又能怎樣？所有的測試平臺、測試流程都要自行搭建，沒幾個資深的測試架構人員還真搞不定。那這測試崗位搞不搞呢？個人認為大公司得搞，而且得結合自身條件狠狠搞，幾十人的小團隊就值得考慮了，產品質量是不是重點，流程未規范的時候，專門招聘測試的成本可不低。
對于談論很多的開發測試比，實際使用時卻有點上綱上線了。對于具體的數值，沒有定論，也別覺得1：1就是好6：1就是差。這與開發測試的能力息息相關，一個牛逼的白盒測試工程師也許能抵10個普通的黑盒測試工程師，這也是為何開發轉測試so easy的原因。通過接口測功能也許只要10個用例，但是被添加了上層邏輯之后，也許就需要100個用例。每個測試都向往著google的開發測試比1：1，卻不知測試工程師的能力比開發工程師還要出眾。
對于企業來說，普通的測試工程師的數量怎么都覺得多；對于普通的測試工程師來說，數量怎么都覺得不夠。沒有對錯，所站的角度不一樣而已。
