年輕人都會(huì)犯的3個(gè)職場(chǎng)錯(cuò)誤，你有幾個(gè)？ 測(cè)試人員如何才能快速成長(zhǎng)？ 軟件測(cè)試行業(yè)，去大公司還是小公司好？

同學(xué)們可以用這 10 道題目，找到自己的薄弱點(diǎn)，對(duì)癥下藥哦。

我的建議是：你們可以拿出紙筆，寫下這 10 道題的答案，然后再與文末的答案進(jìn)行對(duì)照~

選擇題

1. （單選）當(dāng)需要對(duì)某個(gè)系統(tǒng)進(jìn)行測(cè)試的時(shí)候，應(yīng)該從哪些方面來(lái)設(shè)計(jì)測(cè)試用例？

A. 功能驗(yàn)證

B. 性能相關(guān)的驗(yàn)證

C. 兼容性相關(guān)的驗(yàn)證

D. 安全性相關(guān)的驗(yàn)證

E. 以上全是

2. （多選）軟件測(cè)試過(guò)程中，測(cè)試數(shù)據(jù)準(zhǔn)備的痛點(diǎn)有哪些？（多選）

A. On-the-fly 測(cè)試數(shù)據(jù)準(zhǔn)備的時(shí)間消耗

B. Out-of-box 測(cè)試數(shù)據(jù)的“臟數(shù)據(jù)”

C. 測(cè)試數(shù)據(jù)本身組合的復(fù)雜性和多樣性

D. 性能測(cè)試數(shù)據(jù)準(zhǔn)備的時(shí)間消耗

E. 微服務(wù)化后，跨多個(gè)微服務(wù)的數(shù)據(jù)準(zhǔn)備缺乏完整的知識(shí)體系

F. 微服務(wù)化后，測(cè)試數(shù)據(jù)準(zhǔn)備的環(huán)境依賴性

3. （單選）無(wú)頭瀏覽器的主要應(yīng)用場(chǎng)景是？

A. 網(wǎng)絡(luò)爬蟲

B. GUI 自動(dòng)化功能測(cè)試

C. 頁(yè)面監(jiān)控

D. 以上全是

4. （單選）以下不屬于 API 測(cè)試工具的是哪個(gè)？

A. Postman

B. SoapUI

C. JMeter

D. Selenium

5. （單選）以下屬于移動(dòng)應(yīng)用測(cè)試的工具是哪個(gè)？

A. Appium

B. UFT

C. TestNG

D. LoadRunner

問(wèn)答題

1、GUI 自動(dòng)化測(cè)試腳本分層設(shè)計(jì)的最佳實(shí)踐是怎么樣？

2、多個(gè) API 連續(xù)調(diào)用的測(cè)試用例的難點(diǎn)是什么？你是如何來(lái)解決的？

3、單元測(cè)試中，樁函數(shù)和 Mock 函數(shù)用來(lái)解決什么問(wèn)題，兩者又有什么區(qū)別？

4、性能壓測(cè)過(guò)程中，當(dāng)面對(duì)大量并發(fā)用戶調(diào)用的時(shí)候，服務(wù)器端 CPU 的使用率是高好還是低好？為什么？

5、當(dāng)需要在盡可能短的時(shí)間內(nèi)完成大量 GUI 自動(dòng)化測(cè)試用例的執(zhí)行時(shí)，業(yè)界主流的解決方案是什么？

答案與解析

1. （單選）答案：E

解析：除了要考慮顯示的功能性需求外，還要涉及安全性、性能、兼容性等非功能性需求的驗(yàn)證。

2. （多選）答案：ABCDEF

解析：關(guān)于現(xiàn)在流行的微服務(wù)模式，由于每個(gè)單一功能的服務(wù)都是獨(dú)立分開部署的，所以我們?cè)跍?zhǔn)備測(cè)試數(shù)據(jù)時(shí)，還可能會(huì)遇到諸如環(huán)境依賴、跨多個(gè)微服務(wù)的數(shù)據(jù)準(zhǔn)備缺乏完整的知識(shí)體系等問(wèn)題。

3. （單選）答案：D

解析：無(wú)頭瀏覽器的主要應(yīng)用場(chǎng)景，包括 GUI 自動(dòng)化測(cè)試、頁(yè)面監(jiān)控以及網(wǎng)絡(luò)爬蟲這三種。

4. （單選）答案：D

解析：Selenium 屬于 GUI 自動(dòng)化測(cè)試工具。

5. （單選）答案：A

解析：UFT（以前的 QTP）屬于一款 GUI 測(cè)試工具，LoadRunner 屬于性能測(cè)試工具。而 TestNG 是一個(gè)用來(lái)簡(jiǎn)化廣泛的測(cè)試需求的測(cè)試框架，適用于從單元測(cè)試到集成測(cè)試階段的測(cè)試。

