يتوقف قرار تشغيل نظام جديد على فحصين. الأول: هل يصمد النظام عندما يستخدمه عدد كبير من الأشخاص في الوقت نفسه، كما في نهاية الشهر أو أثناء العروض أو في يوم التسجيل. والثاني: هل يوافق من سيستخدمونه يوميًا على أنه يؤدي عملهم. ومشاريع كثيرة تتجاوز أحدهما أو كليهما، فتكتشف المشكلة بعد الإطلاق في صفحات بطيئة وصفحات لا تُفتح وموظفين يعودون إلى جداولهم.
تنفذ Kemlat الفحصين معًا. في الأداء، نحاكي أعدادًا واقعية من المستخدمين والعمليات، ونقيس زمن الاستجابة والأخطاء. وفي اختبار قبول المستخدم (UAT)، وفيه يؤكد المستخدمون في الإدارات المعنية أن النظام يلبي احتياجاتهم، نجهّز سيناريوهات من حالات حقيقية، ونرافق المستخدمين أثناء تنفيذها، ونسجّل ما نجح وما يحتاج إلى إصلاح. وتصلك النتائج والتوصيات قبل قرار الإطلاق الفعلي.
كيف نعمل
- 01
تقييم المخاطر والضغط المتوقع
نراجع أعداد المستخدمين المتوقعة وفترات الذروة والعمليات الحساسة وإعداد الاستضافة. ونحدد مع المسؤولين في الإدارات المعنية الإجراءات التي يسبب فيها البطء أو الخطأ الضرر الأكبر.
- 02
كتابة السيناريوهات والمعايير
للأداء، نحدد سيناريوهات الضغط وأزمنة الاستجابة المستهدفة بالاتفاق معك. ولاختبار القبول، نكتب سيناريوهات من حالات عمل حقيقية، لكل منها نتيجة متوقعة يؤكدها المستخدمون.
- 03
تنفيذ اختبارات الأداء
تحاكي أدوات اختبار الضغط عددًا كبيرًا من المستخدمين في الوقت نفسه، ويُرفع الضغط تدريجيًا، ونسجّل زمن الاستجابة والأخطاء وحمل الخادم، مثل استهلاك المعالج والذاكرة. وتُجرى الاختبارات على بيئة أقرب ما تكون إلى البيئة الفعلية.
- 04
تنفيذ اختبار قبول المستخدم
نجهّز بيانات الاختبار والحسابات، ونشرح للمستخدمين المطلوب، ونساندهم أثناء تنفيذ السيناريوهات. ويُسجَّل كل خلل بدليله ويُصنَّف مع المورّد عيبًا أو طلب تغيير.
- 05
التقرير وإعادة الاختبار والاعتماد
نبين أين يتباطأ النظام، ونوصي بإصلاحات مثل ضبط قاعدة البيانات، أو تعديل الخوادم، أو التخزين المؤقت الذي يُبقي النتائج المتكررة جاهزة. وبعد الإصلاحات نعيد الاختبار ونؤكد القبول مع المسؤولين في الإدارات المعنية.
ما الذي تستلمه
السيناريوهات ومعايير القبول
سيناريوهات ضغط بأزمنة استجابة مستهدفة، وسيناريوهات قبول بالنتيجة المتوقعة لكل حالة عمل.
نتائج اختبارات الأداء
أزمنة الاستجابة ونسب الأخطاء واستهلاك الموارد عند كل مستوى ضغط، بما في ذلك النقطة التي يبدأ عندها الأداء بالتراجع.
سجل اختبار القبول
نتيجة كل سيناريو موقّعة من المستخدمين في الإدارات المعنية، مع كل خلل وحالته.
النتائج والتوصيات
أسباب البطء أو الفشل التي ظهرت، مع الإصلاحات الموصى بها مرتبة حسب أثرها.
إعادة الاختبار واعتماد القبول
تأكيد بعد الإصلاحات أن الأهداف المتفق عليها تحققت، وأن مؤسستك تقبل النظام.
ما الذي يتغير لديك
- تعرف سلوك النظام عند الذروة المتوقعة قبل أن يواجهه العملاء أو الموظفون.
- أكد المستخدمون في الإدارات المعنية أن النظام يعمل مع حالاتهم الحقيقية.
- يُفصل بين العيوب وطلبات التغيير، فتقل الخلافات مع المورّد.
- يستند قرار الإطلاق الفعلي إلى نتائج مقيسة وقبول موقّع.
موقع الخدمة في منهجية KEMLAT
النطاق: تُجرى اختبارات الأداء على بيئة توفرها أو توافق عليها، ولا تُجرى على الأنظمة الفعلية إلا بموافقتك المكتوبة. ويتولى فريق التطوير أو الاستضافة لديك إصلاح العيوب وضبط الخوادم، إلا إذا أُضيف ذلك إلى النطاق.
أسئلة يطرحها العملاء
كم مستخدمًا يجب أن يحاكي اختبار الأداء؟
يأتي العدد من بياناتك: المستخدمون الحاليون، والنمو المتوقع، وأكثر الفترات ازدحامًا. ونتفق معك على المستويات، وعادةً نختبر أيضًا فوق الذروة المتوقعة لنعرف متى يبدأ النظام بالتعثر.
من يشارك من جهتنا في اختبار القبول؟
موظفون سيستخدمون النظام يوميًا، يُختارون من كل دور وإدارة معنية، إضافة إلى مسؤول من الإدارة المعنية يملك صلاحية توقيع القبول. ويُطلب وقتهم خلال جلسات الاختبار.
ما الفرق بين العيب وطلب التغيير؟
العيب يعني أن النظام لا يفعل ما تنص عليه المتطلبات المتفق عليها. أما طلب التغيير فيطلب شيئًا جديدًا أو مختلفًا عمّا اتُّفق عليه. والتمييز مهم، لأن إصلاح العيوب على المورّد، بينما يحتاج التغيير عادةً إلى اتفاق جديد.
هل يمكن أن يضر اختبار الأداء بنظامنا الفعلي؟
قد يحدث ذلك، ولهذا نستخدم بيئة منفصلة كلما أمكن. وإذا لزم الاختبار على النظام الفعلي، نجريه خارج ساعات العمل بموافقتك، ومع خطة لإعادة الخدمة إلى وضعها الطبيعي بسرعة عند الحاجة.
خدمات مرتبطة
كل الخدماتابدأ بمحادثة
أخبرنا أين تقف اليوم، وسنقترح عليك الخطوة الأولى المناسبة دون أي التزام.