ソフトウェア保守性向上のためのユニットテストカバレッジの有効性評価

【JaSST Tokyo2025　登壇資料】
ユニットテストのコードカバレッジはソフトウェアの保守性評価やユニットテストを実施する際の重要指標となりますが、その妥当性や有効性には様々な議論があります。
そこで弊社では、実データを使用して、ブランチカバレッジが復旧時間に短縮に寄与するとの仮説を立て、2つのデータの相関を調査してみました。
データ分析を通じた改善のヒントを得ることができるかもしれません。
https://jasst.jp/tokyo/25-about/

Transcript

1. ソフトウェア保守性向上のた めのユニットテストカバレッジ の有効性評価 JaSST’25 Tokyo
2. 角田　俊 Tsunoda Shun 株式会社マネーフォワード CQO室 プロセスエンジニアリング部
3. 東藤　絵梨衣 Todo　Erii 株式会社マネーフォワード CQO室 プロセスエンジニアリング部
4. アジェンダ 1. CQO室の役割 2. 研究内容の発表 a. 背景と仮説 b. データ収集方法と分析手法 c. 全体の分析結果 d. 重大度別の分析 e. 修正対象別の分析 f. 結論 3. 追加調査 4. まとめ 5. CQO室の今後のアクション
5. CQO室の役割
6. 作業内容
 • シフトレフトテストの推進 • 静的解析ツール、自動テストの推進 • メトリクスを活用したプロダクトの評価と改善 • 社外での障害の管理、改善 • AIツールの評価、検討、作成 • ソフトウェア開発プロセスの改善 CQO室の役割
7. CQO室の役割 作業内容
 • シフトレフトテストの推進 • 静的解析ツール、自動テストの推進 • メトリクスを活用したプロダクトの評価と改善 • 社外での障害の管理、改善 • AIツールの評価、検討、作成 • ソフトウェア開発プロセスの改善 CQO室は横断的に多数のプロダクトの品質を把握する必要がある。 そのために、メトリクス を用いて品質を定量的に評価、把握し、方針を作成していく必要が ある CQO室の役割
