このブログについて

ソフトウェア開発におけるエラーの予防やプロジェクト管理、品質管理を支援するParasoft製品のTIPSなどを、国内総販売代理店テクマトリックスのサポートスタッフが紹介しています。

2014年12月19日金曜日

C++test 新バージョン リリース!

C言語/C++言語対応テストツール 「Parasoft C++test 9.5.4」をリリースいたしました。
多くのお客様からご要望をいただいておりましたIAR Compiler for RXをはじめ、サポート環境を拡充しております。


IAR Compiler for RXのサポート

機能安全規格への取り組みが広がる中、TÜV SÜDより認証された開発ツールへの関心が高まっています。

IARシステムズ社のルネサス RX用 IAR Embedded Workbench は、IEC 61508およびISO 26262に基づき認証された機能安全バージョンがリリースされており、今後ニーズが高まっていくことが予想されます。

こうした状況の中、C++test 9.5.4では、IAR Compiler for RXを正式サポートいたしました。

C++testは、ルネサス RX用 IAR Embedded Workbench のプロジェクトをインポートできるため、簡単に静的解析、単体テストを実施することができます。

サポート環境の拡充

IAR Compiler for RXのほか、以下がサポート環境に加わりました。

<IDE>
・Microsoft Visual Studio 2013
・Eclipse 4.3 Kepler

<コンパイラ>
・Microsoft Visual C++ 2013(12.0)
・GNU gcc/g++ 4.8.x、4.9.x
・Renesas HEW M16C/R8C C Compiler
・Green Hills MULTI C/C++ Compiler for PowerPC
・Green Hills MULTI C/C++ Compiler for INTEGRITY on PowerPC
・Texas Instruments CCS ARM C/C++ Compiler
・ARM C/C++ Compiler for uVision

最新の稼働環境一覧については、こちらをご覧ください。

※C++testはインストールしたホストマシンだけではなく、マイコンベンダーが提供するシミュレーターや、実機(ターゲット機)でも単体テスト、カバレッジ計測が可能です。 また、クロスコンパイラを使用した静的解析も行うことができます。

稼働環境一覧に含まれていないマイコンについては、個別でのご相談も承っておりますので、ぜひお問い合わせください。

C++testの機能概要は以下をご覧ください。

・単体テスト
  http://www.techmatrix.co.jp/quality/ctest/unittest/index.html
・コーディングルールチェック
  http://www.techmatrix.co.jp/quality/ctest/staticanalysis/index.html
・フロー解析
  http://www.techmatrix.co.jp/quality/ctest/bugdetective/index.html
・実行時メモリエラー検出
  http://www.techmatrix.co.jp/quality/ctest/memoryanalysis/index.html


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

ほかにも、「Parasoft C++test 9.5.4」では、MISRA C 2012をはじめとする約80個のコーディングルール追加や、ISO 26262対応で要求される「関数カバレッジ」の対応等、さまざまな機能拡張が行われています。

これらの機能は、無償体験版にてご確認いただけます。

まだC++testをご利用いただいていない方は、この機会にぜひお試しください。

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


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


 技術資料請求

2014年12月12日金曜日

第1回:Webアプリのテスト自動化は、なぜ失敗するのか?

世の中には、Webアプリケーションの機能テストおよび、システムテストの自動化をサポートするツールが存在します。しかし、これらのツールを使用しても、テストの自動化が上手く運用できなかった方が多いのではないでしょうか?

問題は、「テストシナリオのメンテナンスの難しさ」にあり、問題に対して、以下の課題が挙げられます。
今回は、これらの課題に対する対策について、紹介します。


  課題1 : 画面の構成が変わるたびに、シナリオを修正する必要がある

  課題2 : 画面数や、ブラウザのサポート数に比例して、テストシナリオの数や長さが大きくなる

  課題3 : テストシナリオがコード(Javaなど)で管理される場合、運用できる人が限定される

  課題4 : テストを行うための環境(DBの初期化、システムの更新)が必要となる


-------------------------------------------------------------------------------------------------------
 ◆◇◆   画面の構成が変わるたびに、シナリオを修正する必要がある   ◆◇◆
-------------------------------------------------------------------------------------------------------

◆ 課題
開発の中で、画面構成の変更の度に、テストシナリオの修正が必要となる場合、修正に手間がかかり、テスト自動化の恩恵が受けられなくなります。

一般的にテストツールを使用した場合、Webの操作は、HTMLの要素(または、XPath)で制御されますが、画面構成の変更の度に、この要素を修正するには、効率的とは言えません。



◆ 原因
画面構成の変更により、HTMLの要素が変わることで、テストツールで制御していた要素が特定できなくなります。このようなケースは、XPathでオペレーションが記録された場合も、同様に起こります。

以下は、画面構成によって、属性値が変わった(「ショッピングカートに入れる」 ⇒ 「ショッピングカートに追加」)ことにより、ボタンがクリックできなくなります。



