日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關咨詢
選擇下列產(chǎn)品馬上在線溝通
服務時間：8:30-17:00
你可能遇到了下面的問題
關閉右側工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
復雜系統(tǒng)如何保障代碼質量？讓測試先行

一 業(yè)務背景

高德在線導航服務作為有很強業(yè)務特性和多年歷史積累的存量系統(tǒng)，不可避免的存在大量的不合理代碼，而業(yè)務演進對系統(tǒng)性能、算法、底層架構等不斷提出更高要求，存量的各種業(yè)務代碼和算法、架構快速演進的訴求存在嚴重沖突，如何有效保障質量地進行快速重構式演進，成為業(yè)務發(fā)展面臨的首要工程難題。

二 現(xiàn)有質量保障方法問題與分析

1 現(xiàn)有測試方法的問題

常規(guī)方法是對新老服務批量進行請求比較diff，這種方式簡單有效，是我們一直在用的方法，但存在以下問題：

  • 無效diff問題：以公交規(guī)劃引擎為例，依賴步導引擎、搜索、公交突發(fā)事件、路況等多個下游服務，獲取結果的差異導致很多無效diff。
  • 運行時間較長：case量較多時運行時間較長，在10分鐘級別。由于這一步成本較高，一般開發(fā)人員跑diff的頻率不會太高，無法進行"每次一小步"的測試。
  • 排查困難：當發(fā)現(xiàn)diff后進行排查非常困難，因為是整個請求級別的diff，中間步驟可能都存在問題。

2 業(yè)界主流方法實踐

ThoughtWorks、Google等公司使用TDD方式進行敏捷開發(fā)，通過編寫單元測試用例保障開發(fā)、重構的質量，目前已經(jīng)成為主流最佳實踐。

三 單元測試介紹

1 什么是單元測試?

單元測試是對一個模塊、一個函數(shù)或者一個類進行正確性檢驗的測試工作。

測試的粒度更小更輕量，運行時間在秒級，特別適合漸進式重構中的"每次一小步"的質量保障。

由于單元測試用例針對的是一個函數(shù)、類更細粒度的目標，所以當某個用例不通過時，可以快速鎖定問題點。

2 單元測試框架

常見單元測試框架有 xUnit 系列，多種語言都有對應實現(xiàn)，如CppUnit、JUnit、NUnit...

GTest是Google開發(fā)的單元測試框架，此框架具有一些高級功能，如death test, mock等。

我們選擇的是GTest框架。

3 單元測試、重構、TDD與敏捷

TDD(Test Driven Development)是強調測試先行的開發(fā)方式，這種方式的好處在于編寫任何函數(shù)、修改任何代碼時可以通過編寫一個單元測試用例代碼來表達要實現(xiàn)的代碼功能，一個測試用例本身就是一個代碼表達的需求。而積累起來的測試用例可以有效保障開發(fā)及后續(xù)重構演進的質量。

重構和TDD是敏捷方法的核心構成要素，脫離了TDD的敏捷是危險的，沒有用例保障的重構一旦啟動，就像一匹脫韁的野馬。而單元測試和TDD則是縛住野馬的韁繩。

四 公交服務單元測試實踐

1 GTest框架集成

Git庫地址：https://github.com/google/googletest

GTest框架集成非常簡單，把googletest庫加入到工程中, 增加鏈接 libgtest 即可：

