原文鏈接：https://joven.site/PreliminaryStudyOnTestDesign/

測試設(shè)計的初探

TDD：測試驅(qū)動開發(fā)（Test-Driven Development）
BDD：行為驅(qū)動開發(fā)（Behavior Driven Development）
ATDD：驗收測試驅(qū)動開發(fā)（Acceptance Test Driven Development）
DDD：領(lǐng)域驅(qū)動開發(fā)（Domain Drive Design）

通過下面一幅圖就可以發(fā)現(xiàn)對于測試也有不同的層次和流程：

　　從圖中可以發(fā)現(xiàn)，最下面的是單元測試（白盒測試），主要用于測試開發(fā)人員編寫的代碼是否正確，這部分工作都是開發(fā)人員自己來做的。通常而言，一個單元測試是用于判斷某個特定條件（或者場景）下某個特定函數(shù)的行為。再往上，就是BDD（灰盒測試、黑盒測試），主要用于測試代碼是否符合客戶的需求，這里的BDD更加側(cè)重于代碼的功能邏輯。

　　從左邊的范疇也可以看出，測試的范圍也是逐層擴大，從單元測試的類到BDD里面的服務(wù)、控制器等，再到最上層的模擬實際操作場景的Selenium（Selenium也是一個用于Web應(yīng)用程序測試的工具。Selenium測試直接運行在瀏覽器中，就像真正的用戶在操作一樣。）對于包括UI界面的測試。

TDD

TDD指的是Test Drive Development，很明顯的意思是測試驅(qū)動開發(fā)，也就是說我們可以從測試的角度來檢驗整個項目。大概的流程是先針對每個功能點抽象出接口代碼，然后編寫單元測試代碼，接下來實現(xiàn)接口，運行單元測試代碼，循環(huán)此過程，直到整個單元測試都通過。這一點和敏捷開發(fā)有類似之處。

它是一種測試先于編寫代碼的思想用于指導(dǎo)軟件開發(fā)。測試驅(qū)動開發(fā)是敏捷開發(fā)中的一項核心實踐和技術(shù)，也是一種設(shè)計方法論。TDD的原理是在開發(fā)功能代碼之前，先編寫單元測試用例代碼，測試代碼確定需要編寫什么產(chǎn)品代碼。

TDD的好處自然不用多說，它能讓你減少程序邏輯方面的錯誤，盡可能的減少項目中的bug，開始接觸編程的時候我們大都有過這樣的體驗，可能你覺得完成得很完美，自我感覺良好，但是實際測試或者應(yīng)用的時候才發(fā)現(xiàn)里面可能存在一堆bug，或者存在設(shè)計問題，或者更嚴(yán)重的邏輯問題，而TDD正好可以幫助我們盡量減少類似事件的發(fā)生。而且現(xiàn)在大行其道的一些模式對TDD的支持都非常不錯，比如MVC和MVP等。

但是并不是所有的項目都適合TDD這種模式的，我覺得必須具備以下幾個條件。

需求必須足夠清晰
程序員對整個需求有足夠的了解

如果這個條件不滿足，那么執(zhí)行的過程中難免失控。當(dāng)然，要達到這個目標(biāo)也是需要做一定功課的，這要求我們前期的需求分析以及HLD和LLD都要做得足夠的細(xì)致和完善。

其次，取決于項目的復(fù)雜度和依賴性，對于一個業(yè)務(wù)模型及其復(fù)雜、內(nèi)部模塊之間的相互依賴性非常強的項目，采用TDD反而會得不嘗失，這會導(dǎo)致程序員在拆分接口和寫測試代碼的時候工作量非常大。另外，由于模塊之間的依賴性太強，我們在寫測試代碼的時候可能不采取一些橋接模式來實現(xiàn)，這樣勢必加大了程序員的工作量。

特點

有利于更加專注軟件設(shè)計；
清晰地了解軟件的需求；
很好的詮釋了代碼即文檔。

相關(guān)文章

初步認(rèn)識TDD:https://www.cnblogs.com/wfsovereign/p/4198209.html
TDD和BDD及DDD的解說:https://blog.csdn.net/bennes/article/details/47973129
TDD 已死？讓我們再聊聊TDD:http://blog.jobbole.com/110560/

BDD

特點

縮小團隊成員之間溝通差距
促進對客戶需求的理解,并促進對實際需求的持續(xù)溝通

Behavior Driven Development，行為驅(qū)動開發(fā)是一種敏捷軟件開發(fā)的技術(shù)，它鼓勵軟件項目中的開發(fā)者、QA和非技術(shù)人員或商業(yè)參與者之間的協(xié)作。

BDD是一種敏捷軟件開發(fā)的技術(shù)。它對TDD的理念進行了擴展，在TDD中側(cè)重點偏向開發(fā)，通過測試用例來規(guī)范約束開發(fā)者編寫出質(zhì)量更高、bug更少的代碼。而BDD更加側(cè)重設(shè)計，其要求在設(shè)計測試用例的時候?qū)ο到y(tǒng)進行定義，倡導(dǎo)使用通用的語言將系統(tǒng)的行為描述出來，將系統(tǒng)設(shè)計和測試用例結(jié)合起來，從而以此為驅(qū)動進行開發(fā)工作。

