الفرق بين بوستمان وجي ميتر

غالبًا ما يصنف الناس Postman و JMeter كمتنافسين ويتساءلون أيهما يفوز. هذا التصنيف خاطئ. يتحقق Postman مما إذا كانت واجهة برمجة التطبيقات (API) تتصرف بشكل صحيح. ويتحقق JMeter مما إذا كانت واجهة برمجة التطبيقات تتحمل حركة المرور. أحدهما يجيب على سؤال "هل تُرجع نقطة النهاية هذه البيانات الصحيحة؟" والآخر يجيب "هل تبقى نقطة النهاية هذه مستقرة عندما يصل إليها 2000 مستخدم في وقت واحد؟" إنهما يقعان في نقاط مختلفة من دورة حياة الاختبار.

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

ما الذي صُمم Postman لأجله

Postman هو عميل واجهة برمجة تطبيقات (API) ومنصة تعاون. تقوم بإنشاء الطلبات، وتنظيمها في مجموعات، وإرفاق متغيرات البيئة، وكتابة نصوص اختبار JavaScript التي تعمل بعد كل استجابة. وظيفته الأساسية هي التحقق من الصحة الوظيفية: التحقق من رموز الحالة، ونصوص الاستجابة، والرؤوس، وشكل المخطط (Schema).

يبدو نص اختبار Postman النموذجي كما يلي:

pm.test("Status is 200", function () {
    pm.response.to.have.status(200);
});

pm.test("Response has a user id", function () {
    const body = pm.response.json();
    pm.expect(body).to.have.property("id");
    pm.expect(body.id).to.be.a("number");
});

هذا اختبار يعتمد على تأكيد الطلبات الفردية. يقوم Postman بتشغيل كل طلب مرة واحدة، ويقيم فحوصاتك، ويبلغ عن النجاح أو الفشل. يمكن لـ Collection Runner تكرار مجموعة بملفات بيانات، ويقوم Postman CLI بتشغيل نفس المجموعات في مسار، لكن التوجه يظل كما هو: تأكيد أن واجهة برمجة التطبيقات تفعل ما ينص عليه العقد. إذا كنت تريد نظرة أعمق على كتابة هذه الفحوصات، فراجع دليلنا حول تأكيدات واجهة برمجة التطبيقات.

يتألق Postman خلال التطوير والتكامل. يقوم المطور الذي يبني نقطة نهاية جديدة بالتحقق منها بشكل تفاعلي. يحول مهندس ضمان الجودة (QA) هذه الطلبات إلى مجموعة اختبار تراجعي. يشارك الفريق بأكمله مساحة عمل واحدة. لا شيء من ذلك يتضمن قياس الإنتاجية.

ما الذي صُمم JMeter لأجله

Apache JMeter هي أداة لاختبار التحميل والأداء. تقوم بتعريف مجموعة خيوط (Thread Group)، وهي مصطلح JMeter لمجموعة من المستخدمين المحاكين، وتحدد عدد الخيوط التي تعمل، وسرعة زيادتها التدريجية، وعدد مرات تكرارها. ثم يقوم JMeter بإطلاق تلك الطلبات بشكل متزامن ويسجل زمن الاستجابة، والإنتاجية، ومعدل الخطأ.

الأسئلة التي يجيب عليها JMeter كمية. ما هو وقت الاستجابة للمئوي الخامس والتسعين عندما يكون 500 مستخدم نشطًا؟ عند أي معدل طلب يتجاوز معدل الخطأ 1 بالمائة؟ هل تصبح مجموعة اتصالات قاعدة البيانات عنق زجاجة عند 300 جلسة متزامنة؟ لا يمكنك الحصول على هذه الأرقام من أداة ترسل طلبًا واحدًا في كل مرة.

يتجاوز JMeter أيضًا بروتوكول HTTP. يمكنه تشغيل استعلامات قواعد بيانات JDBC، ورسائل JMS، و FTP، و SMTP، و TCP الخام. هذا النطاق الواسع مهم عندما تختبر نظامًا بأكمله بدلاً من نقطة نهاية REST واحدة. التكلفة هي إعداد أكثر صعوبة: يتم تكوين مجموعات الخيوط (Thread Groups)، والعينات (samplers)، والمستمعين (listeners)، والمؤقتات (timers)، والتأكيدات (assertions) من خلال واجهة المستخدم الرسومية لسطح المكتب، وتحدث التشغيلات الجادة في وضع عدم وجود واجهة رسومية (non-GUI mode) من سطر الأوامر من أجل الدقة. إذا كنت جديدًا في هذا المجال، فإن نظرة عامة على اختبار الأداء تشرح المقاييس الأساسية.

مقارنة جنبًا إلى جنب

يعرض الجدول أدناه الفروق العملية.

