dotTEST 新バージョンリリース！

C# / Visual Basic .NET 向けテストツール

ご紹介が遅くなってしまいましたが、 dotTEST の新しいバージョンがリリースされました。
今回は、リリースされたdotTESTについてご紹介いたします。
dotTESTとは、.NET Framework 対応のテストツールです。C#や Visual Basic.NET のコードに対してインスペクションやテストを自動化することができます。

dotTESTを用いたテストは、コマンドラインから実行したり、Visual Studio へプラグインしGUI から実行したり、開発環境に応じて使い方を選択することができます。
例えば、Jenkinsのような継続的インテグレーションツールと連携しテストを自動化することや、コーディングしながら自分の書いたコードに問題がないかをチェックすることもできます。

dotTEST の機能

dotTESTには、次の機能があります。

コーディングスタンダード

社内のコーディング規約に準じているかをチェックしたり、バグを引き起こすコードになっていないか？また、可読性・保守性の高いコードになっているかをチェックすることができます。

フロー解析

静的解析の一部で、アプリケーションを動かさず、アプリケーション動作時に発生するリソースリークや NullReferenceException といったクリティカルな問題を発見することができます。

メトリクス解析

ソースコードの規模、複雑さ、保守性などのソースコードのメトリクスを解析することができます。

単体テストの実行

NUnit や MSTestで作成したテストケースを実行し、カバレッジを計測することができます。

アプリケーションカバレッジ

アプリケーションを実行しながら、カバレッジを計測することができます。

次回から、dotTESTの機能と新しいバージョンでの変更点をご紹介していきます。 dotTEST の体験版をご用意しています。ご興味がある方は、こちらからダウンロードしてお試しください。

【7/15開催】 組込みソフトウェア品質向上セミナー

高度化した現代の組込みソフトウェアでは、たった一つの欠陥が大きな社会的影響を及ぼすことに繋がります。しかしながら、品質確保のために行うべき具体的な方策が見出だせていない方も多いのではないでしょうか？

かつて開発規模が短期間で急激に増加した開発現場で、「生産性倍増」を目標に掲げ、開発効率２倍/早期バグ検出率２０％向上を実現した事例があります。
そこには、現代の開発現場の問題解決にも通じる数多くの“ヒント”が隠されていました。


今回はその実例の立役者である(株)オプテック　先端技術研究開発タスクフォースおよび、ＪＡＳＡ　ＩｏＴ技術研究会　主査である　竹田 彰彦 様をお招きし、当時の事例をご紹介いただくとともに、組込みシステム開発の過去と今から分かる不変の開発・テストプロセス改革についてご講演いただきます。

さらにテクマトリックスからは、開発プロセスの中でもテストフェーズに着目し、うまくいかない 単体テスト と 静的解析 の実例をもとに、実際の開発現場で実践した効果を出すテスト運用法についてご紹介します。

品質の確保に課題を持たれている方必見の内容となっておりますので是非ご参加ください！

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　◆セミナー概要
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

【開催日程】
2016年7月15日(金)13:00～16:30 (開場：12:40)

【会場】
御茶ノ水ソラシティカンファレンスセンター　1F　ROOM B
東京都千代田区神田駿河台4-6

【定員】
80名(定員になり次第締め切らせていただきます。)
　　　　※同一部署からのご参加は、2名様までとさせていただきます。
　　　　※ご同業の方の参加はご遠慮いただいております。

【参加費用】無料

【講演内容】
■「組込みシステム開発技法」～プロセス改革の軌跡～
【講師】
　　　(株)オプテック先端技術研究開発タスクフォース　エグゼクティブ・フェロー
　　　ＪＡＳＡ　状態遷移設計研究会、ＩｏＴ技術研究会　主査
　　　竹田　彰彦　様

【概要】
　　１．プロセス改革の軌跡
　　　携帯電話開発で取り組んだ、プロセス改革を振り返り、特に、単体テストでの
　　　ツール適用とその効果、導入に向けたポイントについて解説する。

　　２．組込みソフトウェアの開発手法
　　　組込みソフトウェアの特性を理解し、特性に応じたプロセスや設計を
　　　適用することの重要性。

　　３．品質向上に向けたテスト手法
　　　ソフトウェアテスト概要、プロジェクト診断、ツール適用の必然性。


■開発現場で成果を出した単体テストの運用改善アプローチ
【講師】
　　　テクマトリックス株式会社　ソフトウェアエンジニアリング技術部
　　　渡辺　征一

