??軟體測驗經典10題（含決議） 軟體測驗行業，去大公司還是小公司好？??

年輕人都會犯的3個職場錯誤，你有幾個？ 測驗人員如何才能快速成長？ 軟體測驗行業，去大公司還是小公司好？

同學們可以用這 10 道題目，找到自己的薄弱點，對癥下藥哦，

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

選擇題

1. （單選）當需要對某個系統進行測驗的時候，應該從哪些方面來設計測驗用例？

A. 功能驗證

B. 性能相關的驗證

C. 兼容性相關的驗證

D. 安全性相關的驗證

E. 以上全是

2. （多選）軟體測驗程序中，測驗資料準備的痛點有哪些？（多選）

A. On-the-fly 測驗資料準備的時間消耗

B. Out-of-box 測驗資料的“臟資料”

C. 測驗資料本身組合的復雜性和多樣性

D. 性能測驗資料準備的時間消耗

E. 微服務化后，跨多個微服務的資料準備缺乏完整的知識體系

F. 微服務化后，測驗資料準備的環境依賴性

3. （單選）無頭瀏覽器的主要應用場景是？

A. 網路爬蟲

B. GUI 自動化功能測驗

C. 頁面監控

D. 以上全是

4. （單選）以下不屬于 API 測驗工具的是哪個？

A. Postman

B. SoapUI

C. JMeter

D. Selenium

5. （單選）以下屬于移動應用測驗的工具是哪個？

A. Appium

B. UFT

C. TestNG

D. LoadRunner

問答題

1、GUI 自動化測驗腳本分層設計的最佳實踐是怎么樣？

2、多個 API 連續呼叫的測驗用例的難點是什么？你是如何來解決的？

3、單元測驗中，樁函式和 Mock 函式用來解決什么問題，兩者又有什么區別？

4、性能壓測程序中，當面對大量并發用戶呼叫的時候，服務器端 CPU 的使用率是高好還是低好？為什么？

5、當需要在盡可能短的時間內完成大量 GUI 自動化測驗用例的執行時，業界主流的解決方案是什么？

答案與決議

1. （單選）答案：E

決議：除了要考慮顯示的功能性需求外，還要涉及安全性、性能、兼容性等非功能性需求的驗證，

2. （多選）答案：ABCDEF

決議：關于現在流行的微服務模式，由于每個單一功能的服務都是獨立分開部署的，所以我們在準備測驗資料時，還可能會遇到諸如環境依賴、跨多個微服務的資料準備缺乏完整的知識體系等問題，

3. （單選）答案：D

決議：無頭瀏覽器的主要應用場景，包括 GUI 自動化測驗、頁面監控以及網路爬蟲這三種，

4. （單選）答案：D

決議：Selenium 屬于 GUI 自動化測驗工具，

5. （單選）答案：A

決議：UFT（以前的 QTP）屬于一款 GUI 測驗工具，LoadRunner 屬于性能測驗工具，而 TestNG 是一個用來簡化廣泛的測驗需求的測驗框架，適用于從單元測驗到集成測驗階段的測驗，

Appium 則是一款很好用的移動測驗工具，

6. GUI 自動化測驗腳本分層設計的最佳實踐是怎樣的？

考點分析：GUI 自動化測驗腳本的分層設計原理，

答案與決議：

大量 GUI 自動化測驗能夠成功的關鍵，就在于腳本的分層設計，而腳本分層設計的核心思想就是模塊化，

首先，我們需要對頁面進行抽象，形成頁面物件模型，在這樣的測驗用例中，你看到的都是類似于 XXXPage.YYYComponent.ZZZOperation 的陳述句，它們和實際的手工測驗可以建立一一對應的關系，用通俗的話語來講，就是某某頁面上的某某元素，執行了某某操作，

接下來，為了使 GUI 自動化測驗腳本更加符合業務場景的描述，同時進一步提高腳本的封裝性和可重用性，就需要引入業務流程腳本的概念，這里，業務流程和實際的業務流程也是一一對應的關系，這樣，測驗用例就可以通過呼叫業務流程腳本來實作，測驗用例本身的可讀性以及可維護性也會更好，同樣地，業務流程腳本，也是基于頁面物件模型實作的，

7. 多個 API 連續呼叫的測驗用例設計難點是什么？你是如何解決的？

