Bliv gratis medlem
|
Dette er især til diverse udviklere af webløsninger. Mit spørgsmål går på om i bruger automatiseret test af jeres løsninger? Hvis i gør: Hvilket værktøj bruger i så? Er der andre værktøjer? Hvad er jeres erfaringer med de forskellige værktøjer? Hvis ikke i gør: Hvorfor ikke? er det forbi i gider bruge det? Er det evt. for besværligt eller kan det bare ikke betale sig? Håber på en god diskussion omkring emnet... - Visti |
Automatiseret test af webløsninger....
|
Men ellers adskiller website projekter sig jo ikke fra andre software udviklingsprojekter, så det er bare med at komme igang med testprogrammering, hvis projektet er stort nok. Jeg laver p.t. ikke webprogrammering, men jeg har tidligere lavet automatiseret test af webløsninger, og det foregik ved at et GUI program fjernstyrede websitet, så vi brugte et testværktøj, der var specifikt til GUI udviklingsmiljøet. Der findes sikkert mange bedre værktøjer til formålet nutildags. |
|
Tak for dit svar... Jeg arbejder for en stor dansk portal, hvos vi er begyndt at automatisere vores test arbejde... Vi bruger selv selenium(http://www.openqa.org/selenium), som er en FF extension. Det syntes vi(Test afd.) selv at det er der store fremtidsperspektiver i, men jeg ville da gerne høre hvordan andre bruge det, hvis de overhoved bruger det.. Håber at høre fra andre også... - Visti |
|
Jeg bruger NUnit og mock objects til test og NAnt til build, og når jeg kan komme til det, så kobler jeg den på min egen Continuous Integration system der rejecter alle ændringer som ikke overholder reglerne (skal kompilere, alle tests skal lykkedes, osv.). http://www.nunit.org/ http://nant.sourceforge.net/ http://sin.tigris.org/ |
|
Automatiseret test og Continuous Integration kan normalt godt betale sig. Lav tests til de vigtigste dele af dit system - de dele som bare koster kassen hvis de går i stykker en dag, og bliver sat i produktion. De kan dog ikke erstatte manuelle tests, men det er heller ikke meningen. Idéen i automatisede tests er at du kan refaktorere/ændre i din kode, og din test vil så ikke kompilere mere eller fejle hvis der er noget du har overset. Udvikleren bliver så nød til at tage stilling til om det er domæne koden (koden der testes) eller selve testen der skal ændres. Hvis der ingen test er, så kan udvikleren nemt overse en antagelse som en anden udvikler i sin tid har foretaget. En erfaren udvikler vil holde antagelser på et minimum, og når de foretages, så sørge for at koden fejler så snart antagelsen viser sig at være forkert, så forkerte tilstande ikke viser sig som fejl senere i programmet og kræver mere tid til debugging. |
|
|
Det holder jeg nu stadig på at det ikke er...i praksis i hvert fald...i teorien er alt jo næsten muligt. |
|
|
Det er fint, og også det vi skal stræbe efter, men mange virksomheder ville ikke have resourcerne til at få acceptabel dækning på det niveau. Skulle du dække et system fuldstændigt af automatiserede tests, så godt som strukturerede manuelle tests kan gøre det, så vil udviklingsomkostningerne være mange hundrede procent højere. |
Opret bruger