testcase設計過程對產品質量的前向保障

我們都知道軟件測試的一個基本理論是：bug越早發現，修復成本越少。根據這條基本理論，我們測試需要做的事情就是：盡早介入產品的質量控制過程，盡量早的發現軟件的問題。那么問題來了，我們測試工程師通過什么點來盡早切入和影響產品的質量呢？我的經驗是：通過需求評審和case設計過程的反饋來做前向的問題發現和溝通。

那為什么標題只提case設計過程，而未涉及需求評審呢？那是因為，我覺得case設計和需求評審是一個整體的過程。一般來講，雖然需求評審在前，case設計和評審在后。但實際上，對于測試工程師來說，需求評審啟動的那一時刻，case設計就已經在做了。我們通過需求文檔來對產品的功能有一個基本的理解，當然僅僅是理解是遠遠不夠的。這時候，我們需要切換成真正的用戶和開發工程師的角色。由于我們從一開始就在考慮如何設計和實現testcase。場景是否能與用戶的實際需要相關，開發工程師可能會如何設計？站在這個角度，能幫助我們更好的關注需求文檔中的不合理與不明確之處。

當然，為了保證質量，將項目向前推進，每當我們發現問題的時候，就應當及時與產品和開發同時進行溝通，是整個團隊的理解一致。晨會是比較不錯的方式，有了這樣的形式就不需要單獨花時間把大家叫到一起。當然，如果團隊成員坐在一起就更理想了，直接面對面的溝通是最有效的。我不建議只是通過郵件或者即時消息的方式將問題拋出，因為這樣效率太低，而且很可能達不到我們理解一致的效果。這些問題都是要記錄下來的，等到測試用例評審環節再結合具體的case場景簡單過一遍，保證在開發過程結束的時候，提交的產品功能是我們想要的。

站在case場景來Review概要設計對產品質量和進度也非常重要。一方面，可以加深我們對內部邏輯的理解，有可能會發現設計的性能缺陷或者對某些異常場景處理不當。比如，測試工程師可以問問開發工程師某些異常場景是如何處理如何表現的，你從開發的臉色就可以看出他是不是在設計的時候就對這些不太顯著的地方有過注意。很多時候，我們大部分報的bug都是靠這些極端場景的測試用例發現的。那么，在編碼階段進行預防是不是更好呢？而且，這樣的問題你提出一些后，會有利于測試地位在團隊中的提升，推進一些其他的時候的時候就會更方便。另外一方面，我們測試也需要考慮功能的可測性。一般來講，testcase更多的是端到端的測試，有界面的場景我們容易覆蓋，而一些內部邏輯是不好簡單通過界面來進行測試覆蓋的。這時就需要向開發提出是否能有一些測試參數或者日志輸出方面的支持，或者請求開發在代碼review的時候特別關注，由開發來保證復雜邏輯的質量。

說了這么多過程中的細節，我們可以發現，testcase設計表面上看很簡單，但實際真正要做好是需要大量的溝通工作的，特別是對于邏輯復雜的功能。對我來說，一份testcase不是為了發現很多的bug，而是給我們建立產品發布的信心。