نظام IBM i (المعروف أيضًا باسم AS / 400) - كيف قمنا بإجراء اختبارات تلقائية لتطبيق الشاشة الخضراء

تحية! اسمي أنطون فوروبيوف ، أنا مسؤول في بنك ألفا عن تطوير التطبيقات لنظام مصرفي مركزي.

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



وُلد نظام AS / 400 (نظام التطبيق / 400) في عام 1988. أول نظام تشغيل لهذا النظام الأساسي هو OS / 400 ، تمت إعادة تسميته لاحقًا إلى i5 / OS وحتى في وقت لاحق إلى IBM i. منذ وقت ليس ببعيد ، احتفلت بعيد ميلادها الثلاثين.

عند الانغماس في عالم التطوير في ظل نظام التشغيل IBM i ، فأنت تفهم أن هذا ليس "إرثًا" بالمعنى التقليدي للكلمة. هذه بيئة مختلفة ومختلفة تمامًا ، وهي تشبه قليلاً أنظمة Windows أو Unix المعتادة. تتمثل المهمة الرئيسية لنظام التشغيل هذا في أن تكون مثمرًا قدر الإمكان على الأجهزة التي يعمل بها ، وألا تكون مريحة للمستخدم.

IMHO ، يمكن لنظام التشغيل هذا أن يجعلك مجنونا حول مدى فعالية الأساليب المعتادة في كتابة كود C ++ غير فعالة عليه (حتى عشرات المرات من فقدان وحدة المعالجة المركزية) ، وأن بعض مضادات الظهور في الكتب المدرسية هي أفضل ممارسة للكود الفعال ، والمصدر مع تاريخ الكتابة لعام 1978 ليس فقط التجمع دون مشاكل ، ولكن أيضا العمل على النحو المصمم! كل هذا يجعلنا نلقي نظرة جديدة على الأساليب الحديثة لتطوير البرمجيات.

مقدمة

تثير مسألة تحسين جودة البرمجيات قيد التطوير عقول كل فريق تطوير. أحد فرق الائتمان الخاصة بنا ، والتي تتمثل مهمتها في تطوير وتطوير الجزء الخلفي من الوحدة النمطية للنظام المصرفي الآلي لـ Misys Equation ، لم يتجاهل هذه اللحظة أيضًا. خصوصية هذا ABS هو:

• عملت الإصدارات الأولى من نظام ABS في السلف السابق AS / 400 - نظام IBM System / 38 (ظهر في عام 1978) تحت نظام CPF OS - "أداة التحكم في البرنامج" ؛
• تم تطويره منذ السبعينيات من القرن العشرين ، وقد تصادف شفرة مكتوبة قبل ولادتك (الكثير من الرموز القديمة) ؛
• ترجع ميزات العمل مع ABS إلى التكامل الوثيق مع IBM i ، وبسبب التوافق العكسي الهائل لهذا الأخير ، يبدو أنك تعمل كعالم آثار في الحفريات في الهرم الأكبر.

IBM i (شعار)

يتم تنفيذ تطوير تطبيقات ABS هذه (خيارات ABS) وفقًا لمعيار الحزمة التقنية من Misys ITP Integrator ، والتي تنص على أن الخيار يجب أن يتكون من برنامج تفاعلي للتفاعل الطرفي مع المستخدم النهائي وتنفيذ واجهة برمجة التطبيقات (API) باستخدام الواجهة المثبتة لتنفيذ الخلفية .

تسمى هذه البرامج التفاعلية التي تم تطويرها بموجب نظام التشغيل IBM i تاريخيا تطبيقات الشاشة الخضراء وهي واجهة المستخدم الوحيدة التي يتفاعل معها مستخدم ABS هذا.

ما هو تطبيق الشاشة الخضراء؟

الإجابة البسيطة هي تطبيق يشبه هذا:



أو هكذا :

لماذا تطبيقات الشاشة الخضراء؟

