如何有效發現UI用戶界面層的缺陷

　　【UI型Bug定義】

　　這里指的UI型指以下兩種Bug：

　　第一種是文字型Bug，即和給定的字符資源不一致的Bug，比如文字/字符/提示語/引導語/用戶協議等文字方面的不一致。

　　第二種是UI效果不一致的Bug，比如應該是個圓角按鈕，做出來的界面卻是個平角的按鈕;有下拉箭頭效果，做出來的界面卻沒有下拉箭頭效果;混動界面應該有3屏，做出來的界面卻只有2屏，諸如此類。

　　【UI型Bug的產生】

　　理論上UI型Bug的產生只有一種原因，即開發人員沒有按照需求文檔或者UI做。

　　開發人員為什么沒按需求的要求去實現?通常有兩種原因：

　　第一種，開發人員一開始就沒按需求實現

　　第二種，需求方頻繁變更，沒來得及更新文檔

　　在敏捷Agile場景下，開發人員會把最主要的原因歸為需求方沒有及時更新文檔。

　　【如何減少UI型Bug】

　　理想情況下，所有的環節都按文檔做，是不存在所謂的UI型Bug的。即需求方確定文檔，開發人員嚴格按照文檔實現

　　UI文檔的變動要及時更新并通知到開發人員和測試人員

　　開發人員要嚴格按照文檔的需求去開發，不能主動發揮(任何的主動發揮都要征得需求方的同意并通知到下一個環節(即測試環節)的人員)

　　【QA人員碰到很多的UI型Bug該怎么辦】

　　當UI型Bug占到Bug總數的一定數量后，QA人員有義務想產品或者項目經理提出抗議，說明這是在浪費大家的時間。

　　【AgileHei測試是怎么做的】​

　　測試人員不負責測試UI型Bug，由需求方在驗收時統一對UI進行驗收(或者在項目中期約定一個時間進行修改)。UI型Bug是很直觀的Bug，由需求方和實現方直接達成協議，結對及時修改最有效率。

　　【結論】

　　UI型Bug是溝通不一致的產物，測試人員不要把有限的精力放在UI型Bug上面。為追求所謂的敏捷而導致了后續環節的頻繁溝通，不是Agile的本意，是為了敏捷而敏捷，為了增加溝通而溝通。

原文轉自：http://agileqa.org/archives/35