8. 背景と仮説
9. • 自社サービスの運営会社では継続的なサービスの改善、機能追加が行われる • 保守性が高い状態を維持することでメリットがある ◦ 機能追加が容易になる ◦ バグへの対応が容易になる 実践ソフトウェアエンジニアリング　第9版より 開発の生産性が向上し、 コスト削減になる 背景
10. 課題 保守性の指標の一つとしてコードカバレッジを測定、モニタリングしている しかし、コードカバレッジ率の妥当性については様々な議論がある ホワイトボックスカバレッジの要求レベルを指定する場合は、 100%で指定するのが良い。 その理由 は、カバレッジレベルを低く指定した場合、テストを実施しない部分は、テストが最も困難な部分であり、通常、最も複雑で エラーが発生しやすい部分であることを意味するからである。 そのため、例えば 80%のカバレッジを要求し達成することは、検出可能な欠陥の大部分を含むコードをテストしないまま放置す ることを意味する場合がある。 JSTQB テクニカルテストアナリストシラバス V4.0 より Google では、 60% を「許容」、75% を「推奨」、90% を「模範的」とする一般的なガイドラインを提供している。 Google Testing Blog Code Coverage Best Practices より 本研究では、コードカバレッジの有効性を発見し、 どの程度のカバレッジ率が効果的かを見出したい 課題
11. - デプロイの頻度 01 02 03 04 - 変更障害率 - サービス復元時間 DORAのメトリクス - 変更のリードタイム DevOpsでの品質
12. - デプロイの頻度 01 02 03 04 - 変更障害率 - 変更のリードタイム - サービス復元時間 障害に関連する指標 DevOpsでの品質 DORAのメトリクス
13. 仮説 「ユニットテストのコードカバレッジが高い場合、 サービス復元時間が短縮される」 と仮説を設定する。 コードカバレッジが高いテストが存在することで、以下の効果があると想定 • コードを変更した場合の影響範囲の特定が容易になる • リグレッションテストの実行時間が短縮される 障害発生 検知 修正の提供 原因の調査 ソフトウェアの修正 テスト 仮説
14. 復旧時間 障害発生 検知 修正の提供 サービス復元時間 DORAのサービス復元時間の定義は、 「本番環境での障害回復するのにかかる時間」。 本研究では、さらに具体的に以下の定義で評価を行う。 復旧時間：不具合を検知してから修正されるまでの時間
15. データ収集方法と分析手法
16. データ収集方法 • 市場発生不具合を一元管理している Jiraチケット ◦ 対象プロダクト：20 ◦ 収集対象外となるもの ▪ 時間データが未記載のもの ▪ 障害レポートが無く、正確な時間無し ▪ 修正不要と判断 ▪ カバレッジが取得できないプロダクト ◦ これらのデータを母集団とし、全数調査を行う • カバレッジデータ ◦ SonarQubeのブランチカバレッジを取得 データ収集方法
17. 分析手法 • 散布図 ◦ 相関を評価するために、二つの変数 の関係を可視化する • 回帰分析 ◦ y＝f(x)という回帰式で変数の間の関 係を定式化する ◦ xを説明変数(ブランチカバレッジ) ◦ yを目的変数(復旧時間) ブランチカバレッジ 復 旧 時 間 長 い 短 い 高い 低い y x ブランチカバレッジ xが高い時に、 復旧時間yが短くなる = 式が右下がり になることを期待する y＝ αx+β+ε 分析手法
18. • 相関係数 ◦ 2つの変数の関係性の強さを表す数値　-1から1で表す 相関係数の絶対値 関連の程度 0以上0.2未満 ほぼ相関なし 0.2以上0.4未満 弱い相関あり 0.4以上0.7未満 やや相関あり 0.7以上1未満 強い相関あり 相関係数 ‐0.8 相関係数 ‐0.1 分析手法
19. 名前 ピアソンの相関係数 r スピアマンの順位相関係数 p 概要 一般的に”相関”として 使われている値 順位データから求められる値 特徴 正規分布に従ったデータが前提 正規分布でなくても使用可能 欠点 外れ値に引っ張られる 外れ値に引っ張られにくいが、順位デー タのため変数間の情報が無い 分析手法 • 相関係数 ◦ 2つの変数の関係性の強さを表す数値　-1から1で表す
20. • 決定係数（ R2） ◦ 回帰式におけるデータの当てはまりの良さの指標 ◦ 1に近いと当てはまりが良く、0に近いと当てはまりが悪い 良 悪 R2＝0.92 R2＝0.45 R2＝0.003 分析手法
21. 全体の分析結果
22. 回帰式 y=-0.719*x + 106 相関係数r -0.070 相関係数p 0.017 決定係数 0.005 • 右下がりだが、相関係数は0に近くほぼ相関なし。 • 決定係数0.005　式の当てはまりも悪い。 • データに偏りがあるため、データの分布を確認する必要がある。 結果
23. 復旧時間が12時間以内のデータが全体 の6.5割を占めており、偏りが見られた。 障害が発覚した当日に修正が行われて いることが分かる。 ヒストグラムでデータの分布を確かめる デ l タ数
24. ヒストグラムでデータの分布を確かめる ブランチカバレッジが70%を 超えるデータが7割を占めて おり、偏りが見られた。 カバレッジが低いプロダクト のデータ数が少なく、分析に おいて信頼性が足りない。 デ l タ数 ヒストグラムでデータの分布を確かめる
25. • 外れ値やデータの偏りをできるだけ無くし、より信頼性を上げるために ◦ 復旧時間が 12時間以内 ◦ コードカバレッジ 70％以上　　これらのデータをさらに分析する。 分布の結果から分析対象データを絞り込む
26. ・復旧時間が 12時間以内 ・カバレッジ 70%以上 これらのデータに絞って分析する
27. 回帰式 y=-0.0314*x + 4.91 相関係数r -0.070 相関係数p -0.14 決定係数 0.009 • 同様の結果。右下がりになるが相関係数は0に近くほぼ相関なし。 ◦ 他の変数と絡めて関係性を調べることにする。 結果
28. 重大度別に分析する
29. • 仮説 ◦ 重大度によって修正対応の優先度合いが 変わると予想すると、同じ重大度ごとに データを見ると効果的なのではないか。 • 手法 ◦ データを重大度ごとにわけ、コードカバレッ ジと復旧時間の分析を行う。 1 2 3 4 顧客への重大度が高い 顧客への重大度が低 い 重大度の違いによって相関が見られるか
30. 重大度 1 回帰式 y=0.326*x + -22 相関係数r 0.952 相関係数 p 1 決定係数R2 0.905 結果 • 正の相関ありで仮説と逆。データ数は少なく信憑性が低い結果となった。 ◦ 複数プロダクトが関連する障害が多い。
31. • 弱い負の相関あり。 ◦ コードカバレッジと復旧時間に少なくとも一定の影響があるかもしれない。 重大度 2 回帰式 y=-0.09*x + 9.49 相関係数r -0.314 相関係数 p -0.42 決定係数R2 0.098 結果 結果 •
32. • やや負の相関あり。 ◦ コードカバレッジと復旧時間に少なくとも一定の影響があるかもしれない。 結果 重大度 3 回帰式 y=-0.11*x + 10.9 相関係数r -0.493 相関係数 p -0.61 決定係数R2 0.258
33. • 弱い正の相関(および相関ほぼなし)で仮説と逆。 • データ量が少なく、軽微な不具合は全体的に修正時間が短いため傾向が見られなかった。 重大度 4 回帰式 y=0.0654*x + -3.45 相関係数r 0.230 相関係数 p 0.09 決定係数R2 0.053 結果 結果
34. 重大度 1 2 3 4 全体 相関係数r 0.952 -0.314 -0.493 0.230 -0.09 相関 強い正の相関 弱い負の相関 やや負の相関 弱い正の相関 ほぼ相関なし 相関係数p 1 -0.42 -0.61 0.09 -0.14 相関 強い正の相関 弱い負の相関 やや負の相関 ほぼ相関なし ほぼ相関なし 決定係数 0.905 0.098 0.258 0.053 0.009 • 重大度2,3において、弱い負の相関、やや負の相関が見られた。 • 重大度1はデータ量が少なく、結果の信頼性が低いと思われる。 • 重大度4もデータ量が少なく、全体的に修正時間が短かったため明確な相関がみられなかった と思われる。 結果
35. 修正対象を絞って分析する
36. • 仮説 ◦ 修正対象はコードだけでなくインフラやデータ周りなど様々ある。 ◦ コードカバレッジとの相関をより明確にするために、コードカバレッジの影響が大 きいと思われる、コードに変更 を加えた障害のみを検証するとより効果的なので はないか。 • 手法 ◦ バックエンド のリポジトリに修正を加えた不具合データに絞り、分析する。 コードに変更を加えた障害のみに絞った際の分析
37. 修正対象 バックエンド 回帰式 y=8.11E-03*x + 1.9 相関係数r 0.02 相関係数 p 0.117 決定係数R2 0 • 仮説と逆で、相関もほぼなし。 ◦ データに偏りがあり、外れ値のデータに引っぱられた可能性がある。 コードに変更を加えた障害のみに絞った際の分析
38. 結論
39. • 一部分析において、相関が見られた。 ◦ 重大度2,3においては負の相関が見られた。 ◦ 全ての結果で相関が見られたわけではなかったため、コードカバレッジ以外の変数 も復旧時間に大きく影響していると思われる。 結論
40. • 分析方法 ◦ 復旧時間のみに着目したが、今後の研究では他の変数を含めた多変量解析を 行い、より詳細な検証を進める必要がある。 • データ量 ◦ 今回解析に使用したデータ量では、分析するのに少なかったと感じている。 • 効果的なコードカバレッジ率 ◦ コードカバレッジが70%以下のデータが少なく、有効性はわからなかった。 考察
41. [追加調査] 復旧時間に影響を与える変数を 分析する
42. コードカバレッジ以外に復旧時間に影響する変数を深掘りする 復旧時間に影響する変数を分析する
43. 復旧時間が短くなる変数を分析する • 1. 検知方法の違い ◦ モニタリングツールでの検知 ▪ 復旧時間が短くなると予想 • 障害の原因となる欠陥がピンポイントで特定でき、調査時間を短縮でき るため ◦ 顧客や、社内の従業員からの検知 ▪ 復旧時間が長くなると予想 • 不具合再現手順のコミュニケーションが必要で、原因となる欠陥が特 定しにくく、調査時間が必要になるため 障害発生 検知 修正の提供 原因の調査 ソフトウェアの修正 テスト 復旧時間に影響する変数を分析する
44. 検知方法 モニタリングツールからの 通知 顧客からの連 絡 従業員からの 連絡 全体 平均復旧時間 1.87 3.11 3.02 2.47 結果
45. • 2. 障害発生タイミング ◦ リリース直後の検知不具合 ▪ 復旧時間が短くなると予想 • リリース直後は開発チームが即座に対応できる体制になっている可能 性があるため ◦ リリース後に時間が経過してからの検知不具合 ▪ 復旧時間が長くなると予想 • 開発チームが他の作業を行っていて、即座に対応できる体制になって いない可能性があるため 復旧時間に影響する変数を分析する
46. 障害発生のタイミ ング リリース直後に発覚 リリース後に 時間が経過してから発覚 全体 平均復旧時間 1.53 2.89 2.47 結果
47. • モニタリングツールの活用 ◦ モニタリングツールを活用することで、復旧時間を短縮できる可能性が高い。 • リリース直後の開発体制の強化 ◦ 85%がリバートで対応 していた。 ▪ リバートできるようなリリースの仕方を検討することで、復旧時間が短縮で きる可能性が高い。 復旧時間に影響する変数を分析する
48. 最後に
49. • コードカバレッジと復旧時間は一部相関が見られた。 • しかし、復旧時間に影響する変数は他にも存在している。 ◦ 検知方法の違い ◦ 障害発生タイミング • コードカバレッジの向上に加えて、様々な取り組みを組み合わせることで復旧時間 をより効果的に短縮できる 可能性がある。 まとめ
50. データ分析における感想 • データ準備に時間がかかった ◦ 手動でデータを取得・変換する作業が多く、全体の中で特にデータの下準備に 時間がかかった。 ◦ 収集するのを目的にせず、取得しやすくかつ変換しやすい形でのデータ収集を 心がけたい。 • データ信頼性の担保 ◦ 障害を検知した時間ではなく欠陥を埋め込んだ時間を入れてしまっているデータ もあり、信頼性がないデータを計測に使えなかった。 ◦ メトリクスツールを用いて自動で取得することも検討したい。
51. • CQO室の出している方針は維持 ◦ ブランチカバレッジで70%,80%を目指す。 ▪ テストされるべきコードがテストされていることが重要 • 保守性の評価の方法 ◦ 他の値を複合的に評価し、プロダクトの保守性を評価していく。 • サービス復元時間を短縮するための活動は継続する 障害発生 検知 修正の提供 CQO室の今後のアクション
53. • 総務省, 令和４年通信利用動向調査の結果 , 発行日2023/05/29, https://www.soumu.go.jp/johotsusintokei/statistics/data/230529_1.pdf,アクセス日 • Nicole Forsgren他, LeanとDevOpsの科学, 株式会社インプレス , 2018/11/21 発行 • ISTQB, JSTQBテクニカルテストアナリストシラバス , 発行日 2024/07/14, https://jstqb.jp/dl/JSTQB_CTAL-TTA_Syllabus_version2024.v4.0.J01.pdf • Gojko Adzic他, ソフトウェアテストをカイゼンする 50のアイデア, 翔泳社, 2022/09/20 発行 • Google, Google Testing Blog, 発行日 2020/08/07 , https://testing.googleblog.com/2020/08/code-coverage-best-practices.html, • Martin Fowler, Test Coverage, 発行日 2012/04/17, https://martinfowler.com/bliki/TestCoverage.html, • Vard Antinyan他, Mythical Unit Test Coverage https://www.researchgate.net/publication/324959836_Mythical_Unit_Test_Coverage • NIST, The Economic Impacts of Inadequate Infrastructure for Software Testing, 発行日 202/05, https://www.nist.gov/system/files/documents/director/planning/report02-3.pdf, アクセス日 2024/09/09 • 生物工学会誌 第95巻 第8号 https://www.sbj.or.jp/wp-content/uploads/file/sbj/9508/9508_tokei_kaiseki.pdf • 阿部 真人.(2021). 『データ分析に必須の知識・考え方 統計学入門 仮説検定から統計モデリングまで重要トピックを完 全網羅』. ソシム出版社. 参考文献