修行の場

知人が言っていました。これは修行だと。

ソフトウェアテスト

ソフトウェアテストは重要

ソフトウェアテストはソフトウェアエンジニアにとってもとても重要です。 なぜなら、ソフトウェア開発はテストと表裏一体だからです。

Cracking the coding interviewによると、 エンジニアの採用面接では次のような点を評価するようです。 実際の仕事では、これらの点を満たしていなければ、 テストの取捨選択ができずにリリースが遅れたり、 テストが足りずに障害が起きたりすると思います。

  • 全体像を理解しているか?(=システムが使われる文脈を理解しているか?)
    • 誰が使うのか?なぜ使うのか?
    • ユースケースは?
    • 全体像の理解を元に適切な優先順位でテストできるか?
  • 部品がどのように組み合わさっているか理解している?(ユースケースを実現する機能がどう作られているか?)
    • 他のサービスと連携するなら結合テストをするか?
    • 結合テストするなら、どうやってテスト用のデータを用意するか?
  • 系統建てて答えられるか?
    • カテゴリ分けなどをしてテストを整理できているか?
  • チームの制約や技術制約を満たしていてpracticalな答えを出しているか?

テストを設計するためのアプローチ

CrackingCodingInterviewにはテストを考える際のアプローチの一例が乗っています。 1. ユーザの特定 2. ユースケース特定 3. 限度の特定:カバーされているユースケースの範囲は?限界は? 4. 不具合の想像:そして、負荷などある一定の条件により発生する不具合にはどういうものがあるか? 5. テスト方法の落とし込み。

1,2はユーザストーリーを書いてもいいですし、 ユースケース図など図にまとめてもいいと思います。 3は技術やオペレーションの限界で機能には限界があるはずなので、 そこを特定する 4不具合は不具合の想像です。 5で優先順位をつけたり、自動化、手動、ホワイトボックス、ブラックボックスの判断をします。

3,4,5を実施するためには更に詳細な知識が必要となります。 このアプローチはクラスやモジュールなど部品単位にも適用できるはずです。

通常のユースケースのテスト(3,5)

動作保証範囲内のテスト

ソフトウェア設計では機能要件に近いもののテストです。 分類軸としては

があります。

経験によると、 * 小さい単位でテストするほうがバグを見つけやすいしデバッグもしやすい * サンドボックスでテストするほうが後片付けが楽で手間が少ない。トラブルも減る * fixtureとかmockとか使ったほうが速いこともある で単体自動テストを早い段階で書くことが有効なことが多かったです。

pythonでは、下記のライブラリが役立ちます。

動作保証範囲が正しいことのテスト

負荷テストなどです。 実際の事例として下記のようなものがあります。

  • APIサーバ
  • ジョブキュー
  • ネットワーク
  • ハードディスク
  • キャッシュ
  • メモリ

不具合の予想とテスト(4,5)

限度と不具合はテスト対象によって異なります。 実際のソフトウェアやハードウェアの事例について復習しておくと、 自分でソフトウェアを作る際も感が働くかもしれません。

例えば、ネットワークでは負荷が増えると輻輳が発生します。 実際の事例として下記のようなものがあります。

  • ネットワーク
  • ハードディスク
  • キャッシュ
  • メモリ