Appium 則是一款很好用的移動(dòng)測(cè)試工具。

6. GUI 自動(dòng)化測(cè)試腳本分層設(shè)計(jì)的最佳實(shí)踐是怎樣的？

考點(diǎn)分析：GUI 自動(dòng)化測(cè)試腳本的分層設(shè)計(jì)原理。

答案與解析：

大量 GUI 自動(dòng)化測(cè)試能夠成功的關(guān)鍵，就在于腳本的分層設(shè)計(jì)。而腳本分層設(shè)計(jì)的核心思想就是模塊化。

首先，我們需要對(duì)頁(yè)面進(jìn)行抽象，形成頁(yè)面對(duì)象模型。在這樣的測(cè)試用例中，你看到的都是類似于 XXXPage.YYYComponent.ZZZOperation 的語(yǔ)句。它們和實(shí)際的手工測(cè)試可以建立一一對(duì)應(yīng)的關(guān)系，用通俗的話語(yǔ)來(lái)講，就是某某頁(yè)面上的某某元素，執(zhí)行了某某操作。

接下來(lái)，為了使 GUI 自動(dòng)化測(cè)試腳本更加符合業(yè)務(wù)場(chǎng)景的描述，同時(shí)進(jìn)一步提高腳本的封裝性和可重用性，就需要引入業(yè)務(wù)流程腳本的概念。這里，業(yè)務(wù)流程和實(shí)際的業(yè)務(wù)流程也是一一對(duì)應(yīng)的關(guān)系。這樣，測(cè)試用例就可以通過(guò)調(diào)用業(yè)務(wù)流程腳本來(lái)實(shí)現(xiàn)，測(cè)試用例本身的可讀性以及可維護(hù)性也會(huì)更好。同樣地，業(yè)務(wù)流程腳本，也是基于頁(yè)面對(duì)象模型實(shí)現(xiàn)的。

7. 多個(gè) API 連續(xù)調(diào)用的測(cè)試用例設(shè)計(jì)難點(diǎn)是什么？你是如何解決的？

考點(diǎn)分析：多個(gè) API 連續(xù)調(diào)用時(shí)，前后兩個(gè) API 之間的參數(shù)傳遞。

答案與解析：

單個(gè) API 測(cè)試并不難，難的是多個(gè) API 的連續(xù)調(diào)用，并且后一個(gè) API 的參數(shù)值使用的是前一個(gè) API 調(diào)用的返回結(jié)果，這就要求多個(gè) API 調(diào)用之間可以方便地進(jìn)行參數(shù)傳遞。一個(gè)最典型的場(chǎng)景就是，前一個(gè) API 調(diào)用會(huì)返回一個(gè)有效的 token，后一個(gè) API 調(diào)用需要帶著這個(gè) token 才能調(diào)用成功。

為了解決這個(gè)問(wèn)題，一般來(lái)講有三種處理方法：

第一種方法是，手工復(fù)制前一個(gè) API 返回結(jié)果中的某個(gè)值，然后粘貼給后一個(gè) API 作為輸入?yún)?shù)。當(dāng)然，這是最基本的方法，但是效率太低，而且無(wú)法實(shí)現(xiàn)自動(dòng)化。

第二種方法是，使用基于代碼的 API 測(cè)試框架。由于此時(shí)所有的測(cè)試邏輯都是通過(guò)代碼來(lái)實(shí)現(xiàn)的，因此可以很容易地實(shí)現(xiàn) API 之間的參數(shù)傳遞。

第三種方法是，借助于類似 HttpRunner 之類的已有 API 測(cè)試框架。此類框架可以通過(guò)關(guān)鍵字，很方便地將前一個(gè) API 的返回值中的某個(gè)值傳遞給下一個(gè) API 作為輸入?yún)?shù)。

8. 單元測(cè)試中，樁函數(shù)和 Mock 函數(shù)主要用來(lái)解決什么問(wèn)題？這兩者又有什么區(qū)別呢？

考點(diǎn)分析：理解樁函數(shù)和 Mock 函數(shù)的本質(zhì)區(qū)別。

答案與解析：

當(dāng)被測(cè)函數(shù)中調(diào)用了第三方的函數(shù)時(shí)，我們一般會(huì)采用樁函數(shù)或者 Mock 函數(shù)來(lái)模擬這些第三方函數(shù)，以此來(lái)實(shí)現(xiàn)被測(cè)函數(shù)的高代碼覆蓋率?？梢哉f(shuō)，樁函數(shù)和 Mock 函數(shù)的使用大大方便了單元測(cè)試的開展，同時(shí)也解決了單元測(cè)試的代碼耦合性問(wèn)題。