【概要】
単体テストの実施において、ツールの運用がうまくいかない、効果がでないのはなぜなのか？
今回は過去のユースケースを元に、単体テストを成功につなげるためには、何が不足していて、何を実施する必要があったのかについてご紹介します。


■品質を底上げする静的解析運用のコツ  ～バグの元を断ち切れ！～
【講師】
　　　テクマトリックス株式会社　ソフトウェアエンジニアリング技術部
　　　筒井　俊晴

【概要】
バグを早期発見するための取り組みをしていても、バグが減らない開発現場とバグが減っていく開発現場があります。
バグの元を断ち切るためには、どのような取り組みをすればよいのか？
本セッションでは、バグが減っていく開発現場の特徴とその理由を交えて、品質を底上げするための静的解析運用法をご紹介します。


　※内容は、変更する場合がございます。あらかじめご了承ください。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆予告情報！　※自分の席から気軽に参加！オンラインセミナー開始します！※
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
○「遠方まで出向いてセミナーに参加するのはなかなか難しい」
　「まずは概要を知れるような機会がほしい」というお客様必見！
　パソコンさえあれば、自分の席から製品紹介セミナーに参加できる、
　オンラインセミナーを開始します！
　※日程等は、近日弊社セミナーページでの公開を予定しています。　

テストケースのコーディングが不要！ Test Case Editor

単体テストの最大の課題とは？

単体テストが必要であることは認識している。でも時間がないので現実は… という開発現場は少なくないと思います。

単体テスト工程における最大の課題はテストケースのコーディング作業とされ、ツールを使用しない場合、 そのコーディングの量はテスト対象のソースコードの 3～5 倍とも言われています。

テストケース、スタブのコーディングが不要！

C++testの最新バージョンではソースコードを記述せずにテストケースを作成できる「Test Case Editor」が新たに搭載されました。

Test Case Editorを使うと、コーディングを行うことなく、テストケースとスタブを作成することができます。またテストケースの入力値／期待値、スタブの振る舞いなども独自のGUIから設定することが可能です。

さらに、テストケースのメンテナンスもGUI上で行うことができるため、テスト対象が変更される度にテストケースのコードを修正するといった煩雑な作業から開発者を解放します。

高機能なスタブ

Test Case Editorを利用することで、コーディングを行うことなく高機能なスタブを作成することが可能です。 例えば、渡された引数に応じた戻り値を設定するなど、複雑な振る舞いをGUI上で容易に組み込むことができます。

条件に応じて、オリジナル関数をそのまま呼び出す／スタブの処理を実行するを切り分けることもできます。 これにより、標準関数の処理が失敗した場合などの異常系の動作検証を簡単に行うことができます。

TÜV SÜDによる認証

C++testは、第三者試験認証機関であるTÜV SÜD社よりISO 26262（自動車の機能安全についての国際規格）、IEC 61508（機能安全の国際規格）に準拠したテストツールとして認証を取得しております。最新のC++test 9.6においても、認証を再取得いたしました。
テストツールが認証を取得していない場合、ユーザーは規格の要求に応じて、第三者試験認証機関に認証を依頼し、認証を取得するための時間や費用が必要になります。C++testは認証のためのコストを削減します。

無償体験版をお試しください

これらの機能は、無償体験版にてご確認いただけます。
まだC++testをご利用いただいていない方は、この機会にぜひお試しください。
C++testの機能概要、稼働環境は以下をご覧ください。

・単体テスト
・コーディングルールチェック
・フロー解析
・実行時メモリエラー検出／アプリケーション実行時カバレッジ
・最新の稼働環境

※本文中に記載されている製品名、および社名はそれぞれ各社の商標または登録商標です。

C++test 体験版ダウンロードは ↓ こちら ↓です。

Jtest DTP・Parasoft DTP を利用した短期・高品質開発

短期・高品質開発を実現する仕組みとは？

今回は、Jtest DTPとParasoft DTPを組み合わせた短期・高品質開発を実現する仕組みをご紹介します。

短期・高品質開発を実現するJtest DTP、Parasoft DTPの仕組みは以下の通りです。

図の仕組みに関して詳細にご説明いたします。

①継続的インテグレーションによる問題早期発見

継続的インテグレーション導入により、ビルド・インスペクション・テスト・パッケージング・リリースを継続的に実行し、開発・テストプロセスで発生する問題の早期発見が可能です。「問題点→対策」の一例を以下に示します。

