6年前,我在一家中型跨國公司
工作的時候,我建議與其浪費時間在準備充分的
測試用例，還不如編寫描述測試場景的文檔。所有的人都對我的建議。投以煩惱的目光。他們的臉上清晰地傳遞出,我這個建議犯了個大錯誤。雖然沒人否認了這一想法,但更沒有人愿意接受。每個人都認同傳統做法,即編寫測試用例,會更穩妥。我無力反駁。
4年之后,該公司接到一個測試項目,唯一的約束就是時間,唯一的期望是完整的測試證明材料。再次見面,我們討論了怎么趕上最后期限的想法。應用程序主要是關于“通過搜索和生成不同菜單項的報表”。編寫和記錄測試用例應該要花大部分時間,我們不確定,有多少文檔會用到客戶交付時。所以，我建議記錄測試場景,雖然有些猶豫,但最后大家都還是同意了。相對說我們可以節省寶貴的文檔時間,更可以利用它進行測試。
測試用例很快就會被測試場景代替嗎？
隨著時間的推移,一切都在變化,軟件行業和過程也發生了深刻的變化。
傳統的瀑布式和v-模型已經被
敏捷和迭代模型所取代。文檔是必要的,但是為了趕上最后期限,使過程簡單而透明的,文檔的方式也是可以改變的。
這些時候測試用例的文檔是很重要的:
1.客戶要求的文檔（是項目的一部分）
2.沒有時間的約束(我不認為這是可能的)
3.測試員是新人的或不熟悉產品
4.公司政策(我堅信它可以改變)
讓我分享一下我的一個經歷
我和我的團隊參與測試一個項目是世界500強公司,有著靈活的時間表。我們用最好的模板來記錄測試用例并且得到客戶的評審通過。一旦開始組建QA團隊,每天的大部分時間里,我們的責任就是,機械地遵循100個測試用例,更新文檔中通過/失敗結果，和在一天結束的時候把結果發給客戶。很多團隊的成員開始抱怨工作的單調乏味,盡管這仍然可以為公司創收。
然后就可以休息一天，沒有新的測試。我們坐在一起,并討論我們接下來要做什么。當我提議去想更多的方法來改進測試用例文檔,所有的團隊成員都否認我們投入的努力。按照他們的想法,他們沒有更多地去思考我們已經覆蓋的所有場景。說服他們跳出思維框架，產生更多的想法真的很艱難。
大多數時候,當我們測試用例(帶執行結果)文檔時,一旦得到客戶的評審通過,就認為我們所做的工作已經完成,我們的大腦會自動停止思考任何其他方法來測試產品。
相信我,當測試用例文檔準備好了,我們就只想機械地跟隨它。請告訴我，在你的職業生涯中，你和團隊成員在得到類似評審通過后，還提供了額外的測試用例的情況，你經歷了過多少次?
另一個經歷
在每周的團隊挑戰活動中,我們會要求團隊成員完成對被測應用程序指定的“測試場景”。所有的團隊成員,包括那些后期有反饋或無反饋的想法（有的沒的的想法）。為什么呢?沒有正式的用例文檔了,他們就不得不“諸如：補填預期結果，每個步驟的每個用例的功能和前提條件等等”。我們在一天中居然收集了40個測試場景,這是一個成功的經歷。
為了更好地證明我的經驗,我想展示一個例子。
拿一個應用程序做示例：用一個用戶名、密碼,登錄和取消按鈕的登錄頁面來說。如果以同樣的要求寫測試用例,我們將通過結合不同的選項和細節，的排列組合最終可以寫得50多個測試用例。
但如果用測試場景編寫,這將是如下重要的10行:
High Level 的場景:登錄功能
Low Level的場景:
1．檢查應用程序的啟動
2．檢查登錄頁面上的文本內容
3．檢查用戶名字段
4．檢查密碼字段
5．檢查登錄按鈕和取消按鈕功能
參見= > 180 +示例測試場景來測試web和桌面應用程序。
由于時間關系,測試場景與其說是以前那個IODEX（一種去痛膏），還不如說是止痛藥噴霧。但效果還是一樣的。
最后,我總結的區別如下:
最后這篇文章應該得出的結論為:
測試用例是軟件開發生命周期中最重要的一部分,沒有了它,就很難跟蹤、了解,遵循和推理出一些東西。但在 Agile的時代,測試用例將很快被測試場景所取代。
每個類型的測試的常見測試清單為 (數據庫測試、GUI測試、功能測試等)，加上測試場景，就是軟件測試人員的現代利器。討論、培訓、問題和實踐絕對可以改變你的生產力（包括報bug的能力）。
關于作者:這篇優秀的文章是由 STH的作者Bhumika Mehta。她是一個有著超過7年的軟件測試項目管理經驗。她喜歡測試存在的一切,欣賞好的創意和創新,但討厭單調的工作。
像往常一樣,我們歡迎聽到您的想法。