寫TC貌似是很簡單的
工作，但當動手寫的時候往往會出現，不知道寫什么，又感覺有一堆的東西需要寫，即使一個簡單的日常也會覺得里面的邏輯非常復雜，然后就是暈得不知所向。
個人認為，寫TC沒有固定的模式，也沒有唯一的答案，每個人的方式不同，習慣不同，TC中的如何分類歸納也就自然不相同。但目標是一致的，基本目標是覆蓋需求、無盲區；加強目標是加深測試點，完善用戶友好性等。
下面分享下我寫TC的幾種思路。
第一種思路——先對象，后流程
面向對象是在平常入門學習中 首先接觸到的概念，它不僅僅存在于代碼的編寫中，更存在于我們的工作方式和方法中。首先分析需求中涉及到哪些對象，比如頁面是一個對象，對它加以細化，頁 面大對象可能又分為新增頁面，修改頁面，刪除頁面和查詢頁面等，或者從功能上劃分為賣家頁面、小二頁面等。分析完后再層層細化，比如新增頁面包含的哪些文 本的輸入框，單選/多選項、日歷控件，以及它們之間操作的優先級，錯誤提示的優先級等等，再洗化到各個控件本身的限制檢查，如單行文本最長和最短的校驗長 度是多少，非法字符校驗等。
當所有對象類信息完成后，再考慮這些對象之間的流程關系，比如對用戶身份審核的操作必須建立在用戶身份信息 已創建之后，或者信息被修改后。不光是需要校驗正常的操作流程，還需要花大精力放在異常流程的操作上，比如用戶在填寫信息時，突然中斷了操作，這樣的情況 通過什么樣的流程去處理。因此這里的流程，應該是包括正常流、異常流及擴展流（需求中未涉及，但測試人員基于用戶友好或者性能方面考慮需要加入的流程）。
回過頭想一想，我們說，把面向對象的思想帶入TC，那面向對象又體現在什么地方呢，難道僅僅是分類么？NO！
我們是不是經常會在寫TC中碰到這樣的問題，比如某些項目中，進行查看和修改時，發現自己看到的是相同的頁面，也就是可能在做不同操作流程的時候發現到 達了相同的一個出口，那對于這N個流程是否需要寫N個平行的TC，是否可以把某部分寫成公共模塊以提高效率，避免冗余呢。
第一種思路可 能會有同學覺得很麻煩，很容易復雜化，確實是的，因為大家平常做項目或日常時，至少是有頁面或者頁面大概的原形，如果需求是很模糊的，又或者客戶也不知道 具體是要做成什么樣的，同時客戶又希望能快速立項的情況下，可以使用這種方式，其實在這樣的過程中，測試人員無形中擔當了架構的角色，并且能幫助開發完善 產品。
第二種思路——先流程，再對象
這種思路，要求是頁面設計到位，至少是大概的原形具有，然后對著原形寫TC。
從打開的第一個頁面開始層層深入寫，比如首先是用戶登陸，然后是主展示頁面，再可能是搜索寶貝等，先把流程正常流程建立好，然后將這些流程細化，如用戶 登陸是否采用彈出窗口，窗口的位置、大小，窗口中的表單項是否完整，如是不是缺少驗證碼項，再考慮某一項的校驗，如用戶名是否為單行文本，長度限制多少， 非法字符限制，是否為必填項（不填是否有提示）等。
使用這種思路的時候，切記至少要包含幾類信息：頁面總體展示、表單項完整性、表單項正確性、表單項可操作性（獨立操作和組合操作）、表單項非法校驗、及當前頁面的其他跳轉出口（如點擊“登陸”，在用戶輸入的信息正確的情況下，應跳轉到主展示頁面）。
這種思路可能使用的同學比較多，至少我是經常用的。這里實際上還是把頁面當成了大對象，當出現多類頁面跳轉到相同頁面上去的時候，這個相同頁面就可以作為公共部分來使用了。
記得在學校里學習這些原理的時候，對它的用法感悟不深刻，出來工作以后發現，其實很多思想就穿插在平時的應用中，所以有一句話很欣賞：解決問題，思路很重要，技術在其次。
以上是對于寫TC思路的一些個人看法，有不足之處還請大家指正。