我們正在構建基於SalesForce.com雲的大型CRM系統。我正試圖爲系統制定一個測試計劃，但我不確定如何創建系統範圍的測試。我想爲此使用一些行爲驅動的測試技術，但我不確定我應該如何將它們應用於平臺。我們應該如何自動化系統測試？
因爲我們將建立在系統的定製部件我計劃要麼SpecFlow的黃瓜上的UI駕駛硒行動來處理這個。但對於SalesForce UI Customisations，我不確定要進行多少測試。諸如工作流程和驗證規則之類的定製可以封裝我認爲應該測試的許多複雜邏輯。
寫Selenium測試在Salesforce的這一點的現成功能似乎對價值過於繁瑣。您可以與SalesForce.com平臺分享您的系統測試經驗，我們應該如何處理這個問題？
這是預先詳細測試計劃的問題。你試圖猜測什麼樣的錯誤，有多少，以及你會在哪些領域得到。這可能會很棘手。
也許你應該有整體的主測試計劃僅指定的測試策略，主要的工具集，風險，你要多少測試把在特定領域（基於風險）相對量。
然後當你開始工作給定的功能或迭代（我希望你在迭代而不是瀑布），你準備了這套工作的詳細測試計劃。您可以根據以前部分的經驗調整您的工具/估算/測試範圍。
通過這種方式，您可以在開始時說什麼是您的一般方法和優先事項，但您可以隨着項目進展稍後再進行調整。
問你需要多少測試投入測試COTS是一樣的任何軟件：您需要評估風險。
如果你的軟件必須 Validated因爲外部 條例（FDA，DoD ..） 你需要與你的 測試深入，幾乎測試整個應用程序。這裏的一個 問題可確保 外部穩壓器，該工具你 用於驗證被驗證 （這是一個麻煩）。
如果您的應用程序是爲您的公司， 關鍵不是你仍然需要做基於廣泛的風險 分析很多 測試。
如果您的申請不關注 與以上所有，你可以用 更輕的測試。也許你可以 跳過由平臺製造商測試 功能，並專注於您的定製 。在另一個 手中，我仍然會爲您的 業務流程使用 工作流編寫測試（在 至少happy paths）。
當我們開始學習硒測試在2008年，我們從Salesforce創建手冊招聘應用，創造了一系列測試，並在我們的blog描述我們的道路一步一步來。如果您決定編寫Selenium代碼來測試您的應用程序，它可能會幫助您開始。