من الناحية التاريخية ، فإن التطبيقات التفاعلية الوحيدة التي تعمل على الأنظمة المنخفضة والمتوسطة في عائلة AS / 400 وغيرها من الهياكل الرئيسية لشركة IBM ، والتي سمحت لك بطلب أي إدخال مستخدم ، هي تطبيقات شاشة خضراء. تم إجراء التثبيت والإدارة والتهيئة والتطوير على نظام تشغيل IBM i (والأسلاف السابقة i5 / OS و AS400) (وما زالت تنفذ في مكان ما) بشكل حصري باستخدام تطبيقات الشاشة الخضراء.

تحتوي صورة تطبيق الشاشة الخضراء على مقاسين - 24 × 80 و 27 × 132 حرفًا و 16 لونًا ممكنًا. ضمن هذا المقياس ، يتم تنفيذ معظم أعمال المطورين ومستخدمي نظام التشغيل هذا.

أحجام الشاشة هذه هي نتيجة لتطور "محطات العمل" التي كانت متصلة بمُصنِّعي AS400 من القطاعات المنخفضة والمتوسطة المدى لأجهزة الكمبيوتر التجارية IBM System / 32 و System / 34 و System / 36 و System / 38. كانت محطات العمل هذه تسمى المحطات الطرفية وتتكون من شاشة في علبة معدنية مع لوحة مفاتيح وأجهزة إضافية في شكل قلم خفيف. في البداية ، تم دعم لونين فقط من الشاشة - الأخضر والأخضر اللامع ، وهذا هو السبب في أن العبارة التي تم إنشاؤها "تطبيق الشاشة الخضراء" (تطبيق الشاشة الخضراء في الأدب الإنجليزي). في السبعينيات ، زاد عدد الألوان المدعومة إلى 16.


5251 عرض محطة نموذج 11

كانت أكثر خيارات الأجهزة الطرفية شيوعًا هي 5251 Display Station Model 1 (960 حرفًا على الشاشة) والطراز 11 (1920 حرفًا على الشاشة) بأبعاد العرض / العمق / الارتفاع تساوي 530/400/400 مم ، على التوالي ، ويزن 34 كجم. كانت دقة شاشة الطراز 1 12 × 80 ، والطراز 11 - 24 × 80. تم توصيل المحطة مباشرة بالنظام المضيف.

كانت المحطات الطرفية 5251 Display Station Model 2 (960 حرفًا على الشاشة) والنموذج 12 (1920 حرفًا على الشاشة) بأبعاد كبيرة ووزن 45 كجم شائعة جدًا أيضًا. يتم تمييزها عن الموديل 1 والطراز 11 من خلال إمكانية "إعادة توجيه" الاتصال المنبع من خلالهما إلى الجهاز المضيف من عملاء أرخص في شكل طابعات طراز 1 (أو 11) مع طابعات سطح المكتب أو طابعة أرضية منفصلة. وبالتالي ، عمل النموذجان 2 و 12 كمحور ، حيث كانا يوصيان بالاتصال بالمضيف من الأجهزة التي تتطلب اتصالًا مباشرًا بجهاز المضيف ، وتكلفتهما أكبر بكثير.

ستبدو محطات سلسلة الشاشة المزدوجة 5252 أيضًا غير عادية للشخص العادي.


صورة ترويجية من كتيب IBM System / 38 للمعدات والبرامج (محطة العرض المزدوج 5252)

قد يصل سعر طقم الوحدة الطرفية مع طابعة متصلة به إلى عدة آلاف من الدولارات الأمريكية.

تم توصيل الأجهزة الطرفية عبر كابل twinaxial إلى الجهاز المضيف مع طوبولوجيا حافلة في وضع أحادي الاتجاه مع سرعة نقل تصل إلى 1 ميغابت في الثانية. يصل الحد الأقصى لعدد المحطات الطرفية المدعومة من twinaxial إلى 6 أطراف ، ويجب أن تكون المحطة الطرفية البعيدة عن المضيف على مسافة لا تزيد عن 1500 متر.

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

