اختبار API قائم على البيانات باستخدام Apidog CLI: تكرارات CSV و JSON

لقد قمت ببناء سيناريو اختبار قوي لنقطة نهاية الدفع الخاصة بك. إنه يربط ثلاثة طلبات، ويؤكد على كل استجابة، ويمر في كل مرة تنقر فيها على "تشغيل". ولكن بعد ذلك، تحتاج مسار عملك (pipeline) إلى تغطية أربعين مجموعة من المدخلات، وسحب البيانات من ملف يحتفظ به قائد ضمان الجودة الخاص بك، وتشغيل نفس السيناريو مقابل بيئات الاختبار (staging) والإنتاج (production) باستخدام بيانات اعتماد مختلفة. التشغيل بنقرة زر الذي عمل على جهاز الكمبيوتر المحمول الخاص بك لا يترجم إلى ذلك، ولا تريد استنساخ السيناريو أربعين مرة.

هذا الميل الأخير هو ما يتعامل معه سطر الأوامر. باستخدام Apidog، يمكنك تأليف سيناريو اختبار مرة واحدة في المصمم المرئي، ثم تشغيله من الطرفية باستخدام حزمة apidog-cli. العلم (flag) الذي يحول سيناريو واحدًا إلى تشغيل يعتمد على البيانات هو -d، وهو اختصار لـ --iteration-data. يستقبل هذا العلم ملف CSV، أو ملف JSON، أو مجموعة بيانات قمت بتخزينها في مشروع Apidog الخاص بك، ويقوم بتشغيل السيناريو مرة واحدة لكل صف، مع ربط قيم كل صف بالمتغيرات التي تشير إليها طلباتك.

زر

كيف يقرأ العلم `-d` ملفًا

توجد الميزة بأكملها في خيار واحد. إليك الشكل الطويل والقصير، مباشرة من apidog run --help:

-d, --iteration-data <path|testDataId>   تحديد البيانات المستخدمة للتكرارات (إما JSON أو CSV)

هذا <path|testDataId> هو التفصيل الذي يفوته معظم الناس. الحجة (argument) محمّلة بشكل زائد. مرر إليها مسارًا وسيقرأ سطر الأوامر ملفًا محليًا من القرص. مرر إليها معرف بيانات اختبار (test-data ID) وسيستدعي سطر الأوامر مجموعة بيانات قمت بحفظها داخل مشروع Apidog الخاص بك. نفس العلم (flag)، مصدران، ويحدد المشغل أيهما سلمته إليه.

شكل الملف المحلي هو نقطة البداية الشائعة. وجهه إلى ملف بالنسبة للمكان الذي تشغل منه الأمر:

apidog run --access-token $APIDOG_ACCESS_TOKEN \
  -t 605067 -e 1629989 \
  -d ./test-data/checkout-cases.csv -r cli

يفتح سطر الأوامر checkout-cases.csv، ويعد الصفوف تحت الرأس، ويشغل السيناريو 605067 مرة واحدة لكل صف. في كل تمريرة، يربط الأعمدة بالمتغيرات المطابقة في طلباتك، ويطلق السيناريو، ويسجل نتيجة هذا التكرار. أربعين صفًا، أربعين تمريرة، سيناريو واحد.

يتبع التنسيق الملف. يقبل نفس العلم JSON دون أي خيار إضافي:

apidog run --access-token $APIDOG_ACCESS_TOKEN \
  -t 605067 -e 1629989 \
  -d ./test-data/checkout-cases.json -r cli

لا تخبر سطر الأوامر بالتنسيق الذي تستخدمه. فهو يقرأ الامتداد وشكل الملف. وهذا يعني أنه يمكنك تبديل CSV بمصفوفة JSON في منتصف المشروع دون لمس الأمر، طالما أن أسماء الأعمدة ومفاتيح JSON تتطابق مع المتغيرات التي يتوقعها السيناريو الخاص بك.

ما يتوقعه CLI داخل كل ملف

CSV هو التنسيق للحالات المسطحة والجداول. تسمي صفوف الرؤوس متغيراتك. كل صف أسفله هو تكرار واحد. إليك ملف checkout-cases.csv حقيقي لنقطة نهاية الخصم:

sku,quantity,coupon,expected_status,expected_total
DESK-01,1,SAVE10,200,89.10
DESK-01,0,SAVE10,422,0
CHAIR-09,3,,200,447.00
DESK-01,1,EXPIRED,410,0
GHOST-99,1,SAVE10,404,0

