Reporter.ReportEvent in UFT/QTP مع المثال

ما هو Reporter.ReportEvent في UFT/QTP?

Reporter.ReportEvent هي طريقة قياسية مدمجة في UFT/QTP (يباع الآن باسم) OpenText/ميكرو فوكس UFT أولاً، يقوم هذا الخيار بكتابة رسالة مخصصة سهلة القراءة مباشرةً في نافذة نتائج الاختبار. على عكس نتائج النجاح أو الفشل التلقائية التي تُنشئها نقاط التحقق المدمجة، يتيح استدعاء ReportEvent للمختبِر تحديد ما يتم تسجيله بالضبط، ومتى، وكيف يجب تصنيفه.

هذه HP QTP البرنامج التعليمي يوضح استخدام الوظيفة Reporter.ReportEvent و تنسيق النتائجيطلب منك البرنامج التعليمي إنشاء نص برمجي قصير، وإكمال تمرين كتابة النصوص البرمجية هذا هو أسرع طريقة لرؤية تحديث التقارير المخصصة لشجرة النتائج في الوقت الفعلي.

انقر اضغط هنا إذا لم يكن من الممكن الوصول إلى الفيديو

يُعدّ Reporter.ReportEvent بالغ الأهمية في مجال الأتمتة، لأنّ البرنامج النصي عادةً ما يُنفّذ تلقائيًا، وفقًا لجدول زمني، أو ضمن مسار CI/CD. يصبح ملف نتائج التشغيل السجل الوحيد لما حدث، لذا فإنّ أي خطوة تفشل دون تنبيه، أو تنجح دون تفسير، تُصعّب عملية تصحيح الأخطاء لاحقًا. إضافة استدعاء صريح لـ ReportEvent بعد إجراء حاسم يُحوّل شجرة النتائج إلى سجل تدقيق مقروء خطوة بخطوة، يُمكن للمختبِر أو المطور أو المدير مراجعته دون الحاجة إلى فتح البرنامج النصي نفسه.

يختلف هذا عن نقطة تفتيش الكائن، والتي UFT يُنشئ التقرير تلقائيًا ويُبلغ عنه باستخدام اسم الخطوة الافتراضي الخاص به. أما Reporter.ReportEvent، فيتيح لك إرفاق عبارات ذات دلالة تجارية، مثل "تم عرض تأكيد الطلب"، بدلاً من عبارة عامة مثل "تم اجتياز نقطة التحقق على كائن WebEdit"، مما يُسهّل على أصحاب المصلحة غير التقنيين قراءتها في التقرير النهائي. وتعمل هذه الطريقة بنفس الأسلوب سواءً كان البرنامج النصي يستهدف صفحة ويب أو Windows تطبيق سطح المكتب، أو طرفية الحاسوب المركزي، لأن Reporter هو كائن عام وليس خاصية لأي كائن اختبار واحد.

Guru99 في UFT/QTP تتناول السلسلة هذه الطريقة مباشرة بعد ذلك. عبارات If و Else و Exists، لأن معظم استدعاءات Reporter.ReportEvent تقع داخل كتلة شرطية تحدد ما إذا كان ينبغي الإبلاغ عن النتيجة على أنها micPass أو micFail.

صيغة Reporter.ReportEvent وقيم EventStatus

يمكنك استخدام Reporter.ReportEvent للإبلاغ عن خطوات الاختبار المخصصة في Micro Focus UFTشجرة نتائج الاختبار. تقبل الطريقة ثلاثة وسائط إلزامية ووسيطًا اختياريًا واحدًا، بترتيب ثابت، كما هو موضح أدناه.

Reporter.ReportEvent EventStatus, ReportStepName, Details [, ImageFilePath]

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

يمكن أيضًا تمرير كل ثابت كقيمته العددية بدلاً من اسمه، لذلك Reporter.ReportEvent 1, “Step”, “Detail” يتصرف تمامًا مثل Reporter.ReportEvent micFail, “Step”, “Detail”إن استخدام الثابت المسمى يسهل قراءته في نص برمجي سيقوم مختبر آخر بصيانته لاحقًا.

عادةً ما يتضمن البرنامج النصي عدة استدعاءات ReportEvent داخل إجراء واحد: إدخال micDone قبل بدء الإجراء، وإدخال micPass أو micFail واحد لفحص المفتاح، وإدخالات micWarning إضافية لأي شيء غير عادي تم ملاحظته على طول الطريق.

• عند تنفيذ حالات الاختبار باستخدام أدوات الأتمتة، قد يصعب على بعض المستخدمين فهم نتائج الاختبار الأولية. يمكنك استخدام استخدم ملف results.xml لإنشاء ملف XSL يعرض نتائج الاختبار بالطريقة التي تفضلها.
• يمكنك أيضا استخدام فبسكريبت وظائف المكتبة لـ قم بتخزين النتائج في ملف إكسل أو ملف نصي للإبلاغ خارج UFT.

