基于Robot Framework框架使用經(jīng)驗(yàn)，總結(jié)下測(cè)試腳本的設(shè)計(jì)思路。

這里所謂的設(shè)計(jì)思路，其實(shí)就是編寫(xiě)測(cè)試腳本時(shí)應(yīng)該關(guān)注的點(diǎn)。在工作中，我有根據(jù)自己的經(jīng)驗(yàn)，整理了針對(duì)實(shí)際工作內(nèi)容的腳本編寫(xiě)規(guī)范，并逐步優(yōu)化腳本編寫(xiě)規(guī)范以及測(cè)試腳本的模板。

個(gè)人以為，在編寫(xiě)測(cè)試腳本時(shí)，需要關(guān)注以下幾點(diǎn)：規(guī)范性、簡(jiǎn)潔性、時(shí)效性、結(jié)構(gòu)性、穩(wěn)定性、可讀性。

一、規(guī)范性

規(guī)范性有多重要呢？大家都遵循相同的規(guī)范，那么在看別人的腳本時(shí)，就容易找得著北。

• 腳本名稱

  • 腳本命名要求能體現(xiàn)功能名稱，也就是見(jiàn)名知意。如果團(tuán)隊(duì)需要維護(hù)多個(gè)測(cè)試組件的測(cè)試工程集，那么建議腳本命名規(guī)則：組件名稱-功能名稱；
  • 全部使用小寫(xiě)字母；
  • 使用英文描述，描述需簡(jiǎn)潔，禁止使用拼音和特殊字符；
  • 英文單詞之間用"-"符合隔開(kāi)。

• 用例名稱

  • 名稱格式為：序號(hào)-英文名稱，如"01-Test point"；
  • 簡(jiǎn)潔明了，可體現(xiàn)case要測(cè)試什么；
  • 單詞之間可使用英文空格隔開(kāi)或者"-"隔開(kāi)；
  • 名稱不使用特殊字符，如@,/等；
  • 英文名稱部分，首字母大寫(xiě)，其他均小寫(xiě)；

• 配置文件命名

  • 全部使用小寫(xiě)字母；
  • 使用阿拉伯?dāng)?shù)字+組件名稱以表示用例的序號(hào)；
  • 每個(gè)用例對(duì)應(yīng)一個(gè)配置文件，如果一個(gè)用例使用多個(gè)配置文件，則配置文件的命名格式采用劃線后緊跟阿拉數(shù)字再緊跟下劃線最后緊跟阿拉伯?dāng)?shù)字；

• 變量定義
  在腳本中多次(2次以上)使用的一些值，可定義為變量值，以簡(jiǎn)化腳本編寫(xiě)及后期維護(hù)的工作量。
  Robot Framework是不區(qū)分大小寫(xiě)的，但我們習(xí)慣將全局變量用大寫(xiě)，局部(臨時(shí))變量用小寫(xiě)；單詞之間用空格隔開(kāi)，不要使用特殊字符。

• 自定義關(guān)鍵字的命名
  腳本語(yǔ)句超過(guò)2句及以上并且在2個(gè)及以上地方被調(diào)用，建議自定義關(guān)鍵字實(shí)現(xiàn)。

  • 名稱一律使用英文，要求簡(jiǎn)潔明了，可體現(xiàn)關(guān)鍵字實(shí)現(xiàn)的功能；
  • 單詞之間使用英文空格隔開(kāi)；
  • 名稱不要使用特殊字符，如@，/等；
  • 名稱英文部分首字母為大寫(xiě)，其他均小寫(xiě)；
  • 功能復(fù)雜，需要Documentation用描述；
  • 關(guān)鍵字要求具有通用性，功能相近盡量使用一個(gè)關(guān)鍵字實(shí)現(xiàn)；

• CaseTags
  case tags用于匹配不同序號(hào)的用例，方便對(duì)每個(gè)測(cè)試用例單獨(dú)測(cè)試。
  標(biāo)簽固定格式為"_case+序號(hào)"，序號(hào)對(duì)應(yīng)測(cè)試用例編號(hào)。

