ضمان جودة برمجيات المصدر المفتوح (OSS) - دراسة حالة ميلفوس
صورة الغلاف
هذا المقال بقلم ونكسينغ تشو وأعدته أنجيلا ني.
ضمان الجودة (QA) هو عملية منهجية لتحديد ما إذا كان المنتج أو الخدمة تفي بمتطلبات معينة. ويُعد نظام ضمان الجودة جزءًا لا غنى عنه في عملية البحث والتطوير لأنه، كما يوحي اسمه، يضمن جودة المنتج.
يقدم هذا المنشور إطار عمل ضمان الجودة المعتمد في تطوير قاعدة بيانات ميلفوس المتجهة، بهدف توفير دليل إرشادي للمطورين والمستخدمين المساهمين في العملية. كما سيغطي وحدات الاختبار الرئيسية في ملفوس بالإضافة إلى الأساليب والأدوات التي يمكن الاستفادة منها لتحسين كفاءة اختبارات ضمان الجودة.
الانتقال إلى:
- مقدمة عامة عن نظام ميلفوس لضمان الجودة
- وحدات الاختبار في ميلفوس
- أدوات وأساليب لتحسين كفاءة ضمان الجودة
مقدمة عامة عن نظام ميلفوس لضمان الجودة
بنية النظام أمر بالغ الأهمية لإجراء اختبارات ضمان الجودة. فكلما كان مهندس ضمان الجودة على دراية أكبر بالنظام، زادت احتمالية توصله إلى خطة اختبار معقولة وفعالة.
بنية ميلفوس
تتبنى Milvus 2.0 بنية سحابية أصلية وموزعة ومتعددة الطبقات، حيث تعتبر مجموعة أدوات تطوير البرمجيات المدخل الرئيسي لتدفق البيانات في Milvus. يستفيد مستخدمو Milvus من مجموعة تطوير البرمجيات SDK بشكل متكرر، وبالتالي هناك حاجة ماسة إلى إجراء اختبارات وظيفية على جانب SDK. أيضًا، يمكن أن تساعد اختبارات الوظائف على SDK في اكتشاف المشكلات الداخلية التي قد تكون موجودة داخل نظام Milvus. بصرف النظر عن الاختبارات الوظيفية، سيتم أيضًا إجراء أنواع أخرى من الاختبارات على قاعدة البيانات المتجهة، بما في ذلك اختبارات الوحدة، واختبارات النشر، واختبارات الموثوقية، واختبارات الثبات، واختبارات الأداء، واختبارات الأداء.
تجلب البنية السحابية الأصلية والموزعة كلاً من الملاءمة والتحديات لاختبارات ضمان الجودة. فعلى عكس الأنظمة التي يتم نشرها وتشغيلها محلياً، يمكن لمثيل Milvus الذي يتم نشره وتشغيله على مجموعة Kubernetes أن يضمن إجراء اختبار البرمجيات في نفس ظروف تطوير البرمجيات. ومع ذلك، فإن الجانب السلبي هو أن تعقيد البنية الموزعة يجلب المزيد من الشكوك التي يمكن أن تجعل اختبار ضمان الجودة للنظام أكثر صعوبة ومضنية. على سبيل المثال، يستخدم نظام ميلفوس 2.0 خدمات متناهية الصغر لمكونات مختلفة، وهذا يؤدي إلى زيادة عدد الخدمات والعقد، واحتمال أكبر لحدوث خطأ في النظام. وبالتالي، هناك حاجة إلى خطة ضمان جودة أكثر تطوراً وشمولاً لتحسين كفاءة الاختبار.
اختبارات ضمان الجودة وإدارة المشكلات
يتضمن ضمان الجودة في ميلفوس كلاً من إجراء الاختبارات وإدارة المشكلات التي تظهر أثناء تطوير البرمجيات.
اختبارات ضمان الجودة
تُجري ميلفوس أنواعًا مختلفة من اختبارات ضمان الجودة وفقًا لميزات ميلفوس واحتياجات المستخدم حسب الأولوية كما هو موضح في الصورة أدناه.
أولوية اختبار ضمان الجودة
يتم إجراء اختبارات ضمان الجودة على الجوانب التالية في ميلفوس حسب الأولوية التالية:
- الوظيفة: التحقق مما إذا كانت الوظائف والميزات تعمل كما تم تصميمها في الأصل.
- النشر: التحقق مما إذا كان بإمكان المستخدم نشر وإعادة تثبيت وترقية كل من إصدار Mivus المستقل ومجموعة Milvus بطرق مختلفة (Docker Compose أو Helm أو APT أو YUM، إلخ).
- الأداء: اختبار أداء إدخال البيانات والفهرسة والبحث المتجه والاستعلام في Milvus.
- الاستقرار: تحقق مما إذا كان يمكن تشغيل Milvus بثبات لمدة 5-10 أيام تحت مستوى عادي من عبء العمل.
- الموثوقية: اختبار ما إذا كان ميلفوس لا يزال يعمل بشكل جزئي في حالة حدوث خطأ معين في النظام.
- التهيئة: التحقق مما إذا كان ميلفوس يعمل كما هو متوقع في ظل تهيئة معينة.
- التوافق: اختبار ما إذا كانت Milvus متوافقة مع أنواع مختلفة من الأجهزة أو البرامج.
إدارة المشكلات
قد تظهر العديد من المشكلات أثناء تطوير البرمجيات. يمكن أن يكون مؤلف المشكلات النموذجية مهندسي ضمان الجودة أنفسهم أو مستخدمي ميلفوس من مجتمع المصدر المفتوح. فريق ضمان الجودة مسؤول عن حل المشكلات.
سير عمل إدارة المشكلات
عندما يتم إنشاء مشكلة، ستخضع للفرز أولاً. أثناء الفرز، سيتم فحص المشكلات الجديدة للتأكد من تقديم تفاصيل كافية عن المشكلات. إذا تم تأكيد المشكلة، فسيتم قبولها من قبل المطورين وسيحاولون إصلاح المشكلات. بمجرد الانتهاء من التطوير، يحتاج مؤلف المشكلة إلى التحقق مما إذا تم إصلاحها. إذا كانت الإجابة بنعم، سيتم إغلاق المشكلة في النهاية.
متى تكون هناك حاجة إلى ضمان الجودة؟
أحد المفاهيم الخاطئة الشائعة هو أن ضمان الجودة والتطوير مستقلان عن بعضهما البعض. ولكن الحقيقة هي أنه لضمان جودة النظام، هناك حاجة إلى جهود من كل من المطورين ومهندسي ضمان الجودة. لذلك، يجب إشراك ضمان الجودة طوال دورة الحياة بأكملها.
دورة حياة ضمان الجودة
كما هو موضح في الشكل أعلاه، تتضمن دورة حياة البحث والتطوير الكاملة للبرمجيات ثلاث مراحل.
خلال المرحلة الأولية، يقوم المطورون بنشر وثائق التصميم بينما يقوم مهندسو ضمان الجودة بوضع خطط الاختبار وتحديد معايير الإصدار وتعيين مهام ضمان الجودة. يجب أن يكون المطورون ومهندسو ضمان الجودة على دراية بكل من مستند التصميم وخطة الاختبار بحيث يتم مشاركة الفهم المتبادل لهدف الإصدار (من حيث الميزات والأداء والاستقرار وتقارب الأخطاء وما إلى ذلك) بين الفريقين.
أثناء البحث والتطوير، يتفاعل فريقا التطوير واختبارات ضمان الجودة بشكل متكرر لتطوير الميزات والوظائف والتحقق منها، وإصلاح الأخطاء والمشاكل التي يبلغ عنها مجتمع المصدر المفتوح أيضًا.
خلال المرحلة النهائية، إذا تم استيفاء معايير الإصدار، يتم إصدار صورة Docker جديدة لإصدار Milvus الجديد. هناك حاجة إلى مذكرة إصدار تركز على الميزات الجديدة والأخطاء التي تم إصلاحها وعلامة إصدار للإصدار الرسمي. ثم سيقوم فريق ضمان الجودة أيضًا بنشر تقرير اختبار عن هذا الإصدار.
وحدات الاختبار في ملفوس
هناك العديد من وحدات الاختبار في ملفوس وسيشرح هذا القسم كل وحدة بالتفصيل.
اختبار الوحدة
اختبار الوحدة
يمكن أن تساعد اختبارات الوحدة في تحديد الأخطاء البرمجية في مرحلة مبكرة وتوفير معايير التحقق من إعادة هيكلة التعليمات البرمجية. وفقًا لمعايير قبول طلب السحب (PR) في ميلفوس، يجب أن تكون تغطية اختبار وحدة التعليمات البرمجية 80%.
اختبار الوظيفة
يتم تنظيم اختبارات الوظائف في ميلفوس بشكل أساسي حول PyMilvus و SDKs. الغرض الرئيسي من اختبارات الوظائف هو التحقق مما إذا كانت الواجهات تعمل كما تم تصميمها. اختبارات الوظائف لها وجهان:
- اختبار ما إذا كان بإمكان حزم SDKs إرجاع النتائج المتوقعة عند تمرير المعلمات الصحيحة.
- اختبار ما إذا كان بإمكان SDKs معالجة الأخطاء وإرجاع رسائل خطأ معقولة عند تمرير معلمات غير صحيحة.
يصور الشكل أدناه إطار العمل الحالي لاختبارات الدوال الذي يعتمد على إطار عمل pytest السائد. يضيف إطار العمل هذا غلافًا إلى PyMilvus ويمكّن الاختبار بواجهة اختبار مؤتمتة.
اختبار الدالة
بالنظر إلى الحاجة إلى طريقة اختبار مشتركة والحاجة إلى إعادة استخدام بعض الدوال، تم اعتماد إطار الاختبار أعلاه، بدلاً من استخدام واجهة PyMilvus مباشرةً. كما تم تضمين وحدة "تحقق" في الإطار لتوفير الراحة في التحقق من القيم المتوقعة والفعلية.
تم تضمين ما يصل إلى 2700 حالة اختبار دالة في دليل tests/python_client/testcases
، وهي تغطي جميع واجهات PyMilvus تقريبًا بشكل كامل. تشرف اختبارات الدالة هذه بدقة على جودة كل عملية علاقات عامة.
اختبار النشر
يأتي ميلفوس في وضعين: مستقل وعنقودي. وهناك طريقتان رئيسيتان لنشر ميلفوس: باستخدام Docker Compose أو Helm. وبعد نشر Milvus، يمكن للمستخدمين أيضًا إعادة تشغيل خدمة Milvus أو ترقيتها. هناك فئتان رئيسيتان لاختبار النشر: اختبار إعادة التشغيل واختبار الترقية.
يشير اختبار إعادة التشغيل إلى عملية اختبار ثبات البيانات، أي ما إذا كانت البيانات لا تزال متاحة بعد إعادة التشغيل. يشير اختبار الترقية إلى عملية اختبار توافق البيانات لمنع الحالات التي يتم فيها إدراج تنسيقات غير متوافقة للبيانات في ملفوس. يشترك كلا النوعين من اختبارات النشر في نفس سير العمل كما هو موضح في الصورة أدناه.
اختبار النشر
في اختبار إعادة التشغيل، تستخدم عمليتا النشر نفس صورة docker. ومع ذلك في اختبار الترقية، تستخدم عملية النشر الأولى صورة docker لإصدار سابق بينما تستخدم عملية النشر الثانية صورة docker لإصدار لاحق. يتم حفظ نتائج الاختبار والبيانات في ملف Volumes
أو المطالبة بوحدة تخزين ثابتة (PVC).
عند تشغيل الاختبار الأول، يتم إنشاء مجموعات متعددة وإجراء عمليات مختلفة لكل مجموعة من المجموعات. عند تشغيل الاختبار الثاني، سيكون التركيز الرئيسي على التحقق مما إذا كانت المجموعات التي تم إنشاؤها لا تزال متاحة لعمليات CRUD، وما إذا كان يمكن إنشاء مجموعات جديدة أخرى.
اختبار الموثوقية
عادةً ما تعتمد الاختبارات على موثوقية النظام الموزع السحابي الأصلي على طريقة هندسة الفوضى التي تهدف إلى القضاء على الأخطاء وأعطال النظام في مهدها. وبعبارة أخرى، في اختبار هندسة الفوضى، نقوم في اختبار هندسة الفوضى بخلق حالات فشل النظام عن قصد لتحديد المشاكل في اختبارات الضغط وإصلاح أعطال النظام قبل أن تبدأ بالفعل في إحداث مخاطر. أثناء اختبار الفوضى في ميلفوس، نختار شبكة الفوضى كأداة لخلق الفوضى. هناك عدة أنواع من الإخفاقات التي يجب إنشاؤها:
- تعطلالكبسولة: محاكاة لسيناريو تعطل العقد.
- فشل الكبسولة: اختبار ما إذا كانت إحدى العقدة العاملة قد تعطلت وما إذا كان النظام بأكمله لا يزال بإمكانه الاستمرار في العمل.
- إجهاد الذاكرة: محاكاة لاستهلاك موارد الذاكرة ووحدة المعالجة المركزية الثقيلة من عقد العمل.
- تقسيم الشبكة: بما أن ميلفوس يفصل التخزين عن الحوسبة، فإن النظام يعتمد بشكل كبير على الاتصال بين المكونات المختلفة. هناك حاجة لمحاكاة السيناريو الذي يتم فيه تقسيم الاتصال بين مختلف الكبسولات لاختبار الترابط بين مكونات Milvus المختلفة.
اختبار الموثوقية
يوضح الشكل أعلاه إطار عمل اختبار الموثوقية في ميلفوس الذي يمكنه أتمتة اختبارات الفوضى. يكون سير عمل اختبار الموثوقية كما يلي:
- تهيئة مجموعة Milvus من خلال قراءة تكوينات النشر.
- عندما تكون الكتلة جاهزة، قم بتشغيل
test_e2e.py
لاختبار ما إذا كانت ميزات ميلفوس متوفرة. - تشغيل
hello_milvus.py
لاختبار ثبات البيانات. قم بإنشاء مجموعة باسم "hello_milvus" لإدراج البيانات وتدفقها وبناء الفهرس والبحث المتجه والاستعلام. لن يتم تحرير هذه المجموعة أو إسقاطها أثناء الاختبار. - قم بإنشاء كائن مراقبة سيبدأ ستة خيوط لتنفيذ عمليات الإنشاء والإدراج والتدفق والفهرس والبحث والاستعلام.
checkers = {
Op.create: CreateChecker(),
Op.insert: InsertFlushChecker(),
Op.flush: InsertFlushChecker(flush=True),
Op.index: IndexChecker(),
Op.search: SearchChecker(),
Op.query: QueryChecker()
}
- قم بإجراء التأكيد الأول - جميع العمليات ناجحة كما هو متوقع.
- أدخل فشل النظام إلى ميلفوس باستخدام Chaos Mesh لتحليل ملف yaml الذي يحدد الفشل. يمكن أن يكون الفشل هو قتل عقدة الاستعلام كل خمس ثوانٍ على سبيل المثال.
- قم بإجراء التأكيد الثاني أثناء إدخال فشل النظام - احكم على ما إذا كانت النتائج التي تم إرجاعها للعمليات في Milvus أثناء فشل النظام تتطابق مع التوقع.
- القضاء على الفشل عبر شبكة الفوضى.
- عندما يتم استرداد خدمة Milvus (بمعنى أن جميع الكبسولات جاهزة)، قم بإجراء التأكيد الثالث - جميع العمليات ناجحة كما هو متوقع.
- قم بتشغيل
test_e2e.py
لاختبار ما إذا كانت ميزات ميلفوس متوفرة. قد يتم حظر بعض العمليات أثناء الفوضى بسبب التأكيد الثالث. وحتى بعد التخلص من الفوضى، قد يستمر حظر بعض العمليات، مما يعيق نجاح التأكيد الثالث كما هو متوقع. تهدف هذه الخطوة إلى تسهيل التأكيد الثالث وتعمل كمعيار للتحقق مما إذا كانت خدمة Milvus قد تعافت. - تشغيل
hello_milvus.py
، وتحميل المجموعة التي تم إنشاؤها، وإجراء عمليات CRUP على المجموعة. بعد ذلك، تحقق مما إذا كانت البيانات الموجودة قبل فشل النظام لا تزال متاحة بعد استرداد الفشل. - اجمع السجلات.
اختبار الاستقرار والأداء
يصف الشكل أدناه الأغراض وسيناريوهات الاختبار ومقاييس اختبار الاستقرار والأداء.
اختبار الاستقرار | اختبار الأداء | |
---|---|---|
الأغراض | - التأكد من قدرة Milvus على العمل بسلاسة لفترة زمنية محددة تحت عبء العمل العادي. - التأكد من استهلاك الموارد بثبات عند بدء تشغيل خدمة ميلفوس. | - اختبار أداء جميع واجهات ميلفوس. - العثور على التكوين الأمثل بمساعدة اختبارات الأداء. - العمل كمعيار للإصدارات المستقبلية. - العثور على عنق الزجاجة الذي يعيق الأداء الأفضل. |
السيناريوهات | - سيناريو القراءة المكثفة غير المتصلة بالإنترنت حيث يتم تحديث البيانات بالكاد بعد الإدراج وتكون النسبة المئوية لمعالجة كل نوع من الطلبات: طلب البحث 90%، طلب الإدراج 5%، والطلبات الأخرى 5%. - السيناريو كثيف الكتابة عبر الإنترنت حيث يتم إدراج البيانات والبحث عنها في وقت واحد وتكون النسبة المئوية لمعالجة كل نوع من الطلبات هي: طلب إدراج 50%، وطلب بحث 40%، وطلب بحث 40%، وأخرى 10%. | - إدراج البيانات - بناء الفهرس - البحث المتجه |
المقاييس | - استخدام الذاكرة - استهلاك وحدة المعالجة المركزية - زمن انتقال الإدخال والإخراج - حالة كبسولات ميلفوس - زمن استجابة خدمة Milvus وما إلى ذلك | - إنتاجية البيانات أثناء إدخال البيانات - الوقت الذي يستغرقه إنشاء فهرس - وقت الاستجابة أثناء البحث المتجه - الاستعلام في الثانية (QPS) - الطلب في الثانية - معدل الاستدعاء إلخ. |
يشترك كل من اختبار الاستقرار واختبار الأداء في نفس مجموعة سير العمل:
اختبار الاستقرار والأداء
- تحليل التكوينات وتحديثها، وتحديد المقاييس. يتوافق
server-configmap
مع تكوين ميلفوس المستقل أو العنقودي بينما يتوافقclient-configmap
مع تكوينات حالة الاختبار. - تكوين الخادم والعميل.
- إعداد البيانات
- طلب التفاعل بين الخادم والعميل.
- إعداد التقارير وعرض المقاييس.
أدوات وأساليب لتحسين كفاءة ضمان الجودة
من قسم اختبار الوحدات، يمكننا أن نرى أن إجراءات معظم الاختبارات هي في الواقع متشابهة تقريبًا، وتتضمن بشكل أساسي تعديل تكوينات خادم ميلفوس والعميل وتمرير معلمات واجهة برمجة التطبيقات. عندما تكون هناك تكوينات متعددة، كلما زاد تنوع مجموعة التكوينات المختلفة، زادت سيناريوهات الاختبار التي يمكن أن تغطيها هذه التجارب والاختبارات. ونتيجةً لذلك، فإن إعادة استخدام الرموز والإجراءات تكون أكثر أهمية لعملية تعزيز كفاءة الاختبار.
إطار عمل اختبار SDK
إطار عمل اختبار SDK
لتسريع عملية الاختبار، يمكننا إضافة غلاف API_request
إلى إطار الاختبار الأصلي، وتعيينه كشيء مشابه لبوابة واجهة برمجة التطبيقات. ستكون بوابة واجهة برمجة التطبيقات هذه مسؤولة عن جمع جميع طلبات واجهة برمجة التطبيقات ثم تمريرها إلى Milvus لتلقي الردود بشكل جماعي. سيتم تمرير هذه الردود إلى العميل بعد ذلك. مثل هذا التصميم يجعل التقاط معلومات سجل معينة مثل المعلمات والنتائج المرتجعة أسهل بكثير. بالإضافة إلى ذلك، يمكن لمكون المدقق في إطار عمل اختبار SDK التحقق من النتائج من Milvus وفحصها. ويمكن تحديد جميع طرق الفحص داخل مكون المدقق هذا.
مع إطار عمل اختبار SDK، يمكن تغليف بعض عمليات التهيئة الحاسمة في دالة واحدة. وبذلك، يمكن التخلص من أجزاء كبيرة من الرموز المملة.
من الجدير بالذكر أيضًا أن كل حالة اختبار فردية مرتبطة بمجموعتها الفريدة لضمان عزل البيانات.
عند تنفيذ حالات الاختبار،pytest-xdist
، يمكن الاستفادة من امتداد pytest، لتنفيذ جميع حالات الاختبار الفردية بالتوازي، مما يعزز الكفاءة بشكل كبير.
إجراء GitHub
إجراء GitHub
تم اعتمادGitHub Action أيضًا لتحسين كفاءة ضمان الجودة لخصائصه التالية:
- إنها أداة CI / CD أصلية مدمجة بعمق مع GitHub.
- يأتي مع بيئة آلة مهيأة بشكل موحد وأدوات تطوير برمجيات شائعة مثبتة مسبقًا بما في ذلك Docker و Docker Compose، إلخ.
- وهو يدعم العديد من أنظمة التشغيل والإصدارات بما في ذلك Ubuntu و MacOs و Windows-server، إلخ.
- لديه سوق يقدم امتدادات غنية ووظائف خارج الصندوق.
- تدعم مصفوفته الوظائف المتزامنة، وإعادة استخدام نفس تدفق الاختبار لتحسين الكفاءة
بصرف النظر عن الخصائص المذكورة أعلاه، هناك سبب آخر لاعتماد GitHub Action وهو أن اختبارات النشر واختبارات الموثوقية تتطلب بيئة مستقلة ومعزولة. ويُعد GitHub Action مثاليًا لاختبارات الفحص اليومية على مجموعات البيانات صغيرة الحجم.
أدوات للاختبارات المعيارية
لجعل اختبارات ضمان الجودة أكثر كفاءة، يتم استخدام عدد من الأدوات.
أدوات ضمان الجودة
- Argo: مجموعة من الأدوات مفتوحة المصدر لـ Kubernetes لتشغيل مهام سير العمل وإدارة المجموعات من خلال جدولة المهام. ويمكنها أيضًا تمكين تشغيل مهام متعددة بالتوازي.
- لوحة معلومات Kubernetes: واجهة مستخدم Kubernetes قائمة على الويب لتصور
server-configmap
وclient-configmap
. - NAS: التخزين المتصل بالشبكة (NAS) هو خادم تخزين بيانات حاسوبية على مستوى الملفات لحفظ مجموعات البيانات الشائعة لمعايير الشبكة الوطنية.
- InfluxDB و MongoDB: قواعد بيانات لحفظ نتائج الاختبارات المعيارية.
- Grafana: حل مفتوح المصدر للتحليلات والمراقبة لمراقبة مقاييس موارد الخادم ومقاييس أداء العميل.
- Redash: خدمة تساعد في تصور بياناتك وإنشاء مخططات للاختبارات المعيارية.
حول سلسلة الغوص العميق
مع الإعلان الرسمي عن التوفر العام ل Milvus 2.0، نظمنا سلسلة مدونات Milvus Deep Dive هذه لتقديم تفسير متعمق لبنية Milvus ورمز المصدر. تشمل الموضوعات التي تتناولها سلسلة المدونات هذه ما يلي:
- مقدمة عامة عن نظام ميلفوس لضمان الجودة
- وحدات الاختبار في ملفوس
- أدوات وأساليب لتحسين كفاءة ضمان الجودة
- حول سلسلة الغوص العميق
On This Page
Try Managed Milvus for Free
Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.
Get StartedLike the article? Spread the word