◆ 対策
要素を一意の情報で制御することで、画面の構成に変更があったとしても、テストシナリオを修正することなくテストを継続できます。

以下のように、要素の属性にid(または、name)を指定することで、画面の構成要素を一意の情報で制御できます。


テストツールを使用し、テスト自動化を行うためには、ただテストシナリオを作成して、実行すれば良いだけではなく、テストの自動化を想定したアプリケーションを設計することも重要となってきます。


◆ テストツールによる対策!
以下、SOAtestのテストツールを使用した、対策方法についてご紹介します。

※ 静的解析ルールによる、HTMLの属性値の確認が可能!
WebアプリケーションのHTMLの要素に対して、idおよび、name属性が一意の値として振られているかをチェックするためのルールを使用し、確認を行うことができます。



保守性レポートによる、テストシナリオの確認が可能!
テストツールによって生成されたテストシナリオに対して、画面構成の変更により、テストシナリオが動作しなくなる可能性がある箇所をレポートします。




次回予告
-----------------
次回は、2つ目の課題である『画面数や、ブラウザのサポート数に比例して、テストシナリオの数や長さが大きくなる』の対策について紹介します。


 体験版ダウンロード
-----------------------------
http://www.techmatrix.co.jp/quality/download/index.html#soatest

2014年11月17日月曜日

2014年12月5日開催 お客様が語る実践セミナー 高信頼性システムソフトウェア開発への取り組み方




医療機器・車載機器・産業機械・航空宇宙機器などに使用されるシステムには高い信頼性と安全性が求められます。
そして、このようなクリティカルシステム(高信頼性システム)の開発従事者には国際規格に準拠するレベルのソフトウェア品質および安全性を達成するためのスキルが求められています。


一方で開発現場からは、

「規格対応セミナーに参加して規格の要求事項はどうにか理解できたものの、実際の現場で何からどう手をつけたらよいのかが分からない。」
 
「高信頼性システムへの取り組み方として、より実践的な内容が知りたい。」

という声も聞かれます。


そこで、今回はソニー株式会社メディカル事業ユニットの前田 宗泰様をお招きし、「開発者個々のスキルアップ」と「ソフトウェアエンジニアリング」の観点から現実的で効果的なクリティカルシステム(高信頼性システム)開発への取り組み方についてご講演いただきます。

また、テクマトリックスからはソフトウェアエンジニアリングの中でもソフトウェア品質確保における効果的なテスト方法にフォーカスし、その実施における課題と対応策について実例を交えながらご紹介いたします。


○医療機器・車載機器・産業機械・航空宇宙機器をはじめとしたクリティカルシステム (高信頼性システム)のソフトウェア開発に携われている方

○表面的な規格対応にとどまらず、高品質・高信頼性システムの開発のために、実務レベルでのプロセスの整備・改善、スキル向上を目指したい方

特にこれらに当てはまる方には、実践的な情報が得られる内容となっておりますので、是非参加をご検討ください。





━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆セミナー概要
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【開催日程】2014年12月5日(金)13:30~17:00 (開場:13:10)

【会場】東京コンファレンスセンター品川東京都港区港南 1-9-36 アレア品川 4F 406

【参費用】無料

【定員】80名(定員になり次第締め切らせていただきます。)
    ※ご同業の方の参加はご遠慮いただいております。


【講演①】
クリティカルシステム開発は
ソフトウェアエンジニアリングの個人メドレー!?
~結果を左右する基礎固めとは?~

【講師】
ソニー株式会社 メディカル事業ユニット 信頼性保証部門プロセスマネジメント部
前田 宗泰 様


【概要】
クリティカルシステムソフトウェア開発における規制や規格は、分野が異なってもソフトウェアエンジニアリングをベースにしている点は共通です。また安全性実現のために実質的に開発者には個人メドレーの如く、多くのスキルを要求するものとなっています。
一方で開発現場では具体的にどのように取り組めばよいのか答えを見いだせていないことが多くあります。
そこで今回は、開発者のスキルとソフトウェアエンジニアリングにフォーカスし、好ましい習慣としての“お作法”をキーワードに現実的で効果的な取り組み方をご紹介いたします。

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


【講演②】
ソフトウェアエンジニアリングの基礎への取り組み
~成果を出す静的解析・単体テストの実施法~

【講師】
テクマトリックス株式会社 ソフトウェアエンジニアリング技術部
渡辺 征一

【概要】
ソフトウェアエンジニアリングの基礎の中でも重要になるのが静的解析と単体テストです。
これを効率的に実現するために様々なツールが存在しますが、開発現場で運用に乗らないということをよくお聞きします。運用に乗らない主な原因は、各開発者の必要なスキルが不足していることや各開発者が好ましい習慣を身につけるためのプロセスの見直しができていないことにあります。
そこで、スキルやプロセスの見直し方法をはじめ、そこで洗い出される課題への対応策について具体的な事例を交えご紹介します。



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


【申込方法】お申し込み受付ページからお申し込みください。

2014年11月7日金曜日

C++testの便利な使い方


