كما قلت بالفعل في الجزء الأخير ، عند تطوير مشروع إنترنت الأشياء ، فإن بروتوكولات التفاعل مع الأجهزة غير مستقرة إلى حد ما ، وكانت فرص فقدان الاتصال بأجهزة الاختبار بعد تحديث البرامج الثابتة كبيرة جدًا. شاركت العديد من الفرق في التطوير ، وكان هناك مطلب صارم - ألا تفقد القدرة على اختبار طبقة الأعمال للتطبيق ، حتى إذا أدى وميض الأجهزة إلى كسر التدفق الكامل للعمل مع أجهزة الاستشعار.
لكي يقوم محللو الأعمال باختبار فرضياتهم حول البيانات التي تشبه الواقع إلى حد ما ، قمنا ببناء نموذج محاكاة للجهاز. وبالتالي ، إذا تعطل الجهاز بسبب البرامج الثابتة الجديدة ، وكانت هناك حاجة إلى تلقي البيانات بشكل عاجل ، فقد أطلقنا نموذج محاكاة بدلاً من جهاز حقيقي على الشبكة ، والذي ، وفقًا للصيغة القديمة ، قاد البيانات وأنتج النتيجة.أيضًا ، كانت ميزة النموذج هي أن الشركة لن تشتري أبدًا مجموعة كبيرة من الأجهزة لمجرد اختبار الفرضية. على سبيل المثال ، قرر فريق تحليل الأعمال أن التنبؤ بوقت ملء الحاوية يجب أن يعمل بشكل مختلف. ولاختبار فرضيتهم ، لن يركض أحد لشراء 10000 جهاز استشعار.تطوير نموذج المحاكاة
كان نموذج المحاكاة نفسه كما يلي: يتم وصف
حالة وسلوك سلة المهملات بواسطة آلة حالة عادية. أولاً ، نقوم بتهيئة جهاز الحالة بالحالة `EMPTY (المستوى = 0)` ويمكننا تنفيذ بعض الإجراءات عليه ، أي رمي القمامة في الحاوية. تحتاج الآن إلى تحديد ما إذا كانت الحاوية لا تزال فارغة `((المستوى؟ MAX_LEVEL)` أم أنها ممتلئة` (المستوى> = MAX_LEVEL) `. إذا كانت الثانية ، تتغير الحالة إلى `FULL`.يمكن لشخص ما أن يفرغ القمامة من حاوية ممتلئة ، أو أن البواب قد حان لتنظيف فوضى ، ونحن بحاجة إلى تحديد الحالة التي ننتقل إليها. إن حالة `CHOICE` مسؤولة عن اختيار إجراء - في مصطلحات آلة الحالة ، شيء مشابه لكتلة if.قد يتم حرق حاوية أخرى ، ثم تتغير حالة حالة الجهاز إلى "الحريق". أيضا ، قد تسقط الحاوية ، ويصبح حالتها `FALL` (في التقرير تحدثت عن الأسباب غير المتوقعة التي قد تسببها قطرات الحاوية). ولكن هناك حالة `LOST` أخرى ، صالحة من أي دولة أخرى - يتم تعيينها عند فقد الاتصال.تصف آلة الحالة هذه كل سلوك الحاوية والمستشعر تقريبًا. لكن هذا لا يكفي لصنع نموذج محاكاة ، لأننا نعرف عن الحالات والتحولات المحتملة منها ، لكننا لا نعرف ما هو احتمال هذه الأحداث ومتى ستحدث.في الواقع ، اتضح أن احتمال وقوع الأحداث يعتمد على الوقت من اليوم ، لأنه:- لا تعمل شركات النقل ليلاً ؛
- يرمي الناس المزيد من القمامة في ساعات معينة (في الصباح قبل العمل وفي المساء).
لذلك ، جعلنا من الممكن لفريق تحليل الأعمال تخصيص سلوك المحاكاة. كان من الممكن تحديد احتمال وقوع حدث في وقت معين من اليوم.اختبار ضغط بسيط وبديهي
التقليد في حد ذاته له العديد من المزايا ، أحدها اختبار الحمل الرخيص. إنه رخيص لأن التقليد ، في الواقع ، هو خيط منفصل يبدأ تشغيل جهاز الحالة ، ويطبق الأحداث عليه ، ويتم إرسال الأحداث نفسها إلى الخادم الحقيقي.لذلك ، لا تختلف محاكاة الواجهة الخلفية عن المستشعر الحقيقي. وإذا كنا بحاجة إلى تشغيل 1000 مستشعر ، فقم بتشغيل 1000 خيط وعمل. بالإضافة إلى ذلك ، تتم محاكاة المحاكاة بشكل مثالي.
من ناحية ، من الصعب اختبار الحمل ، ولكن من ناحية أخرى ، جعلت المحاكاة من الممكن دفع الكثير من البيانات قريبة من الواقع للمشروع بأكمله. ولا تنسى المطورين الصينيين الموهوبين الذين تجاهلوا البروتوكولات القياسية مثل MQTT وشاهدوا بروتوكولهم في أعلى المقابس. لذلك ، كان علينا أن نقوم بتنفيذنا الخاص لخادم يقبل البيانات على مآخذ التوصيل بموجب هذا البروتوكول الخاص.يجب أن يكون هذا الخادم متعدد الخيوط ، نظرًا لوجود العديد من مستشعرات الإدخال. كما يجب اختبار هذا الجزء بشكل منفصل باستخدام اختبارات الأداء. يمكنك أن تأخذ JMeter (كتابة نص اختبار نموذجي) ، JMH / JCStress (اختبار الأجزاء المعزولة ووضع مقياس أرق) ، أو أي شيء آخر خاص بك. عندما تتخذ قرارًا في موقف مماثل ، أنصحك بالاستماع إلى المحترفين ، على سبيل المثال ، Alexei Shipilev. في JPoint 2017 ، تحدث بشكل رائع للغاية عن كيفية قياس الأشياء المختلفة وما تحتاج إلى التفكير فيه عند إجراء اختبار الأداء.لقد اخترنا خيار القيام بشيء خاص بنا ، حيث كان للمشروع نهج غير اعتيادي لضمان الجودة - ليس لدينا فريق منفصل من المختبرين ، واختبر فريق الواجهة الخلفية الوظيفة. أي أن الشخص الذي كتب خادم مأخذ التوصيل كان عليه تغطية الرمز بالوحدات العادية واختبارات التكامل والأداء.كان لدينا أداة صغيرة سمحت لنا بوصف سيناريو الحمل بسرعة وتشغيله بالكمية المناسبة من الخيوط المتوازية:StressTestRunner.test()
.mode(ExecutionMode.EXECUTOR_MODE)
.threads(THREADS_COUNT)
.iterations(MESSAGES_COUNT)
.timeout(5, TimeUnit.SECONDS)
.run(() -> sensor.send(MESSAGE));
Awaitility.await()
.atMost(5, TimeUnit.SECONDS)
.untilAsserted(() ->
verifyReceived(MESSAGES_COUNT)
);
نقول كم عدد سلاسل المحادثات التي تحتاج إلى تشغيلها ، وعدد الرسائل المطلوب إرسالها ، والوقت الذي تستغرقه ، وإرسال البيانات إلى المقبس في كل سلسلة رسائل. يبقى فقط انتظار خادمنا لمعالجة جميع هذه البيانات بشكل صحيح. تم إصدار بضعة أسطر فقط من التعليمات البرمجية التي يمكن كتابتها بواسطة أي مطور خلفية.مضاهاة مشاكل الشبكة
بمساعدة التقليد ، تمكنا من محاكاة كل من الجودة الرديئة والعمل المحدد باستخدام المقابس. لا تحتوي بطاقات SIM SIM في أجهزة الاستشعار على عناوين IP "بيضاء" ، ويمكننا تلقي البيانات من عناوين IP مختلفة 50 مرة في اليوم. وغالبًا ما حدث أنه تم فتح الاتصال ، وبدأنا في نقل البيانات ، ثم تغير عنوان IP ، وفتح الخادم اتصالًا جديدًا دون إغلاق الاتصال القديم. إذا لم نأخذ ذلك في الاعتبار ، فسيتم نفاد المنافذ المجانية على الخادم في غضون يومين.
كانت هناك أيضًا مشكلة في أجهزة استشعار السرعة المختلفة. قد يفتح الجهاز البطيء الاتصال ويتجمد لفترة ، بينما سيرسل الجهاز السريع شيئًا ما. وكل هذا يحتاج إلى معالجته بشكل صحيح. في التقليد ، من السهل محاكاة موقف مماثل باستخدام التوقفات.
هذا ليس سوى جزء من السيناريوهات التي يمكن دمجها في النموذج.الموجودات
يبدو لي أن إمكانية المحاكاة هي التي تميز بشدة إنترنت الأشياء عن المشاريع الأخرى. محاكاة سلوك الجهاز أسهل من سلوك الإنسان. عند المدخلات ، نحصل على قيم حتمية ترتبط بشكل جيد مع نموذجنا ، وليس الأفعال البشرية العشوائية. لأن سلوك الأجهزة أسهل منطقيًا في الوصف من سلوك الأشخاص ، ويصبح اختبار النظام أسهل.نظرنا إلى عدد غير قليل من الجوانب المختلفة للتطور في إنترنت الأشياء.
إذا تخطيت الجزءين السابقين من هذه المقالة ، فيمكنك العثور عليها هنا:إنترنت الأشياء حيث لم تنتظر (الجزء 1) - مجال الموضوع ومشكلاتإنترنت الأشياء حيث لم تنتظر (الجزء 2) - بنية التطبيق واختبار إنترنت الأشياء لأشياء محددةجيثب مع أدوات الاختبار المعنية.. , Heisenbug , IoT. , ! JPoint, . Heisenbug JPoint 6 . !