BDD的通用語言是一種近乎自然語言的描述軟件的形式。傳統(tǒng)的開發(fā)模式中，客戶很難從技術(shù)層面理解問題，開發(fā)人員很難從業(yè)務(wù)需求考慮問題，基于這種通用語言形式可以盡可能的避免客戶和開發(fā)者在溝通上的障礙，實現(xiàn)客戶和開發(fā)者同時定義系統(tǒng)的需求。避免了因為理解需求不充分而帶來的不必必要的工作量。

BDD描述的行為就像一個個的故事(Story)，系統(tǒng)業(yè)務(wù)專家、開發(fā)者、測試人員一起合作，分析軟件的需求，然后將這些需求寫成一個個的故事。開發(fā)者負(fù)責(zé)填充這些故事的內(nèi)容，測試者負(fù)責(zé)檢驗這些故事的結(jié)果。通常，會使用一個故事的模板來對故事進行描述

# 關(guān)鍵字：
# Feature(功能)
# Scenario(場景)
# Given(假如), When(當(dāng)), Then(那么), And(而且), But(但是)[Steps]
# Background (背景)
# ScenarioOutline(場景大綱)
# Examples(例子)

# example：

Feature: calculator
    In order to avoid silly mistakes
    As a math idiot
    I want to be told the sum of two numbers
@mytag
Scenario: Add two numbers
    Given I have entered 50 into the calculator
    And I have entered 70 into the calculator
    When I press add
    Then the result should be 120 on the screen

# 中文例子：

功能: 計算器
    為了避免愚蠢的錯誤
    作為一個數(shù)學(xué)白癡
    我想知道兩個數(shù)的和

@mytag
場景: 添加兩個數(shù)字
    假如 我已經(jīng)輸入了第一個數(shù)50到計算器
    而且 我已經(jīng)輸入了第二個數(shù)70到計算器
    當(dāng) 我點擊求和
    那么 結(jié)果應(yīng)該顯示120

常見的BDD框架：

C – Cspec
C++ – CppSpec, Spec-CPP
.Net – NBehave, NSpecify, SpecFlow
Groovy – GSpec, easyb, Cuke4Duke
PHP – PHPSpec
Python – Specipy
Ruby – RSpec, Shoulda, Cucumber

與Java相關(guān)的BDD測試工具：

JBehave – Java annotations based, Test frameworks agnostic
Cuke4duke – Cucumber support for JVM
JDave – RSpec (Ruby) inspired, Mojo 2 & Hamcrest based
beanSpec – Java based
easyb – Java based, Specifications written in Groovy
instinct – BDD framework for Java, providing annotations for contexts. Inspired by Rspec
BDoc - Extracts behaviour from unit tests

來自Leo_wlCnBlogs：https://www.cnblogs.com/Leo_wl/p/4780678.html

HLD & LLD (High Level Design & Low Level Design)

HLD：高層次設(shè)計High Level Design,概要設(shè)計
LLD：低級別設(shè)計Low Level Design,詳細(xì)設(shè)計

高層次設(shè)計（HLD）是整個系統(tǒng)的設(shè)計-包括系統(tǒng)架構(gòu)和數(shù)據(jù)庫設(shè)計。它描述了該系統(tǒng)的各個模塊和功能之間的關(guān)系。 數(shù)據(jù)流，流程圖和數(shù)據(jù)結(jié)構(gòu)下HLD覆蓋。
低級別設(shè)計（LLD）就像是詳細(xì)的HLD。它定義了用于該系統(tǒng)的每個部件的實際邏輯。類圖與類之間的所有方法和關(guān)系。程序規(guī)范是根據(jù)LLD覆蓋。

.net下的測試框架及相關(guān)庫

xUnit.net是一個免費的，開源的，以社區(qū)為中心的.NET Framework單元測試工具。
MSTest是微軟自己寫的一套開源的,測試工具,目前是V2版本.Github:https://github.com/Microsoft/testfx
NUnit是所有.Net語言的單元測試框架。最初從JUnit移植，當(dāng)前的生產(chǎn)版本3已經(jīng)完全重寫了許多新功能并支持各種.NET平臺。
SpecFlow是一個可以將業(yè)務(wù)需求綁定到.NET代碼的工具,并且開源,用于管理和自動執(zhí)行人類可讀的驗收測試.是Cucumber家族的一部分.
Shouldly是一個斷言框架，它專注于在斷言失敗時提供很好的錯誤消息，同時簡單而簡潔。Github:https://github.com/shouldly/shouldly
Cucumber是一種支持行為驅(qū)動開發(fā)（BDD）的工具。遵循Gherkin語法規(guī)則.