項目終結之一--測試規范定義

第一次從項目開始做到終結，應該還是有很多想要留下來給自己沉淀的部分吧。那第一個部分應該就是項目先前的整體規劃，包括整個流程的規范，包括開發規范、測試規范，也還包括與客戶在驗收上要達成的一致，例如驗收標準，要達到什么樣的目標。這部分不在這里多談，畢竟是老板們談的事情

簡單說兩句開發的部分，畢竟不是我的專業，只是說些看到的問題，有不對的地方請大家拍磚吧

首先，開發用的語言、框架自然不必說。其次，代碼的規范，例如文件命名的定義。是不是需要寫Unit Test，那是不是要達到什么樣的覆蓋度，當然對于貫徹持續集成的項目中，這一項會相對重要，如果不需要CI這一項就可以根據項目情況來決定啦。CI的部分在流程規范的部分再談吧。其實開發部分的規范還有很多，就不多說了，只是想說明規范很重要。

好吧，說到測試的部分。

1. Test Case

首先，Test Case中要有什么欄位，例如Title、 Description(steps)、Input(test data)、Priority、Module、Functionality、Sub-functionality(maybe)、Case ID、Automation、Test type(blackbox, whitebox or others)、還可以通過欄位標記smoke/regression/E2E、Story ID(這里是來記錄需求文檔的number或其他的資訊，會比較好追溯)，標記Test type的訊息是為了讓以后的Test Case比較好管理，可以在不同的測試時抓到正確的Test Case，例如我要做Head版本的測試可能要用的就是smoke，那在做branch測試的時候就會做Regression等等。

其次，Test Case的Description其實很難定義出來要寫成什么樣子，畢竟大家的工作習慣不全然相同。一直認為說，Test Case要像一個人寫的，統一風格。在經歷了這個項目之后覺得，那真的是個很好的預期，但確是很難達到的狀況。理想很豐滿現實很骨感。還是Case by case來說吧，進入Team的Tester時間不一樣，那項目的松緊程度也不同，是否可以把標準統一貫徹到每個member，就要考慮現實狀況了；再者，規范定義出來之后在執行的時候是否嚴格，例如case review發現不符合標準的部分，如何讓每個member都進行修改，直到達到標準之後。好了，我還是具體來說我的想法。再說明下，個人習慣(也有可能是客戶要求)、項目情況都不同，還是case by case來看。對于Steps，描述清楚當然是首要標準，每一步都應該講清楚是進入哪個頁面(where)，進行什么樣的操作(do what)，輸入的數據是什么(input data)，輸出應該是什么(output、expected result)。有些項目習慣用excel來管理Test Case，這樣很難把每個步驟的output寫清楚，只會有最后一個期望結果，那這樣好處是case粒度很細，壞處就是case過度冗余，而且對于模塊之間的關聯性測試就很難cover到，完全要依靠member對于模塊的熟悉度去進行探索性測試，而這部分在測試過程當中往往是最關鍵的，基本上大體的功能是不會漏測或者說開發不會做錯的，像異常情況一樣，這些模塊之間串接的部分才是關鍵的測試點。對于一些有所共識的操作或者組件可以先期定義好，避免認知上的誤差，例如復選框統一用checkbox，單選框用radiobutton；選擇復選框用select，radiobutton用click

最后Test Case的規劃管理。個人見解，Test Case應該是項目中利用率最高的部分，因為需求的變更帶來的修改也是不可避免的，那就需要很好的管理。在我接觸過的項目中或者是潛意識中認為，按照Module來管理Test Case是比較合理的，業界也有很多方便的Test Case的管理工具，例如Testlink或者最簡單的Excel。不過我想說，在你有些不同測試需求的時候就好像不那么方便。舉例來說，按module測試，如果想進行smoke測試的時候就需要重新找case出來，費時費力。那么如果我們可以有一種方式用Test Case中的一個鍵值將想進行測試的Test Case直接導出來或者生成一個文檔就很方便，只要分分鐘就可以搞定龐大的Test Case。當然，前提是Team member了解定義Test Case中定義每個欄位的意圖在哪里，需要在新人正式進入工作前，給予系統的Training讓大家清楚Test Case要寫成什么樣子的，什么樣子的Test Case是smoke的、哪些又是Regression的，才會方便不同面向的測試

2. Bug

Bug上也有標準需要統一。Bug作為最能體現問題的、與開發人員直接溝通的介質，要提供足夠多正確的信息給開發人員重現問題、定位問題、解決問題。例如bug必須有截圖、可能的話還要提供log日志、要有清晰的Title描述、詳細的復現步驟，包括特定的帳號以及input data、screenshot要有文字描述、測試環境說明。就像港劇里說的，死者是要借法醫們傳遞死因給大家。我一直鼓勵大家要盡可能挖掘到問題的本質，而不是單純的表象。要了解到Bug到底是如何產生的，真正的原因是什么，就要大家熟悉產品/項目的架構或技術體系，這也從一個角度說明測試其實並不一定比開發的要求低。另外一個頗具爭議的部分就是Priority和Severity。每個人的視角不同，無法有一個統一的標準定義優先級。我就遇到過這類問題，其實是很簡單的小問題，但會Block自動化測試的進度，那就會是大問題。我也想這樣是不是就把問題搞復雜了，bug的定義還是應該簡單化。

如果頁面點不了、打不開、進入出錯頁那肯定就是高優先級要處理的問題；

功能層面上也有可能有P1或者P2之分，那就要Case by Case的來區別對待；

功能上還有部分屬于異常情況的測試場景就可以放到P3的范疇；

當然還有些是trivial或者tinny的問題，但請不要忽略這樣的bugs，有時候在客戶看來或者不同的軟件產品上有些wording的問題會影響專業性。

其實，說到底無論是什么開發模式，敏捷也好、瀑布也罷，在項目kickoff之前確定好個部分的規范很重要，出現了什么問題應該找誰，產品經理應該做到什么、測試要做到什么、開發要如何開發。從項目管理的角度，才讓每個部分的進程在可控的范圍，PM應該在這幾個面向上去管控項目流程進度的透明度以及正規化。這里面還有些沒有談到的，比如整個項目的流程上、持續集成都幾個層面的問題，等我釐清之后再慢慢寫吧。謝謝觀賞