用ABP只要加人即可馬上加快項目進展(二) - 分工篇

2018年和1998年其中兩大區別就是:

1. 前端蓬勃發展, 前后端分離是一個十分大的趨勢.
2. 專門的測試人員角色被取消, 多出了一個很重要的角色, 產品經理

 

ABP只要加入即可馬上加快項目進展, 選擇前后端+產品經理分工結構會比前面的全棧篇好十分多!!! 因為:

1. 分工協作和流水線作業工作效率會遠遠比傳統的個人全能型先進很多, 這個道理很多同學都懂, 我就不贅述了.
2. 前端快速和迅猛發展, 6個月發布一次大版本, 瀏覽器6周發布一次小版本, 導致傳統程序員光是學習新技術就已經很吃力, 要談精通更難了.請欣賞此圖:
3. 招人擴展團隊加快項目進度更容易了!!! 這才是重點!!!
   流水線作業減低每個人的技術難度, 讓招人和培訓新手更容易
   招校招生上手難度降低, 更容易招聘和更快能夠有產出
   招社招生更容易, 質量更高, 特別現在是前端爆發期

 

接下來說說是怎么流水線作業的.

 

考慮到並不是所有同學都運用過BDD, 有很多同學只用過TDD的. 所以我分成兩套流水線作業講述. 

先說第一套沒有BDD只有TDD的流水線作業工序吧:

1. 前后端一起定義接口
2. 后端寫好C# interfaces用Swagger生成接口文檔
3. 前端將后端寫好的接口用refresh.bat生成前端ts proxy
4. 前后端各自干各自的活

 

以上流水線自然而然就運用了如下技術思想和技術點, 避免為了技術而技術, 為了思想而思想:

1. TDD
2. IOC/Mock
3. Interface

讓技術和思想自然而然的為你服務, 而不是你為技術和思想服務.

 

大家看到, 在第一套流水線里面, 產品經理並沒有參與進來. TDD是由開發人員寫的, 與產品經理無關.

而在接下來的第二套流水線里, 產品經理通過運用BDD參與進來了:

1. 前端根據產品經理寫好的Specflow的.feature文件用cucumber寫BDD代碼
2. 前后端一起定義接口和實現BDD的step definition代碼
3. 后端寫好C# interfaces用Swagger生成接口文檔
4. 前端將后端寫好的接口用refresh.bat生成前端ts proxy
5. 前后端各自干各自的活


這么說有可能會比較抽象, 在往后的日子里我會增加具體實際操作文章和視頻.

 

與第一套流水線相比:

1. 產品經理參與進來, 給開發人員寫明了詳細操作步驟級的測試結構代碼.
2. 開發人員不需要思考詳細操作步驟, 只需要實現具體每個操作步驟.
3. 每個操作步驟是獨立分割的, 遇到項目緊急時, 通過臨時調人加人來加快項目進度變得更可行.
4. BDD與TDD相比, 天然的具備了結構性, 避免書寫重復代碼, 減少了測試代碼的書寫量.
5. 很多公共的測試代碼可以分割出來, 讓專門的技術專家去寫 (這會在后面一節里提到)

 

可以看到, 第二套流水線比第一套流水線先進十分多.

 

那么有個問題, 產品經理有能力寫BDD嗎? 

從目前市場現狀來看, 從測試人員改行過來做產品經理的, 是十分有能力寫好BDD的.

反而開發人員很難寫好BDD, 甚至寫好TDD都很困難. 這也是為什么BDD和TDD在很多企業推廣不起來的原因之一, 因為角色和能力錯配了.

 

2010年開始, 行業里面逐步減少測試人員, 到了2015年, 這個趨勢終於成了氣候, 微軟在2015年大量裁減測試人員成了這類現象的里程碑事件.

那么這么多被裁減的測試人員都去哪里了呢? 絕大多數人並沒有離開IT這個這么火的行業, 很多都改為做產品經理了. 他們寫測試用例的能力和寫BDD能力是對標的, 並且切換很容易.

 

在這里要說明一下, 產品經理來源有兩類:

1. 校招/美工/市場銷售轉過來的, 會用Axure等原型設計工具,這種情況應該由三個人結對編程寫BDD.
2. 測試人員改行的, 這種人寫測試用例的能力就很容易很天然的演變為寫BDD的能力 

