タグ

ブックマーク / xtech.nikkei.com (68)

  • 第3回 「攻めるテスター」がアジャイル開発の品質を保証する

    第3回 「攻めるテスター」がアジャイル開発の品質を保証する カナダ ドラゴンファイアー創立者 ジャネット・グレゴリー氏に聞く 迅速かつ柔軟な開発を目指したアジャイル開発手法を採用する企業が増えている。この連載では、アジャイル開発を主導する「賢者」に開発の極意を聞く。今回は、アジャイル品質プロセスのコンサルティングや研修サービスを提供するカナダのドラゴンファイアーの創立者であるジャネット・グレゴリー氏に、アジャイル開発におけるテストの勘所を聞く。 グレゴリー氏のインタビューに入る前に、アジャイル開発のテストについて簡単に説明しておこう。アジャイル開発におけるテストは、従来型開発のテストと意味合いが異なる。従来型開発のテストは通常、要求・要件に適合しているかどうかを検証することを目的とする。これに対し、アジャイルのテストは「ビジネス価値を最大化しているか」を検証することを最大の目的としている。

    第3回 「攻めるテスター」がアジャイル開発の品質を保証する
  • キャプチャーリプレイツールを使ったGUIテストの自動化

    前回までは、単体テストを対象としたテスト実行およびテスト実装について、ツールによる自動化を解説しました。今回は、テスターによるGUI操作を伴うテストの自動化について紹介します。自動化には、キャプチャーリプレイツールと呼ばれるツールを利用します。 キャプチャーリプレイツールとは、「キャプチャー機能」「リプレイ機能」という二つの機能を備えるツールを指します。 ・キャプチャー機能 テスト対象となるシステムへのユーザー操作(キーボード入力、マウス操作など)を記録して、スクリプトとして保存する ・リプレイ機能 記録したスクリプトを用いて、何度も繰り返しテストを実行できる 以前のキャプチャーリプレイツールは、キャプチャー機能によって記録されるスクリプトにテスト対象の座標を利用していました。そのためGUIが少しでも変わると、スクリプトの修正が必要でした。その頃にツールを利用していた方は、今もそのようなイ

    キャプチャーリプレイツールを使ったGUIテストの自動化
  • なぜテスト自動化が必要なのか?

    読者の皆さんは、今の手作業のテストに問題がなければ、無理に自動化する必要はないと思うかもしれません。そのような方にもテスト自動化をお勧めする理由を、三つ挙げてみます(図1)。 (1)大規模・複雑化 vs 短納期・低コスト 最近のシステムがどんどん大規模化かつ複雑化しているのは、改めて言うまでもないことと思います。システムが大規模化、複雑化すれば、その分テストする量も増えるのが普通です。増えたテストをするには、より多くの時間をかける、あるいはテストする人を増やすなどの対応を取りたくなります。 ただし一方でシステム開発には、短納期、低コストという制約が立ちはだかります。限られた期間、予算の中で多くのテストをするためには、テストを自動化し、効率を上げることが解決策の一つとなります。 (2)多様なデバイスの登場 最近はスマートフォンやタブレット型端末などさまざまなデバイスが登場し、人々のライフスタ

    なぜテスト自動化が必要なのか?
  • Google、Android 4.1ソフト開発キットを公開

    一連のOpenGL呼び出しをトレースし、各呼び出しの結果を視覚的に確認できる「Tracer for GLES」 米Googleは現地時間2012年6月28日、モバイルOS「Android 4.1」(開発コード名「Jelly Bean」)に対応したソフトウエア開発キット(SDK)をリリースしたと発表した。最新版のツールパッケージ「Android SDK Tools, Revision 20」とEclipseプラグイン「Android Development Tools(ADT)20.0.0」を公開している。 このうちAndroid SDK Tools, Revision 20では、さまざまなAndroid用デバッギングツールをまとめた「Device Monitor」や、アプリケーション性能の最適化のための「Systrace」などを追加した。また「SDK Manager」などを強化したほか、テ

    Google、Android 4.1ソフト開発キットを公開
  • [危うい現状]法的には“グレー”が多いスマホアプリ

    「IDやプライバシーにかかわる情報を送信するAndroidアプリケーションは、400のうち約45.3%にも上る」---。KDDI研究所の竹森敬祐研究主査によるAndroidアプリケーションの挙動の調査結果が話題を呼んでいる。竹森主査がAndroid Market(2012年3月7日から「Google Play」に名称変更)から400のアプリを選び出して調査したところ、半数近くのアプリが、Android IDや端末ID(IMEI)、位置情報、電話番号など、利用者のプライバシーに関わる情報を外部に送信していた。そして、そのうち適切な説明や許諾があったアプリは、わずか2%程度しかないとも指摘する。 このように、利用者が意図しない形でモバイル端末から情報を取られるケースが横行している。とりわけ目立つのがAndroid端末だ。竹森主査は「実害はほとんど報告されていない」とするものの、今後、悪意あ

    [危うい現状]法的には“グレー”が多いスマホアプリ
  • 新日鉄ソリューションズがHTML5スマホアプリ開発基盤をOSSとして公開へ

    写真●新日鉄ソリューションズがOSSとして公開するスマートフォン/タブレット向けアプリケーション開発フレームワーク「hifive」の構成 新日鉄ソリューションズは2012年4月11日、「スマートデバイスソリューションセンター」を設置したと発表した。また同社が開発してきたHTML5準拠のスマートフォン/タブレット向けアプリケーション開発フレームワークをオープンソースソフトウエア(OSS)として公開することも明らかにした。 新日鉄ソリューションズでは、スマートデバイスの開発フレームワークやMDM(モバイルデバイス管理)ツールを提供してきた。「企業情報システムへのスマートデバイス格導入時代が到来した」ことから、2012年4月1日付けで専門組織を設置したとしている。 開発フレームワークは同社のシステム研究開発センターで開発しているもの。名称は「hifive」。スマートデバイス固有の開発知識を必要

    新日鉄ソリューションズがHTML5スマホアプリ開発基盤をOSSとして公開へ
  • 基礎から学ぶソフトウエア・テスト(6)

    品質を把握するためのグラフとしては,図5[拡大表示]のようなバグのオープン・クローズ・チャートが挙げられます。バグ検出数,未対応バグ数,対応バグ数の累計と,テスト・ケースの残数(実施件数)を時系列に折れ線グラフにしたものです。 このグラフからは多くのことが読み取れます。まず,バグ・レポートで指摘したバグが,どこまで対応されているのかがわかります。バグが直っていなければ納品はできませんから,とても重要な判断材料となります。また,バグの累計数の曲線がなだらかになっていくことでバグの発生が収束し,品質が安定していることを確認できます*9。 また,テスト・ケースの残数を同じグラフ内に別軸でグラフにすることで,テストの進ちょく状況も把握できます。バグの曲線がなだらかになっていても,テストの残数が減っていかない場合は,ただテストをしていないだけで,バグが収束したとはいえません*10。このようにバグの件

    基礎から学ぶソフトウエア・テスト(6)
  • なぜ相次ぐドコモの通信障害、スマホ時代に一変したインフラ運用の常識

    写真1●1月25日に発生したトラブルについて、1月26日午前に会見するNTTドコモの岩崎文夫 取締役 常務 執行役員(左) NTTドコモの大規模な通信障害が相次いでる。昨年から今年にかけて、スマートフォンに関連する大規模な通信障害だけでも4件発生。1月25日にも東京都内で最大で252万人がつながりにくくなるトラブルが起きたばかりだ(写真1、関連記事1、2)。事態を重く見た総務省は、これら一連のトラブルに対して再発防止策を取るように行政指導を行った。 実はそれぞれトラブルの原因となった箇所はバラバラである。昨年12月末の障害は、spモードシステム内サーバーの輻輳を契機に表面化したIPアドレス払い出しシーケンスの設計ミスに起因(関連記事、詳報を日経コミュニケーション2月号に掲載)。今年1月1日のトラブルは、spモードシステム内のサーバーの故障。1月25日のトラブルは、切り替えたばかりの携帯コア

    なぜ相次ぐドコモの通信障害、スマホ時代に一変したインフラ運用の常識
  • 図2●「IT内部統制項目表」イメージ(All Rights Reserved, Copyright (c) JEITA 2009)

    日経クロステック登録会員になると… ・新着が分かるメールマガジンが届く ・キーワード登録、連載フォローが便利 さらに、有料会員に申し込むとすべての記事が読み放題に! 日経クロステックNEXT開催記念キャンペーン! >>詳しくは

    図2●「IT内部統制項目表」イメージ(All Rights Reserved, Copyright (c) JEITA 2009)
  • ジェミナイ・モバイル、Amazon S3準拠API備えるクラウドストレージ構築ソフト

    ジェミナイ・モバイル・テクノロジーズは2011年7月19日、クラウドストレージ構築ソフト「Cloudian」の提供を開始すると発表した。Amazon S3 REST APIに準拠したクラウドAPIを備えるクラウドストレージ基盤を構築できる。大規模分散に向いたNoSQLデータベースを実装することも可能。月額使用料の料金体系を採用する。 2011年3月から試験版を提供していたが、このほど商用版として提供を始めたもの。同製品を利用すると、複数の顧客向けにデータストレージサービスを提供する環境を構築できる。最少2台のサーバーからシステムを構成し、台数を増やして容量を増大させることが可能。レポーティングと課金の機能も備える。 ソフトウエア使用料とサポート内容には、「Gold」「Silver」「Bronze」という三つのグレードがある。ソフトウエアの最低月額使用料は、Goldが159万2000円、Si

    ジェミナイ・モバイル、Amazon S3準拠API備えるクラウドストレージ構築ソフト
  • DIコンテナ

    DIコンテナは,「DI(Dependency Injection:依存性の注入)」と呼ぶデザインパターンに基づいて作られたコンポーネント群を集中管理するためのソフトウエアです。 DIは,コンポーネント(クラス)間の依存関係をソースコードから取り除くことで,プログラムの実行時までコンポーネント同士が依存関係を持たないようにするデザインパターンです。 例えば,あるクラスAの中で別のクラスBのインスタンスを生成して利用しているとき,AはBに強く依存してしまっています。つまり,Bを別のクラスに差し替えたときなどにはAも変更しなければなりません。このような依存関係は,AとBを別の人が作っている場合などに特に困ります。 こうした依存性をクラスから取り除くのがDIパターンです。Bへの依存性をAから排除するには,まずBの機能を抽象化したインタフェースIを定義し,Iを実装したクラスとしてBを作ります。 Bの

    DIコンテナ
  • データベースの内部動作を知る

    SQLのプログラミングは奥が深い。特にパフォーマンスの観点から、そう言えるだろう。 みなさんご承知の通り、同じ結果を出すプログラムでも、SQLの書き方次第で処理時間に何倍もの差が生じ得る。効率の悪いSQLを書いてしまう原因は、多くの場合、リレーショナルデータベースの内部動作やアプリケーションに関する理解不足である。両者をよく知った上で最適なSQLを書けるようになることは、システムエンジニアとしての重要なスキルの一つである。 特集『基礎から理解するデータベースのしくみ』では、リレーショナルデータベースの内部動作について、基的な部分を分かりやすく解説している。SQLプログラミングに役立つことはもちろん、SQLチューニングやデータベース設計のための基礎知識としても不可欠だ。 イントロダクション ブラックボックスのままでいいの? Part 1:SQL文はどのように実行されるのか SQL実行までの

    データベースの内部動作を知る
  • 第1回 重なった30の不手際

    東日大震災から3日後の2011年3月14日。この日の午前に最初のトラブルは発生した。テレビ局が東日大震災の義援金を番組などで呼びかけたところ、みずほ銀行東京中央支店のテレビ局の義援金口座(以下、口座a)に、振り込みが殺到した。 午前10時16分、振り込みによって生じた「取引明細」の件数が上限値を超え、口座aに対する「預金・取引内容照会」ができなくなった。取引明細は通帳の記帳に使う。 みずほ銀は口座aを、格納できる取引明細の上限値が小さい「個人・通帳口」として間違って設定していた(表-1)。 みずほ銀は口座の種類を二つの属性の組み合わせによって区別している。一つは「個人」か「法人」か。もう一つは、取引明細を通帳に記帳する「通帳口」か、記帳しない「リーフ口(ぐち)」かである。 これら二つの属性によって、格納できる取引明細の上限値が変わる。通常、義援金口座のような大量振り込みが予想される口座

    第1回 重なった30の不手際
  • Webシステムのボトルネック回避---目次

    Webシステムはアクセス数が増加することで性能が悪化する。ボトルネックの大半はデータベース・サーバー(DBサーバー)とアプリケーション・サーバー(APサーバー)にある。 性能を改善する方法は,ハードウエアの拡張とミドルウエアのチューニングが王道。従来,DBサーバーの拡張はサーバー機自体の入れ替えに頼っていたが,ここへ来てDBサーバーの負荷分散やDBアクセスのキャッシュが現実味を帯びてきた。(日川 佳三) Webシステムのボトルネック回避(1) 総論「DBサーバーの負荷分散が有効」 Webシステムのボトルネック回避(2) パート1:拡張「DBサーバーも拡張可能に」 Webシステムのボトルネック回避(3) パート2:チューニング「適切なパラメータを見出す」 Webシステムのボトルネック回避(4) パート3:新機軸「DBアクセスをキャッシュする」

    Webシステムのボトルネック回避---目次
  • Webシステムのボトルネック回避(1)

    画面1●ムラウチが実施したXML DBサーバーの負荷テスト結果<BR>ECサイトの商品情報を格納するXML DBサーバーに対し,想定したクエリーごとに同時アクセス数(画面中のC)とデータ件数(同D)を段階的に変えて応答時間を計測した。同時アクセス数は10~20クライアントでDBサーバー性能の限界に達する。データ件数による応答時間の変動も分かる Webシステムはアクセス数が増加することで性能が悪化する。ボトルネックの大半はデータベース・サーバー(DBサーバー)とアプリケーション・サーバー(APサーバー)にある。 性能を改善する方法は,ハードウエアの拡張とミドルウエアのチューニングが王道。従来,DBサーバーの拡張はサーバー機自体の入れ替えに頼っていたが,ここへ来てDBサーバーの負荷分散やDBアクセスのキャッシュが現実味を帯びてきた。 (日川 佳三=hikawa@nikkeibp.co.jp)

    Webシステムのボトルネック回避(1)
  • FX市場を創設、処理スピードは2ミリ秒

    大阪証券取引所は、「外国為替証拠金取引市場(大証FX)」を創設した(画面)。処理が高速であることが特徴。注文受付、約定ともに各2ミリ秒程度でこなす。システムの開発は、シンプレクス・テクノロジーが担当。「提案依頼書(RFP)」では50ミリ秒を目標に掲げたが、メモリーを活用することで処理時間を大幅に短縮した。 「システムの性能と信頼性にはこだわった」。大阪証券取引所 システム部の山森一頼氏は、新システムの開発方針をこう話す。FX市場への参入に伴い、売買/相場/清算システムを新たに構築した。高速処理を実現したポイントは、メモリーを活用する「オンメモリー型」アーキテクチャの採用にある。売買システムはメモリー上でトランザクションを処理し、その結果を非同期でデータベースに書く。こうしたデータ制御の仕組みを作り込んだ。 トレーディングシステムのスクラッチ開発でありながら、開発期間は14カ月(要件定義~

    FX市場を創設、処理スピードは2ミリ秒
  • 「メモリーを意識してみよう」第1回 ヒープがどのくらい使われているかを理解する

    Javaのメモリーはガーベジ・コレクタが管理するため,アプリケーション側ではそれほど気にするありません。しかし,全く気にしないわけにはいかないのも実情です。 小さいアプリケーションでは無頓着であっても構いませんが,大規模になればそうもいってはいられません。使用メモリー量,ガーベジ・コレクション(GC)の頻度,リークの有無などは,できればチェックしておきたい項目です。 Javaではメモリーを複数の領域に分割して管理しています。クラス定義やメソッドなどのデータが格納されるPermanent領域や,インスタンスが割り当てられるヒープなどがあります。このような領域がどのように使用されているかを知ることは,パフォーマンスを考えるうえでもとても重要になります。 ここでは,特にヒープに着目していきたいと思います。 ヒープの使用量を知る まずはヒープの使用量がどのくらいになっているかを調べてみましょう。

    「メモリーを意識してみよう」第1回 ヒープがどのくらい使われているかを理解する
  • システム基盤設計の基礎

    交通量に見合った道路を作ったり,工場の排煙を減らす高度なごみ処理施設を建設したりする,といった基的な都市計画がなされていない,つまり「都市基盤」が整備されていなければどうなるか。道路は慢性的に渋滞しており,たどりつくだけで一苦労。街で交通事故が発生しても救急車が現場に到達することさえままならない。工場は排煙をまき散らし,深刻な大気汚染を引き起こす──。 情報システムにも,同じことが当てはまる。豊富な機能を持つアプリケーションを開発することは確かに重要だ。だが,サーバーやストレージの性能や信頼性,ネットワークの回線速度などを無視していては,システムの品質を保つことは難しい。システム開発に携わるあらゆるITエンジニアにとって,システムの性能や信頼性などを左右する「システム基盤」の知識は不可欠だ。そこで講座では,システム基盤を理解するための基的な技術や用語から,実践的な開発方法論までを解説

    システム基盤設計の基礎
  • キャパシティ・プランニングの進め方:業務による負荷を洗い出す

    キャパシティ・プランニングの作業手順は,3つのフェーズに分かれる。(1)構築対象のシステムが実行する処理の種類や量である「ワークロード(負荷)情報」の収集と,それを基にした性能要件の決定,(2)性能要件からリソースのスペックを見積もる「サイジング」,(3)サイジング結果を評価して精度を高めていく「評価・チューニング」である。 トランザクション処理とターンアラウンドタイムに関する情報を収集してシステムに必要な性能を見積もり,サーバーやストレージなどのスペックを決定する「キャパシティ・プランニング」の進め方を見ていこう。 図1には,キャパシティ・プランニングの基的な作業手順を示した。作業手順は,大まかに次の3つのフェーズに分かれる。 (1)構築対象のシステムが実行する処理の種類や量である「ワークロード(負荷)情報」の収集と,それを基にした性能要件の決定,(2)性能要件からリソースのスペックを

    キャパシティ・プランニングの進め方:業務による負荷を洗い出す
  • Webアーキテクチャ設計術 --- ITpro

    Webシステムを設計するアーキテクトが検討すべきポイントを連載でお届けします。まず,「HTTPの仕組み」を説明した後,「可用性」「パフォーマンス」「セキュリティ」「運用性」の4点を取り上げます。この4点を,ソフトウエアの品質について定めた国際規格「ISO/IEC 9126-1」に基づいてマッピングすると,図1のようになります。網掛け部分が連載のターゲットです。

    Webアーキテクチャ設計術 --- ITpro