但是，這兩者到底有什么區(qū)別呢？

通俗來(lái)講，如果你的測(cè)試驗(yàn)證是在被測(cè)函數(shù)中進(jìn)行的，那么此時(shí)你使用的就是樁函數(shù)；而如果你的測(cè)試驗(yàn)證是在被模擬的函數(shù)中進(jìn)行的，那么這個(gè)被模擬的函數(shù)就是 Mock 函數(shù)。

9. 性能壓測(cè)過(guò)程中，當(dāng)面對(duì)大量并發(fā)用戶調(diào)用的時(shí)候，服務(wù)器端 CPU 的使用率是高好還是低好？為什么？

考點(diǎn)分析：理解性能測(cè)試指標(biāo)解讀的復(fù)雜性，必須要全盤考慮多個(gè)指標(biāo)間的相互關(guān)聯(lián)和制約。

答案與解析：

這個(gè)問(wèn)題的答案，一定會(huì)有堅(jiān)持不同意見的兩派人。

一部分人認(rèn)為，CPU 使用率當(dāng)然是越低越好。這說(shuō)明后端代碼實(shí)現(xiàn)得很高效，只占用很少的計(jì)算資源就能實(shí)現(xiàn)較高的并發(fā)。并發(fā)情況下，越低的 CPU 占用率，說(shuō)明系統(tǒng)可以繼續(xù)承載越多的并發(fā)負(fù)載。

而另一部分人則認(rèn)為，CPU 的使用率是越高越好。這說(shuō)明系統(tǒng)的計(jì)算資源被充分利用了起來(lái)。

你同意哪個(gè)觀點(diǎn)呢？

其實(shí)，這個(gè)問(wèn)題本身就是個(gè)偽命題，單單通過(guò)題干中的信息是不足以給出孰好孰壞的結(jié)論的。這里的關(guān)鍵是，隨著并發(fā)用戶數(shù)的上升，事務(wù)的響應(yīng)時(shí)間是如何變化的。

如果隨著并發(fā)用戶數(shù)的增加，事務(wù)的響應(yīng)時(shí)間也呈線性增長(zhǎng)，但 CPU 的使用率一直上不去，這就是典型的 CPU 資源沒(méi)有被充分利用的現(xiàn)象。此時(shí)，你就需要去進(jìn)一步診斷為什么 CPU 資源不能在并發(fā)場(chǎng)景下被充分利用。

而如果隨著并發(fā)用戶數(shù)的增加，事務(wù)的響應(yīng)時(shí)間能基本保持穩(wěn)定，同時(shí) CPU 的使用率會(huì)隨著并發(fā)用戶數(shù)的增加呈線性增加，這反倒是我們希望看到的結(jié)果，也就是說(shuō)更多的并發(fā)用戶會(huì)需要使用更多的 CPU 資源。

10. 當(dāng)需要在盡可能短的時(shí)間內(nèi)，執(zhí)行完大量 GUI 自動(dòng)化測(cè)試用例時(shí)，業(yè)界主流的解決方案是什么？

考點(diǎn)分析：測(cè)試執(zhí)行架構(gòu)的設(shè)計(jì)

答案與解析：

這個(gè)問(wèn)題其實(shí)不難回答，業(yè)界一般會(huì)采用兩種方案：

一種是，使用第三方的云測(cè)服務(wù)，比如國(guó)外的 Sauce Labs、國(guó)內(nèi)的 Testin 等；

另一種是，自己搭建 Selenium Grid 集群。

其實(shí)，這兩種方案的本質(zhì)都是將大量的測(cè)試用例以并發(fā)的方式來(lái)執(zhí)行。

最后感謝每一個(gè)認(rèn)真閱讀我文章的人，看著粉絲一路的上漲和關(guān)注，禮尚往來(lái)總是要有的，雖然不是什么很值錢的東西，如果你用得到的話可以直接拿走：

這些資料，對(duì)于【軟件測(cè)試】的朋友來(lái)說(shuō)應(yīng)該是最全面最完整的備戰(zhàn)倉(cāng)庫(kù)，這個(gè)倉(cāng)庫(kù)也陪伴上萬(wàn)個(gè)測(cè)試工程師們走過(guò)最艱難的路程，希望也能幫助到你!

在我的QQ技術(shù)交流群里（技術(shù)交流和資源共享，廣告勿擾）

可以自助拿走，群號(hào)：310357728群里的免費(fèi)資料都是筆者十多年測(cè)試生涯的精華。還有同行大神一起交流技術(shù)哦

如果對(duì)你有一點(diǎn)點(diǎn)幫助，各位的「點(diǎn)贊」就是小編創(chuàng)作的最大動(dòng)力，我們下篇文章見！

?