مع تطور أنظمة سطح المكتب وشبكات الوصول ، تم استبدال المحطات الضخمة بمحطات العمل ، حيث تم استخدام بطاقات التوسع المختلفة لشركات الطرف الثالث كوسيلة للوصول إلى الجهاز المضيف ، ودعم الاتصال المباشر عبر twinaxial. بعد قيام IBM بتطوير تقنية Token Ring في عام 1984 ، ظهرت حلول برمجية للوصول إلى الجهاز ، بما في ذلك من خلال هذه الواجهة.


محول 5250 إلى ناقل ISA (الصانع غير معروف)


بطاقات محول Blackbox 5250 (PC470C ، PC471C ، PC472C ، PC473C ، PC478C)

تظهر المحاكيات لـ MS-DOS و MS Windows من كل من IBM ومن الشركات المصنعة لجهة خارجية ، بما في ذلك تطبيقات OpenSource (على سبيل المثال ، tn5250j.sourceforge.net). في منتصف التسعينات ، تأتي مكدس TCP / IP في منتصف العالم -آلات الأعمال المنخفضة نهاية. لدعم وصول المضيف عبر البروتوكول الجديد ، تقوم IBM بتطوير برامج محاكاة سلسلة 5250.

من أجل تكوين بروتوكول مضيف ، تقوم IBM بتطوير
ملحقات بروتوكول Telnet (RFC 854 ، RFC 855 ، RFC 856 ، RFC 860 ، RFC 885 ، RFC 1091 ، RFC 1205 ، RFC 1572 ، RFC 2877) ، يشار إليها مجتمعة باسم Telnet5250 (TN5250) ، الذي يصف عملية استقبال البث المباشر تدفقات البيانات 5250 (تدفقات البيانات 5250) عبر بروتوكول Telnet القياسي.


وصول عميل IBM / 400 لـ Windows 3.1 Installer

ما هو خاص حول IBM 5250؟

من ميزات أجهزة IBM 5250 الطرفية (ووفقًا لذلك بروتوكول TN5250) هو اتجاه الكتلة الخاص بها ، على النقيض من المحطات الطرفية * * nix المعتادة ، الموجهة نحو الرموز . هذا يعني أن تدفق البيانات 5250 الذي يتصل به المضيف مع الجهاز يتم إرساله في كتل البيانات ، ورمز منفصل فيه بدون سياق الكتلة المرسلة لا معنى له.

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


شاشة تسجيل الدخول إلى IBM i host RZKH.de (pub400.com)

علاوة على ذلك ، تتمثل مهمة المحاكي الطرفي في تفسير كتلة البيانات من الجهاز وتشكيل شاشة إدخال للمستخدم ، حيث يُمنح الفرصة لإدخال أي معلومات في الحقول المسموح بها. أيضًا ، تتضمن مهام المحاكي الطرفي رد فعل على تصرفات المستخدم. تُعد مفاتيح F1-F24 (F13-F24 تتم محاكاتها عبر SHIFT + Fx) ، و Enter ، و Home ، و End ، و PageUp ، و PageDn ، وبعض المفاتيح الخاصة الأخرى غير المتوفرة على لوحات المفاتيح الحديثة تعتبر مفاتيح مضيفة. هذا يعني أنه بالضغط على هذا المفتاح ، سيتم إرسال مخزن مؤقت يحتوي على معلومات من حقول الإدخال وموضع المؤشر على الشاشة ، المملوء مسبقًا بمحاكي الجهاز الطرفي ، إلى المضيف للمعالجة.


WIreshark 5250 Data Stream محاولة تسجيل الدخول تفريغ في pub400.com

يستقبل المضيف المخزن المؤقت ، ويقوم بتوزيعه ، ويتم إرسال نتيجة الإدخال إلى البرنامج الذي يطلب رد فعل المستخدم للحصول على مزيد من التحقق من صحة البيانات ويستمر التطبيق في العمل ، بينما يتلقى التطبيق رمز مفتاح المضيف المضغوط.

لماذا autotesting هنا على الإطلاق

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