Talk is cheap, just show your code. 為了更形象的表現出產品經理有能力寫BDD，我貼一個BDD .feature文件示例：

Feature: 登錄
	此文件包含登錄成功和失敗的例子

Scenario: 輸入正確的用戶名和密碼能夠正常登錄
	Given 我來到登錄頁面
	When 輸入用戶名"admin"
	And 輸入密碼"123qwe"
	And 點擊"登錄"按鈕
	Then 跳轉到首頁

Scenario: 輸入正確的用戶名和錯誤的密碼則登錄失敗
	Given 我來到登錄頁面
	When 輸入用戶名"admin"
	And 輸入密碼"111111"
	And 點擊"登錄"按鈕
	Then 依舊停留在登錄頁面
	And 提示"用戶名或密碼錯誤"

Scenario: 輸入錯誤的用戶名則登錄失敗
	Given 我來到登錄頁面
	When 輸入用戶名"admin"
	And 輸入密碼"111111"
	And 點擊"登錄"按鈕
	Then 依舊停留在登錄頁面
	And 提示"用戶名或密碼錯誤"

Scenario: 輸入空的用戶名則提示要輸入空用戶名
	Given 我來到登錄頁面
	And 點擊"登錄"按鈕
	Then 依舊停留在登錄頁面
	And 提示"用戶名必須填寫"

Scenario: 輸入空的密碼則提示要輸入空密碼
	Given 我來到登錄頁面
	When 輸入密碼"admin"
	And 點擊"登錄"按鈕
	Then 依舊停留在登錄頁面
	And 提示"密碼必須填寫"

　　從這個示例我們可以看到，除了少數幾個大家都看得懂的英語單詞外，全部都可以為中文，全部都可以為人類可以識別的語言，沒有一行代碼！不需要產品經理會寫代碼。

除了以上這個好處外，BDD在程序員方面還帶來了天然的很良好的測試代碼結構。讓我們看一下示例：

using TechTalk.SpecFlow;

namespace Bowling.SpecFlowXUnit.StepDefinitions
{
    [Binding]
    public sealed class 公用測試代碼
    {
        [When(@"輸入密碼""(.*)""")]
        public void When輸入密碼(string p0)
        {
            //ScenarioContext.Current.Pending();
            //具體測試代碼
        }

        [Given(@"我來到登錄頁面")]
        public void Given我來到登錄頁面()
        {
            //ScenarioContext.Current.Pending();
            //具體測試代碼
        }

        [When(@"輸入用戶名""(.*)""")]
        public void When輸入用戶名(string admin0)
        {
            //ScenarioContext.Current.Pending();
            //具體測試代碼
        }

        [When(@"點擊""(.*)""按鈕")]
        public void When點擊按鈕(string 登錄0)
        {
            //ScenarioContext.Current.Pending();
            //具體測試代碼
        }

        [Then(@"跳轉到首頁")]
        public void Then跳轉到首頁()
        {
            //ScenarioContext.Current.Pending();
            //具體測試代碼
        }

        [Then(@"依舊停留在登錄頁面")]
        public void Then依舊停留在登錄頁面()
        {
            //ScenarioContext.Current.Pending();
            //具體測試代碼        
        }

        [Then(@"提示""(.*)""")]
        public void Then提示(string 用戶名或密碼錯誤0)
        {
            //ScenarioContext.Current.Pending();
            //具體測試代碼
        }

        [Given(@"點擊""(.*)""按鈕")]
        public void Given點擊按鈕(string 登錄0)
        {
            //ScenarioContext.Current.Pending();
            //具體測試代碼
        }
    }
}

　　從上面示例可以看到，以上代碼結構都可以用Specflow自動生成，程序員不需要像TDD一樣要自己去組織測試代碼結構，這也是BDD優於TDD的很大一個特點。這里有個小秘訣，自動生成之后把Class Name全改為一致然后加上Partial關鍵字就可以有重復Step Definition會編譯不通過提醒。

這系列文章是實戰文章，所以不止止停留在理論上，在實際運用過程中會遇到各種問題。比如：

1. 如何在.NET Core下安裝Specflow.
2. .NET Core里跑Specflow - 可以跑集成測試和單元測試.