تصبح خمسة أعمدة خمسة متغيرات. داخل نص الطلب تكتب {{sku}} و {{quantity}}؛ وفي التأكيدات تقارن الاستجابة بـ {{expected_status}} و {{expected_total}}. يربط المشغل هذه القيم لكل صف. الخلية الفارغة coupon في الصف الثالث تصبح سلسلة فارغة، وهي بالضبط الحالة التي لا تحتوي على قسيمة والتي تريد تغطيتها.

JSON هو التنسيق عندما تحمل حالاتك بنية متداخلة تتسطح بشكل سيء في أعمدة. الملف عبارة عن مصفوفة من الكائنات، كائن واحد لكل تكرار:

[
  {
    "label": "valid order, two items",
    "order": {
      "items": [
        { "sku": "DESK-01", "qty": 1 },
        { "sku": "CHAIR-09", "qty": 2 }
      ],
      "shipping": { "country": "US", "method": "ground" }
    },
    "expected_status": 200
  },
  {
    "label": "unshippable country",
    "order": {
      "items": [{ "sku": "DESK-01", "qty": 1 }],
      "shipping": { "country": "ZZ", "method": "ground" }
    },
    "expected_status": 422
  }
]

داخل السيناريو، تشير إلى {{order}} و {{expected_status}} بنفس الطريقة، ويسلم المشغل حقول كل كائن إلى التكرار. الحقل label هو لك. يظهر في التقرير بحيث تقرأ "دولة غير قابلة للشحن" بدلاً من "التكرار 2" عند فشل التمريرة، وهو الفارق بين تشخيص مدته خمس ثوانٍ وآخر مدته خمس دقائق.

بعض القواعد تمنع هذه الملفات من أن تسبب لك المشاكل في التكامل المستمر (CI):

حافظ على أسماء الرؤوس متطابقة مع أسماء المتغيرات في السيناريو الخاص بك. عمود يسمى qty لن يربط بطلب يقرأ {{quantity}}. هذا عدم التطابق هو السبب الأكثر شيوعًا لفشل تشغيل يعتمد على البيانات محليًا وإنتاج قيم فارغة في مسار العمل (pipeline).
ضع علامة اقتباس حول أي حقل CSV يحتوي على فاصلة، أو انقل هذا الملف إلى JSON. حقل نص حر يحتوي على فاصلة ينقسم إلى عمودين ويحرك كل قيمة بعده.
ضع النتيجة المتوقعة في البيانات، وليس في السيناريو. الصف الأول يتوقع 200، الصف الرابع يتوقع 410. إذا قمت بترميز التوقع في التأكيد بشكل ثابت، فستعود إلى سيناريو واحد لكل حالة.
قم بتثبيت هذه الملفات بجانب تكوين الاختبار الخاص بك بحيث يتم إصدارها مع الكود الذي تختبره. ملف البيانات هو جزء من الاختبار، وليس قطعة أثرية فضفاضة.

بالنسبة لجانب JSONPath من كتابة التأكيدات التي تقرأ هذه القيم المرتبطة، فإن إعداد التأكيدات واستخراج المتغيرات من استجابة JSON يشرح التركيب بالتفصيل.

التشغيل من مجموعة بيانات مخزنة بدلاً من ملف

الشكل الثاني لـ -d هو الذي لا يظهر في معظم الإرشادات. بدلاً من المسار، تمرر معرف بيانات اختبار (test-data ID):

apidog run --access-token $APIDOG_ACCESS_TOKEN \
  -t 605067 -e 1629989 \
  -d 38291 -r cli

الآن، يستدعي سطر الأوامر مجموعة البيانات ذات هذا المعرف من مشروع Apidog الخاص بك بدلاً من قراءة ملف من قرص المشغل. هذا مفيد عندما تكون البيانات مع الفريق، وليس مع المستودع (repo). يحتفظ قائد ضمان الجودة بجدول الحالات داخل Apidog، ويقوم بتحريره في التطبيق، وتلتقط كل عملية تشغيل للتكامل المستمر (CI) الإصدار الحالي دون أن يقوم أي شخص بتثبيت ملف CSV. السيناريو والبيئة والبيانات كلها من جانب الخادم؛ يقوم الأمر فقط بتسميتها حسب المعرف.

