التحقق من صحة الخدمات المدفوعة هي واحدة من القضايا الهندسية الرئيسية في اختبار Badoo. تم دمج تطبيقنا مع 70 من مزودي الدفع في 250 دولة في العالم ، ويمكن أن يؤدي الخلل في واحد منهم على الأقل إلى نتائج غير متوقعة.
في هذه المقالة ، سأتحدث عن طرق الاختبار التي نستخدمها في Badoo ، وحدود قابلية تطبيق هذه الأساليب - مراحل الاختبار التي تكون فيها أكثر فعالية.
ستكون هذه المقالة مفيدة للمختبرين والمطورين ومديري المنتجات ، الذين تم دمج مشاريعهم بالفعل مع مزودي الدفع ، أو أن عملية التكامل بدأت للتو. إذا كنت تواجه عملك في مشكلة اختيار طرق اختبار لمثل هذه الدمج ، فمرحبًا بك في cat!
اسمي فلاديمير سولودوف ، I Billing QA Engineer في Badoo: أنا منخرط في التحقق من تكامل الاختبار ومعالجة الدفع. ساعدني زميلي فيكتور كورونيفيتش في إعداد النص: حيث أعددنا معه تقريرًا في مؤتمر هايسنبوج ( فيديو ). في المقالة ، قمنا بتوسيع منطقة الوصف لتشمل جميع عمليات التكامل مع موفري الدفع الذين يستخدمون في Badoo ، وقمنا بتصنيف ووصف ممارسة إزالة التبعيات الخارجية بمزيد من التفاصيل.باستخدام دراسات الحالة التجارية كمثال ، سوف أخبرك لماذا يجب عليك إيلاء المزيد من الاهتمام لاختبار الخدمات المدفوعة وكيف لا تؤدي إلى تفاقم المشاكل إذا حدثت مع ذلك. ثم سنستمر في وصف المشكلات الفنية لاختبار التكامل وطرق حلها.
الجزء الثاني من المقالة ، الذي نتحدث فيه أكثر عن أتمتة اختبار الخدمات المدفوعة في تطبيقات iOS ، موجود
هنا .
دعنا نذهب!
مواصفات اختبار الفواتير
عادةً ما يكون الهدف من العمل هو تحقيق إيرادات. في Badoo ، شبكة اجتماعية للتعارف ، يتم كسب الدخل عن طريق القروض والاشتراكات المتميزة. القروض هي العملة الداخلية لـ Badoo. بمساعدتهم ، على سبيل المثال ، يمكنك رفع ملف التعريف الخاص بك في نتائج البحث في المقام الأول ، وتقديم هدية لمستخدم آخر ، وأكثر من ذلك. يسري الاشتراك المتميز لفترة معينة من الوقت ويوفر لك العديد من الخيارات في وقت واحد: قم بتشغيل الوضع "غير المرئي" ، ورؤية الأشخاص الذين أبدوا اهتمامًا بك ، وتأكيد صحة حسابك وغير ذلك الكثير.
لجعل هذه الخدمات المدفوعة تعمل ، نستخدم التكامل مع أكثر من 70 من مزودي الدفع. يعتمد اختيار المزود على النظام الأساسي والبلد والجهاز ومشغل الهاتف المحمول وعوامل أخرى. لذلك ، فإن مسألة اختبار الخدمات المدفوعة أمر ملح للغاية.
للبدء ، فكر في سبب وجوب التعامل مع اختبار الخدمات المدفوعة باهتمام خاص. هناك سببان.
1. البق الفواتير حاسمة لرجال الأعمال.
المشكلة الأولى هي السمعة. يصبح المستخدم الذي دفع ثمن الخدمة أكثر حساسية (وأقل تسامحًا) للأخطاء في التطبيق. أي تعليقات في الأماكن العامة ، سواء كانت مراجعة لتطبيق مدونة أو تعليقًا على App Store أو Google Play ، من مستخدم واجه خطأً في خدمة مدفوعة ، ستكون أكثر عاطفية - وهذا عامل يؤدي إلى فقدان السمعة.
المشكلة الثانية هي أنه بمجرد أن تبدأ في تلقي الأموال من مستخدم مقابل خدمة ما ، فإنك تصبح هدفًا لقانون يحمي مستهلك الخدمة. ويمكن أن تتحول خسائر السمعة بسهولة إلى خسائر مالية.
الشركات تخسر المال بثلاث طرق.
الطريقة الأولى هي
المبالغ المستردة . لنفترض أن المستخدم يجد أنك بعته خدمة لا تفي بتوقعاته. في هذه الحالة ، سيتصل بفريق الدعم الخاص بك. يجري موظفوها تحقيقًا واكتشفوا أن توقعات المستخدم لم تتحقق بالفعل نظرًا لوجود خطأ في التطبيق. يمكنك بدء استرداد. في هذه الحالة ، هناك استرداد: نتيجة لذلك ، تواجه الشركة أرباحًا ضائعة ، وهذه هي الطريقة الأكثر ضررًا لخسارة الأموال.
الطريقة الثانية هي
تحميل التكاليف . لنفترض أن نفس الموقف قد حدث ، فلم يتصل المستخدم سوى بخدمة الدعم الخاصة بك ، ولكن البنك الذي أصدر البطاقة أو مزود الدفع. البنك / مزود يبدأ استرداد. في هذه الحالة ، نحن نتعامل مع تحميل التكاليف. الخطر على الأعمال هنا ليس فقط في الأرباح الضائعة. بعد عدد معين من عمليات رد التكاليف ، تتلقى الشركة غرامة ، وينخفض تصنيف المخاطر. يؤدي خفض التصنيف ، بدوره ، إلى ارتفاع تكلفة خدمات مزودي الدفع.
الطريقة الثالثة -
الدعاوى (المطالبات) . في الحالات الأكثر إهمالًا ، يمكن أن تتم الدعاوى (بما في ذلك الدعاوى الجماعية) ، مما يؤدي إلى عواقب وخيمة. لذلك ، في عام 2015 ، بعد دعوى قضائية من قبل شركة Ofgem's regulator ، اضطرت British Gas لدفع تعويضات بملايين الدولارات للمستخدمين الذين فرضوا رسومًا أعلى بسبب خطأ في نظام الشحن. اقرأ المزيد عن هذا
هنا .
2. لاختبار التكامل ، هناك حاجة إلى المعرفة والخبرة.
غالبًا ما تواجه الفرق التي بدأت عملية التكامل مع مزودي الدفع هذه المشكلة. نظرًا لعدم معرفة جميع حالات الفوترة المحتملة ، فإنهم يفتقدون إلى الفروق الدقيقة المهمة عندما يدركون رد فعل النظام على إخطارات مزودي الدفع.
يمكن أن يؤدي ذلك إلى عواقب غير متوقعة - من الأرباح الضائعة إلى المستخدمين غير الراضين.
دعونا ننظر إلى المخطط الذي يسرد أنواع الخدمات المدفوعة ، والنظر في المشكلة بعناية أكبر.
الشكل 1. حالات الفوترة المحتملةهناك ثلاث حالات رئيسية: خطأ ، ودفع ناجح ، واسترداد الأموال للمستخدم. لكن كل حالة لها تفاصيل ، كل حالة يجب على نظامك التعامل معها بشكل مختلف.
يمكن أن تكون
الأخطاء حرجة وغير حرجة. يمكن أن يُعزى خطأ الإشعار إلى عدم الأهمية - عندما يقوم مزود الدفع بإعلام حول نقص الأموال في حساب المستخدم ، والحظر الحرج - لطريقة الدفع الخاصة بالمستخدم. وإذا كان بإمكانك في الحالة الأولى محاولة الدفع لاحقًا ، فعندئذ في الحالة الثانية - سيكون من الجيد معرفة سبب حظر هذه الطريقة. ربما لاحظ المستخدم في الاحتيال ويجب أن تكون أكثر حذرا بشأن معاملاته.
المبالغ المستردة . أنت تعرف بالفعل أن هناك نوعين من العائدات: المبالغ المستردة والمبالغ المستردة. يجب أن يستجيب نظامك بشكل مختلف لهم. على سبيل المثال ، بعد استرداد التكاليف ، من المنطقي التفكير في حظر بعض وظائف التطبيق الخاص بك للمستخدم ، لأن استرداد التكاليف هو أحد أكثر طرق الاحتيال شيوعًا.
قد يكون
الدفع الناجح عبارة عن دفعة لمرة واحدة ، أو قد يكون اشتراكًا.
يمكن أن تكون المدفوعات لمرة واحدة مستهلكة وغير قابلة للاستهلاك. مثال على الدفع المستنفد الذي درسناه في بداية المقال - هذه قروض في Badoo. يمكن تقديم مثال للدفع غير القابل للاستهلاك من الألعاب. افترض أن لديك شخصية تلعبها. تريد أن تشتري له القوى العظمى التي كانت موجودة منذ بعض الوقت. في هذه الحالة ، ينتمي الشراء إلى فئة المدفوعات غير المستهلكة.
اشتراكات (الاشتراكات). هنا هو أكبر مجموعة متنوعة من الحالات. بالإضافة إلى الشراء الأولي للاشتراك ، قد يكون لديك:
- تجديد اشتراك (تجديد) ؛
- إغلاق الاشتراك (إلغاء الاشتراك) ؛
- الاشتراك التجريبي (التجريبي) ؛
- اشتراك فترة السماح: عندما يتعذر علينا تجديد الاشتراك ومحاولة الدفع مرة أخرى لفترة زمنية تسمى فترة السماح. بالنسبة للمستخدم ، فإن فترة السماح تبدو هكذا. لنفترض أنك اشتريت اشتراكًا شهريًا في الصحف. تحاول الشركة التي ترسل إليك الصحف شطب الدفعة للشهر التالي من الاشتراك بعد نهاية الشهر الأول ، لكن لا يمكنها القيام بذلك (بسبب قفل البطاقة ، ونقص الأموال في الحساب ، وما إلى ذلك). إذا كانت فترة صلاحية فترة السماح هي عشرة أيام ، فستحاول الشركة خلال هذا الوقت شطب الدفعة ، بينما يظل الاشتراك ساريًا. إذا كانت الشركة غير قادرة على شطب الأموال ، فسيتم إلغاء الاشتراك. إذا كان الأمر كذلك ، يتم تجديد الاشتراك من تاريخ آخر دفعة ؛
- الدفع الجزئي (الفواتير الجزئية). على سبيل المثال ، يسمح لك PayPal بإجراء مدفوعات جزئية إذا لم يكن لدى حساب المستخدم أموال كافية (دفع جزئي) ، أو تقسيم الدفعة إلى أجزاء (فاتورة جزئية).
يجب أيضًا أن تأخذ في الاعتبار خاصيتين تعتمدان تمامًا على مزود الدفع: يمكن التحكم في الاشتراك عن طريق تطبيقك أو إدارته خارجيًا.
- الاشتراك الذي تتم إدارته داخليًا ، على سبيل المثال ، هو اشتراك يستخدم بطاقات الائتمان أو PayPal ، وعندما يتم منحك رمز مميز بعد الدفعة الأولى تقوم بإعادة تقديمه إلى الموفر دون أي تفاصيل دفع للمستخدم.
- الاشتراك المدار من الخارج هو عندما يتحكم مجمع الدفع بالكامل في اشتراكاتك ويرسل إليك ببساطة إشعارات حول أوضاعهم الحالية.
في الشكل ، يتم تسليط الضوء على المناطق الأكثر وضوحا ، رد الفعل الذي يتحقق عادة في المقام الأول ، باللون الأرجواني. جميع الآخرين تبدأ في أن تؤخذ في الاعتبار في وقت لاحق من ذلك بكثير ، كما تراكم الخبرات. ومما يسهل ذلك إلى حد كبير التطبيق غير الصحيح لمنهجيات التطوير التكراري في مجال الفواتير.
الشكل 2. حالات الفواتير التي يتم تنفيذها في المقام الأول في النظممثل هذا التطبيق المرحلي يمكن أن يؤدي إلى عواقب لا يمكن التنبؤ بها. على سبيل المثال ، في أحد المشاريع التي عملت عليها قبل Badoo ، لم تتم مراعاة إمكانية استرداد الأموال. ونتيجة لذلك ، لم تتم جميع العائدات من خلال عمليات الاسترداد ، ولكن من خلال عمليات رد التكاليف ، والتي أثرت سلبًا على تصنيف مخاطر الشركة وأدت إلى إخفاقات في جمع إحصاءات الدخل. يمكن أن يؤدي الجهل بمجموعة كاملة من حالات الفوترة إلى خسارة الأرباح أو تعرض الشركة للمستخدمين الذين يشعرون بالغش.
لذلك ، فمن ناحية ، يجب العثور على الأخطاء في معالجة الدفع قبل الإصدار ، لأنها يمكن أن تؤدي إلى عواقب سلبية للغاية. إذا لم يكن ذلك ممكنًا ، فمن المهم أن نفهم في أسرع وقت ممكن أن الخطأ حصل في إصدار إصدار التطبيق ، وإصلاحه ، والأهم من ذلك ، ما ينسى كثير من الناس ، "طمأنة" المستخدمين الذين واجهوا هذا الخطأ.
من ناحية أخرى ، فإن الموقف معقد بسبب حقيقة أن التكامل مع مزودي الدفع هو التفاعل دائمًا مع الصندوق الأسود ، مما يضيف الكثير من المتغيرات إلى عملية الاختبار.
المشكلات الفنية أثناء اختبار الفوترة
دعنا نتأملها على سبيل المثال من خلال تكامل Badoo مع متجر التطبيقات.
تنتمي الاشتراكات في App Store إلى فئة المدارة من الخارج ، أي تتم إدارتها بشكل كامل من جانب الموفر ، ويمكن لنظامنا طلب الحالة الحالية فقط أو تلقي إشعار بتغييره.
لقد اخترنا هذا التكامل على وجه التحديد ، لأنه الأكثر تعقيدًا ويحتوي على جميع الحالات المتنوعة التي يمكن العثور عليها في عملية دمج الخدمة مع مزودي الدفع الآخرين.
بادئ ذي بدء ، ننتقل إلى شراء مستهلك لمرة واحدة.
الشكل 3. عملية تسديد دفعة لمرة واحدةفي الخطوة 1 ، يقدم المستخدم طلبًا لشراء الخدمة. يقرر التطبيق أنه يجب إجراء الدفع ، وفي الخطوة 2 ، يتم نقل التحكم إلى مزود الدفع (متجر التطبيقات). الخطوة 3: يتم تقديم المستخدم مع نموذج لإجراء الدفع. الخطوة 4: يوفر المستخدم بيانات للدفع. الخطوة 5: يكمل الموفر المعاملة ويبلغ النتيجة إلى التطبيق ، ويعيد إيصالًا يحتوي على معلومات كاملة عن الشراء (التاريخ ، الخدمة ، الحالة ، إلخ). الخطوة 6: يتم إرسال الشيك ، مع استكمال بيانات المستخدم ، إلى الخادم للمعالجة. يقوم الخادم بمعالجة بيانات الفحص وإنشاء إشعار دفع للتطبيق في الخطوة السابعة. في الخطوة الثامنة ، يظهر الإخطار للمستخدم.
المشكلة هي أن الخطوات 3 و 4 و 5 يتم تنفيذها على جانب مزود الدفع ، ولا يتم التحكم فيها من الناحية العملية ، ويمكن أن يكون لها أشكال مختلفة. وبالتالي ، لا تحتوي العملية فعليًا على هيكل خطي ، كما هو موضح في الشكل 2 ، ولكن له بنية متفرعة (انظر الشكل 4) ، ويجب التعامل مع كل فرع بطريقة مختلفة بواسطة التطبيق.
الشكل 4. المتفرعة مخطط حالة الدفع لمرة واحدةيبدأ شراء الاشتراكات بنفس طريقة الدفع لمرة واحدة ، لكن التحكم في العملية أمر صعب للغاية.
الشكل 5. حالات الاشتراك المدارة خارجيًااسمحوا لي أن أذكركم بأن اشتراك Apple ، الذي نعتبره مثالًا ، يتم إدارته خارجيًا. هذا يعني أن المستخدم بعد الشراء يمكنه إدارته بشكل غير متزامن: إغلاق ، تغيير تاريخ انتهاء الصلاحية ، طلب استرداد. نرى هذا في الخطوة 9. بما أن الإجراء يحدث خارج نظامنا ، في الشكل الذي قمت بتمييزه بخط منقط.
في الخطوة 10 ، يمكن لـ App Store تغيير حالة الاشتراك: التجديد ، الإغلاق ، إدخال فترة السماح في النافذة.
حتى نتمكن من معرفة الحالة التي يوجد بها الاشتراك ، هناك الخطوة 11 ، التي تخص المُجمعين مثل App Store و Google Wallet. في هذه الخطوة ، يرسل النظام رمزًا ، يتم استخدامه كإيصال تم استلامه في البداية عند شراء اشتراك أو بعد تجديده السابق.
الخطوة 12 هي استجابة الموفر. نتلقى الشيك مع الوضع الحالي للاشتراك. تعتمد النتيجة في هذه الخطوة على الخطوتين 9 و 10 غير المتزامنين.
في خريف عام 2018 ، طبقت شركة Apple للجميع آلية
إشعارات الخادم إلى الخادم ، والتي تسمح لك
بالإبلاغ عن التغييرات التي حدثت مع الاشتراك. يظهر إيصال هذا الإخطار في الخطوة 13. بالنسبة لمعظم مقدمي الخدمات الآخرين ، فإن آلية الإخطار من الخادم إلى الخادم هي الوحيدة ، لذلك يمكن القول أن مثال Apple يغطي مجموعة كاملة من الحالات. في حالة الموفرين الآخرين ، تتيح لك الخطوة 13 استبعاد الخطوتين 11 و 12 من المخطط.
في الخطوة 14 ، ينشئ الخادم استجابة للتطبيق لتغيير حالة الاشتراك.
وبالتالي ، حصلنا على رسم بياني كامل للدول التي يجب تمريرها من أجل التحقق من الخدمات المدفوعة.
الشكل 6. العملية الكاملة لتغيير حالات الدفع (باستخدام اشتراك مُدار من الخارج كمثال)الأجزاء التي لا نتحكم فيها في نظامنا ملونة باللون البرتقالي ، وهي صناديق سوداء بالنسبة لنا.
طرق اختبار الفوترة
لذا ، فإن المشكلة التقنية الرئيسية عند اختبار الخدمات المدفوعة هي وجود "الصناديق السوداء" ، التي لدينا سيطرة قليلة للغاية عليها. هذا يحدد مجموعة من الطرق التي يمكن أن تغطي مجموعة كاملة من الحالات.
لا يوجد الكثير من هذه الطرق ، وقسمناها إلى ثلاث فئات: المدفوعات الحقيقية ، وصناديق الرمل ، والقضاء على التبعيات الخارجية من "الصناديق السوداء".
المدفوعات الحقيقية
المدفوعات الحقيقية كطريقة اختبار جيدة من حيث أنها تعطي فكرة واضحة عن حالة التكامل. خطأ في إجراء الدفع الحقيقي هو دليل غير مشروط على وجود خطأ.
خلاف ذلك ، المدفوعات الحقيقية سيئة. أولاً ، إنه مكلف: فمن الواضح أنه من أجل القيام بالدفع الحقيقي ، تحتاج إلى إنفاق أموال حقيقية. أنت مخطئ إذا كنت تعتقد أنه في النهاية سيتم إرجاع المبلغ بالكامل إلى الشركة: أولاً ، يفرض مقدمو الخدمات رسومًا على كل معاملة ، يعتمد حجمها ، كما هو موضح أعلاه ، على تصنيف المخاطر في المنظمة ويمكن أن يصل إلى 40٪ (وأكثر من ذلك) . ثانياً ، قد تخسر المال عند اختبار الدفعات في بلدان أخرى بسبب فارق العملة - الفرق بين سعر الشراء والبيع للعملة (ستقوم بالشراء بسعر بيع البنك للعملة الأجنبية ، وستأتي العائد بسعر الشراء).
بالإضافة إلى ذلك ، قد تستغرق هذه الطريقة وقتًا طويلاً ، لأنه يجب عليك الانتظار حتى نهاية فترة تجديد الاشتراك ، واستكمال فترات السماح ، وقد تكون هذه أشهر.
رمل
رمل جميلة. هذه ، في الواقع ، هي نفس الوظيفة التي يوفرها لنا مزود الدفع في حالة الدفع الحقيقي ، ولكن دون إنفاق أموال حقيقية. يتم دعمه بالكامل من قبل الموفر ، مما يعني أن التكامل مع الصندوق الرمل رخيص.
يتم حل مشكلة طول الاختبار مع مرور الوقت ، كقاعدة عامة ، باستخدام الحيل المختلفة. على سبيل المثال ، يستخدم رمل متجر التطبيقات تحويل انتهاء صلاحية الاشتراك التالي.
جدول 1. نسبة فترة الصلاحية للاشتراك الحقيقي والاشتراك في صندوق الحماية الخاص بـ Appleيتم سرد اشتراكات صندوق حماية Google الافتراضية في الجدول 2 ويمكن تهيئتها في وحدة تحكم البائع.
جدول 2. تحديد مدة الاشتراك في رمل جوجلبخلاف صندوق الحماية الخاص بـ Apple ، يمكنك أيضًا التحقق من النسخة التجريبية وفترة السماح وما إلى ذلك ، في صندوق حماية Google ، باستخدام النسبة المئوية من الجدول 3.
جدول 3. صلاحية ميزات الاشتراك الإضافية في صندوق حماية Googleيمكن أيضًا تنفيذ إغلاق الاشتراك بطرق مختلفة: في صندوق الحماية في متجر التطبيقات ، يتم الإغلاق بعد التجديد الخامس ، ويتم في محفظة Google من وحدة تحكم البائع أو على الجهاز من متجر Play.
المشكلة في صناديق الحماية هي أن مقدمي الخدمات لديهم موقف مختلف تجاه جودتهم. تُظهر تجربتنا أنه من بين أكثر من 70 مزوّد دفع مدمجين في Badoo ، هناك صندوقان للرمل فقط يتمتعان بالوظائف الكاملة والتشغيل المستقر. هذه هي الصناديق الرملية لأدين وباي بال. يتمتع الموفرون الآخرون إما بالثبات ، ولكن يتم اقتطاعهم من حيث صناديق الحماية الوظيفية (مثل محفظة Google) ، أو غير المستقرة والمقتطعة بشكل كبير في الوظائف (مثل App Store و Fortumo). وهناك مقدمو خدمات ليس لديهم صندوق رمل على الإطلاق ولن يملكوه.
الشكل 7. تصنيف صناديق الرمل حسب الاستقرار والأداء الوظيفيإزالة التبعيات الخارجية
إذا كنا مقتنعين بأن اختبار استخدام المدفوعات الحقيقية باهظ التكلفة وغير فعال ، وأن مزودي الدفع لا يوفرون صناديق رمل ذات جودة مناسبة ، فلا يزال يتعين علينا اللجوء إلى طرق مختلفة للقضاء على التبعيات الخارجية. هناك ثلاثة منهم فقط: موكي ، مزيفة وكعوب.
Moki في الفوترة هو تشكيل ردود أفعال النظام الخاص بك على الطلبات ذات المعلمات المحددة مسبقًا دون استدعاء حقيقي لمزود الدفع (انظر الشكل 8). على سبيل المثال ، يتم اعتراض طلب مقدم خدمة إرسال رسائل نصية قصيرة إلى الرقم + 7111-111-11-11 في مرحلة إرسال طلب إلى المزود ويولد استجابة للنظام في شكل عملية دفع ناجحة. تم اعتراض الطلب على الرقم + 7111-111-11-12 أيضًا ، لكنه يؤدي إلى رد فعل على خطأ في الكود "لا يوجد ما يكفي من المال لإكمال الصفقة."
الشكل 8. مخطط وهميةمزيفة في الفواتير هي مزيفة من الإخطارات (كما لو أنها تأتي من مزود حقيقي) (انظر الشكل 9). يتضمن التكامل مع كل موفر مجموعة محدودة من ردود أفعال النظام على مجموعة محدودة من أنواع الإخطارات أو إعادة التعيين. ( ), .
9.— (. . 10), .
10., , . (, , ) . , , , , .
. 3, 4, 5 : , . - : , — , — . « ».
11. ( App Store), (, ). — , . . , , , . , . , .
. , ? :
- — ?
- end-to-end — : - ?
- — : , .
.
4.. . . , . : , .
. , , Apple Google, . ( ). end-to-end : . , , .
, , — . . . : .
, , .
, . .
: . , , — .
, : — , , ; — : .
12., , , ,
.
, 12, Badoo.
. . QA- . , . , - , , . , .
: .
, , — . , Apple . . , . : - .
— , . -, . -, , -, , .
— : , Apple . 1 — , .
. , . , - .
, ( ).
النتائج
- , .
- ( ) . , .
- « » , . - — . , : , — , — .
- عند استخدام المنتجات المقلدة والعصرية والكعب ، من المهم أن تتذكر أن هذه نماذج دفع حقيقية ، ومثلها مثل أي نموذج ، فإنها تتمتع بدرجة تقريبية من الواقع والمخاطر. يجب تقييم هذه المخاطر وتغطيتها إما عن طريق المدفوعات الفعلية أو عن طريق شيكات إضافية.
حول كيفية تمكننا من تحقيق أتمتة مستقرة وغير مكلفة لاختبار الخدمات المدفوعة في تطبيق iOS ، نتحدث في المقال التالي .شكرا لاهتمامكم! جميع الأرباح الكبيرة وعدد أقل من الأخطاء!