このブログについて

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

2016年8月4日木曜日

dotTEST の フロー解析

先月リリースされた dotTEST DTP 10.2 では、フロー解析 がパワーアップし、『配列の範囲外アクセス』 やスレッド処理で発生しがちな、『デッドロック』『レースコンディション』の問題を検知できるようになりました。
今回は、新しいルールのご紹介の前に dotTEST のフロー解析をご紹介します。


フロー解析

フロー解析とは、プログラムを実行せずにソースコードを検証する静的解析です。
単体テストのようにテストデータを用意する必要なく、アプリケーションに潜むクリティカルな問題を発見することができます。
dotTEST には、フロー解析以外にも コーディングスタンダードがあります。これは、パターンマッチングでコードを検証するのに対してフロー解析は、クラスやメソッドをまたがった実行パスを解析し、特定の条件で発生するアプリケーションの問題を発見できます。

アプリケーションを動作させず問題を検出できるため、テスト環境での実行が難しい処理想定していなかった例外パターンなどの問題を見つけることができます。


NullReferenceException の問題

『NullReferenceException』の問題を例に、問題を見つけるまでの流れを説明します。
まず、変数からのメソッド呼び出しを 怪しいポイントとみなします。
そして、その怪しいポイントを通る実行パスを抽出し、メソッド呼び出しの変数に null が設定されている場合に、問題をレポートします。

では、実際のコードを例に説明いたします。

NullReferenceException が発生するコード:
public EngineInfo BadGetEngineInfo()
{
    EngineInfo engine = null; 

    // 条件により engine に値を設定 

    return engine;
}
public void NullReferenceFromMethodReturnValue()
{
    var engine = BadGetEngineInfo(); 
    string str = engine.ToString(); //怪しいポイント
    Console.WriteLine(str); 
}

このサンプルコードでは、BadGetEngineInfo メソッドは特定の条件を満たさない場合に、null を返してしまいます。
この状態で engine.ToString() が実行されると、NullReferenceException が発生します。


dotTESTのイメージ:







NullReferenceException が発生する原因は、今回の例だけでなく、
  • 条件によってオブジェクトに値が入らない
  • メソッドのパラメータが null
  • コレクションや配列のオブジェクトが null
などがあり、dotTEST は、これらのパターンも検出することができます!

フロー解析の種類

dotTEST DTP 10.2 では、NullReferenceExceptionの問題以外にも
  • リソースリーク
  • InvalidOperationException
  • SQLインジェクション
  • クロスサイトスクリプティング(XSS)
  • 配列の境界外アクセス new
  • デッドロック new
  • レースコンディション new

などのクリティカルな問題を見つけることができます。


ぜひこの機会に、dotTEST のフロー解析をお試し頂き、品質の高いアプリケーションの開発に取り組んでください。


dotTESTの体験版はこちらから



次回は、新たに検出できるようになった『デッドロック』や『レースコンディション』の問題をご紹介します!

2016年7月21日木曜日

RedmineとParasoft DTPでプロジェクト進捗報告を効率化!

■プロジェクト管理とRedmine


あなたがソフトウェア開発に携わっているのならば、ほとんどの場合何かしらのプロジェクトに参加して作業を行っていると思います。そしてプロジェクトでは、タスク管理、進捗管理、障害(バグ)管理、品質管理など、様々な管理が行われていると思います。
これらの管理のため、近年RedmineというWebベースのプロジェクト管理ツールが人気を博しています。Redmineは、タスクや障害などをチケットとして管理できる他、構成管理リポジトリとの連携、作業時間の記録、ガントチャートの表示など、ソフトウェア開発のプロジェクト管理に必要な一通りの機能を有しています。

■プロジェクト進捗報告


ところで、プロジェクトの進行中、顧客や社内向けにプロジェクトの進捗報告を行います。進捗報告のためにデータを集めたり、体裁が決められた進捗報告書を作成することはなかなか大変な作業かと思います。Redmineは進捗報告に必要なデータを集めるための手助けになりますが、進捗報告書に記載するグラフを作成してくれるとは限りません。この場合、データをエクスポートして表計算ソフトで集計するなど、報告書の作成の度に手間がかかってしまいます。
ここで、Parasoft Development Testing Platform (Parasoft DTP) を使用すると、タスクや障害などの情報をグラフ化し、ソースコードの品質情報と共に表示することができます。

■進捗報告用のグラフの作成


Parasoft DTPはソフトウェアの開発とテストのためのプラットフォームです。Parasoft DTPの基本機能としては、Parasoft社の静的解析やコードメトリクス、テストの結果をグラフ化する機能があります。これに加えてサードパーティ製のツールやシステムからデータを取得し、任意のグラフを作成することができます。
Redmineのチケットの情報をグラフ化する場合は、まずRedmineのREST APIを利用してチケットの情報を収集します。次に収集した情報を集計するのですが、例えば週ごとにチケットのステータス別の件数を集計すると、タスクや障害のステータスの推移を示すことができ、タスクを消化できているかを確認できます。


また別の方法として、週ごとに新規で作成されたチケット数と完了したチケット数を集計すると、タスクや障害の発生数と消化数の推移を表示できます。単純に数を棒グラフにするだけでなく、その差異を折れ線グラフとして重ねて表示することで増減の推移を確認したり、期間内における差異の平均を求めることでプロジェクトが収束に向かっているかどうかを確認することもできます。


視点を変えてチケットを担当者別で集計すると、誰に作業が集中しているかを把握できます。チケットへの登録方法によって、障害発生の原因となったモジュール別に障害件数を表示するなど、報告に必要なグラフを必要なタイミングで自動的に作成し、進捗報告書に添付するグラフとして利用できます。