المقايضة هي أين يقع مصدر الحقيقة الخاص بك. ملف CSV مثبّت يمنحك مجموعة بيانات قابلة للمقارنة في طلبات السحب ومثبتة على التثبيت الذي يتم اختباره. معرف بيانات اختبار مخزن يمنحك جدولًا مشتركًا واحدًا يقوم الجميع بتحريره في مكان واحد. لا يوجد خطأ في أي منهما. اختر الملف المثبت عندما يجب أن تتحرك البيانات بالتزامن مع الكود، والمعرف المخزن عندما يمتلك البيانات أشخاص لا يتعاملون مع المستودع.

التشغيل دون اتصال من ملف مُصدَّر

هناك طريقة ثالثة لتغذية CLI، وهي تغير شكل الأمر بأكمله. يمكنك تصدير حالة اختبار من Apidog كملف مستقل وتشغيل هذا الملف مباشرة، بدون معرف سيناريو وبدون رحلة ذهاب وعودة عبر الشبكة لاستدعاء السيناريو:

apidog run ./checkout.apidog-cli.json -r cli,html

هنا، الحجة الأولى هي file-source، وهي حالة الاختبار المصدرة نفسها، وليست علمًا (flag). يشغل CLI ما هو موجود في الملف. لا يزال بإمكانك إضافة بيانات التكرار باستخدام -d:

apidog run ./checkout.apidog-cli.json -d ./checkout-cases.csv -r cli,junit

هذا مهم لحالتين. الأولى هي مشغل التكامل المستمر (CI runner) المعزول هوائيًا أو المقيد الذي لا يمكنه الوصول إلى سحابة Apidog لحل معرف سيناريو؛ الملف المصدر يحمل كل ما يحتاجه التشغيل. والثانية هي قابلية إعادة الإنتاج: الملف المصدر هو لقطة مجمدة للسيناريو وقت التصدير، لذلك لا يتأثر التشغيل منه بقيام شخص بتحرير السيناريو في التطبيق لاحقًا. لتثبيت وتشغيل الآليات الأساسية لهذا، يغطي دليل تثبيت Apidog CLI كيفية إعداد الثنائي، و مرجع Apidog CLI الكامل يوثق كل علم في جدول واحد.

إقران `-d` مع `-n` وتجاوزات المتغيرات

نادرًا ما تسير عمليات التشغيل المعتمدة على البيانات بمفردها. هناك ثلاثة أعلام تقترن بـ -d باستمرار.

-n, --iteration-count تحدد عدد مرات تشغيل السيناريو. عندما تقوم بتزويد ملف بيانات، فإن عدد الصفوف يدفع بالفعل عدد التكرارات، لذلك عادةً ما تترك -n وتدع الملف يقرر. تلجأ إلى -n بشكل أساسي عندما تريد تشغيل الجدول أكثر من مرة، أو عندما تقوم بالتشغيل بدون ملف بيانات على الإطلاق، مثل اختبار التحمل (soak test) الذي يكرر سيناريو ثابتًا واحدًا:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -n 50 -r cli

--env-var و --global-var يحقنان أزواج key=value في وقت التشغيل دون لمس البيئة في مشروعك. هذه هي الطريقة التي تحافظ بها على الأسرار والتكوينات الخاصة بالمسار (per-pipeline config) خارج السيناريو وملف البيانات على حد سواء. يحتفظ ملف البيانات بحالات الاختبار؛ وتحتفظ التجاوزات (overrides) بالأشياء التي تتغير في كل عملية تشغيل:

apidog run --access-token $APIDOG_ACCESS_TOKEN \
  -t 605067 -e 1629989 \
  -d ./test-data/checkout-cases.csv \
  --env-var "base_url=https://staging.internal" \
  --global-var "api_key=$RUNTIME_API_KEY" \
  -r cli,junit

الانقسام متعمد. بيانات التكرار هي الجزء من التشغيل المتطابق في كل مكان: الحالات التي يجب أن تعالجها نقطة النهاية الخاصة بك. تجاوزات المتغيرات هي الجزء الذي يتغير لكل بيئة: المضيف، المفتاح، المستأجر. احتفظ ببيانات الاعتماد في مخزن أسرار CI الخاص بك ومررها عبر --global-var من متغير بيئة، بالطريقة التي يفعل بها $RUNTIME_API_KEY أعلاه. لا تقم أبدًا بتضمينها في CSV، حيث يمكن لأي شخص لديه حق الوصول إلى المستودع قراءتها.

قراءة النتائج لكل تكرار

لا يكون التشغيل المعتمد على البيانات مفيدًا إلا إذا تمكنت من معرفة الصف الذي فشل. تحدد أعلام المُبلغ (reporter flags) ما تحصل عليه في المقابل.

