غيّر ظروف الشبكة مع الوقت

السيناريو جدول زمني

ملف JSON واحد. تقول كل خطوة في هذه الثانية، هذه الإعدادات، وما لا تذكره يحتفظ بقيمته:

{
  "loop": true,
  "steps": [
    {"at": 0,  "settings": {"latency": 20, "jitter": 15, "down": 4096}},
    {"at": 20, "settings": {"loss": 8, "latency": 180}},
    {"at": 45, "settings": {"block_ip": "203.0.113.0/24"}},
    {"at": 65, "settings": {"block_ip": "", "loss": 0, "latency": 20}}
  ]
}

الأزمنة ثوانٍ منذ بداية التشغيل، لا فجوات بين الخطوات. ومع "loop": true يبدأ الجدول من جديد حين ينتهي، وهذا ما تريده لاختبار تحمّل طويل: اتركه يعمل واستخدم التطبيق.

BeanNetworkTester.exe --scenario cafe-wifi.json --target myapp.exe

عدد السيناريوهات الجاهزة في البرنامج: 8

في مجلد scenarios بجوار الملف التنفيذي. مقروءة من هذه الملفات، فهذا هو ما لديك فعلًا:

هي نصوص عادية: افتح ملفًا، وغيّر رقمًا، واحفظ. وتقول الأسماء ما تعيد إنتاجه: مقهى مزدحم، واتصال جوال يهبط من LTE إلى 3G، ورفع يموت في منتصفه، وخادم يُثقل عليه، وDNS يتوقف عن الإجابة.

طريقتان أبسط لإحداث التغيير

يستحق السيناريو أن يُكتب حين يهم التسلسل. وحين لا يهم، يتغير إعدادان من تلقاء نفسيهما:

• تشغيل الوصلة وإيقافها: طول دورة وكم منها انقطاع. دورات من عشر ثوانٍ، أربع منها انقطاع، إلى الأبد.
• جدول السرعة: سلسلة من السرعات يمر بها الحد، فيتدهور الاتصال ويتعافى دون ملف.

BeanNetworkTester.exe --flap-period 10 --flap-down 40 --target myapp.exe

لماذا يعمل أثناء تشغيل التطبيق

كل إعداد يمسّه السيناريو يُطبَّق مباشرة على الجلسة الجارية: لا يحتاج التطبيق إلى إعادة تشغيل ولا الأداة. يسجّل سجل الأحداث كل خطوة حين تحدث، فإذا انكسر شيء رأيت أي تغيير سبقه. اقرن ذلك بـ seed فيتكرر التسلسل كله، بما في ذلك الفقدان العشوائي داخله، بدقة.

التالي

• التنزيل
• فقدان الحزم
• زمن الاستجابة والجيتر
• تحديد السرعة
• استهداف تطبيق واحد
• بلا إنترنت
• قطع الاتصالات
• اختبارات الشبكة في CI
• تأخر الألعاب
• بديل Clumsy
• اختبار الفوضى
• أسئلة وأجوبة
• جداول مرجعية