إدارة بيانات اختبار SAP: بيانات مقنّعة بحجم الإنتاج

إدارة بيانات اختبار SAP هي الطريقة التي تمنحون بها كل نظام اختبار بيانات تتصرف كبيانات الإنتاج دون كشف تفاصيل أشخاص حقيقيين. قاعدتي بسيطة: بيانات مقنّعة، ولكن بمستوى الإنتاج، في الحجم وفي الواقعية.

البيانات الهزيلة المصنوعة يدويًا تخفي العيوب المهمة. وبيانات الإنتاج غير المقنّعة تضع سجلات العملاء والموردين والموظفين في أنظمة ضوابطها أضعف من ضوابط الإنتاج.

بيانات الاختبار جزء واحد من خطة اختبار أوسع. ويغطي دليلي شرح اختبار SAP أنواع الاختبار، ومن يتولاها، وموقعها في SAP Activate.

لا يستطيع الاختبار أن يكتشف إلا مشكلة تستطيع بياناته إثارتها. فالعميل الذي لديه خمسة بنود مفتوحة يتصرف بشكل مختلف عن عميل لديه خمسون ألفًا، وشرط التسعير الذي لم ينشئه أحد في عميل الاختبار لن يفشل أبدًا في عميل الاختبار.

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

لهذا أصرّ على بيانات بمستوى الإنتاج. وهذا يعني أربعة أمور:

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

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

واختبار التزامن على قاعدة بيانات شبه فارغة لا يثبت إلا القليل. ويغطي دليلي إلى اختبار أداء SAP كيفية إعداد هذه الاختبارات.

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

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

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

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

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

يقارن الجدول بينها في النقاط التي تحدد الملاءمة.

الطريقة	ما تحصلون عليه	الحجم	معالجة الخصوصية	الأنسب لـ
نسخة النظام الكاملة	نسخة مطابقة للإنتاج، بكل عميل وكل جدول	كامل	يجب تشغيل الإخفاء بعد النسخ وقبل منح المستخدمين الوصول	اختبارات الأداء والتحويلات التجريبية وتجارب الانتقال
نسخة العميل	نسخ عميل واحد داخل نظام أو بين نظامين؛ ويحدد ملف تعريف النسخ ما إذا كانت البيانات الرئيسية وبيانات المعاملات تُنسخ أيضًا	كامل أو التهيئة فقط	كنسخة النظام حين تُنسخ بيانات التطبيقات	عملاء جدد للاختبار أو التدريب، وإعادة عميل إلى حالة معروفة
SAP Test Data Migration Server (TDMS)	نسخة مخفضة، مختارة حسب الفترة الزمنية أو الوحدة التنظيمية، مع تشويش البيانات	مخفض	قواعد التشويش داخل الأداة	بيئات SAP Business Suite القائمة المرخصة لها بالفعل
أدوات النسخ الانتقائي من الشركاء	كائنات أعمال أو شرائح مختارة، تُنسخ عند الطلب وتُقنَّع أثناء النقل	مخفض وموجّه	قواعد الإخفاء داخل الأداة، تُطبَّق أثناء النسخ	التحديثات المنتظمة، وبيانات الانحدار، وإعادة إنتاج العيوب
بيانات مبنية أو مرحَّلة	بيانات تُنشأ بالسيناريوهات البرمجية أو بعمليات تحميل الترحيل أو بالإدخال اليدوي	بقدر ما تبنون	لا بيانات شخصية حقيقية إذا بُنيت من الصفر	اختبارات الوحدة المبكرة، ومشاريع Greenfield قبل التشغيل الفعلي

نسخ النظام الكاملة ونسخ العملاء

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

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

SAP Test Data Migration Server

ينشئ SAP Test Data Migration Server (TDMS) أنظمة غير إنتاجية مخفضة من بيانات الإنتاج، مع تشويش الحقول الحساسة. وقد نشأ على SAP Business Suite، ومجموعة الوثائق الحالية على SAP Help Portal خاصة بالإصدار 4.0 SP14.