كان الألم الخاص للفريق هو الغياب شبه الكامل لعام 2017 لأدوات الاختبار التلقائي للشاشة الخضراء ، باستثناء حل الملكية الفكرية UIPath . حتى اليوم لا توجد حلول كثيرة مماثلة ، يعرف المؤلف Automate from HelpSystems و JMeter extension لـ BlazeMeter (سأكون سعيدًا لتلقي معلومات حول المنتجات المماثلة الأخرى).

أول بحث عن المشكلة

المحاكي القياسي لجهاز TN5250 المثبت في أماكن العمل في البنك هو IBM Personal Communications for Windows 6.0 (PCOMM 6.0). وجد الزملاء أن هذا المنتج لديه وسائل منتظمة لأتمتة إدارته في شكل واجهة برمجة تطبيقات متنوعة ، وهي:

1. واجهة برنامج تطبيق اللغة عالية المستوى (HLLAPI) ؛
2. تعزيز HLLAPI.
3. ويندوز HLLAPI
4. المضيف عميل الوصول مكتبة (HACL).

الواجهات الثلاثة الأولى هي الأقدم وتم دعمها منذ DOS والإصدارات 16 بت من Windows. يتم تنفيذ العمل على واجهة EHLLAPI عن طريق استدعاء وظيفة واحدة وفقًا للنموذج الأولي التالي:

long hllapi (LPWORD, LPSTR, LPWORD, LPWORD); 

حيث المعلمة الأولى هي مؤشر إلى الرقم العددي للوظيفة التي يتم تنفيذها ، أما الآخران فهما الوسيطتان حساستان للسياق للوظيفة التي يتم استدعاؤها ، والأخير هو نتيجة الدالة. أي ، لطلب حالة الاتصال "A" (يتم ترقيم الجلسات في المحاكي بحرف لاتيني من النطاق من "A" إلى "Z") ، يجب تشغيل التعليمات البرمجية التالية (مأخوذة من وثائق IBM):

  #include "hapi_c.h" struct HLDQuerySessionStatus QueryData; int Func, Len, Rc; long Rc; memset(QueryData, 0, sizeof(QueryData)); // Init buffer QueryData.qsst_shortname = 'A'; // Session to query Func = HA_QUERY_SESSION_STATUS; // Function number Len = sizeof(QueryData); // Len of buffer Rc = 0; // Unused on input hllapi(&Func, (char *)&QueryData, &Len, &Rc); // Call EHLLAPI if (Rc != 0) { // Check return code // ...Error handling } 

عدد الوظائف المتاحة للاتصال بهذه الطريقة حوالي 60.

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

يبدو أن واجهة Host Access Client Library (HACL) أكثر سهولة في الاستخدام ، لأنه على النقيض من استدعاء "الوظيفة التي تحمل الاسم نفسه" ، تم توفير متغير من التسلسل الهرمي الموجه للكائنات للفئات التي تحاكي تمامًا أي إجراء من إجراءات المستخدم.


التسلسل الهرمي فئة مكتبة المحاكي HACL (C ++)

هناك تطبيقات HACL لـ C ++ و Java و LotusScript وخادم أتمتة COM لنظام Windows (مناسب لـ Visual Basic و .NET).

النموذج الأول

بسبب التعقيد الهائل لبروتوكول تدفق البيانات 5250 والمعلومات الشحيحة للغاية حول أجهزته الداخلية مع ارتباطات إلى الأدبيات المدفوعة المغلقة من IBM ، أصبح من الواضح أن تطوير محاكي خاص بك غير تافه للغاية ويستغرق وقتًا طويلاً. في هذا الصدد ، ظهرت الفكرة لاستخدام طبقة البرامج الوسيطة ، والتي سوف تتيح لك التحكم في محاكي الجهاز في الحد الأدنى من الوظائف المطلوبة ، ولا سيما "إدخال قيمة في الحقل" أو "مقارنة جزء من الشاشة بالمعيار" أو "اضغط على مفتاح المضيف F22".