الفرق الأبرز هو نموذج التزامن. يقوم Collection Runner في Postman بالتكرار، لكنه لا يحاكي مئات المستخدمين وهم يضغطون على نقطة نهاية في نفس اللحظة. هندسة JMeter بأكملها موجودة للقيام بذلك بالضبط.

متى تستخدم Postman

استخدم Postman عندما يكون السؤال المطروح هو "الصحة" (Correctness). استخدمه عندما تقوم بتطوير نقطة نهاية جديدة وتحتاج إلى ملاحظات سريعة حول شكل الطلب والاستجابة. استخدمه لبناء مجموعة اختبار تراجعي (regression suite) تعمل على كل طلب سحب (pull request). استخدمه عندما يحتاج غير المطورين في الفريق إلى استكشاف واجهة برمجة تطبيقات دون كتابة تعليمات برمجية. استخدمه لـ اختبار العقود، حيث تؤكد أن واجهة برمجة التطبيقات لا تزال تتطابق مع مخططها المنشور.

يتناسب Postman أيضًا مع التكامل المستمر. يمكنك تصدير مجموعة، وتشغيلها باستخدام Postman CLI أو Newman داخل مسار عملك، وإفشال البناء إذا فشل تأكيد ما. هذا هو تراجع وظيفي، وليس اختبار تحميل، وينتمي إلى كل التزام (commit).

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

قراءة نتيجة JMeter

ينتج تشغيل JMeter أرقامًا، وعليك أن تعرف الأرقام المهمة. متوسط وقت الاستجابة هو الأقل فائدة بينها، لأن بعض الطلبات السريعة يمكن أن تخفي عددًا كبيرًا من الطلبات البطيئة. الأرقام التي يجب الانتباه إليها هي المئويات. تخبرك أزمنة الاستجابة للمئويات 90 و 95 و 99 بما يواجهه أبطأ المستخدمين لديك، وهؤلاء هم المستخدمون الذين يشتكون. تعني المئوية 95 التي تبلغ 1.8 ثانية أن 5 بالمائة من الطلبات استغرقت وقتًا أطول من ذلك، وهي مشكلة حقيقية حتى لو بدا المتوسط جيدًا.

الإنتاجية هي الرقم الثاني. وهي عدد الطلبات التي أكملها النظام في الثانية، وتخبرك بالقدرة الفعلية لواجهة برمجة التطبيقات تحت الحمل الذي طبقته. معدل الخطأ هو الرقم الثالث. التشغيل الذي يُبلغ عن أوقات استجابة سريعة ولكن بمعدل خطأ 6 بالمائة ليس نجاحًا؛ فهذا يعني أن واجهة برمجة التطبيقات استمرت في العمل فقط عن طريق إسقاط الطلبات. تقرأ الثلاثة معًا، وتقرأها عند مستوى التزامن الذي يتناسب مع حركة المرور الحقيقية لديك. اختبار بـ 50 مستخدمًا لا يخبرك شيئًا عن السلوك عند 1000 مستخدم.

متى تستخدم JMeter

استخدم JMeter عندما يكون التوسع هو السؤال المطروح. استخدمه قبل الإطلاق لتحديد معدل الطلبات الذي تتدهور عنده أوقات الاستجابة. استخدمه للتحقق من أن قواعد التحجيم التلقائي (autoscaling) تعمل بشكل صحيح تحت حركة المرور المستمرة. استخدمه لاختبارات التحمل (soak tests) التي تعمل لساعات للكشف عن تسرب الذاكرة واستنزاف الاتصالات. استخدمه لاختبارات الذروة (spike tests) التي تحاكي تدفقًا مفاجئًا للمستخدمين، مثل بيع فوري.

تغذي نتائج JMeter تخطيط السعة. إذا ظل زمن الاستجابة للمئوية 95 أقل من 400 مللي ثانية عند 1000 مستخدم متزامن ولكنه ارتفع إلى أكثر من 2 ثانية عند 1500، فقد وجدت الحد الأقصى لديك. هذا الرقم يدفع قرارات البنية التحتية. لا يمكن لتشغيل Postman أن ينتج ذلك. للحصول على شرح مفصل لبناء هذه الاختبارات، يغطي البرنامج التعليمي لاختبار أداء واجهة برمجة التطبيقات سير العمل من البداية إلى النهاية.

هما مكملان، وليسا متنافسين

تستخدم استراتيجية الاختبار الناضجة كليهما. أثناء التطوير، يتحقق Postman من أن واجهة برمجة التطبيقات تُرجع بيانات صحيحة. قبل الإصدار، يتحقق JMeter من أن واجهة برمجة التطبيقات تقدم تلك البيانات الصحيحة بالسرعة الكافية للجمهور المتوقع. تخطي أي منهما يترك فجوة. يمكن أن تكون واجهة برمجة التطبيقات مثالية وظيفيًا ومع ذلك تنهار عند 200 مستخدم. يمكن أن تكون واجهة برمجة التطبيقات سريعة جدًا ومع ذلك تُرجع قيمًا خاطئة.