لم أجد بيانًا رسميًا من SAP بشأن تغطية TDMS لإصدارات S/4HANA الحالية أو بشأن خلَف مسمّى له. إذا كنتم تخططون للاعتماد عليه، فاسألوا SAP كتابيًا عما إذا كان يدعم الإصدار المستهدف ونموذج النشر لديكم، بما في ذلك RISE with SAP.

SAP Landscape Transformation ونسخ الهيكل (Shell)

SAP Landscape Transformation مجموعة من أدوات التحليل والتحويل تستخدمها SAP في الانتقال الانتقائي للبيانات. ويصف SAP Learning تحويل الهيكل (shell conversion) بأنه نسخة من نظام الإنتاج تُصنع دون البيانات الرئيسية وبيانات المعاملات، ثم تُحوَّل إلى S/4HANA.

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

تنسخ عدة منتجات من الشركاء بيانات أعمال مختارة إلى أنظمة اختبار SAP وتقنّعها في الطريق. هذه هي المنتجات التي استطعت التحقق من ادعاءاتها على موقع المورد نفسه، دون ترتيب.

1. EPI-USE Labs Data Sync Manager. مجموعة أدوات لنسخ البيانات وإخفائها عبر بيئات SAP ABAP، تشمل العملاء المخففين، والنسخ على مستوى الكائن، والإخفاء بقواعد معرّفة مسبقًا. وتذكر EPI-USE Labs أن Data Sync Manager معتمد للتكامل مع SAP S/4HANA وS/4HANA Cloud، ويعمل مع RISE with SAP.
2. SNP Kyano Test Data Organizer. يستخرج البيانات التي يحتاجها الاختبار بدلًا من النظام كله، ويقنّع البيانات الحساسة أثناء توفيرها. وتصف SNP أداة Test Data Organizer بأنها متوافقة مع RISE with SAP Private Cloud Edition.
3. Qlik Gold Client. ينسخ بيانات معاملات مختارة من الإنتاج إلى أهداف غير إنتاجية ويزامنها، مع إخفاء ثابت للأنظمة القائمة وإخفاء ديناميكي للبيانات أثناء النقل.
4. Natuvion DCS Protect. يعثر على البيانات الشخصية ويطبق إخفاء الهوية أو الاستعارة في أنظمة الاختبار والجودة والتطوير والتدريب. وتضعه Natuvion لعمليات الترحيل التجريبية وللتشغيل المستمر، ولا تذكر S/4HANA في تلك الصفحة، فتأكدوا من التغطية مباشرة.

قبل أن تشتروا، اطلبوا من كل مورد الإجابة عن هذه الأسئلة على أنظمتكم أنتم:

1. ما إصدارات S/4HANA ونماذج النشر التي يدعمها اليوم؟
2. هل يقنّع البيانات قبل أن تغادر الإنتاج، أم بعد أن تصل إلى الهدف؟
3. هل يبقى الإخفاء متسقًا عبر الأنظمة المتصلة، بحيث يطابق العميل المقنّع في S/4HANA العميل نفسه في نظام CRM أو مستودع البيانات لديكم؟
4. كم يستغرق تحديث رمز شركة واحد بأحجام الإنتاج؟
5. من يتولى صيانة قواعد الإخفاء حين تضيفون جداول أو حقولًا مخصصة؟

كل مرحلة اختبار تحتاج إلى البيانات لسبب مختلف. ومن هنا أبدأ حين أخطط لبيانات الاختبار في برنامج S/4HANA.

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

يستحق UAT عناية إضافية. فيجب أن يتولى قطاع الأعمال اختبار قبول المستخدم، وفي رأيي يحتاج إلى ما لا يقل عن 6 إلى 8 أسابيع.

امنحوا المستخدمين بيانات يتعرفون عليها: عملاؤهم وموادهم وقوائم أسعارهم، حتى بأسماء مقنّعة. ويغطي دليلي إلى اختبار قبول المستخدم في SAP كيفية إدارته.

