 |
Raluca Gagea在軟件測試行業工作了5年，至今仍熱愛著它。 Raluca初是在一個公司開發一個計費和客戶服務平臺中負責各種測試活動，她由此獲得了測試經驗。這引發了她對需求、測試分析、測試用例設計的興趣。 獲得必要的信心和質量驅動的一組動作后，她開始在一家外包公司工作，在那她一直參與各種項目，現在已經聚集了測試服務元素的不少新經驗。 過去的一年，她在一家信用卡處理公司職，她試著實施各種測試過程，包括親身卷入許多測試階段。 一步一步地，她正邁進開發過程的測試管理角色。 除了她項目的相關活動， Raluca也很樂意協助公司內部的一些研究組（一個是測試分析&設計組，一個是測試管理組）以及針對這些主題的其他培訓活動。 在這里，我們可以分享我們的經驗，共同學習，并指導新。 |
每推出一個產品，我發現測試用例設計問題越來越具有挑戰性，但我已經學會了如何區分神話與現實之間的差異。我曾經遇到的主要的神話都與測試用例的無益，難度，業務類型間的不兼容，測試人員的個人資料或開發進程相關。這是神話。
不幸的是，我發現，與測試用例及需求的可跟蹤性相關的一切，僅被視作被一個正式推出過程強制實行的強制性過程，但它不被認為像實際上那樣有價值。這導致了低效率，無知和“匆忙”測試。這是現實。
本文中，我想和大家分享我關于可以使測試用例設計觀念非凡的Soft Touch的意見。
何時適合開始考慮測試用例？
測試用例不僅僅是用來測試各種flow的一些句子。
測試用例是我們通過衡量需求覆蓋范圍及它們在開發過程中的每一點的狀態推出產品時證明信心的方法——要求是否被足夠多的測試用例覆蓋，某一點上的測試執行狀態是否像期望的或計劃的那樣。
有了這個重大的責任，測試用例需要我們的一點幫助，以便終能夠向我們證明正確的事情。
他們需要在我們第一次接觸 “未來的產品”時被考慮在內，而不是一切緒時。 這意味著我們必須用我們收集的每條信息聯系他們。首先看看第一次接觸。
我們收到一些業務需求，也許不是終需求，也許在我們與客戶首次互動……
▪他們是可測試的嗎？
如果是的話，那么我們可以繼續。如果不是，那么我們需要提出問題。
▪他們是終產品或業務的關鍵功能嗎？
如果是的話，我們要看哪種需要的測試集？我們如何優先考慮他們？改變花在審查測試用例、執行它們、跟蹤執行狀態、然后恢復初始優先級上的精力的優先級的幾率有多大？
▪如何構造需求文檔？
比方說，我們收到用例模型。我們的第一反應會是用佳測試場景及備選流，有可能還是使用擁有大量步驟的獨立設計風格（這意味著每個測試用例可以單獨被執行而不依賴于其它測試用例）去構建基于由行為驅動的功能流的測試用例。這并沒有錯，但我們仍然需要考慮一些其他因素，例如：
▪對于對客戶并不那么重要但其他場景運行卻需要的關鍵功能，我們應該分別對待，用較高優先級而不是佳測試場景加以標記。
▪由一個行動者執行的每個功能流都有需要操作的必要中間層。這意味著我們需要考慮他們的測試——特殊測試用例集，或另一種設計風格或更詳細的編寫風格。這意味著我們一定要考慮一些技巧去選擇有代表性的測試用例——至少一些等價類劃分及其邊界值。
▪測試用例中有終端到終端的flow可能意味著我們的測試用例有較高冗余度及如果初期常見的步驟之一不工作時阻擋整個執行的高風險。分裂功能組件中終端到終端的flow或許可以更好地工作。
▪回歸測試 - 在獨立的測試用例上更容易做到，而不是在級聯的測試用例上。
▪我們可能想要或需要自動化flow的某些部分，因為他們中的一些不能進行自動化。這無疑表明了一個有時采用級聯方式的詳細的編寫風格。考慮到終端到終端的flow的初始結構，我們一定會寫出另一個可以進行自動化的測試用例——另一項工作，包含目前其他測試用例中的相同信息，再一次造成了冗余。
▪有人考慮過非功能性的需求嗎？他們不可能被包含在我們剛剛收到的用例模型里，所以我們需要確保我們有一個他們的測試用例結構。