今回のテーマ:無限ループの単体テスト

皆さん、単体テストしてますか?

今回は、すこし稀な話題かもしれませんが、無限ループの単体テストについて取り上げてみたいと思います。

皆様のご存じのとおり、無限ループのある関数に対して単体テストをうまく実施することはできません。 テスト対象の関数が終了し、実行後の状態を確認しないと単体テストは完了とならないからです。

今回の記事では、C++testを使って無限ループの単体テストを行う方法をご紹介します。


どうして無限ループの単体テストができないのか?

関数単位で実行される単体テストは、

  1. 事前状態の設定
  2. 関数の実行
  3. 事後状態を確認

というような構成をとります(このような構成は、ホーアトリプルと呼ばれます)。

関数の実行による状態の変化、つまり事後状態を確認することで単体テストは完了します。

そのため、関数内の処理が無限ループに入ってしまうと、事後状態を確認することができず、単体テストは成立しないのです。

そのまま実行してもタイムアウトしてしまう・・・



C++testでは無限ループなどでテスト対象の処理が終わらない場合、タイムアウトでテスト失敗とみなします。(そのほかのツールではテストの実行がハングアップしてしまうかもしれません。)

そのため、無限ループするソースコードについては、レビューをしっかり行い単体テストは省略するという選択肢をとる場合もあります。

しかし、実際の開発現場では、ループ内の処理を確認したい、コードカバレッジを計測したい というケースがあるでしょう。

そうなると、どうにかして無限ループの単体テストを実施しなければなりません。

無限ループへの対策

では、無限ループのある関数をテストするにはどうしたらよいのでしょう?

よく見かけるのは、
  1. #ifdefで一時的にループを排除する
  2. ループを抜けるための変数を用意する(デバッガで変数を書き換える)
というような方法です。

すでに皆様の中にもこのような方法をとっている方がいるかもしれません。もちろん、それでテストが実施できていれば問題はありません。

ただ、1番目はソースコードが煩雑になりますし、2番目については、テストを自動化することができません。

そこで、登場するのが、

3. 「無限ループ用のC++test マクロを使う」


です。


無限ループの単体テストに対応するためのマクロ - C++test ユーザーズガイドより
名前
説明
CPPTEST_REGISTER_JMP(expression)
setjmp または sigsetjmp を使って内部的なジャンプ バッファーを設定し、渡される式を評価します。 CPPTEST_JMP API の呼び出しを使ってバッファーにジャンプすることができます。通常このマクロはテスト ケースの内部で使用され、テスト対象関数への呼び出しをラップします
CPPTEST_JMP (value)
longjmp の呼び出しを実行します (longjmp または siglongjmp 使用されます)。実行ステータスを最新の CPPTEST_REGISTER_JMP の呼び出しに戻します。通常このマクロはスタブの中で使用され、整数の引数を受け取ります。この引数は cpptestGetJmpReturn 関数によってテスト ケース内で返却されます。引数を使って、実行されるジャンプの正しさを検証できます 。
int CDECL_CALL cpptestGetJmpReturn();
最新の CPPTEST_JMP の呼び出しの戻り値、つまり longjmp/siglongjmp の引数を返します。これは setmp/sigsetjmp からの戻り値です。

これらのマクロを使うと、テスト対象のソースコードに手を加えることなく、無限ループの単体テストを実施することができます。

無限ループ用のC++testのマクロの利用イメージ


テストケースの実装例

ぜひご活用ください!

今回は、無限ループに関する、C++testの便利な使用方法をご紹介しました。

ご紹介したマクロについては、サンプルコードがC++testのマニュアルに記載されておりますので、あわせてご活用ください。

また、ユーザ様向けに、FAQサイトの公開もおこなっております。そちらもぜひご利用ください。


C++testをご利用いただいていない方は、この機会にぜひお試しください。

無償体験版ダウンロードは↓こちら↓です。



 技術資料請求


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

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

2014年10月21日火曜日

セミナー情報「JAVA,C#,VB.NETの単体テスト運用を阻む“3つの壁”の乗り越え方とは?」

 セミナー詳細

昨今のエンタープライズシステム開発では、品質向上を図るために単体テストの実施が求められるようになってきました。特に銀行、保険、証券など金融システムでは単体テストの実施が必須となってきていると言われています。

しかし、実際の開発現場では単体テストがうまく運用に乗らず成果を出せていなかったり逆に工数増加につながってしまっているという状況も多いのではないでしょうか?

お客様にその原因について伺うと、単体テストの運用を妨げる3つの大きな壁が見えてきました。


1つ目の壁「単体テスト定義の壁」

 ・各担当者における単体テストの認識が異なっていることで、テスト品質にバラつきが生じ、成果が出にくい状況に陥っている。
  例:
  # 単体テストは誰が実施するべきなのか分からない。
  # 単体テストをどの単位で行えばいいのか分からない。
  # 保守開発において、どこまでをテスト範囲とすべきか分からない。

