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

テストを書くことで自分自身を繰り返すことがなぜ非常に奨励されるのですか テストは基本的にコードと同じことを表しているため、コードの（概念ではなく、実装で）重複しているようです。DRYの最終的なターゲットには、すべてのテストコードの削除が含まれませんか？

11 testing  dry 

私は、QA組織としてのテスト効率の測定に関する経営陣との議論に参加しようとしています。この背後にある主な理由は、私たちのチームの半分が外注されており、私たちのビジネスは私たちがどれほど効果的/効率的であるかのいくつかのメトリックを提供したいので、私たちは請負業者のサービス契約と契約パラメータを交渉するための基礎データを持っている。 このテーマについて私が見つけた意見のほとんどは、開発者の効率性に関するものです。コードの行、配信されたストーリーポイント、導入された欠陥などです。 しかし、テスターはどうですか？テストは主に要件ベースで、手動、半自動、自動のテストが混在しています（すべてを自動化していないためではなく、テストシステムで自動化できないものがあるためです）。

11 testing  efficiency  qa  metrics 

私が取り組んできた小さなMVCフレームワークがあります。コードベースは決して大きくはありませんが、2、3のクラスではありません。私はついに思い切ってテストを書き始めることにしました（はい、私はずっとそれをやっていたはずですが、APIはこれまで非常に不安定でした） とにかく、私の計画は、統合テストなど、テストを非常に簡単にすることです。統合テストの例は、次のようなものに沿って進みます。 偽のHTTP要求オブジェクト-> MVCフレームワーク-> HTTP応答オブジェクト->応答が正しいことを確認 これは状態や特別なツール（ブラウザの自動化など）なしですべて実行できるため、実際には通常の単体テストフレームワーク（私はNUnitを使用）で簡単に実行できます。 さて、大きな質問です。ユニットテストと統合テストのどこに正確に線を引くべきですか？ユニットテストで一度に（可能な限り）1つのクラスのみをテストする必要がありますか？また、統合テストは、ユニットテストプロジェクトと同じテストプロジェクトに配置する必要がありますか？

11 .net  testing  unit-testing  integration-tests  nunit 

開発では、通常、テストする予定のデータ、シナリオ、および実行手順を文書化する独自のテストスクリプトを使用します。これは私の開発テスト計画です。機能がTestに展開されると、テスターは独自に作成したテストスクリプトを使用してテストします。UATでは、ビジネスユーザーは独自のテスト計画を使用してテストします。 振り返ってみると、デベロッパーテストではブラックボックステストとホワイトボックステストが混在し、テスターやビジネスユーザーはブラックボックステストに重点を置いているため、より良いカバレッジが得られるようです。しかし一方で、これはステージごとにのみ実行される別個のテストケース（つまり、テスト担当者がテストステージでのみ実行されると考えるケース）を表示し、開発者がそれを逃したことを望みます。 。 テストスクリプトを最初から統合する価値はありますか？したがって、1つの統一されたテストスクリプトを使用しますか、それともこれを事前に行うのは少し難しいですか？

11 testing  test-management 