通過如下代碼即可驅動用例執(zhí)行：

 
 
 
 
    
  
  
  
  
  1. int RCUnitTest::Excute()
    2. 
  
  
  
  
  2. {
    3. 
  
  
  
  
  3.   int argc = 2;
    4. 
  
  
  
  
  4.   char* argv[] = {const_cast(""), const_cast("--gtest_output=\"xml:./testAll.xml\"")};
    5. 
  
  
  
  
  5.   ::testing::InitGoogleTest(&argc, argv);
    6. 
  
  
  
  
  6. 
  
  
  
  
  7.   return RUN_ALL_TESTS();
    8.

開關控制：為避免影響到正式版本, 可以考慮通過編譯控制，也可以增加一個配置項開關。

我們在使用時是在入口處通過一個配置項控制是否觸發(fā)單元測試用例，編譯時默認只鏈接入口文件，需要運行單元測試時添加上單元測試用例文件進行鏈接運行。

2 測試代碼編寫

通過實現(xiàn)一個Test類的派生類，然后使用TEST_F宏添加測試函數(shù)即可，如下示例：

 
 
 
 
    
  
  
  
  
  1. class DateTimeUtilTest : public ::testing::Test
    2. 
  
  
  
  
  2. {
    3. 
  
  
  
  
  3. protected:
    4. 
  
  
  
  
  4.     virtual void SetUp()
    5. 
  
  
  
  
  5. {
    6. 
  
  
  
  
  6.     }
    7. 
  
  
  
  
  7. 
  
  
  
  
  8. virtual void TearDown()
    9. 
  
  
  
  
  9. {
    10. 
  
  
  
  
  10.     }
    11. 
  
  
  
  
  11. };
    12. 
  
  
  
  
  12. 
  
  
  
  
  13. TEST_F(DateTimeUtilTest, TestAddSeconds_leap)
    14. 
  
  
  
  
  14. {
    15. 
  
  
  
  
  15.     //閏年測試 2020-02-28
    16. 
  
  
  
  
  16.     tm tt;
    17. 
  
  
  
  
  17.     tt.tm_year = (2020 - 1900);
    18. 
  
  
  
  
  18.     tt.tm_mon = 1;
    19. 
  
  
  
  
  19.     tt.tm_mday = 28;
    20. 
  
  
  
  
  20.     tt.tm_hour = 23;
    21. 
  
  
  
  
  21.     tt.tm_min = 59;
    22. 
  
  
  
  
  22.     tt.tm_sec = 50;
    23. 
  
  
  
  
  23. 
  
  
  
  
  24.     DateTimeUtil::AddSeconds(tt, 30);
    25. 
  
  
  
  
  25.     EXPECT_TRUE(tt.tm_sec == 20);
    26. 
  
  
  
  
  26.     EXPECT_TRUE(tt.tm_min == 0);
    27. 
  
  
  
  
  27.     EXPECT_TRUE(tt.tm_hour == 0);
    28. 
  
  
  
  
  28.     EXPECT_TRUE(tt.tm_mday == 29);
    29. 
  
  
  
  
  29.     EXPECT_TRUE(tt.tm_mon == 1);
    30. 
  
  
  
  
  30. 
  
  
  
  
  31.     //非閏年測試 2019-02-28
    32. 
  
  
  
  
  32.     tm tt1;
    33. 
  
  
  
  
  33.     tt1.tm_year = (2019 - 1900);
    34. 
  
  
  
  
  34.     tt1.tm_mon = 1;
    35. 
  
  
  
  
  35.     tt1.tm_mday = 28;
    36. 
  
  
  
  
  36.     tt1.tm_hour = 23;
    37. 
  
  
  
  
  37.     tt1.tm_min = 59;
    38. 
  
  
  
  
  38.     tt1.tm_sec = 50;
    39. 
  
  
  
  
  39.     DateTimeUtil::AddSeconds(tt1, 30);
    40. 
  
  
  
  
  40.     EXPECT_TRUE(tt1.tm_sec == 20);
    41. 
  
  
  
  
  41.     EXPECT_TRUE(tt1.tm_min == 0);
    42. 
  
  
  
  
  42.     EXPECT_TRUE(tt1.tm_hour == 0);
    43. 
  
  
  
  
  43.     EXPECT_TRUE(tt1.tm_mday == 1);
    44. 
  
  
  
  
  44.     EXPECT_TRUE(tt1.tm_mon == 2);
    45. 
  
  
  
  
  45. };
    46.

測試用例執(zhí)行效果：

目前公交引擎已經(jīng)積累了23個模塊測試用例，基本覆蓋了尋站、尋路、ETA、票價、風險停運等核心功能，持續(xù)積累中。通過單元測試保障，每個版本開發(fā)活動中都在進行漸進式重構活動，能夠有效保障質量，提測迭代次數(shù)和線上新增代碼引入問題數(shù)量持續(xù)較低。

3 問題與難點

數(shù)據(jù)依賴問題

在線導航引擎是對數(shù)據(jù)重度依賴的業(yè)務，多組數(shù)據(jù)結構之間互相關聯(lián)，字段繁多，很難脫離數(shù)據(jù)構建有效的單元測試。通過mock方式構造假數(shù)據(jù)成本很高。而數(shù)據(jù)變化將導致用例不能通過。

我的實踐：

能夠簡單構造假數(shù)據(jù)的通過構造假數(shù)據(jù)來搞定。

對于很難構建假數(shù)據(jù)的情況，直接使用真實數(shù)據(jù)即可。數(shù)據(jù)變化可能導致這部分用例不通過，沒有關系，只需要保障在每次重構前把相關的用例調通即可，這樣仍可以確保重構過程的質量。即：不需要做到用例隨時隨地都能運行通過，而是保證重構前后都可以通過。

4 常見錯誤認知

對于沒有真正實踐過單元測試和TDD開發(fā)方式的同學來說，有一些認知上的常見誤區(qū)，比如：

開發(fā)時間都不夠, 哪有時間編寫單元測試?

我的理解：

  • 首先TDD的開發(fā)方式強調的是測試先行，編寫測試代碼是在前面的，這個過程等于是理解需求的過程。即想清楚你要實現(xiàn)的是什么功能?這個測試代碼是理清需求的產(chǎn)物， 如此而已，不存在更多時間成本。
  • TDD開發(fā)方式屬于典型的一次投入，持續(xù)受益的事情，用例積累越多，越容易在早期發(fā)現(xiàn)問題，重構有了質量保障，代碼越來越整潔清晰，開發(fā)同學們再也不用哀嘆歷史代碼。

歷史代碼那么多，怎么補單元測試?

那就從添加第一個用例開始。我的做法是對應本次修改涉及到的代碼添加用例，逐步積累。

添加用例的過程是理解現(xiàn)有代碼的過程，對于存量的歷史代碼，各種硬性編碼侵入，各種耦合，全局變量或長生命周期大對象，通過編寫單元測試用例能夠有效理清函數(shù)真正的輸入輸出，也為重構增加了有效保障。

五 存量復雜系統(tǒng)代碼漸進式重構

對于我們一線碼農(nóng)，每天大部分時間都在和代碼打交道，如果你維護的代碼結構合理、易讀易擴展，那么恭喜你!但大部分情況我們面對的是存在各種歷史"積淀"的存量工程，各種牽一發(fā)而動全身，這種情況下小改動還可以靠多花時間，認真仔細來搞定，但想要做一些大的系統(tǒng)升級就難了。

而對于巨型業(yè)務系統(tǒng)來說，重寫在成本和質量控制方面顯得更不現(xiàn)實。那么設置幾個大的節(jié)點，通過漸進式重構逐漸優(yōu)化，變量變?yōu)橘|變，是綜合來看最優(yōu)的方式。

而單元測試和TDD，則是漸進式重構有效開展的必選方法。


分享題目：復雜系統(tǒng)如何保障代碼質量？讓測試先行
文章出自：http://www.5511xx.com/article/cdggddg.html