論測試用例完整性的重要性

今天，遇到了這樣一個問題。這個問題經曆了兩輪測試并沒有被發現。

這次測試的内容是一個活動頁面，需求的情景是從app内通路連結并進入到這個活動頁面，伴随着自動登陸（不需要使用者輸入使用者名和密碼，對app的使用者登入狀态進行擷取并進行自動登入）。

隻有第一次通路活動頁面時會傳回50x，之後再進入活動頁面都不會再傳回50x，一切正常。

因為每天的測試工作要大量的切換hosts，是以很容易出現由于浏覽器或app緩存所導緻的問題。一般通過重新整理、清理緩存能夠解決的問題，我們大多數情況認為是環境導緻的，不屬于開發的代碼問題。恰恰是這樣的想法，配合上這個問題邏輯上也隻會出現一次的隐蔽性，導緻了之後都沒能再發現這個問題。歸根結底，是由于測試用例的設計沒有貫穿整個測試需求流程邏輯的始終。

想要發現這樣的bug，首先要對接口傳回的資料非常敏感。如果不通過配合Fiddler進行實時抓包跟蹤的黑盒測試，我們很難由表及裡的發現這個問題。換而言之，想要發現這個問題，從單純的黑盒測試上來講，有兩種辦法：

1. 大量的使用者試驗；（無針對性，盲目不可取）

2. 保證測試流程的始終性和測試用例設計的完整性。（有針對性，可取）

想要避免這種問題的發生，排除知道代碼邏輯的情況（單元測試能夠發現的問題），另一種就是從表及裡（黑盒測試的手段）發現這個問題。

由于問題很隐蔽，我們必須從邏輯上下手，那就是保證測試流程的始終性和測試用例設計的完整性。以“登陸”為始，以“登出”為終——所有的測試用例必須由始至終進行設計，才算完整。如果不保持流程的始終性和完整性，我們很難發現兩端銜接處存在的問題（比如涉及到自動登陸的問題，第一次通路失敗，但登陸狀态可能将被記住，第二次通路将一切正常，是以如果用例設計不包括登陸操作和登出操作的話，将很難發現這個自動登陸上存在的問題）。如果用例隻在排除了始端和終端外的中端部分進行測試，測試結果将很容易建立在已經存在的bug的基礎上。