2つ目の壁「単体テスト手法の壁」

 ・ノウハウ不足による工数増加でテスト実施まで至らない。
  例:
  # どこまでテストしたらいいのか分からず、終了基準が曖昧。
  # ドライバやスタブはどう準備すればいいのか分からない。
  # データベースにアクセスするメソッドはどうやってテストを実施するのか分からない。


3つ目の壁「単体テスト運用の壁」

 ・テスト実施後のテスト資産やノウハウが活用できていない。



そこで今回は単体テスト実施におけるこの3つの大きな壁をテーマに、実際の例を交えながらその乗り越え方をご紹介いたします。また、単体テストの次のステップとして効率的なテストと品質向上を実現する継続的インテグレーション環境の構築方法についても併せてご紹介いたします。

単体テスト実施を一度諦めてしまった方、運用に乗せたいとお悩みの方必見の内容となっておりますので、是非ご参加ください!




━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆セミナー概要
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【開催日程】2014年11月7日(金)14:00~17:00 (開場:13:40)

【会場】テクマトリックス セミナールーム
    東京都港区高輪4丁目10番8号 京急第7ビル

【参費用】無料

【定員】40名(定員になり次第締め切らせていただきます。)
    ※ご同業の方の参加はご遠慮いただいております。

【講演内容】
「単体テスト運用における3つの壁とその乗り越え方」
講師:テクマトリックス株式会社 鈴木 沙緒理
概要:
多くの方が品質向上のために単体テストが必要と感じています。しかし、いざ実施に踏み出すと様々な問題に直面し、実際には運用に乗せられなかったケースも多く聞かれます。本セッションでは、単体テストの運用において直面する壁とその解決策を事例を交えながらご紹介します。

「CI環境構築によるテスト自動化がもたらす品質向上と早期リリースの実現」
講師:テクマトリックス株式会社 内田 江美
概要:
テストのさらなる効率化のためには、CI(継続的インテグレーション)環境の構築がおすすめです。しかし、何からスタートすればいいのかお悩みの方も多いのではないでしょうか? 本セッションでは、CIに関する基礎知識を初め、テストの実行をCI環境に取り入れた場合のメリットについてご紹介します。
 
 ※内容は、変更する場合がございます。あらかじめご了承ください。


2014年10月2日木曜日

ケーススタディにみるIEC 62304/ FDA GPSV対応とは

医療機器ソフトウェアの開発プロセス その最適化と効率化
~FDA、MDD、CFDA、新法(医薬品・医療機器等法)対応~


2014年11月25日の新法(医薬品・医療機器等法)の施行が少しずつ近づいて参りました。
GHSから法規制対象外のヘルスソフトウェアに関する開発ガイドラインが公表され、また、法規制対象の単体プログラム医療機器の医療機器申請に関しましても、厚労省 医療機器・体外診断薬部会などから情報が公開されつつあります。

こうした動きの中で、IEC 62304、ISO 14971対応に関する弊社へのお問い合わせも急増し、方針やスピードの違いはあれ、多くの企業様が既に対応作業を開始されています。

また、国内の薬事法改正に関わらず、欧州・米国・中国など海外に向けた医療機器ソフトウェアに関する医療機器申請でも、開発現場でのソフトウェアの内部品質、外部品質を担保する品質文書や記録とそれらに裏付けられたサマリ文書が当然必要に
なります。
それらの品質文書や記録はソフトウェア開発プロセスを構築して生み出されるものです。FDAの査察、EUのUV(非通知審査)に対応して、しっかりとプロセスを立ち上げておく必要があります。


 しかし一方で、

  「何から手を付ければいいのか分からない」

  「どのくらい大変な作業になるのか検討がつかない」

  「規格書は読んだが、具体的には何をすればいいの?」

  「自社の今の開発プロセスでは不十分なのか?」

  「ある程度規格に準拠した開発は行っているつもりだが、効率が良くない」

 などのお悩み・不明点をお持ちのご担当者様もまだまだいらっしゃるのではないでしょうか。


テクマトリックスは、FDA、MDDなどに関する専門知識とソフトウェアエンジニアリングのノウハウの両方を駆使し、お客様の課題に合わせたソリューションを提供しています。

今回は、お客様から寄せられるよくあるケースをもとに課題解決への取り組みとその効果についてご紹介します。



<ケーススタディ>
 医療機器ソフトウェアの開発プロセス その最適化と効率化


 ◆お客様の声
「FDA、MDDともに申請通過済み。しかし申請内容と実態に大きな乖離を感じている」


今回のケースでは、海外の医療機器申請は通過しているものの、法令、国際規格がソフトウェアに求めることの本質や背景への理解が不十分だったために、表面的な対応になっています。
そして、それが結果的に開発への大きな負担となり、生産性や品質にも悪影響をもたらしています。

そのため、現状を分析し、まずはFDA、MDDに申請しているソフトウェアライフサイクルプロセスへ実態を近づけなければなりません。その上でプロセスを最適化し、品質、生産性の向上につなげていく必要があります。