النموذج الذهني الصحي هو مسار عمل (pipeline). تعمل الفحوصات الوظيفية مبكرًا وبشكل متكرر، عند كل التزام (commit)، لتحديد أي تراجعات في السلوك. تعمل اختبارات التحميل بشكل أقل تكرارًا، قبل الإصدارات أو بعد تغييرات البنية التحتية الرئيسية، لتحديد أي تراجعات في السعة. عاملهم كمرحلتين، وليس كمرشحين اثنين لخانة واحدة.

لنأخذ مثالاً ملموسًا. يقوم فريق بإطلاق نقطة نهاية للبحث. تؤكد اختبارات Postman أنها تُرجع النتائج الصحيحة، وتعمل بترقيم الصفحات بشكل صحيح، وترفض الاستعلامات المشوهة. كل الفحوصات خضراء، لذا يتم دمج نقطة النهاية. بعد أسبوعين، تؤدي حملة تسويقية إلى زيادة حركة المرور عشرة أضعاف المعدل المعتاد، وترتفع أوقات البحث إلى ثماني ثوانٍ لأن كل استعلام يؤدي إلى فحص قاعدة بيانات غير مفهرسة. لم تحظى الاختبارات الوظيفية بفرصة لالتقاط هذا؛ فقد أرسلت طلبًا واحدًا إلى نظام خامد. كان تشغيل JMeter بتزامن واقعي سيكشف الفهرس المفقود قبل الإطلاق. الدرس ليس أن Postman فشل. بل إن الفريق أجرى نوعًا واحدًا فقط من الاختبارين اللذين كانت نقطة النهاية بحاجة إليهما.

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

أين يتناسب Apidog

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

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

الأسئلة الشائعة

هل يمكن لـ Postman إجراء اختبار التحميل؟

ليس بطريقة مجدية. يقوم Collection Runner بتكرار مجموعة بشكل تسلسلي، وقد أضاف Postman مؤخرًا ميزة أساسية لاختبار الأداء في تطبيق سطح المكتب، لكنها لا تتطابق مع أداة مصممة خصيصًا للتزامن الواقعي، والتحكم في الزيادة التدريجية، أو المئويات التفصيلية لوقت الاستجابة. لاختبار التحميل الجاد، استخدم JMeter أو k6 أو Gatling أو وحدة اختبار الأداء في Apidog.

هل يمكن لـ JMeter إجراء اختبار واجهة برمجة التطبيقات الوظيفي؟

يمكنه ذلك، باستخدام تأكيدات الاستجابة (Response Assertions) التي تتحقق من رموز الحالة ومحتوى النص. لكن واجهة JMeter الرسومية غير ملائمة لمجموعات الاختبار الوظيفية التي تعتمد بشكل كبير على التأكيدات، وقوته تكمن في التزامن، وليس في فحوصات الصحة. تحتفظ معظم الفرق بالاختبار الوظيفي في Postman أو Apidog وتخصص JMeter للتحميل.

هل JMeter أصعب في التعلم من Postman؟

نعم. واجهة Postman سهلة الاستخدام، ويمكنك إرسال طلب في غضون دقائق. يقدم JMeter مفاهيم مجموعات الخيوط (Thread Groups)، والعينات (samplers)، والمؤقتات (timers)، والمستمعين (listeners)، بالإضافة إلى ممارسة تشغيل الاختبارات في وضع عدم وجود واجهة رسومية (non-GUI mode) للحصول على نتائج دقيقة. توقع فترة تعلم أطول، خاصة إذا لم تكن قد قمت بأعمال أداء من قبل.

هل أحتاج إلى كلتا الأداتين؟

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

أي أداة تكتشف استعلام قاعدة بيانات بطيء؟

JMeter، تحت التحميل. قد يعود طلب Postman واحد ضد نظام خامد بسرعة حتى عندما يكون الاستعلام غير فعال. تظهر المشكلة فقط عندما تتنافس حركة المرور المتزامنة على اتصالات قاعدة البيانات. يكشف تزامن JMeter عن عنق الزجاجة هذا؛ بينما الاختبار الوظيفي التسلسلي عادة لا يكشفه.

أين تتناسب k6 و Gatling و Locust؟

إنها بدائل لـ JMeter، وليست لـ Postman. تعتبر k6 و Gatling و Locust جميعها أدوات لاختبار التحميل تتنافس مع JMeter وتميل إلى تفضيل الاختبارات المحددة بالكود على الواجهة الرسومية. إذا وجدت واجهة JMeter غير مريحة، فإن أيًا منها يستحق النظر فيه. لا يحل أي منها محل اختبار واجهة برمجة التطبيقات الوظيفي، لذا لا يزال الانقسام بين Postman وأدوات التحميل قائمًا.

كم مرة يجب أن أقوم بإجراء اختبارات التحميل؟

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