考點分析：多個 API 連續呼叫時，前后兩個 API 之間的引數傳遞，

答案與決議：

單個 API 測驗并不難，難的是多個 API 的連續呼叫，并且后一個 API 的引數值使用的是前一個 API 呼叫的回傳結果，這就要求多個 API 呼叫之間可以方便地進行引數傳遞，一個最典型的場景就是，前一個 API 呼叫會回傳一個有效的 token，后一個 API 呼叫需要帶著這個 token 才能呼叫成功，

為了解決這個問題，一般來講有三種處理方法：

第一種方法是，手工復制前一個 API 回傳結果中的某個值，然后粘貼給后一個 API 作為輸入引數，當然，這是最基本的方法，但是效率太低，而且無法實作自動化，

第二種方法是，使用基于代碼的 API 測驗框架，由于此時所有的測驗邏輯都是通過代碼來實作的，因此可以很容易地實作 API 之間的引數傳遞，

第三種方法是，借助于類似 HttpRunner 之類的已有 API 測驗框架，此類框架可以通過關鍵字，很方便地將前一個 API 的回傳值中的某個值傳遞給下一個 API 作為輸入引數，

8. 單元測驗中，樁函式和 Mock 函式主要用來解決什么問題？這兩者又有什么區別呢？

考點分析：理解樁函式和 Mock 函式的本質區別，

答案與決議：

當被測函式中呼叫了第三方的函式時，我們一般會采用樁函式或者 Mock 函式來模擬這些第三方函式，以此來實作被測函式的高代碼覆寫率，可以說，樁函式和 Mock 函式的使用大大方便了單元測驗的開展，同時也解決了單元測驗的代碼耦合性問題，

但是，這兩者到底有什么區別呢？

通俗來講，如果你的測驗驗證是在被測函式中進行的，那么此時你使用的就是樁函式；而如果你的測驗驗證是在被模擬的函式中進行的，那么這個被模擬的函式就是 Mock 函式，

9. 性能壓測程序中，當面對大量并發用戶呼叫的時候，服務器端 CPU 的使用率是高好還是低好？為什么？

考點分析：理解性能測驗指標解讀的復雜性，必須要全盤考慮多個指標間的相互關聯和制約，

答案與決議：

這個問題的答案，一定會有堅持不同意見的兩派人，

一部分人認為，CPU 使用率當然是越低越好，這說明后端代碼實作得很高效，只占用很少的計算資源就能實作較高的并發，并發情況下，越低的 CPU 占用率，說明系統可以繼續承載越多的并發負載，

而另一部分人則認為，CPU 的使用率是越高越好，這說明系統的計算資源被充分利用了起來，

你同意哪個觀點呢？

其實，這個問題本身就是個偽命題，單單通過題干中的資訊是不足以給出孰好孰壞的結論的，這里的關鍵是，隨著并發用戶數的上升，事務的回應時間是如何變化的，

如果隨著并發用戶數的增加，事務的回應時間也呈線性增長，但 CPU 的使用率一直上不去，這就是典型的 CPU 資源沒有被充分利用的現象，此時，你就需要去進一步診斷為什么 CPU 資源不能在并發場景下被充分利用，

而如果隨著并發用戶數的增加，事務的回應時間能基本保持穩定，同時 CPU 的使用率會隨著并發用戶數的增加呈線性增加，這反倒是我們希望看到的結果，也就是說更多的并發用戶會需要使用更多的 CPU 資源，

10. 當需要在盡可能短的時間內，執行完大量 GUI 自動化測驗用例時，業界主流的解決方案是什么？

考點分析：測驗執行架構的設計

答案與決議：

這個問題其實不難回答，業界一般會采用兩種方案：

一種是，使用第三方的云測服務，比如國外的 Sauce Labs、國內的 Testin 等；

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

其實，這兩種方案的本質都是將大量的測驗用例以并發的方式來執行，

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

這些資料，對于【軟體測驗】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴上萬個測驗工程師們走過最艱難的路程，希望也能幫助到你!

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

可以自助拿走，群號：310357728群里的免費資料都是筆者十多年測驗生涯的精華，還有同行大神一起交流技術哦

如果對你有一點點幫助，各位的「點贊」就是小編創作的最大動力，我們下篇文章見！