20181113-17.md

17章信頼性のためのテスト

徹底したテストは将来の信用性を予測しやすくなる

• テストのカバレッジが高い=信頼性が許容できる範囲が広い

---

17.1 ソフトウェアテストの種類

いわゆるソフトウェア開発の手法と同じ

• ユニットテスト(単体テスト)
• 結合テスト(インテグレーションテスト)
• システムテスト

ペパボのマネクラではシステムテストも振る舞いテストとして自動化。インフラのレイヤーだとInfraTesterとかかなぁ？

システムテスト

• パフォーマンステスト 性能のテスト、これが必要なレベルにはまだない。リリース後性能遅延とかを見てる感じがほとんどかな？
• 回帰テスト
• RSpec + ヘッドレストブラウザ
• 独自テストフレームワーク

---

17.1.2.1 設定テスト

イメージ的にはproductionに入る値が適切な値であるかどうかをテスト。 bin/rake serverspec production:xxxx的な感じ。 googleではテストプログラムが本番の値を調べて、差異を洗い出してくれる。

17.1.2.2 ストレステスト

性能限界を取るテスト。導入時にやるかなぁ。

17.1.2.3 カナリアテスト

書いてる内容はカナリアリリース。書かれてはないけどカナリアリリースの最大の注意点はモニタリング。いかに異常に気づけるかが大事。

17.2 テストの作成と環境の構築

テストが無い環境などもある。それらに対してどう取り組むか？

1. 何らかの優先順位をつけてそこを重点的に取り組む。
2. 課金などの失敗が許されない領域をカバーする
3. 外部に提供している機能をカバーする

---

強固なテスト文化を確立する

1. 報告されたバグをテストケースにする
2. テスト実行基盤を作成する

ビルド、テストの失敗は最優先で失敗すべきである

17.3.5 予想されるテストの失敗

信頼性を保ちながら、SREの人数がリニアにスケールしないようにするためにも、プロダクション環境はほぼ人手なしで動作しなければなりません。

1. 小さな障害に弾力性がある
2. SREが使用するツールは十分にテストされている必要がある(信頼性があるべき)

---

設定ファイルのテスト甘く見られがち

設定ファイルは多くの場合、コードの変更を避け、高速に挙動を変更するために用いられるが、挙動を変えるということは同じなのに意外とテストされていない。

17.3.6 結合

インタープリタはバイナリに組み込むことが出来、Pythonのようなインタープリタ言語が設定ファイルに使われます。(使われねーよ) いわゆる組み込みをやってるっぽい。

17.3.7 プロダクション環境におけるプローブ

テストは既知のデータに対して行われるものであり、モニタリングは未知のユーザーデータに対する動作が許容範囲に収まっていることを確認するものである。

1. 既知の異常・正常なリクエストを利用してテストをする。
2. それらは本番でもテストすべき、なぜなら本番と結合の環境は違うだろうから