單元測試和驗收測試是否足夠？

Question

如果我對每個類和/或成員函數進行單元測試併爲每個用戶故事進行驗收測試，我是否有足夠的測試來確保項目按預期運行？

例如，如果我對某個功能進行單元測試和驗收測試，我還需要進行集成測試還是單元測試和驗收測試應覆蓋相同的接地？測試類型之間是否有重疊？

我在這裏談論自動化測試。我知道手動測試仍然需要易用性等。

Answer 1

我推薦閱讀2nd edition of Code Complete中的第20-22章。它非常好地覆蓋了軟件質量。

下面是一些關鍵點的快速擊穿（全部歸功於麥康奈爾，2004）

Chapter 20 - 軟件品質景觀：

• 沒有一個單一的缺陷檢測技術是完全有效的本身
• 你發現一個缺陷越早，就越交織它會成爲你的代碼的休息和損傷少就會造成

Chapter 21 - 合作建設：

• 協同發展的做法往往會發現缺陷的百分比高於測試，並更有效地找到他們
• 協同發展的做法往往會發現不同類型的錯誤比測試呢，這意味着你需要同時使用審查和測試，以確保軟件的質量
• 結對編程通常花費大約相同的檢查，併產生類似的質量代碼

Chapter 22 - 開發人員測試：

• 自動化測試是在一般的有用，是迴歸測試
• 改善的最好方法必不可少的測試過程，使之有規律，衡量它，並使用你所學到的以提高它
• 編寫測試用例的代碼所花的時間和精力相同數量的代碼之後編寫測試用例之前，但它縮短缺陷檢測調試校正週期（測試驅動開發）

就您如何制定單元測試而言，您應該考慮基礎測試，數據流分析，邊界分析等。所有這些都在本書中進行了詳細解釋（其中還包括許多其他參考資料以供進一步閱讀）。

也許這不完全是你問的，但我會說自動化測試絕對不足以應付一種策略。你還應該考慮配對編程，正式評論（或非正式評論，取決於項目規模）以及測試腳手架以及自動化測試（單元測試，迴歸測試等）。

Answer 2

多個測試周期的想法是在事情發生變化時儘早發現問題。

單元測試應由開發者完成，以確保單元單獨工作。

驗收測試應由客戶完成，以確保系統符合要求。

但是，在這兩點之間也發生了一些變化，這些點也應該進行測試。這是在將產品交付給客戶之前將其集成到產品中。

這應該首先由產品創建者測試，而不是客戶端。當你吸引客戶的那一刻，事情就會變慢，所以在他們弄骯髒的小手之前，你可以做的修復越多越好。

在大型商店（如我們的）中，在交付產品發生變化的每個點都有單元測試，集成測試，全球化測試，主構建測試等。只有所有高嚴重性錯誤都得到修復（並且制定了修復低優先級錯誤的計劃），我們纔會向我們的測試版客戶釋放產品。

我們做不想給他們一個狡猾的產品僅僅是因爲固定在那個階段的一個錯誤是貴了不少（尤其是在文案方面）比我們在內部做。

Answer 3

根據您是否對每種方法和功能進行測試，知道您是否有足夠的測試是不可能的。通常我會將測試與覆蓋率分析結合起來，以確保我的所有代碼路徑都在我的單元測試中執行。即使這樣做還不夠，但它可以作爲您引入未經測試的代碼的指南。這應該表明需要編寫更多的測試，或者如果您正在進行TDD，則需要放慢腳步並更加嚴謹。 :-)

測試應該包括好的和壞的路徑，尤其是在單元測試中。您的驗收測試可能更多或更少關注不良路徑行爲，但至少應解決可能出現的常見錯誤。根據你的故事的完整性，驗收測試可能會或可能不足。驗收測試和故事之間通常存在多對一的關係。如果每個故事只有一個自動驗收測試，那麼除非您有不同的故事供您選擇，否則您可能沒有足夠的空間。

Answer 4

集成測試適用於您的代碼與其他系統（如第三方應用程序）或其他內部系統（如環境，數據庫等）集成的情況。使用集成測試來確保代碼的行爲仍然符合預期。

Answer 5

如果我對每個類和/或成員函數進行了單元測試，並且對每個用戶故事都進行了驗收測試，我是否有足夠的測試來確保項目按預期運行？

編號測試只能驗證你的想法。不是你沒有想到的。

Answer 6

多層測試可能非常有用。單元測試，以確保件的行爲;整合以表明合作單位集羣如預期那樣合作，以及「驗收」測試表明該方案按照預期發揮作用。每個人在開發過程中都會遇到問題重疊本身不是一件壞事，儘管它太多會變成浪費。

這就是說，可悲的事實是，你永遠不能確保產品的行爲「如預期」，因爲期望是一個變幻莫測的人類事物，在紙上翻譯得很差。良好的測試覆蓋率不會阻止客戶說「這不符合我的想法......」。頻繁的反饋循環有助於此。考慮將頻繁演示作爲「理性測試」添加到您的手動組合中。

Answer 7

總之沒有。

首先，你的故事卡應該有驗收標準。也就是說，產品所有者與分析師一起指定接受標準，規定所要求的行爲，如果符合，故事卡將被接受。

