テスト関連の記事(Wiki化以前)に関するページ

記事 / テスト関連(Wiki化以前)

  • Q&A:システム稼働前のテストについて教えて?
    • ITpro 編集部
    • 2006/5/25
    • ITpro SMB
    • http://itpro.nikkeibp.co.jp/article/COLUMN/20060525/239020/
    • (引用)Q:オンラインショップを運営するため,Webシステムの構築を検討しています。ベンダーが開発テストに力を入れたいと打診してきましたが,システム稼動前のテストはそんなに重要なものなのでしょうか? また,どのような流れで行うのでしょうか?
  • 実践!電卓で学ぶソフトウェアテストのコツ
    • 吉田 誠一
    • 2005/11/18
    • http://www.aerith.net/design/test_calc-j.html
    • (引用) 品質の良いソフトウェアを作るためには、ソフトウェアテストの技術が不可欠です。(略) バグを見つける技術は、経験で身につけるのが一番でしょう。ここでは、Windowsに付いてくる「電卓」から、バグが見つけられるかどうか、試してみたいと思います。
  • 実業務に使えるシステムか? 運用試験と実用準備
    • 青島 弘幸<BR>
    • 2005/9/23
    • 企業システム戦略の基礎知識 / @IT
    • http://www.atmarkit.co.jp/fbiz/cinvest/opinion/basic/11/01.html
    • (引用)システム構築の最終段階である運用試験は、開発してきたシステムが実際の業務に耐えるか否かを調べる重要なフェイズだ。しかしベンダに依存し過ぎていたりすると、意外に疎かにされてしまう。開発目的を忘れずにチェックしていこう。
  • Webアプリケーションのパフォーマンス・テストを行うには?
    • 山田 祥寛
    • 2005/9/16
    • .NET TIPS / @IT
    • http://www.atmarkit.co.jp/fdotnet/dotnettips/351aspperftest/aspperftest.html
    • (引用)テスト工程の重要な1ステップとして、パフォーマンス性能を判断する「負荷テスト」の存在は欠かせないものだろう。(略)Visual Studio .NET(以降、VS.NET) 2003 Enterprise Edition(もしくはVS.NET 2002 Enterprise Edition)を利用しているならば、付属の「Application Center Test」(以下、ACT)を利用して、負荷テストを実施することが可能だ。ACTならばユーザー・インターフェイスが日本語化されているのはもちろん、ヘルプ・ドキュメントも充実しているため、容易に利用することができる。本稿では、このACTを利用した具体的な負荷テストの手順を紹介する。
  • JMeterによるWebサーバ性能評価の勘所
    • 鶴長 鎮一
    • 2005/9/6
    • 実用 Apache 2.0運用・管理術 / @IT
    • http://www.atmarkit.co.jp/flinux/rensai/apache2_02/apache02a.html
    • (引用)Apacheはそのままでも十分なパフォーマンスを発揮しますが、設定値や構成の見直しを行うことで、さらに高い性能を得ることができます。しかし、適切な値を設定しなければ、サーバの潜在能力や許容量をオーバーし、かえってパフォーマンス低下を招く可能性もあります。経験やノウハウの蓄積が少ない状態では、チェック&トライの繰り返しが必要です。今回は、チェックのための道具であるベンチマークソフトの使い方とその結果の見方を紹介します。
  • 紛争勃発に備えよ!──受け入れ検査時のトラブル対策
    • 青島 弘幸
    • 2005/8/25
    • 企業システム戦略の基礎知識 / @IT
    • http://www.atmarkit.co.jp/fbiz/cinvest/opinion/basic/10/01.html
    • (引用)システムの納品・検収の際に発生しやすいのが、「欠陥か、仕様変更か」をめぐるトラブルだ。こうした“紛争”を丸く収める方法を伝授する。
  • プロファイラでメモリリークとパフォーマンス問題を解決
    • 岡崎 隆之(サン・マイクロシステムズ)
    • 2005/8/10
    • Java開発の問題解決を助ける / @IT
    • http://www.atmarkit.co.jp/fjava/rensai3/debug02/debug02_1.html
    • (引用)この連載は、Java開発を妨げるさまざまな問題の解決方法を扱います。第2回は、プロファイラを使ってメモリリークやパフォーマンスの問題を解決する手法を紹介します。
  • 納品されたシステムに対する効果的な検収方法
    • 青島 弘幸
    • 2005/7/23
    • 企業システム戦略の基礎知識 / @IT
    • http://www.atmarkit.co.jp/fbiz/cinvest/opinion/basic/09/01.html
    • (引用)業者側での統合試験が完了すると、いよいよ納品だ。納品後は、速やかに受け入れを実施し、検収しなければならない。単なる心配性から、だらだらと時間をかけるのはよろしくない。要件定義書と要求仕様書に従って、要求どおりにシステムが作られているかどうかを淡々とチェックする。検査中に、プログラムの不具合や要求事項の漏れなどに気が付くかもしれないが、後でまとめて対策を考えることとし、その場で是正作業に入ったり、仕様変更を要求したりしないことだ。
  • 正規表現の入力・テストを行うプラグイン
    • 岡本 隆史(NTTデータ)
    • 2005/7/21- CoolなEclipseプラグイン / @IT
    • http://www.atmarkit.co.jp/fjava/rensai3/eclipseplgn05/eclipseplgn05_1.html
    • (引用)今回は、正規表現の入力、テストを支援するQuickRExプラグイン、ログ出力コードの入力を支援するLog4E、プロパティファイルの入力を支援するCrossJPropEditorをご紹介します。
  • フリーツールで行うネットワーク脆弱性検査
    • 遠藤 宣孝(三井物産セキュアディレクション)
    • 2005/7/7
    • 知ってるつもり?「セキュリティの常識」を再確認 / ITmedia
    • http://www.itmedia.co.jp/enterprise/articles/0507/07/news001.html
    • (引用)Webアプリケーションの検査に加えて、サーバやネットワークの検査も重要だ。改めてネットワーク脆弱性検査の重要性を認識するためにも、今回はフリーツールを使ったネットワーク脆弱性検査を紹介する。
  • Delta Debuggingの紹介
    • Alessandro Giusti(NewsForge.com)
    • 2005/7/6
    • japan.linux.com
    • http://japan.linux.com/desktop/05/07/12/0249222.shtml
    • (引用)開発者なら誰でもデバッグ――プログラムコード内の不具合を見つけて修正する作業――が重要な工程であることを知っている。デバッグに徹した取り組みが、ソフトウェア開発のほかのどの工程にコストをかけるより重要な場合も多い。一つのバグの原因がわからないために開発者が長時間かかり切りになることもあり、デバッグ作業は予測不可能だ。しかも不幸なことに、これまでのデバッグはたいてい手作業だった。だが、それもDelta Debuggingの登場によって変わろうとしている。
  • 「Whoppix」を使ってペネトレーションテストをやろう
    • 岡崎 隆之(サン・マイクロシステムズ)
    • 2005/6/29
    • Security&Trust ウォッチ / @IT
    • http://www.atmarkit.co.jp/fsecurity/column/ueno/34.html
    • (引用)KNOPPIXというLinuxを聞いたことがあるだろうか? KNOPPIXは1CD Linuxに分類されるもので、CDから起動できるためインストールなどを行う必要がない。そのKNOPPIXをベースとして、ペネトレーションテスト用のツールを数多く組み込み、1CD LinuxとしてパッケージしたものがWhoppixである。
  • デバックでのブレークポイント活用
    • 岡崎 隆之(サン・マイクロシステムズ)
    • 2005/6/23
    • Java開発の問題解決を助ける / @IT
    • http://www.atmarkit.co.jp/fjava/rensai3/debug01/debug01_1.html
    • (引用)「結果が期待と異なる」「パフォーマンスが出ない」「どうやらメモリリークしている」「コーディング規約がなかなか守られない」など、Java開発における問題点は無数にあります。これらの問題解決を効率的に行うためには、ツールや技術が必要です。(略)第1回は、統合開発環境(IDE)に装備されているデバッグツールを活用した問題解決を紹介しましょう。
  • Webアプリケーションセキュリティの常識
    • 杉山 俊春(三井物産セキュアディレクション)
    • 2004/6/16
    • 知ってるつもり?「セキュリティの常識」を再確認 / ITmedia
    • http://www.itmedia.co.jp/enterprise/articles/0506/16/news030.html
    • (引用)Webアプリケーションの脆弱性のほとんどは、開発時のささいなミスから生じる。Webアプリケーションの攻撃から保護するには、専門家によるペネトレーションテストが有効だ。
  • ユーザーにとっては“ユーザーインターフェイス”こそが製品そのもの
    • 上野 学(ソシオメディア)
    • 2005/6/2
    • Webアプリケーションのユーザーインターフェイス / @IT
    • http://www.atmarkit.co.jp/fwcr/rensai/usability01/01.html
    • (引用)この「Webアプリケーションのユーザーインターフェイス」シリーズでは、GUIの基礎的な概念の確認から、ハイパーメディア(Web)に適したデザイン、設計プロセスについてのメソッド、各種UIコントロールを利用する際に考慮すべきルールなどを解説していきます。
  • システム発注で後悔しない契約書のチェック・ポイント
    • 青島 弘幸
    • 2005/5/31
    • 企業システム戦略の基礎知識 / @IT
    • http://www.atmarkit.co.jp/fbiz/cinvest/opinion/basic/07/01.html
    • (引用)システム開発を外部に委託する場合、トラブル発生時の「備え」として大切なのが契約書だ。無用なトラブル、追加費用を回避する契約書とはどのようなものか、そのポイントを見ていこう。(略)納品後の検収も完了の条件をするかを契約時点で取り決めておく。しかし、検収時点ですべての不具合を発見できる可能性は低いので、瑕疵に関しても期間や定義を契約書で定めることができれば、かなり安心である。
  • jWebUnitフレームワークでWebアプリケーションのテストが容易に
    • Amit Tuli(IBM India)
    • 2005/5/31
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/java/library/j-jwebunit/ (引用)Web開発用の自動テストをお探しですか? 走り回って探す必要はありません。大部分のJava IDEに簡単にプラグインできるjWebUnitは、Webアプリケーション用のテスト・ケースを作るための、オープンソースのフレームワークです。この記事では、ソフトウェア技術者のAmit Tuliが、jWebUnitを紹介します。サンプル・アプリケーションを使いながら、簡潔なテスト・ケースを生成する方法を、順を追って説明します。
  • テスト前のレビューでエラーをつぶす
    • 増岡 直二郎(naoIT研究所)
    • 2005/5/26
    • 経営者に送る、失敗しないIT導入の勧め / 日経BP SMB+IT
    • http://itpro.nikkeibp.co.jp/free/smbit/smbit/20050526/161569/
    • (引用)前回と前々回で、システムトラブルを防ぐためにシステムテストの重要性を説き、経営者の注意を喚起した。(略)しかし、テストはあくまでもトラブルを防ぐ「最後のとりで」である。経営者としては最後のとりでを背水の陣で背負うことは、できるだけ避けたい。(略)そのためには、トラブルをテストで発見する前につぶしておけばよい。そこで登場するのが「レビュー」である。
  • システム発注で後悔しない契約書のチェック・ポイント
    • 青島 弘幸
    • 2005/5/21
    • 企業システム戦略の基礎知識 / @IT
    • http://www.atmarkit.co.jp/fbiz/cinvest/opinion/basic/07/01.html
    • (引用)システム開発を外部に委託する場合、トラブル発生時の「備え」として大切なのが契約書だ。無用なトラブル、追加費用を回避する契約書とはどのようなものか、そのポイントを見ていこう
  • 隣のテストチームが優秀ないくつかの理由(後編)
    • Len DiMaggio(IBM)
    • 2005/5/21
    • The Rational Edge / @IT
    • http://www.atmarkit.co.jp/farc/rensai/redge34/redge34.html
    • (引用)本稿はまず、「ソフトウェアテストで成功するチームと失敗するチームがあるのはなぜだろう?」という疑問から入ってきた。単純な答えや月並みの決まり文句以外に、本稿では、チームが自分たちの役割を明確にしてチーム内およびチーム間の関係を確立していく流れ、マネージャがチームに欲しがる人物のタイプ、プロジェクトマネージャやチームのメンバーがチームを成功させるべく行う管理の役割について説明してきた。
  • 隣のテストチームが優秀ないくつかの理由(前編)
    • Len DiMaggio(IBM)
    • 2005/5/18
    • The Rational Edge / @IT
    • http://www.atmarkit.co.jp/farc/rensai/redge33/redge33.html
    • (引用)ソフトウェア開発チームを編成するときの成功の秘訣は何だろうか?スーパースターを採用するのではなく、多様な長所やスキルセットを持つメンバーを確保することだ、と本稿は断言する。本稿はプロジェクトやチームのマネージャのために、チームメンバーにとって望ましい特性や、監視や矯正の必要なチームメンバーの特徴について解説する。
  • 効果的にシステムテストを行う方法とは?
    • 増岡 直二郎(naoIT研究所)
    • 2005/5/13
    • 経営者に送る、失敗しないIT導入の勧め / 日経BP SMB+IT
    • http://itpro.nikkeibp.co.jp/free/smbit/smbit/20050513/160813/
    • (引用)ほとんどの経営者はテストにまで考えが及ばないが、基本的にプログラムにはバグが必ず潜んでいる。さらにシステムは稼動してみないと、使えるかどうか、イメージがわかないもの。そうしたテストの不可欠性を、まず念頭におかなければならない。その上でテスト体制の確立、テストの計画立案が必要だ。
  • Coberturaでテスト対象範囲を調べる
    • Elliotte Harold(Polytechnic University)
    • 2005/5/2
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/java/library/j-cobertura/ (引用)Coberturaは、テスト対象範囲を調べるオープンソースのツールであり、コードベースを実装することによって、またテスト・スイートが実行する際に、どのコード行が実行され、どのコード行が実行されないかを監視して、対象範囲を調べます。また、Coberturaは未テストのコードを特定し、バグを見つけることに加えて、到達不能な、死んでいるコードにフラグを立てることによって、コードを最適化します。その結果、APIが現実的にどのように動作するかを洞察することもできます。この記事ではElliotte Rusty Haroldが、コード・カバレッジ(テスト対象範囲)に関するベスト・プラクティスを使ってCoberturaを活用する方法を解説します。
  • テスト設計の方針は千差万別
    • 大西 建児(豆蔵)
    • 2005/4/28
    • ソフトウェアテスト・エンジニアの本音 / @IT
    • http://www.atmarkit.co.jp/farc/rensai/test05/test05a.html
    • (引用)今回は2005年1月24、25日の2日間に行われたJaSST'05「ソフトウェアテストシンポジウム」の模様を通して、ソフトウェアテストに対するエンジニアの意識や認識などを浮き彫りにしていきたいと思います。
  • Q&A:システム稼働前のテストについて教えて?
    • SMB+IT
    • 2005/4/19
    • IT化 Q&A / 日経BP SMB+IT
    • http://nikkeibp.jp/wcs/leaf/CID/onair/smbit/qa/370986
    • (引用)オンラインショップを運営するため、Webシステムの構築を検討しています。ベンダーが開発テストに力を入れたいと打診してきましたが、システム稼動前のテストはそんなに重要なものなのでしょうか? またどのような流れで行うのでしょうか?
  • システムトラブルはテスト不足に端を発する
    • 増岡 直二郎(naoIT研究所)
    • 2005/4/8
    • 経営者に送る、失敗しないIT導入の勧め / 日経BP SMB+IT
    • http://nikkeibp.jp/wcs/leaf/CID/onair/smbit/masuoka/370408
    • (引用)システムトラブルを防ぐにはテストを徹底的に行うことが重要だ。しかし実際には、テストは軽視され、十分に行われていない。この状況をいかにして変えるか?
  • カバレージを考慮した機能試験の自動化(その1)
    • 加藤 大受(サイボウズ)
    • 2005/4/8
    • Webアプリケーション開発における理論的・計画的なテストの実現 / ITmedia
    • http://www.itmedia.co.jp/enterprise/articles/0504/08/news004_2.html
    • (引用)テストケースに優先順位と難易度を設定することで不具合の発見数を予想できるが、機能試験が100%網羅しているか、つまりカバレージはどのように測定すればいいだろうか。
  • テストの自動化、その最新事情
    • Danny Faught(Tejas Software Consulting)、James Bach(Satisfice)
    • 2005/3/30
    • IT Architect / @IT
    • http://www.atmarkit.co.jp/farc/rensai/s_minds01/s_minds01.html
    • (引用)かなり低価格なツールやすでに手元にあるツールを使って、2日もあればできる「自動化」(の方法)を見つけ出していただきたい。今回のコラムでは、Danny FaughtとJames Bachが、テストの自動化に対する一段上のアジャイルなアプローチを提案する。
  • Linux での Bugzilla を使用したバグの追跡
    • Jason "Jay" Clark(IBM)
    • 2005/3/18
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/linux/library/l-bugzilla/
    • (引用)サポートの場に身を置く人たちにとって、問題点を監視し、それに対して適用される修正プログラムを常に把握することは、大変な作業です。しかし、この課題に対する理想的なオープン・ソース・ソリューションがあります。それが Bugzilla です。Bugzilla をインストールすると、バグを容易に追跡でき、特定の問題やその解決策が見つかると通知を受け取ることができます。この記事では、Linuxシステムに Bugzilla をインストールするためのガイドを、順を追って説明します。
  • DoS攻撃の手口を知る
    • 出雲 教郎(日本ラドウェア株式会社)
    • 2005/3/11
    • DoS攻撃の手法と対策 / @IT
    • http://www.atmarkit.co.jp/fsecurity/special/58dos/dos02.html
    • (引用)ここではDoSアタックのコードや攻撃ツールよりも、それによって発生する攻撃内容に基づいて大まかに分類しながら、それぞれの内容と特徴について述べてみたい
  • テストを設計するには(その3)
    • 加藤 大受(サイボウズ)
    • 2005/3/4
    • Webアプリケーション開発における理論的・計画的なテストの実現 / ITmedia
    • http://www.itmedia.co.jp/enterprise/articles/0503/04/news041.html
    • (引用)今回はシステムの対応環境の組み合わせでの動作を検証するシステム構成試験、脆弱性の検証などを確認するセキュリティ試験などについて紹介する。
  • Webアプリケーションの脆弱性を総括する
    • 中村 隆之(三井物産セキュアディレクション)
    • 2005/3/4
    • Webアプリケーションに潜むセキュリティホール / @IT
    • http://www.atmarkit.co.jp/fsecurity/rensai/webhole14/webhole01.html
    • (引用)今回は本連載の最終回ということで、まとめとしてこれまでに説明してきたWebアプリケーションの脆弱性1つずつ簡単に説明していくことにする。一部、サンプルコードを示している個所もあるので開発を行っている読者は参考にしてほしい。
  • テストを設計するには(その2)
    • 加藤 大受(サイボウズ)
    • 2005/2/24
    • Webアプリケーション開発における理論的・計画的なテストの実現 / ITmedia
    • http://www.itmedia.co.jp/enterprise/articles/0502/24/news070.html
    • (引用)実システムを構築する上で、負荷試験というテストは欠かせない。今回は、さまざまな負荷のパターンについて解説するとともに、負荷試験の設計時に考慮すべきポイントなどについて考えていこう。
  • テストという破壊的な作業の建設的なやり方
    • 大西 建児(豆蔵)
    • 2005/2/18
    • ソフトウェアテスト・エンジニアの本音 / @IT
    • http://www.atmarkit.co.jp/farc/rensai/test04/test04a.html
    • (引用)今回は「Five Trends Affecting Testing」というテーマで基調講演(「ソフトウェア・テストに影響を及ぼす5つのトレンド (@ITNews)」)をしてくださった、テストの世界でご活躍中の独立コンサルタントであるレックス・ブラック(Rex Black)氏と実行委員会との懇談の様子をお伝えしましょう。
  • パフォーマンスの目: ウェイト・リーク
    • Jack Shirazi, Kirk Pepperdine(JavaPerformanceTuning.com)
    • 2005/1/20
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/java/library/j-perf01215/
    • (引用)パフォーマンス調整とデバッグの違いは紙一重です。メモリー・エラーやスレッドの競合状態(race condition)など、ある特定のカテゴリーのバグは、パフォーマンス調整の際に頻繁に表面化します。今月はパフォーマンス調整のエキスパートである Jack ShiraziとKirk Pepperdineが、ウェイト・リーク(wait leaks) と呼ばれる、特別な競合状態を見つけ出す方法を説明します。
  • テストを設計するには(その1)
    • 加藤 大受(サイボウズ)
    • 2005/1/28
    • Webアプリケーション開発における理論的・計画的なテストの実現 / ITmedia
    • http://www.itmedia.co.jp/enterprise/articles/0501/28/news002.html
    • (引用)前回は、テストプロジェクトの目次となるテスト計画書とテストの種類を解説した。今回は、テストを設計するために必要となる知識について説明する。常にレビューやテストを考慮し品質への意識を持つことが重要である。
  • 「品質でも新興勢力に負ける」、テストの専門家が指摘
    • 森側 真一(日経コンピュータ)
    • 2005/1/27
    • インタビュー / 日経IT Pro
    • http://itpro.nikkeibp.co.jp/free/NC/NEWS/20050127/155365/
    • (引用)「中国やベトナムに、生産性だけでなく品質でも負ける恐れがある」。こう指摘するのは、20年以上にわたりテストや品質保証の専門活動を続けてきた、米レックスブラック・コンサルティング・サービスのレックス・ブラック社長だ。
  • QAの革新なくしては、世界水準のソフトウェアはつくれない
    • 加藤 大受(サイボウズ)
    • 2005/1/14
    • インタビュー / ITmedia
    • http://www.itmedia.co.jp/enterprise/articles/0501/14/news003.html
    • (引用)サイボウズ(略)は品質面でもトップクラスの評価を獲得している。同社では、(略)QAプロセスを一新するプロジェクトを推進中だ。そのプロジェクトのリーダーである加藤大受氏が、わが国におけるQAの現状、サイボウズの新しい挑戦を語った。
  • 見直されるソフトウエア・テストの重要性――専門書市場にもミニ・ブーム
    • 鈴木 亨(日経BP出版局)
    • 2005/1/14
    • 記者の眼 / 日経ITpro
    • http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20050113/154654/
    • (引用)この数年,IT関連の専門書籍の分野ではソフトウエア・テストの本が急に増えてきた。これは出版社に勤務する一編集者の個人的印象ではないようで,欧米の著名なテスト業界人も同じことを述べている。
  • テストの計画をまとめる
    • 加藤 大受(サイボウズ)
    • 2005/1/12
    • Webアプリケーション開発における理論的・計画的なテストの実現 / ITmedia
    • http://www.itmedia.co.jp/enterprise/articles/0501/12/news030.html
    • (引用)前回はテストをどう考えるかについて説明した。今回は、テストプロジェクトの目次となるテスト計画書とテストの種類について紹介していこう。テスト計画を作り、この計画をレビューしていくことがテストプロジェクトのスタートとなる。
  • テスト計画が失敗する原因、その回避策
    • 大西 建児(豆蔵)
    • 2005/1/12
    • ソフトウェアテスト・エンジニアの本音 / @IT
    • http://www.atmarkit.co.jp/farc/rensai/test03/test03a.html
    • (引用)これまで技術的なアプローチからテストの話題を議論してきましたけど、そろそろ管理系の話をしたいなぁと考えていたんですよ。管理系といっても幅が広いので、まずはおのおの、テストを実施するに当たってどんな計画を立てているか、それとも立てていないのか、そんなところから話を始めませんか。
  • 不具合追跡でよくある間違い
    • 津田 義史(豆蔵)
    • 2004/12/23
    • 開発プロセス再入門 / @IT
    • http://www.atmarkit.co.jp/farc/rensai/build09/build09a.html
    • (引用)第8回「ソフトウェアの不具合を追跡するには」では、不具合報告書のライフサイクルと状態、処理方法について説明しました。今回は、不具合報告書に記述すべき項目を紹介します。また、トリアージという考え方についても紹介します。
  • テストをどう考えていますか?
    • 加藤 大受(サイボウズ)
    • 2004/12/28
    • Webアプリケーション開発における理論的・計画的なテストの実現 / ITmedia
    • http://www.itmedia.co.jp/enterprise/articles/0412/28/news032.html
    • (引用)近年のWebアプリケーション開発におけるテストは、クライアント・サーバシステムと比べ、数倍の難しさを持っているといえる。同特集では、Webアプリケーションをいかに効率よく、かつ計画的にテストしていくかを解説していく。第1回となる今回は、テストをどう考えるのかというテーマで話を進めていこう。
  • テスト設計の基本とさまざまなテスト技法
    • 大西 建児(豆蔵)
    • 2004/12/3
    • ソフトウェアテスト・エンジニアの本音 / @IT
    • http://www.atmarkit.co.jp/farc/rensai/test02/test02a.html
    • (引用)テスト技法というわけじゃないけど、テストって昔からいわゆるKKD(経験・勘・度胸)だけでやってきたという現場が多いんじゃないですか。KKDでやっている限り、MMK(もうかってもうかって困る)という次元にはまず達しないから基本的なテスト技法くらいは押さえておかないとね。
  • ソフトウェアの不具合を追跡するには
    • 津田 義史(豆蔵)
    • 2004/12/1
    • 開発プロセス再入門 / @IT
    • http://www.atmarkit.co.jp/farc/rensai/build08/build08a.html
    • (引用)不具合の追跡プロセスはソフトウェア開発の下流工程では非常に重要なもので、それはそのままソフトウェア開発の下流工程を規定するものといっても過言ではありません。不具合は、一般に開発者とQAの間で、不具合報告書(PR:Problem Report)をやり取りしながら管理することになります。今回は、不具合の状態と処理方法に注目し、不具合を追跡するプロセスについて説明します。
  • ITガナバンスの観点を取り入れた「新・システム監査基準」
    • 小野 修一(ビジネス情報コンサルティング)
    • 2004/7/15
    • 「新・システム監査基準」解説 / @IT
    • http://www.atmarkit.co.jp/fbiz/cbuild/complete/audit/01.html
    • (引用)1985年版、1996年版に続く「システム監査基準」が公表された。「システム監査基準」と「システム管理基準」の峻別などを含む今回の改定のポイントを見ていこう。
  • モデル駆動型ソフトウェアテストの可能性
    • 大西 建児(豆蔵)
    • 2004/11/5
    • ソフトウェアテスト・エンジニアの本音 / @IT
    • http://www.atmarkit.co.jp/farc/rensai/test01/test01.html
    • (引用)ソフトウェアテストを地道にVモデルで実施して、品質を確保するっていうスタンダードなアプローチ自体は否定しないけど、もうそろそろ、システムを作りながら同時に検証もしていくっていう(ソフトウェア開発の)世界になっていくべきだって最近考えているんだけど、みんな、どう思う?もちろん、技術的には発展途上だし、難しい面がたくさんあるから、夢物語っていわれるかもしれないけどね。
  • 法廷に出た、動かないコンピュータ
    • 広岡 延隆, 中村 建助(日経コンピュータ)
    • 2004/10/25
    • 記者の眼 / 日経ITpro
    • http://itpro.nikkeibp.co.jp/prembk/NC/ITARTICLE/20041013/151184/
    • (引用)システムの開発が進まない、完成したはずのシステムがきちんと動かず、業務に重大な支障をきたす。いわゆる「動かないコンピュータ」を経験した企業は少なくないだろう。その、動かないコンピュータに最近、一つの変化が見られる。当事者間で問題を解決できず、裁判で決着をつけるケースが増えているのだ。動かないコンピュータはなぜ生まれ、どうして裁判にいたることになったのか。実例を徹底取材し、トラブルの実態とその対策を探った。
  • テスト計画の立案
    • 津田 義史(豆蔵)
    • 2004/10/27
    • 開発プロセス再入門 / @IT
    • http://www.atmarkit.co.jp/farc/rensai/build07/build07a.html
    • (引用)今回は、どのビルドでどのようなテストをすべきかを計画する方法について説明します。ソフトウェア開発プロジェクトでは、いろいろな計画を立てなければいけませんが、テスト計画はその中でも大事なものです。テスト範囲とテスト戦略、QA要員やテストに必要なソフトウェア/ハードウェアなどのリソース調達、そしてスケジュールなどについて、テスト計画書を記述します。また、具体的なテストケースの記述と、この実施についても計画しなければなりません(一般に、テスト計画書の中にはテストケースは含まれません)。(略)今回は反復型開発において注意すべき事柄に的を絞って説明したいと思います。
  • プログラムの品質を高めるためのアサーションとは?
    • BULL(WINGSプロジェクト)
    • 撚充宏(スカイライトコンサルティング)
    • 2004/10/27
    • Java TIPS / @IT
    • http://www.atmarkit.co.jp/fjava/javatips/095java011.html
    • (引用)プログラムの品質向上手法として、契約による設計(Design by Contract、以下DBC)という手法があります。DBCでは、あるオブジェクトに対するメソッド呼び出しを行っているとき、プログラムが正しく動作している際に満たされるべき条件として、以下の3条件を規定しておきます。
  • 後で後悔しないための品質マネジメント
    • 撚充宏(スカイライトコンサルティング)
    • 2004/10/13
    • プロジェクトマネジメントスキル 実践養成講座 / @IT
    • http://jibun.atmarkit.co.jp/lskill01/rensai/pm05/pm01.html
    • (引用)今回は、プロジェクトにおける品質マネジメントについて解説する。 品質マネジメントと聞くと具体的に何を想像するだろうか。現場を知っている読者の意見としては、数多くの文書作成に始まり、承認や変更履歴の管理など面倒なことが増えるだけ、というものが多いだろう。また、これまで解説してきたスケジュールやコストマネジメントと比較するとイメージしづらいかもしれないし、実際のプロジェクトにおいてもスケジュールやコストほど意識して品質マネジメントを実施しているプロジェクトは少ないのではないだろうか。これは「品質というものが時間やお金と異なり目に見えにくいこと」に加えて、「品質マネジメントということを意識して行わずともプロジェクトは取りあえず先に進める」ことに起因している。
  • システム・トラブルの「もぐらたたき」に終止符を
    • 大和田 尚孝(日経コンピュータ)
    • 2004/9/21
    • 記者の眼 / 日経ITpro
    • http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20040919/150108/
    • (引用)すぐに直せるような不具合なら,その気になれば早く見つけることができるはずである。なのに実際には,システムの稼働前後まで見つからないケースが多く見受けられる。そのせいでトラブルを引き起こしてしまい,自社あるいは顧客に損害を与えたとしたら,これほどもったいない話はない。なぜ稼働ギリギリまで単純なミスに気付かないのか。その原因を,今こそ再度チェックしてみる必要があるのではないだろうか。
  • テスト作業を定量的に評価する―製品の評価とテスターの評価
    • 根岸 睦(マイクロソフト)
    • 2004/9/9
    • Visual Studioの開発現場から(4) / 日経ITpro
    • http://itpro.nikkeibp.co.jp/free/NT/WinColumn/20040909/1/
    • (引用)今回のテーマは,テスト作業の定量的な評価です。これまで2回にわたってテスト・チームの概要や作業内容などについて説明してきました。今回は,開発中の製品の品質を評価する方法と,さらに評価に携わるテスターを評価する方法についてもお話します。
  • ビルドの位置付けとリリースの順序
    • 津田 義史(豆蔵)
    • 2004/9/8
    • 開発プロセス再入門 / @IT
    • http://www.atmarkit.co.jp/farc/rensai/build06/build06a.html
    • (引用)反復を計画するということはビルドのリリース計画を立てることです。ビルドはなるべく早い段階から定期的にリリースすることが重要です(略)開発の段階が進むと、(略)ビルドの位置付けが変化していくわけです。各ビルドでは着目すべき側面(aspect)が異なりますし、求められる品質も違います。(略)今回は、どのような位置付けのビルドをリリースしていくべきかを順に紹介します。
  • 極限におけるプロファイル
    • Jack Shirazi, Kirk Pepperdine(JavaPerformanceTuning.com)
    • 2004/9/2
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/java/library/j-perf09024/
    • (引用)チューニングの対象はスピードだけとは限りません。時には別の面でチューニングが必要になることもあります。アプリケーションにチューニングが必要な時に、最初にすべきことはプロファイラーでアプリケーションをモニターすることです。ところが場合によると皮肉な理由から、必ずしもプロファイラーが現実的な解とはならないことがあるのです。パフォーマンスの目 、今回の記事では、最近JackとKirkが、ファット・クライアント(fat client)にプロファイラーを使った経験に関連してお話しします。この時にはクライアントがあまりに大きすぎ、プロファイラーが入る余地すら無かったのです。
  • テスト終了前に検収を要求してくるベンダーには、どう対応したらいい?
    • Q&A
    • 2004/8/24
    • SMB+IT / 日経BP
    • http://www.nikkeibp.co.jp/archives/327/327021.html
    • (引用)検収に応じるならば、まずは現在の問題点とその解決策、対応時期、支払い条件などを明確にし、ベンダーとコンセンサスを図っておくべきでしょう。
  • ソフトウェアテスターのための4つのレッスン
    • Len DiMaggio(IBM)
    • 2004/7/31
    • The Rational Edge / @IT
    • http://www.atmarkit.co.jp/farc/rensai/redge26/redge26a.html
    • (引用)本稿はソフトウェアテスターを念頭に書かれてはいるものの、ソフトウェア開発チームの全員に関連のある内容で、技術の流れに遅れず、統合に関する問題を理解し、チーム内のメンバーに十分な情報を提供するための手堅いアドバイスを提供する。
  • 変更の危険性を判断する
    • Jack Shirazi, Kirk Pepperdine(JavaPerformanceTuning.com)
    • 2004/7/30
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/java/library/j-perf07304/
    • (引用)既知のボトルネックを除去するための妥当な時間枠として、どの程度を上の人に要求すべきでしょう。(略)その前提として、皆さんがパフォーマンス改善に必要な変更の全てを理解していることが必要です。非常に多くの場合、コードベース中で予期しない問題に突き当たるにつれ、必要な、または考慮すべき変更のリストは次第に大きくなりがちなものです。(略)幸いなことに、ここにソフトウェア・メトリックスという形の助けがあります。
  • J2EEのベストプラクティス・トップ10(+2)(前編)
    • Kyle Brown / Keys Botzum / Ruth Wilenborg(IBM)
    • 2004/7/23
    • Java Solution / @IT
    • http://www.atmarkit.co.jp/fjava/rensai3/devworks03/devworks03.html
    • (引用)筆者らは、この迷路でさまよえる読者に向けた簡単なガイドとして、J2EEにおける最も重要なベストプラクティスのトップ10リストを作成した。(略)「2. すべてのレイヤにテストツールを用意し、ユニットテストを自動化すること」(略)GUIのテストだけで済ませてはならない。すべてのレイヤでテストを実施することで、デバッグやメンテナンスが大幅に簡素化される。
  • 効率的なテスト環境構築のための工夫
    • 橋本 芳昭(マイクロソフト)
    • 2004/7/22
    • Visual Studioの開発現場から(3) / 日経ITpro
    • http://itpro.nikkeibp.co.jp/free/NT/WinColumn/20040722/1/
    • (引用)われわれVisual Studioのテスト・チームが行っているテスト作業には,製品テスト以外にも,テスト環境の構築,テストの自動化,バグ・レポートの作成など,様々なものがあり,それぞれに効率化すべきことがあります。今回は,その中のテスト環境の構築を取り上げましょう。
  • 資格から考える「システム監査人材」の育成と活用
    • 小野 修一(ビジネス情報コンサルティング)
    • 2004/7/15
    • 特別企画:システム監査人材 / @IT
    • http://www.atmarkit.co.jp/fbiz/cstaff/complete/audit/01.html
    • (引用)システム監査に関連する資格は複数ある。システム監査を実施する人員確保という面から、それぞれの資格の特徴を考察してみよう。
  • Linuxカーネルのストレス・テスト
    • Robert Williamson(IBM)
    • 2004/6/30
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/linux/library/l-stress/
    • (引用)ソフトウェアのテストを自動化することにより、同一のテストを一定期間に渡って行うことができるようになります。また自動化によって同じ種類のテスト結果を比較することで、確実に正確な評価ができるようになります。この記事では、Linux Test Projectチームのメンバーがその方法論と考え方を紹介し、また彼らがLinux?カーネルのストレステストに使用しているスクリプトやツールについて説明を行います。
  • 「動かないコンピュータ」からは脱出できない,陥らないことが重要
    • 中村 建助(日経コンピュータ)
    • 2004/7/5
    • 記者の眼 / 日経ITPro
    • http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20040704/146776/
    • (引用)今回の記者の眼は,6月10日に公開した「『動かないコンピュータ』の解決に裁判は役立つか」について,皆さんからのご意見を紹介しながら,「動かないコンピュータ」にまつわる問題について考えていきたいと思います。前回の記事で指摘したことは2点。1点目は,自分のかかわっているプロジェクトが「動かないコンピュータ」になってしまったらどうするべきなのか,そして動かないコンピュータの最終解決手段として「裁判」が有効なのか,というものです。
  • Validatorによる妥当性検証の実現(後編)
    • 山田 祥寛
    • 2004/6/26
    • Strutsを使うWebアプリケーション構築術(6) / @IT
    • http://www.atmarkit.co.jp/fjava/rensai3/struts06/struts06_1.html
    • (引用)前回「Validatorによる妥当性検証の実現(前編)」では、Validatorプラグインを利用する際に必要となる環境設定や準備について紹介しました。後編となる今回は、前回の設定を基に書籍登録・更新アプリケーションに検証機能を組み込みます。
  • QA――品質を検証し,製品出荷のカギを握るテスト・チーム
    • 橋本 芳昭(マイクロソフト)
    • 2004/6/10
    • Visual Studioの開発現場から(2) / 日経ITpro
    • http://itpro.nikkeibp.co.jp/free/NT/WinColumn/20040610/1/
    • (引用)マイクロソフトの製品開発部門には「QAチーム」と呼ぶ組織があります。QAはQuality Assuranceの略。製品開発に伴うテストを専門に行っているテスト・チームのことです。テスト・チームは当然,製品の品質に関して最も詳しくかつ厳しく,その製品が出荷できる品質に達しているかを判断する責任を負っています。つまり,テスト・チームが最終的に承認しなければ,その製品の出荷はできないのです。では,このような責任を全うするために,具体的にどのように作業しているのでしょうか。本連載の第2回となる今回からは,3回にわたってテスト・チームについて説明していきます。まず今回は,テスト・チームが行っている作業内容について,実際のVisual Studioの例にも触れながら,その概略を紹介します。
  • テストでワクワク。陽気で前向きなテスト屋
    • 渡辺 登(沖通信システム)
    • 2004/6/10
    • SESSAMEメンバが語る「組込みソフト開発の明日」(4) / EIS
    • http://www.caravan.net/eis/sessame/index04.html
    • (引用)今回の「SESSAMEの愉快な仲間たち」は、大西 建児さんです。大西さんは、テストのスペシャリストとして活躍されている方です。テスト技術者交流会やソフトウェアテストシンポジウムなどでも有名です。SESSAMEではテストを中心に大活躍されています。今回はテストという重要な作業にフォーカスを当て、組込みエンジニアの姿勢や将来像など導き出したいと思います。
  • 企業価値を高める“これからのシステム監査”
    • 小野 修一(ビジネス情報コンサルティング)
    • 2004/6/3
    • システム監査入門(5) / @IT
    • http://www.atmarkit.co.jp/fbiz/cbuild/serial/audit/05/01.html
    • (引用) 企業において情報システムの重要性が増すにつれ、システム監査の大切さも増している。今回は重みを増すシステム監査のこれからを見ていこう。
  • なぜ「テスト」は軽視されるのか?
    • 池上 俊也(日経ITプロフェッショナル)
    • 2004/6/1
    • 記者の眼 / 日経ITPro
    • http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20040531/145101/
    • (引用)皆さんは,単体テストや結合テスト,システム・テストといったシステム開発における「テスト」に対して,どんな印象をお持ちだろうか。記者は日経ITプロフェッショナル2004年6月号で,テストに関する特集「テスト技術のA to Z」を担当。そこで強く感したのが,IT業界に蔓延する“テスト軽視”の風潮だ。
  • Validatorによる妥当性検証の実現(前編)
    • 山田 祥寛
    • 2004/5/28
    • Strutsを使うWebアプリケーション構築術(5) / @IT
    • http://www.atmarkit.co.jp/fjava/rensai3/struts05/struts05_1.html
    • (引用)前回は「書籍登録・更新アプリケーション」を例に、アクションフォームBeansの主要な用法とDynaActionFormによるデータ受け渡しの簡略化について説明しました。今回は、Struts 1.1からの新機能である入力データ検証機能(Validatorプラグイン)について紹介します。
  • コード品質を改善する
    • Chris Grindstaff(IBM)
    • 2004/5/25
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/java/library/j-findbug1/
    • (引用)静的な分析ツールは開発者の側に大きな努力を要求することなく、コード中にあるバグを見つけてくれます。当然ながら長年プログラミングをしている人ならば、こうしたうたい文句が必ずしも正しいものではないことを知っているでしょう。とは言え静的分析ツールは、良質なものであればツールボックスの中に入れておくだけの価値があるものです。2部構成のこのシリーズでは、上級ソフトウェア・エンジニアのChris Grindstaffが、FindBugsがコードの品質改善や、隠れているバグを取り去るのにどれほど役に立つかを説明します。
  • 反復開発の“反復”とは何をどのように反復するのか
    • 津田 義史(豆蔵)
    • 2004/5/13
    • 開発プロセス再入門(4) / @IT
    • http://www.atmarkit.co.jp/farc/rensai/build02/build02.html
    • (引用)さて、さっそく今回から反復型開発について具体的な話を始めましょう。(略)つまり、QAによるこのビルドのテストと、開発者による次のビルドの開発は並行して行われます。
  • Linuxに足りないのはテスト方法論
    • 2004/5/6
    • エンタープライズ / japan.linux.com
    • http://japan.linux.com/enterprise/04/05/06/0941215.shtml
    • (引用)Linuxカーネルについては、主にLinux Test Projectなどの努力のおかげで、非常に高度な安定性テストと信頼性テストが行われているが、Linux上のアプリケーションのパフォーマンスを測定するのはもっと困難である。Open Source Development Labs(OSDL)は各アプリケーションベンダに対して、自社製品の信頼性、セキュリティ、クラスタリングに関するテストを実施するよう求めている。さらにOSDLは、オープンソース精神にのっとり、それぞれのテストとテスト結果を共有することを各ベンダに要求している。
  • Slashdotに聞け!: 職場でのバグ管理はどうやってる?
    • 2004/5/3
    • Slashdotに聞け! / Slashdot Japan
    • http://slashdot.jp/askslashdot/04/05/03/022219.shtml?topic=16
    • (引用)(略)さて、今回、考えたいのは、バグ管理について。前者 (オンラインでの開発) では、多くの場合、たとえば SourceForge や Bugzilla などのサイト/ツール (バグ管理システム:BTS) を使って行っているでしょう。ところが後者 (企業(小規模)プロジェクトの開発) では、文書や管理簿を使っているところも多いのではと思うのです。みなさんの場合、どのようにバグ管理をしていますか。あるいは、うまいこと BTS を導入する方法があったら教えてください。
  • 情報システムの“有効性”と “投資対効果”を監査する
    • 小野 修一(ビジネス情報コンサルティング)
    • 2004/4/29
    • システム監査入門(4) / @IT
    • http://www.atmarkit.co.jp/fbiz/cbuild/serial/audit/04/01.html
    • (引用) システム監査の目的に1つに“システムの有効性向上”がある。情報システムの投資対効果を考えるうえでは有効性(=目的、目標に対して妥当な投資、方法で効果を実現しているか)に着目して評価する必要がある。これは「投資効果性」「採算性」と呼ばれ、今日情報システムの有効性を示す重要な視点の1つとなっている。
  • SLA、サービスレベル管理でベストプラクティスに導く
    • 村松 武(日本アイ・ビー・エム・システムズ・エンジニアリング)
    • 2004/4/8
    • 特集:SLAとサービスレベル管理 / @IT
    • http://www.atmarkit.co.jp/fnetwork/tokusyuu/24sla/01.html
    • (引用)ここでは、ITILに記述された運用プロセスのベストプラクティスを参考にしながら、具体的な事例も交えてSLA、サービスレベル管理について説明していきます。(にし注:SLAを導入するのであれば、テストからSLAを意識する必要がありますので、読んでおくとよいでしょう。)
  • 知識とソフトウェアのギャップ、それをどう埋めるのか?
    • 山田 正樹(メタボリックス)
    • 2004/4/6
    • 実行可能な知識とソフトウェア(2) / @IT
    • http://www.atmarkit.co.jp/farc/rensai/knowledge02/knowledge02.html
    • (引用)知識にはいろいろな性質がある。モジュール性、伝達可能性、柔軟性、抽象性、具体化可能性などなど。単に知識が「あればいい」というわけではない。「知識の質」、特に「知識のダイナミクス」を支える質が重要なのだ。今回はその1つ、知識の検証可能性ということを考えてみることにしよう。知識の「正しさ」を知る方法には実は2種類ある(「正しさ」に2種類あるといってもいい)。1つは検証(verification)と呼ばれるもの、もう1つは妥当性確認(validation)と呼ばれるものだ。
  • Slashdotに聞け!: テストってどれだけやってますか?
    • 2004/3/29
    • Slashdotに聞け! / Slashdot Japan
    • http://slashdot.jp/askslashdot/04/03/29/0444242.shtml?topic=104
    • (引用)スラッシュドットの皆さんはソフトウェアのテストの重要性はひしひし感じていらっしゃると思いますが, やはり軽視している上司やお客様が多いのも事実. 記事中,テストの工数は全体の工数の少なくとも3割, 多いと9割占めると書かれていました. 皆さんのプロジェクトではどの程度占めるのでしょうか.
  • トラブルの根本原因を絶つ:レビューを見直せ
    • 大和田 尚孝(日経コンピュータ)
    • 2004/3/29
    • ITレポート / 日経BP
    • http://itpro.nikkeibp.co.jp/members/NC/ITARTICLE/20040318/1/
    • (引用)不注意や単純ミスに端を発するシステム障害が後を絶たない。その背景にあるのは、仕様の誤解や機能の漏れを防ぐ「レビュー」が形骸化しているという問題だ。システム・トラブルが経営に与えるダメージは極めて大きい。今こそ、レビューの機能不全がトラブルの根本原因であることを認識し、効果的なレビューのやり方を見いだすべきだ。
  • “安心して使えるシステム”を客観的に評価する
    • 小野 修一(ビジネス情報コンサルティング)
    • 2004/3/27
    • システム監査入門(3) / @IT
    • http://www.atmarkit.co.jp/fbiz/cbuild/serial/audit/03/01.html
    • (引用)業務活動の中での情報システムの重要度は高まる一方だ。“安心して使えるシステム”実現のためのさまざまな対策は講じられているはずだが、それを客観的に評価するのもシステム監査の大きな役割である。システム監査の目的である「情報システムの信頼性、安全性、効率性の向上」のうち、信頼性、安全性について整理してみよう。
  • Webサーバ周辺、これだけおさえれば、落ちても大丈夫?
    • 鳴滝 光二
    • 2004/3/20
    • システム管理の鉄則 / @IT
    • http://www.atmarkit.co.jp/fnetwork/tokusyuu/22tool/01.html
    • (引用)この連載では、システム障害時の迅速・的確な対応を第一義とした、システムの具体的な監視のための手法について解説していきます。
  • エラーパターンの闇にひそむもの(下)
    • 塩田 紳二
    • 2004/3/18
    • 障害事例:ネットワークの理(6) / @IT
    • http://www.atmarkit.co.jp/fnetwork/rensai/kotowari06/01.html
    • (引用) 得意先の飲食店で売り上げデータを通信するストコンに異常発生。TAや配線、ストコンをチェックしてみると問題がない……
  • 「品質」をつねに念頭に置きながらソフトウェアを開発する
    • 杉浦 英樹(富士ゼロックス)
    • 2004/3/16
    • 技術解説 / 組み込みネット
    • http://www.kumikomi.net/article/explanation/2004/07softte/01.html
    • (引用) ここでは組み込みソフトウェアの品質確保の問題について解説する.組み込みソフトウェアは,エンド・ユーザからの要求だけでなく,システム設計やハードウェア設計の要求も反映させなければならない.そのため,組み込みソフトウェアの開発は複雑になり,そのスケジュールはしばしば遅れがちである.ソフトウェア開発者は,テスト担当者と協力しながら,ソフトウェアの品質をつねに意識して作業を進める必要がある.
  • 特集:ソフトウェアのテスト技術の現状と今後
    • 西 康晴(電気通信大学)
    • 2004/3/12
    • IT Architect / @IT
    • http://www.atmarkit.co.jp/farc/rensai/bto01/bto01.html
    • (引用)ソフトウェア開発におけるテストの重要性が年々高まってきている。しかし、開発現場の状況はいまだ多くの混乱に満ちているといってもいい。極端にいえば、開発工数の9割にも達するといわれるテスト工程が直面する危機的な状況について電気通信大学の西康晴氏に聞いた。
  • 開発のトラブルは必然
    • 山野 寛(クロノス)
    • 2004/3/3
    • 開発現場で学べること(第5回)/ @IT
    • http://jibun.atmarkit.co.jp/lskill01/rensai/devgenba05/devgenba01.html
    • (引用)例に漏れず、今回の開発においても筆者の頭を悩ませたトラブルがあった。それは「単体テストの工数オーバー」である。われわれは開発に入る前の準備段階から多くの議論を行ったうえでテスト方針を決定したにもかかわらず、第1反復終了時点では当初予定していたテスト工数の2〜3倍もかかってしまっていたのである。では、なぜそのような事態になってしまったのかを順を追って説明しよう。
  • 報告だけでは終わらないシステム監査の進め方と効果
    • 小野 修一(ビジネス情報コンサルティング)
    • 2004/2/28
    • システム監査入門(2) / @IT
    • http://www.atmarkit.co.jp/fbiz/cbuild/serial/audit/02/01.html
    • (引用)「監査」というと大変そうだと思われがちだ。また会計監査のような“義務”として監査をイメージしていると、その真の効果に気付きにくいかもしれない。今回はシステム監査の進め方とその効果について解説する。
  • テストの本質を探る――30年の歴史を持つ 「ソフトウェア工学」の知恵に学ぶ
    • 伊藤 昌夫(ニルソフトウェア)
    • 2004/2/24
    • 技術解説 / 組み込みネット
    • http://www.kumikomi.net/article/explanation/2004/07softte/01.html
    • (引用)ここではテスト(対象物が正しく動作することを確認する作業)の意味や,これまでソフトウェア工学の世界で議論されてきたテストに関する数々の話題を紹介する.主にソフトウェアの例をもとに解説しているが,多くの議論はHDL設計や回路設計,システム設計におけるテスト(検証)と共通している.テストの問題については,ソフトウェア工学から学ぶべきことが多い.
  • サーバアプリケーションのモニタリングとは
    • 岩村 郁雄(日本アイ・ビー・エム システムズ・エンジニアリング)
    • 2004/2/24
    • エンタープライズ・モニタリングのつぼ(後編)/ @IT
    • http://www.atmarkit.co.jp/fnetwork/tokusyuu/monitoring01/04.html
    • (引用)後編ではさらに、サーバの「ソフトウェアリソース」として、サーバ上で稼働するアプリケーションの監視技術について解説します。サーバ上のプロセス監視に始まり、あたかもクライアントがサーバを使用しているかのようなシミュレートを行い監視する技法まで、多種多様な監視技術について実例を挙げてご紹介します。最後に、ご紹介したモニタリング技術を監視製品が実装するときの付加機能、すなわち、システム監視として運用する観点で、利便性を上げる機能やシステム品質を向上させるための機能について特徴を解説します。
  • エラーパターンの闇にひそむもの(上)
    • 塩田 紳二
    • 2004/2/20
    • 障害事例:ネットワークの理(5) / @IT
    • http://www.atmarkit.co.jp/fnetwork/rensai/kotowari05/01.html
    • (引用)ウチは、その各店舗に入るシステムを請け負った。POS端末を接続して売り上げなどを集計し、センターに転送するシステムである。(略)テストでは問題はなく、センター側の接続テストもクリア。つまり、いまはどこもおかしくないのである。しかし、エラーが発生したのも事実。いったいどうすればいいのか? 何だか目が回ってきた……。
  • オフショア開発でハッピーになれましたか?
    • 今村 智(ボーランド)
    • 2004/2/11
    • 要求仕様のボトルネックを探す(第1回) / IT Architect / @IT
    • http://www.atmarkit.co.jp/farc/rensai/bottleneck01/bottleneck01.html
    • (引用)開発プロセスブームも一段落した感がある中、最近は、原点回帰ともいえる“ソフトウェア要求”に関する話題が目に付くようになりました。この短期連載では、ソフトウェア開発、特に企業情報システムのSIの現場でよく見聞きする取り組みと、そのほとんどが失敗している原因に“ソフトウェア要求”の存在があること、そういった取り組みを成功させるためには、どのように考え、何を行っていくべきかをお伝えしたいと思います。(にし注:結構テストの話が出てきます。特に上流からテスト設計を行うというのは重要です。)
  • その“ソリューション”は本物か?
    • 秋池 治(リアルナレッジ)
    • 2004/2/11
    • 問題発見能力を高める(第1回) / @IT
    • http://www.atmarkit.co.jp/fbiz/cinvest/serial/expert/01.html
    • (引用)さて「ソリューション」という用語だが、これはもともと「問題を解決すること、問題を解決する解答や方法」を意味する。しかし実際、ソリューションの提供者と受け手との間には大きなギャップが生まれる。これはなぜだろうか。この原因を探るには、例えば医者と患者の関係を考えてみると分かりやすい。(にし注:テストと関係ないように感じますが、この中で出てくる「信頼できない医者」のようなテスト技術者にならないように注意しましょう。)
  • 現在のWebサイト監視に欠けているポイントとは
    • アットマーク・アイティ編集局
    • 2004/2/10
    • FYI / @IT
    • http://www.atmarkit.co.jp/ad/empirix/onesight/onesight01.html
    • (引用)前回(Web負荷テストの押さえるべきポイントとは)では、Webサイトを構築する上で、公開前の“負荷テスト”について触れた。次に問題となるのは、公開後──すなわちWebサイトの運用フェイズだ。ここでも、サイトが顧客が期待するパフォーマンスが出ているか、サービスがきちんと提供できているかをモニタリングしつづける必要がある。今回は、顧客視点でのWebサイト監視について見ていこう。
  • サーバやリソースをモニタリングするには
    • 岩村 郁雄( 日本アイ・ビー・エム システムズ・エンジニアリング)
    • 2004/2/4
    • エンタープライズ・モニタリングのつぼ(中編)/ @IT
    • http://www.atmarkit.co.jp/fnetwork/tokusyuu/monitoring01/02.html
    • (引用)(前編)では、ITインフラストラクチャーの屋台骨であるネットワークのモニタリングについて解説しました。中編では、「リソースやサーバ・ハードウェアリソースのモニタリング」を解説します。
  • オンラインショッピングにおける脆弱性の注意点
    • 中村 隆之(三井物産GTI)
    • 2004/2/7
    • Webアプリケーションに潜むセキュリティホール(第9回) / @IT
    • http://www.atmarkit.co.jp/fsecurity/rensai/webhole09/webhole01.html
    • (引用)今回はオンラインショッピングの機能について調べてみよう。前回までの解説で検査対象としてきたデモサイトにもショッピング画面があるのだが、セッション管理方法が同じだと、これまでと似たような説明になってしまうため、今回はデモサイトは使わずに説明していくことにする。
  • テスト・シナリオを自動生成できるテスト・ツール「.TEST」(ドットテスト)
    • 川俣 晶(ピーデー)
    • 2004/2/4
    • .NET Tools / Insider .NET/ @IT
    • http://www.atmarkit.co.jp/fdotnet/tools/dottest/dottest_01.html
    • (引用)要求されたドキュメントがテスト結果の報告書であり、具体的な書式に特に注文が付いていないのなら、「.TEST」(ドットテスト)というツールを使えば、数えるほどの回数のクリックを行うだけで、テスト結果に関するドキュメントを生成することができる。プログラミングの知識もほとんど要らない。手順も簡単である。
  • システム構築のプロジェクト管理はベンダーに丸投げしてしてよいか?
    • 企業のIT戦略Q&A
    • 2004/1/30
    • SmallBiz / 日経BP
    • http://www.nikkeibp.co.jp/archives/288/288401.html
    • (引用)発注側は「施主」であると同時に「プロデューサー」だと思ってください。結果責任を負うのはあなたです。(にし注:テストとは直接関係ない記事なんですが、ユーザ側がシステムの品質を確認しなくてはいけないのが現状だったりするので、紹介してみました。)
  • ガベージコレクションとパフォーマンス
    • Brian Goetz(Quiotix Corp)
    • 2004/1/27
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/java/library/j-jtp01274/
    • (引用)コレクタの選び方によるパフォーマンスへの影響、コーディング形式の違いによるガベージコレクションへの影響、さらにメモリ確保やそれに関連する動作がJava仮想マシンに与える負担がここ数年でどのように変化したかについて論じていただきます。(にし注:パフォーマンスが重要なアプリのテストやタイミングにまつわるバグを見つけるテストでは、ガベージコレクションをどう発生させるかが難しい点となります。この記事は直接関係ありませんが、読んでみてもよいでしょう。)
  • 最適なシステム環境を維持する方策とは?
    • 小野 修一(ビジネス情報コンサルティング)
    • 2004/1/22
    • システム監査入門(1) / @IT
    • http://www.atmarkit.co.jp/fbiz/cbuild/serial/audit/01/01.html
    • (引用)「システム監査」について、その本質や具体的な内容を知っている情報マネージャは少ない。本連載ではシステム監査の目的やポイント、重要性を説明していく。第1回は「システム監査」の概要について。
  • 信号強度100%の見えない線(下)
    • 塩田 紳二
    • 2003/1/17
    • 障害事例:ネットワークの理(4) / @IT
    • http://www.atmarkit.co.jp/fnetwork/rensai/kotowari04/01.html
    • (引用)150m離れた2つのビルを2Mbpsの無線LAN(小電力データ通信システム)で接続している。アンテナにも有線側にも特に異常は見られない……。
  • ネットワーク健全化の実作業はこれだけある
    • 秋山 浩一(NRIラーニングネットワーク)
    • 2004/1/15
    • ネットワーク運用管理入門(3) / @IT
    • http://www.atmarkit.co.jp/fnetwork/rensai/netadmin03/netadmin03.html
    • (引用)本連載は「ネットワーク運用管理の基礎」について紹介していきます。読者の皆さんは、「ネットワーク運用管理」と聞くと、多分「あ、あんなことかな?」と、その実作業については何となく理解していることかと思います。この連載では、その「何となく」をもう少し体系立て、まとめることを目的とします。 第3回は、ネットワーク運用管理で行うべき日々の業務内容を紹介していきます。
  • セキュアなプログラマー: 入力に目を光らす
    • David A. Wheeler(Institute for Defense Analyses)
    • 2003/12/19
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/linux/library/l-sp3/
    • (引用)この記事では、データがプログラムに到達するまでの各種経路について、どうすればそうした経路を適切に扱えるかに重点を置きながら説明します。皆さんは経路の全てを分かっていないかも知れないのです!この記事ではデータが入り込む経路を制限するにはプログラムをどう設計すれば良いか、またそうした設計によって何を入力とするのかが変わってくることを説明し、次に入力経路にはどんなものがあり、それらをどう扱うべきかを説明します。(入力チャネルには環境変数、ファイル、ファイル・ディスクリプタ、コマンドライン、GUI(graphical user interface)、ネットワーク・データ、その他入力があります。)
  • 信号強度100%の見えない線(上)
    • 塩田 紳二
    • 2003/12/19
    • 障害事例:ネットワークの理(3) / @IT
    • http://www.atmarkit.co.jp/fnetwork/rensai/kotowari03/01.html
    • (引用)この連載では以下の人物たちがトラブルにつまづき、障害の原因解明、解決に挑んでいます。読者の皆さんも登場人物とともに、問題の原因を考えてみてください。
  • ネットワーク監視対象に適したモニタリングとは
    • 稲山 享伸( 日本アイ・ビー・エム システムズ・エンジニアリング)
    • 2003/12/18
    • エンタープライズ・モニタリングのつぼ(前編)/ @IT
    • http://www.atmarkit.co.jp/fnetwork/tokusyuu/monitoring01/01.html
    • (引用)エンタープライズ環境を支えるITインフラストラクチャーは、さまざまなソフトウェア、ハードウェアによって構成されており複雑さを増しています。このため、エンタープライズ環境を漏れなく確実にモニタリングするためには、監視対象の特性に合ったいろいろなモニタリング手法に精通していなくてはなりません。(略)前編では、ITインフラストラクチャーを支えるネットワーク機器をモニタリングする技術について解説します。
  • ロジック系の検査 〜 問い合わせ画面に含まれる脆弱性 〜
    • 中村 隆之(三井物産GTI)
    • 2003/12/12
    • Webアプリケーションに潜むセキュリティホール(第8回) / @IT
    • http://www.atmarkit.co.jp/fsecurity/rensai/webhole08/webhole01.html
    • (引用)今回は、ほとんどのサイトに存在するであろう、問い合わせ画面に含まれるロジック系の脆弱性について説明した。ロジック系の検査では、アプリケーションの動きを把握することが必要である。OSコマンドインジェクションやSQLインジェクションなどのテクニカル系の脆弱性に関しても、やみくもに不正文字列を入力するのではなく、アプリケーションの動きを理解したうえで行うことで、検査の質を向上させることができる。
  • プログラムを仕上げるときの強力な助っ人DevPartner
    • 川俣 晶(ピーデー)
    • 2003/12/6
    • .NET Tools / Insider .NET/ @IT
    • http://www.atmarkit.co.jp/fdotnet/tools/devpartner/devpartner_01.html
    • (引用)プログラマーが自分の書いているプログラムを理解していると思うのは早計で、実際には書いた本人すらも気付かないことがいろいろある。例えば、プログラムが遅いから高速化しようとプログラムを書き換える際、プログラマー本人がボトルネックだと思っていた個所と、本当にボトルネックになっていた個所が違っていた、というような話はよくある。プログラムを正しく理解するために、プログラム内容を分析し、的確な情報を得ること、それが、客観的に優れたプログラムを作成するために必要といえるだろう。
  • マイクロパフォーマンスのベンチマーキング
    • Jack Shirazi, Kirk Pepperdine(JavaPerformanceTuning.com)
    • 2003/12/5
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/java/library/j-perf12053/
    • (引用)Javaパフォーマンス狂、Jack ShiraziとKirk Pepperdine(JavaPerformanceTuning.com のそれぞれディレクターとCTO)は開発者を悩ませるパフォーマンス問題は何なのかと、インターネット中の議論を追跡しています。最近Usenetニュースグループcomp.lang.javaを見ていて、低レベルのパフォーマンス・チューニングに関する面白い質問に出くわしました。今回の記事ではこうした質問のいくつかに答えるべく、バイトコード解析に飛び込んでみます。
  • Windowsのパッチはいかにして作られるか? 〜注目されるサステインド・エンジニアリング〜
    • Michael Cherry
    • 2003/12/3
    • Insider's Eye / Windows Server Insider / @IT
    • http://www.atmarkit.co.jp/fwin2k/insiderseye/20031203wse/wse.html
    • (引用)WSEが、パッチ・プロセス全般にかかわる中心的な役割を果たす(略)WSEは一般に、新機能の仕様策定や設計を行う代わりに、開発プロセス中に先送りされたあらゆるバク・フィックスを再検討し、PSSおよびセキュリティ・レスポンス・チームと連携して新たな問題のトリアージとフィックスを行う(略)テストはすべての言語とバージョンに対して同時に実施される。これはオリジナル・リリースのテストと同様であり、「デプス」「インテグレーション」「セットアップ」の3つの基本カテゴリのテストに分類される。
  • トラフィックの通らなかった道(下)
    • 塩田 紳二
    • 2003/11/26
    • 障害事例:ネットワークの理(2) / @IT
    • http://www.atmarkit.co.jp/fnetwork/rensai/kotowari01/01.html
    • (引用)連載2回目の登場人物です。主人公は“師匠”に会いに行き、問題の解決に努めます。読者の皆さんも登場人物とともに、問題の原因を考えてみてください。
  • テスト終了に不具合、そのときプロジェクト・マネージャは
    • 垣内 郁栄
    • 2003/11/22
    • NewsInsight / @IT
    • http://www.atmarkit.co.jp/news/200311/22/tiffe.html
    • (引用)IT業界の注目を集めていた東京金融先物取引所(TIFFE)の新システムが、今年4月末にカットオーバーした。英国製のパッケージソフトを導入すると同時に、国内ベンダが別のシステムを新規開発するという異例のプロジェクト。しかもシステム・インテグレータを入れずに、TIFFEがすべてのプロジェクトを管理した。プロジェクト・マネージャを務めたTIFFEの業務部 システム課長 高橋邦夫氏が「Gartner Symposium/ITxpo 2003」(主催:ガートナー ジャパン)でプロジェクト成功のポイントを明らかにした。
  • 障害対応マニュアルを作成しよう(4)ロールプレイから対応マニュアルを文章化する
    • 北原 静香
    • 2003/11/20
    • Master of IP Network / @IT
    • http://www.atmarkit.co.jp/fnetwork/rensai/emerg04/01.html
    • (引用)前回の記事では、実際に管理するシステムを想定して、管理基準書作成の留意点について解説しました。そこで、今回はこの管理基準書に記載されている内容を基にして、システムの監視・運用チームが参照する障害対応マニュアルの作成方法を順を追って解説することにします。
  • Webアプリケーションの検査テクニック(3) 〜 攻撃されないためのセッション管理の検査方法 〜
    • 中村 隆之(三井物産GTI)
    • 2003/11/15
    • Webアプリケーションに潜むセキュリティホール(第7回) / @IT
    • http://www.atmarkit.co.jp/fsecurity/rensai/webhole07/webhole01.html
    • (引用)前回はWebアプリケーションのセッションまわりの検査について説明した。今回は、もう1歩踏み込んで、セッション管理の検査方法を手順を追って説明しよう。
  • トラフィックの通らなかった道(上)
    • 塩田 紳二
    • 2003/11/8
    • 障害事例:ネットワークの理(1) / @IT
    • http://www.atmarkit.co.jp/fnetwork/rensai/kotowari01/01.html
    • (引用)この連載では登場人物たちがトラブルにつまづき、障害の原因解明、解決に挑んでいきます。読者の皆さんも登場人物とともに、問題の原因を考えてみてください。
  • 大切なのはトラブル・ゼロよりトラブル後
    • 松山 貴之(日経システム構築)
    • 2003/11/6
    • 記者の眼 / 日経ITPro
    • http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20031104/2/
    • (引用)IT Proでシステム・トラブルに関する記事が掲載された際,「原因分析が甘い。なぜそうなってしまったのかをもっと追求すべき」「ソフト業界はバグという言葉を安易に使い過ぎ」といった読者からのコメントをよくいただく。おそらく,ソフト業界とは異なる業界を経験した方なのだろう。
  • ストレス負荷 - ストレス・テストと、正しいツール選択に関わる要素
    • Jack Shirazi, Kirk Pepperdine(JavaPerformanceTuning.com)
    • 2003/10/28
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/java/library/j-perf10283/
    • (引用)勇敢なる最適化推進者、JavaPerformanceTuning.com のディレクターJack ShiraziとCTOの Kirk Pepperdineはインターネット中で起きているパフォーマンスに関する議論を追跡しており、気が付いた問題をこのコラムで分析、明確化しています。最近TheServerSide.comのメッセージ・ボードを見て、ストレス・テストと負荷テストについて疑問がわいてきました。二人はこの問題を精査し、ツールの選び方でどれほど大きな結果の差が生じるかをお話します。
  • ガーベッジ・コレクションはどのように機能するのか
    • Brian Goetz(Quiotix Corp)
    • 2003/10/28
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/java/library/j-jtp10283/
    • (引用)Java言語はガーベッジ・コレクションを利用しているプログラミング言語の中では最も広く用いられていますが、最初にガーベッジ・コレクションを利用した言語ではありません。ガーベッジ・コレクションは、Lisp、Smalltalk、Eiffel、 Haskell、 ML、 Scheme、Modula-3など多くのプログラミング言語に不可欠なもので、1960年代初めからずっと使用されてきました。 Javaの理論と実践 の今回の記事で、Brian Goetzはガーベッジ・コレクションの最も一般的なテクニックについて解説します。(にし注:パフォーマンスが重要なアプリのテストやタイミングにまつわるバグを見つけるテストでは、ガベージコレクションをどう発生させるかが難しい点となります。この記事は直接関係ありませんが、読んでみてもよいでしょう。)
  • テスト終了前に検収を要求してくるベンダーには、どう対応したらいい?
    • 企業のIT戦略Q&A
    • 2003/10/24
    • SmallBiz / 日経BP
    • http://www.nikkeibp.co.jp/archives/327/327021.html
    • (引用)検収に応じるならば、まずは現在の問題点とその解決策、対応時期、支払い条件などを明確にし、ベンダーとコンセンサスを図っておくべきでしょう。
  • セキュアなプログラマー: 入力を検証する
    • David A. Wheeler(Institute for Defense Analyses)
    • 2003/10/23
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/linux/library/l-sp2/
    • (引用)この記事では、セキュアなプログラムにおいての第一防御線の一つ、入力検証をどうすべきかについて説明します。(にし注:いわゆる“サニタイジングテスト”と呼ばれるものです。)
  • 障害対応マニュアルを作成しよう(3)Webサーバ監視の管理基準書を作ってみよう
    • 北原 静香
    • 2003/10/23
    • Master of IP Network / @IT
    • http://www.atmarkit.co.jp/fnetwork/rensai/emerg03/01.html
    • (引用)今回は、システム管理者がどのようにシステムの障害に対応するのか、その監視運用の基準の策定をシステムを想定して具体的に解説することにしましょう。
  • センター統合を成功させるために
    • 塩澤 清恵(野村総合研究所)
    • 2003/10/17
    • ITソリューションフロンティア / 野村総合研究所
    • http://www.nri.co.jp/opinion/it_solution/2003/pdf/IT20030903.pdf
    • (引用)企業合併では、全社のシステムやリソースを合併会社の視点で最適化し直すことが求められるが、事務やシステムについては統合が難しく、すぐに経営の効率化に結びつくとは限らない。そこで事務・システムの統合と併行して、データセンターなどの物理的なリソースの統合を始めることが効果的である。本稿では、センター統合の検討の視点と実現施策について考察する。
  • Webアプリケーションの検査テクニック(2) 〜 Webサイトのセッションまわりを調べる方法 〜
    • 中村 隆之(三井物産GTI)
    • 2003/10/10
    • Webアプリケーションに潜むセキュリティホール(第6回) / @IT
    • http://www.atmarkit.co.jp/fsecurity/rensai/webhole06/webhole01.html
    • (引用)前回は Webアプリケーションの検査とはどういったものなのか、ということについて説明した。今回からは、実際にWebアプリケーションの検査に入っていく。前回説明した検査用ツール「Achilles」のインストールは済んでいるだろうか。今回はAchillesを実際に使用するので、まだという方は、前回の説明を見ながらインストールし、使い方に慣れておいていただきたい。
  • Web負荷テストの押さえるべきポイントとは
    • アットマーク・アイティ編集局
    • 2003/10/4
    • FYI / @IT
    • http://www.atmarkit.co.jp/ad/empirix/eload/eload01.html
    • (引用)いまやビジネスにとってWebサイトは重要なツールの1つであることはいうまでもない。しかし、そのWebサイトが不安定な状態で、顧客が不快な思いをしたり、使えない状況になっていたりすれば、かえってビジネスにはマイナスだ。今回は、Webサイトを正しく構築・運用する上で、公開前に実施してほしいチェックの1つである“負荷テスト”について焦点を当ててみよう。
  • やはりクオリティを中心に回る日本企業
    • 浅井 龍男(ガートナージャパン)
    • 2003/9/23
    • Gartner Column(第111回) / ITmedia
    • http://www.itmedia.co.jp/enterprise/0309/23/epn01.html
    • (引用)品質管理は日本の製造業のお家芸だと言われてきた。一時は、過剰品質などと言われてコスト高の元凶と目されもしたが、やはり日本企業は品質とその拡大概念としてのクオリティといったところで競争力を維持しようとしている。
  • Webアプリケーションの検査テクニック(1)
    • 中村 隆之(三井物産GTI)
    • 2003/9/20
    • Webアプリケーションに潜むセキュリティホール(第5回) / @IT
    • http://www.atmarkit.co.jp/fsecurity/rensai/webhole05/webhole01.html
    • (前編からの引用)前回まではさまざまなWebアプリケーションの脆弱性についての説明を行ってきたが、 今回からは実際に検査を行う場合に必要となるテクニックについて説明する。
  • Webサービスの互換性を検証するテストツール
    • 岩本 幸男(ビーコンIT)
    • 2003/9/20
    • Webサービス相互運用性(2) / @IT
    • http://www.atmarkit.co.jp/fxml/tanpatsu/29wsitool/01.html
    • (前編からの引用)Webサービスの相互運用性を向上させる目的で設立された「WS-I」から、2003年8月にBasic Profile 1.0が公開された。さらに相互運用ガイドラインへの適合性を検証するテストツールがWS-Iから提供されている。このテストツールの開発(国際化)に参加した筆者により基本的な使用方法を解説する。
  • 問題の所在を明らかにする − 複雑なシステムの問題判別技術
    • 奥田 邦夫/福田 剛志(日本IBM)
    • 2003/9/2
    • テクノロジ解説(第18回) / BizTechイノベーター
    • http://www.nikkeibp.co.jp/style/bizinno/tech/article20030902.shtml
    • (引用)(略)このため、障害時には調査対象が複数の製品・拠点にまたがり、今までのような単一製品・単一地点での調査では解決できず、広範囲な製品の知識と多様なツールが必要となってきました。私たちは(略)1996年以降、お客様のシステムで発生した障害の中で通常の方法では解決できない複雑な問題を1000件以上解析し、解決してきました。現在、IBM東京基礎研究所と共同で新しい問題判別技術の研究開発に取り組んでいます。今回は、その経験を元に、最新の問題判別技術について解説します。
  • システムの不具合を予防する方法
    • 西元 信雄(アイティ・フロンティア)
    • 2003/8/28
    • J2EE開発のパフォーマンス管理術(後編) / @IT
    • http://www.atmarkit.co.jp/im/carc/serial/performance02/pr02.html
    • (前編からの引用)本記事は、J2EEアプリケーション開発における重要な要素としての「パフォーマンス管理」をテーマとし、筆者自身の開発経験を交えて執筆する。後編では、前編で指摘した問題点を解決する方法として、システム内部動作の視覚化によるパフォーマンス管理解説を実例を挙げながら展開する。
  • オブジェクトの参照方法でガーベジ・コレクターに重大な影響が
    • Jack Shirazi / Kirk Pepperdine(JavaPerformanceTuning.com)
    • 2003/8/26
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/java/library/j-perf08273/
    • (引用)勇敢なる最適化推進者、JavaPerformanceTuning.com のディレクターJack ShiraziとCTOの Kirk Pepperdineはインターネット中で起きているパフォーマンスに関する議論を追跡しており、気が付いた問題をこのコラムで分析、明確化しています。今月はJava Games のWebサイトに注目し、ガーベジ・コレクションに際してアプリケーションがオブジェクトを解放しない場合に起きる問題をゲーム開発者がどのように特定し、解決しているかを見ていきます。
  • 障害対応マニュアルを作成しよう(2)「早期検知と迅速対応」ポリシー策定への道
    • 北原 静香
    • 2003/8/20
    • Master of IP Network / @IT
    • http://www.atmarkit.co.jp/fnetwork/rensai/emerg02/01.html
    • (引用)連載「障害対応マニュアルを作成しよう」の1回目『システム障害に対応する、とは』では、「システムの障害に対応する」の意味をお話ししました。いざというときに備えることが、システム管理の一部であること、また、システム管理コストは、そのシステムが稼働していることで得られる利益と密接にかかわっているということがお分かりいただけたでしょうか。そこで、今回は管理コストを念頭に置いたうえで、実際のシステム障害にどのように備えるべきかについて解説しましょう。
  • コンパイル・スピード、例外、ヒープサイズがBig Moose Saloon常連の話題に
    • Jack Shirazi / Kirk Pepperdine(JavaPerformanceTuning.com)
    • 2003/7/30
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/java/library/j-perf07303/
    • (引用)パフォーマンス。それはJavaプラットフォームで、常に非難を浴びる側面です。Javaプラットフォームが他の面では大成功を収めていることから、パフォーマンスの問題もきちんと検証すべき段階に来ています。この新しいコラムでは勇敢なる最適化推進者の二人、 JavaPerformanceTuning.com のディレクターJack ShiraziとCTOの Kirk Pepperdineが、彼らが経験している課題・問題を展開、明確化しながらインターネット中で沸きあがっているパフォーマンスに関する議論を追跡していきます。今月はJavaRanchに進み出て、コンパイル・スピード、例外、ヒープサイズ調整に関する議論を取り上げます。
  • なぜシステム障害を防げなかったのか ― 苦悩するユーザー
    • 森山 徹(日経システム構築)
    • 2003/7/30
    • 記者の眼 / 日経ITPro
    • http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20030729/1/
    • (引用)続発するシステムのトラブルが大きな被害をもたらしている。(略) トラブルの原因は多様だ。プログラムのバグや運用上のミス,ハードウエアの故障など,不具合が重なって復旧に手間取ることもある。どうすればトラブルは防げるのか。(略)システム面の対策はこの特集で詳しく書いたので,ここでは体制面に触れたいと思う。特に,トラブルをはさんだユーザーとベンダーの責任範囲である。
  • パフォーマンス問題解決の定石
    • 小野 幸治(ヒューレット・パッカード・ソリューションデリバリ)
    • 2003/7/30
    • J2EEパフォーマンス管理の勘所 / @IT
    • http://www.atmarkit.co.jp/fjava/rensai2/j2eeoprmng01/j2eeoprmng01.html
    • (引用)いま、J2EEシステムの運用をいかに成功させるかが大きな課題となっている。J2EEは新しいテクノロジであり、運用ノウハウを確立している企業が少ないからだ。例えば、システムが問題なく稼働していると判断されていたにもかかわらず、ユーザーからのクレームで初めてWebシステムのパフォーマンスに問題が発生していることが分かるケースさえある。
  • オープンソース時代のテスト手法、そのノウハウ ― Part3:ロードマップのしめくくり
    • Len DiMaggio(IBM Software Group/Rational Software)
    • 2003/7/29
    • The Rational Edge / @IT
    • http://www.atmarkit.co.jp/im/carc/serial/redge19/redge19.html
    • (引用)前回「オープンソース時代のテスト手法、そのノウハウ――Part2:テストのロードマップ」では、「スモークテスト」から「モニタリングとロギングテスト」までを解説した。今回は、「セキュリティテスト」から「メンテナンス性と拡張テスト」まで説明し、オープンソース時代のテスト手法におけるロードマップのまとめを行う。
  • 創造性を高めることによりシステムの信頼性を高めよ
    • 白井 康之(三菱総合研究所)
    • 2003/7/29
    • Take IT Easy
    • http://easy.mri.co.jp/20030729.html
    • (引用)システム統合や、大規模業務システム構築のような、できることが大前提となっているようなシステム開発に対しても、高い付加価値を求め、かつそれを健全に評価する仕組みが必要である。創造性よりも従順性、俊敏性よりも確実性が重視されると思われがちなシステム開発において、どのような付加価値が考えられるのだろうか ? 以下、考えられるところを列挙してみよう。
  • 障害対応マニュアルを作成しよう(1)− システム障害に対応する、とは?
    • 北原 静香
    • 2003/7/4
    • Master of IP Network / @IT
    • http://www.atmarkit.co.jp/fnetwork/rensai/emerg/01.html
    • (引用)この連載では「システムには障害が発生する」ということを前提として、障害をいち早く検知する方法や、障害が発生した場合の対処方法などについて解説します。しかし、発生した障害への技術的な対応方法や、障害原因の切り分け方法などはもっと詳細なほかの技術解説記事に譲ることにして、ここでは「システムの障害時にスタッフはどのように行動するべきか」に注目してみることにしましょう。
  • オープンソース時代のテスト手法、そのノウハウ ― Part2:テストのロードマップ
    • Len DiMaggio(IBM Software Group/Rational Software)
    • 2003/6/17
    • The Rational Edge / @IT
    • http://www.atmarkit.co.jp/im/carc/serial/redge18/redge18.html
    • (引用)テストのタイプは9種類ある。実施する順番はケースバイケースだが、まず最初に行うべきなのは「スモークテスト」であることを覚えておいて欲しい。以下、これらのタイプを詳細に説明し、併せてテストの計画と実施に役立つ「教訓」も紹介する。
  • リスク評価から始めよう
    • 清水 友晴(三菱総合研究所)
    • 2003/6/17
    • Take IT Easy
    • http://easy.mri.co.jp/20030617.html
    • (引用)セキュリティ製品といえばファイアウォールくらいしか無かった時代を考えると素晴しい限りだが、導入すればたちどころにセキュリティが改善されるといった魔法はありえない。どのセキュリティ製品にも使いどころがあり、不適切な使い方をしては効果が発揮できない。本稿では、適材適所のセキュリティ対処を行うために不可欠な「リスク評価とは何か」について述べる。
  • 再録:Scott Trappeに聞く、コード品質についての10の質問
    • Slashdot.org
    • 2003/5/14
    • Open Tech Press
    • http://opentechpress.jp/enterprise/03/05/14/0214213.shtml
    • (引用)Reasoning のCEOでコード品質のエキスパートであるScott Trappeに聞きたい質問を募集し、そのうち10の質問を実際に尋ねてみた。彼は質問に対する回答の中で、コード品質を向上させるためのいくつかのポイントと、彼がいかにして、もはや有名になった「LinuxのTCP/IPスタックは、商用ソフトの TCP/IPスタックより優れている」という結論に至ったかについて語ってくれた。
  • オープンソース時代のテスト手法、そのノウハウ ― Part1:どこから始めるか
    • Len DiMaggio(IBM Software Group/Rational Software)
    • 2003/5/9
    • The Rational Edge / @IT
    • http://www.atmarkit.co.jp/im/carc/serial/redge17/redge17.html
    • (引用)2回連続でお送りする今回のテーマで目指すゴールは、サードパーティの部品を使いながら構築したソフトウェア群を統合した結果、その“境界”で起こる問題を解決するための“レシピ”をステップ・バイ・ステップで示すことだ。ところで、この議論を始める前に、ソフトウェア間の“境界”には、統合作業を失敗に導く3つの「落とし穴」が潜んでいることをあらかじめいっておく。どこから始めたらいいのか、そしてどのように始めたらいいのか。まずはここから議論を始めよう。
  • SEの読むべき50冊 − テスト技法
    • 二上 貴夫(東陽テクニカ)
    • 2003/2
    • ネクストエンジニア Vol.10 / SEshop.com
    • http://www.seshop.com/se/yomu50/7.asp
    • (引用)テストは自分の力試しと思うと楽しい工程になります。
  • テストの基本を身につける
    • 好川 哲人(m&t Consulting)
    • 2003/2/16
    • All About Japan / Recruit
    • http://allabout.co.jp/career/swengineer/closeup/CU20030216A/index.htm
    • G.Myers「ソフトウェア・テストの技法」の内容のごく一部を短くまとめている。とても old-fashioned な記事なので、周りに聞く人がおらず本屋も無い初心者は、この記事でこっそり勉強するとよいだろう。
  • V字モデル【後編】
    • 山崎 敏(武蔵流プログラマ)
    • 2003/2/17
    • コードデザイン最前線(vol.12) / デスマーチと戦う武蔵流プログラマ やまざき のページ
    • http://www.01-tec.com/document/code_design/vol12.html
    • (引用)山田さんはホワイトボードに「V(ブイ)」の文字を大きく書き始めた.(略)ウォーターフォールモデルの変形で,「V字モデル(図1)」とか呼ばれていた気がする.そう思ったことを上田君がそのまま発言した.「V字モデルですね.」「そうです.問題なのは,テストでバグが出た場合の手戻りなんです.」と山田さんは手戻りの矢印を強調した.
  • V字モデル【前編】
    • 山崎 敏(武蔵流プログラマ)
    • 2003/1/26
    • コードデザイン最前線(vol.11) / デスマーチと戦う武蔵流プログラマ やまざき のページ
    • http://www.01-tec.com/document/code_design/vol11.html
    • (引用)私はあるシステム開発でデスマーチに陥っていた.期限はあと1ヵ月.身も心もボロボロ.コードも書けていない.後輩の上田君は辞めると言っている.そんな中,女性プログラマの山田さんが投入される.彼女はいったい….
  • Webサービスのテスト技法進化論
    • Jason Bloomberg(Senior Analyst/ZapThink LLC)
    • 2002/11/19
    • The Rational Edge / @IT
    • http://www.atmarkit.co.jp/im/carc/serial/redge11/redge11.html
    • (引用)Webサービステストのこれら2つの局面と企業によるWebサービスの採用を詳細に説明する。今後数年間のロードマップを組み合わせれば、Webサービステストがどの方向に向かって発展していくべきかが明確に見えてくる。
  • ソフトウェアテスト〜短期開発が増すテストの重要性〜
    • 端山毅(NTTデータ/技術開発本部/開発担当シニアスペシャリスト)
    • 2002/10: Vol.15
    • US Insight: Silicon Valley Research
    • http://www.nttdata.co.jp/event/report/usinsight/us_2002/pdf/usi_vol15.pdf
    • (引用)ソフトウェアテストに関する問題を概観した後、ソフトウェアテストの基本的な事項を整理する。このソフトウェアテストに関する解説は、実際にテストを行う人を対象とした高度なものではなく、発注者や管理者、マーケティングや営業など、非技術系の人々に対するオリエンテーションを意図している。この分野に詳しい方は読み飛ばして頂いて結構である。最後の項では、短期開発など最近の動向を踏まえて、今後のテストのあり方をまとめてみた。
  • 優秀なテスターの育成と訓練方法
    • Cem Kanerへのインタビュー
    • 2002/9/14
    • The Rational Edge / @IT
    • http://www.atmarkit.co.jp/im/cpm/serial/redge08/redge08.html
    • (引用)法学博士であるCem Kaner氏は、フロリダ工科大学のコンピュータサイエンスの教授であり、おそらく世界で最も著書と読者の多い作家、コンサルタント、教育者、そしてソフトウェアテストを専門にする弁護士でもある。今回Kaner氏には、テストのための教育とコンサルティング業務との関係に対する持論や、「アジャイル」ソフトウェア開発に対する見解を語ってもらった。
  • テストの経済学・心理学的捉え方
    • 畑田 成広(テクノロジックアート)
    • 2002/08/21
    • http://home.att.ne.jp/gamma/shata/articles/whatstest.html
    • (引用)ネタ元は、「ソフトウェア・テストの技法」第2章をまとめたものです。ソフトウェア開発のときに行う「テスト」に焦点を当てており、大変面白い本です。ソフトウェアのテストについての古典中の古典ですね。
  • システム障害を引き起こす「テスト不足」の正体
    • 大和田 尚孝(日経コンピュータ)
    • 2002/8/1
    • 記者の眼 / 日経ITPro
    • http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20020731/1/
    • (引用)大規模なシステム・トラブルが頻発している。(略)トラブルの当事者となった企業の多くが,その原因として「テスト不足」を挙げている,ということである。実際,「テストでバグを発見できなかった」と指摘する新聞や雑誌の記事も数多く目にした。だが,そもそも「テスト不足」とはどういうことなのか。そして,なぜ「テスト不足」が起きたのか。記者はこうした疑問を解くために,ユーザー企業やベンダーを取材して回った。その結果,各社の言う「テスト不足」の意味は,大きく二つに分けることができた。
  • 「テスト」徹底に挑む企業〜トラブルの芽を見逃すな!
    • 大和田 尚孝/吉田 琢也(日経コンピュータ)
    • 2002/8/1
    • 日経コンピュータ Express
    • http://itpro.nikkeibp.co.jp/free/NC/TOKU1/20020725/1/
    • (引用)障害の原因となるバグや仕様の不備は,どんなシステムにも必ず潜んでいる。こうしたトラブルの芽を稼働前に摘み取るための最後の砦がテストだ。頻発するシステム・トラブルを目の当たりにして,企業は改めてテストの重要性に目覚め始めた。東京海上火災保険やセブンーイレブン・ジャパン,東レなどの先進ユーザー企業や大手インテグレータへの取材から,企業を危機から救うテストのあり方を探った。
  • 分散コンピューティング時代のテスト手法
    • Jeffrey Bocarsly/Jonathan Harris/Bill Hayduk(RTTS)
    • 2002/7/20
    • The Rational Edge / @IT
    • http://www.atmarkit.co.jp/im/carc/serial/redge06/redge06.html
    • (引用)簡単にいえば、既存のアーキテクチャやコンピューティング環境が複雑化したため、従来のクライアント/サーバ指向のテストスキーマが時代遅れになってしまったのである。ソフトウェアの開発と導入を成功させるには新しく積極的な品質改善戦略が必要である。最も有力な戦略は、コンポーネントのテストと環境全体のテストを組み合わせたものだ。
  • ソフトのバグによる損失は年間595億ドル − 米商務省
    • 日経BizTech
    • 2002/7/1
    • http://www.nikkeibp.co.jp/archives/193/193751.html
    • NISTの発表資料 / レポート本文
    • (引用)  「ソフトウエアのバグによる損失額は年間で推定595億ドルにのぼる。この数字は国内総生産の0.6%に相当する」、などとする調査結果を、米国商務省の国立標準技術研究所(NIST:National Institute of Standards and Technology)が米国時間6月28日に発表した。NISTによると、テスト・インフラを強化して早期にバグを検出および除去することにより、1/3以上の損失(222億ドルに相当)を減らすことができるという。現在のバグの半数以上は開発段階の後半か、販売時に発見されている。
  • 国際市場向けのEclipseプラグインをテストする方法
    • Dan Kehn(IBM)
    • 2002/7
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/opensource/library/os-i18n2/
    • (引用)この記事では、国際化対応製品を検証する方法を示し、翻訳テストの際に生じることが予想される一般的な問題のための対応を示します。この記事には、プロパティー・ファイル比較 ビューを定義するEclipseプラグインが含まれています。このプラグインを使用することにより、翻訳テスターはエラーを迅速に検出することができます。
  • インタビュー「金融機関のシステムリスク動向とその管理について」
    • 富永 新(日本銀行考査局企画役)
    • 2002/6/28
    • にちぎんクオータリー2002年夏季号(6月25日発刊) / 日本銀行情報サービス局
    • http://www.boj.or.jp/type/pub/nichiginq/out033.htm
    • (引用)このところ、大きなシステムトラブルの発生などを契機に、金融機関のシステムリスク管理のあり方にスポットライトが当たっています。本日は、こうしたリスクの特徴や、今後の金融機関経営面での課題などについて、日本銀行考査局企画役の富永さんにお話を伺います。
  • Java単体テスト・ツールの生かし方
    • 井上 英明(日経オープンシステム)
    • 2002/6/19
    • 日経ITPro
    • http://itpro.nikkeibp.co.jp/members/NOS/ITARTICLE/20020619/1/
    • (引用)短期開発を乗り切るには,定型作業を多く含む“単体テスト”の自動化が有効だ。ここにきて,Javaプログラムにおける単体テストの自動化を可能にするツールが充実してきた。ただし,ツールによってカバーできるテスト項目などに違いがあるため,必要な機能を見極めて活用したい。
  • Javaコードの診断: 「テスト可能な」アプリケーションの設計
    • Eric E. Allen(Rice University)
    • 2001/9
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/java/library/j-diag0911/
    • (引用)今回の記事で、Eric Allen氏は、特定のバグ・パターンの調査を一時中断し、代わりに、テストするのが容易で面白いとも思えるソフトウェアを設計するのに関係する事項を、検討することにしました。同氏は、テストを記述する際に生産性を大幅に向上でき、その結果コード・ベースを強化する7つの設計原則について概要を示しています。
  • Webアプリケーションのパフォーマンスとスケーラビリティーの検査
    • Frank Cohen(Inclusion.net)
    • 2001/6
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/java/library/j-load/
    • (引用)急速に進展するWebアプリケーション開発の世界では、XMLとJavaテクノロジーの組み合わせによるパフォーマンスとスケーラビリティーのテストが不可欠です。この記事でFrank Cohenは、Webソフトウェアを構築するためのフレームワークについての概念を説明しています。ここでは、JavaオブジェクトとXMLベースのスクリプト言語の組み合わせがテストに役立つ理由や、状態テストや境界テストのような実際的なWebソフトウェア・テストを行う方法について、また、テストに役立つオープン・ソースのツールやLoadと言うスクリプト言語についても紹介されています。
  • PageHeap ユーザーガイド
    • 2001/6
    • WindowsXP White Paper / Microsoft
    • http://www.microsoft.com/japan/technet/prodtechnol/winxppro/deploy/pageheapug.mspx
    • (引用)ページ ヒープは、ヒープ関連のバグや破損を見つけるための強力なツールであり、また Microsoft Windows システム上で実行されているアプリケーションのリークもある程度見つけることができます。ページ ヒープでは、アプリケーションとシステムの間にソフトウェア検証層を導入し、すべての動的メモリ処理 (割り当て、解放、その他のヒープ処理) を検証します。この文書では、ページ ヒープの使用方法を解説します。Windows 2000 Service Pack 1 および Windows XP から利用可能になるページ ヒープ機能が対象となります。ページ ヒープはオペレーティング システムの一部であり、個別にインストールする必要はありません。その動作は、Gflags.exe および Pageheap.exe の 2 つのツールで制御します。
  • Windowsアプリケーションの探索的テストプロシージャ
    • 2001/6
    • WindowsXP White Paper / Microsoft
    • http://www.microsoft.com/japan/technet/prodtechnol/winxppro/proddocs/exptest.mspx
    • (引用)このドキュメントでは、ソフトウェア アプリケーション (以降「製品」として参照) が開発中の Windows バージョンでも期待通りの動作をするかどうかを検証する目的で、機能性と安定性をテストするためのプロシージャを記述しています。このプロシージャ (以降「プロシージャ」として参照) は製品を総合的にテストするものではないため、正式なテスト計画と置き換えないことをお勧めします。その代わり、Windows の新バージョンでも、ほとんどのユーザーが 既存製品を問題なく使えることの検証を限られた時間内で試みます。このプロシージャは、Windows 2000 対応アプリ認定プログラム向けに James Bach が開発した「汎用機能と安定性のテスト プロシージャ」に基づいています。
  • アプリケーション互換性チェックリスト − Microsoft Windows 2000 および Windows XP 用
    • 2001/4
    • WindowsXP White Paper / Microsoft
    • http://www.microsoft.com/japan/technet/prodtechnol/winxppro/deploy/chkcomp.mspx
    • (引用)このアプリケーション互換性チェック リストは、アプリケーションが新しいオペレーティング システムと互換性があるかどうかをテストする際に、取り上げる一般的なテスト事項を列挙したものです。このリストには、ほとんどのアプリケーションに当てはまる代表的なテスト事項を含めます。これはアプリケーションのテストについて検討する出発点となることを意図したものです。
  • テスト、面白いですか?本当に?
    • Jeff Canna(RoleModel Software)
    • 2001/3
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/java/library/j-test/
    • (引用)テスト。私はテストがダ〜イ嫌いです。 私は、いままでズ〜とテストが嫌いでした。単体テストと機能テストはどちらも「本来の」仕事の邪魔になります。 誰でも、作成したコードは完ぺきだと思っているものです。コードを変更する必要がある場合に、誰が見ても処理内容がわかるように十分なコメントが記述されることはめったにありません。 私はもっと大人になる必要があるでしょうか? (カウンセラーに相談する必要があるかもしれません)
  • ユーザビリティ試験の威力
    • Scott Berkun(Microsoft Corporation)
    • 2000/11
    • MSDN Library Japan / Microsoft
    • http://msdn.microsoft.com/ja-jp/library/cc421563.aspx
    • (引用)ユーザビリティ試験の価値と、それをプロジェクトのライフサイクル全体に取り入れることの重要性について解説します。
  • やさしいバグトラッキング
    • Joel Spolsky(Fog Creek Software)
    • 2000/11/8
    • Joel on Software
    • http://japanese.joelonsoftware.com/Articles/PainlessBugTracking.html
    • (引用)バグデータベースを使っていることは優れたソフトウェアチームの目印になる。実際にそれをやっているチームがいかに少ないかということには、いつも驚かされる。大きな間違いはの1つは、プログラマがすべてのバグを覚えておけるとか、あるいはポストイットで管理できると信じていることだ。しばらくあなたの耳を拝借できるなら、以前のアーティクル「やさしいスケジュール」と「やさしい機能仕様」の精神にのっとり、バグトラッキングのとても簡単なやり方について説明しよう。
  • ジョエル・テスト
    • Joel Spolsky(Fog Creek Software)
    • 2000/8/9
    • Joel on Software
    • http://japanese.joelonsoftware.com/Articles/TheJoelTest.html
    • (引用)そこで、私は自分で作ることにした。これはソフトウェア開発チームの質を評価するものだが、とっても当てにならないいいかげんなテストだ。このテストの素晴らしいところは、3分程度で終わることだ。(略)「ジョエル・テスト」の良い点は、それぞれの質問にすぐにイエスかノーかを答えられることだ。
  • コード検査でテストを補う
    • Mark Roulo(JavaWorld)
    • 2000/3
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/java/library/j-jw-javatip88/
    • (引用)コードの検査は、バグを除去する上で最も強力な手段の 1 つです。コードの検査が有益である理由の 1 つに、テスト時に見過ごされたエラーが発見されることが多いということがあります。検閲者が特定の間違いを探すようにするなら、コードの検査の効果はさらに高まります。テストするよりコードを読んだ方が見つけやすい間違いの場合は、特にそう言えます。ここでは、コードを検査することによって容易に見つけることのできるプログラミング上の間違いを何種類か取り上げます。

