Datums die het testen waard zijn
Software gaat niet stuk op gewone dinsdagen. Ze gaat stuk op de laatste dag van het kwartaal, op 29 februari, op het moment dat een jaar omslaat, en een seconde nadat een licentie is verlopen. Dit zijn de datums die die bugs vinden - 14 ervan worden meegeleverd als benoemde scenario's.
Periodegrenzen
Alles wat een periode afsluit, een document per jaar nummert of oploopt tot een stopdatum, maakt hier als eerste fouten.
- Laatste dag van de maand - gedragen maandafsluiting en periodetoerekening zich goed op de laatste dag van de maand?
- Laatste dag van het kwartaal - gedragen kwartaalafsluiting en rapportage zich goed op de laatste dag van het kwartaal?
- Laatste dag van het boekjaar - sluit de app het boekjaar op de juiste dag af, de dag voordat het nieuwe boekjaar begint?
- Jaarwisseling, live - verwerken documentnummering, jaar in de naam en jaarrapportage de omslag terwijl die gebeurt, in plaats van achteraf opnieuw te worden gestart?
De laatste is degene die mensen meestal helemaal niet kunnen testen, omdat de klok dan om middernacht van 31 december moet passeren terwijl de applicatie draait. Met een versnelde klok is dat een klus van tien seconden.
Kalender- en weergavegrenzen
- 29 februari - de schrikkeldag die maar eens in de vier jaar bestaat en die verrassend veel validatiecode botweg afwijst.
- Unix-epoch nul - behandelt de app 1 januari 1970 als een echte datum, of als een lege waarde die ze nooit had mogen opslaan?
- De grens van 2038 - het moment waarop een 32-bits
time_tmet teken opraakt, op2038-01-19T03:14:07Z. Een seconde later loopt de teller over naar 1901.
Licenties, proefperiodes en installatie
Deze zijn bedoeld om je eigen licentiebeheer te testen, het geval waarvoor ze geschreven zijn.
- Laatste dag van de proefperiode - werkt de app nog op het allerlaatste moment van de proefperiode?
- Eerste dag na het verlopen van de proefperiode - weigert ze de toegang op het moment dat de proefperiode eindigt, en hoe? Met een verstandige melding of met een stacktrace?
- Licentie een jaar geleden verlopen - gaat ze om met een licentie die lang geleden verliep, niet alleen gisteren?
- Datum vóór installatie - gedraagt ze zich als de klok vóór haar eigen installatiedatum is gezet? Deze leest de bestandsdatum van het doel zelf, dus heeft geen parameter nodig.
Bedrijfsregels en klokgedrag
- Betaling verschuldigd, +N werkdagen - valt een betaling die over N werkdagen verschuldigd is op de juiste dag, met overslaan van weekenden en de feestdagen van het juiste land? Het enige scenario dat een kalender nodig heeft, en het antwoord verschilt per markt.
- Grens van de meerderjarigheid - laat de app iemand precies op de grens toe en weigert ze iemand die een dag tekortkomt?
- Klokafwijking, +90 s - redt de app het als haar klok negentig seconden voorloopt op de echte tijd? Dit is het geval dat tijdgebaseerde eenmalige wachtwoorden en tokenvalidatie breekt.
Er een gebruiken
Een scenario is een benoemde datumexpressie. De calculator rekent uit wat ze betekent, en de vervanging draait een applicatie erop - dezelfde naam op beide plekken.
# Welke datum is het, en wat test die datum? chrono calc --preset month-end # Een applicatie erop draaien chrono run "C:\apps\test.exe" --preset year-rollover --report session.txt # De proefscenario's nemen de startdatum uit de bestandsdatum van het doel zelf chrono run "C:\apps\test.exe" --preset trial-first-day-after
In het venster zijn het chips boven het datumveld - een klik vult het in. Elk draagt zijn eigen zin die zegt wat het opspoort, het onderdeel dat een online datumcalculator je niet kan geven.
Wat hier niet staat
De zomertijdovergangen. Een applicatie door de grens van de overgang naar of van zomertijd sturen is een werkelijk nuttige test en ontbreekt bewust, omdat de sessietijdzone een vaste offset zonder zomertijd is - er is nog geen overgang om te simuleren. Een scenario meeleveren dat stilzwijgend niets deed, zou erger zijn dan het niet meeleveren.
Het komt terug met een model van de tijdzoneregels. Wat de tijdzone wel en niet doet →