apidog run --access-token $APIDOG_ACCESS_TOKEN \
  -t 605067 -e 1629989 \
  -d ./test-data/checkout-cases.csv \
  -r cli,junit --out-dir ./test-reports

يطبع -r cli تفصيلاً قابلاً للقراءة لكل تكرار إلى الطرفية، وهو ما تقوم بمسحه في سجل البناء. يكتب -r junit ملف JUnit XML، وهو التنسيق الذي تحلله تقريبًا كل لوحة تحكم CI إلى شجرة نجاح/فشل، لذلك يظهر الصف الفاشل كاختبار فاشل مُسمى بدلاً من نص سجل مدفون. يمكنك تمرير html و json أيضًا؛ يمنح html تقريرًا قابلاً للتصفح لأرشفته كقطعة أثرية للبناء، ويمنح json إخراجًا منظمًا خامًا إذا قمت بمعالجة النتائج لاحقًا. يتحكم --out-dir في مكان هبوط الملفات حتى تتمكن من الاحتفاظ بها كقطع أثرية.

بشكل افتراضي، يتوقف التشغيل عند أول تأكيد معطل. بالنسبة لجدول بيانات واسع، غالبًا ما يكون هذا القرار خاطئًا، لأنك تريد رؤية كل صف فاشل في تمريرة واحدة، بدلاً من إصلاح واحد وإعادة التشغيل للعثور على التالي. قم بتبديل السلوك باستخدام --on-error:

apidog run --access-token $APIDOG_ACCESS_TOKEN \
  -t 605067 -e 1629989 \
  -d ./test-data/checkout-cases.csv \
  --on-error continue \
  -r cli,junit --out-dir ./test-reports

يؤدي --on-error continue إلى تشغيل كل تكرار حتى عندما تفشل التكرارات السابقة، بحيث يعرض لك تقرير واحد أن الصفوف الثاني والسابع والتاسع عشر معطلة في آن واحد. لا يزال التشغيل ينتهي برمز خروج غير صفري إذا فشل أي شيء، لذلك يظل بوابة حقيقية. --on-error end هو الافتراضي للفشل السريع للتحقق السريع (smoke check)؛ ignore مخصص للخطوة النادرة المعروفة بتقلبها التي لا تريد أن تعرقل التشغيل.

تصحيح خطأ ربط لا يفعل شيئًا بصمت

نمط الفشل الذي يهدر أكبر قدر من الوقت في التشغيل المعتمد على البيانات ليس تأكيدًا أحمر. إنه تشغيل أخضر لم يختبر شيئًا، لأن البيانات لم تربط بالطلب أبدًا. تم إطلاق الطلب بقيم فارغة، وأعادت نقطة النهاية 200 لحمولة فارغة، ومر التأكيد بالصدفة. تبدو التغطية جيدة؛ ولكنها ليست كذلك.

عندما يتصرف التشغيل المعتمد على البيانات بشكل غريب، أضف --verbose:

apidog run --access-token $APIDOG_ACCESS_TOKEN \
  -t 605067 -e 1629989 \
  -d ./test-data/checkout-cases.csv \
  --verbose -r cli

يطبع --verbose الطلب والاستجابة الكاملين لكل تكرار. انظر إلى نص الطلب الذي أرسله المشغل فعليًا. إذا رأيت {{sku}} موجودًا هناك دون استبدال، أو قيمة فارغة بينما خلية CSV لم تكن كذلك، فقد تعطل الربط. ثلاثة أسباب معتادة، حسب تكرار حدوثها:

اسم العمود واسم المتغير لا يتطابقان. رأس CSV هو product_sku والطلب يقرأ {{sku}}. أعد تسمية أحدهما ليكون متطابقًا.
فاصلة شاردة قسمت صف CSV. حقل نص حر غير مقتبس حرك كل عمود بعده، لذلك يحتوي expected_status الآن على ما يجب أن يكون في العمود التالي. ضع علامة اقتباس حول الحقل أو حول الملف إلى JSON.
مسار ملف البيانات خاطئ بالنسبة لدليل العمل في CI. يتم حله بشكل صحيح على جهاز الكمبيوتر المحمول الخاص بك ويقرأ شيئًا بصمت في المسار. استخدم مسارًا نسبيًا لجذر المستودع (repo root) الذي ينتجه خطوة السحب (checkout step)، وتأكد من وجود الملف في خطوة قبل التشغيل.