ادعى الزملاء الذين استخدموا واجهات HACL مسبقًا (وأكد بحث على StackOverflow) أن كائن COM لديه مشاكل في الاستقرار ويمكن أن يتعطل بعد تنفيذ عدد معين من الأوامر. ساعد فقط إعادة تشغيل عملية خادم الأتمتة. أظهر تحليل سريع لإصدار Java أن Wrapper يستخدم عبر واجهة C ++ من خلال JNI. لذلك ، وقع الاختيار على واجهة C ++. كانت ملفات الرأس المطابقة وملفات .lib متوفرة في دليل تثبيت Personal Communications For Windows نفسه.

اعتمد النموذج الأولي الأول على Qt5 ، حيث كان من الممكن تنفيذ تعليمات JavaScript البرمجية من خلال QtScript. في بيئة البرنامج النصي القابل للتنفيذ ، تم تسجيل كائن بعدد صغير من الطرق التي سمحت بتنفيذ الأوامر في المحاكي الطرفي كما لو كان يتم تنفيذها من قبل شخص (إدخال حقل ، والضغط على مفاتيح المضيف ، في انتظار ظهور خط على الشاشة). لقد أظهرنا عرضًا تجريبيًا مباشرًا ، حيث قمنا بكتابة حالة مستخدم لبدء تشغيل تطبيق شاشة خضراء من معادلة ABS مع اختبار رد فعل التطبيق على إدخال غير صحيح في الحقول. أظهر العرض التوضيحي أن النموذج الأولي كان ناجحًا وأنه يمكننا المضي قدمًا.

ظهور الجار

جنبا إلى جنب مع العرض التوضيحي للنموذج الأولي الأول ، قام زملاء من قسم آخر بتجميع مجموعة من وحدات Ruby + Cucumber + Quick3270 + Ruby ( cheeze / te3270 ). يستخدم الخيار المقترح وحدة نمطية Ruby التي تتفاعل مع محاكي DN32 Computing Quick3270 من خلال كائنات COM المتخصصة (غير متوافقة مع واجهات HACL). لقد كان حلاً كاملاً لتطبيقات الاختبار التلقائي للشاشة الخضراء على غرار BDD ، مع بعض الخطوات الموضحة مسبقًا. ومع ذلك ، في الحل المقترح ، شعرنا بالقلق إزاء ما يلي:

1. استخدمنا محاكيًا مدفوعًا من جهة خارجية ، وليس من IBM (جميع المحاكيات تعمل بشكل مختلف قليلاً ، لكننا بحاجة إلى التحقق من العمل على المعايير القياسية المستخدمة في البنك ، فإن سعر الخطأ مرتفع بشكل لا يصدق) ؛
2. استخدمت تطبيقات خطوات Cucumber الخاصة بـ Quick3270 عددًا كبيرًا من النوم لانتظار استجابة الجهاز ؛
3. أداء رديء للغاية من Quick3270 عبر واجهة التشغيل الآلي (العمل مع HACL في النموذج الأولي من خلال واجهة C ++ بدا أكثر ديناميكية).

Quick3270 المحاكي الطرفي

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

انحدار غنائي . على الرغم من وجود عدد كبير من المشكلات الفنية حول IBM "القديمة" المفترض ، والتي ، على ما يبدو ، كان يجب حلها بالفعل لأنظمة مستوى الأعمال التجارية على مستوى المؤسسات والمؤسسات ، إلا أن أهمية تكييف ونقل الحلول التقنية الحالية مرتفعة للغاية ببساطة لأن غيابهم على المنصة. غالبًا ما يكون الغياب مرتبطًا بميزات نظام التشغيل هذا ، والتي تختلف اختلافًا أساسيًا عن * nix الحديثة أو Windows أو MacOS X ، والتي تتطلب تحسينًا كبيرًا للبرنامج لهذا المكدس.

القرار الخاص

كحل خاص بنا ، أنشأنا خادم أتمتة كتطوير للنموذج الأولي الموضح مسبقًا. ينفذ هذا الخادم أوامر لأتمتة التفاعل من المستهلكين من خلال خادم RPC (Qt5 WebSocket). إنه يتفاعل مع Personal Communications for Windows ، والذي يعد جزءًا من صورة نظام التشغيل Windows للشركة ، ويسمح لك بما يلي:

• بدء / إيقاف جلسات المحاكي الطرفية ؛
• أداء الشاشة كشط الشاشة الخضراء.
• البحث عن حقول الإدخال على الشاشة ؛
• السيطرة على المؤشر ومحاكاة ضربات المفاتيح (بما في ذلك المضيف) ؛
• وغيرها

بدء تشغيل خادم الأتمتة

ومع ذلك ، لكل مزايا واجهة برمجة تطبيقات HACL ، فإن لها عيبًا واحدًا - فهي لا تعرف كيفية العمل مع DB2 لنظام i DBMS المدمج في نظام التشغيل ولا تسمح بتنفيذ الأوامر الحيوية لبناء بيئة وهمية حيث سيتم تنفيذ برنامج نصي للاختبار. إذا كان عميل DB2 الخاص بـ Ruby موجودًا من IBM ، فإن عميل الأمر البعيد وخادم اتصال البرنامج الموزع يكون مخصصًا لجافا فقط في شكل مكتبة JTOpen : الإصدار المفتوح المصدر من IBM Toolbox for Java (المعروف أيضًا باسم jt400 ). لقد "أطلعنا" على حل هذه المشكلة في IBM نفسها من خلال تحليل سلوك منتجاتها مع وظائف مماثلة (على وجه الخصوص ، الاتصالات الشخصية لنقل بيانات Windows ، iSeries إلى الكمبيوتر الشخصي / الكمبيوتر الشخصي إلى iSeries Transfer ، إلخ). اتضح أن هذه المنتجات ، من خلال تنفيذها ، قم بتشغيل IBM JRE 6 أو 8 ، اعتمادًا على إصدار التطبيق ، واستخدام مكتبة jt400.

لخادم الأتمتة ، قررنا أن نفعل الشيء نفسه. JNI تطلق IBM JVM ، الذي يأتي مع الاتصالات الشخصية لنظام التشغيل Windows. باستخدام أساليب التفاف خاصة ، يتم تنفيذ الأوامر من خادم RPC القادم من الخارج عن طريق تحويلها إلى مكالمات إلى وظيفة jt400 اللازمة. نظرًا لأن الأخير يحتوي أيضًا على برنامج تشغيل JDBC لـ DB2 ، فقد تقرر استخدامه للوصول إلى DBMS على IBM i.

من المهم ملاحظة أنه لا يمكنك استخدام Oracle JVM عند استخدام HACL. إذا قمت بتشغيل جلسة محاكي المحطة الطرفية ، فسوف تتعطل محاولة إنشاء مثيل للجهاز الظاهري. وبالمثل ، إذا قمت بتشغيل Oracle JVM في مساحة العنوان لعملية تتفاعل مع HACL ، فسيتم تعليق الأخير بدون تفسير.

مع مرور الوقت ، تم تنفيذ الحل على عدد متزايد من الوظائف. كان يعمل بشكل أسرع من الحل مع Quick3270. نمت الشعبية ، كما ارتفع عدد الاختبارات الذاتية. ومع ذلك ، أثناء العملية ، نشأت صعوبات إضافية:

1. يتجمد محطة عرضية.
2. عدم القدرة على العمل على موقف الانحدار بسبب رفض المحاكي الطرفي بدء التشغيل إذا تم حظر سطح مكتب المستخدم الذي يبدأ تشغيل المحاكي به أو تم حظر جلسة RDP الخاصة به ؛
3. ويندوز فقط؛
4. إجراء معقد لتثبيت الأدوات وتكوينها وتحديثها (عبر حزمة msi) ؛
5. بدأت دورة الانحدار الخاصة بـ 130 اختبارًا تلقائيًا (حوالي 4000 خطوة) تستغرق 7-8 ساعات.

يجب القيام بشيء ما ...

