タグ付けされた質問 「testing」

テストとの継続的な統合は、常に「出荷可能な」コードがチェックインされていることを確認するのに役立ちます。 ただし、包括的なテストスイートを維持することは非常に難しく、多くの場合、ビルドにバグがあるように感じます。 CIパイプラインテストに自信を持たせるには、どのくらいのテストが必要ですか。十分なテストがあるかどうかを判断するために、ある種のメトリックを使用していますか？

10 unit-testing  testing  continuous-integration 

REST APIをテストしています。JSON構造を返すとしましょう。サーバーをテストするための最良のアプローチは何ですか？各テストステップは、前のすべてが成功した場合にのみ成功します。 構造A：すべてを一度にテストする - Test method 1: - make server request - assert http response code was 200 - assert returned file is not empty - assert returned file has valid JSON syntax - assert returned JSON contains key X これが最善の解決策のようです。 利点： 1つのサーバー要求のみ 「サーバーはキーXのJSONを返しますか？」という動作全体をテストしています。 構造B：各テストにアサートを徐々に追加します - Test method 1: - …

10 testing  acceptance-testing 

わかりやすくするために、私が作成したストレステストは、システムが限界点に達するまで、システムの負荷を徐々に増やしていきます。理論的には無期限に実行されますが、システムリソースは有限であるため、しばらくすると障害が発生することが予想されます。システムに予想される負荷がありますが、これは負荷テストで個別にテストされます。このストレステストの目的は、スケーリングを実装する必要がある前に、システムにどれだけの負荷をかけることができるかを調べることです。 私はシステムのストレステストを作成している最中です。合格/不合格の基準があるのが理にかなっているのではないかと思っています。テストの性質上、負荷は、ブレークポイントに到達する（つまり、失敗する）まで着実に増加します。私は明らかに、この限界点が事前に何であるかを知らないので、システムが処理できる負荷は（とにかく）期待できません。 現在、予想される負荷などでシステムをテストする他のパフォーマンステストがあります。これは、合格/不合格の基準を簡単に設定でき、これらの基準をストレステストの基礎として使用できます。言い換えれば、ストレステストに到達するための最小ベースラインを設定することはできますが、これが正しいことかどうかはわかりません（これが他のテストを「複製」していますか？）。 パフォーマンステストの経験が豊富な方に協力していただければ幸いです。ストレステスト（ある場合）の際に、他のどの合格/不合格基準を使用しましたか？

10 testing  stress-testing 

職場では、かなり複雑なシステムがあります。このシステムをSystem_Aと呼びます。QAチームは別のシステムを作成しました。このシステムをSystem_Bと呼び、System_Aをテストします。 System_Bの使用方法は次のとおりです。入力（System_B自体を使用）INを生成し、そのような入力をSystem_Bを介して処理し、出力O_Bを生成します。したがって、プロセスは次のとおりです。 System_B(IN) -> O_B。 次に、System_Aにも同じことを行い、独自の出力O_Aを生成します。 System_A(IN) -> O_A。 いつでも、O_Bは期待される出力であり、O_Aは観測された/実際の出力であると想定されます。暗黙のうちに、O_Bは「ゴールド」ソース（真実）です。しかし、問題の組み合わせに遭遇しました。 O_Aは間違っている、O_Bは正しい O_Aは正しい、O_Bは正しい O_Aが間違っている、O_Bが間違っている O_Aは正しい、O_Bは間違っている O_Bが常に正しいと想定されている場合（または何が期待されている場合）、何が正しいかをだれが決定しますか まあ、それはO_Bが人間の検査と分析で時々（またはしばしば）間違っていることがわかりました。物事はこのプロセスを使用してQAに合格し、実際のユーザーは不満を抱きます。結局、O_Bが間違っていたことが判明するまで戻ります。 問題はこれです。実際のシステムをテストするための「テストシステム」を作成することは悪い習慣ですか？ 滑りやすい斜面はどうですか？それでは、「テストシステム」をテストするためにさらに別のシステムが必要だと主張できないでしょうか。 開発者は少なくとも2つのコードベースを学習する必要があり、おそらくSystem_BはSystem_Aよりも複雑であるため、コストは明らかに法外です。System_Bが組織にとってどれほど良いか悪いかをどのように定量化しますか？ System_Bを作成する本来の「説得力のある」理由の1つは、テストを「自動化」することでした。現在、完全に自動化されていることを非常に誇りに思っています（System_Bが入力を生成して、それ自体を使用して出力も生成するプロセスをブートストラップするため）。しかし、定量化できない方法で、より多くの危害を加え、より複雑さを導入したと思います。QAの仕事は完全に自動化されていますか？その理由は、並列システムを作成することを正当化するのに十分ですか？ 私の本当の懸念はこれです。System_Bが間違っていることは誰もが知っています（かなり頻繁に）。System_Bが入力の処理に非常に優れていて、その出力がゴールドソースである場合は、System_AをSystem_Bに置き換えてみませんか？それに対して、職場の誰も満足のいく対応をすることができません。 この問題に関するガイダンスは大歓迎です。

