『Googleソフトウェアテストの道』を読む

IT分野では、グーグルは旗印であり、思考が上手で試しやすい会社です.挑戦が増大するにつれて、伝統的なテストの展開方式もますます力が入らなくなり、この本は完全な転換過程を述べており、非常に価値がある.これは古い本で、1年以上前に拝読したことがあります.その时、もっと多く見たのは格差と困難で、1年の努力と試みに従って、突然少し理解して、みんなと分かち合います.

基本理念

Googleの品質面での基本的な共通認識は:
品質はテストされたものではありません
具体的な目標は次のとおりです.
すべてのエンジニアに品質を重視させる
長年従事して、このスローガンは実はよく耳にすることができて、しかし大多数の時ただ1つのスローガンで、とても長い間、私は甚だしきに至っては開発者が品質意識に欠けてすでに1種の天性になったと感じて、どのようにこの堅氷を破って、Googleは少し啓示をもたらすことができるかもしれません.

組織の変革

Googleの変革は組織から始まり、いくつかの大きな問題に直面しています.
テスト部門は保留する必要がありますか?思考の角度から言えば、開発は思考を作成することであり、テストは思考を破壊することであり、両者は同時に互換性がない.1つの部門は2つの考え方を互換化するのが難しいので、Googleは独立したテスト部門を維持しています.
テスト部門の位置づけはどうですか.新しい部門の名前はEngineering Productivityエンジニアリング生産力部門と呼ばれています.部門の名称から見ると、主に生産力の向上に注目している.
工事生産力部門はどのように働いていますか.肝心なのは人員の分業で、主に2種類の役SETとTEがあります.TE(テストエンジニア)は通常のテストロールと類似しており、主に機能面の検証を担当しています.SET(テスト開発エンジニア)これは新しい職責であり、開発者のテストを支援することを目標としています.
Googleの変革の核心は新しい役割SETを追加することであり、この役割は主に開発とテストの融合剤を果たし、品質意識を普及させる鍵でもある.

テスト分類

SETというキャラクターがどのように協働しているのか、Googleのテスト分類が鍵です.
テスト分類は次のとおりです.
小型テスト:ユニットテスト.中型テスト:2つ以上のモジュールで、機能のインタラクションに注目します.大規模なテスト:3つ以上、実際のユーザーシーンとデータを使用します.
初めてこの分類を見て、私は少し乱れていると感じて、命名の上であまりにも厳格ではありません.技術的な観点から,3種類のテストをより詳細に区別し,多くのことを明らかにした.
ミニテスト
中型テスト
大規模なテスト
時間
10 ms以内
1 s以内
できるだけ早く
強制終了
1min
5min
15min
ネットワークサービス
シミュレーション
ローカルのみ
はい
データベース#データベース#
シミュレーション
はい
はい
ファイルシステム
シミュレーション
はい
はい
ユーザーインタフェース
シミュレーション
励まさない
はい
システムコール
いいえ
励まさない
はい
マルチスレッド
励まさない
はい
はい
小型テストの特徴は、実行時間が短く、外部依存性がないことです.すべての条件を満たすわけではありません.小型テストでも、次のコードは一致しますが、出力結果が不安定なため、小型テストではありません.

    public String getString(){
        return new SimpleDateFormat("yyyy-MM-dd hh:mm:ss.SSS")
                        .format(new Date());
    }

3種類のテストの分業は以下の通りです.
小型テストは運行時間が短く、依存性がなく、出力が安定しており、これらの特性は間違いなくテストに非常に有利であり、多くの開発者は完全に適任であり、すべての小型テストは開発者SWEが担当している.同時に,小型テストはすべてのモジュールの礎であり,この品質体系の安定した基礎を構成している.すべてのコードがスモールテストの要件を満たすわけではないので、SETの最初の職責は、開発者がコードの再構築をスモールテストに適合させることです.
中型テストは外部依存とモジュール間インタフェースに関連し,比較的難易度が高いため,主にSETが担当するとともに,SETがインタフェース関連の開発を担当する.
大規模なテストは主にユーザー向けで、TEが担当します.
Googleでは、SWE、SET、TEが共同で品質の仕事を完成するために協力していますが、3つの間には厳格な境界区分があり、小型テストの数は膨大でテストしやすく、必要なのは細部の論理の掌握であり、SWEの責任が最も適切です.その上で、中型テストはインタフェースと外部依存を実現する必要があり、専門性が強く、SETが責任を負う.大規模なテストは主にユーザーと価値向けで、TEが担当します.三者は共に質量のピラミッドを構成した.

ACC試験法

TEロールは、小型テストと中型テストのサポートにより、主にユーザー体験とビジネス価値に注目します.仕事のやり方をACCテスト法といいます.
A特性、Cコンポーネント、C能力はマトリクス表現である.各コンピテンシー(システム機能)は、機能と特性(ビジネス価値)の両方を同時に考慮する必要があります.
機能1
プロパティ2
機能3
コンポーネント1
コンピテンシー
コンポーネント2
コンピテンシー
コンポーネント3
コンピテンシー
ACCはテスト計画の手配法であり,従来のツリー構造と比較して特性の次元が増加し,ビジネス価値が顕著になった.しかし、この方法は主観性が大きく、テスト担当者に一定の要求がある.

小結

本の中でSETとTEの仕事に対して比較的に具体的な説明があって、紙面に限られてもう贅沢に述べません.本全体を読むと、最も印象的なGoogleの問題解決の構想があります.品質という業界の巨大な難題に直面して、Googleのやり方はスローガンではなく、革命ではなく、具体的な問題ごとに、非常に人間的な解決を行い、非常に大きな問題を分解した.その解決方法はグーグルの特色が強く、私たちは完全にそのままではいけないが、問題を解決する考え方と派生した多くの技術成果は私たちが学ぶ価値がある.