開發(fā)和測試工程師寫代碼的高下之分-2

第第頁開發(fā)和測試工程師寫代碼的高下之分開發(fā)和測試工程師寫代碼的高下之分

發(fā)表于：2023-04-18來源：：點(diǎn)擊數(shù)：標(biāo)簽：代碼測試工程師開發(fā)高下

有來javascript:;"onclick="javascript:tagshow(event,'%C3%E6%CA%D4');"target="_self"_base_target="_blank">面試的同行問個一個問題：“如果微軟的開發(fā)和測試工程師都需要寫代碼，那么兩者寫出來的代碼有高下之分嗎？”當(dāng)時我只能簡單的解釋

有來javascript:;"onclick="javascript:tagshow(event,'%C3%E6%CA%D4');"target="_self"_base_target="_blank">（面試）的同行問個一個問題：“如果（微軟）的開發(fā)和（測試）工程師都需要寫代碼，那么兩者寫出來的代碼有高下之分嗎？”

當(dāng)時我只能簡單的解釋一下?，F(xiàn)在可以多說一些了。

舉個例子，（單元測試）。適合不同語言的工具有一大堆，各個論壇上都能搜到大堆文章。出現(xiàn)頻率最高的不外乎CppUnit，NUnit，JUnit三種。比起NUnit和JUnit，CppUnit因為C++語言特性的關(guān)系，用起來較不方便。

這里我給大家秀一下，解決這個問題，測試工程師會如何的“不擇手段”。

單元測試往往需要解決以下幾個問題：

1.用戶能在產(chǎn)品代碼中指定需要測試的函數(shù)

2.用戶能在測試代碼中指定需要執(zhí)行的函數(shù)

3.用戶能指定各種控制執(zhí)行過程的參數(shù)，比如優(yōu)先級、重復(fù)、初始化/清理函數(shù)等等

（其它）就先不說了，待會大家就知道再多的都能做到，現(xiàn)在先做到這三個需求就挺不錯了。需求1是可選的。VisualStudio從2023開始有這個功能，但是如果沒有，估計大家也不會太在意，對吧？

那么，CppUnit如果要做到NUnit和JUnit的樣子會遇到什么困難呢？首先就是C++缺乏反射（Reflection）功能。

你看NUnit和JUnit都是定義了一大堆a(bǔ)ttribute。用戶通過為函數(shù)指定恰當(dāng)?shù)腶ttribute，就能標(biāo)明這個函數(shù)需要作為（test）case執(zhí)行，之前執(zhí)行初始化函數(shù)Setup，之后執(zhí)行Cleanup，還有重復(fù)100次，優(yōu)先級2什么的，其它的往上堆a(bǔ)ttribute就行了。

VisualStudio2023之后為實現(xiàn)需求1，通過.NETReflection找出一個類的全部成員函數(shù)，然后列個表讓你選要測試的函數(shù)，最后代碼架子都給你搭好。

而CppUnit得用模板，還有另外一個我忘了名字的C++單元測試工具用的是宏。他們費(fèi)這么些勁是為了什么呢？其實是為了取得這些信息：

具有特定標(biāo)記的函數(shù)的名字或者入口地址/函數(shù)指針

附加在該函數(shù)上的各種整數(shù)，字符串或者函數(shù)指針的值

拿到之后呢？CppUnit也好，NUnit或JUnit也好，都是按照取得的信息規(guī)劃每個函數(shù)的執(zhí)行，保證異常和錯誤不干擾其它函數(shù)的執(zhí)行，統(tǒng)計整理執(zhí)行結(jié)果和記錄（日志），沒什么區(qū)別。

我們來看看，Reflection對于取得那些信息是不是必需的呢？

沒錯，Reflection是能夠在執(zhí)行時（runtime）取得上述信息，然后在執(zhí)行時利用它指導(dǎo)testcase的執(zhí)行。

等等，我雞蛋里挑個骨頭：非要把“取得信息”和“指導(dǎo)testcase執(zhí)行”放在同一段執(zhí)行時期里面嗎？或者說，先“取得信息”，停一下，再“指導(dǎo)testcase執(zhí)行”，行不行？

