詳細

ソフトウェア自動化テストの構造を打破する

 

自動テストのエラー

自動化テストは人件費の代わりにしか考えられないため、多くの企業が自動化テストを実施しているのは、既存のTest Caseを自動化スクリプトに変換するだけであることを見ています.
これにより、テスト全体のレベルを向上させることも、テスト結果を改善することもできません.その結果、手作業でテストできる問題自動化テストでテストでき、手作業でテストできない問題自動化テストもテストできなかった.
テストの観念は既存のTest Case段階にとどまっているため、Test Caseはビジネスプロセステストの段階にとどまっている.
最終自動化テストは、テスト例に従ってビジネスプロセスを歩み、ビジネスプロセスの検証を完了するだけです.

階層化と導入に伴う問題

技術の発展につれて、ソフトウェアの多様性に伴い、テストはCS構造に基づくGUIテストに限らず、BSブラウザWEB UIテストに基づいている.例えば、現在のアンドロイドシステム、アップルIOSシステム、マイクロソフトのWindows Mobileシステムなども自動化テスト分野に加わっている.
アプリケーションもますます複雑になっています.たとえば、次のようなものです.

階層の変化:インタフェース層、インタフェース層、ビジネスロジック層、ソリッドモデル層

の導入の変化:シングルマシンの実行からデュアルマシンのホットバックアップ、さらに負荷の均衡まで、最近分散システムに進化しました.

ストレージの変化:リレーショナル・データベース、非リレーショナル・データベース、キャッシュ・データベース、検索エンジン・データベース

次のピラミッドアーキテクチャから,ソフトウェアがユーザに示すのはUIインタフェース層のみであることがわかる.

/\
           /  \
          / UI \
         /------\
        /   API  \
       /----------\
      /   Service  \     
     /--------------\
    /    Component   \
   /------------------\  
  /      Database      \
 /______________________\

上はソフトウェアの階層化であり、1つのソフトウェアが導入されると構造が複雑になります.

/\
           /  \
          /CDN \
         /------\
        / WEB SER\
       /----------\
      / APP Server \     
     /--------------\
    / Message Queue  \
   /------------------\  
  / Cache|SearchEngine \
 /   Database| NoSQL    \ 
/________________________\

WEBアプリケーションテストについては、ブラウザ->WEBサーバ->APPサーバ->キャッシュ->データベースから、さまざまなエージェント、負荷分散、分散ファイルシステムなど、幅広い内容が含まれています.
テストの内容は次のとおりです.

CDNテスト、ドメイン名解析テスト、

WEB UIテスト、HTML、Ajax

を含む

APIサーバテスト、apiは、特定のプロトコルを介してAPIサーバとインタラクティブに通信する非ヒューマン・マシン・インターフェースです.

コードユニットテスト

配置テスト、配置管理過程における配置変更後のテスト、システムとアプリケーションを含む

セキュリティテスト、インタフェースセキュリティ、認証、権限

注入テスト、JS注入、SQL注入、Shell注入

キャッシュテスト、ヒット率テスト、CDN、WEBサーバ、キャッシュサーバ、検索エンジン

を含む

圧力試験、頑丈性試験

拡張性試験、水平拡張試験、垂直拡張試験

高可用性テスト、クラスタテスト

圧力テストの問題点

私のもう一つの文章「ストレステストに存在する問題」を参考にしてください.
ここでは、圧力テストを単独で強調します.多くの人のテスト方法に問題があります.
圧力テストは、機械に圧力テストソフトウェアをインストールする準備をしてテストを開始するわけではありません.圧力テストの環境は非常に重要で、多くの長年働いていたテストスタッフはこの問題を意識していません.
圧力テストには2つの重点があり、1つは圧力テスト環境の建設であり、2つは圧力テストの順序である.

圧力試験環境

