外表簡單內裡複雜的功能測試，如何進行？

問題引出

不知道大家有沒有遇到這樣的測試場景：一個Web應用，待測功能很簡單，只需要點選按鈕啟動執行，經過一系列內部運算，返回給使用者一個結果列表。 加我VX：atstudy-js 回覆“測試”，進入 自動化測試學習交流群~~

從可見的交付給使用者的最上層UI功能來看，待測功能只是一個簡單的“啟動”—“觀察結果”。

但是，我想當測試人員接手這樣一個測試專案的時候，恐怕應該是先“驚喜”後“恐慌”吧？！

“驚喜”：這麼簡單，點一下看一下結果不就測完了？

“恐慌”：這麼簡單？會不會還有什麼測試點我遺漏了，怎麼感覺有點惴惴不安呢？！

這樣的測試場景，我想幾乎每個測試人員在職業生涯中都會遇到。那麼，是不是真的就是“點一點”看看結果就行了呢？顯然不是。

那麼，對於這樣型別的待測專案我們應該怎麼去設計測試或者進行測試呢，或者有什麼測試技巧需要掌握的呢？

需要說明的是：在這裡，我們不討論什麼先進行單元測試、再進行整合測試、最後系統測試這類的分層測試設計理念，也不細緻討論使用什麼判定表、等價類等具體的黑盒或白盒測試方法。

我們本文討論的核心是：從業務層面出發，思考如何進行這類專案的測試，及我們需要藉助或抓住的一些測試靈感。

問題思考

問題1：如何確定“點一點”返回的結果是正確的呢？

比如：點一點搜尋某個“number=100”的資料有多少個，返回結果有10個。

既然，我們不能確定“點一點”返回給我們的結果是正確的。那麼，我們可以模擬資料，以此判定結果的正確性。具體怎麼做呢？

例如：確定系統內沒有number=200的資料，模擬、輸入100個number=200的資料。透過被測系統查詢，返回number=200的資料數量。

若返回數量為100個則表明系統正確性，透過測試；

若返回數量不是100個，則表明系統存在錯誤，測試失敗。

以此模擬資料，來判定被測系統的正確性與否。

因此，如何進行外表簡單的應用功能測試？需要掌握的第一個測試技巧是：學會模擬測試資料。

問題2：如何豐富測試資料樣本呢？

比如：在1中，我們證明了某類測試資料測試場景下，被測系統的正確性。但是，在其他型別測試資料輸入情況下，被測系統是否會響應正確呢？

也許，看到這個問題，有的人會說：繼續模擬更多型別的測試資料唄，比如string啊、int啊、list啊等等。

不得不說，這的確是一個方法。但是，資料型別多種多樣，系統資料邊界我們也不得而知（從業務層面出發，我們不知悉程式碼內部細節），我們如何能夠列舉完所有的資料型別和模擬資料邊界值呢？！

要解決這個問題，從使用者的角度出發，有一個很好的建議：如果可以，儘量使用真實資料進行測試。

如果我們能獲得真實資料取樣樣本，那麼可以很好地解決我們模擬資料樣本不夠豐富和模擬資料與真實資料之間存在差異的問題。而且，真實資料能讓我們更接近使用者的使用環境。

問題3：對於內部邏輯複雜的應用，最終返回結果正確，但是我還是有點擔心內部運算有沒有出問題呢？

比如：某個應用，只需web頁面點選即可觸發，但後臺程式涉及多個元件，如何確定運算過程中各個元件的正確性。

解決多個元件聯合作業的問題，常用的方法是：階段性測試，即每次只測試一個元件正確性，最終聯合確定整個系統正確性。

但從業務層面出發，有一個簡單的技巧就是：如果可以，請隨時觀察後臺程式日誌列印。

日誌是一個很好的測試媒介，藉助日誌可以發現許多未曾暴露到前端呈現在使用者面前的問題。我們要善於抓住日誌中的“error”、“warn”等等資訊。

問題4：如何快速地瞭解被測系統的一些“不為人知“的細節？

比如：觀察到日誌中某個”可疑“資訊，但是無法確定是否是故障，或者系統重啟後，表現與預期不一致，無法確定是否是故障。

這個時候，作為場內測試人員，你就需要同開發人員保持良好的夥伴關係。

開發人員對被測系統內部細節的瞭解程度遠勝於測試人員，同開發人員保持良好的夥伴關係，可以在遇到問題的第一時間求助開發人員而得到很好的答疑。並且，在開發人員的指導下，可以幫助我們更快地熟悉被測系統。

問題總結

針對本文的核心問題：如何進行外表簡單的應用功能測試？在此給出了4點建議。如下表所示：

我們不談測試技術，我們談的是如何思考測試。

最後：

可以到我的個人V：atstudy-js，可以免費領取一份10G軟體測試工程師面試寶典文件資料。以及相對應的影片學習教程免費分享！其中包括了有基礎知識、Linux必備、Mysql資料庫、抓包工具、介面測試工具、測試進階-Python程式設計、Web自動化測試、APP自動化測試、介面自動化測試、測試高階持續整合、測試架構開發測試框架、效能測試等。

這些測試資料，對於做【軟體測試】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你！