10 unit-testing  testing  qa  acceptance-testing  integration-testing 

オブジェクトがあります public class MyObject{ protected MyObject(){} public string Property1 {get;private set;} public string Property2 {get;private set;} public string Property3 {get;private set;} public string Property4 {get;private set;} public string Property5 {get;private set;} public string Property6 {get;private set;} public string Property7 {get;private set;} public string Property8 {get;private set;} public string Property9 {get;private …

10 c#  testing  constructors  setters 

ゲームの一部は、自動化された方法（ロジック、数学、入力処理）で簡単にテストできます。しかし、純粋に視覚的で簡単にテストできないものもたくさんあります。 ゲーム業界がこれをすべて手動テストに任せたとしたら、私は驚きます。十分なお金があるので、少なくともゲームの視覚的な側面のいくつかを回帰テストできるように努力が払われたと思います。 これは本当ですか？もしそうなら、ゲームのレンダリングをテストすることができる可能な方法は何ですか？出力のキャプチャと画像の比較（これは信頼できますか？）？低レベルでグラフィックカードからのデータをインターセプトしますか？その途中で頂点情報（など）をキャプチャするグラフィックスカード？可能性はたくさんあるようです。しかし、これに関する情報は見つかりません:( 注：この質問はこの質問の重複であるとマークされていましたが、これを行う方法について特定のtech / frameworks / toolsについては質問していませんが、このプラクティスに関するアイデア、および実際のゲーム業界が行っていること（ある場合）彼らはまったくそうします）。

10 unit-testing  testing  game-development 

ソフトウェアテストの利点を誇る多くの研究記事や技術ブログを目にしました。私はそれを確信しました。しかし、すべてのソフトウェアテスト調査は大規模なソフトウェア会社によって行われているため、スタートアップに実際に適用されるとは思いません。新興企業には、大規模なソフトウェア会社とは異なるニーズと制約があるためです。 したがって、これは疑問を投げかけました。テック系スタートアップは自動テストを書くべきか？もしそうなら、それらは大手ソフトウェア会社と同じ方法で行われますか？（スモークテスト、回帰テストなど）。このトピックに関するいくつかの研究記事を参照できるのが最善です。自分で見つけることができなかったためです。 （私はまだキャリアの早い段階ですが、自動テストの作成に真剣に取り組んでいるスタートアップを見たことはありません）

10 testing  startup 

プログラムに新しい構成オプションを追加すると、多くの場合、オプションを実行する必要がある場所にオプションを取得するという点で、大量の波及効果が生じる可能性があります。私が認識しているこれに対処する3つの基本的な方法があります。 すべての構成設定を、プリミティブとして明示的に必要とするプログラムの部分に渡します。これは最も明示的な方法であり、物事を最も分離する方法です。欠点は、これが冗長であり、もろいことです。 最も頻繁に使用される構成設定をグローバル/静的にします。これは最も簡単な方法ですが、距離を置いてアクションを導入し、テスト性を妨げ、構成が本当にグローバルであると仮定します（常に1つの構成のみが必要である）。 プログラム全体またはプログラム内の主要な懸念事項のすべての構成オプションを含む構成クラス/構造体を作成し、これを明示的に渡します。これは、（1）より明確ではありませんが、（2）より明確です。1つの関数呼び出しのみの設定を変更する場合は、構成オブジェクトを複製して、この1つの値を変更できます。これは、テストと実際の両方で役立ちます。ただし、必要のない関数に大量の情報を渡す可能性があり、configクラス/構造体の値を変更すると、離れた場所でアクションが発生する可能性があります。 （3）パターンとアンチパターンのどちらを検討しますか？アンチパターンの場合、代わりに何をしますか？

10 design  testing  configuration  object 

現在、中規模/大規模のPHP / MySQLプロジェクトに取り組んでいます。私たちはPHPUnitとQUnitでユニットテストを行っており、アプリケーションを手動でテストしている2人のフルタイムテスターがいます。テスト（モック）データは現在、SQLスクリプトで作成されています。 テストデータ用のスクリプトの管理に問題があります。ビジネスロジックはかなり複雑で、テストデータの1つの「単純な」変更によって、アプリケーションにいくつかのバグが発生することがよくあります（実際のバグではなく、無効なデータの産物です）。テーブルの作成と変更は常に行われているため、これはチーム全体にとって大きな負担になっています。 UIを使用して約5分ですべてをアプリケーションに手動で追加できるため、スクリプトでテストデータを維持する意味は本当にわかりません。私たちのPMはこれに同意せず、テストデータで展開できないプロジェクトがあることは悪い習慣だと言います。 テストデータを含むスクリプトのメンテナンスを中止し、テスターがデータなしでアプリケーションをテストできるようにする必要がありますか？ベストプラクティスは何ですか？

10 testing  unit-testing  quality  manual-testing 

ソフトウェアテストの概要（Ammann＆Offutt）は、p.32で5レベルのテスト成熟度モデルについて言及しています。 レベル0テストとデバッグの間に違いはありません。 レベル1テストの目的は、ソフトウェアが機能することを示すことです。 レベル2テストの目的は、ソフトウェアが機能しないことを示すことです。 レベル3テストの目的は、特定のものを証明することではなく、ソフトウェアを使用するリスクを減らすことです。 レベル4テストは、すべてのITプロフェッショナルがより高品質のソフトウェアを開発するのに役立つ精神的な規律です。 詳細については触れていませんが。デバッグとテストの違いは何ですか？

10 testing  debugging 

従来のV字型の開発プロセスを使用しています。次に、要件、アーキテクチャ、設計、実装、統合テスト、システムテスト、および承認があります。 テスターは、プロジェクトの最初のフェーズでテストケースを準備しています。問題は、リソースの問題（*）が原因で、テストフェーズが長すぎ、時間の制約があるために短縮されることが多いということです（プロジェクトマネージャーは知っています...;））。開発者は必要に応じてユニットテストを行っています。 したがって、私の質問は簡単です。開発者がテスト段階に関与する必要があるかどうか、それはあまりにも「危険」ではありません。作業が完了したので、プロジェクトマネージャーに良い品質の誤った感覚を与えることになると思いますが、追加されたman.daysは何か価値がありますか？私は、開発者がテストを行うことに自信がありません（ここでは問題はありませんが、数日間に数回のクリックで中断するのは非常に難しいことは誰でも知っています）。 ご意見をお寄せいただきありがとうございます。 （*）あいまいな理由から、テスターの数を増やすことは現在のところオプションではありません。 （ちょうど前もって、それはプログラマーがテストを設計する際にテスターを助けるべきか？の複製ではなく、テストの準備ではなくテストの準備について話し、開発者の影響を回避します）

10 testing  development-process 

この質問は、経験豊富なテスターまたはテストリードに対するものです。これはソフトウェアプロジェクトのシナリオです。 開発チームが10の機能の最初の反復を完了し、システムテストにリリースしたとします。テストチームは、これらの10の機能のテストケースを作成し、テストのために5日間を見積もりました。もちろん、開発チームは5日間アイドル状態にすることはできず、次の反復のために10の新しい機能の作成を開始します。この間、テストチームは欠陥を発見し、いくつかのバグを提起しました。バグは優先順位が付けられており、それらのいくつかは次の反復の前に修正する必要があります。問題は、すべてのバグが修正されるまで、新機能や既存の機能への変更を伴う新しいリリースを受け入れないことです。テストチームは、バグ修正に加えて新機能も導入する場合、テスト用の安定したリリースを保証できると述べています。また、反復ごとにすべてのテストケースの回帰テストを実行することもできません。 つまり、開発チームはバグ修正のためだけにコードのブランチを作成し、開発を続ける別のブランチを作成する必要があります。特にリファクタリングとアーキテクチャの変更により、より多くのオーバーヘッドがマージされます。 これが一般的なテスト原則であるかどうかに同意していただけますか。テストチームの懸念は有効ですか。プロジェクトで実際にこれに遭遇しましたか？

10 development-process  testing 

私は非常に大きいPHPアプリを持っています。通常、2〜3人の開発者がフルタイムで取り組んでおり、変更を加えてバグ（咳機能）を作成するところまで来ています。ソフトウェアは言うまでもなく複雑ではありません。多くのことが起こっているだけです（35〜コントローラー、同じモデルなど）。 注意していても、このビューを変更すると（要素のIDを微調整）、特別な条件（片足でログアウトしている）で発生するajaxクエリが壊れるのは簡単です。 ユニットテストは最初に思い浮かぶものですが、別のアプリで試してみたので、それらを忘れたり、テストを記述してからテストを実行したりすることに多くの時間を費やすことは簡単です。ライブ配信する前にコードがチェックされるステージング環境があります。 多分パートタイムのQ / Aの人が必要ですか？ 誰もが何か提案/考えを持っています。

10 testing  code-quality  tdd 

時々、私のQAチームはバグを報告しますが、私も彼らもそれらを再現する方法について何の考えも持っていません。これにより、非常に長くてイライラするデバッグセッションが発生し、結果が得られない場合もあります。 私のソフトウェアは専有のハードウェアと強く結びついているので、バグは一度に多くの方向から発生する可能性があります。 「ボタンを押したときにソフトウェアがクラッシュした」以上のことを期待するべきでしょうか、それとも自分で何が起こったのかを理解する必要がありますか？ 編集： 私の同僚の1人は、おそらくここではすべての開発者であるため、結果には少しバイアスがかかる可能性があると指摘しました

10 testing  bug  qa  reporting 

私たちは、技術的な負債を多く抱えた大規模な（1200時間以上）ウェブサイトを持っています。これは主に次の（通常の）理由が原因です。 開発中に出入りする複数のプログラマー。 開発中の仕様変更。 多数の追加機能が（短時間で）追加されました。 顧客は多くの新しい機能を望んでおり、それは基本的にこのプロジェクトに毎週 10時間以上取り組むことになります。 技術的な負債があるため、問題の修正または調査に多くの時間を費やしていますが、通常、問題の原因は次のいずれかにあります。 人々を泣かせる、恥知らずで愚かなバグ。 新しい機能が影響するすべての場所を予測していなかったため、新しい機能は上記の結果をもたらしました。 私たちが直面しているいくつかの他の問題（サーバーの移行、アップグレード） 私たちは毎日問題を抱えており、これを停止するために以下のことを試みました： ウェブサイトのインポート、支払い、および一般的な作業に関する技術文書を作成しました。 週の初めに会議を開き、現在の問題または改善点とそれらにどのように取り組むべきかについて話し合います。 テスト計画を立てます。プログラマーAテストB、BテストC、CテストA.次に、プロジェクトマネージャーがいくつかのテストを行います。この機能の影響については、ステージング環境に投入し、お客様に確認してもらいます。 問題は、問題が発生し続けることです...そしてどういうわけかそれを把握することができません。新機能は依然としてバグを引き起こし、古いバグは挨拶を続けます。どういうわけか-おそらくプロジェクトの規模のため-このプロジェクトを把握できていないようです。 私はこれよりも大きなプロジェクトに取り組んでいるプログラマーがたくさんいると思います。それが私が私の質問に来る理由です： 私たちは何ができるのか、何をすべきか、あなたは大規模なプロジェクトでこれらの問題を回避するのですか？ 細かい編集、追加情報： バージョン管理（SVN）を使用しています。 DTAP開発プロセスがあります。

10 testing  programming-practices