最近開始整理自動化平臺上面的測試用例，自己也寫了很多的表格去與手工測試用例進行對照，想總結一下這兩年多的測試用例編寫方法。

手工測試用例編寫

現在還記得剛開始進入現在的公司面試的時候，當時的面試官叫我寫一個登入頁面的用例，他說給你五分鐘的時間，你看看你能想到多少。我當時就覺得這很簡單呀，在面試官出去的那五分鐘裡，奮筆疾書寫了大概十幾二十幾條吧，然後面試官回來了，沒錯，他嘲笑了我。。。。。。
首先，我的用例全部都是功能性用例（黑盒測試嘛），等價類，邊界值劃分什麼的；
其次，用例寫的毫無章法，亂七八糟（現在想起來真的是自己都想嘲笑自己）；
最後，即使是黑盒測試用例，我也沒能寫完整，全部都是隻看到字面意思那樣去寫。
謝謝當時的面試官也就是現在的老大，給我指出了當時的問題，在這裡想要記錄一下，希望其他去面試的小夥伴不要犯我當時的錯誤。
測試用例不要上來就寫

很多人可能都有這種習慣，習慣不管什麼時候，拿到一個需求或者頁面就開始著手寫用例，把一些簡單的用例直（hu）接(luan)寫出來，可是簡單的用例也都沒能寫好，東一句西一句去拼湊，最後還不清楚哪個需求點沒能寫好，測出來的產品也就沒有預期的樣子。
（1）熟悉並仔細閱讀需求說明書，但是現在很多網際網路公司都是敏捷測試，可能需求說明文件就沒有傳統測試難麼詳細，很多細節都需要主動去溝通和確認的。
（2）編寫過程中需要仔細思考，產品的使用者群是什麼樣的，到底使用者想要的結果什麼，也就是使用者思維。
（3）用例編寫過後，需要給組內人員進行評審，一個能可能不能兼顧那麼多點，但是組內人員大家一起討論，會產生不一樣的效果哦。
拿現在公司的 APP（網際網路金融，P2P 行業）來說，如果要求寫一個登入頁面的測試用例，需要從功能、效能、安全性、易用性、相容性、介面是否美觀和可維護性這幾個主要方面進行編寫測試用例。
編寫測試用例的方式

在編寫測試用例的過程中，雖然清楚需要側重的點是什麼，但還需要用例思維，我之前用過這三種方式進行編寫。
（1）傳統的用例編寫模式：Excel 表格（或者是測試管理工具）中，輸入編號，用例名稱，前置條件，輸入資料，用例步驟，優先順序，預期結果，編寫人員，複審人員、日期等等一系列的條件。
（2）腦圖思維方式編寫：在 Excel 表格中，從一級開始向外延伸，一級、二級、三級……八級這樣去思考，比較不容易丟下測試重點，也利於大腦進行思考，掌握全域性觀念。
（3）思維導圖方式編寫：在 Xmind 中進行編寫，這種方式其實和腦圖思維比較像，都是依靠一個功能點或者中心點思維慢慢向外延伸進行編寫用例，而且思維導圖中還可以新增一些任務進度和優先順序這種標誌，比較方便測試人員進行標記記錄。

自動化測試用例編寫

自動化測試用例與手工測試用例比較起來可能比手工測試用例要簡單許多，因為自動化測試用例大部分都是適用於軟體測試的迴歸和通用性比較強的用例測試。在當前的網際網路金融公司中，大部分都選擇在自己做的平臺進行自動化用例的編寫，使用一些封裝方法，將動作封裝成關鍵字進行編寫，可能需要到的知識也就是 Xpath 定位方式一類的。
自動化用例需要評審
自動化工具不可能完全替代人手工操作，所以在進行自動化用例編寫之前，需要進行了解哪一部分是自動化工具可以執行的，哪些是必須手工去執行的。比如一些不好獲取到的控制元件、解綁銀行卡之後重現上傳照片、使用電話進行聯絡客服等這樣的情況都是需要手工測試區判斷的。在編寫好的手工測試基礎上，對自動化測試用例進行篩選或者評審，或者也可以根據之前制定的迴歸計劃進行編寫自動化測試用例。

用例編寫感悟

2016年的時候，大部分時間都是在進行功能測試，沒有任何自動化或者效能方面的經驗，所以用例設計的也比較簡單，形成的思維方式也比較固定，原因就在於自己太不注重去多瞭解外面的測試情況，屬於比較故步自封的那種型別。在之後的很多次面試中，面試官之前就要求需要寫一些或者講解一些自己之前寫過的測試用例，這樣說起來就比較 low 了。還是需要自己多去了解多去增加自己的知識相簿，現在記錄下來，給自己提個醒吧。