>このケースの詳しい内容




◆ 無料相談会 実施中!◆

テクマトリックスでは、医療機器ソフトウェアのIEC 62304(JIS T 2304)およびFDAガイドラインへの適合に向けた様々な課題について、プライベート無料相談会を開催しております。
本プライベート無料相談会では、ソフトウェアを使った医療機器の欧米薬事や、今後より一層求められるCSV、今年11月25日に施行される新法(医薬品・医療機器等法)についても、ご相談をお受けします。

IEC 62304、FDA、新法(医薬品・医療機器等法)についてお悩みをお持ちのお客様は、ぜひご検討ください。



2014年9月24日水曜日

9/11開催 「ユースケースに学ぶソフトウェア品質向上ノウハウ」セミナーレポート


9/11に開催されました開発現場に合った最適な品質向上策を実施するには?ユースケースに学ぶ 運用に乗せるソフトウェア品質向上ノウハウ」セミナーはお足元の悪い中にも関わらず、多くの方にご参加頂きご好評のうちに無事開催終了いたしました。

遠方からもご足労いただき、誠にありがとうございました。


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

セミナーにご参加いただいたお客様の声
「回帰テストがうまく回っていない理由がわかった気がします。参考にしたいと思います。」
「実例を踏まえた内容で参考になりました。」
「ステルス・アジャイルは参考になりました。できるところから改善したいです。」
「テスト駆動開発の概要が理解できました。」

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


会場の様子


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

単体テストの実施においてツールが運用にのらない、効果がでないのはなぜなのか?運用に乗せるためには、開発現場に何が不足していて何を実施する必要があったのかを過去の例を交えながら紹介しました。




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

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

実はフロー解析におけるバグの検出と修正だけでは、次回以降のプロジェクトでも同じようなバグの検出と修正を繰り返してしまいます。
「テスト工程以降にバグが流出している」
「過去と同じバグを繰り返している」
「レビューの工数が多い、指摘漏れが多い」
といった各ケースにおける原因と対策について、ご紹介しました。





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

「五月雨式の仕様変更に耐えるコーディング方法」

繰り返される仕様変更に耐えるアジャイルの開発手法「テスト駆動開発」。なぜテスト駆動開発が必要なのか?その理由と実施のために必要な環境についてご紹介しました。



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

多くの質疑応答もあり、大盛況のうちに終了する事ができました。

多くのご質問もいただき、活発な議論も

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

また、今回のご紹介させていただいたParasoft社製テストツールC++testの詳しい情報、無償体験版ダウンロードはこちら↓です。


  技術資料請求


2014年9月12日金曜日

単体テスト Genie でテストをしよう!

皆さん、単体テストしてますか? 
C#やVBなどの.NET Fromeworkのアプリケーションでは、NUnitやMSTestなどが有名ですが、dotTESTにも「単体テストGenie」という機能があります。
dotTEST の Genie を利用すると。。。
NUnit や MStest のようにコードを書く必要がなく、テストケースを作成することができます!

では、今回は、dotTEST の単体テストGenieについてご紹介します。
※Genie とは、アラジンのランプの魔人のことです。


■ 単体テストGenie
テストケースの作成には、2つの専用のビューを使用します。
単体テストGenieビュー
ビルダー 
























[単体テストGenie]ビューで、テストしたいメソッドを選択し、テストケースの入力値や期待値を[ビルダー]画面で入力していきます。

■ テストケースの作成
今回は、映画料金を計算する Chargeメソッドを例にご紹介します。

Chargeメソッドでは、入力値に「年齢」や「大学生かどうか?」など複数の引数を指定し、その結果、映画料金を返します。

【映画料金表】

一般 1,800 円
大学生 1,500 円
高校生 1,000 円
小人(3歳から中学生) 1,000円
シニア(60歳以上) 1,000円
障害者手帳をお持ちの方 1,000円


ビルダー画面は、複数のタブで構成されています。入力値(今回は、メソッドの引数)は、[入力]タブ、期待値(今回は、映画料金)は、[アサーション]タブで設定します。
















テストケースを作成するときは、同じ料金になるように、入力値を考えます。今回は年齢に着目して、60歳以上のシニア料金のパターンを考えてみましょう。



























入力値を任意の値で設定するために、「ユーザー定義値の使用」にチェックを入れ、(60,65,70,75)と60歳以上の年齢入力します。
※改行を入れると複数データを入力できます。

シニア料金の場合は、男性でも女性でも関係ないので、lady の設定だけ、true/falseを選択し、他の入力値はfalseを選択すると、8個のテストケースが作成されます。
Genieは、入力値のすべての値を組み合わせて、テストケースを作成します。今回は、年齢の4パターンと性別の2パターンを組み合わせて、8パターンとなります。

次は、期待値を入力します。
















シニアの場合は、一律1000円になります。種類を「アサート」に変更し、期待値に「1000」と入れて、生成ボタンをクリックするとテストケースが生成されます。