• Suite Documentation
  這是針對(duì)整個(gè)腳本的描述,位于腳本名稱下的Settings下?？稍诖颂幪砑庸δ苊Q、需求鏈接、版本號(hào)、研發(fā)人員、測(cè)試人員等信息。
  通常我還會(huì)把該測(cè)試腳本所覆蓋的測(cè)試點(diǎn)，按照測(cè)試用例的順序，在此處羅列，讓腳本所覆蓋的測(cè)試點(diǎn)一目了然。

• Case Documentation
  這是針對(duì)每個(gè)用例的描述，位于每個(gè)用例的Settings下。
  case documentation用于描述測(cè)試用例，包括用例標(biāo)題、配置、步驟和預(yù)期結(jié)果。

• case獨(dú)立性
  每個(gè)case之間不能有任何的依賴關(guān)系，需要保持各自測(cè)試的獨(dú)立性，各自均可獨(dú)立運(yùn)行。

• 功能單一性
  盡量保持用例功能的單一性。所謂單一性并非一個(gè)case只能測(cè)試一個(gè)測(cè)試點(diǎn)，可包括幾個(gè)有關(guān)聯(lián)并且可連續(xù)的測(cè)試點(diǎn)，但不可隨意穿插其他測(cè)試點(diǎn)。

二、簡(jiǎn)潔性

測(cè)試腳本應(yīng)該保持精簡(jiǎn)。精是一種修煉，簡(jiǎn)是一種風(fēng)格。如何保持簡(jiǎn)潔性？最基礎(chǔ)的就是不要冗余。

• 不要有冗余的變量；
• 不要有冗余的自定義關(guān)鍵字；
• 不要有冗余的操作；
• 不要有冗余的注釋注解；
• 配置文件中不要有除了配置模板以外的冗余配置；

三、時(shí)效性

腳本時(shí)效性的重要性，大家知道得不徹底。為什么說(shuō)不徹底呢？因?yàn)楣ぷ鬟^(guò)程中有發(fā)現(xiàn)挺多測(cè)試人員有個(gè)錯(cuò)誤的觀念：我一個(gè)suite/case多花一兩秒、幾秒或十幾秒，有什么關(guān)系呢？
有什么關(guān)系呢？整個(gè)測(cè)試工程集有幾千個(gè)case，每個(gè)case要是多花一秒，積少成多就是幾千秒了。按照我們現(xiàn)有的case量，一次回歸就得至少多花兩小時(shí)。
對(duì)一個(gè)初級(jí)的腳本編寫(xiě)者來(lái)說(shuō)，關(guān)注腳本時(shí)效性可以考慮以下幾點(diǎn)：

• 謹(jǐn)慎使用sleep；
• 操作的必要性；
• 盡量請(qǐng)求小文件；
• 響應(yīng)時(shí)間
• 系統(tǒng)時(shí)間
• 能在suite層一次操作的，不要在case層多次操作；(舉個(gè)例子：我們工作過(guò)程中，使用lighttpd模擬源站。如果腳本中的所有用例都使用同一份lighttpd配置文件啟動(dòng)，那么我們一般把lighttpd的啟停放在suite setup/teardown，而不是放在 case setup/teardown中多次啟停。)

更進(jìn)一步來(lái)說(shuō)，腳本時(shí)效性和測(cè)試點(diǎn)、測(cè)試用例的組織，脫離不開(kāi)關(guān)系。30個(gè)測(cè)試點(diǎn)組織成10個(gè)case和30個(gè)測(cè)試點(diǎn)組織成8個(gè)case，腳本的運(yùn)行時(shí)效性是不一樣的。時(shí)效性差多少，就和腳本運(yùn)行的每個(gè)操作有關(guān)系了。

清楚地知道每個(gè)常用操作的運(yùn)行耗時(shí)，能幫助我們寫(xiě)出時(shí)效性更強(qiáng)的腳本。如何知道每個(gè)操作的運(yùn)行耗時(shí)呢？看腳本運(yùn)行結(jié)束后生成的log.html即可。

四、結(jié)構(gòu)性

清晰的腳本結(jié)構(gòu)，包括用例集的初始化和結(jié)束(Suite setup/teardown)、用例的初始化和結(jié)束(Case setup/teardown)。

