1.互聯網測試人員不專業嗎?
前段時間和一個朋友聊到測試用例的問題，他說在剛工作那會，編寫用例都要寫的很詳細，前置條件、操作步驟，預期結果缺一不可，每一條用例都需要有詳細的操作和輸入數據，每一個用例都有唯一的預期結果；而互聯網企業中所謂的“用例”，其實就是原來的測試大綱,從這一點上來說，互聯網測試人員的專業性還是差了一些，你說為什么會這樣呢？
我回答到道，這個問題其實我是思考過的，其實不是人員的專業性的問題，而是互聯網和傳統行業的差異造成的，比如業務、用戶、運營等不同造成的。
業務不同：傳統企業主要解決企業信息化的問題，互聯網主要解決需求與供給的匹配問題，面向端的業務較為簡單。
使用對象不同：傳統軟件使用者大多是有一定專業能力的人員，業務復雜；而互聯網企業用戶一般比較復雜，要求業務簡單。
運維能力差異：傳統企業更多是客戶運營，而互聯網企業更多的是提供服務企業自運營。
當時對這個回復還是挺滿意的，直到上周閱讀到《數據中臺：讓數據用起來》一書中提到：“數據是一種資產”。突然想到一個問題，測試用例是資產嗎？如果是資產應該如何編寫用例，如果不是資產又應該如何編寫用例呢？
2.測試用例是資產嗎？
2008年參與了某四大行的測試資產管理系統開發工作，系統包含測試用例管理、測試數據管理、測試環境管理三部分內容。當時沒有太關注系統的名字，現在想來大有深意，至少在傳統企業中，很多公司把測試用例當成一種測試資產。
如果測試用例是一種資產的話那該如何編寫用例呢？從資產的特上來說，資產是有價值的，可復用，可傳承（轉讓）。如果讓測試用例這個資產有價值、可復用、可傳承呢？那就需要有更多的信息描述，如前置條件，測試步驟（詳盡的測試數據，每一步都是可以預期的結果），測試結果（一條用例有唯一的預期結果）；以及測試用例詳細信息（關聯需求、優先級、重要程度、需求描述、編寫人、維護人、時間等屬性）。
但在互聯網快速發展的時代，因為業務性質、用戶、運營以及軟件技術和開發流程都發生了很大的變化，面向端的測試用例本身來說不一定是資產，因為需求可能是臨時的，實驗性質的，這個時候，“用例”可能只是一種對需求的理解，或者一種測試思路，其目的是為了和產品經理對其思路，或者提供一種測試思路。基于這個思路，用例編寫不再有求詳盡，而是能夠表達清楚對產品的理解和測試思考即可。
所以從這個角度來說，傳統企業和互聯網企業對用例的認識和定位不同，測試用例到底是不是一種資產，直接影響著用例的編寫方式。
3.互聯網時代的測試用例該如何編寫？
前面討論了測試用例到底是不是資產是基于大背景下的一個思考，但互聯網時代，測試用例該如何編寫，該基于什么樣的邏輯編寫呢？JVM存儲模式給予一個新的思考方式。比如把用例分成幾個等級。如基礎能力、核心業務、其他業務等。
基礎能力：登錄、路由、通用或者技術組件等
核心業務：小金庫、白條、交易等
其他業務：營銷、新業務等
基礎能力是業務最核心的能力，直接影響用戶使用或者經營決策的業務，這些業務相對穩定，按照資產的邏輯編寫詳盡的測試用例，一則可以確保測試時無遺漏，二則確保知識交接轉移無縫銜接。
核心業務可以業務情況選擇使用資產的方式，編寫詳盡的用例，也可以選擇按照大綱的方式編寫用例。
其他業務則只要做到對齊需求，做到不遺不漏就可以，沒必要編寫詳盡的測試用例，從資產的角度來說，有用，但不能復用。
以上只是簡單的從另外一個角度思考測試用例，只是從測試意外的角度理解測試。希望給讀者一個不一樣的視角思考測試用例。