甚至，“取得信息”放在一個程序里先執(zhí)行，“指導(dǎo)testcase執(zhí)行”放在另一個程序里后執(zhí)行，又如何？

更甚之，“取得信息”是讓別的程序做的，之后讓“指導(dǎo)testcase執(zhí)行”撿現(xiàn)成的呢？

可見，Reflection提供了比我們所需要的多得多的功能，實際上我們只需要知道“怎樣指導(dǎo)testcase執(zhí)行”就夠了。

那可以如何實現(xiàn)呢？

一、編譯鏈接兩次

對，你沒聽錯！編譯鏈接之后除了可執(zhí)行文件還會產(chǎn)生不少有用信息，最有用的當(dāng)屬PDB文件，包含了所有標(biāo)識符（Symbol）的信息。VisualStudio2023開始就帶有一個DIASDK，可以在其安裝目錄的DIASDK文件夾下面找到頭文件、庫文件、COM組件DLL和示例程序。用它分析一個DLL或者EXE可執(zhí)行文件對應(yīng)的PDB文件，你可以取得每個編譯單元（用.c/.cpp編譯得到的obj或者lib）里全部函數(shù)的情況，包括函數(shù)名字、是否成員函數(shù)、返回類型、全部參數(shù)的名字和類型、全部局部變量的名字和類型，甚至它在哪個文件的哪一行定義。

在這些信息中可以過濾出用戶預(yù)先指定的信息，用來拼成另一個C/C++源文件，這個源文件叫做執(zhí)行表，里面包含了所有需要執(zhí)行函數(shù)的名字列表以及各項參數(shù)的靜態(tài)定義。“指導(dǎo)testcase執(zhí)行”是可以預(yù)先分離實現(xiàn)的模塊，把它include進(jìn)來即可。最后，把原先用來產(chǎn)生可執(zhí)行文件的全部文件，把定義main或者DllMain的那個源文件，改為執(zhí)行表，再編譯鏈接一次，大功告成。

問題是怎樣產(chǎn)生第一個可執(zhí)行文件呢？用戶使用單元測試工具的時候不都實現(xiàn)了一些函數(shù)嗎？那就能產(chǎn)生用戶的編譯單元。我們可以預(yù)先提供一個定義DllMain的殼lib，它與用戶的編譯單元鏈接在一起就成為被DIASDK分析的DLL。然后像前面說的，最后換成執(zhí)行表的編譯單元。

你注意到了嗎，用這個方法，別說CppUnit，做CUnit都可以。

二、用struct表達(dá)attributes

剛才并沒有提到如何像NUnit和JUnit一樣取得attribute所定義的信息。我們要求需要執(zhí)行的函數(shù)定義成返回BOOL類型，只有一個參數(shù)，一個結(jié)構(gòu)的指針。

如果用戶定義的這個結(jié)構(gòu)像這樣

structSIGNATURE_001

{

SIGNATURE_001()

{

constchar*title="Testcase1";

constDWORDpriority=PRIORITY.P1;

constchar*Setup="MySetup";

constchar*Cleanup="MyCleanup";

…

}

};

用DIASDK分析就會發(fā)現(xiàn)，這個函數(shù)的參數(shù)類型具有構(gòu)造函數(shù)，其中有局部的常量名字如何，值多少。依靠這些信息，我們足可以判斷一個函數(shù)是不是需要執(zhí)行，所需要的參數(shù)都是怎么樣。

為了簡化，我們可以用一個簡單的宏幫助定義這一切，放在函數(shù)前面就可以了。當(dāng)然它不是必需的。

在C下面可不能這么用，但辦法還是有的。

三、用解釋表達(dá)attributes

既然我們能把函數(shù)定位到某一行，那么往前掃描源文件行，遇到三個斜杠開頭的就濾掉“///”讀進(jìn)來，如果我們預(yù)期這些解釋看起來是這個樣子

