Tijdens de voorbereiding van een kennissessie georganiseerd door AMIS kwam een collega met een interessante praktijk case.
Doel van de functie is het omzetten van radialen naar graden. Om de werking van de functie te testen voerde hij een reeks waarden in, lopende van 0 t/m 10. Vervolgens voerde hij de reeks van -10 t/m 0 in. Het resultaat was dat beide reeksen correct werden omgezet, zonder foutmeldingen. De functie lijkt dus correct geprogrammeerd te zijn. Zonder enige aanleiding voerde hij nog een reeks getallen in, namelijk 20 t/m 50 en tot zijn verbazing gaf de functie een foutmelding,
Oracle: ORA-06502: PL/SQL: numeric or value error: number precision too large.
Ik was in deze case geïnteresseerd geraakt omdat ik als tester benieuwd was of deze fout ook door één van de testtechnieken – equivalentieklasse of grenswaarde analyse – geconstateerd zou worden.
Mijn collega had de oorzaak van de fout gevonden. In de functie had de ontwikkelaar het formaat aangegeven van de resultaat variabele namelijk “graden number(5,2)” (totaal aantal karakters is 5 en 2 karakters achter komma/decimaalteken).
Tot en met de invoerwaarde van radialen van 17 gaat het goed, het resultaat is namelijk <1000 (=974,02825). Echter wanneer de invoerwaarde van de radialen >17 is gaat het fout. Het resultaat (in graden) wordt dan namelijk: 1145,91.
Mijn collega paste de functie zodanig aan dat de foutmelding niet meer optreed. Op zich geen verkeerde actie. Maar tijdens het bespreken van de case op de kennissessie bleken er toch andere invalshoeken te zijn.
Gezien vanuit het testen gaf ik aan dat als ik de equivalentie klassen techniek had toegepast ik deze fout niet ontdekt zou hebben.
Waarom niet? De equivalentieklassen kent de begrippen ‘geldige klasse’ en ‘ongeldige klasse’, respectievelijk waarde die wel aan de conditie voldoet en waarde die niet aan de conditie voldoet. Verder wordt is het uitgangspunt dat een waarde uit een klasse representatief is voor alle waarden in die klasse. Aangezien er geen randvoorwaarden/eisen bekend zijn gelden naar mijn mening alle waarden (positief en negatief). Feitelijk bestaat er dus geen ‘ongeldige klasse’.
Dus volgens dit uitgangspunt voldoet elk willekeurige waarde hieraan. Invoeren van andere waarden zou dus in principe niet nodig zijn.
Programmafout? Dat is dus eigenlijk de vraag. Het formaat van de functie is “number(5,2)”. Op zich is hier niets mis mee. Is dit dan een programmafout?
Specificatiefout? Of de conversie functie foutief is geprogrammeerd of dat de fout d.m.v. testen naar boven gekomen zal zijn hangt natuurlijk af wat gespecificeerd is. En daar ligt mijnsinziens de oorzaak van het probleem.
Omdat er niets is gespecificeerd is dus onbekend wat de grenswaarden van de output (in graden) zijn, bijvoorbeeld:
Sit 1: 1 maal de cirkel rond (positief) vanaf 0 graden t/m 360 graden
Sit 2: 2 maal de cirkel rond (1 x positief: 0 graden t/m 360 graden en 1 x negatief: -360 graden t/m 0 graden)
Sit3: N maal rond zowel negatief als positief (N x positief: 0 graden t/m Nx360 graden en N x negatief: -N x 360 graden t/m 0 graden)
(Invoerwaarden in radialen en de uitvoerwaarden in graden)
Sit 1: uitvoerwaarden reeks: 0,00 <= X <= 360,00
Ongeldig bij X = -5 (X <0) en bij X = 400 (> 360) (invoerwaarde in radialen: 0,0872 en 6,981)
Geldig bij X = 50 (invoerwaarde: 0,872)
Sit 2: uitvoerwaarden reeks: -360,00 <= X <= 360,00
Ongeldig bij X =-400 (<-360) en bij X = 400 (> 360) (invoerwaarde in radialen: +6,981 en -6,981)
Geldig bij: X = -50 (invoerwaarde: 0,872)
In beide situaties blijft de uitvoerwaarde (in graden) binnen het formaat van “number(5,2)”
Sit 3: uitvoerwaarden reeks: (N *-360,00) <= X <= (N * 360,00)
Zoals eerder is gesteld zijn alle invoerwaarden geldig dus ongeacht het aantal malen dat het startpunt wordt gepasseerd.
Als we uitgaan dat het aantal keren de cirkel rond een geheel getal is dan gaat het goed tot N = 2. Bij N= 3 wordt een foutmelding gegenereerd. De uitvoerwaarde bij N=3 is 1079,45 en voldoet dus niet aan het formaat “number(5,2)”. (feitelijk is het omslagpunt bij de waarde N=2,77)
Resumerend.
Door het ontbreken van specificaties kan dus niet bepaald worden of de functie foutief is ontwikkeld of dat deze onjuist is aangepast. Dit betekent tevens ook in feite dat deze functie ook niet getest kan worden.
De aanpassing van de functie heeft er toe geleid dat er geen foutmelding meer getoond wordt, maar of deze correctie geen vervolgeffecten heeft, is nog maar de vraag.
Het is namelijk denkbaar dat de uitvoerwaarde in graden in een andere functie gebruikt wordt. Als daar uitgegaan wordt van het formaat “number(5,2)” dan treedt in functie weer dezelfde fout op.
De functie is aangepast zonder te weten wat de specificaties / eisen zijn waaraan de functie moet voldoen. Als tester ben ik dit vaker tegengekomen, dat als specificaties ontbreken of onvolledig zijn de ontwikkelaar zelf een oplossingsrichting kiest. Dit hoeft overigens niet -altijd – verkeerd te zijn. Omdat de oplossing (veelal) niet wordt gedocumenteerd en goedgekeurd, zal dit mogelijk tot discussie leiden tijdens de testfase.
