如何判定“測試通過”？【轉】

文如標題。其實這應該是一個老生常談的問題，然而因為太老了，所以它差不多已經在不斷涌現的“后浪”（新問題）推動下死在了“沙灘上”，而答案也變得更加的模糊。

　　可是這個問題其實每一個測試人員都無從逃避。也許我們每個人都在心里有一把尺子，只是尺子的最小單位和最大丈量范圍不同，但是確實就那么存在著。我也有，從我做測試的第一天起其實就已經有了，只是每次用這把尺子算出結果的時候，我都會或多或少的擔心過是否自己計算錯誤。想想看，一個以測試為職業一個習慣對任何事物先進行懷疑的人怎么能不去懷疑自己的計算結果，更何況這個結果產生的影響足以值得我們去測試這個結果。

　　算算看自己做測試也快要3年了，可是每次修改任務狀態為測試通過時，都會有種“心虛”的感覺，可以說這感覺跟了我近3年了。尤其是在最近的一次較為緊急的日常需求測試中，這種感覺似乎愈演愈烈。當開發人員不停的詢問測試進展和情況時，總有種不知如何回答的感覺，即使是以測試用例的執行情況來作為判定標準，但是我們都知道隨著測試的深入，用例本身也需要強化和修改，尤其在這種周期短的日常測試中更讓人難以預估，因為對需求理解的深度和相關業務的廣度都受到了時間上的制約，但是這同時并不能成為我們測試人員遺漏問題的借口，因為凡是經過我們的測試都必須有一定質量的保證。所以我習慣把我想不明白的問題與開發做交流，同時在自己測試完成后明確的通知開發人員我測試了哪些內容，并讓他們分析是否還有遺漏。盡管我知道開發人員未必能給出很多提示，但是我希望我們測試人員并不是獨自戰斗，更不應該只是時時向開發人員匯報進度，我們需要開發人員的支持和幫助。尤其是我會把自己在測試中無法保證的情況也向他們說明，并請求他們分析我所懷疑的問題是否程序能夠處理，或者提供我某種驗證的思路、方法以便讓我對這些情況進行測試。

　　其實可以換一個角度想，開發人員也非常需要得到測試人員的認可，并且這認可越早得到他們得到的鼓舞就越高�？墒菧y試人員并不能以滿足開發人員的“成就感”為第一目標。因為一個有缺陷的東西測試人員首當其沖的要為其負責。所以即便開發人員認為測試已經足夠時，測試人員還應該要拿出自己的尺子再次定奪。

　　我們都知道bug無處不在，它的生命力是比小強還強。那么“測試通過”的意義為何？很多時候我們可能會回答詢問測試情況的人“基本沒有問題”、“差不多了”�？墒翘鞎缘梦艺f這話的時候有多么難受，因為曾經就看過這樣一篇文章說很多人都會為了逃避責任喜歡講“基本如何如何”，可是什么是“基本”，究竟差了多少沒有任何的說明。所以我們在任務的狀態里也只能看到通過或者不通過，而不是基本通過、基本不通過�？茖W是嚴謹的，它決定了我們不能摸棱兩可的做事。

　　于是我喜歡在日常需求發布表的備注里具體的寫些自己的測試情況，哪些測試了，哪些考慮了卻無法進行測試等等我在測試過程中遇到的問題。因為這樣做會緩解我對標明“測試通過”的心理壓力，因為我覺得單靠一個測試狀態并不能真正反映測試的情況。所以，在我沒有得到判定“測試通過”的標準答案前，我會一直這么做下去。假如還有其它測試人員也和我一樣有類似的困惑，不妨可以試試我的方式，或者我們再交流、再切磋，不讓我們彼此孤單的承受這“折磨”。