windows - vigtigste testmiljø - skal det være det fælles operativsystem eller det fremtidige operativsystem?

Indlæg af Hanne Mølgaard Plasc

Problem



Mit firma er ved at købe et automatiseret testværktøj. Vi er ikke et stort firma og kan kun råd til en enkelt licens til værktøjet. Vi har en intern tvist om, hvorvidt det testede OS skal være det mest almindeligt anvendte af vores klienter (XP) eller den næste generation af OS (Windows 7). Alle mulige OS vil blive testet alligevel, men i en meget mindre skala.


Den meste af vores udvikling er færdig med PowerBuilder, og alle dev maskiner kører XP. Derfor bruger vi ikke nogen ny funktion, der tilbydes af Vista eller 7. Dette betyder, at hvis vores software kører på 7, burde det ikke have noget problem at køre på XP. Den anden vej er en anden historie, og derfor skal testes ordentligt. OTOH, er det fornuftigt, at de vigtigste testmiljøer er det primære produktionsmiljø.


I betragtning af sådanne begrænsede ressourcer, hvilken OS vil du fokusere dine test på?

Bedste reference


Absolut det vigtigste miljø.


Hvorfor spilde tidstest på Windows 7, hvis din primære brugerbase er XP. Ja, når du har testet på XP, skal du helt sikkert prøve på vista &7 også, men hvis du kun har ressourcerne til at automatisere testen på en, skal du fokusere på den primære platform.

Andre referencer 1


Du bør ikke antage det, fordi din app kører fint på Windows 7, at den kører på XP. Der er et uendeligt antal ændringer, der potentielt bryder mellem de to OS versioner. Ideelt set bør du teste på alle operativsystemer, du understøtter, dette er måske ikke muligt, men det vigtigste er at sikre, at det virker på dit hovedmål.

Andre referencer 2


Test, hvad du støtter. derefter test, hvad du skal støtte i den nærmeste fremtid, og sidst, lad udviklere teste 'skære' kant/beta/rtm/alpha OS.


For eksempel, hvis du understøtter XP, så er det det primære operativsystem til test, hvis det gøres korrekt, ressourcerne til at teste, at operativsystemet skal være minimal, hvis din næste udgave understøtter Vista, så bring Vista i testsløjfen og lav det er en prioritet.


Hvis du har brug for Windows 7 til at blive understøttet, så lad udviklerne først køre på den, alligevel kan det nok have brug for noget 'kodning' og vil muligvis bryde automatiseret testning. når det kommer til et acceptabelt niveau af kvalitet, bring det til testsløjfen.

Andre referencer 3


Tid til at støde af den gamle 'PowerBuilder 1 og Windows beta' -historien. Husk: Jeg var ikke her, det er mundtlig historie, og jeg er gammel nok til at min hukommelse begynder at pynte mine egne historier, endsige en andens.


Powersoft fik denne store marketing score. De samarbejdede med Microsoft for at frigive deres nye produkt, PowerBuilder, samme dag som den nye version af Windows (3.0). Microsoft forsøgte at bevise, at denne platform, de byggede, var egnet til brugerdefinerede line-of-business-applikationer, ikke kun grafiske programmer og minesveger. Så, Powersoft fik den sidste udgivelseskandidat fra Microsoft, og de slog ordentligt på PowerBuilder. De var tilfredse. På startdagen gik forretningsmændene ud af computerforretningen med en kopi af Windows under den ene arm og PowerBuilder under den anden. Så begyndte opkaldene at komme ind. PowerBuilder blev alvorligt brudt, og det var smerteligt indlysende. Microsoft havde ændret noget (formodentlig med det formål at fastsætte en fejl) mellem frigivelseskandidaten og den generelle tilgængelighedsversion, der bragte PowerBuilder på knæ. Powersoft reagerede hurtigt med en løsning, men der var mange røde ansigter i mange dage efter.


Historiens moral: Testning mod beta betyder stort set ingenting. Medmindre du laver planer efter 22. oktober, bør du ikke planlægge at gøre noget mere end overfladiske tests på Windows 7, fordi du skal gøre testen alle igen, når < em> ægte Windows 7-skibe.


Held og lykke,


Terry.

Andre referencer 4


Windows udgivelser er ofte ustabile indtil de første par service packs. At hoppe på nu betyder, at du ikke tester din software, men du tester også på et uprøvet system. Hvis der er en fejl, hvordan vil du vide, om det er dit program eller det nye OS?


Dine kunder vil være på XP i nogen tid fremover (takket være Vista, det er stadig populært). Gå med det, du ved.


Desuden besparer du sandsynligvis 1-2 gigre RAM, der kunne bruges bedre til din kompilator og værktøjer end på vindues slik og den sædvanlige opblomstring.

Andre referencer 5


Med fare for at lyde glib, test begge. Bære over med mig.


Start med at have en automatiseret byggeproces, der kan gøre en ren bygning af din software fra kildekontrol (du har kildekontrol, ikke?). Tilføj automatiserede tests. Dette omfatter alt fra lavt niveau enhedsforsøg til integrationstest til uovervåget funktionstest ved hjælp af noget som TestComplete eller SmarteScript. Nu, da du nu kan teste hele din vare (eller i det mindste vigtige stykker) uden nogen menneskelig interaktion, kan du køre disse tests så ofte som du vil. [1] [2]


Opret en ren virtuel maskine til at repræsentere en typisk klient-pc. Din udviklingskasse er nok ikke et godt eksempel på dette. Som en del af din automatiserede byggeproces kan du scribe den virtuelle maskine (i hvert fald VMWare og VPC) for at starte fra et kendt godt øjebliksbillede, installere den nyeste build af din software, Kør dine automatiserede tests og offentliggør resultaterne.


Det var den hårde del. Nu skal du bare oprette en ny virtuel maskine med enhver kombination af operativsystemer/service packs/memory/etc og gentage de automatiserede tests på hver af dem.


Det lyder som om du tilføjer en forfærdelig masse proces. Hvad du faktisk gør er at tage alle de ting, der kan (og derfor bør) blive automatiseret af dine hænder, hvilket giver dig mere tid til mere interessant (hvordan man sælger det til dig selv) og rentabelt (hvordan man sælger det til din chef) ting.


Ellers kan du bare teste mod OS, de fleste af dine kunder bruger og medtage en ansvarsfraskrivelse.