والتحويلات التجريبية تتبع المنطق نفسه. ففي تحويل Brownfield أخطط لثلاث عمليات تحويل تجريبية، ويجب أن تُنفَّذ كل منها على نسخة حديثة من الإنتاج.

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

بيئتان، وخطتا تحديث

خلال البرنامج أشغّل بيئتين منفصلتين: واحدة للمشروع وأخرى للأعمال الاعتيادية (BAU). وبذلك تُختبر تغييرات الدعم الحي وتغييرات المشروع كلٌّ على حدة.

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

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

يستهلك الاختبار نحو 35 بالمئة من جهد البرنامج. خططوا لبيانات الاختبار ضمن هذا الجهد، لا في الأسبوع السابق لاختبار SIT.

هذا هو الترتيب الذي أتبعه:

1. اتفقوا على المبدأ كتابة. بيانات مقنّعة بمستوى الإنتاج، يعتمدها راعي البرنامج ومسؤول حماية البيانات ومالكو الأعمال.
2. حددوا البيانات الشخصية والحساسة. العملاء والموردون والموظفون والتفاصيل المصرفية وجهات الاتصال وحقول النص الحر والمرفقات وأي جداول مخصصة تحتويها.
3. اكتبوا قواعد الإخفاء. قرروا حقلًا بحقل ما الذي يُستبدل أو يُحتفظ به أو يُحذف، وحافظوا على اتساق القيم البديلة عبر الأنظمة المتصلة.
4. اربطوا البيانات بكل مرحلة اختبار. استخدموا الجدول أعلاه نقطة انطلاق، وحددوا الحجم لاختبارات الأداء والتزامن أولًا.
5. اختاروا طرق النسخ والأدوات. نسخ كاملة حيث يهم الحجم، ونسخ انتقائية حيث تهم السرعة والتكرار، وتحققوا من دعم الأداة لإصداركم.
6. حددوا تقويم التحديث. خطة لكل بيئة، مع تحديثات موقوتة قبل كل جولة SIT وUAT وكل تحويل تجريبي.
7. أغلقوا الوصول حتى يُتحقق من الإخفاء. لا يسجل أحد من خارج الفريق التقني الأساسي دخوله إلى نسخة جديدة حتى ينجح فحص الإخفاء.

ثم اجعلوها بوابة. فالاستراتيجية ومعايير الدخول ومعايير الخروج لكل دورة موجودة في دليلي إلى استراتيجية اختبار S/4HANA، وجاهزية بيانات الاختبار مكانها في معايير الدخول لكل جولة.

الخطوة التالية الملموسة: اكتبوا قائمة بكل نظام غير إنتاجي يحتوي اليوم على نسخة من بيانات الإنتاج، وتحققوا من أيها جرى إخفاؤه.

إذا أردتم رأيًا مستقلًا في نهج لبيانات الاختبار أو في خطة اختبار لبرنامج S/4HANA، يمكنكم التواصل معي هنا.

ما هي إدارة بيانات اختبار SAP؟

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

هل يمكنني استخدام بيانات الإنتاج لاختبار SAP؟

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

هل لا يزال SAP TDMS متاحًا لـ S/4HANA؟

الوثائق الحالية لـ TDMS على SAP Help Portal خاصة بالإصدار 4.0 SP14، وقد نشأ TDMS على SAP Business Suite. لم أجد بيانًا رسميًا من SAP بشأن تغطيته لإصدارات S/4HANA الحالية. اسألوا SAP كتابيًا قبل أن تخططوا على أساسه.

ما الأدوات التي تنشئ بيانات اختبار SAP انتقائية؟

SAP Test Data Migration Server، إضافة إلى منتجات الشركاء مثل EPI-USE Labs Data Sync Manager وSNP Kyano Test Data Organizer وQlik Gold Client. ويركز Natuvion DCS Protect على إخفاء هوية البيانات واستعارتها في أنظمة الاختبار. تحققوا من كل منها مقابل إصدار S/4HANA ونموذج النشر لديكم.

ما حجم بيانات الاختبار التي أحتاجها لاختبار أداء SAP؟

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