測試數據在整個測試過程中扮演着極為重要的角色，但是它卻像個沒有星象的演員，明明至少是男二號，但總是被觀眾忽略。在測試過程中，我們往往在測試計划階段就忽略了測試數據，在起先沒有給測試數據的設計、准備留出足夠的時間，投入足夠的精力，到了測試執行階段追悔莫及。只有吃過大虧的測試人員，才會在下一個測試開始的初期就認真的對待它。樓主也算是吃過虧的人。因此在現在經手的測試工作中，總會提着測試數據這根弦。今天一個網上的一個同學問了一個關於測試數據的問題，隨手回答了一下以后，發現自己其實已經積累了一些經驗了。現在把它們總結出來,供大家討論。歡迎提出各種建議和各種問題，我會試着作出解答。
測試數據為什么重要：
1.最淺顯的道理：說白了測試用例的執行工作主要是做一些輸入操作，然后觀察輸出。測試數據就是輸入的內容，沒有測試數據，你咋執行用例？
2.測試數據是測試設計的重要組成部分，測試用例的有效性嚴重依賴測試數據的選取或者設計，要記住測試的本質是抽樣，樣品的選取其實是一門深奧的科學，有學過統計學的同學會深切明白這個道理。
3.沒有把測試數據這一塊兒理順，良好的自動化測試簡直是空談。試想，測試自動化采取的最普遍默模式就是“錄制-回放”模式，如果搞不定數據，回放基本上會失敗，自動化驗證自然也就無法有效完成了。
4.測試數據能夠啟發測試設計。做測試多的同學都會有過選取一組測試用例后來了感覺發現自己思如泉涌的經歷。
5.如果是已上線系統，或者生命周期較長的系統，從生產系統上log下來的數據可以很好的指導測試。（通過一些統計可以幫助識別那些業務重要，為能夠制定正確的測試策略提供重要信息；對數據做pattern分析的話可以用於補充測試場景、用例，同樣十分有益；這些數據還可以在測試中進行復用）。
6.其它種種好處。。。
測試數據的分類
我們可以從多個維度對測試數據進行分類，下面講一下我的分類方式：
從測試數據的生命周期角度看可以將測試數據分為：穩定和數據、可消耗的數據和混合類型數據
- 穩定的數據：在一輪/多輪測試執行過程中幾乎不會發生變化的數據，如常見的電商系統中的一些基礎數據--城市，郵政編碼，一些商品的屬性，如衣服尺寸碼等。
- 可消耗數據：測試執行完某個步驟后，數據發生不可逆改變，或者發生逆轉操作需要耗費大量精力的改變。這類數據的例子有：商品的庫存，票務系統里的票，要被 夜維程序刪除的過期數據，網絡數據包等等。
- 混合類型數據：某些數據是復合型數據，如XML結構或者Json結構的某些數據，一條數據中的一部分是穩定的數據，另一部分是可消耗數據，這樣的例子其實很常見，一般這樣的數據會被當做可消耗數據來處理。
從數據是否可構造的角度來看可以將測試數據分為：可直接構造數據和需要間接獲取的數據。
- 可直接構造的數據：常見系統的大部分數據都可以直接被構造，通過操作系統本身，或者通過調用某些接口（SQL也算接口）插入數據，有時候甚至這些數據就是文本，直接准備好他們就行了。
- 需要間接獲取的數據：手工制造成本太高（理論上我們可以制造所有測試數據，但有時候就是成本太高），如某些以二進制存儲的含有信息的數據（被序列化的數據），某些非文本數據，例如音頻數據，視頻數據，傳感器上傳過來的極為復雜的帶有某些pattern的數據。舉個很好玩的例子，見過“獵曲奇兵”這款軟件么？偶然聽到一首歌，打開獵曲奇兵，十秒鍾左右它就能告訴你是哪一首歌。你基本上無法自己創造一條有效的測試數據，除非你是張學友或者Lady Gaga。
從業務角度來看數據可以分為：合規數據、非合規數據、Fuzz數據
- 合規數據：望文生義，就是符合業務規則的數據，如能夠通過校驗的身份證號。
- 非合規數據：顯然就是不符合業務規則的數據，當你被要求輸入注冊郵箱的時候，你給出這樣的輸入：skytraveler@@163.com 顯然不會合規。
- Fuzz數據：Fuzz數據主要是利用一些工具生成的亂七八糟的數據，主要用於系統穩定性測試和安全測試。這是一個大話題，有興趣的話推薦看《模糊測試》這本好書。
從測試數據來源來看，可以分為：生產dump數據，自己生成的數據
上面的分類其實並不是很准確，但是分類就是為了幫助更高效的解決問題。接下來我會講解對於上面類型的數據我是如何來處理的。
測試數據的生成過程
概念上的數據：也就是抽象的數據，例如，你的被測物是一款收銀軟件，你知道每筆交易結束后，需要生成一張“發票”，見過發票的你大概知道 它長什么樣子（如下圖），“發票”就是概念上的數據，但它並不能直接使用。
被細化了的數據：也就是具體的數據項。拿到發票后，我們還要分析發票里到底有哪些數據，經過需求的獲取及分析，我們知道發票包含：發票日期，發票代碼，付款方，收款方，金額，防偽碼，二維碼等。同時我們也知道了這些數據的規約，例如,發票的日期格式是：yyyy年mm月dd日。
真正能使用的數據：我們知道了數據的細節，就可以按照這些細節准備被測系統能夠識別和接受的數據了。例如，上面所說的發票付款方，收款方，真正的操作可能會直接在GUI中輸入，或者可以調用某些接口，或者可以直接插入數據庫。這時候你要做的就是，讓你的數據變得能用起來。
從上面的解釋可以得到測試數據從被識別，到能夠被使用的大體步驟:
事實上，實際工作中，測試數據的准備遠遠不是這么簡單。很多時候上面的每一步驟的推動都是一個艱苦的過程。搞定它需要柯南一樣抽絲剝繭的能力和工匠的細致和耐心。我會盡量在后續的文章中講述一些我的經驗。
