フェリカネットワークス株式会社様

携帯電話への実装に要求されるソフト品質

• モバイルFeliCaは、携帯電話向けに開発された非接触ICカード技術です。携帯電話をリーダ/ライタにかざすだけで、利用者認証や電子決済などが可能となり、今後様々なサービスへの展開が期待されています。
  モバイルFeliCaは、国内すべての携帯電話キャリア（事業者）、メーカーの端末への実装を想定しているため、実装される端末は膨大な数が予想されます。万一、組み込みソフトに不具合があれば、多くの利用者への影響はもちろんのこと、不具合対応にかかる損失は、膨大なものになります。
  そのため、モバイルFeliCaの組み込みソフトには、厳しい品質保証が求められています。これが、フェリカネットワークス開発部が、モジュール単体テスト、パスカバレッジテストに着目して、ソフト品質の検証を行った理由の1つです。
• 

マルチプラットフォームへの実装とガイオツール選択のポイント

• モバイルFeliCaに使用されるマイコンは、品種を限定しておらず、要求に応じて様々なプラットフォームに対応する必要があります。実装するソフトウエアは汎用性の高いC言語で記述されていますが、組み込みマイコンの上で必ず動作するとは限りません。各マイコンの上で、単体テストを含めたソフト検証を行うことが求められます。
  モジュール単体テストを行うツールとして、ガイオの「カバレッジマスター」を選択した理由の1つが、このマルチプラットフォームへの対応です。「カバレッジマスター」は多くのCPUをサポートしたマイコンシミュレータ（ISS）をテストエンジンとして使用しており、テストデータ資産は全てのマイコンに共通に使用できます。
  モジュール単体テストは、テストデータを資産化して、以降の開発に反復的に利用することが、ソフト品質を保つためのポイントとなるため、ここが、ガイオのツールをご選択頂いた大きな理由となっています。
• 

実機による総合テストでは発見できない例外系のバグ

• ソフトウエアのバグは、正常系と例外系に大別できます。正常系動作のバグについては表面的なものが多く、開発の過程でいずれは発見されますが、例外系のバグは、例外条件が重なった時のみに起こるものが多く、総合的なテストでは発見できないものがあります。例えば、C言語による開発において代表的なバグの1つに、NULLポインタアクセスがあります。通常ではNULLになることはない変数であっても、例えばハードウエアが故障した際にNULLになるものであれば、正常系の総合試験では発見できません。つまり、これを検証しなければ、ハードウエアの一部が故障しただけで、ハングアップしてしまう製品が出来てしまいます。
• 

開発の上流で単体テストを徹底全体の検証プロセスを改善

• 「ホワイトボックステスト」であるモジュール単体テストは、正常・異常と言ったシステムの事情に依存することなく、網羅的に条件をテストするものです。上記のNULLケースも1つのテストケースとして扱うことで、例外的なハード故障に対する回避動作を、予めソフトウエアに組み込んでおくことができるのです。
  フェリカネットワークス開発部は、開発の上流で「モジュール単体テスト」を徹底することで、潜在的なバグとなりやすい例外系を含めたデバッグを前倒しして、後半の総合テストを補完できるような検証プロセスの確立を目指しています。

テストデータ作成基準を設定担当者間の個人差を縮小

• では、モジュール単体テストツールの運用方法について、話を進めたいと思います。
  フェリカネットワークス開発部は、カバレッジマスターの採用を決めた後、開発チーム全員に対して、モジュール単体テストの運用基準を作りました。
  せっかくツールを採用しても、「ツールを配って、開発者個人の基準でテストを実施する」と言った運用では、ツールの使い方に個人差が大きく、最終的なソフトの品質保証基準が異なってしまうからです。
  そこで、例えば、条件分岐には少なくとも「最大値・最小値・しきい値」の3つのケースを設定する、と言った、関数に対するテストケースの決め方に基準を設け、各担当者によるテスト項目を標準化しています。

網羅性を意識したテストで開発者自身がソースコードを磨く

