タグ

Systemに関するnaoto_akazawa_1のブックマーク (35)

  • ユーザ受入れテスト(UAT) - ユーザ受入れテスト(UAT)のテストケースを書くことになりました。書いたことがないのですがどのレベ... - Yahoo!知恵袋

    ユーザ受入れテストとは、ユーザ側が納品された製品を受け入れる(=対価を払う)かどうか を判定する為の重要なフェーズです。 開発側からすれば、受入れ検収なしでメクラ判をついてもらったほうがありがたいのですが、 それでは番稼動してから不具合が起こった時に困るのはユーザです。 主目的は「要求仕様」を満たしているかのチェックです。 「要求仕様書」「要件定義書」などと照らし合わせ、チェックすることになります。 なので、システムテストとは異なり、システムの中身をチェックするのではなく、 システムをブラックボックスとして、業務が想定通りに行えるかという観点でテスト を実施します。 定型業務、非定型業務、日次業務、月次業務、決算業務などの 各業務単位で、業務フローに基づいた手順でシステムのI/Oを検証することになります。 また、運用テストとしては、高負荷テスト(想定最大データ量での処理能力テスト)や、

    ユーザ受入れテスト(UAT) - ユーザ受入れテスト(UAT)のテストケースを書くことになりました。書いたことがないのですがどのレベ... - Yahoo!知恵袋
  • 【中級】無駄なく確実にテストする II 結合テスト

    結合テストの目的は,単体テストが完了したプログラムを「機能」や「サブシステム」単位で組み合わせ,基設計書に定義された仕様を満たしているかどうかを確認すること。 代表的な手法は,(1)機能単位にプログラムを結合してテスト対象とする「ブラックボックス・テスト」,(2)さらにサブシステム単位に機能をまとめてテスト対象とする「動作確認テスト」の2つがある。 また,プログラムの結合はトップダウンで実施されるのが一般的だ。そのため,テストは結合された上位機能から順に実施され,呼び出される下位のプログラムの代わりには「スタブ」などを用いる*13。 II-(1):ブラックボックス・テスト このテストでは,テスト対象が「機能」となる。機能は,「複数のプログラムの集合体」であり,「データを入力すると,一意の出力データを得られる箱」と考えることができる。「ブラックボックス・テスト(機能テスト)」は,この中身の

    【中級】無駄なく確実にテストする II 結合テスト
  • 結合テストと総合テスト

    ソフトウェアの開発におけるテスト作業は、「テスト計画」「テスト設計」「テスト実施」「テスト管理」という4つのプロセスで構成されます(図1)。 テスト計画プロセスでは、テスト全体の指針や概要をまとめます。テストの目的、対象範囲、実施方法、テスト体制、テスト環境、スケジュール、合格基準など、テスト全般に関わる方針を「テスト計画書」にまとめ、ユーザを含むプロジェクトメンバー全員で方向性を共有します。 テスト設計プロセスでは、策定されたテスト計画に基づいて、実際のテスト作業内容を設計します。テストのシナリオやテスト内容、確認すべき項目などを「テスト仕様書」に具体的に定義します。 テスト実施者は、このテスト仕様書に基づいてテストを実施します。障害を発見した際は、障害番号を採番し、障害管理票に記載して残管理します。これらの障害が片づいて、テストが正常に行われた場合は「テスト報告書」で報告します。 弊社

  • ホワイトボックステスト

    日頃より楽天のサービスをご利用いただきましてありがとうございます。 サービスをご利用いただいておりますところ大変申し訳ございませんが、現在、緊急メンテナンスを行わせていただいております。 お客様には、緊急のメンテナンスにより、ご迷惑をおかけしており、誠に申し訳ございません。 メンテナンスが終了次第、サービスを復旧いたしますので、 今しばらくお待ちいただけますよう、お願い申し上げます。

  • SQL入門

    あなたがSQLの初心者であれ、 SQLをちょっと復習したいデータ ウェアハウス業界の経験豊かな人であれ、いいところに来られました。この SQL教材のサイトは、よく使われる SQL コマンドが掲載してあります。このサイトは以下のように分かれます。 - SQL コマンド: SQL がどのように保存、読み込み、又はデータベース内のデータ処理に使われること。 - テーブル処理: データベース内のテーブル作成にSQL がどのように使われること。 - SQL プログラミング: 当該教材に提示される SQL プログラミングを示すページ。 各コマンドについては、あらかじめ、当該プログラミングを示し、説明します。それから、そのコマンドの使い方をよく理解させるように、例を一つ挙げます。このサイトにおけるすべての教材を読み終えたとき、 SQL プログラミングについて、大まかな理解ができるはずだと思います。 そし

  • SQL -TECHSCORE-

    ここでは、リレーショナル型データベースを操作するために必須となる世界標準言語 SQL について、基礎から応用まで詳しく説明しています。 また、SQL のみにとどまらず、リレーショナルデータベースマネージメントシステム (RDBMS) の持つ様々な機能について詳しく説明しています。 最後には、データベースの設計に関する非常に重要な考え方についても触れていますので、これらを全て学習すると、データベースの操作から設計まで幅広い知識を身につけることができるでしょう。 SQL INDEX 1. データベースの概要 1.1. データベースとは 1.2. データベースシステムの特徴 1.3. データベースとファイルの違い 1.4. 代表的なデータモデル 1.5. リレーショナル型データベース 1.6. まとめ 2. SQL 2.1. SQL歴史 2.2. SQL とは 2.3. SQL の機能 2.

  • ソフトウェアテスト - Wikipedia

    ソフトウェアテスト (英: software testing) は、コンピュータのプログラムから仕様にない振舞または欠陥(バグ)を見つけ出す作業のことである。ソフトウェアテストで見つかったプログラム中の欠陥を修正する作業をデバッグという。ソフトウェアテストに成功するとは、テストで欠陥が発見されるか、規定した試験項目にすべて合格するか、規定した品質目標に到達することである。目標とした品質には、規定した試験項目にすべて合格することもある。例えば、OS, プログラミング言語では、仕様を満たしているかどうかの適合試験を規定している。ソフトウェアテストでは、欠陥が存在することを示すことはできるが、欠陥が存在しないことは証明できない。ソフトウェアに仕様にない振舞がないことを保証する作業を証明といい、証明用のシステム、証明しやすい言語も多数存在している。項では動的なソフトウェアテストを中心に扱う。 目

  • ブラックボックステストとは - IT用語辞典

    入力と出力のみに着目し、様々な入力に対して想定通りの出力が得られるかどうかを確認する。テストケースの作成などに関して、内部の処理手順やプログラムの構造などは考慮しない。 とはいえ、闇雲に値を与えても正しい処理が行われているか確認できないため、仕様上同じ処理が行われるはずの値の範囲やグループを求め、それぞれの範囲から代表値を選んでテストする「同値分割」や、範囲の境界付近が正しく処理されるか確認する「限界値分析」(境界値分析)などの手法が用いられる。 一方、プログラムなどの構造を見ながら内部のデータやコードが正しく機能しているかを検証する手法を「ホワイトボックステスト」(white box testing)という。

    ブラックボックステストとは - IT用語辞典
  • ホワイトボックステストとは - IT用語辞典

    概要 ホワイトボックステスト(white-box testing)とは、ソフトウェアテストの手法の一つで、プログラムの内部構造を理解した上でそれら一つ一つが意図した通りに動作しているかを確認するテスト。 開発したプログラムの挙動を確かめるテスト手法の一つで、プログラムコードの構造に基づいて命令文や内部状態を網羅するようにテストケースを作成する。コードの理解が前提となるため開発者が実施することが多く、主に単体テスト(ユニットテスト)で用いられる。 テスト対象のソースコードのうち、どの程度の割合のコードがテストされたかを表す尺度を「カバレッジ」(テストカバレッジ/コードカバレッジ)という。何に着目するかによって「命令網羅」「判定条件網羅」「条件網羅」「複数条件網羅」「経路組み合わせ網羅」などの種類がある。 ホワイトボックステストはコードが意図した通りに動作しているかを確かめられるが、コードの内

    ホワイトボックステストとは - IT用語辞典
  • トップダウンテストとは - IT用語辞典

    概要 トップダウンテスト(top-down testing)とは、ソフトウェアやシステムのテスト手法の一つで、上位のモジュールから順に結合しながら動作を検証していく方式。 複数のモジュール(部品)を組み合わせてソフトウェアなどを開発する場合、問題の発生箇所を特定しやすくするため、いきなりすべてを繋いで一気に調べるのではなく、少しずつ追加していきながら何度も繰り返し試験する「結合テスト」がよく用いられる。 その際、「スタブ」(stub)と呼ばれるダミーの下位側(呼び出される側)のモジュールを用意し、上位モジュールから順に結合してテストする方式をトップダウンテストという。上位モジュールに問題が見つからなければ、スタブを物の下位モジュールに置き換えて再びテストが行われる。同じ手順を何段階も繰り返し、上位側から下位側へ順番にテスト対象を広げていく。 最上位のモジュールからテストしていくため、シス

    トップダウンテストとは - IT用語辞典
  • スタブ - Wikipedia

    スタブ(stub)とは、コンピュータプログラムのモジュールをテストする際、そのモジュールが呼び出す下位モジュールの代わりに用いる代用品のこと[1]。下位モジュールが未完成でも代わりにスタブを用いることでテストが可能になる。逆に上位モジュールの代わりに用いる代用品をドライバ(ソフトウェアの場合)またはコントローラ(ハードウェアの場合)と呼ぶ。ただし、仮のモジュールではなく正規のモジュールについてもドライバまたはコントローラと呼ばれることがあるので、区別するために「テストドライバ」や「サンプルドライバ」などと呼ぶことも多い。 なお、stubの原義は使い残し、半券、切り株といった意味である[2]。 概要[編集] 呼び出す側(上位)のモジュールを検査する場合に、呼び出される側(下位)の部品モジュールが未完成であることがある。このとき、呼び出される側の部品モジュールの代用とする仮のモジュールを、「ス

  • コンポーネントとは - IT用語辞典

    概要 コンポーネント(component)とは、部品、成分、構成要素などの意味を持つ英単語ITの分野では機器やソフトウェア、システムの構成する部品や要素などのことを意味する。 ソフトウェア開発の分野では、特定の機能を持ち単体で完結しているが、単体では使用せず(できず)、他のプログラムから呼び出されたり連結されたりして使用されるプログラム部品のことをソフトウェアコンポーネントという。 特に、ある特定のシステムの一部を構成するのみに留まらず、将来単体で提供されて他のソフトウェアに組み入れられたり、他の開発プロジェクトで再利用されることを意図し、汎用性や独立性を高めた仕様や設計を持つものを指してコンポーネントと呼ぶことが多い。 また、ソフトウェア開発の中でも、GUIアプリケーションやWebシステムの場合には、実行時の操作画面を構成する個々の操作要素(ボタンやテキストボックスなど)のことや、それ

    コンポーネントとは - IT用語辞典
  • 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:初めてのソフトウェアメトリクス(前編)

    ソフトウェアメトリクスとは ソフトウェアメトリクス(品質測定:メトリクス)とは、ソフトウェア開発をさまざまな視点から定量的に評価したものです。普段実際の開発現場では触れられることの少ないキーワードですが、記事では「ソフトウェアの品質向上」という視点からソフトウェアメトリクスに焦点を当て、開発現場へのメトリクスの導入方法やその効果について解説していきます。 ソフトウェアにとっての品質 エンジニアなら誰もが、良いソフトウェアを作りたい、という思いを持っていると思います。ところが現実には、理想的なソフトウェアを作成するための十分な時間も潤沢な予算もなかなかないのが現状だと思います。それは、ソフトウェアの良しあし、すなわち品質ということについて、顧客と開発会社双方に十分な認識がないからです。このような“慣習”がソフトウェアの開発業界において「作りっ放しで終わり」という悲しい風潮をまかり通らせる背

    @IT:初めてのソフトウェアメトリクス(前編)
  • 第8回 ウォークスルーとインスペクション--設計・開発の早期に欠陥を発見・除去し品質を作り込む

    「ウォークスルー」と「インスペクション」は,システム開発の早い段階で欠陥を発見・除去するための方法である。開発者自身やチーム内の「モデレータ」と呼ばれる調整役が自主的に運営することが特徴だ。今回は,品質向上に欠かせないウォークスルーとインスペクションの具体的な実施手順を解説する。 布川 薫/日IBM 前回は,プロジェクト遂行段階における品質のトラッキング方法(品質保証活動)の概要を説明した。今回は,システム開発において最もポピュラーで効果的な品質保証活動の1つである「ウォークスルー」と「インスペクション」の進め方を,読者が今からすぐにでも実行できるよう,具体的に説明しよう。 欠陥の発見が遅れれば遅れるほど,修正作業の手間がいたずらに増えることは,この連載でも再三強調してきた。肝心なのは,設計・開発の初期段階から,頻繁に欠陥の発見・除去活動を行い,テストの段階までに持ち越される欠陥を最少限

    第8回 ウォークスルーとインスペクション--設計・開発の早期に欠陥を発見・除去し品質を作り込む
  • システム開発プロセスは,本当に反復型が主流になるのか?

    欄の読者は,自社でシステムを開発する際のプロセス(開発プロセス)として,どんなやり方を採用しているだろうか。こんな疑問を持ったのは,日経ITプロフェッショナル7月号で予定している,開発プロセスに関する特集を担当することになったからだ。 主流は今もなお,ウォーターフォール型だろう。しかし,ここにきてRUP[用語解説]やXP[用語解説]のような反復型(スパイラル型)を採用する企業も,目立ってきている。開発プロセスとしてはどちらを選ぶべきなのか――。 注目を集める反復型 ご存じのように,ウォーターフォール型は,大手ITベンダーをはじめとして,多くのシステム・インテグレータ(SI)が自社の開発プロセス標準として採用している。システム開発の歴史は,すなわちウォーターフォール型を洗練させる歴史,と言っても過言ではないほどだ。だが,このウォーターフォール型が,一部のプロジェクトで適用しなくなってきてい

    システム開発プロセスは,本当に反復型が主流になるのか?
  • IBM - 第6回 ITアーキテクチャとシステムズ・エンジニアリング (2) - Japan

  • 機能要件は3階層で整理

    上はarrowheadの全体機能と利用者や接続システムを示す「全体業務フロー図」。中は業務単位で機能間の連携をまとめた図。下は機能をさらに細分化して要件を記述したもの 最上位層に当たるのが左上の「全体業務フロー図」。arrowheadを中心に配置し、接続先システムやシステムの利用者を周辺に並べて、それらの関係性を図式化した。 全体業務フロー図の狙いは、1枚の資料でシステム全体を俯瞰できるようにすることだ。「注文処理」や「情報配信」「取引規制」などの機能群を、どの粒度でどのように分類するのが最善かを検討しやすくなると期待した。 記述が細かすぎると全体を直感的に把握できない。かといって大ざっぱすぎても意味がないので、粒度には気を配った。今回は外部に位置する接続先システムや利用者などの「アクター」と呼ぶ存在に着目して機能群を分けた。arrowheadが処理するデータはアクターから入ってくる。出力

    機能要件は3階層で整理
  • 機能要件設計書だけで20種類

    意図が伝わる設計書を作るには,前提として「それぞれの設計書がどういう役割を担うか」「それぞれの設計書が相互にどういう関係にあるか」を正しく理解しておくことが重要である。豊富なサンプルとともに,設計書の役割と関係,さらには書き方のコツを解説する。 石川貞裕 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進部 担当部長 向坂太郎 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進部 「基設計書」と聞いて,どんなものをイメージするだろうか。業務フロー図や画面レイアウト,E-R図など様々だろう。大規模,高品質のシステムを開発するなら,図1に示すような多くの設計書を作成することになる。 中心となる機能要件設計だけでも20種類。それぞれの役割や関係をきちんと理解し,過不足なく設計情報を盛り込むことが求められる。 難しいのは,設計書の読み手が開発者だけではないことだ

    機能要件設計書だけで20種類