1.《World Quality Report 2020-2021》要點解讀 2. 類淘寶商城自動化測試實戰(zhàn) 3. 測試學習方法分享 1.思考：大家知道為什么需要自動化測試或者自動化測試怎么來的嗎？” 為了回答這個問題，...

1.《World Quality Report 2020-2021》要點解讀

2. 類淘寶商城自動化測試實戰(zhàn)

3. 測試學習方法分享

1.思考：大家知道為什么需要自動化測試或者自動化測試怎么來的嗎？”

為了回答這個問題，我們可以回想一下軟件測試的概念：軟件測試是使用人工或自動的手段來運行或測定某個軟件系統(tǒng)的過程，其目的在于檢驗它是否滿足規(guī)定的需求或弄清預期結果與實際結果之間的差別。概念中就明確指出了傳統(tǒng)人工測試和自動化測試，所以說自動化也是完成和驗證客戶需求的一種方式。為什么會有這種方式呢？

人力成本：當公司的項目足夠多，或者公司的項目足夠復雜、功能很多，那么需要的測試人員肯定會越來越多。時間成本：目前IT行業(yè)競爭激烈，企業(yè)對內(nèi)對外都需要一個很快的節(jié)奏，而測試是保障軟件產(chǎn)品的重要手段，如果太慢，即使質(zhì)量好，也會失去市場。人工測試的弊端在于人在大量重復執(zhí)行同一任務時，會形成固定思維，從而導致誤測、漏測，影響產(chǎn)品質(zhì)量。人工測試工作通常滯后于自動化測試，而測試的原則就是要盡早測試，所以自動化測試是必須的。

另外，根據(jù)《World Quality Report 2020-2021》（全球質(zhì)量報告）

有來自32個國家、10個行業(yè)的1750名QA/測試經(jīng)理、首席信息管理和其他IT高管參與的調(diào)查結果表明，2020-2021年測試領域有6個主要趨勢：其中也有一點：

自動化測試在整個QA生命周期中的比重不斷上升，但自動化測試的優(yōu)勢并沒有得到充分利用。

其實我們很多同學都會或者已經(jīng)做了自動化測試了，最大的問題就在于對自動化整個知識體系的理解還有所欠缺，會用會寫，但是不知道怎么做才最好。那么今天來這里就對了，我今天就教大家怎么樣將自動化做得清新脫俗。

2. 類淘寶商城自動化測試實戰(zhàn)

這是淘寶App我想這個軟件大家一定都用過，那假設我們在淘寶上班?，F(xiàn)在項目組發(fā)布了一個新的版本，給的測試時間是2周。請問大家都是用什么方法來解決的呢？

好的，我已經(jīng)看到公屏上有很多種答案了啊。

我們一個個來看看。

首先是手工測試的傳統(tǒng)辦法，這是典型的4K薪資水平的做法…….

我們再來看看另外的做法，先測試接口嗎？好的，這種思路基本可以拿到8K，其關鍵的目的在于測試的提前，可以更早的介入，更早的發(fā)行問題……

還有同學說用自動化。那一般的自動化怎么做的呢？為了方便起見，我們用一個類淘寶商城來替代，因為商用的線上環(huán)境會有很多限制….

這里我們先來寫一段代碼：

大家看出來什么問題沒有？這是不是很多同學的做法？這樣的代碼能不能讓自動化測試真正落地呢？

不能！那怎樣才能讓自動化代碼變得清新脫俗？好，現(xiàn)在我教大家一步步地來完成這個任務。

實際上從上到下，我們可以簡單地將腳本劃成幾個部分：

part1：頭部

這里是需要引入的包。

part2：瀏覽器控制

這一塊代碼，主要作用就是實例化瀏覽器驅(qū)動，并且根據(jù)需要對瀏覽器進行相關操作，比如這里的最大化瀏覽器。

part3：具體的操作（測試用例）

這塊代碼比較長，主要做的是具體的操作，實際上這就是自動化測試用例。

part4：退出

最后一部分就是一行代碼，非常簡單，用于退出驅(qū)動。

思考：這樣的腳本用于實際測試會產(chǎn)生什么樣的問題？

代碼非常死板，不適應環(huán)境運行用例不夠完整，沒有任何判斷是否符合需求測試數(shù)據(jù)單一，覆蓋面很小……

解決問題：腳本改造！

2.1 引入測試框架，讓代碼層次更加清晰

我們可以根據(jù)實際測試常見將腳本重新組合一下，比如我現(xiàn)在就想測試搜索功能，那么按照功能測試用例的寫法，我們應該知道一條用例有前置條件，輸入以及輸出，所以我們可以將腳本改成：

但是實際測試過程中，根據(jù)之前的功能測試知識，嚴格上來說，一條測試用例只會對應一個測試結果，所以我們會把有多個結果的用例進行拆分。可以采用下面的方法進一步改造，為了更容易理解，我將之前的眾多操作挑選登錄作為實例：

完善測試用例，加入結果判斷

我們都知道一條完整的測試必須有結果判斷，用來驗證實際結果是否符合預期結果，所以我們需要將測試用例中添加斷言處理：（前面部分一樣，這里只是測試用例部分代碼）

使用參數(shù)化，讓數(shù)據(jù)變活

從上面代碼效果看來，層次比最開始確實清晰很多，但是還有存在不少問題。比如，代碼里面有很多都是一樣的代碼，就是數(shù)據(jù)不一樣，并且這些數(shù)據(jù)都是寫“死”在里面，假設還需要搜索別的內(nèi)容，又要多一截。怎么解決這個問題呢？可以使用參數(shù)化來處理，參數(shù)化正是解決這種邏輯相同數(shù)據(jù)不同的方法，我們來看解決辦法：

使用外部文件管理數(shù)據(jù)，實現(xiàn)數(shù)據(jù)驅(qū)動（DDT）

雖然這樣做可以減少后期一行行改代碼的問題，但是實際上還不夠“自動”。實際測試中，我們經(jīng)常使用外部文件來實現(xiàn)數(shù)據(jù)管理，后期只用維護文件就行，這也就是數(shù)據(jù)驅(qū)動的基本思想。外部文件可以使用的格式有很多，比如yaml、csv、json等都可以，這里采用yaml來舉例：

首先編輯yaml文件：

再改造代碼：

我們的腳本逼格是不是越來越高了？實際上，都是圍繞著解決自動化實際落地，能夠真正讓測試人員解放雙手的目的地。后續(xù)我們根據(jù)需要繼續(xù)將日志/測試報告/持續(xù)集成去實現(xiàn)起來，就達到了真正能落地的框架了。本文部分代碼因為篇幅問題，不是很完全。最后，如果你對軟件測試感興趣，歡迎百度搜索“特斯汀軟件測試騰訊課堂”或關注公眾號“特斯汀軟件測試”，里面涵蓋很多精彩免費視頻或干貨知識。