1 ►
ビジネスの背景
Didi の中核事業であるオンライン配車事業は、システム アーキテクチャが複雑で、注文チェーン全体に多くの下流サービスが含まれており、全体的な反復頻度が高く、同時に、さまざまなカテゴリを通じて差別化されたサービス機能を提供しています。今日、急行列車は複数のカテゴリに拡張されており、特定のカテゴリのシナリオや毎日の機能反復における特定の機能テストの実装には非常に高いコストがかかります。典型的な例をいくつか挙げると、次のようになります。
相乗りシナリオ: 2 人の乗客が同時にログインして同じエリアで注文を行う必要があり、同じドライバーが 2 つの注文を受け入れて契約を完了できます。
B シリアル配達注文シナリオ: ドライバーは、前の注文を完了する前に次の注文を受け取る必要があります。
これら 2 つの典型的な例は、オンライン配車学生のテスト作業における共通テストと合格シナリオですが、上記のシナリオには、乗客アカウントが存在するエリアとドライバー アカウントをテストする機能をテストするための高い要件があります。同時に運用するには時間がかかり、シーンの構築を完了するのが難しいため、各事業ラインでは利便性の高い注文シーンの構築とテスト機能に対する強い需要があり、そのビジネス特性が形成されています。研究とテストの効率を向上させ、高品質のビジネス提供を保証するための、サービス指向で標準化された注文テスト機能。
2 ►
注文テストプロセス
オンライン配車の注文トランザクション全体のリンクの上流と下流には複数のサービスが関与しており、サービスは相互に関連しています。中核となるタクシー配車ビジネスでは、サーバー側の API が受信側から上向きにリクエストを行い、サービスを組み立てます。ビジネス センターのさまざまなシステムがタクシー配車プロセス全体を完了するまで待ちます。
注文テストでは、注文ステータスのフローに応じて上流と下流が異なります。注文処理フローを完了するために、注文テストはサーバーのメインプロセス API を呼び出し、ノード間のパラメータの転送を実現してシリアル接続を完了します。フロー注文プロセスを確認し、注文ステータスの変化を認識します。
3 ►
注文テストの進化プロセス
エンドツーエンドの単一テスト (2015 年以前)
「
ビジネスアプリケーション
ビジネス開発の初期段階のテストモードでは、端末に完全に依存して注文テストを実現し、実際の旅客ターミナルで乗客をシミュレートして価格の見積もりと注文の発行を実行し、実際のドライバー端末で注文を完了してからシナリオを完了します。検証。
エンドツーエンドのテスト
「
テストの利点
ターミナルテストは高度なシミュレーションを備えており、通常のビジネスシナリオで乗客が注文を出し、ドライバーが注文を完了するまでの全プロセスを完全にシミュレートしており、プロセス全体にビジネスモックはなく、シーン検証はより包括的で、完了。
「
不十分なテスト
ピュアエンドテストは通常の注文の分割・発送ロジックに従うため、日々の業務テストでは特定の地域で注文を行う必要がありますが、指定されたドライバーが毎回注文を受けられる保証はなく、成功率も高くなります。低い。
エンドツーエンドのテストでは、プロキシ構成を通じて指定された環境にアクセスする必要があるため、注文テストごとに複雑なプロキシ構成が必要になります。
複雑な注文シナリオの構築手順は面倒で多大な労力を要します。
器具注文作成試験（2015年～2020年）
「
ビジネス要件
端末モデルはビジネスの初期段階での研究開発とテストの主な手段ですが、オンライン配車ビジネスの急速な発展に伴い、ビジネスの複雑さはますます高くなり、端末を使用するだけでは完全に機能しなくなりました。オンライン注文シナリオをシミュレートします。ビジネスでは、より複雑な請求が必要です。また、受注シーンの注文では、より高い注文成功率とより安定した注文機能が必要です。
「
ツールの構築
高頻度の注文テストシナリオを維持するための注文循環ツールの構築を通じて、注文を受け取るためのモックドライバー、および注文を作成するためのツールを通じて、特定の注文シナリオのリンク構築を達成するためのオールドラッグオフエンドモードまたはハーフドラッグオフエンドモード。
ツール側では、主に次の 4 種類のコア機能が実現されます。
注文シナリオライブラリ: コア注文シナリオのパラメータ情報を保持します。
注文の流れ: 乗客と運転手の模擬フルプロセス テスト パネル。
ドライバー転送: モックドライバーの完全なプロセスパネル。
一般的なインターフェイスのリクエスト: インターフェイスのテストをサポートします。
計測化された単一テスト
「
不十分なツール
ビジネスの発展に伴い、端末 + 注文流通ツールをベースにしたモデルの欠点が明らかになり始めました。これは主に次の 3 つの側面に反映されています。
現場の更新や保守に遅れが生じる ツール保守者は主に品質センターにいるため、ビジネスシーンの繰り返しの変更をツール保守者に同期させることが難しい アジャイル開発の進展により、この遅れが顕著になるますます明らかになります。
注文転送ツールの転送結果は、異なるユーザー間で共同で共有することができず、注文テストプロセス全体の状態管理が行われず、テストプロセス全体を効果的に追跡することが困難です。
現在、注文フロー ツールはメイン プロセスの注文リンク テストのみをサポートしており、より一般的な注文ブランチのサポートは不十分です。人員上の理由により、新しいシナリオのサイクルは一般的に日単位であり、ビジネスの反復が制限されています。 。
セルフサービス注文作成テスト（2020年～現在）
「
ビジネス要件
長期にわたる蓄積を経て、注文流通ツールにはオンライン配車のための 70 を超えるコア注文流通シナリオが含まれていますが、ツールのメンテナンスと反復に固有の欠点があるため、在庫シナリオの数とシミュレーションにはギャップが生じています。明らかに、ビジネスの観点からは、注文テストシナリオの迅速な構築を実現するために、既存の注文フローシナリオに基づいてパーソナライズされたシナリオリンクテストを迅速に構築できることが望まれます。
「
機能的アーキテクチャ
視覚化、標準化、インテリジェンスの原則と注文流通ツールに基づいて、セルフサービスの注文作成テスト機能が構築されています。
インテリジェントな単機能アーキテクチャ
セルフサービス注文作成テストに基づく変更点:
視覚的なリンク アセンブリ機能は、単純な構成要素を通じてリンク シーンの生成を実現します。
チームを超えた連携やコラボレーションを実現する便利なシーン共有機能。
多様な注文シナリオの中心となる要件は、シナリオの保守と反復を第一線のビジネス学生に引き継ぎ、ビジネス学生が自分たちでシナリオを作成して適用できるようにすることであるため、便利なリンクアセンブリを提供するのは非常に簡単です。デバッグ機能、相互コラボレーションおよび共有機能により、ビジネス学生がセルフサービス テストを大幅に達成できるようになります。
「
リンクアセンブリのデバッグ
シーンの編集とデバッグには、主に 2 つの困難があります。
1. 初期化パラメータの構築が難しい
2. シーンの整理やデバッグに時間がかかる
ソリューションのアイデア: リンク データ プリセットを通じてユーザー取得パラメーターのコストを削減し、コンポーネント化のアイデアに基づいてオーケストレーションとデバッグをより柔軟で使いやすくします。
具体的な解決策:
リンク オーケストレーションのデバッグ
リンク編集プロセスでは、パルスチェック ログ システムがオープンされ、履歴ログのリンク抽出ルールに基づいてデータの非感作を通じてリンク データが初期化されると同時に、テンプレートの再利用機能に基づいて、リンク シナリオが作成されます。プラットフォームにデポジットされている初期化機能も提供できます。
リンク配置では、データ、環境、リンクがコンポーネントにパッケージ化されてリンク ノードを形成し、Web ドラッグ アンド ドロップに基づいてリンクが調整されます。シーンが生成されると、標準化されたデータ分割と永続的なストレージが DB に保存され、その後のデータ分析に使用されます。統計とシーンの再利用により利便性が高まります。
配置効果: 次のようにページをドラッグ アンド ドロップすることで、リンクをすばやく調整およびデバッグできます。
ウェブレイアウト
「
シーンの共同共有
シーンコーディネート
ビジネスの降水シーンのアトリビューション属性を拡張して、アトリビューション ユーザー全体で協調的な属性を形成し、コラボレーションを通じて降水シーンを再利用して、ビジネス ライン全体にわたる注文テストの管理と制御を形成します。
共有プール
ユーザーは、デバッグ済みの注文シナリオを部門の共有プールにプッシュし、共有を通じて注文シナリオの調整をポイントツーポイントからポイントツーポイントに拡張することができ、共有プール内の決済済み注文シナリオをすべてのユーザーが便利に利用できます。 。
共同共有
4 ►
エフェクトを適用する
現在、セルフサービステスト機能により330を超える注文テストシナリオが蓄積され、新しいシナリオも継続的に追加されており、ユーザーベースでは毎月500ユーザー以上のデバッグと実行をサポートしています。
5 ►
概要の見通し
注文テストの進化以来、さまざまなビジネス チームの協力を得て、効率と使いやすさの点で段階的な開発が行われてきました。しかし、ビジネスの継続的な進化に伴い、注文テストの需要は常に繰り返されており、ビジネスの変化に適応するために注文テスト機能を継続的に最適化する必要があります。将来的には探求されます:
エンパワーメントテストが左にシフト
セルフサービス テストにより、オーダー テストの構築コストが削減されるため、ビジネス学生はオーダー テストのシナリオを迅速に構築し、問題の発見を事前に実現し、テストを左に進めることができます。環境の準備、テストの統合、結果のフィードバックを経て、認識されないことを認識するプロセス全体の順序テスト。
インテリジェントなシーン構築
オンライントラフィック分析やシーンデータ再生などによるテストシナリオのインテリジェントな構築をさらに実現し、シーン構築のコストを削減し、ワンクリックでのシーンリンク構築検証を実現します。
終わり
著者と所属の紹介
この記事の著者 ソング
ユー・レイ、ユー・チャン、来てください
Didi のオンライン配車旅行テクノロジー チームの旅行テクノロジーは、エンドユーザー エクスペリエンス プラットフォームの構築、C エンド ユーザー製品エコロジー、B エンド容量供給エコロジー、旅行の安全性などを通じたオンライン配車ビジネスの研究開発チームです。エコロジー、サービスガバナンスエコロジー、コア保証システムを統合し、安全、信頼性、効率性、利便性、そしてユーザーの信頼性を備えた旅行プラットフォームを構築します。求人情報
チームのバックエンドとテスト要件を募集しています。興味のあるパートナーはぜひご参加ください。下の QR コードをスキャンして履歴書を直接送信できます。ご参加をお待ちしています。
研究開発エンジニア
仕事内容：
1. ビジネスアーキテクチャの設計、開発、複雑さの制御、システムパフォーマンスと研究開発効率の改善など、関連ビジネスシステムの背景研究と開発を担当します。
2. ビジネス感覚を持ち、継続的な技術研究と革新を通じて、製品と運用とともにビジネスのコアデータを反復的に改善します。
テスト開発エンジニア
仕事内容：
1. オンライン配車事業に適用される品質保証システムを構築し、関連する高品質な技術ソリューションの策定と導入を推進し、事業品質を継続的に確保する。
2. ビジネスを深く理解し、ビジネス内のさまざまな役割とのコミュニケーションを確立し、ビジネス上の問題と問題点を要約し、総合的な方法でビジネスの価値を創造し、固定された境界線なく作業します。
3. 関連する品質インフラストラクチャを適用することで、ビジネス コードの品質と配信効率を向上させます。
4. 効率的なテスト ソリューションを考案し、他のビジネス分野へのアプリケーションの導入をサポートする汎用ソリューションを提供します。
5. ビジネス品質保証における困難な問題および複雑な技術的問題を解決する。
6. 高品質の技術分野における将来を見据えた探求。
