2010-04-14 26 views
8

我們有很多開發人員,只有幾個質量保證人員。通過編寫自動化測試,開發人員在整個開發過程中越來越多地參與qa,但我們的質量保證實踐大多是手動的。我怎樣才能決定手動測試什麼,以及相信自動測試的內容?

我很喜歡的是,如果我們的開發實踐是BDD和TDD,並且我們開發了一個強大的測試套件。問題是:在構建這樣的測試套件時,我們如何確定我們可以信任的測試,以及我們應該繼續手動進行測試?

回答

7

第一分界線 - 什麼是基本上容易手動測試,並且什麼是基本上容易以自動化的方式來測試?

這些當然很容易弄清楚,也許你會在中間留下一大堆垃圾。

我的下一個篩將是 - 用戶界面問題是最難測試的自動化方式之一,儘管一些項目使其更容易。因此,我會將這些問題留給QA人員一段時間,然後將您的自動化測試集中在小部分後端代碼上,然後逐漸擴展到跨多個單元和/或多個應用程序層的較大集成測試。

+0

+1關於UI自動化的評論。很難保持良好的UI測試框架。 – 2010-04-15 12:56:51

+0

我們是一個.NET商店,我們使用NUnit進行單元測試,並使用Watir的Cucumber進行用於UI的驗收測試。 我們發現的是,我們的黃瓜測試很脆弱,我們不會將它們用於它們旨在支持的BDD樣式過程。 您認爲使用BDD樣式測試來測試服務層代碼而不是UI會更好嗎? – bhazzard 2010-04-29 14:03:20

+0

至少在2010年,服務層代碼將比UI層代碼更容易以自動方式進行測試。你可以也應該做黃瓜式的BDD和服務層代碼測試(雖然我承認我從來沒有使用黃瓜 - 我真的很想有機會這樣做!)。 – 2010-04-29 14:46:08

6

我的建議是,你可以自動化所有可能的自動化。讓人類做他們擅長的事情,比如回答「這個看起來對不對?」或「這是否可用?」。對於其他一切,自動化。

+0

這是我想聽到的。但我不確定我們的質量保證人員(甚至是我自己)是否會購買我們可以信任自動化套件的產品。 – bhazzard 2010-04-29 13:59:37

+1

很明顯,你絕對不能100%測試自動化套件,但我已經和很多人類測試人員合作過了,我不會100%信任他們。 – 2010-04-29 14:40:53

+1

@Jim Kiley:你說得很對。自動化測試的優勢在於您可以合理確保每次運行完全一樣。對於人類,特別是被迫一次又一次地進行相同手動測試的人來說,很容易犯錯誤。手動測試可能令人頭腦麻木。 – 2010-04-29 17:18:35

4

+1給Jim推薦手動測試UI元素;使用UI自動化工具創建測試相對容易,但需要設計一個足夠強大且全面的測試框架,以最大限度地減少測試的維護,這需要很多思考和預期。

如果需要優先考慮,一對夫婦的我已經習慣identfiy會從另外的測試中受益最大的非UI方面的技術是:

  1. 看看以前版本的bug報告,尤其是如果您有權訪問客戶報告的錯誤。一些特定的功能區域通常會佔據大部分錯誤。
  2. 當您運行現有的自動化測試時,請使用代碼覆蓋工具,並記下覆蓋很少或沒有覆蓋的區域。
5

看看Mike Cohn的文章Test Automation Pyramid。具體來說,考慮真正需要以這種方式測試UI的哪一部分。例如,角落案例通常通過服務層得到更好的測試。

+1

什麼是用於測試服務層的有效工具?我們應該使用傳統的XUnit測試框架還是更多的BDD風格的基於小黃瓜的框架(即Cucumber或SpecFlow)? – bhazzard 2010-04-29 14:07:18

1

手動測試任何新功能以確保其符合要求,然後將其添加到自動化套件以進行迴歸,這並不會帶來任何負面影響。 (或者它太傳統了?)

4

手動測試能做到以下幾點,不像自動化測試:運行測試時

  • GUI測試
  • 可用性測試
  • 探索性測試
  • 使用變化
  • 尋找新的,不迴歸bug
  • 人眼可以注意到所有問題。自動測試只驗證幾件事情。

自動化測試可以做到以下幾點,不像手動測試:

  • 壓力/負載測試
  • 你甚至可以使用一個自動化測試套件來測試性能
  • 配置測試(恕我直言,這是最有利)。 寫完後,您可以在不同環境下使用不同設置運行相同的測試,並發現您從未想過的隱藏依賴項。
  • 您可以對數千個輸入數據運行相同的測試。 在手動測試的情況下,您必須使用不同的技術選擇最小的一組輸入數據。

此外,在自動測試中犯錯誤更容易,然後更可能在手動測試過程中犯錯。 我建議你自動化最有價值的功能,但在重要版本之前手動運行測試(至少理智)。

+0

加1以獲得詳細回覆。 – bhazzard 2010-06-13 14:33:29

相關問題