اختبار الحسابات والمنتجات في نظام الإنتاج

Question

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

لقد قمت بتطبيق بروتوكولات المراسلة التي تحتوي على سمة اختبار = "True" في المواصفات، وتساءلت عما إذا كان المخطط الحديث يجب أن يتضمن بيانات وصفية لوضع علامات على الطلبات والحسابات والمعاملات وما إلى ذلك.ككيانات اختبارية تتم معالجتها تمامًا مثل أي كيان آخر - ولكن أقل بقليل من النقطة التي يتم فيها إنفاق الأموال.أي:فهو يقوم بتزييف شحن بطاقة ائتمان وهمية وتزييف شحنة طرد ما.

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

Answer 1

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

Answer 2

أتخيل أن شرطة أفضل الممارسات ستصرح بالشعار "لا تختبر أبدًا في الهمز" وربما ترمي أيضًا "لا ينبغي للمطورين الوصول إلى الهمز".

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

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

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

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

Answer 3

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

في بيئتي، نستخدم نظام تثبيت السرعة للإنشاءات المستمرة.يتم فحص البرامج النصية SQL لإنشاء قاعدة البيانات في CVS مع كل شيء آخر، ويتم إعادة بناء قاعدة البيانات من تلك البرامج النصية على أساس يومي.

بيانات الاختبار لدينا هي مجموعة ثانية من البرامج النصية SQL، والتي يتم تشغيلها لقاعدة بيانات الاختبار ولا يتم تشغيلها لقاعدة بيانات الإنتاج.

نظرًا لأن بيانات اختبار البيئة لدينا لا تمس قاعدة بيانات الإنتاج أبدًا.

هذا الحل يعمل بشكل رائع بالنسبة لنا.

Answer 4

لن أضع أي بيانات اختبار في نظام الإنتاج ولا أرغب في الوصول إلى هذا النظام كمطور.

أنا أعمل في صناعة تحتوي على معلومات طبية ومالية حساسة للغاية، والحصول على مثل هذه المعلومات سيجعل من المستحيل التمييز بين البيانات المنتجة والبيانات الموجودة في نظام الاختبار.

أفضل ممارسة لـ IMHO هي الفصل التام بين هذين العالمين والاستثمار في إعداد إجراء لإعداد بيئة اختبار شاملة.

Answer 5

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

وكما قلت، فهذه تطبيقات داخلية فقط، وبالتالي يتم تقليل المخاطر الأمنية إلى حد ما - وهذا مصدر قلق مشروع للغاية.

Answer 6

لا تختبر أبدًا في الإنتاج، على الرغم من أن هذا هو المكان الذي يتم فيه توليد كل الإيرادات/جمع الإحصائيات/يحدث السحر...؟

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

ليس من الضار أن يكون لديك بيانات اختبار على المنتج، عليك أن تكون حذرًا.