///TestCase

///TitleTestcase1/Title

///Priority1/Priority

///SetupMySetup/Setup

///CleanupMyCleanup/Cleanup

////TestCase

那么只要分析這段XML文本，接下來的事情就跟前面說的一樣了。

四、自動運(yùn)行整個過程

用戶需要的是寫好測試代碼，執(zhí)行一個命令就能得到所有可執(zhí)行代碼。我們可以利用makefile把這一切連接起來：先寫好需要分析的DLL的依賴關(guān)系，然后讓執(zhí)行表依賴上述DLL，命令為執(zhí)行分析代碼產(chǎn)生執(zhí)行表，最后讓目標(biāo)DLL依賴執(zhí)行表即可。又或者用VisualStudio的BuildSteps來驅(qū)動也可以。

到這里，大家可以看到，為了實現(xiàn)最終目的，我們突破了習(xí)慣的限制（只使用語言特性），并且充分利用現(xiàn)有的（技術(shù)）和工具（DIASDK和XMLParser）。只要能實現(xiàn)目的，“無所不用其極”。

你可能覺得折騰這么一套東西動作也挺大的。我得說，“看菜吃飯”。

另一個例子，有一個測試框架，萬事俱備，就是沒法把testcase自動傳送到AppleMacintosh的機(jī)器上。現(xiàn)有的代碼可以讓testcase在AppleMacintosh上執(zhí)行，也可以把testcase從服務(wù)器下載到Windows');"target="_self"_base_target="_blank">（Windows）測試機(jī)器上發(fā)動執(zhí)行，但是沒法跟AppleMacintosh交流。

怎么辦？在Apple上開發(fā)誰都不懂。在AppleMacintosh上寫一個客戶端跟服務(wù)器交流，夠忙半天的了。面對一整套已經(jīng)完備的測試框架，讓它盡快用于新的環(huán)境，比做什么都重要。

別人告訴我，可以AppleMacintosh上開一個共享夾，然后Windows的機(jī)器可以用UNC路徑往里面讀寫文件。

OK，這就足夠了。Windows測試機(jī)器上發(fā)動執(zhí)行的只是一個腳本，把需要用到的文件往指定Apple機(jī)器的共享文件夾上寫。寫完之后再寫一個文件，名字是約定好的，例如“ready”，里面包含啟動testcase的命令行。然后不停的隔一段時間檢查共享文件夾里面一個叫做例如“done”的文件，出現(xiàn)之后把它作為結(jié)果返回服務(wù)器，最后把它和其它文件都刪掉，退出。

AppleMacintosh上面則運(yùn)行另一個腳本，始終不退出。它不停的隔一段時間檢查其指定的共享文件夾里面一個叫做“ready”的文件，出現(xiàn)之后執(zhí)行里面的命令并且等待它結(jié)束。這個命令必須生成一個叫做“done”的文件，包含執(zhí)行結(jié)果。然后，不停的隔一段時間檢查“done”是不是還在，不在了就回到最初的檢查“ready”的代碼。

這就足夠了。兩個腳本加起來50行不到。

你覺得它太粗糙了吧？這么簡單的協(xié)議？

事實上，它并不需要十分健壯。

一、Windows和Macintosh雙方的網(wǎng)絡(luò)文件系統(tǒng)協(xié)議解決了很多問題

二、測試機(jī)器是不會有人去用的，你可以安全的假設(shè)只有你的程序在執(zhí)行

三、服務(wù)器和testcase都已經(jīng)測試過，他們應(yīng)該負(fù)擔(dān)起若干健壯性的需求。事實上，他們比這兩個腳本更適合做這個，不是嗎？

這就是“看菜吃飯”：不需要的功能，是不需要去實現(xiàn)的，無論它看上去有多么的cool；必需的功能，無論如何都要做到，無論它看上去有多么的boring。

其實，無論開發(fā)測試，都是為了讓人們更好的發(fā)揮自身的潛力。開發(fā)工程師讓人們可以專注于自身的事業(yè)而不用過多（