?問題引出

不知道大家有沒有遇到這樣的測試場景：一個Web應用，待測功能很簡單，只需要點擊按鈕啟動運行，經過一系列內部運算，返回給用戶一個結果列表。

從可見的交付給用戶的最上層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點建議。如下表所示：

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