• Suite Setup
  執(zhí)行測(cè)試腳本前進(jìn)行環(huán)境初始化操作。如關(guān)閉會(huì)影響本腳本的應(yīng)用程序，釋放端口，源文件拷貝，配置準(zhǔn)備等。
• Suite Teardown
  執(zhí)行完測(cè)試腳本后恢復(fù)測(cè)試環(huán)境。如關(guān)閉腳本啟用的應(yīng)用程序，刪除suite setup中拷貝的源文件和配置，刪除腳本產(chǎn)生的臨時(shí)文件，系統(tǒng)時(shí)間恢復(fù)等。
• Setup
  執(zhí)行測(cè)試用例前先關(guān)閉某些程序，清除某些可能會(huì)影響用例正常執(zhí)行的文件。
• Teardown
  用例執(zhí)行后判斷是否存在core文件。也可以像Case setup一樣關(guān)閉某些應(yīng)用程序和刪除文件。但是操作不能和Case setup重復(fù)，避免浪費(fèi)時(shí)間。

五、穩(wěn)定性

穩(wěn)定的腳本可以降低自動(dòng)化維護(hù)成本。
常見(jiàn)的腳本穩(wěn)定性的問(wèn)題有：

• 程序啟動(dòng)失敗
  程序要監(jiān)聽(tīng)的端口被占用，導(dǎo)致啟動(dòng)失敗。應(yīng)當(dāng)在Suite setup/Case setup中釋放要監(jiān)聽(tīng)的端口。

• tcpflow抓包失敗

  • 一種是沒(méi)抓到數(shù)據(jù)
    這種失敗是因?yàn)閠cpflow抓包命令后后臺(tái)執(zhí)行，但還沒(méi)執(zhí)行時(shí)，請(qǐng)求命令就已經(jīng)結(jié)束，導(dǎo)致抓不到數(shù)據(jù)。
    解決這種問(wèn)題，我一般在tcpflow抓包命令后臺(tái)執(zhí)行后，sleep 0.3s;
  • 另一種是抓到數(shù)據(jù)但讀不到
    這種失敗是抓包數(shù)據(jù)來(lái)不及寫(xiě)入臨時(shí)文件導(dǎo)致從臨時(shí)文件獲取數(shù)據(jù)失敗。
    解決這種問(wèn)題，可以先把tcpflow命令結(jié)束掉(會(huì)被緩沖區(qū)的數(shù)據(jù)寫(xiě)入臨時(shí)文件)再執(zhí)行從臨時(shí)文件獲取數(shù)據(jù)的操作。

• 內(nèi)部測(cè)試依賴外部資源
  原則上內(nèi)部測(cè)試不用使用外部資源，必須在內(nèi)網(wǎng)搭建環(huán)境。

• 路徑問(wèn)題
  由于自動(dòng)化平臺(tái)運(yùn)行腳本并不是在腳本的當(dāng)前路徑下執(zhí)行的，所以，腳本中的配置文件都要指定路徑，特別是當(dāng)前路徑的情況下，要加${CURDIR}/,以免自動(dòng)化平臺(tái)運(yùn)行時(shí)找不到指定的配置文件而導(dǎo)致腳本運(yùn)行失敗。

六、可讀性

可讀性好的腳本，可以降低他人學(xué)習(xí)和維護(hù)該腳本的成本。

良好的用例編寫(xiě)習(xí)慣可以讓他人更容易看懂你的測(cè)試用例和測(cè)試腳本。Case Documentation中要有完整清晰準(zhǔn)確的測(cè)試用例。

測(cè)試腳本中，也可以增加適當(dāng)?shù)淖⑨屖鼓_本更易于理解。
注釋有Comment和"#"兩種。前者注釋的內(nèi)容會(huì)體現(xiàn)在報(bào)告中，后者注釋的內(nèi)容不會(huì)顯示在報(bào)告中。建議在腳本中使用Comment進(jìn)行注釋，并用"Comment step-n"把腳本步驟和用例步驟進(jìn)行一一對(duì)應(yīng)。

實(shí)際工作中，建議持續(xù)維護(hù)配置文件模板和測(cè)試腳本模板。模板既是對(duì)工作的優(yōu)化固化，又可以降低腳本編寫(xiě)調(diào)試、學(xué)習(xí)維護(hù)的成本。