قاعدة بيانات لوحة معلومات VTS

لدعم لوحة معلومات للتكامل المستمر تكون قابلة للتطوير وذات أداء ومرنة ، يجب تصميم الواجهة الخلفية للوحة معلومات VTS بعناية مع فهم قوي لوظائف قاعدة البيانات. Google Cloud Datastore هي قاعدة بيانات NoSQL تقدم ضمانات ACID للمعاملات والاتساق النهائي بالإضافة إلى الاتساق القوي داخل مجموعات الكيانات. ومع ذلك ، فإن الهيكل مختلف تمامًا عن قواعد بيانات SQL (وحتى Cloud Bigtable) ؛ بدلاً من الجداول والصفوف والخلايا ، توجد أنواع وكيانات وخصائص.

توضح الأقسام التالية هيكل البيانات وأنماط الاستعلام لإنشاء خلفية فعالة لخدمة ويب VTS Dashboard.

جهات

تقوم الكيانات التالية بتخزين الملخصات والموارد من عمليات التشغيل الاختبارية لـ VTS:

  • كيان الاختبار . يخزن البيانات الوصفية حول عمليات التشغيل الاختبارية لاختبار معين. مفتاحه هو اسم الاختبار وخصائصه تشمل عدد الفشل وعدد مرات النجاح وقائمة بأعطال حالة الاختبار من وقت تحديث مهام التنبيه.
  • اختبار تشغيل الكيان . يحتوي على بيانات وصفية من تشغيلات اختبار معين. يجب أن يخزن الطوابع الزمنية لبداية ونهاية الاختبار ، ومعرف إنشاء الاختبار ، وعدد حالات الاختبار التي تم اجتيازها وفشلها ، ونوع التشغيل (على سبيل المثال ، ما قبل الإرسال ، أو الإرسال اللاحق ، أو المحلي) ، وقائمة ارتباطات السجل ، والمضيف اسم الجهاز ، وحسابات ملخص التغطية.
  • كيان معلومات الجهاز . يحتوي على تفاصيل حول الأجهزة المستخدمة أثناء التشغيل التجريبي. يتضمن معرّف إنشاء الجهاز واسم المنتج وهدف البناء والفرع ومعلومات ABI. يتم تخزين هذا بشكل منفصل عن كيان التشغيل التجريبي لدعم تشغيل الاختبار متعدد الأجهزة بطريقة واحد لأكثر.
  • الكيان تشغيل نقطة التنميط . يلخص البيانات التي تم جمعها لنقطة تعريف معينة ضمن تشغيل اختباري. يصف تسميات المحور ، واسم نقطة التنميط ، والقيم ، والنوع ، ووضع الانحدار لبيانات التشكيل الجانبي.
  • كيان التغطية . يصف بيانات التغطية التي تم جمعها لملف واحد. يحتوي على معلومات مشروع Git ومسار الملف وقائمة عدد التغطية لكل سطر في الملف المصدر.
  • اختبار حالة تشغيل الكيان . يصف نتيجة حالة اختبار معينة من تشغيل اختباري ، بما في ذلك اسم حالة الاختبار ونتيجتها.
  • كيان المستخدم المفضل . يمكن تمثيل كل اشتراك مستخدم في كيان يحتوي على مرجع للاختبار ومعرف المستخدم الذي تم إنشاؤه من خدمة مستخدم App Engine. يتيح ذلك إجراء استعلام ثنائي الاتجاه فعال (أي لجميع المستخدمين المشتركين في الاختبار ولجميع الاختبارات التي يفضلها المستخدم).

تجميع الكيانات

تمثل كل وحدة اختبار جذر مجموعة الكيانات. كيانات التشغيل التجريبي هي كيانات تابعة لهذه المجموعة والآباء لكيانات الجهاز ، وكيانات نقطة التوصيف ، وكيانات التغطية ذات الصلة بسلف الاختبار والاختبار المعني.

الشكل 1 . اختبار أصل الكيان.

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

فوائد

يضمن متطلب التناسق أن العمليات المستقبلية لن ترى آثار المعاملة حتى يتم الالتزام بها ، وأن المعاملات في الماضي مرئية للعمليات الحالية. في Cloud Datastore ، يُنشئ تجميع الكيانات جزرًا من تناسق قوي في القراءة والكتابة داخل المجموعة ، والذي يمثل في هذه الحالة جميع عمليات التشغيل الاختبارية والبيانات المتعلقة بوحدة اختبار. يقدم هذا الفوائد التالية:

  • يمكن التعامل مع القراءات والتحديثات لاختبار حالة الوحدة النمطية عن طريق وظائف التنبيه على أنها ذرية
  • عرض متسق مضمون لنتائج حالة الاختبار داخل وحدات الاختبار
  • استعلام أسرع داخل أشجار النسب

محددات

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

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

اعتبارات القياس

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

حالات تجريبية

الاختناق المحتمل الآخر هو الاختبارات الكبيرة مع العديد من حالات الاختبار. القيدان التشغيليان هما الحد الأقصى لسرعة الكتابة داخل مجموعة كيانات بواقع واحد في الثانية ، إلى جانب الحد الأقصى لحجم المعاملة البالغ 500 كيان.

تتمثل إحدى الطرق في تحديد حالة اختبار لها تشغيل اختباري كأحد الأسلاف (على غرار كيفية تخزين بيانات التغطية وبيانات التنميط ومعلومات الجهاز):

الشكل 2 . تنحدر حالات الاختبار من عمليات التشغيل التجريبية (غير مستحسن).

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

ومع ذلك ، بدلاً من تخزين نتائج حالة الاختبار كأطفال للتشغيل التجريبي ، يمكن تخزين حالات الاختبار بشكل مستقل وتوفير مفاتيحها للتشغيل التجريبي (يحتوي التشغيل التجريبي على قائمة بالمعرفات لكيانات حالات الاختبار الخاصة به):

الشكل 3 . يتم تخزين حالات الاختبار بشكل مستقل (موصى به).

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

أنماط الوصول إلى البيانات

تستخدم لوحة معلومات VTS أنماط الوصول إلى البيانات التالية:

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

للحصول على تفاصيل حول واجهة المستخدم ولقطات الشاشة لأنماط البيانات هذه أثناء العمل ، راجع VTS Dashboard UI .