• ビルドが壊れた！→コンパイル不能なコードを特定しビルドが通るように修正
• インスペクションで指摘が発見された！→バグの場合は早期に修正
• テストが失敗した！→バグの場合は早期に修正
• 上記すべてを合わせて、リリース可能なモジュールか判断可能！

特に、Jtest DTPによるインスペクション・テスト自動化により、コーディング工程で結合レベルのバグを早期発見したり、人の目では追えない複雑な処理(Exception発生時の処理等)で発生する問題を特定することができ、早期に品質を向上させるための基盤を整えることができます。

※Jtest DTPで検出できる指摘については詳しくはJtestとOSSとの違いを参照ください。

②Parasot DTPによる問題点可視化・リスク分析

継続的インテグレーションで発生した問題を眺めているだけでは、何も解決しません。問題が改善しているのか、リアルタイムで確認する必要が出てきます。

Parasoft DTPでは、インスペクション、テスト、メトリクス、ビルド等さまざまな情報を一元的に収集して表示できます。ウィジェットの一例を示します。

問題の発生状況をリアルタイムで確認

ウィジェット	概要
	指摘事項の傾向を表示し、改善しているかを確認できます。
	ソースコードメトリクスに順守して開発しているかを表示します。赤は指摘、緑は順守していることを示します。
	Jenkinsのジョブの状況を表示します。

多角的なデータからリスクを特定し、自動的に優先度付け

ウィジェット	概要
	モジュールのビジネスリスク・セキュリティリスク・指摘数からリスクのあるモジュールを特定します。
	Googleのバグ予測スコア・サイクロマチック複雑度・コードボリュームから複雑でバグの混入確立が高いコードを特定できます。

③優先度付けされた指摘の取り込み、修正と生産性の高い開発

開発者は優先度付けされた指摘事項やテスト結果をIDEに取り込めます。 普段使いなれたIDE上で確認ができるので 生産性の高い開発も実現できます。

EclipseとIntelliJ IDEAに指摘を取り込んだ画面

開発者の手元でも解析を行えるので、チェックイン前のコードの品質を高めることができます。

最後に

いかがでしたでしょうか。Jtest DTPとParasoft DTPを組み合わせることで早期に問題を発見し、改善状況をリアルタイムにモニタリングできます。また、多角的な情報からリスク分析することで、ソフトウェア開発をより潤滑に進められるのではないでしょうか。

今回ご紹介した Jtest DTP、Parasoft DTPに関するセミナーを10月23日に実施いたします。

セミナーにつきましては、以下の記事で詳しく紹介していますので、ぜひこちらも御覧ください。

「2015年10月23（金）開催セミナー　JALインフォテック様における旅客システム開発の品質向上事例紹介！」



また、Parasoft DTPの体験版もご用意しておりますので、ぜひお問い合わせください。

【東京・大阪】ユースケースセミナー開催レポート

先日、東京・大阪２会場で開催されました「ユースケースに学ぶ 運用に乗せるソフトウェア品質向上ノウハウ」セミナーは、多くの方にご参加頂き、ご好評のうちに無事終了いたしました。
ご参加いただいた皆様ありがとうございました。

会場の様子

今回のセミナーでは、これまでのテクマトリックスの取り組みで成功した複数のユースケースをもとに、現場に合った運用に乗せる品質向上策の実施方法について、ご紹介させていただきました。

両会場ともに、セッション終了後もその場で多くのお客様より個別にご相談をいただくなど、大盛況のうちに終了することができました。


セミナーにご参加いただいたお客様の声

「うまくいかないプロジェクトの特徴は耳が痛い部分がありました。」

「ソフトウェア品質向上に向けた取り組み手順などの参考になりました。」

「単体テストの導入を検討しており、参考になった。」

「分かりやすいセミナーをありがとうございました。」

ご都合により来場いただけなかった方で、セミナー内容にご興味のある方に、当日資料の簡易版も提供しております。ご希望の方は、お気軽にお問い合わせください。

=============================================================================

「開発現場で成果を出した単体テストの運用改善アプローチ」

単体テストの実施においてツールが運用にのらない、効果がでないのはなぜなのか？過去のユースケースを元に、成果を出すための単体テストの実施手順について、ご紹介いたしました。

=============================================================================

「品質を底上げする静的解析の徹底利用法」