القاعدة العامة: عندما تمر التكرارات ولكن تشك في أنها لا ينبغي لها أن تمر، اقرأ طلبًا مطولًا واحدًا قبل أن تثق بالنتيجة الخضراء. الاختبار الذي يتم تشغيله مقابل إدخال فارغ أسوأ من عدم وجود اختبار، لأنه يخبرك أن كل شيء على ما يرام بينما تظل نقطة النهاية غير مختبرة.

ربطه بـ CI (التكامل المستمر)

المكافأة هي أن الجدول بأكمله يعمل مع كل تغيير دون أن ينقر أحد على "تشغيل". إليك مهمة GitHub Actions تقوم بتثبيت CLI وتشغيل سيناريو يعتمد على CSV عند كل طلب سحب:

name: Data-driven API tests
on: [pull_request]

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Install Apidog CLI
        run: npm install -g apidog-cli
      - name: Run data-driven scenario
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
        run: |
          apidog run --access-token $APIDOG_ACCESS_TOKEN \
            -t 605067 -e 1629989 \
            -d ./test-data/checkout-cases.csv \
            --on-error continue \
            -r cli,junit --out-dir ./test-reports
      - name: Upload report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: api-test-report
          path: ./test-reports

يأتي الرمز المميز من secrets.APIDOG_ACCESS_TOKEN، الذي يتم تعيينه مرة واحدة في إعدادات المستودع (repo settings). يقوم --on-error continue بجمع كل الصفوف الفاشلة في تقرير واحد بدلاً من التوقف عند الأول. يحافظ if: always() على التحميل على التقرير حتى عندما يفشل التشغيل، وهو الوقت الذي ترغب فيه بقراءته أكثر من غيره. استبدل مسار CSV بملف JSON، أو بمعرف بيانات اختبار مخزن، ولن يتغير شيء آخر.

تنتقل نفس الخطوات الثلاث إلى أي نظام CI: تثبيت Node.js و CLI، كشف الرمز المميز كمتغير بيئة، استدعاء apidog run باستخدام -d. لا تحتاج أنظمة GitLab CI و Jenkins و CircleCI وغيرها إلى إعادة كتابة اختباراتك لكل منصة. للحصول على شرح أعمق لجانب Actions، انظر أتمتة اختبارات API في GitHub Actions، وللحصول على سطح العلم الكامل لـ CLI عبر التقارير ومعالجة الأخطاء و TLS، يقدم دليل Apidog CLI الكامل كل خيار.

سير عمل يتوسع دون زيادة الاختبار

ابدأ بسيناريو واحد وثلاثة صفوف. أنشئ السيناريو في التطبيق مع مراجع المتغيرات في الطلبات والنتائج المتوقعة في التأكيدات. اكتب ملف CSV يحتوي على مسار سليم، وفشل معروف، وحالة حدودية واحدة. قم بتشغيله محليًا باستخدام -d حتى تتصرف التكرارات الثلاثة جميعها بشكل صحيح.

ثم قم بتوسيع البيانات، وليس السيناريو. يصبح كل تقرير خطأ صفًا جديدًا مع مخرجه المتوقع الصحيح. يتحول الخطأ إلى حالة تراجع دائمة، ولم تكتب اختبارًا جديدًا أبدًا؛ لقد أضفت سطرًا إلى ملف. على مدار بضعة أشهر، يجمع هذا الملف المشاكل الحقيقية التي تواجهها نقطة النهاية الخاصة بك في الإنتاج.

أخيرًا، ضع أمر apidog run -d في CI مع --on-error continue ومُبلِّغ junit. الآن، أي تغيير يؤدي إلى كسر صف القسيمة المنتهية الصلاحية سيفشل عملية البناء لحظة دفعه، مع تكرار مُسمى يشير مباشرة إلى الحالة المعطلة. يظل السيناريو شيئًا صغيرًا وسهل القراءة بغض النظر عن مدى اتساع الجدول. هذا هو الفوز المركب: تنمو التغطية بإدخال البيانات، وتبقى الصيانة ثابتة.

إذا كنت لا تزال تقرر ما إذا كان مشغل سطر الأوامر مثل هذا يناسب مجموعتك التقنية مقارنة بإطار عمل يعتمد على الكود أولاً، فإن الشرح في الأداة التي يجب اختيارها لاختبار API المعتمد على البيانات باستخدام CSV أو JSON يقارن بين النهجين، و Apidog CLI مقابل Newman يغطي أقرب نظير لسطر الأوامر من عالم Postman.