dotTESTは、NUnit形式のテストケースを作成してくれます。メソッド実行後の期待値をチェックするために、AreEqualメソッドを使用してます。もし映画料金が期待値と一致しない場合は、すぐに確認することができます。

■ テストの実行
では、作成したテストケースを実行してみましょう。
単体テストを実行するには、 ビルトインの[Run Tests and Check Assertions]をメニューから選択します。このテストコンフィギュレーションでは、単体テストの実行と、一緒にカバレッジも測定することができます。



■ まとめ
Genieを使うと、GUIで操作しながらテストケースを作成することができます。面倒なコードを書く必要がありません。また、テストケース内で、期待値と結果を判定しているので、結果をひと目で確認もできます。単体テストをやっていない人、まずはGenieを使って単体テストをはじめてみませんか?

テストケースを1つ1つ、Genieで作るのは、ちょっと大変じゃない?という人には、Genieで作ったテストケースを修正することで、Excelなどの外部ファイルに入力値や期待値のテストデータを定義して、テストを行うことも可能です。


















Excelを利用したテストケースの方法について弊社で作成した資料がありますので、気になる方は、Parasoft製品カスタマーセンターまでお問合せください。

Genieを使って単体テストをやってみたいという人は、dotTEST の体験版をご用意していますので、 Parasoft dotTEST 製品ページ をご確認ください。



2014年8月6日水曜日

CppUnitを手放す日

今回はCppUnitの問題をC++testでどのように解消できるかをご紹介します。

この記事は、過去にCppUnitを使用されていた方や、現在使用中のCppUnitに不満を持っており、代替のツールをご検討されている方を対象としています。

CppUnitは、ご存じの通りオープンソースのソフトウェアテストフレームワークです。
フリーで利用できるため、だれでも気軽に使うことができます。ですがその一方で不満点としてよく聞くものに次のようなものがあります。

  • テストするためにmain関数を変更したり、テスト用のプロジェクトを作成したりして、コンパイルする必要がある
  • スタブ関数を使いたいが、機能としてないため、作成して呼び出すための処理を追加する必要がある
  • 実行したテストのカバレッジを測定する機能がない
  • 実行結果が成功失敗しか分からないため、詳細なレポートを作成するのに時間がかかる

不満点を要約すると、とても面倒くさいということになります。
テストフレームワークを使わずに、自分で一からテストコード(テストドライバ・スタブ)を作成するのは気が遠くなるぐらい面倒な作業です。それを軽減するためにCppUnitを使ってテストを作成するのですが、それでもやっぱり面倒なのです。

余計な作業が多く必要ということは、それだけ開発作業の生産性・効率が下がっていることになります。場合によってはテスト作成が面倒なために、十分なテストができないということにもなりかねません。そうなると、生産性どころかソフトウェアの品質まで下がってしまいます。

テスト作成を困難にする理由のひとつは、CppUnitがテストのためのシンプルなライブラリであるということです。CppUnitはテストに必要なAPIだけを提供します。つまり、それ以外の多くの部分をテストを実施する人が実装しなければなりません。テストを行うために、テスト対象のコードとテストコードをコンパイルし、テスト用の実行モジュールを作成して実行します。
実際にやってみるとこれは結構大変で、依存関係が複雑なコードになると、テストのためのコンパイルがなかなか成功しない、という状況も発生します。
他にも、テスト対象外の関数のスタブ関数化や、テストの網羅度を確認するためにコードカバレッジを取ろうとすると、CppUnitだけでは対応することができません。そのため、別のツールを合わせて使うなどの、特別な対応が必要となります。



CppUnitを使う場合、テストの作業フローは図1のようになります。

図1.CppUnitの作業フロー

テストまでの作業量がとても多いですね。一方、不満が多くてもなかなか「では、作業量の少ない新しいツールを」とはならないのが実情です。変えられない理由の多くは、既に過去にCppUnitでテストした資産があるからです。一般的に、「新しいモノを手にするためには、既に持っているモノを手放さなければならない」とよく言われます。ただ、そうは言っても可能であれば、過去のテストを再利用する方が効率的ですし、余計なコストもかかりません。そのため、持っているモノを手放すということを軽々しく選択することはおすすめできません。既に持っているモノを持ったまま、新しいモノを手にしましょう
そんなことが可能なのでしょうか?C++testを使用することで可能なのです。
C++testを使うと、CppUnitのテストコードを何の変更もなく実行することができます。さらに、作業量の大幅な削減が可能です。C++testを使用した場合、テストの作業フローは図2のようになります。



図2.C++testの作業フロー

このようにテスト作成にかかる作業を大幅に減らすことができます。減った部分はC++testが自動で行ってくれます。そのため、開発者はテストパターンの検討やスタブ関数の作成という知的作業のみに集中できるようになります。加えて、CppUnitの課題であるコードカバレッジやレポートに関しても、C++testがしっかりサポートしますので、生産性は大幅に向上します。