كيفية استخدام Reporter.ReportEvent: أمثلة عملية

معرفة الصيغة شيء، ورؤيتها داخل نص برمجي حقيقي شيء آخر، وهو ما يجعل فهم ثوابت الحالة الأربعة واضحًا. المثال أدناه يغلّف عملية التحقق داخل عبارة If…Then…Else، ثم يُبلغ عن نجاح أو فشل باستخدام Reporter.ReportEvent بحيث تظهر النتيجة في شجرة النتائج تمامًا حيث يتوقعها المراجع.

If Browser("Guru99 Demo").Page("Guru99 Demo").WebButton("Login").Exist(5) Then
    Reporter.ReportEvent micPass, "Login button check", "Login button was found on the page"
Else
    Reporter.ReportEvent micFail, "Login button check", "Login button was not found on the page"
End If

وهذا يعكس النمط الموضح في Guru99 في عبارات VBScript الشرطية البرنامج التعليمي، حيث يختار كتلة If…Then…Else بين نتيجتين؛ والفرق الوحيد هنا هو أن كل فرع يستدعي أيضًا Reporter.ReportEvent لتسجيل النتيجة.

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

Reporter.ReportEvent micDone, "Enter search text", "Typed 'UFT tutorial' into the search box"
errorImage = "C:\Results\SearchDelay.png"
Browser("Guru99 Demo").CaptureBitmap errorImage, True
Reporter.ReportEvent micWarning, "Search response time", "Results took longer than 5 seconds to load", errorImage

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

غالباً ما تقوم الفرق التي تستدعي ReportEvent من العديد من البرامج النصية بنقل هذا المنطق إلى دالة VBScript مشتركة، مثل LogStep(status, name, details)، بحيث ينتج كل برنامج نصي شجرة نتائج متسقة دون تكرار نفس كتلة If…Then.

خصائص كائن المُبلِّغ: عامل التصفية، ومسار التقرير، وحالة التشغيل

لا يُعدّ Reporter.ReportEvent العضو الوحيد في كائن Reporter. فهناك ثلاث خصائص إضافية تُتيح تحكمًا أكبر في محتوى النتائج ومكانها. UFT تخزنها، وتظهر بشكل متكرر في أطر أتمتة الإنتاج.

يقبل Reporter.Filter أربع قيم: 0 أو rfEnableAll لعرض جميع الأحداث وهو القيمة الافتراضية؛ 1 أو rfEnableErrorsAndWarnings لإخفاء الخطوات التي تم اجتيازها؛ 2 أو rfEnableErrorsOnly لإخفاء كل من الخطوات التي تم اجتيازها والتحذيرات؛ و3 أو rfDisableAll لإيقاف تسجيل النتائج تمامًا. يتيح التحقق من Reporter.RunStatus أثناء تنفيذ البرنامج النصي للاختبار إنشاء فرع منطقي خاص به، على سبيل المثال، تخطي.ping الخطوات المتبقية في إجراء ما بعد فشل خطوة سابقة.

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

أفضل الممارسات لـ Reporter.ReportEvent في UFT

بعض العادات تجعل التقارير المخصصة مفيدة بدلاً من أن تكون مزعجة.

• احتفظ بكلمة "micFail" للأخطاء الحقيقية: كل استدعاء لـ micFail يقلب Reporter.RunStatus، لذا فإن استخدامه للمشاكل التجميلية يخفي العيوب الحقيقية لاحقًا في نفس التشغيل.
• اكتب ReportStepName كنتيجة متوقعة: ينبغي على المراجع أن يفهم عملية التحقق من اسم الخطوة فقط، دون قراءة عمود التفاصيل.
• التقاط لقطات الشاشة فقط في حالة الفشل: يؤدي تمرير ImageFilePath في كل خطوة إلى ملء مجلد النتائج بسرعة وإبطاء عملية التشغيل مقابل فائدة ضئيلة.
• تصفية عمليات التشغيل الصاخبة: قم بتعيين Reporter.Filter إلى rfEnableErrorsAndWarnings لعمليات التشغيل المجدولة أو عمليات CI حتى لا تخفي الخطوات التي تم تمريرها حالات الفشل المهمة.
• مركزة المنطق: قم بتغليف استدعاءات Reporter.ReportEvent داخل كائن قابل لإعادة الاستخدام عمل أو مكتبة وظائف بحيث يسجل كل نص برمجي في المجموعة النتائج بنفس الطريقة.
• تصدير للقراء غير التقنيين: قم بدمج ملف results.xml مع ملف XSL مخصص عندما يحتاج أصحاب المصلحة من خارج فريق ضمان الجودة إلى مراجعة النتائج دون فتح الملف. UFT.

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