バグを検出するフロー解析を続けているだけでは、次回以降のプロジェクトでも、同じようなバグの作り込みを繰り返す可能性があります。

「テスト工程以降にバグが流出している」

「過去と同じバグを繰り返している」

「レビューの工数が多い、指摘漏れが多い」

といったケースにおける静的解析の効果的な運用法について、ご紹介しました。

=============================================================================

「ソースコード解析ツールの最新版Understand 4.0を活用した単体テスト、静的解析の効率化」

先日、最新版バージョン4.0がリリースされたソースコード解析ツールUnderstand を活用し、効果的な単体テストや静的解析に必要となるソースコードの構造や影響範囲を正しく理解する方法についてご紹介しました。

=============================================================================

セミナー終了後もたくさんのご相談をいただきました

今回ご紹介したテストツールC++testとソースコード解析ツールUnderstandの詳細や導入事例、体験版については、Webサイトを参考ください！

テクマトリックスではツールのご提供のみにとどまらず、導入前の支援から、導入開始時における開発者向けのトレーニング、CI（継続的インテグレーション）環境構築など、運用に乗せるための様々なサービスも実施しています。

ご興味のある方は、お気軽にお問い合わせください。

今回セッション内でご紹介したノウハウを実際に体感いただける、特別プログラムのハンズオンセミナーを東京・大阪にて近日開催予定です。

こちらもぜひご参加ください！

参加者特典アリ！ 東京・大阪にて開催特別セミナー

テクマトリックスでは、これまで車載機器・OA機器・FA・医療機器など、様々な組込み業界において、多くの課題解決に取り組んで参りました。
ソフトウェア開発の現場で、次のような問題に悩まされた経験はないでしょうか？

• （有償無償に関わらず）テストツールを導入したがうまく運用に乗らない。

• 静的解析を実施しているが、工数が増加しただけで効果を実感できない。

• 自社の独自コーディングルールにツールが対応しておらず、目視のレビューが必要。

これらの問題を解決し品質向上を成功させるためには、お客様の開発現場や文化、特性に合った対策が必要となります。

今回のセミナーでは、テクマトリックスの長年のノウハウのもと、上記のような課題を解決した複数ユースケースから、品質向上策の実施方法についてご紹介します。

実際の運用を想定した解決策を知りたい方、様々な品質向上策についてまとめて知りたい方、現状の課題に対して何から取り組むべきか迷われている方は、是非ご参加ください。

　★セミナー参加特典★

講師がセッション内でご紹介したノウハウを実際に体感いただける、特別プログラムのハンズオンセミナーを東京・大阪にて近日開催予定です。
本セミナーにご参加いただいたお客様には、優先的にご案内させていただきます。
※日程等はセミナー内でお知らせ致します。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆セミナー概要
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

【開催日程】※東京と大阪では開催日程が異なりますので、ご注意ください。
　■東京開催
　2015年9月4日(金)13:30～17:00 (開場：13:10)

　■東京会場
テクマトリックス　セミナールーム
東京都港区三田3-11-24　国際興業三田第2ビル

　■定員　40名(定員になり次第締め切らせていただきます。)
　　　　※同一部署からのご参加は、2名様までとさせていただきます。
　　　　※ご同業の方の参加はご遠慮いただいております。

------------------------------

　■大阪開催
　2015年9月11日（金）13:30～17:00（会場：13:10）
　
　■大阪会場
新大阪ブリックビル
大阪府大阪市淀川区宮原1丁目6番1 新大阪ブリックビル3階
会議室E+F
　
　■定員　30名(定員になり次第締め切らせていただきます。)
　　　　※同一部署からのご参加は、2名様までとさせていただきます。
　　　　※ご同業の方の参加はご遠慮いただいております。
------------------------------
【参費費用】無料


【講演内容】
■「開発現場で成果を出した単体テストの運用改善アプローチ」
【講師】
　　　テクマトリックス株式会社　ソフトウェアエンジニアリング技術部
　　　渡辺　征一

【概要】
単体テストの実施において、ツールの運用がうまくいかない、効果がでないのはなぜなのか？　今回は過去のユースケースを元に、単体テストを成功につなげるためには、何が不足していて、何を実施する必要があったのかについてご紹介します。


■「品質を底上げする静的解析の徹底利用法」
【講師】
　　　テクマトリックス株式会社　ソフトウェアエンジニアリング技術部
　　　工藤　公靖

