▪我們有開發過程的細節嗎？我們是時間固定的嗎？
我們需要看一看需求，看看如何提供功能，我們是否可以再次使用一些初創建的測試用例，我們是否可以從一開始創建一個回歸測試集并在開發產品的過程中改進它，這些問題在處理迭代過程中尤為重要，在敏捷開發流程中也是。
時間是產品開發的關鍵因素，因此，如果我們擁有的時間比所需時間少，我們應該考慮將由關鍵部分驅動的功能集上的測試用例（產品和項目風險都要考慮）分組，使用高水平的編寫風格，級聯終端到終端的flow，并使關鍵部分獨立。
假設關于“接收第一套業務需求時做什么好”我們已做了我們能做的，我們現在對他們了解得更多了，比起第一印象有了不同的理解，我們必須切實開始設計和編寫它們。
這是一個很好的時機，看看我們應該使用什么工具，并根據測試結構的測試需求評估其兼容性。
基本上，從測試用例設計角度來看，在選擇測試管理工具時我們應該考慮幾件事情：
▪它應該有一個明確的測試集，測試用例和測試腳本結構。
▪它應允許我們在某些點上可能需要的幾乎每一種測試結構：sprints /迭代或其他測試階段的組織，有許多配置層的分層組織。
▪它應當提供用其他方式而非測試集來分組測試用例的可能性，如標簽，關鍵字（用在需要時組織有效的臨時測試執行周期）。
▪它提供儲存各種版本的測試用例的可能性，以及如果他們已被分配給測試執行時更新測試用例的可能性。
▪它應該有其他可以服務測試員目標的可配置屬性。
▪它應該允許將被采用的先決條件或初步措施有一個明確劃分。
我們談談接收業務需求的那一刻。當收到技術規范時，當測試執行獲得批準時，當我們時間很緊時該怎么辦？在這些時刻，誰在乎測試用例設計呢？理想情況下，我們應該關心它，否則跟蹤執行比跟蹤業務需求更困難。這是測試“可理解的”業務需求與壓力下時間緊急下的“不可理解的”技術需求的主要區別。盡管團隊的一些成員可能終執行一些像小機器人一類的技術測試用例，我們確知，至少有人分析了這些規范，分割它們，優先考慮他們，其他一些人至少會執行所有的場景一次。
強調測試用例設計并不僅僅涉及編寫測試用例，我要說，所需測試結構的早期檢測要考慮：測試用例的外觀及其如何被創建的，花在測試準備上的精力，將被用于選擇具代表性測試的測試測試用例設計技術。這有助于我們為測試流創建基準。此外，這還使得設計如下測試用例更容易：
▪由于需求的早期分析而使得檢測出誤差的概率更大的有效測試用例。
▪由于正確識別要遵循的初始步驟，測試集組織和測試用例的設計風格而使之不冗余的測試用例。
▪擁有由已辨識的需求和已分配的時間驅動的適當細節的測試用例。
▪由于需求和測試用例間的早期相關性使其更容易在需求變化時或一些測試集不再工作并影響產品時識別受影響的區域更容易的可追蹤的測試用例。
我知道似乎不止靠一個soft touch可以造非凡，但重要的一條是要拋開神話，接受現實，并通過盡快在這個過程中考慮一切所需方面，造非凡。
版權聲明：本文出自 SPASVO澤眾軟件測試網：http://www.eqie.com.cn/news/html/2014327150011.html
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。
