最近作者有個做性能的任務，任務本身很簡單就是做一個登錄的腳本。但是隨着深入瞭解，發現這個數據準備卻是一個棘手的事情。
場景是這樣的，系統部署在一個內網，要登錄系統必須先遠程一個終端機，然後通過這個終端機再訪問系統，然後這個終端機的配置並不優秀，CPU和內存基本處於快飽和狀態，然後作者需要製作1500條左右的登錄數據。
當然作者第一步就是想着如何偷懶，首先去數據看看有沒有可用的數據，有麼就直接可以用了，那是自然好啦，結果通過終端打開數據庫管理器，然後SELECT了一下，發現等了一支菸的時間，結果數據愣是沒有出來，作者是加了 top 500的, 好吧終端硬件吃緊我也就認命了，然後作者優化了SQL語句，主要是把不需要的字段複雜的表連接統統去掉，發現SQL語句還是可以用了，但是沒有作者要的數據量，只能自己動手豐衣足食了。
但是找到的數據是沒有加密的，而在腳本中的數據是需要加密的，好嘞~事情又來了，怎麼加密呢，作者幾經詢問，找到了一個接口，是用來加密的。這下在做性能之前又需要做自動化了，1500條數據難道要手動一條一條加密嗎？當然是不行的，這不是人都變傻了，得嘞自動化的搞起，自動化腳本折騰好了，數據也收集到了，這下應該沒問題了吧。
結果就是個悲劇，作者發現接口的方式從GET變POST了，數據庫對應的表都變化了，這下作者傻眼了，好吧接着倒騰，作者抓來了系統測試，詢問了相關開發後，終於搞到了必要信息，接口的格式，數據庫的對應表和字段，然後作者還要往數據庫裏的一個表插入必要數據才能使用接口，作者又風風火火的看了數據，發現這張表還有一個唯一鍵的字段，都沒人知道是幹嘛的，於是作者毛了，直接找了個有效的值，改了最後5位數，就這麼INSERT了，還好結果是可以用的。
不過作者這個時候又發現一個問題，這樣的數據作者要插入1500條，於是乎作者需要製作一個讀取TXT數據，寫入數據庫的小程序，說幹就幹，通過一天的努力，作者寫出了程序，打了個包，直接實驗，結果慘敗，數據庫直接KILL了我的進程，我瞬間哭都哭出來了。作者自暴自棄了4個小時，然後又狗回了自己的位子，然後查看除了什麼問題，查看了LOG，看了數據庫的LOG，發現也沒什麼，然後又嘗試了幾次，發現INSERT到500多條的時候，程序進程就會被KILL掉，想了好久作者認爲是數據庫安全策略，好了DBA，他老人家不在，又找了運維兄弟，看了也不知道爲啥，好嘛~不知道就不知道吧，作者突然靈機一動，直接把自己的程序改了，改成每到450次INSERT後就斷開SQL連接重新連接，哈哈哈哈，天無絕人之路作者成功了。
然後作者從新嘗試了一下測試腳本，發現測試成功，但是有個好奇怪的事情，單筆登錄時間居然要十幾秒，這個做毛毛的性能啊，直接可以砍死開發大大們了。於是作者抱着普度衆生的心態，問了自己的老大，這個任務的由來是怎麼回事，後來發現，這件事情是線上發現的，結果UAT上還沒弄了，好吧。。。作者於是又找了運維兄弟，從生產線上複製了必要的文件和信息，然後安裝在了UAT上。
至此作者終於準備好了測試環境，測試數據，測試腳本。
作者這麼多廢話，其實就想表達一點，測試數據的準備，沒有什麼一定的方法，或是必須由什麼人來製作出來，條條大路通羅馬，八仙過海，就是這麼回事。
作者在這個任務中基本上把所有的可用手段都用上了，從開發知識到業務知識再到數據庫知識，自動化性能測試知識也都統統用上了。數據準備工作雖然麻煩，但是作爲高質量的測試卻是必不可少的一個環節。
好了作者也嘮叨完了，希望可以給大家一些啓發吧。