C++testを使用した場合の作業フローを簡単に説明します。

  1. ツールがテストケースの雛型を生成
  2. 必要に応じて開発者がテストケースの処理を追加
  3. 必要に応じて開発者がスタブ関数の処理を追加
  4. ツールが自動でmain関数を作成し、実行モジュールを作成してテストを実行
  5. ツールが自動でテストカバレッジの計測
  6. ボタン一つでテスト結果のレポートを生成


ソフトウェアのユニットテストだけでなく、C++testではコーディングルールのチェックやフロー解析といった静的解析を行うことができます。静的解析はソースコードさえあればすぐに実行できるので、作業効率をさげることなく品質の向上が見込めます。

このように、C++testを使うことでCppUnitを使った場合よりも生産性の向上、ソフトウェア品質の向上が可能です。
現在CppUnitを使っていて、新しいツールを検討している方や、検討したいが二の足を踏んでいる方はぜひごともC++testをお試しください。
また、現在C++testを使用されており、過去にCppUnitを使っていた方はこれを機に過去の資産の再利用を検討されるのもよいのではないかと思います。

C++test体験版をご希望の方は Parasoft C++test 製品ページ へ。

2014年7月10日木曜日

「膨大なテストケース作成」と「テスト実行工数」を大幅に削減する画期的なテスト技法とは?



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

高機能化・複雑化が進むITシステムの品質確保
膨大なテストケース作成とその実行工数に悩まされていませんか?

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


例えば、金融システムに代表されるミッションクリティカルな基幹システムでは、数百から数万といった膨大な量のテストケースが作成され、テストが実施されています。
一方で、市場における競争力維持のためにリリースの短期化、開発コストへの圧力はますます強くなっている状況です。

開発現場は、このような「高品質」「短納期」「低コスト」という相互に矛盾した問題に頭を抱えているのではないでしょうか?


その解決策の1つが、テスト設計における【無駄や漏れが最少化されたテストケースの作成】【効率的なテスト実行プロセス】です。

今回は産業技術総合研究所が研究中の最新のテスト設計技法をご紹介するとともに、その技法を活用したコストに見合うテストケース生成と効率的なテスト実行を実現するテストソリューションをご紹介します。
是非、ご参加ください。



━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆セミナー概要
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【開催日程】2014年8月7日(木)13:30~17:00 (開場:13:10)

【会場】アキバプラザ 6階 セミナールーム1
    東京都千代田区神田練塀町3 富士ソフト秋葉原ビル
    http://www.fsi.co.jp/akibaplaza/cont/info/access.html


【参費用】無料

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


【講演内容】
■モデルベーストテスト技法 FOT

【講師】
独立行政法人産業技術総合研究所
セキュアシステム研究部門 大岩 寛様・北村 崇師様

【概要】
FOT は産総研が研究開発するモデルベーストのテスト分析技術、及び、テストケース自動生成技術である。モデルベースト手法により系統的なテスト分析を支援し、自動生成技術により漏れ・重複のないテストケースを低コストで作成する。
本講演では、FOTの技術概要、及び、その産業システムへの適用事例について紹介する。
   

■「テスト計画の早期立案」と「効率的なテスト実施法」
【講師】
テクマトリックス株式会社

【概要】
設計段階から始める無駄のないテストケースの作成及び、テスト自動化ツールを活用したテスト実施法のデモを含め、テスト設計からテスト実施までのテストプロセスを効率的に進める方法を紹介する。


■テクマトリックスの製品とサービスのご案内

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


【申込方法】お申し込み受付ページからお申し込みください。

2014年6月12日木曜日

テストを複数回実施したカバレッジのログをマージする

■テストを複数回実施したカバレッジのログをマージすることは可能?

はい、可能です。
C++testのテスト実行時のカバレッジのログは、簡単にマージすることが出来ます。


単体テストを複数回に分けて実施した際、テストの結果・カバレッジのログを手動でマージしていませんか?

C++testのデフォルト設定では、実施した単体テストの回数分だけテストログが分割されます。今回ご紹介する内容は、それらのログを自動でマージする方法です。
自動でログをマージできれば、1つにまとまったテスト結果レポートを効率的に作成することが出来ます。

それでは具体的な設定例をご紹介いたします。

■ログファイルについて

C++testでは、以下の2つのログファイルにテスト結果情報とカバレッジ情報を保持しています。

  • テスト結果[cpptest_results.tlog]
  • テストの成功/失敗の情報を含むログファイル

  • カバレッジ[cpptest_results.clog]
  • テスト実行時のソースコードのカバレッジの情報を含むログファイル
     
これら2つのログファイルはテスト実行時に追記する形式として生成されます。
C++testデフォルトの設定では、テスト毎に2つのログファイルを削除する設定となっているため、毎回書き換えられているように見えます。
そのため、2つのログファイル(cpptest_results.tlog、cpptest_results.clog)を削除せず追記するように設定すれば、ログファイルのマージが可能になります。

■設定(テストコンフィギュレーション)の変更