クラス割り当て用のソートアルゴリズムをいくつか作成し、アルゴリズムが正しく実装されていることを確認するためのテストもいくつか作成しました。私のテストの長さは10行に過ぎず、3行ありますが、3行の間で変更されるのは1行だけなので、多くのコードが繰り返されます。このコードを、各テストから呼び出される別のメソッドにリファクタリングする方が良いでしょうか？その後、リファクタリングをテストするために別のテストを作成する必要はありませんか？一部の変数は、クラスレベルまで移動することもできます。テストクラスとメソッドは、通常のクラス/メソッドと同じルールに従う必要がありますか？ 以下に例を示します。 [TestMethod] public void MergeSortAssertArrayIsSorted() { int[] a = new int[1000]; Random rand = new Random(DateTime.Now.Millisecond); for(int i = 0; i < a.Length; i++) { a[i] = rand.Next(Int16.MaxValue); } int[] b = new int[1000]; a.CopyTo(b, 0); List<int> temp = b.ToList(); temp.Sort(); b = temp.ToArray(); MergeSort merge = new MergeSort(); …

11 testing  unit-testing  code-quality 

誰かが浸漬試験とストレス試験の違いを説明できますか？私はそれらについてグーグルで調べたところ、どちらもその限界を超えてソフトウェアをテストしようとしていることがわかりました。両方のテスト戦略に適していますか？

11 testing  qa  stress-testing 

私はかなり長い間製品開発部門を持っていた小さな会社で働いています。ただし、これまでになかったのはQA /テストグループです。 テストグループの追加を検討していますが、会社の組織構造のどこに配置するのが最適かを判断するのに苦労しています。具体的には、「リードテスター」のポジションを採用します。それらは製品開発部門の一部として配置されるべきですか、それとも新しい部門になるべきですか？彼らはどこか別の場所にいるべきですか？ 当社は大まかに次のように構成されています。 最高経営責任者（CEO CTO 製品開発ディレクター ディレクターカスタマーケア 開発者 VPオペレーション ネットワークエンジニア セールス/セールスエンジニア 大統領 コントローラ

11 testing  organization  qa 

アプリケーションに新しい機能を追加することを目的とする小さなプロジェクトを考えると、導入された変更は、特定の領域でこれらを更新することを含む既存のコードに影響を与えます。実装中に、更新されたこれらのコードの一部にリファクタリングの候補があることがわかりました。 これは、影響を受けるコンポーネントのリグレッションテストを必要とするリファクタリングの適切な時間ですか（したがって、元々プロジェクトの一部ではないスコープを導入している可能性があります）？または、機能を延期し、機能を完成させ、おそらくリファクタリングのための別個のプロジェクトを用意する必要があります（ただし、ビジネスユーザーは、コードの保守性を重視しない限り、機能を追加しないプロジェクトを完全に後援できないため、少しためらっています...）？

11 testing  refactoring  decisions  maintainability  scope 

数日前にバグが発見された多言語のウェブサイトがあります。他の言語のデータを他の言語で表示し、英語などのデータの混合も選択されていましたが、ページにも他の言語のデータが表示されていました。それはまれですが、ウェブサイトに存在します。これは常に発生するわけではないため、コードを調べても役に立ちません。 問題をタイムリーに見つけるための提案はありますか？ここで戦略を求めています。

11 web-development  testing  bug 

統合されたテストサポートと独立したQAスタッフを持たないスクラム環境から、テスター（QA担当者）はどのようにスクラムチームと最適に統合されますか？彼らは何をすべきでしょうか？ 参考のために、いくつかのテスト関数は次のとおりです。 単体テスト 統合テスト 機能テスト 性能試験 受け入れ試験

11 testing  scrum 

Martin FowlerによるRefactoringを読み直しています。第4章「テストの構築」で、次の文章に出会いました。 実際、テストを作成する最も便利な時期の1つは、プログラミングを開始する前です。機能を追加する必要がある場合は、テストを作成することから始めます。これは思ったほど後方ではありません。テストを書くことで、関数を追加するために何をする必要があるかを自問しています。また、テストの記述は、実装ではなくインターフェイスに集中します（常に良いことです）。また、テストが機能するときに、コーディングを完了する明確なポイントがあることも意味します。 私は現在、テスト駆動開発の提唱者ですが、5年近く前にこの本を最初に読んだときにこの概念を紹介されたことを覚えていませんでした。 Amazon.comによると、この本はもともと1999年7月8日に発行されました。これは、テストファーストプログラミングへの最初の発行されたリファレンスですか、それとももっと早いものですか？

11 testing  history 

テストを書くとき、誰かがデータをモックするだけでなくインメモリデータベースを使用したいのはなぜですか？ インメモリデータベースは、自分のリポジトリをテストするのに役立つことがわかりました。ただし、フレームワーク（Spring Dataなど）を利用する場合、リポジトリのテストはフレームワークのテストであり、実際にはアプリケーションロジックではありません。 ただし、モッキングはより高速に見え、単体テストやTDDを作成するときに一般的に採用されているのと同じパターンに従っています。 それで私は何が欠けていますか？インメモリデータベースが役立つのはいつ/なぜですか？

11 unit-testing  testing  tdd  mocking 

関数Bをテストする場合、その関数Bを呼び出す関数Cをテストします。つまり、その関数Bを呼び出す関数Cをテストするためのテストプログラムを作成しても、テストメソッドはユニットテストなどと呼ばれますか？ ターゲット関数を呼び出す関数を間接的にテストすることが望ましい場合、および関数を直接テストすることが望ましい場合はいつですか？

11 unit-testing  testing 

最近、修士プログラムのソフトウェアエンジニアリングコースの最終試験を受けましたが、試験の質問の1つは次のとおりです。 Unit Testing is considered: a. White-box Testing b. Black-box Testing c. Either 7年間のソフトウェア開発経験の中で、ユニットテストは常にホワイトボックスアプローチを採用してきました。テスターは、テストを作成する間、常にユニットの実装について完全な知識を持っています。ブラックボックステストは、統合、システム、および受け入れテストという形で常に後になります。 ただし、（教授によると）試験に対する正解は、単体テストはホワイトボックステストまたはブラックボックステストのいずれかであるということです。 私はいくつかの調査を行いましたが、多くの場合、「ブラックボックスユニットテスト」は、コードが作成される前にユニットテストが記述されるテストファーストアプローチを記述するために使用されているようです。しかし、私の意見では、これはまだホワイトボックステストです。実装はまだ存在していませんが、テストを書いている人は一般に、ソースコードの実装方法についてかなり良い考えを持っています。 ブラックボックスユニットテストのしくみ（本当にそうである場合）とホワイトボックスユニットテストとの違いを誰かに説明してもらえますか？

11 unit-testing  testing  tdd 

新しい機能とバグ修正のテストを担当する人（Tedと呼ぶことにします）がいます。 GitとGitHubを使用しています。master常に展開可能である必要developmentがあり、新しい機能やバグ修正をコミット/マージする場所ですが、Tedによってテストされた後でなければなりません。 プロジェクトはPHPにあります。 テストプロセスは次のようにします。 開発者は新機能（課題追跡に記載されているTedとしての機能/バグ＃123としましょう）に取り組みたいので、ローカルリポジトリにプルorigin/developmentし、そこからdevelopment新しいブランチ（としましょうissue-123）を作成します。 作業に満足したら、新しいブランチをコミットしてにプッシュしoriginます。 Tedは接続しtest.ourproject.com/choose-branchてブランチのリストを確認し、originスイッチをオンにしますissue-123（Webページから実行できます）。その後、彼はに進みtest.ourproject.com、Webアプリケーションの地獄をテストし（彼は本当に無慈悲です）、開発者と何度かやり取りした後、彼は機能に満足しています。 テッドは、彼がマージすることができ、開発者告げるissue-123上にdevelopment上をorigin。 すすぎ、繰り返します。 3番目のステップでは、その仕事（特定のページからの分岐の表示と切り替え）をハッキングすることができますが、ここで説明したことは非常に一般的なパターンだと感じています。 だから私の質問は： これは分岐のための良い/持続可能な/保守可能なワークフローですか？このワークフローに従う他のプロジェクトの例をいくつか挙げて、回答を裏付けることができますか？

11 testing  git  integration