التواريخ الجديرة بالاختبار

لا تتعطل البرمجيات في أيام الثلاثاء العادية. إنما تتعطل في آخر يوم من الربع، وفي 29 فبراير، وفي اللحظة التي تنقلب فيها السنة، وبعد ثانية واحدة من انتهاء الترخيص. هذه هي التواريخ التي تكشف تلك الأعطال - ويأتي 14 منها ضمن سيناريوهات مسمّاة.

حدود الفترات

كل ما يُقفل فترة، أو يرقّم مستندًا بالسنة، أو يستحق حتى موعد قطع، يخطئ في هذه أولًا.

آخر يوم في الشهر - هل يسلك إقفال نهاية الشهر واستحقاق الفترة سلوكًا صحيحًا في آخر أيام الشهر؟
آخر يوم في الربع - هل يسلك إقفال نهاية الربع وإعداد التقارير سلوكًا صحيحًا في آخر يوم من الربع؟
آخر يوم في السنة المالية - هل يُقفل التطبيق السنة المالية في اليوم الصحيح، أي اليوم السابق لبدء السنة المالية؟
انقلاب السنة، مباشرةً - هل يتعامل ترقيم المستندات والسنة في الاسم والتقارير السنوية مع الانقلاب وهو يحدث، بدل أن يُعاد تشغيلها بعده؟

والأخير هو ما لا يستطيع الناس اختباره عادةً، لأنه يتطلب أن تعبر الساعة منتصف ليل 31 ديسمبر والتطبيق قيد التشغيل. وهذا عمل عشر ثوانٍ مع ساعة مُسرَّعة.

حواف التقويم والتمثيل

29 فبراير - اليوم الكبيس الذي يوجد مرة كل أربع سنوات فقط، والذي يرفضه عدد مدهش من شيفرات التحقق رفضًا تامًا.
الصفر في حقبة Unix - هل يعامل التطبيق 1 يناير 1970 تاريخًا حقيقيًا، أم قيمة فارغة كان ينبغي أن يرفض تخزينها؟
حدّ 2038 - اللحظة التي ينفد فيها time_t المُوقَّع بطول 32 بت، عند 2038-01-19T03:14:07Z. وبعد ثانية واحدة يفيض العدّاد إلى عام 1901.

التراخيص والفترات التجريبية والتثبيت

هذه لاختبار ترخيصك أنت، وهي الحالة التي كُتبت من أجلها.

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

قواعد العمل وسلوك الساعة

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

كيف تستخدم واحدًا منها

السيناريو تعبير تاريخ مسمّى. تحسب الحاسبة معناه، ويشغّل الاستبدال تطبيقًا عنده - بالاسم نفسه في الموضعين.

# أي تاريخ هذا، وماذا يختبر ذلك التاريخ؟
chrono calc --preset month-end

# شغّل تطبيقًا عنده
chrono run "C:\apps\test.exe" --preset year-rollover --report session.txt

# سيناريوهات التجربة تأخذ تاريخ البدء من تاريخ ملف الهدف نفسه
chrono run "C:\apps\test.exe" --preset trial-first-day-after

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

شاشة الإعداد في Chrono Mock وقسم Scenarios مفتوح: حقل بحث فوق القائمة، ثم كل تاريخ جاهز مع السؤال الذي يجيب عنه - حدّ 2038، و29 فبراير، وساعة تسبق بتسعين ثانية، وآخر يوم في الشهر - وتحت القائمة سطر يقول إن ثلاثة أخرى تحتاج إلى قيمة تختارها. ويقرأ التذييل اللحظة بلغة عادية فوق زر Start. — يحمل كل سيناريو السؤال الذي يجيب عنه لا تاريخًا فحسب. أما الثلاثة التي تحتاج إلى قيمة تختارها فتُسمّى تحت القائمة ولا تُخفى.

ما ليس موجودًا هنا

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

وسيعود مع نموذج لقواعد المناطق الزمنية. ما تفعله المنطقة الزمنية وما لا تفعله ←

جرّبه

نزّل نسخة Windows الحاسبة