以下の方法で、ログファイルを削除する設定を変更します。
単体テスト、及びアプリケーションモニタリング 用のテストコンフィギュレーションのダイアログより、処理フローを参照します。
    [実行]タブ → [全般]タブ → [テスト実行フロー]右の[編集]ボタンの処理フロー
処理フロー内に以下のような"RemoveFileStep"といったログファイルを削除する処理が記載されています。


このファイルを削除する処理を処理フローから削除することで、テスト結果とカバレッジのログをテスト毎に追加することができます。

■活用例

以下にカバレッジのマージの活用例をご紹介します

◆単体テストのカバレッジレポートをマージする
通常、上記のカバレッジをマージする設定を行わずに複数のテストを行った場合、GUI上では、カバレッジはマージされますが、レポートの出力結果は最後に実行したテスト結果のみになります。
  • テストケース1(calcFare関数のテスト)を実行し、GUI上でカバレッジを確認します
  • テストケース2(getFareInt関数のテスト)を実行し、1同様にカバレッジを確認します
  • GUI上ではテストケース1の結果も反映されカバレッジがマージされています
  • ですが、上記の実行結果のレポートを見てみますと
  • 結果がマージされておらず、最後の実行結果だけレポートされていることがわかります
  • ここで、カバレッジをマージする設定を実施後、再度同様にテストを実行し、レポートを出力すると
  • 上記のように、レポートもマージされたものが出力できます

◆アプリケーションモニタリングの結果をマージする
アプリケーションモニタリング の機能を使うことで、操作別のカバレッジの集計を取ることが出来ます。
例えば、以下のよう操作を実施したとします。
  1. アプリケーションを動作させ、操作1を実行
    →操作1実行時のカバレッジ情報を取得
  2. アプリケーションを動作させ、操作2を実行
    →操作2実行時のカバレッジ情報を取得
このように、操作1を実行した時のカバレッジと操作2を実行した時のカバレッジ情報をアプリケーションモニタリング機能で取得し、カバレッジの結果をマージすることで、最終的には実行された操作の分だけ、tlog、clogに結果が追記され、集計されたカバレッジを見ることができます。

■まとめ

いかかでしたでしょうか?
単体テストの結果ログファイルをマージすることで、複数の実行結果やカバレッジレポートを一つにまとめることができました。
実施するテストの内容によっては、一括で実行できない場合もありますので、そのようなシーンでもC++testを効率的にご活用いただけると思います。

今回ご紹介した内容については、こちらのユーザーページFAQで設定ファイル等のサンプルを公開する予定です。
その他にもユーザページでは C++test の便利な使い方をご紹介しています。是非、ご活用ください。

2014年5月13日火曜日

ESEC2014 出展!

今年も昨年に引き続き、東京ビッグサイトで開催される「組込みシステム開発技術展(ESEC)」に出展します。

第17回 組込みシステム開発技術展(ESEC 2014)
会期:2014.05.14(水)/15(木)/16(金) 10:00~18:00(16日(金)のみ17:00終了)
会場:東京ビッグサイト


2014年5月12日月曜日

医療機器ソフトウェアセミナー「2014年にみる医療機器ソフトウェアの規制と現状、および医療機器ソフトウェアのセキュリティ対策」開催レポート

4/14にソラシティカンファレンスセンターにて開催されました医療機器ソフトウェアセミナー
「2014年にみる医療機器ソフトウェアの規制と現状、および医療機器ソフトウェアのセキュリティ対策」は
多くのお客様にご来場いただき、盛況のうちに終了いたしました。

遠方からもご足労いただき、誠にありがとうございました。

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



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

電子情報技術産業協会 医療用ソフトウェア専門委員会

平井 正明様


これまでの薬事法に代わり、2014年に施行される医薬品医療機器等法による医療機器ソフトウェアの規制・規格の動向について、ご紹介していただきました。


平井様によるセッションの様子


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

テクマトリックスでは、医療機器ソフトウェアに関するセキュリティ対策として「CWE/SANS のセキュリティ上最も危険なソフトウェアバグ トップ 25」による対策例と、C++testによるセキュリティ対策のデモンストレーションを行いました。

医療機器ソフトウェアに関係するセキュリティ対策

Parasoft社のC++testによるセキュリティ対策デモンストレーション

実機を使ったバッファオーバーフローの再現

テクマトリックスでは、医療機器ソフトウェアについて、IEC およびFDA適合対応に関係する 無料相談会を開催しております。ソフトウェア開発から申請までの規格適合全般について、ご相談を承りますので、お気軽にお問い合わせください。

【相談例】
ISO 14971とIEC 62304の関係について知りたい
FDAで求められるテストカバレッジが知りたい
IEC 62304適合を目指すが何から手を付けて良いかわからない
テクマトリックスが提供するコンサルティングサービス、教育サービスについて詳しく知りたい
IEC 62304対応の文書化はどこまで必要か知りたい




今回のご紹介させていただいたParasoft社製テストツールC++testの詳しい情報、無償体験版ダウンロードはこちら↓です。