1つの画面の中に、静的解析や動的テストの結果に加えてチケットの情報も表示することで、プロジェクトの現状の品質と進捗が同時に把握できるようになり、プロジェクトの分析に役立ちます。さらに、ソースコードのメトリクスと工数の情報を掛け合わせると、生産性をも同時にレポートすることができます。


■まとめ


いかがでしたでしょうか。プロジェクト管理で人気のあるRedmineとParasoft DTPを組み合わせることで、顧客や社内で要求されるプロジェクト進捗報告書を作成が容易になることがお分かりいただけたと思います。
最後に、Parasoft DTPはこちらのサイトで詳しく紹介しております。また無償で2週間ご評価いただけますので、ぜひご利用ください。

2016年7月20日水曜日

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 の体験版をご用意しています。ご興味がある方は、こちらからダウンロードしてお試しください。

2016年6月20日月曜日

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

並行プロジェクト数20以上、頻発する仕様変更の中で開発効率2倍/早期バグ検出率20%向上に挑戦   その立役者が語る、不変の開発・テストプロセス改革手法


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

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


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

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

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


 参加申込み


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

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

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

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

【参加費用】無料

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

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

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

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


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

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


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

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


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


 参加申込み




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



2016年6月13日月曜日

テストケースのコーディングが不要! 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 体験版ダウンロードは ↓ こちら ↓です。


最新版 C++test 体験版ダウンロード

2016年5月11日水曜日

ソースコードに技術的負債を溜め込んでいませんか?


“とりあえず動く”コード

 納期間際になって不具合が見つかった状況を考えてみます。選択肢は2つあります。一つは設計から見直し、コードを変更してテストも行うことですが、納期に間に合わないかもしれません。

 もう一つはとりあえず不具合を解消するよう深く考えずにソースコードを変更することです。納期に間に合ってプログラムも正常に動いている模様ですが、その後の変更時に影響範囲が大きかったりソースコードの意味が分からなかったりして、不具合の修正や機能追加が大変になる、あるいはコードをいじれない、という事態が待ち受けています。

 あなたのプロジェクトは2つ目のような事態に陥ってはいませんか?

技術的負債とは?

 2つ目の選択肢のような「とりあえず動くが、後から変更が大変なコード」は「技術的負債」と呼ばれています。技術的負債は単にソースコードが汚くて読みにくいコードだけでなく、次のようなコードも当てはまります。
  • テストケースが作られていないコード
  • 設計を推敲せずに書かれたコード
  • 別のところからコード断片をコピー&ペーストしたコード
 これらが溜まってくると、コードを修正して良いのかどうか、何のためのコードなのかが分からなくなってきます。その結果、次のような問題に発展していきます。
  • 変更に時間がかかる
  • テスト工数が膨らむ
  • リリースが遅れる
  • リリース後も障害が起きる
 このような問題に発展する前に、リリースまでに技術的負債を極力減らしておく努力が必要です。作られてしまった技術的負債を減らす方法は唯一、リファクタリングを行い、地道にコードをきれいにすることです。しかしリファクタリングを行うにも工数が必要ですから、技術的負債の量や、技術的負債に対処しなかった場合のビジネス上の影響、プロジェクトの進捗などといったものとのバランスを見て行わなければなりません。

技術的負債の計測と可視化

 では技術的負債の量はどのように求めたら良いでしょうか? 技術的負債の構成要素としては、コーディング規約違反の件数、メトリクスの超過/過少の量、単体テストの失敗件数、テストで未到達なコードの量、等が考えられます。一例として、SQALEメソッドにおいて技術的負債の計算方法が例示されていますので、参考になると思います。

 技術的負債を定義したら、次は技術的負債の構成要素を計測します。計測方法は要素によって異なりますが、コードレビュー時に確認したり、単体テストを実行したり、静的解析や構造解析のツールを利用することが一般的です。弊社取扱製品であるParasoft JtestParasoft dotTEST, Parasoft C++testといったテストツールももちろん利用できます。

 最後に、各要素から技術的負債を計算してプロジェクトメンバーに提示します。先程例として挙げたSQALEメソッドに従うと、技術的負債は単純な四則演算で計算できますので、表計算ソフトでも計算できます。あるいは弊社取扱製品であるParasoft Development Testing Platform (Parasoft DTP) を使用すると、技術的負債を計算する手段が予め提供されている他、技術的負債がモジュールや品質特性ごとに計算され、かつWebブラウザで確認できます。WebブラウザでParasoft DTPにアクセスすれば、下図のようにどこにどれくらいの技術的負債が溜まっているかをいつでも誰でも確認できるため、技術的負債を減らすためにリファクタリングを開始する動機付けが可能になります。


 また、継続的インテグレーションの中に技術的負債の計測を組込むことで、現在のプロジェクトの技術的負債の状況をリアルタイムに近い形で確認することが可能になります。技術的負債が増加していることをリアルタイムに把握できれば、リーダーの方がリファクタリングを開始するよう指示して早期にプロジェクトを軌道修正することも容易に可能になります。

技術的負債を計測しませんか?

 いかがでしたでしょうか。技術的負債とは何か、技術的負債が溜まるとどうなるか、技術的負債を算出して可視化する方法をご説明いたしました。読者の方が技術的負債を返済し、将来の変更の労力を少しでも減らすことができればと思います。

 最後に、上記で紹介しました弊社取扱製品はすべて2週間無償でご評価いただけますので、購入を検討されたい方は下記からぜひお試しください。またParasoft DTPのユーザー様向けに、技術的負債を計算するためのプラグインも提供しておりますので、ぜひご利用ください。



Parasoft DTPプラグイン提供ページ