• フェリカネットワークス開発部での運用の特徴は、モジュール単体テストを、開発者自身が行っていることです。設計した関数に対して、開発者自身が「網羅性」を意識したテストデータを作ることで、自分の書いたソースコードのレビューを行うきっかけとなり、テストデータ作成時に、ソースに潜むバグを見つけることが多数あります。特に、カバレッジマスターの「カバレッジビュー」（下図）を使用して、各テストケースによるソースコード上の実行経路を見直すことで、容易には気が付かないif文条件のしきい値（TRUE/FALSEの境目）の間違いなどを検証することで、ソースコードの信頼性を高める結果となっています。
  第三者が機械的に単体テストを行い、結果だけを開発者にフィードバックしてソースを修正させる運用に比較すると、フェリカネットワークス開発部の「開発プロセスに組み込まれた」開発者自身による単体テストは、その何倍もの効果を上げているのです。
• 

単体テストの事例データ

• この開発プロジェクトで開発したソフトウエアとテストデータの概要は、以下の通りです。
  
  ・マイコン:RISC系/CISC系
  ・オブジェクトコードサイズ:50kバイト
  ・評価関数の数:850
  ・テストケース数:7500（約9ケース/関数）
  
  テストデータは、if文、switch文などの条件分岐に着目して、関数に含まれる分岐条件に「最小値、最大値、しきい値」の3ケースを設定しています。平均として、１関数当たり9ケース程度のテストデータを設定しています。
  カバレッジの基準については、C0（ソース行を少なくとも1回は実行しているか）の網羅率を計測し、同時に条件分岐については上で述べた3ケースの期待値が正しいことを基準としています。
  評価関数から呼び出されるサブ関数に関しては、すべて「カバレッジマスター」のSTUB機能を使用して置換しており、関数のネストには入らず、評価対象の関数の中のみで閉じたテストを行っています。

事前試行テストと一斉テストの2段階に分けたテストスケジュール

• このプロジェクトの単体テストは、2段階に分けて行われました。最初の段階では、STUBの設定方法などに基準を作成する目的で、事前の試行テストを行い、テスト方法を決定したあとで、一斉にテスト実行を行っています。
  テストにかかった人数と時間は、以下の通りです。テスト担当者は、他の業務との兼任でなく、フルタイムでテストを行っています。
  
  1. 事前試行テスト:5名5日間
  2. 一斉テスト実行:7名15日間

実行結果と導入効果

• このプロジェクトでの単体テスト結果は以下の通りです。
  
  ・C0カバレッジ網羅率:99.9%
  ・分岐条件（3ケース）のテスト:100%
  
  C0カバレッジの網羅率は100%にはならず、若干のコードを残しています。フェリカネットワークス開発部は、評価漏れになっているソースを調査しています。これは、switch文の default ケースによるもので、コードのロジックから、defaultに当たるデータが設定できないものでした。このように原因をすべて解析把握したことで、実質100%のC0カバレッジを達成していると言えます。
  この単体テストの実施により、結合テストを行う前に発見することのできた不具合件数は以下の通りです。
  
  ・不具合件数90件（開発レビュー時のものも含む）
  
  フェリカネットワークス開発部は、この不具合の原因をデータベース化し、要因の分類などを分析しています。多くは、例外条件に相当する部分での不具合であり、結合テストでは見つけられない可能性が高いものも多く含まれていることが分かっています。

将来に向けての課題

• 今回の開発プロジェクトでは、「カバレッジマスター」を導入して、マルチプラットフォームに対応したモジュール単体テストの基盤を確立することと、テストデータを資産化することが目標でしたが、これらは達成できました。
  今後の大きな課題の1つが、今回作成した、異常系のチェックが可能な貴重なテストデータ資産を、今後の開発にどのように活かすかです。テスト工程の「自動化」など、効率的な運用により、ソフト品質を保った開発を行うことが次の目標となります。もう1つの課題は、テストデータの管理方法です。テストデータを資産として管理することは、ソフト品質を保つための条件の一つとなります。
  ガイオには、これらの機能のアップデートを含めた検討課題を頂いています。

さいごに

• 今回は、ガイオのモジュール単体・カバレッジツールをご採用頂き、短期間で成果を上げることができた事例を紹介いたしました。今後も貴重なご意見を頂きながら、製品の改良に努めて参ります。（画像：フェリカネットワークス（株） 開発部のみなさま）
•