【概要】
バグを検出するフロー解析を続けているだけでは、次回以降のプロジェクトでも、同じようなバグの作り込みを繰り返す可能性があります。
本セッションでは、基本的な静的解析の適用例から、過去に発生したバグを二度と繰り返さない運用まで、徹底的な静的解析の利用法をご紹介します。


■「ソースコード解析ツールの最新版Understand 4.0を活用した単体テスト、静的解析の効率化」
【講師】
　　　テクマトリックス株式会社　ソフトウェアエンジニアリング営業部
　　　渡部　達郎

【概要】
単体テストや静的解析において、構造や影響範囲を正しく理解することは非常に重要です。ソースコードを高速に解析し、必要な情報を容易に収集することで、単体テストと静的解析をいっそう効果的なものにする方法をご紹介します。


　※内容は、変更する場合がございます。あらかじめご了承ください。

失敗しない単体テストに必要なものとは？

単体テストやらないと・・・と思っていても、なかなか取り組めていない人も多いのではないでしょうか？

今回は、これから単体テストに取り組もうとしている人も、実際に始めてみたけど結果に満足していない人にも参考にしてほしい、失敗しない単体テストの実施法についてご紹介します。

■単体テストの重要性

ソフトウェアの規模がそれほど大きくなかった時代においては、複数の開発者が作成したプログラムを結合し、まとめてテストするほうが効率的でした。
しかし、大規模・複雑化が進む最近のソフトウェア開発では、すでに効率的な方法ではなくなってきています。

一般的にソフトウェアの規模が大きいほどバグは見つけづらくなり、後工程で見つかるバグほど修正コストが大きくなると言われています。
バグを残したまま開発が進む「まとめてテストをする」方法では、バグの潜在化を招くとともに、リリース直前・直後に見つかるバグの対応に追われることになります。

そこで、重要になってくるのが「単体テスト」です。

単体テスト（ユニットテストと呼ばれることもあります）とは、プログラムを構成する部品（コンポーネント）が個々の機能を正しく果たしているかどうかを検証するテストです。
テスト対象を分割し、細かくテストをする単体テストを開発早期から実施することで、バグの作り込みを防止し、しかも迅速かつコストを抑えて修正をおこなうことができます。こうして部品の品質が向上し、最終的に全体の品質向上につながっていきます。

このように、メリットの多い単体テストですが、様々な要因によりうまく実施できていない開発現場も多いようです。では、なぜ単体テストがうまくいかないのでしょうか？

■単体テストの実施を妨げる課題

既存のソフトウェアの追加・保守開発が多くを占める開発現場では、すでに複雑化したソフトウェアに対して、１から単体テストを実施することは難しくなっています。
また、開発現場に単体テストの実施フローが確立されていないために、本格的に取り組もうとすると従来の方法とは別に発生する工数を懸念したり、実施を始めたもののうまく効果が出せていないという声もよく聞かれます。


お客様からよく聞かれる課題

• 全てをテストする余裕がない
• 効果的なテストの粒度（スコープ）が分からない
• 担当者によってテスト精度が異なる
• 網羅的にテストをしたのにバグが多く残る
• 単体テストの効果が見えない

このように、敷居が高く感じられる単体テストで効果を出すためには、どうすればいいのでしょうか。


■単体テストを成功に導くために

今回挙げられた「お客様からよく聞かれる課題」の１つひとつに対して、テクマトリックスのこれまでの経験と実績をもとに、「失敗しない単体テストの勘所」と題し、資料にまとめました。

　　　全てをテストする余裕がない現場での解決策は…

　　　　　　　ソフトウェアのコードを○○の条件で３つに分類することだった！

など、詳しい内容を知りたい方は、ぜひ資料をご参考ください！

また、テクマトリックスでは。単体テストを効率的に実施する様々な機能を備えたテストツール「C++test」の導入から、単体テストの実施までをサポートするサービスをご提案しています。
製品サイトでは、ツールの導入メリットや単体テスト実施においてC++testがカバーする範囲、活用ポイントなどをまとめています。ぜひご参照ください！

C++testで効率化する単体テスト

品質向上に結果を出す！！静的解析のチーム運用術

品質向上を目指し、開発現場に「静的解析」を取り入れたものの、なかなか結果に結びついていないと感じている方は多いのではないでしょうか？

今回ご紹介する株式会社JVCケンウッドのプロオーディオ技術部では、従来の静的解析をより効果的なものにするためにツールを見直し、C++testを新たに導入しました。

