在C++環境中優化迴歸測試

爲了避免太多測試，我希望爲質量保證（QA）團隊提供一些提示，指出在開發迭代後哪些功能必須進行迴歸測試。你知道哪些工具可以在C++和Subversion（和Visual Studio）開發環境中實現嗎？有關使用情況在C++環境中優化迴歸測試

詳情：

功能將由開發團隊進入點，通常是類或類方法來定義。說，功能「excel文件導入」由方法定義ImportXcelFile（...）類 FileImporter。
在開發迭代中，開發團隊對某些類的某些方法提交了一些更改。說，這些類的一個間接使用方法 ImportExcelFile（）
在迭代結束時，所有提交由報告生成工具和分析並發表給QA團隊。在我們的示例中， QA團隊被告知功能必須測試「excel文件導入」，，並且其他功能X Y & Z不會更改爲。

很有可能這個工具會使用靜態代碼分析和使用Subversion的API。但它存在嗎？

來源

2009-12-16 Denis Dollfus

G'day，

你所描述的並不是真正的迴歸測試。您只是測試新功能。

迴歸測試是您專門運行完整測試套件的地方，以查看支持您的新功能的代碼是否破壞了先前的代碼。

我會強烈建議閱讀Martin Fowler的優秀論文「Continuous Integration」，它涵蓋了一些你所談論的方面。

它也可能爲您提供更好的工作方式，特別是馬丁在他的論文中提到的CI方面。

編輯：特別是因爲CI有一些隱性的小陷阱，後見之明。例如阻止測試人員試圖測試尚未實現新功能的所有文件的版本。（您確認過去五分鐘內沒有提交）。

再大點是時間上的損失，如果你有一個破碎的構建和不知道它是壞了，直到有人簽出代碼，然後嘗試構建它，以便他們可以測試它。

如果它壞了，你現在有：

測試人員圍坐無法做到計劃的檢測，
開發打斷他們目前的工作回到以前的工作理清什麼引起的打破構建。更可能是開發人員，因爲問題是兩個獨立部分之間的交互，每個部分都獨立工作。
由於開發人員不得不重新回到前一部分工作的思維而導致的時間損失，以及開發人員重新陷入他們所從事的新工作的思維的時間損失在中斷前進行調查。

CI的基本思想是在一天中對整個產品進行幾次構建，以便儘早捕獲破損的構建。您甚至可以選擇一些測試來檢查產品的基本功能是否仍然有效。再次儘快通知您的構建的當前狀態存在問題。

編輯：至於你的問題，你完成測試後如何標記庫TESTS_COMPLETE_2009_12_16。那麼當你準備研究下一組測試在最新的測試之間完成標記和HEAD之間的「svn diff -r」是什麼？

HTH

順便說一句，因爲我認爲他們我會更新這個答案與一些進一步的建議。

歡呼聲，

來源

2009-12-16 10:12:08

Rob，謝謝你的回答。其實我知道並支持Martin Fowler的出版物，我們正在使用持續集成，包括自動化單元測試。這裏的關鍵是我們還有一個單獨的QA團隊，專注於測試功能 - 就XP而言的「故事」。我們希望能夠引導他們在多次提交之後重新測試哪些故事，特別是爲了防止「過度測試」那些不可能倒退的故事。 – 2009-12-16 13:01:39

@Denis，歡呼聲。你的開發人員可以標記單個用戶故事的提交嗎？當故事完成時進行一次提交可能是危險的（如由於本地副本丟失而導致潛在的工作損失）並且不靈活。我建議可能在美國完成並提交時標記存儲庫。順便說一句，我希望我有一美元，每次有人說「不可能倒退」，當我明白了！（ - ： – 2009-12-16 13:07:44

將您的項目拆分爲單獨的可執行文件並構建它們。

如果依賴關係發生變化，Make會重建任何可執行文件。

將任何鏈接測試的輸出文件添加到下一個測試的依賴項 - 例如，保存文件測試的輸出作爲讀取文件測試的依賴項。

在此之後構建的任何東西都需要進行單元測試。

如果任何庫文件使用共同的可用資源（堆內存，磁盤，全局互斥等），將它們也作爲依賴項添加，因爲由於一個庫中的泄漏導致的耗盡往往是另一個庫中的迴歸失敗。

在某個點之後建立的任何東西都需要回歸測試。

除非你在保證缺乏資源耗盡的環境下工作（例如TinyC），否則你將最終迴歸測試一切。迴歸測試不是單元測試。

來源

2009-12-16 11:43:58

在C++環境中優化迴歸測試

回答

相關問題