記事 / テストファースト関連(Wiki化以前)

  • JUnit用アサーション・エクステンション:alphaWorksのパッケージを使うと、複合アサーションを持つユニット・テストが容易に
    • Tony Morris(IBM)
    • 2005/3/8
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/java/library/j-unitx/index.html
    • (引用)JUnitを使うと、目的とする要求に合致しているというアサーション(assertions)を行うことでソフトウェアのコード・ユニットをテストできるようになりますが、こうしたアサーションは初歩的な操作用に限られています。この記事では、IBMのソフトウェア技術者のTony MorrisがJUnit用のJUnitX(Assertion Extensions for JUnit)を導入して、その隙間を埋めます。JUnitXは、JUnitフレームワーク内で実行する一連の複合アサーションを提供します。 alphaWorksからの、この新しいパッケージを使って、Javaソフトウェアの信頼性と堅牢性を向上させる方法を学んでください。
  • Jesterでテストをテストする
    • Elliotte Rusty Harold(Polytechnic University)
    • 2005/3/3
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/java/library/j-jester/
    • (引用)包括的なユニットテスト・スイートは堅牢なプログラムのために必須なものです。しかし、そのテスト・スイートが、行うべきテストをすべて行っているかどうか、どのように分かるのでしょう? Ivan Mooreの書いたJUnitテスターであるJesterは、テスト・スイートの問題を発見するのに優れており、ユニークな方法でコードベースの構造を分析します。この記事ではElliotte Rusty HaroldがJesterを紹介し、最善の結果を得るための使い方を説明します。
  • PMDでバグを退治する
    • Elliotte Rusty Harold(Polytechnic University)
    • 2005/1/7
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/java/library/j-pmd/
    • (引用)オープン・ソースの静的解析ツールであるPMDは、バグ退治のツールとして手元に置くべき価値のあるものです。この記事ではPMDに組み込まれているルールの使い方と、Javaコードの品質を改善するためにカスタムのルール・セットをどのように作るかを、Elliotte Rusty Haroldが説明します。
  • TestNGでJavaユニット・テストを楽々行う
    • Filippo Diotalevi(IBM Italy)
    • 2005/1/6
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/java/library/j-testng/
    • (引用)この数年、JUnitはごく僅かしか進化していません。JUnitは補完的な他のテスト・フレームワークと統合して使う必要があるため、今日のように複雑な環境に向けたテストを書くことが次第に難しくなっています。この記事では、Filippo Diotaleviが、Javaアプリケーションのテスト用の新しいフレームワークであるTestNGを紹介します。TestNGは非常に強力で革新的、拡張可能そして柔軟なだけではなく、JDK 5.0の素晴らしい新機能であるJavaアノテーション(Annotations)の応用例として、非常に興味深いものにもなっています。
  • .NET開発でアジャイルを導入するための実践テクニック
    • 福井 厚 & 小井土 亨
    • 2004/12/22
    • Insider .NET / @IT
    • http://www.atmarkit.co.jp/fdotnet/devprocess/agileentry02/agileentry02_01.html
    • (引用)アジャイル開発プロセスのプラクティスをどのように導入すれば効果的だろうか?(略)後編となる今回は.NET開発環境においてアジャイル開発のプラクティスを実践するための具体的な方法を紹介する。単体テストを自動化するとテストの頻度を増やすことができ、コードの修正が原因で以前はパスしていたコードが思わぬ影響を受けてパスしなくなるといった状況を早期に発見できるようになる。良いテストの原則を挙げるので、テスト作成のときの参考にしてほしい。
  • テスト駆動開発ツール最前線(後編)−Mockオブジェクトを使ったNUnit 2.2によるテスト
    • 川俣 晶(株式会社ピーデー)
    • 2004/11/17
    • .NET Tools / @IT
    • http://www.atmarkit.co.jp/fdotnet/tools/nunit22_02/nunit22_02_01.html
    • (引用)前編では、テスト駆動開発ツールNUnitの新版であるNUnit 2.2の新機能について紹介した。今回は、NUnit 2.2の新機能の中でも最も注目すべき「Mockオブジェクト」と、NUnit 2.2によるテストを支援する2つのツール「Test Driven .NET」と「NMock」について解説する。
  • Groovyを使って、より高速にJavaコードをユニット・テストする
    • Andrew Glover(Vanward Technologies)
    • 2004/11/9
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/java/library/j-pg11094/
    • (引用)まだあまり古い話ではありませんが、developerWorksの寄稿者であるAndrew Gloverがalt.lang.jre シリーズの一部として、Javaプラットフォーム用の標準言語として新しく提案されたGroovyの紹介記事を書きました。読者からの反応が非常に大きかったので、この新しい技術を使うための実際的なガイドとして、コラムを始めることになりました。この最初の記事では、GroovyとJUnitを使って Javaコードをユニット・テストするための単純な戦略を紹介します。
  • テスト駆動開発ツール最前線(前編)−.NET用テスト駆動開発支援ツールNUnit 2.2の新機能
    • 川俣 晶(株式会社ピーデー)
    • 2004/11/6
    • .NET Tools / @IT
    • http://www.atmarkit.co.jp/fdotnet/tools/nunit22_01/nunit22_01_01.html
    • (引用)この記事は、「NUnit入門 Test Firstのススメ [NUnit 2.0対応版]」および「『テスト駆動開発』はプログラマのストレスを軽減するか?」の内容のアップデートという位置付けである。今回は、それに加えて関連する2つのツールを紹介する。
  • テスト駆動開発(TDD)が分かると従来の設計手法の問題が見えてくる(後編)
    • arton
    • 2004/4/27
    • 連載◎開発現場から時代を眺める / 日経ITPro
    • http://itpro.nikkeibp.co.jp/free/JAV/J2EE/20040426/2/
    • (引用)前編では,テスト駆動開発(TDD)の概要と,従来型の実装設計の手法を説明し,TDDを適用することによって最初に説明した開発手順が「どのように変わるか」を説明した。後編では,TDDの適用が向いているのはどのような開発なのかについて考えてみよう。
  • テスト駆動開発(TDD)が分かると従来の設計手法の問題が見えてくる(前編)
    • arton
    • 2004/4/27
    • 連載◎開発現場から時代を眺める / 日経ITPro
    • http://itpro.nikkeibp.co.jp/free/JAV/J2EE/20040426/1/
    • (引用)本稿の目的は,TDDがテストのためのものだというありがちな誤解を解くことである。またそれと同時に,なぜプログラムの設計工程以降にTDDが有効なのか,逆に言えば実装の詳細を細部まで,プログラミング工程の前にあらかじめ机上で設計する従来型の手法の何が問題なのかを解説する。
  • DbUnitとAnthillによるテスト環境の制御
    • Philippe Girolami(Digiplug)
    • 2004/4/13- developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/java/library/j-dbunit/
    • (引用)Extreme Programming 方法論の導入は、主流のJava開発実践においてテストと同時進行させる開発そして連続的な統合をもたらしました。このような手法をサーバー側のjava 開発に導入する行為は、ツールが揃っていなければ最悪の事態を招きかねません。連続的な統合にいかにして対処するか、そして(テスト前にデータベースの状態を設定してテスト環境を一貫して制御する為に)JUnitと同時進行でいかにしてDbUnitを使用するかを、ソフトウェア開発者である Phillippe Girolami氏がこの記事で説明します。
  • 「テスト駆動開発」はプログラマのストレスを軽減するか?
    • 川俣 晶(株式会社ピーデー)
    • 2003/11/8
    • @IT
    • http://www.atmarkit.co.jp/fdotnet/special/tdd/tdd_01.html
    • (引用)本稿の目的は、実際の開発に携わるプログラマの視点から、TDDを検証してみることにある。具体的には、『テスト駆動開発入門』(ケント・ベック著ピアソン・エデュケーション刊)への筆者なりの感想と、実際にTDDを試みた結果を基に構成している。あくまで筆者の解釈によるTDD解説なので、よりオリジナルの形のTDDを知るには、この書籍を読むことをお勧めする。
  • エクストリーム・プログラミングの神秘を解く: ジョブに最適な (XP) ツール
    • Roy W. Miller(RoleModel Software)
    • 2003/5/27- developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/java/library/j-xp052703/
    • (引用)開発チームがXPを試してみようと思ってみても、どこから始めてよいのか分からないことが多いものです。一般には、そういう人たちは、XPのプラクティスに関して多くの疑問を抱いています。技術は身に着けたものの、その後はどうすればいいのでしょうか?今月、Roy Miller氏は、理論を実践に移し、使用すべきツールとその使用法について説明します。
  • NUnit入門 Test Firstのススメ [NUnit 2.0対応版]
    • 川俣 晶(ピーデー)
    • 2003/4/26- .NET Tools / @IT
    • http://www.atmarkit.co.jp/fdotnet/tools/nunit2/nunit2_01.html
    • (引用)「NUnit」は、単体テストの自動実行を支援するためのツールである。Java用のテスト・ツールである「JUnit」をベースにして、.NET Framework上で利用できるように変更を加えたものだ。
  • エクストリーム・プログラミングの神秘を解く: テスト主導型プログラミング
    • Roy W. Miller(RoleModel Software)
    • 2003/4/22- developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/java/library/j-xp042203/
    • (引用)テスト主導型プログラミングは、プログラマーの意表をつくXPの特徴の1つです。プログラマーの多くは、その意味およびその実行方法について誤った認識を持っています。今回の記事で、XPコーチでありJava開発者のRoy Miller氏は、テスト主導型プログラミングとは何か、なぜそれがプログラマーの生産性と品質を飛躍的に向上させるのか、およびテストを書くために必要な技法について説明します。
  • Eclipse、CVS、Antを利用した継続的インテグレーション&テスト環境の構築
    • 縣俊貴/橋本正徳(Project Mobster/メディアファイブ)
    • 2003/6/13
    • 快適なXPドライビングのすすめ / @IT
    • http://www.atmarkit.co.jp/im/carc/serial/xpd07/xpd07.html
    • (引用)XPのプラクティスに「継続的インテグレーション」というのがあります。JUnitによるテストと同様にXP開発ではないプロジェクト(チーム)でも実行可能な項目です。新規クラスの追加やリファクタリングの後、リファクタリングがほかのクラスに影響を及ぼしたことや、ユニットテストでも見つからなかった結合時に発生するバグを継続的インテグレーションを行えば見つけることができます。さらに、テスト用マシンを本番環境さながらに用意しておけば、環境依存のバグをいとも簡単に発見することができます。継続的インテグレーションで高速道路をフルスロットルで飛ばしましょう!
  • テストファーストでコードを作成する
    • 縣俊貴/橋本正徳(Project Mobster/メディアファイブ)
    • 2003/4/11
    • 快適なXPドライビングのすすめ / @IT
    • http://www.atmarkit.co.jp/im/carc/serial/xpd05/xpd05.html
    • (引用)今回は実際にEclipseを使ってテストファーストでコードが作られていく様子をチュートリアル形式でご紹介します。JUnitを用いた単体テストはXP開発でなくてもシステムの品質向上に十分に役に立つプラクティスです。ぜひJUnitの持つパワーを体験してみてください。
  • EclipseとJUnitによるテスティング
    • 縣俊貴/橋本正徳(Project Mobster/メディアファイブ)
    • 2003/3/7
    • 快適なXPドライビングのすすめ / @IT
    • http://www.atmarkit.co.jp/im/carc/serial/xpd04/xpd04.html
    • (引用)XPではテストに関して「テストファースト」に代表される、独自のアプローチを取っています。それらは通常の開発に慣れた人にとっては、奇異に映るかもしれません。しかし、実際に開発に取り入れて実践してみると、大変合理的な手法であることに気付くと思います。今回は「テストの意義」と「テスティングフレームワーク(主にJUnit)」について解説し、その後Eclipseを利用した効果的な単体テストの活用法に焦点を移します。
  • Javaコードの診断: 単体テストと自動コード分析の連携
    • Eric E. Allen(Rice University)
    • 2002/7
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/java/library/j-diag1015/
    • (引用)単体テストと静的分析は、プログラムの正確さを保証する上で、互いに関係のない方法と考えられることがよくあります。今回の記事では、これら2つの方法の関係を調べ、それぞれのバックボーンとなるツールをどのように使用すれば、相互に連携して互いに利点をもたらすものとなるかについて説明します。具体的には、Eric Allen氏が、単体テストをより一層活用するために利用可能な新しい優れたアプリケーションのいくつかについて説明します。
  • AntとJUnitを用いた漸進的開発: 単体テストでコードの品質を徐々に向上させる
    • Malcolm Davis
    • 2000/11
    • developerWorks / IBM
    • http://www.ibm.com/developerworks/jp/java/library/j-ant/
    • (引用)ソフトウェア開発においてやり方を少し変えることで、ソフトウェア品質の大幅な向上につなげることができます。 単体テストを開発プロセスに取り入れ、プロジェクト全体を通すと、時間と労力がどの程度節約できるかを確認してみましょう。 ここでは、単体テストのメリット、特にAntとJUnitを使用してコード・サンプルを単体テストする場合のメリットを探ります。


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2008-07-19 (土) 01:38:19 (3985d)