同部署では「ツール導入が品質向上のゴールではない」という意識のもと、独自のチーム運用とプロセス改革により、静的解析の効果を最大限に引き出しています。さらに、単体テストによるアプローチも同時に実施し、効率的な品質向上を実現しています。

品質向上が“実感できる”静的解析の実施法とは？
開発者の意識が変わる静的解析のチーム運用とは？
C++testだから実現できた開発者の教育・スキルアップとは？

ツールの活用・導入において、効果が出ない状況に行き詰っている方は、JVCケンウッド様が実施している結果を出すツール運用を、是非ご参考ください！

▼▼事例のダウンロード・詳細な内容に対する問い合わせはこちら▼▼

■静的解析＋動的解析　両方の機能を搭載したオールインワンテストツール

C++testとは？

C++testは、C/C++プログラムの単体テスト、コーディング規約チェック、静的フロー解析、実行時メモリエラー検出を自動化する総合的なテストツールです。

静的解析では、バグの検出をおこなう静的フロー解析とバグを防止するコーディング規約チェックで、品質の底上げを開発フェーズの早期から強力にサポートします。

C++testを15日間無料で試用できる体験版をご用意しているほか、Jtestを使用して、効率的にテストを行う方法を短時間でご理解いただける無償のハンズオンセミナーも実施中です。

こちらも是非、ご利用ください。

　　

　　

ESEC2015出展レポート

5月13日～15日、東京ビッグサイトで開催されました『ESEC：組込みシステム開発技術展2015』にテクマトリックスブースを出展し、多くのお客さまにご来場いただきました。
誠にありがとうございました。

テクマトリックスブースでは、機能安全規格IEC 61508や自動車向け機能安全規格ISO 26262のツール認証を取得したC/C++言語対応オールインワンテストツール「C++test」を始め、C#/VB.NETアプリケーションを対象とした「dotTEST」とその最新導入事例をご紹介させていただき、連日、ブースは大盛況で終えることができました。

また今や世界中で、IoT、M2M、IVIなど外部システムと連携する組み込み開発が急増していく中、
連携接続先の用意が間に合わず開発が止まってしまうという問題を解決し対向機器/対向システムのふるまいを仮想化して、テスト対象機器のテストを円滑に進行させるためのインフラ「Virtualize」を、この度はじめて出展させていただきました。

ブースでは、システム並行開発で想定される問題と、Virtualizeを用いた問題解決方法について、クラウドからのセンサー機器遠隔操作システムをコンパクトにまとめたデモ環境を使って、ご紹介させていただきました。


IoT、M2M、IVIなど外部システムと連携する組み込み開発を円滑に進める方法にご興味がある方！新たにご紹介サイトをご用意しましたので、ぜひお越しください！！

システム並行開発インフラ「Virtualize」

システムテストでのテスト漏れ対策

リリース後に見つかるバグ

皆さんは、アプリケーションのリリース後にバグが見つかってしまうという苦い経験をされたことはありませんか?

リリース後にバグが見つかると修正する手戻りが大きく、もし繰り返しバグが発生するようであれば会社の信用にもかかわります。

しっかりシステムテストを実施しているのに、バグが発生してしまうのはなぜでしょう?

決して誰も手抜きをしている訳ではないはずです。

テスト漏れはシステムテストの観点不足？

システムテストでは、そのアプリケーションを利用する際の観点が多く盛り込まれ、操作性や業務の運用に問題がないかを確認します。その一環として異常系のテストも実施されるため、ひと通りの機能がテストされたように思えます。

しかし、ここに『観点の不足よるテスト漏れ』が潜んでいます。

例えば、ユーザの操作と言う観点でみると、ある機能のテストはひとつのテストケースで十分に見えるかもしれません。しかし、ユーザの操作と実際のソースコードは必ずしも一致する訳ではありません。

特にエラー処理などは、プログラム言語に依存したコードが含まれるため、ユーザの操作と言う観点だけではテスト漏れが生じてしまうのです。

Jtest 『アプリケーションカバレッジ』 でテスト漏れを予防

そこで今回は、テストの観点を補う仕組みとして、Jtest の『アプリケーションカバレッジ』をご紹介します。

この『アプリケーションカバレッジ』を使用すると、いつもどおりのシステムテストを実行するだけでコードカバレッジの計測が行えます。

コードカバレッジを計測すると、客観的にテストの実施状況を捉えることができます。

