平成30年秋期試験午後問題 問8
問8 情報システム開発
⇱問題PDF
継続的インテグレーションに関する次の記述を読んで，設問1～4に答えよ。
継続的インテグレーションに関する次の記述を読んで，設問1～4に答えよ。
広告
C社は，会員間で物品の売買ができるサービス(以下，フリマサービスという)を提供する会社である。出品したい商品の写真をスマートフォンやタブレットで撮影して簡単に出品できることが人気を呼び，C社のフリマサービスには，約1,000万人の会員が登録している。
C社には，サービス部と開発部がある。サービス部では，フリマサービスに関する会員からの問合せ・クレーム・改善要望の対応を行っている。開発部は，フリマサービスを利用するためのスマートフォン用アプリケーション(以下，Xという)，タブレット用アプリケーション(以下，Yという)，及びサーバ側アプリケーション(以下，Zという)について，開発から運用までを担当している。
競合のW社が新機能を次々にリリースして会員数を増加させていることを受け，C社でも新機能を早くリリースすることを目的に，開発プロセスの改善を行うことになった。開発プロセスの改善は，開発部のD君が担当することになった。
〔課題のヒアリング〕
D君は，開発部とサービス部に現状の開発プロセスの課題をヒアリングした。
D君は，既存機能に対するテストを含めたテストの効率向上及び段階的な機能追加を実現するために，フリマサービスの開発プロジェクトに継続的インテグレーション(以下，CIという)を導入することにした。CIとは，開発者がソースコードの変更を頻繁にリポジトリに登録(以下，チェックインという)して，ビルドとテストを定期的に実行する手法であり，aに採用されている。CIの主な目的はb，c及びリリースまでの時間の短縮である。
D君は，開発用サーバにリポジトリとCIツールをインストールし，図1に記載のワークフローとアクティビティを設定した。D君が設定したワークフローでは，リポジトリからソースコードを取得し，コーディング規約への準拠チェックとステップ数のカウントの後に，各アプリケーションのビルドと追加・変更箇所に対する単体テストを行い，テストサーバへ配備して，全アプリケーションを対象とするリグレッションテストを実行する。
またD君は，このワークフローを2時間ごとに実行するように設定し，各アクティビティの実行結果は正常・異常にかかわらずX，Y，Zの担当チームメンバ全員に電子メール(以下，メールという)で送信するように設定した。
なお，ワークフロー内のアクティビティは，前のアクティビティが全て正常終了した場合だけ，次のアクティビティが実行できるようにした。
〔テストプログラムの作成〕
D君は，単体テストで利用するテストプログラムを作成した。テスト対象のプログラムとテストプログラムの例を図2に示す。テスト対象のプログラムである checkTime は，時と分を示す二つの整数値を引数 hour と mm で受け取り，hour が0以上24未満の値かつ mm が0以上60未満の値であったら true を返し，それ以外の値であったら false を返すプログラムである。一方，テストプログラムである test_checkTime は，境界値テストの考え方に基づき，6種類の境界値に対してそれぞれ checkTime を呼び出し，全ての呼出しで仕様どおりの値を返したら true を，それ以外なら false を返すプログラムである。
また，D君はこれまで手作業で行っていたリグレッションテストについてもCIツールで自動実行できるように，テストプログラムを作成した。
なお，新機能のリリース後には，新機能の単体テストで用いたテストプログラムは，リグレッションテストのテストプログラムとして再利用することにした。
〔CIの試行〕
次にD君は，フリマサービスのアプリケーションの全てのソースコードをリポジトリに移行し，CIの試行を開始した。試行開始から1か月後，D君の設定したCIツールは問題なく動作していたが，開発部のメンバから次の3点を指摘された。
C社には，サービス部と開発部がある。サービス部では，フリマサービスに関する会員からの問合せ・クレーム・改善要望の対応を行っている。開発部は，フリマサービスを利用するためのスマートフォン用アプリケーション(以下，Xという)，タブレット用アプリケーション(以下，Yという)，及びサーバ側アプリケーション(以下，Zという)について，開発から運用までを担当している。
競合のW社が新機能を次々にリリースして会員数を増加させていることを受け，C社でも新機能を早くリリースすることを目的に，開発プロセスの改善を行うことになった。開発プロセスの改善は，開発部のD君が担当することになった。
〔課題のヒアリング〕
D君は，開発部とサービス部に現状の開発プロセスの課題をヒアリングした。
- 開発部:
- リリースするたびに，追加・変更した機能とは直接関係しない既存機能で障害が発生しており，会員からクレームが多数出ている。機能追加・機能変更に伴い，設計工程では既存機能に対する影響調査を，テスト工程ではテストの強化を行っている。しかし，①既存機能に対する影響調査とテストを網羅的に行うことは，限られた工数では難しい。
- サービス部:
- 会員からのクレームや改善要望は日々記録しているが，現在の開発サイクルでは改善要望の対応に最大6か月掛かる。改善要望をまとめて大規模に機能追加する開発方法から，短いサイクルで段階的に機能追加する開発方法に変更してほしい。
D君は，既存機能に対するテストを含めたテストの効率向上及び段階的な機能追加を実現するために，フリマサービスの開発プロジェクトに継続的インテグレーション(以下，CIという)を導入することにした。CIとは，開発者がソースコードの変更を頻繁にリポジトリに登録(以下，チェックインという)して，ビルドとテストを定期的に実行する手法であり，aに採用されている。CIの主な目的はb，c及びリリースまでの時間の短縮である。
D君は，開発用サーバにリポジトリとCIツールをインストールし，図1に記載のワークフローとアクティビティを設定した。D君が設定したワークフローでは，リポジトリからソースコードを取得し，コーディング規約への準拠チェックとステップ数のカウントの後に，各アプリケーションのビルドと追加・変更箇所に対する単体テストを行い，テストサーバへ配備して，全アプリケーションを対象とするリグレッションテストを実行する。
またD君は，このワークフローを2時間ごとに実行するように設定し，各アクティビティの実行結果は正常・異常にかかわらずX，Y，Zの担当チームメンバ全員に電子メール(以下，メールという)で送信するように設定した。
なお，ワークフロー内のアクティビティは，前のアクティビティが全て正常終了した場合だけ，次のアクティビティが実行できるようにした。
D君は，単体テストで利用するテストプログラムを作成した。テスト対象のプログラムとテストプログラムの例を図2に示す。テスト対象のプログラムである checkTime は，時と分を示す二つの整数値を引数 hour と mm で受け取り，hour が0以上24未満の値かつ mm が0以上60未満の値であったら true を返し，それ以外の値であったら false を返すプログラムである。一方，テストプログラムである test_checkTime は，境界値テストの考え方に基づき，6種類の境界値に対してそれぞれ checkTime を呼び出し，全ての呼出しで仕様どおりの値を返したら true を，それ以外なら false を返すプログラムである。
また，D君はこれまで手作業で行っていたリグレッションテストについてもCIツールで自動実行できるように，テストプログラムを作成した。
なお，新機能のリリース後には，新機能の単体テストで用いたテストプログラムは，リグレッションテストのテストプログラムとして再利用することにした。
次にD君は，フリマサービスのアプリケーションの全てのソースコードをリポジトリに移行し，CIの試行を開始した。試行開始から1か月後，D君の設定したCIツールは問題なく動作していたが，開発部のメンバから次の3点を指摘された。
- 指摘1:
- 一つの要求を実現するために必要なソースコードの変更は多岐にわたるので，チェックインは1週間に1回程度行っている。ワークフローは2時間ごとに動作するように設定されているが，1週間に1度で十分である。
- 指摘2:
- Yの単体テストでエラーが検出されていたが，CIツールから送信されるメールが非常に多く，Yを担当するチームはエラーに気付かず，1日放置されていた。②開発者がエラーに気付くように，CIツールから送信されるメールを限定してほしい。
- 指摘3:
- Xのビルドでエラーが検出され，単体テストまでワークフローが流れないことが多い。このため，Zを担当するチームでは，開発者の開発PC上でCIツールと同じテストケースを実行しており，③CIの導入効果が出ていない。
広告
設問1
本文中のa～cに入れる適切な字句を解答群の中から選び，記号で答えよ。
a，b，c に関する解答群
- ウォーターフォールモデル
- エクストリームプログラミング
- 設計の曖昧性の排除
- ソフトウェア品質の向上
- バグの早期発見
- プロトタイピングモデル
- 網羅的なテストケースの作成
- 要件定義と設計の期間短縮
解答例・解答の要点
a：イ
b：エ ※順不同
c：オ ※順不同
b：エ ※順不同
c：オ ※順不同
解説
継続的インテグレーション(CI:Continuous Integration)は、システムのビルド、テストの実行を自動化し、短いサイクルで継続的に行うことで品質改善や納期短縮を図る手法です。次のような効果が期待できます。- 継続的に「出荷できる状態」にできる。
- 新しく追加されたコードが問題既存のバグを引き起こしていても、早期に検知できる。
- 問題に早期に対処することで継続的に出荷可能な状態を保つことができる。
- 動作環境も含め、継続的インテグレーションできるため、自動テストやアジャイル型開発の基盤の一つとなる。
〔aについて〕
文脈からaには開発手法のいずれかが入ると判断できます。選択肢には、ウォーターフォールモデル、エクストリームプログラミング、プロトタイピングモデルのどれかから選ぶことになりますが、このうちCIを採用しているのはエクストリームプログラミング(XP)です。
∴a＝イ：エクストリームプログラミング
〔b，cについて〕
選択肢からCIの主な目的を2つ選びます。
1つ目は、バグの早期発見です。CIを採用するとテストの頻度が上がるため、新しく追加したコードのバグや、機能追加により発生した既存機能のバグを早期に検出できます。
2つ目は、ソフトウェア品質の向上です。CIを使用することで、既存機能も含めた網羅的なテストが自動で行われるようになります。テスト工程の属人性が排除されることにより、テスト品質が一定となり、常に安定した品質のソフトウェアをリリースすることが可能になります。
∴b＝エ：ソフトウェア品質の向上（※順不同）
c＝オ：バグの早期発見（※順不同）
広告
設問2
本文中の下線①について，(1)，(2)に答えよ。
- 既存機能に対するテストを行うために必要なCIツールのアクティビティを，図1中の字句を用いて答えよ。
- 既存機能に対するテストについて，設定したテストケース数の妥当性を評価するために考慮すべき値を解答群の中から選び，記号で答えよ。
解答群
- 各アプリケーションのステップ数
- 設計書の変更ページ数
- 対応する改善要望数
- 追加機能のステップ数
解答例・解答の要点
- リグレッションテスト
- ア
解説
- システム／ソフトウェアに変更を加えた際に、その変更によって以前まで正常に動作していた既存機能に不具合や影響が出ていないかを検証するテストを、リグレッションテストといいます。これは、午前問題でも頻出の用語です。
リグレッションテストは、退行テスト・回帰テスト・レグレッションテストとも呼ばれますが、「図1中の字句を用いて答えよ」という指定があるため、リグレッションテストが正解となります。
∴リグレッションテスト - "既存機能に対するテスト"では、機能変更・機能追加された部分だけでなく、追加・変更された機能とは直接関係ない部分も含めて網羅的に再テストを実施します。当然ですが、アプリケーションの規模が大きくなれば、それだけテストしなければいけない部分も増えるため、テストケース数は増加します。アプリケーションの規模はステップ数で表されますから、"既存機能に対するテスト"のテストケース数は、アプリケーションのステップ数と密接な関連があります。
ステップ数に対するテストケース数をテスト密度といいます。テスト密度は、テストケース数を設定する際の参考値や、テストの十分性評価等に使用できます。IPAの「ソフトウェア開発データ白書」等の資料では、テスト密度の統計が公表されているため、初めてCIツールを導入する場合でも、これらを参考にテストケースの数が妥当であるかどうかを評価することができます。
したがって、テストケース数の妥当性を評価するために考慮すべき値は、アプリケーションのステップ数になります。他の選択肢は、追加・変更された部分の大きさと関連する値ばかりなので誤りです。
∴ア：アプリケーションのステップ数
広告
設問3
図2中のdに入れる適切な字句を答えよ。
解答例・解答の要点
d：false
解説
〔dについて〕図2のプログラム test_checkTime は、プログラム checkTime が正しく動作しているかを確認するためのテストプログラムです。6つの checkTime が、すべて正しい結果を返したときに true を、そうでなければ false を返す仕様になっています。
また、本文中のプログラム checkTime の動作の説明を読むと「hour が0以上24未満の値かつ min が0以上60未満の値であったら true を返し、それ以外の値であったら false を返す」と記載されています。
dの前の checkTime は「checkTime(24, 0)」となっており、hourが24、minが0です。この引数で checkTime を呼び出した場合、「hour が0以上24未満の値」をいう条件式を満たさないので、戻り値として false を返すのが正しい動作です。
したがってdには false が入ります。
∴d＝false
広告
設問4
〔CIの試行〕について，(1)～(3)に答えよ。
解答群
- 改善要望に対応したソースコードから随時チェックインする。
- 一つの要求を細かな要求に細分化して開発する。
- プログラムを小さな機能単位に分割して開発する。
- 変更中のソースコードでもよいので随時チェックインする。
解答例・解答の要点
- エ
- 各アプリケーションの担当チームだけにメールするようにする (28文字)
- 各アプリケーションのビルド終了後，待ち合わせせず単体テストに移る (32文字)
解説
- CIツールを導入する前提として、リポジトリ内のコードは常にビルド可能な状態で、テストが通る状態になっている必要があります。変更中のソースコードをチェックインすると、ビルドが正常終了しない状態が一定時間続くことになり、定期的なインテグレーションを目的とするCIツール導入の意味がありません。
したがって、変更中のソースコードでもよいので随時チェックインするというアドバイスは不適切です。
∴エ：変更途中のソースコードでもよいので随時チェックインする - CIツールから送信されるメールを限定する方法について問われているので、本文中からCIから送信されるメールに関する部分を探すと、「アクティビティの実行結果は正常・異常にかかわらずX，Y，Zの担当チームメンバ全員に…送信する」とあります。この設定では、担当している・していないにかかわらず、全てのアプリケーションのアクティビティごとの情報が2時間ごとに全員に送信されるため、相当な数のメールが届くことになります。これでは、エラーの検出についてのメールを見逃してしまうのも無理はありません。
送信されるメールを限定する目的は、開発者が、自身の担当するアプリケーションのエラーに気付けるようにすることですから、エラーが起こったときにだけ、その担当チームメンバ全員にメールを送信すれば事足ります。設問には「正常時のメールの送信を停止する以外に」という指定があるので、メールを送信するチームを限定する方法を答えることになります。
∴各アプリケーションの担当チームだけにメールするようにする - 図1のCIツールのワークフローを見ると、各アプリケーションは、他のアプリケーションがビルドを完了するのを待ち合わせてから、単体テストに移る手順になっています。ワークフロー内のアクティビティは、前のアクティビティが全て正常終了した場合にだけ、次のアクティビティに進むので、あるアプリケーションのビルドでエラーが発生すると、そこでワークフローが止まり、すべてのアプリケーションが単体テストに進めません。単体テストは、プログラム単体での動作を確認するために行われるテストであり、そのアプリケーション単体で完結するものですから、ビルド終了後の待ち合わせをなくしても支障はありません。ビルド終了後の待ち合わせをなくすことで、他のアプリケーションでビルドエラーが発生した場合でも単体テストまで実行されるようになり、Zを担当するチームの不満も解消できます。
∴各アプリケーションのビルド終了後，待ち合わせせず単体テストに移る
広告