圧力テストは単機でもネットでも、良い圧力テスト環境が必要です.例えば、ネットは高速道路のようなものです.もし道路がボトルネックになったら、正確なデータをテストすることができますか.
まずテスト環境を準備して、例えば単機テストはCPU速度、ディスクIO速度、RAIDカードの速度、RAIDカードキャッシュサイズ、メモリ速度、PCI-Eバス速度を考慮して、甚だしきに至っては多対称CPU関連配置、メモリとCPUチャネルの問題に関連する......など
分散システムをテストする場合は、上記の単一ノードの注意点に加えて、ルータ/ファイアウォールのパケット転送と接続数の制限、スイッチのバックプレート帯域幅およびスループット、負荷イコライザの転送能力も考慮します.

テスト順序

ストレステストシーケンスの切り込み点は非常に重要であり、テストシーケンスの多くはUI(ヒューマン・インターフェース)から切り込み、すなわちUIによってビジネス・ロジックを駆動する.このテストシーケンスは、ユーザー->ブラウザ->WEBサーバ->APPサーバ->キャッシュ->データベースなど、多くの問題をもたらす.

\------------------/
 \    Web server  /
  \   App Server /
   \ Cache / MQ /
    \ Database /
     \ Disk IO/
      \      /

ソフトウェアのパフォーマンスのボトルネックは通常、砂時計型であり、最大のボトルネックはデータベースであり、他のサーバのボトルネックはアーキテクチャの観点からパフォーマンスの問題を解決することができます.
まず、データベースからテストし、データベースの構成最適化が予想される値に達するかどうかを確認する必要があります.次にキャッシュ、メッセージキュー、検索エンジンなど.....
これで、データベース、キャッシュ、メッセージキュー、検索エンジンがストレステストのボトルネックにならないことがわかりました.次に、アプリケーションサーバとアプリケーションソフトウェアをテストできます.
もしあなたのテスト構造が少し拡大できれば、上記のものだけではありません.また、ハードウェア、ネットワーク、オペレーションカーネルパラメータの最適化、TCP/IPスタックの最適化、メンテナンス構成が私たちのニーズを満たすことができるかどうかを検証する必要があります.......

ボトルネック分析

ハードウェアのパフォーマンス、ソフトウェアのパフォーマンスを監視できる監視ソリューションが必要です.
テストの目的は1つの结果を出すためではありませんて、开発者にあなたのソフトウェアがXXXの同时を支えることができることを教えるので、私达のテストの中ですべての操作を监视して、すべての机能の使う时间を计算して、性能のボトルネックを分析して、开発者にソフトウェアを改善するように指导します.
モニタリングは外部モニタリングと内部モニタリングに分けられる.
外部モニタリングは最も実現しやすく、成熟したツールとソリューション、CPU、メモリ、ディスクIO、ネットワークトラフィックなどがあります.
内部モニタリングとは、メモリアドレス、変数、関数呼び出し、ダイナミックリンクライブラリのロード、ファイルハンドルのオープン、Socketアドレス、パケットなど、ソフトウェアの実行によってメモリにロードされた後の変化状態を指します.

開発を指導する

データ、グラフを通じて、ソフトウェアに存在する問題点を迅速に位置決めし、ソフトウェアの改善を指導する.

永続的な統合

継続的な統合、自動化構築はほとんどのテストチームが実施しますが、実際の状況は理想的ではなく、ツール構成の段階にとどまっています.生産環境で自動化構築を使用する人はほとんどいません.
なぜ、継続的な統合が本番環境に適用されないのですか?
(続きは、作者の微信公衆番号に注目してください.今はもう朝6時中ですから、寝ます)

テストの究極の目標

テストは、テスト例に従ってソフトウェアの検収を完了するだけでなく、ユーザーが見えるUI(ヒューマン・インターフェース)をテストするだけでは現代のソフトウェアのテストニーズを満たすことができないと思います.
テスト者はより高い角度から問題を見るべきで、テスト者は開発者を指導し、ソフトウェアの性能、丈夫性、安全性、およびソフトウェアアーキテクチャの設計に影響を与える能力がある.テスト者は広範な国境を越えた知識の支えが必要で、絶えず学習して向上し、既存の構造を打破しなければならない.
2016-12-03 06:30 AM