當測試用例枯竭時,用什麼來提高質量?

2021-09-22 19:43:40 字數 882 閱讀 3655

從某種程度上講,測試用例的設計是有邊界的,這個邊界不是測試用例數量的限制,而是人的思維模式達到邊界。當測試用例幾乎達到上限的時候,又如何進一步保證產品質量呢?

其實,有時候100個測試用例和200個測試用例相比,不一定能直接證明200個測試用例執行後產品的質量就一定要好於100個測試(因為200個測試用例有可能忽略了某定特點的場景)。另外,有些bug是設計缺陷,並且只有在效能測試時或者特定的情況下才能發現。而這些問題在專案的後期發現基本是無解或者只能選擇work around來牽強的修復。所以測試用例並不是一勞永逸的,而更多的設計缺陷需要在更早期被發現。而這些隱藏的風險很多情況下只有開發自己心裡清楚,如果他選擇隱瞞將來就可能是個大雷。而測試的質量保障大部分都是在產品的開發中後期。就像比薩斜塔,在一棟建築快結束的時候發現他是斜的,後期是很難修復的。

既然測試用例已經快接近極限的時候,那就只能通過其他的方式來改進。很多同學提到了需求規範、文件規範、流程規範以及必須有測試計畫、測試策略等。我個人覺得這些確實在流程上幫助了產品的質量,但是在「提高「二字上並沒有發揮出更大的作用。而在質量進一步提高的措施我個人認為在於:評審(review)。在專案的各個關鍵節點上加入評審,能夠在軟體開發流程的整體上降低風險,比如:需求評審、整體架構評審、**評審甚至是測試用例評審。俗話說三個臭皮匠頂乙個諸葛亮,眾人拾柴火焰高也就是這個道理。以下是我根據多年的經驗總結的軟體開發測試流程體系,在每個關鍵的節點上都加上了評審,避免思維的侷限性。在實際的專案運營中也取得了非常好的效果,特別是**設計和架構的評審,在設計初期就能杜絕一些潛在的風險。

當測試用例枯竭時,用什麼來提高質量?

從某種程度上講,測試用例的設計是有邊界的,這個邊界不是測試用例數量的限制,而是人的思維模式達到邊界。當測試用例幾乎達到上限的時候,又如何進一步保證產品質量呢?其實,有時候100個測試用例和200個測試用例相比,不一定能直接證明200個測試用例執行後產品的質量就一定要好於100個測試 因為200個測試...

為什麼設計測試用例

但是即使測試熟悉了,一旦產品開發出來,測試拿到參評就開始使用找bug嗎,我想即使測試熟悉了產品,在測試的過程中肯定對產品的功能有所遺忘,即使是熟悉過文件,由於一款產品的功能模組實在太多 如果測試只是憑著對需求文件的熟悉度,就開始亂點,沒有計畫沒有目標開始測試,到頭來自己做過哪些操作都忘記了,更別談測...

什麼樣的測試用例是好的測試用例

1 用例覆蓋程度毫無疑問,這一點應該是最重要的,無需多說,覆蓋率最大化是一套測試用例的最重要評價標準,如果漏測就杯具了。2 用例是否已經達到工作量最小化 在滿足用例覆蓋程度最大化的前提下,應該盡量減小執行用例所需要的工作量。這些方面的方法有不少,如條件覆蓋,分支覆蓋,正交覆蓋等方法。面對不同的測試物...