そのためテスト実施者の思い込みや考慮不足が取り除かれ、テスト漏れの防止に繋がります。

『アプリケーションカバレッジ』の実行イメージ

1. アプリケーションの操作を行います。


通常のテストシナリオを実行

2. アプリケーションの操作で計測されたカバレッジを確認します。

①行カバレッジ

C0：行カバレッジ計測

②判断文カバレッジ

C1：判断文カバレッジ

『アプリケーションカバレッジ』のおすすめ理由

上記の通り、『アプリケーションカバレッジ』を利用すると、システムテストで実行されなかったコードが一目でわかります。そのため、不足しているテストケースの特定が容易になります。

不足しているテストケースを知ることで、不足しているテストの観点に気づくことができます。

テストの観点不足によるテスト漏れを防ぐには、関数レベルの単体テストが有効な手段ですが、開発スパンの短いプロジェクトなどでは、そこまでのテスト実施は難しい場合があるでしょう。

『アプリケーションカバレッジ』なら面倒な準備は不要です。

これまでのシステムテストと変わらない工数で、より効果的なシステムテストを実施できるようになります。

手軽に始められる Jtest『アプリケーションカバレッジ』、ぜひシステムテストに取り入れてみてはいかがでしょうか？

『アプリケーションカバレッジ』の詳細はこちらのページでご紹介しています。 この機会にぜひチェックしてみてください。

評価版のご案内

今回ご紹介した、『アプリケーションカバレッジ』にご興味がございましたら、ぜひ Jtest 評価版で機能をお試しください。

↓Jtest の評価版はこちらからダウンロードできます。↓

Jtest には『アプリケーションカバレッジ』以外にも特定のコーディングパターンをチェックする『コーディングスタンダード』や複数ファイルにまたがる実行パスをシミュレートする『バグ探偵』、単体テストケースの自動生成、実行など様々な機能がございます。

Jtest の機能については次のページでご紹介しています。

Maven+Jtest9.5+Jenkinsによる継続的インテグレーション

継続的インテグレーションとは

継続的インテグレ―ション(CI)をご存知でしょうか。継続的インテグレーションとはエクストリーム・プログラミングのプラクティスのひとつで、ビルドやインスペクションを継続的に実行していくことを意味します。 本日は、Maven、Jtest、Jenkinsの各特徴をご紹介しながら、継続的インテグレーションをより効果的に運用できるような情報をお届けします。

Maven

Mavenとは、ビルドツールの一種です。いつ、どこで、誰がビルドしても同じ成果物を生成できることを目的としたツールになっており、以下の特徴を有しています。

• プロジェクトのディレクトリ構成が予め決まっている。
• 依存ライブラリはMavenリポジトリから自動的にダウンロードされる。
• 依存ライブラリを使用するタイミング(Maven用語ではフェーズ)を指定できる。
• JUnitによる単体テストの実行が可能である。
• 開発した成果物はMavenのリポジトリに公開可能である。

図1. EclipseのMavenプロジェクト

上記の特徴を持っているため、ソースコードを格納するディレクトリとMavenの設定ファイル(pom.xml)さえあれば、誰がどこでビルドしても失敗することはありません。 コンパイルや実行に必要な依存ライブラリは、Mavenが設定情報を元にインターネットから自動でダウンロードしてくれます。

また、Mavenには単体テストを実行できる枠組みも用意されています。JUnit単体テストケースをsrc/test/javaディレクトリに格納するだけで、Mavenがビルドの前に単体テストを自動実行します。デフォルトの動作では単体テストに失敗した場合ビルドは実行されません。これによりテストにパスしていない成果物の生成を防ぐことができます。ビルド時に意識することなく単体テストが実行されるため、回帰テストとしてもよく利用される機能です。

もちろん開発者はビルド時まで単体テストの実行を待つ必要はありません。mvn testコマンドを実行することで、単体テストを逐次実行することも可能です。

Jtest

Parasoft JtestはJavaアプリケーションに対するテストをサポートするためのツールです。大きく分けて静的解析機能と動的解析機能があり、今回は静的解析機能をご紹介します。 静的解析機能には以下の種類があります。

機能名	概要
パターンマッチング	特定の記述をしていることで発生するバグを検出する。
フロー解析(バグ探偵)	処理の流れを静的に追い、結果的に発生するバグを特定する。
メトリクス計測	ソースコードの保守性や複雑度を数値として計測する。

