SalesForce.comクラウドに基づいて大規模なCRMシステムを構築しています。システムのテスト計画をまとめようとしていますが、システム全体のテストを作成する方法がわかりません。このためにいくつかの動作駆動型のテスト手法を使用したいのですが、それらをプラットフォームにどのように適用すべきかわかりません。
システムに構築するカスタムパーツについては、UIでSeleniumアクションを駆動するSpecFlowのCucumberを使用してこれにアプローチする予定です。しかし、SalesForce UIのカスタマイズについては、テストをどれだけ深く行うべきかわかりません。ワークフローや検証ルールなどのカスタマイズは、テストする必要があると思われる多くの複雑なロジックをカプセル化できます。
このすぐに使える機能のSeleniumテストをSalesForceで作成することは、その価値にとって非常に負担が大きいように思われます。システムテストの経験をSalesForce.comプラットフォームと共有できますか？また、これにどのように取り組む必要がありますか？
これが、事前の詳細なテスト計画の問題です。どのような種類のエラー、いくつのエラー、どの領域で発生するかを推測しようとしています。これは注意が必要かもしれません。
たぶん、テスト戦略、主要なツールセット、リスク、特定の領域に配置するテストの相対量（リスクに基づく）のみを指定する全体的なマスターテスト計画を用意する必要があります。
次に、特定の機能またはイテレーションで作業を開始するときに（ウォーターフォールではなくイテレーションでこれを実行していることを願っています）、この一連の作業の詳細なテスト計画を準備します。前の部分の経験に基づいて、ツール/推定/テストカバレッジを調整します。
このようにして、最初にあなたの一般的なアプローチと優先順位を言うことができますが、プロジェクトが進むにつれて後で適応することができます。
COTSのテストに必要なテストの量に関する質問は、他のソフトウェアの場合と同じです。リスクを評価する必要があります。
外部規制（FDA、DoD ..）のためにソフトウェアを 検証する必要がある場合は、テストを深く掘り下げて、アプリ全体をほぼテストする必要があります。ここでの問題の1つは、外部レギュレーターを確保すること、検証に使用したツールが検証されていることです（これは面倒です）。
アプリケーションが会社にとってミッションクリティカルである場合でも、広範なリスク分析に基づいて多くのテストを行う必要があります。
アプリケーションが上記のすべてに関係していない場合は、より軽いテストを行うことができます。おそらく、プラットフォームの製造元によってテストされた機能をスキップして、カスタマイズに集中することができます。一方、ビジネスプロセスで使用するワークフローのテスト（少なくともハッピーパス）は作成します。
2008年にSeleniumテストの学習を開始したとき、SalesForceハンドブックからRecruitingアプリケーションを作成し、一連のテストを作成し、ブログでパスを段階的に説明しました。アプリをテストするためにSeleniumコードを作成することにした場合は、開始するのに役立つ場合があります。
SalesForceの問題は、ユニットとUIのテストはあるが、サービスレベルのテストはないことだと思います。Selenium UIを駆動するSpecFlowは脆弱であり、サービスレベルのテストソリューションのエンジニアリングで私が求めているものをカプセル化していません。
（「/ Selenium-Testing-Cookbook-Gundecha-Unmesh / dp / 1849515743」に移動し、「今すぐ購入」ボタンをクリックしてから、「チェックアウトに進む」ボタンをクリックします）
それはSpecflowの精神や意図ではありません。
[チェックアウトに進む]を選択したときに製品を選択していない場合は、メッセージが表示されることを確認してください
セレンでそれをテストするには、基本的にクリックと入力に変換する必要がありますが、.NETレルムでは、中間層でオブジェクトなどをインスタンス化し、同じものに対して何百ものインスタンスと派生を実行できます。背景（モックセットアップ）。
セキュリティ上のリスクがありますが、APIを介してSFを公開できると言われています。それについてもっと知りたいです。