著者：ホームカミングクラウド
2020年はあっという間に過ぎて、あっという間に2021年になります。最近、業界の同僚の年末の要約をいくつか読んで、過去も振り返り、利益と損失を合計し、来年の進捗の方向性を指摘できるかどうかを考えているので、これを持っています論文。
少し前に会社の研修「良い分かち合い方」に参加しましたが、今日はいくつかの理論を直接試してみます。トピックから直接話して、「テストエンジニアの価値を反映する方法」を明確に説明するために、なぜ、何を、どのように3つのレベルで話します。
テストの価値を直接反映することができない多くのトリッキーな状況に直面するので、なぜこれについて話したいのですか。たとえば、見つかったバグが多いほど、隠れたバグが少なくなり、製品の品質が向上しますが、必ずしもそうとは限りません。見つかったバグが少ないということは、隠れたバグが多いことを意味し、製品の品質は良くないか、必ずしもそうではありません。テストエンジニアの日常業務のほとんどがここにあるので、この例を例に挙げてみましょう。彼らが非常に一生懸命働いているが、製品の品質が理想的でない場合、私が価値があるかどうか、人々は不満や自信を失います。
テストエンジニアの価値は何ですか？最も重要なことは、製品の品質を確保することです。しかし、ここには別の問題があります。製品品質全体をテストチームに渡すことはお勧めできません。テストチームは製品品質の下限のみを保証でき、製品品質の上限はの共同の努力の結果です。チーム全体。品質の点は別として、もう一つの点は効率であり、これは一般的なテストと開発の比率でもあります。それを迅速かつ適切に行う方法は、自分の価値を反映するための鍵です。
速くて良いというキーポイントを中心にどのように展開するか、そして昨年の仕事の経験を組み合わせて、私たちの仕事がどのように行われるか、何がうまくいくかを維持する必要があるか、何がうまくいかないかについて話します。改善。
3.1プロセスからの品質について話す
上の図は、私たちの要件の1つのライフサイクルを示しています。黄色の部分は、私がチームのメンバーとして責任を負う必要がある日常業務です。「PFB」はプレビュー機能ブランチであることを説明します。これは、同時に開発中の要件が多数あるため、テストに多くのブランチがあり、最終的にバージョン内のすべての要件がバージョンブランチにマージされるためです。
要件の最終レビュー後、テストはタイムリーにテストケースを出力し、開発セルフテストのP0ユースケースを提供して、テストが発生した後のメインプロセスがスムーズであることを確認する必要があります。テスト基準については、当面はお見せしません。
テストPFB環境のテスト後、QA UAT PFB受け入れプロセスがあります。このプロセスは、主に配信されたUATバージョンの品質を保証するためのものです。以前は、UATブランチの管理が不十分なため、頻繁に苦情がありました。 、人員の一部だけが品質管理に投資されました。
次に、リリース段階になると、ステージング回帰テスト、Liveish環境の検証、およびLive環境への展開が必要になり、バージョン要件のライフサイクルが終了します。
反復の速度を確保するために、各バージョンは一定の間隔で並列になっています。ABCには3つのバージョンがあり、バージョンCの要件は今週テスト段階にあり、前のバージョンBの要件は今週UATフェーズにあり、前のバージョンAの要件は今週必要であると仮定します。今週リリースされる予定です。
注意深い学生は、要件を複数の環境で繰り返しテストする必要があることに気付く場合があります。品質が向上したとしても、QAにとって非常に苦痛であり、投資する人員も多くありません。したがって、現在、UATおよびステージング段階にあります。新しい要件はメインプロセスのみを保証しますが、古い機能は品質を保証するために自動化に依存しています。
3.2効率の観点から品質について話す上の
写真は、インターフェース自動化プラットフォームの主な機能です。QAがプラットフォームにインターフェース自動化のユースケースを書き込んだ後、それを毎日の監視とバージョン回帰に使用できるため、反復作業の一部を減らすことができます。できるだけ。書面によるユースケース要件は、可能な限り4つの環境に適用可能であり、十分なシナリオがカバーされるように製品を反復するときに、新しい機能を備えたユースケースを追加する必要があります。
自動ロケーションシステムの機能は、ユースケースが失敗した場合、要求されたグローバルに一意のTrace-IDに従って対応するコンテナでログが検索され、ユースケースの結果に書き込まれるため、QAが場所を特定できるようになります。問題を解決し、ログをチェックする時間のかかる作業を減らします。
PIC（Person In Charge）システムは、各モジュールに対応するDEV PICで構成されており、有用なケースが失敗した場合、DEVに処理するように通知する電子メールが自動的に送信されます。中断や誤検知を防ぐために、ここに手動確認リンクが追加されており、自動メール送信機能は現在有効になっていません。
プラットフォーム全体の本来の目的は、インターフェースの自動化を組み合わせて監視システムを作成することです。1つは各環境の安定性を確保することであり、もう1つは証明書利用者のさまざまな問題のためにブロックされる毎日のテスト作業を回避することです。しかし、結果として実際の状況は改善されていません。まず、監視タスクで失敗したユースケースについて、QAは失敗した理由に対処する時間がありません。次に、証明書利用者の問題は依然として個人的に解決しました。したがって、現在のプラットフォームの最大の価値は、ステージングフェーズの自動復帰にあります。
3.3イノベーションの観点から品質について語る
現在、テストでは左右にシフトするという考え方が出てきますが、ひとつは問題を早期に発見すること、もうひとつは製品の品質を監視することです。常に。
3.1のフローチャートから、要件の最終レビューに参加し、ユースケースレビューを整理する最初のポイントは、製品、開発、およびテストが要件を一貫して理解していることを確認し、製品設計の不整合を回避することです。および関数の実装。
上の写真の黄色い部分は、現在行っている作業です。静的コードスキャンは実際に実行され、GitLabのスキャンプラグインと組み合わせてコミットとマージ中にスキャンしますが、現在は役に立たず、スキャン結果に誰も注意を払っていません。
単体テストは、実際には、開発に独自のコードの所有権があるかどうかに完全に依存します。単体テストをQAに依存することは非現実的であり、効率は非常に低いと思います。TDD（テスト駆動開発）モードの実装について話さない限り、TDDを除いて、単体テストを単独で実装することは非常に困難です。
インターフェーステスト、すでに比較的完全なユースケースのセットがあるので、インターフェーステストの結果をテスト標準の条件の1つとして置きたいと思います。ただし、現在のインターフェイステストはJenkinsに統合されていないため、合格率をテスト標準に引き上げる必要があります。合格率が満たされない場合は、失敗したユースケースを誰が処理する必要がありますか？ QA本体、それは本当に欠けています。
コードカバレッジを試してみて、Coverage.pyと組み合わせてデモを作成すると、目的の機能を実現していると見なすことができます。しかし、Pythonプロジェクトの構築方法、Gunicornへの統合方法、プロジェクトコードへのアクセス方法がわかりません。その後、チームのテクノロジースタックがPythonからGolangに切り替えられ、保留になりました。
オンラインログ監視の場合、現在の主流のアプローチはELKです。これは、ログの検索、保存、表示を担当するElasticsearch、Logstash、Kibanaを組み合わせたものです。しかし実際には、これらはまだ十分ではありません。ELKはログ検索プラットフォームのみを提供します。実際に監視するには、Node Exporter、Prometheus、Grafanaの協力を得て、インターフェースのレイテンシーなどの表示用のデータをログに収集する必要があります。 QPS、200、400、500など。
総括する
自分の作品を整理して見直しましたが、まだまだ改善できることがたくさんあり、できることもたくさんあります。容量が足りない一方で、時間に限りがあり、うまくいかないところも多く、新年が進むことを願っています。
イースターエッグ：パフォーマンステスト、互換性テスト、UIオートメーションについて言及していない小さなパートナーからの疑問があるかもしれません。UIオートメーションは実際には使用されていますが、あまり役に立ちません。うまく行かないとマイナスのメリットが生じる可能性がある仕事です。私はeコマース会社で働いているため、大きなプロモーションの前にパフォーマンステストを行います。 ;互換性テストはUIによるものです自動化が行われておらず、当然UIオートメーションとの互換性テストは不可能で、STFもいじっていますが諦めた状態です。
さあ、テストマン！道は足元にあり、成功は明日です！
将来のあなたは間違いなく今あなたの努力に感謝するでしょう！
ソフトウェアテスト技術交換グループをすべての人に推奨します：1079636098グループの友人は無料で受け取ります
あなたと私が会い、あなたが何かを見つけることができますように！WeChatパブリックアカウントのフォローへようこそ：プログラマーYifan
1.216ページのソフトウェアテストエンジニアのインタビューブックを無料で受け取ります。
2.ソフトウェアテストの学習ルートと対応するビデオ学習チュートリアルは無料で共有できます。