静的回帰ツールとしてはOSSのFindBugsやCheckStyleが有名ですが、Jtestのフロー解析を利用するとOSSではチェックしきれないファイルまたがりのバグを検出できます。
フロー解析(バグ探偵)で検出できるバグの一例をご紹介します。

図2. Jtestによるフロー解析(バグ探偵)の例

詳しくはOSSとの比較ページを参照ください。

Jtest Mavenプラグイン

JtestにはMavenプラグインが提供されており、MavenからJtestを呼びだすことができます。

図3. Jtest Maven プラグインの設定例(pom.xml)

通常、JtestはEclipseプロジェクトでなければ解析できませんが、Mavenプラグインを利用することによりEclipseプロジェクトではないMavenプロジェクトに対しても解析がかけられます。 MavenからJtestを実行するにはmvn parasoft:jtestのようにゴールに「parasoft:jtest」を指定します。

Jenkins

Jenkinsは言わずと知れた継続的インテグレーションツールです。以下の特徴を持っています。

• 定期的なビルドを実行することが可能。
• Mavenとの親和性が高い。
• JUnitの結果やFindBugsの結果をJenkins上で参照することも可能。
• GitやSubversion等のバージョン管理ツールと連携可能。
• 成果物(jar/war/ear)の管理が可能。

Jenkinsの新規ビルドの作成画面では、「Mavenプロジェクトのビルド」が専用で用意されており、Mavenによるビルドを簡単に設定することが可能です。

図4. Jenkinsのビルド作成画面

ビルドの設定画面ではMavenの設定ファイルである、pom.xmlの場所と、ゴール(clean/compile/test/install等)を指定するだけです。

図5. Mavenのビルド方法指定

Maven+Jtest+Jenkinsの相乗効果

Maven、Jtest、Jenkinsの特徴を組み合わせることにより、様々な効果を得ることが可能になります。

開発環境に縛られない

IDEごとにばらばらだった静的解析の実行や単体テストの実行はMavenからの実行で統一されます。 これにより、EclipseやNetBeans、IntelliJなど開発者は自分にマッチしたIDEを自由に選択できます。 静的解析を実行するためにEclipseプロジェクトになおして、依存ライブラリを設定して・・・などという煩わしい作業は不要になります。依存ライブラリの解決はMavenに任せればよいのです。

ジョブの管理が容易

あらゆるタスクがMavenからの実行で可能になるため、Jenkins上のジョブは一つで済みます。いくつもジョブを作成してビルドパイプラインを作る必要はありません。
以下をひとつのジョブで実現可能になり、継続的なインテグレーションをより容易に実現できます。

• ビルドの自動化
• 静的解析(パターンマッチング+フロー解析+メトリクス)とレポート生成の自動化
• 単体テストの自動化
• 成果物のデプロイ自動化

図6. JenkinsからMavenのビルドを実行した際のログ

開発初期から結合レベルのバグを検出

OSSの代わりにJtestのフロー解析を適用することで、コーディング工程では検出が難しいバグを検出可能になり、より効果的なインテグレーションを実施することが可能になるでしょう。検出した違反はMaven+Jtestによって${Mavenプロジェクト}/target/site/parasoftの配下にレポートとして自動出力されます。

図7. Jenkinsによって実行されたJtestのレポート

意識することなく回帰テストを実行可能

単体テスト工程になり、Mavenのテスト格納ディレクトリに単体テストファイルが蓄積されていくと、開発者が意識することなくJenkinsとMavenによって単体テストが実行されます。単体テストの結果は${Mavenプロジェクト}/target/surefire-reports/TEST-プロジェクト名.xmlで保存されるため、テスト結果をそのままIDEにインポートすることも可能です。 加えて、単体テストケースを蓄積しておくことで、ソースコードを変更した際の回帰テストとしての役目も担ってくれます。

成果物に対するテストの状況を確認

いつビルドした成果物なのかをJenkins上で管理することもできます。ビルドされた際のテスト状況も合わせて確認することができるため、リリース可能な成果物なのかを一目で確認可能です。

図8. Jenkins上での成果物と単体テスト結果の確認

最後に

今回はJtest9.5をベースにした継続的インテグレーションをご紹介しました。
Jtestの後継製品であるDTP for Javaでは、Mavenから単体テストを実行し、カバレッジを採取することも可能になる予定です。さらに便利になってインテグレーションの効果を上げるDTP for Java のリリースをお楽しみに！