從某種程度上講，測試用例的設計是有邊界的，這個邊界不是測試用例數量的限制，而是人的思維模式達到邊界。當測試用例幾乎達到上限的時候，又如何進一步保證產品質量呢？
其實，有時候100個測試用例和200個測試用例相比，不一定能直接證明200個測試用例執行後產品的質量就一定要好於100個測試（因為200個測試用例有可能忽略了某定特點的場景）。另外，有些bug是設計缺陷，並且只有在效能測試時或者特定的情況下才能發現。而這些問題在專案的後期發現基本是無解或者只能選擇work around來牽強的修復。所以測試用例並不是一勞永逸的，而更多的設計缺陷需要在更早期被發現。而這些隱藏的風險很多情況下只有開發自己心裡清楚，如果他選擇隱瞞將來就可能是個大雷。而測試的質量保障大部分都是在產品的開發中後期。就像比薩斜塔，在一棟建築快結束的時候發現他是斜的，後期是很難修復的。
既然測試用例已經快接近極限的時候，那就只能通過其他的方式來改進。很多同學提到了需求規範、文件規範、流程規範以及必須有測試計畫、測試策略等。我個人覺得這些確實在流程上幫助了產品的質量，但是在「提高「二字上並沒有發揮出更大的作用。而在質量進一步提高的措施我個人認為在於：評審（review）。在專案的各個關鍵節點上加入評審，能夠在軟體開發流程的整體上降低風險，比如：需求評審、整體架構評審、**評審甚至是測試用例評審。俗話說三個臭皮匠頂乙個諸葛亮，眾人拾柴火焰高也就是這個道理。以下是我根據多年的經驗總結的軟體開發測試流程體系，在每個關鍵的節點上都加上了評審，避免思維的侷限性。在實際的專案運營中也取得了非常好的效果，特別是**設計和架構的評審，在設計初期就能杜絕一些潛在的風險。
當測試用例枯竭時，用什麼來提高質量？
從某種程度上講，測試用例的設計是有邊界的，這個邊界不是測試用例數量的限制，而是人的思維模式達到邊界。當測試用例幾乎達到上限的時候，又如何進一步保證產品質量呢？其實，有時候100個測試用例和200個測試用例相比，不一定能直接證明200個測試用例執行後產品的質量就一定要好於100個測試 因為200個測試...
為什麼設計測試用例
但是即使測試熟悉了，一旦產品開發出來，測試拿到參評就開始使用找bug嗎，我想即使測試熟悉了產品，在測試的過程中肯定對產品的功能有所遺忘，即使是熟悉過文件，由於一款產品的功能模組實在太多 如果測試只是憑著對需求文件的熟悉度，就開始亂點，沒有計畫沒有目標開始測試，到頭來自己做過哪些操作都忘記了，更別談測...
什麼樣的測試用例是好的測試用例
1 用例覆蓋程度毫無疑問，這一點應該是最重要的，無需多說，覆蓋率最大化是一套測試用例的最重要評價標準，如果漏測就杯具了。2 用例是否已經達到工作量最小化 在滿足用例覆蓋程度最大化的前提下，應該盡量減小執行用例所需要的工作量。這些方面的方法有不少，如條件覆蓋，分支覆蓋，正交覆蓋等方法。面對不同的測試物...