أسئلة مكررة

هل يمكن لـ -d أن يأخذ كلاً من مسار ملف ومجموعة بيانات مخزنة؟ يقبل العلم -d أحدهما فقط لكل تشغيل: مسار CSV أو JSON محلي، أو معرف بيانات اختبار يشير إلى مجموعة بيانات محفوظة في مشروع Apidog الخاص بك. أنت تمرر قيمة واحدة. استخدم مسار الملف عندما يجب أن يتم إصدار البيانات مع مستودعك، والمعرف المخزن عندما يكون الجدول المشترك موجودًا في التطبيق ولا تريد تثبيت نسخة منه.

هل يجب علي أن أخبر CLI ما إذا كان ملفي هو CSV أو JSON؟ لا. يقرأ المشغل التنسيق من الملف نفسه، لذا فإن نفس العلم -d يتعامل مع كليهما. حافظ على تطابق أسماء أعمدتك (CSV) أو مفاتيح كائناتك (JSON) مع أسماء المتغيرات التي يشير إليها السيناريو الخاص بك، ويمكنك تبديل التنسيقات دون تغيير الأمر.

ماذا يحدث إذا استخدمت -d و -n معًا؟ يحدد عدد صفوف ملف البيانات عدد التكرارات، لذا فإن -n عادة ما يكون غير ضروري مع -d. الجأ إلى -n عندما تريد تكرار تشغيل بدون ملف بيانات، مثل اختبار التحمل (soak test)، أو عندما تريد تحديدًا تشغيل الجدول بأكمله أكثر من مرة.

لماذا نجح تشغيلي المعتمد على البيانات دون اختبار أي شيء؟ السبب الأكثر شيوعًا هو حدوث ربط لم يحدث أبدًا: اسم عمود لا يتطابق مع اسم المتغير، أو مسار ملف خاطئ في CI لم يقرأ شيئًا. قم بالتشغيل مرة واحدة باستخدام --verbose وافحص نص الطلب الذي أرسله CLI. إذا رأيت {{variables}} غير مستبدلة أو قيمًا فارغة، فقم بإصلاح عدم تطابق الاسم أو المسار قبل الوثوق بالنتيجة الخضراء.

كيف أحافظ على بيانات الاعتماد خارج ملف البيانات الخاص بي؟ احتفظ بالرموز والمفاتيح خارج ملف CSV أو JSON تمامًا. مررها في وقت التشغيل باستخدام --global-var أو --env-var من مخزن الأسرار الخاص بـ CI الخاص بك، بالطريقة التي تمرر بها --global-var "api_key=$RUNTIME_API_KEY". يجب أن يحتوي ملف البيانات على مدخلات الاختبار والنتائج المتوقعة، ولا شيء يوثق التشغيل.

هل يمكنني تشغيل نفس البيانات مقابل بيئات الاختبار والإنتاج؟ نعم. حافظ على السيناريو وملف البيانات ثابتين وقم بتبديل الهدف باستخدام -e. وجه فحص طلب السحب إلى معرف بيئة الاختبار واختبار الدخان (smoke test) بعد النشر إلى الإنتاج باستخدام نفس السيناريو ونفس البيانات، فقط بقيمة -e مختلفة. فصل البيئة عن البيانات هو السبب الرئيسي لعمل هذا.

الخلاصة

العلم -d هو القصة الكاملة للتشغيل المعتمد على البيانات في Apidog CLI، وهو أكثر مرونة مما يبدو عليه للوهلة الأولى. إنه يقرأ ملف CSV أو JSON محليًا، أو مجموعة بيانات مخزنة في مشروعك بواسطة معرف (ID). يقترن بـ -n للتكرارات، وبـ --env-var و --global-var للتكوين لكل تشغيل، وبـ --on-error continue بحيث يعرض تشغيل واحد كل صف فاشل. قم بتشغيله من معرف سيناريو عبر الإنترنت أو من ملف مُصدَّر دون اتصال، واقرأ النتائج لكل تكرار من خلال مُبلِّغي junit و cli.

قم ببناء السيناريو مرة واحدة، وصِف كل حالة كصف، ودع المشغل يوسع تغطيتك في كل مرة يضيف فيها شخص ما سطرًا إلى الملف. قم بتنزيل Apidog، ووجه apidog run إلى أول ملف بيانات لك، وحوّل سيناريو واحدًا إلى جدول من الحالات التي تعمل مع كل عملية دفع (push).

كيف يقرأ العلم -d ملفًا