لدعم لوحة معلومات التكامل المستمر التي تتميز بالقابلية للتطوير والأداء والمرونة، يجب تصميم الواجهة الخلفية للوحة معلومات VTS بعناية مع فهم قوي لوظائف قاعدة البيانات. Google Cloud Datastore هي قاعدة بيانات NoSQL توفر ضمانات ACID للمعاملات والاتساق النهائي بالإضافة إلى الاتساق القوي داخل مجموعات الكيانات. ومع ذلك، فإن البنية مختلفة تمامًا عن قواعد بيانات SQL (وحتى Cloud Bigtable)؛ بدلاً من الجداول والصفوف والخلايا هناك أنواع وكيانات وخصائص.
توضح الأقسام التالية بنية البيانات وأنماط الاستعلام لإنشاء واجهة خلفية فعالة لخدمة ويب VTS Dashboard.
جهات
تقوم الكيانات التالية بتخزين الملخصات والموارد من عمليات تشغيل اختبار VTS:
- كيان الاختبار يخزن البيانات التعريفية حول عمليات التشغيل التجريبية لاختبار معين. مفتاحه هو اسم الاختبار وتتضمن خصائصه عدد مرات الفشل، وعدد مرات النجاح، وقائمة أعطال حالات الاختبار منذ أن تقوم مهام التنبيه بتحديثه.
- كيان تشغيل الاختبار . يحتوي على بيانات وصفية من عمليات تشغيل اختبار معين. يجب أن يقوم بتخزين الطوابع الزمنية لبدء الاختبار وانتهائه، ومعرف بناء الاختبار، وعدد حالات الاختبار الناجحة والرسوبة، ونوع التشغيل (على سبيل المثال، ما قبل الإرسال، أو ما بعد الإرسال، أو محلي)، وقائمة روابط السجل، والمضيف اسم الجهاز، وأعداد ملخص التغطية.
- كيان معلومات الجهاز . يحتوي على تفاصيل حول الأجهزة المستخدمة أثناء التشغيل التجريبي. ويتضمن معرف إصدار الجهاز واسم المنتج وهدف البناء والفرع ومعلومات ABI. يتم تخزين هذا بشكل منفصل عن كيان التشغيل الاختباري لدعم عمليات تشغيل الاختبار متعدد الأجهزة بطريقة واحد إلى متعدد.
- التنميط نقطة تشغيل الكيان . يلخص البيانات التي تم جمعها لنقطة ملف تعريف معينة ضمن التشغيل التجريبي. وهو يصف تسميات المحاور واسم نقطة التوصيف والقيم والنوع ووضع الانحدار لبيانات التوصيف.
- جهة التغطية . يصف بيانات التغطية المجمعة لملف واحد. يحتوي على معلومات مشروع Git ومسار الملف وقائمة أعداد التغطية لكل سطر في الملف المصدر.
- كيان تشغيل حالة الاختبار . يصف نتيجة حالة اختبار معينة من تشغيل اختباري، بما في ذلك اسم حالة الاختبار ونتيجتها.
- الكيان المفضل للمستخدم . يمكن تمثيل كل اشتراك مستخدم في كيان يحتوي على مرجع للاختبار ومعرف المستخدم الذي تم إنشاؤه من خدمة مستخدم App Engine. وهذا يسمح بإجراء استعلام فعال ثنائي الاتجاه (أي لجميع المستخدمين المشتركين في الاختبار ولجميع الاختبارات التي يفضلها المستخدم).
تجميع الكيان
تمثل كل وحدة اختبار جذر مجموعة الكيانات. كيانات التشغيل الاختباري هي كيانات فرعية لهذه المجموعة وكيانات أصلية لكيانات الجهاز، وكيانات نقطة ملف التعريف، وكيانات التغطية ذات الصلة بالاختبار والتشغيل الاختباري المعني.
النقطة الأساسية: عند تصميم علاقات السلالة، يجب عليك الموازنة بين الحاجة إلى توفير آليات استعلام فعالة ومتسقة مقابل القيود التي تفرضها قاعدة البيانات.
فوائد
يضمن متطلب الاتساق أن العمليات المستقبلية لن ترى تأثيرات المعاملة حتى يتم تنفيذها، وأن المعاملات في الماضي مرئية للعمليات الحالية. في Cloud Datastore، يقوم تجميع الكيانات بإنشاء جزر ذات تناسق قوي للقراءة والكتابة داخل المجموعة، والتي تكون في هذه الحالة عبارة عن عمليات تشغيل اختبارية وبيانات مرتبطة بوحدة اختبار. وهذا يقدم الفوائد التالية:
- يمكن التعامل مع عمليات القراءة والتحديثات لاختبار حالة الوحدة النمطية عن طريق وظائف التنبيه على أنها ذرية
- عرض متسق مضمون لنتائج حالة الاختبار داخل وحدات الاختبار
- الاستعلام بشكل أسرع داخل أشجار النسب
محددات
لا يُنصح بالكتابة إلى مجموعة كيانات بمعدل أسرع من كيان واحد في الثانية حيث قد يتم رفض بعض عمليات الكتابة. طالما أن مهام التنبيه والتحميل لا تتم بمعدل أسرع من عملية كتابة واحدة في الثانية، فإن البنية متينة وتضمن اتساقًا قويًا.
في النهاية، يعد الحد الأقصى للكتابة الواحدة لكل وحدة اختبار في الثانية أمرًا معقولًا لأن عمليات التشغيل الاختبارية عادةً ما تستغرق دقيقة واحدة على الأقل بما في ذلك الحمل الزائد لإطار عمل VTS؛ ما لم يتم تنفيذ الاختبار باستمرار في نفس الوقت على أكثر من 60 مضيفًا مختلفًا، فلا يمكن أن يكون هناك اختناق في الكتابة. ويصبح هذا الأمر غير مرجح نظرًا لأن كل وحدة هي جزء من خطة اختبار غالبًا ما تستغرق وقتًا أطول من ساعة واحدة. يمكن التعامل مع الحالات الشاذة بسهولة إذا أجرى المضيفون الاختبارات في نفس الوقت، مما يتسبب في دفعات قصيرة من الكتابة إلى نفس المضيفين (على سبيل المثال، عن طريق اكتشاف أخطاء الكتابة والمحاولة مرة أخرى).
اعتبارات القياس
لا يحتاج التشغيل الاختباري بالضرورة إلى أن يكون الاختبار هو الأصل (على سبيل المثال، يمكن أن يأخذ مفتاحًا آخر ويكون له اسم اختبار، ووقت بدء الاختبار كخصائص)؛ ومع ذلك، فإن هذا سوف يستبدل الاتساق القوي بالاتساق النهائي. على سبيل المثال، قد لا ترى مهمة التنبيه لقطة متسقة بشكل متبادل لأحدث عمليات تشغيل الاختبار ضمن وحدة اختبار، مما يعني أن الحالة العامة قد لا تصور تمثيلاً دقيقًا تمامًا لتسلسل عمليات تشغيل الاختبار. قد يؤثر هذا أيضًا على عرض عمليات التشغيل الاختبارية ضمن وحدة اختبار واحدة، والتي قد لا تكون بالضرورة لقطة متسقة لتسلسل التشغيل. وفي نهاية المطاف، ستكون اللقطة متسقة، ولكن لا توجد ضمانات بأن البيانات الأحدث ستكون كذلك.
حالات تجريبية
عنق الزجاجة المحتمل الآخر هو الاختبارات الكبيرة التي تحتوي على العديد من حالات الاختبار. القيدان التشغيليان هما الحد الأقصى لسرعة الكتابة داخل مجموعة الكيانات وهو واحد في الثانية، إلى جانب الحد الأقصى لحجم المعاملة وهو 500 كيان.
تتمثل إحدى الطرق في تحديد حالة اختبار لها اختبار تشغيل كسلف (على غرار كيفية تخزين بيانات التغطية وبيانات ملفات التعريف ومعلومات الجهاز):
في حين أن هذا النهج يوفر الذرية والاتساق، فإنه يفرض قيودا قوية على الاختبارات: إذا كانت المعاملة تقتصر على 500 كيان، فلا يمكن أن يحتوي الاختبار على أكثر من 498 حالة اختبار (بافتراض عدم وجود بيانات تغطية أو ملفات تعريف). إذا تجاوز الاختبار هذا، فلن تتمكن معاملة واحدة من كتابة جميع نتائج حالة الاختبار مرة واحدة، ويمكن أن يتجاوز تقسيم حالات الاختبار إلى معاملات منفصلة الحد الأقصى لإنتاجية الكتابة لمجموعة الكيانات وهو تكرار واحد في الثانية. وبما أن هذا الحل لن يتم توسيع نطاقه بشكل جيد دون التضحية بالأداء، فلا يوصى به.
ومع ذلك، بدلاً من تخزين نتائج حالة الاختبار كنتائج فرعية لتشغيل الاختبار، يمكن تخزين حالات الاختبار بشكل مستقل وتوفير مفاتيحها لتشغيل الاختبار (يحتوي تشغيل الاختبار على قائمة معرفات لكيانات حالات الاختبار الخاصة به):
للوهلة الأولى، قد يبدو أن هذا يكسر ضمان الاتساق القوي. ومع ذلك، إذا كان لدى العميل كيان تشغيل اختباري وقائمة بمعرفات حالة الاختبار، فلن يحتاج إلى إنشاء استعلام؛ يمكنها بدلاً من ذلك الحصول على حالات الاختبار مباشرة من خلال معرفاتها، والتي نضمن دائمًا أن تكون متسقة. يخفف هذا النهج إلى حد كبير من القيود المفروضة على عدد حالات الاختبار التي قد يكون لها تشغيل اختباري مع اكتساب اتساق قوي دون التهديد بالكتابة المفرطة داخل مجموعة الكيانات.
أنماط الوصول إلى البيانات
تستخدم لوحة معلومات VTS أنماط الوصول إلى البيانات التالية:
- المفضلة للمستخدم . يمكن الاستعلام عنها باستخدام مرشح المساواة في الكيانات المفضلة للمستخدم التي لها كائن مستخدم App Engine المعين كخاصية.
- قائمة الاختبار . استعلام بسيط عن كيانات الاختبار. لتقليل عرض النطاق الترددي لعرض الصفحة الرئيسية، يمكن استخدام الإسقاط على أعداد النجاح والرسوب وذلك لحذف القائمة الطويلة المحتملة لمعرفات حالة الاختبار الفاشلة وبيانات التعريف الأخرى التي تستخدمها وظائف التنبيه.
- يجري الاختبار . يتطلب الاستعلام عن كيانات التشغيل الاختباري إجراء فرز على المفتاح (الطابع الزمني) وتصفية محتملة لخصائص تشغيل الاختبار مثل معرف البنية وعدد التمريرات وما إلى ذلك. من خلال إجراء استعلام أسلاف باستخدام مفتاح كيان اختبار، تكون القراءة متسقة بشدة. عند هذه النقطة، يمكن استرجاع كافة نتائج حالة الاختبار باستخدام قائمة المعرفات المخزنة في خاصية التشغيل الاختباري؛ ويضمن هذا أيضًا أن يكون نتيجة متسقة بقوة بسبب طبيعة عمليات الحصول على مخزن البيانات.
- بيانات التعريف والتغطية . يمكن إجراء الاستعلام عن بيانات التوصيف أو التغطية المرتبطة بالاختبار دون استرداد أي بيانات أخرى لتشغيل الاختبار (مثل بيانات التوصيف/التغطية الأخرى، وبيانات حالة الاختبار، وما إلى ذلك). سيؤدي الاستعلام الأصلي باستخدام مفاتيح كيان الاختبار والتشغيل الاختباري إلى استرداد جميع نقاط التوصيف المسجلة أثناء التشغيل الاختباري؛ ومن خلال التصفية أيضًا على اسم نقطة التوصيف أو اسم الملف، يمكن استرداد كيان واحد للتوصيف أو التغطية. نظرًا لطبيعة استعلامات الأسلاف، فإن هذه العملية متسقة بشدة.
للحصول على تفاصيل حول واجهة المستخدم ولقطات شاشة لأنماط البيانات هذه قيد التنفيذ، راجع VTS Dashboard UI .