驗收標準應推動自動化單元測試（通過TDD完成）以及應該每日運行的自動化迴歸/功能測試。請記住，我們希望將缺陷移動到左側，也就是說，我們越早發現它們越便宜，越快修復。此外，持續測試使我們能夠放心地重構。這是保持可持續的發展速度所必需的。

另外，您需要自動執行性能測試。每天或每隔一天運行一次探查器將提供有關CPU和內存消耗以及是否存在內存泄漏的信息。此外，像loadrunner這樣的工具將使您能夠在系統上加載反映實際使用情況的負載。您將能夠測量生產中的響應時間以及CPU和內存消耗，例如運行loadrunner的機器。

自動性能測試應該反映應用程序的實際使用情況。您可以衡量業務事務的數量（即，如果Web應用程序單擊頁面並響應用戶或往返服務器）。並確定這種交易的組合以及他們每秒到達的房價。這些信息將使您能夠正確設計性能測試應用程序所需的自動化loadrunner測試。通常情況下，一些性能問題將追溯到應用程序的實現，而其他性能問題將由服務器環境的配置決定。

請記住，您的應用程序將進行性能測試。問題是，第一次性能測試會在您發佈軟件之前或之後發生。相信我，生產中出現性能問題的地方更糟。性能問題可能是最難解決的問題，並可能導致部署到所有用戶失敗，從而取消項目。

最後，有用戶驗收測試（UAT）。這些測試是由生產所有者/業務合作伙伴設計的，用於在發佈前測試整個系統。通常，由於所有其他測試，應用程序在UAT期間返回零缺陷並不罕見。

Answer 8

這取決於你的系統有多複雜。如果您的驗收測試（滿足客戶要求）從前向後運用您的系統，那麼您不會。但是，如果您的產品依賴於其他層（如後端中間件/數據庫），那麼您確實需要一個測試來證明您的產品可以愉快地鏈接到端到端。

正如其他人所評論的，測試並不一定證明項目的功能如預期的那樣，只是您希望如何運作。

對客戶和/或以客戶理解的方式（例如在BDD style中）進行分析的測試的頻繁反饋循環確實可以提供幫助。

Answer 9

從技術上講，全套的驗收測試應該涵蓋所有的內容。話雖如此，但對於大多數定義來說，它們還不夠「。通過進行單元測試和集成測試，您可以更早地以更本地化的方式捕獲錯誤/問題，使其更容易分析和修復。

想象一下，手動執行的測試的完整套裝，寫在紙上的說明足以驗證一切按預期工作。但是，如果您可以自動執行測試，那麼您會更好，因爲它使測試變得更容易。紙質版本是「完整的」，但不是「足夠的」。以同樣的方式，每層測試都增加了「足夠」的值。

還值得注意的是，不同的測試集傾向於從不同的「觀點」測試產品/代碼。與質量保證一樣，QA可能會挑選出從未想過要測試的錯誤，但一組測試可能會發現其他組不會測試的錯誤。

Answer 10

如果我爲每個類 和/或成員函數和驗收測試 爲每個用戶故事的單元測試我有足夠 測試，以確保該項目 按預期？

這足以顯示你的軟件是功能正確，至少不亞於你的測試覆蓋率就足夠了。現在，根據您正在開發的內容，肯定存在重要的非功能性需求，請考慮可靠性，性能和可靠性。

Answer 11

可能不會，除非你的軟件真的很簡單，只有一個組件。

單元測試是非常具體的，你應該與他們徹底掩蓋一切。在這裏尋求高代碼覆蓋率。但是，它們一次只涵蓋一項功能，而不是一起工作。驗收測試應該只涵蓋客戶真正關心的高層次問題，雖然它會捕捉到一些事情如何協同工作的一些錯誤，但它不會抓住所有事情，因爲編寫這些測試的人不會深入瞭解系統。

最重要的是，這些測試可能不是由測試人員編寫的。單元測試應該由開發人員編寫，並且由開發人員（以及構建系統，理想情況下）經常運行（最多每隔幾分鐘，取決於編碼風格）。驗收測試通常由客戶或代表客戶的人撰寫，考慮客戶的重要性。但是，您還需要測試人員編寫的測試，像測試人員那樣思考（而不是像開發人員或客戶）。

你還應該考慮以下各種各樣的測試，一般都寫測試人員：

• 功能測試，將涵蓋的功能件。這可能包括API測試和組件級別的測試。您通常也希望在這裏有良好的代碼覆蓋率。
• 集成測試，將兩個或更多的組件放在一起，以確保它們一起工作。例如，當另一個組件需要對象的計數（基於「第n個對象」，基於1）時，您不希望一個組件放置對象所在的數組中的位置（基於從0開始）。在這裏，重點不在於代碼覆蓋範圍，而是覆蓋組件之間的接口（通用接口，而不是代碼接口）。
• 系統級測試，將所有內容放在一起並確保它可以端到端地工作。測試非功能性功能，如性能，可靠性，可擴展性，安全性和用戶友好性（還有其他;不是所有的都與每個項目有關）。

Answer 12

驗收測試甚至可以由客戶手動進行，如果系統在手很小。

單位和小型集成測試（包括單元測試）可以幫助您構建可持續發展的系統。

不要嘗試爲系統的每個部分編寫測試。這是脆弱的（容易打破）和壓倒性的。

決定系統的關鍵部分需要花費太多時間來手動測試和寫入驗收測試，僅針對那些部件來讓所有人都變得輕鬆。