من خلال تحليل سجلات التتبع لإطلاقات autotest العديدة ، وإيجاد اختناقات في أداء الخطوات المستخدمة بشكل متكرر ، تم تخفيض إجمالي وقت تنفيذ الانحدار إلى 4-5 ساعات. ولكن كان من الواضح أن استخدام طبقة الوسيطة في شكل خادم RPC للتشغيل الآلي جنبًا إلى جنب مع واجهة HACL ، التي تحتوي أيضًا على أخطاء "عائمة" تتراكم خلال مدة النظام بالكامل ، لن يساعد في تحسين أداء الحل.

من ناحية أخرى ، كبديل لـ IBM Personal Communications for Windows ، يوفر البائع حلاً عبر الأنظمة الأساسية يسمى IBM i Access - Client Solutions.


IBM i Access - حلول العميل

أظهر تحليل هيكلها الداخلي يومي السبت والأحد على أكواب القهوة أن قاعدة الكود الخاصة بها تستند إلى منتج آخر من IBM يسمى IBM Host on-Demand (IBM HOD). هذا حل كامل للوصول إلى IBM i ، تم تطويره في Java 6 ، والذي لا يحتوي فقط على التنفيذ الكامل لبروتوكولات الاتصال المختلفة المستخدمة في أجهزة IBM (TN3270 ، TN5250 ، VTxxx ، وما إلى ذلك) ، ولكن أيضًا مكونات UI عالية التأرجح java ، تستخدم لبناء المحاكيات الطرفية الخاصة بهم في شكل مُنشئ ، والتي يمكن تجميعها من وثائق IBM هزيلة أظهرت دراسة أكثر تفصيلاً عن IBM HOD أن مكونات واجهة المستخدم تستند إلى تطبيق Java لواجهة HACL ، التي تكون وثائقها مفتوحة. يتزامن سلوكهم مع اختلافات بسيطة فقط من وثائق C ++ HACL.


مضيف IBM عند الطلب (شعار)

بعد ذلك ، أنشأنا مكتبة Java للاستخدام الداخلي ، والتي تنفذ نفس الواجهة مثل خادم أتمتة C ++ RPC ، ولكن داخليًا يستخدم IBM HOD. لتقليل النفقات العامة أثناء تنفيذ خطوات الاختبار التلقائي ، انتقلنا من Ruby Cucumber إلى خيار jvm مع إعادة تنفيذ جميع الخطوات المشابهة لخيارات Ruby. في ظل وجود واجهة برمجية مشابهة لخادم RPC ، لم تكن هذه مشكلة كبيرة ، خاصة بالنظر إلى أننا حاولنا كبح النمو غير المنضبط في عدد الخطوات نفسها وكان لدينا هذه القيمة في منطقة 30 وحدة.

ما هي النتيجة

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

تم إجراء 180 اختبارًا تم إجراؤه بالفعل مع أكثر من 16000 خطوة مع تأخير محدد قدره 60 مللي ثانية بين الخطوات لتشغيل حوالي 30 دقيقة مقابل 5 ساعات و 30 دقيقة ، وهو ما يتوافق مع زيادة بمقدار 11 ضعفًا في أداء حامل الانحدار.

تجاوزت النتائج كل التوقعات. نحن قريبون من الحدود المادية لبروتوكول TN5250.

حتى الآن ، تم نشر القرار على البنك بأكمله ، وانضم الزملاء من مدن أخرى إلى التحسين. من بين التغييرات الأخيرة ، يدمج الزملاء الحل مع Jenkins ، في إصدار الاختبار ، تم الانتهاء من اختبار الإطلاق على خادم Linux مع Xvfb وبدأت مرحلة التشغيل التجريبي لتشغيل الاختبارات الذاتية عليه.

شكرا لك على القراءة حتى النهاية!
كل النجاح!

ملاحظة: في ديسمبر 2018 ، تم عقد مؤتمر مطوري IBMi التالي ، حيث تم تقديم تقرير حول موضوع هذه المقالة.

حتى الآن ، عقدنا المؤتمر سنويًا فقط لموظفي البنك. من عام 2019 ، سوف ندعو المشاركين من الشركات الأخرى. من المثير للاهتمام توسيع دائرة التواصل المهني والشخصي ، وتبادل المشاعر والمعرفة والخبرة.