【中級】無駄なく確実にテストする II 結合テスト
結合テストの目的は，単体テストが完了したプログラムを「機能」や「サブシステム」単位で組み合わせ，基本設計書に定義された仕様を満たしているかどうかを確認すること。 代表的な手法は，（1）機能単位にプログラムを結合してテスト対象とする「ブラックボックス・テスト」，（2）さらにサブシステム単位に機能をまとめてテスト対象とする「動作確認テスト」の2つがある。 また，プログラムの結合はトップダウンで実施されるのが一般的だ。そのため，テストは結合された上位機能から順に実施され，呼び出される下位のプログラムの代わりには「スタブ」などを用いる＊13。 II-(1)：ブラックボックス・テスト このテストでは，テスト対象が「機能」となる。機能は，「複数のプログラムの集合体」であり，「データを入力すると，一意の出力データを得られる箱」と考えることができる。「ブラックボックス・テスト（機能テスト）」は，この中身の
結合テストと総合テスト
ソフトウェアの開発におけるテスト作業は、「テスト計画」「テスト設計」「テスト実施」「テスト管理」という4つのプロセスで構成されます（図1）。 テスト計画プロセスでは、テスト全体の指針や概要をまとめます。テストの目的、対象範囲、実施方法、テスト体制、テスト環境、スケジュール、合格基準など、テスト全般に関わる方針を「テスト計画書」にまとめ、ユーザを含むプロジェクトメンバー全員で方向性を共有します。 テスト設計プロセスでは、策定されたテスト計画に基づいて、実際のテスト作業内容を設計します。テストのシナリオやテスト内容、確認すべき項目などを「テスト仕様書」に具体的に定義します。 テスト実施者は、このテスト仕様書に基づいてテストを実施します。障害を発見した際は、障害番号を採番し、障害管理票に記載して残管理します。これらの障害が片づいて、テストが正常に行われた場合は「テスト報告書」で報告します。 弊社
ホワイトボックステスト
日頃より楽天のサービスをご利用いただきましてありがとうございます。 サービスをご利用いただいておりますところ大変申し訳ございませんが、現在、緊急メンテナンスを行わせていただいております。 お客様には、緊急のメンテナンスにより、ご迷惑をおかけしており、誠に申し訳ございません。 メンテナンスが終了次第、サービスを復旧いたしますので、 今しばらくお待ちいただけますよう、お願い申し上げます。
ソフトウェアテスト - Wikipedia
ソフトウェアテスト (英: software testing) は、コンピュータのプログラムから仕様にない振舞または欠陥（バグ）を見つけ出す作業のことである。ソフトウェアテストで見つかったプログラム中の欠陥を修正する作業をデバッグという。ソフトウェアテストに成功するとは、テストで欠陥が発見されるか、規定した試験項目にすべて合格するか、規定した品質目標に到達することである。目標とした品質には、規定した試験項目にすべて合格することもある。例えば、OS, プログラミング言語では、仕様を満たしているかどうかの適合試験を規定している。ソフトウェアテストでは、欠陥が存在することを示すことはできるが、欠陥が存在しないことは証明できない。ソフトウェアに仕様にない振舞がないことを保証する作業を証明といい、証明用のシステム、証明しやすい言語も多数存在している。本項では動的なソフトウェアテストを中心に扱う。 目
ブラックボックステストとは - IT用語辞典
入力と出力のみに着目し、様々な入力に対して想定通りの出力が得られるかどうかを確認する。テストケースの作成などに関して、内部の処理手順やプログラムの構造などは考慮しない。 とはいえ、闇雲に値を与えても正しい処理が行われているか確認できないため、仕様上同じ処理が行われるはずの値の範囲やグループを求め、それぞれの範囲から代表値を選んでテストする「同値分割」や、範囲の境界付近が正しく処理されるか確認する「限界値分析」（境界値分析）などの手法が用いられる。 一方、プログラムなどの構造を見ながら内部のデータやコードが正しく機能しているかを検証する手法を「ホワイトボックステスト」（white box testing）という。
ホワイトボックステストとは - IT用語辞典
概要 ホワイトボックステスト（white-box testing）とは、ソフトウェアテストの手法の一つで、プログラムの内部構造を理解した上でそれら一つ一つが意図した通りに動作しているかを確認するテスト。 開発したプログラムの挙動を確かめるテスト手法の一つで、プログラムコードの構造に基づいて命令文や内部状態を網羅するようにテストケースを作成する。コードの理解が前提となるため開発者が実施することが多く、主に単体テスト（ユニットテスト）で用いられる。 テスト対象のソースコードのうち、どの程度の割合のコードがテストされたかを表す尺度を「カバレッジ」（テストカバレッジ/コードカバレッジ）という。何に着目するかによって「命令網羅」「判定条件網羅」「条件網羅」「複数条件網羅」「経路組み合わせ網羅」などの種類がある。 ホワイトボックステストはコードが意図した通りに動作しているかを確かめられるが、コードの内
トップダウンテストとは - IT用語辞典
概要 トップダウンテスト（top-down testing）とは、ソフトウェアやシステムのテスト手法の一つで、上位のモジュールから順に結合しながら動作を検証していく方式。 複数のモジュール（部品）を組み合わせてソフトウェアなどを開発する場合、問題の発生箇所を特定しやすくするため、いきなりすべてを繋いで一気に調べるのではなく、少しずつ追加していきながら何度も繰り返し試験する「結合テスト」がよく用いられる。 その際、「スタブ」（stub）と呼ばれるダミーの下位側（呼び出される側）のモジュールを用意し、上位モジュールから順に結合してテストする方式をトップダウンテストという。上位モジュールに問題が見つからなければ、スタブを本物の下位モジュールに置き換えて再びテストが行われる。同じ手順を何段階も繰り返し、上位側から下位側へ順番にテスト対象を広げていく。 最上位のモジュールからテストしていくため、シス
スタブ - Wikipedia
スタブ（stub）とは、コンピュータプログラムのモジュールをテストする際、そのモジュールが呼び出す下位モジュールの代わりに用いる代用品のこと[1]。下位モジュールが未完成でも代わりにスタブを用いることでテストが可能になる。逆に上位モジュールの代わりに用いる代用品をドライバ（ソフトウェアの場合）またはコントローラ（ハードウェアの場合）と呼ぶ。ただし、仮のモジュールではなく正規のモジュールについてもドライバまたはコントローラと呼ばれることがあるので、区別するために「テストドライバ」や「サンプルドライバ」などと呼ぶことも多い。 なお、stubの原義は使い残し、半券、切り株といった意味である[2]。 概要[編集] 呼び出す側（上位）のモジュールを検査する場合に、呼び出される側（下位）の部品モジュールが未完成であることがある。このとき、呼び出される側の部品モジュールの代用とする仮のモジュールを、「ス
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年5月時点の調査。
ピアレビュー
cles::blog 平常心是道 blogs: cles::blog NP_cles() « ヒラル :: フィッシングも著作権法違反？ » 2005/06/12 ピアレビュー SE softwareengineering 76 10へぇ 研究のために必要だったので読んでみたのですがなかなか面白かったです。peer reviewだから、読んで字のごとく同等の人同士で行うレビューですね。そういえば、学術論文の査読とかもピアレビューって言いますね。。。。 ただ、欲を言えば全体的にちょっとボリューム不足な感じ。おそらくレビューについてのベストプラクティスについてのまとめを書いたつもりなんでしょうけど、それを導き出すために利用した事例の説明とか、ワークシートの解説なんかが少なすぎて、哲学というか一般論の羅列のようになってしまっているような感じがしました。おそらく、普通の大学生レベルが読んだとし
＠IT：初めてのソフトウェアメトリクス（前編）
ソフトウェアメトリクスとは ソフトウェアメトリクス（品質測定：メトリクス）とは、ソフトウェア開発をさまざまな視点から定量的に評価したものです。普段実際の開発現場では触れられることの少ないキーワードですが、本記事では「ソフトウェアの品質向上」という視点からソフトウェアメトリクスに焦点を当て、開発現場へのメトリクスの導入方法やその効果について解説していきます。 ソフトウェアにとっての品質 エンジニアなら誰もが、良いソフトウェアを作りたい、という思いを持っていると思います。ところが現実には、理想的なソフトウェアを作成するための十分な時間も潤沢な予算もなかなかないのが現状だと思います。それは、ソフトウェアの良しあし、すなわち品質ということについて、顧客と開発会社双方に十分な認識がないからです。このような“慣習”がソフトウェアの開発業界において「作りっ放しで終わり」という悲しい風潮をまかり通らせる背
第8回 ウォークスルーとインスペクション--設計・開発の早期に欠陥を発見・除去し品質を作り込む
「ウォークスルー」と「インスペクション」は，システム開発の早い段階で欠陥を発見・除去するための方法である。開発者自身やチーム内の「モデレータ」と呼ばれる調整役が自主的に運営することが特徴だ。今回は，品質向上に欠かせないウォークスルーとインスペクションの具体的な実施手順を解説する。 布川 薫／日本IBM 前回は，プロジェクト遂行段階における品質のトラッキング方法（品質保証活動）の概要を説明した。今回は，システム開発において最もポピュラーで効果的な品質保証活動の1つである「ウォークスルー」と「インスペクション」の進め方を，読者が今からすぐにでも実行できるよう，具体的に説明しよう。 欠陥の発見が遅れれば遅れるほど，修正作業の手間がいたずらに増えることは，この連載でも再三強調してきた。肝心なのは，設計・開発の初期段階から，頻繁に欠陥の発見・除去活動を行い，テストの段階までに持ち越される欠陥を最少限
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
