mboost-dp1
Microsoft Corporation
Og Microsoft får øjnene op for intern softwaretest?
Bedre sent end aldrig :(
Utroligt at så generelle biblioteker ikke er testet bedre...
Jeg ville måske forvente at et firma som M$ ville have en relativ stor interesse i at udgive troværdige biblioteker.
Gad nok vide hvor længe denne fejl har været tilstede...
Bedre sent end aldrig :(
Utroligt at så generelle biblioteker ikke er testet bedre...
Jeg ville måske forvente at et firma som M$ ville have en relativ stor interesse i at udgive troværdige biblioteker.
Gad nok vide hvor længe denne fejl har været tilstede...
Casperin (7) skrev:Jeg mener at de har kendt til den fejl i næsten et år nu; så det egentlige spørgsmål er hvorfor der først er sket noget nu.
Måske sku de først finde årsagen til fejlen først?
nu ved jeg ikke meget om kode, men vil da gætte på at ét enkelt malplaceret tegn godt kan være svær at spotte
mathiass (8) skrev:det bestemt ikke nødvendigvis en let fejl at finde. C++ er bestemt ikke lavet med fejlfinding for øje og især ikke når det handler om memoryfejl.
Sproget har ikke meget at sige ifbm. softwaretest. For det første skal du lave en lokal test, der sikre at alle små delelementer overfører sig som tiltænkt. Dernæst tester man de enkelte elementer i samspil med omliggende klumper. Dertil kommer automatiske tests der systematisk gennemgår alle tænkelige og nogen gange utænkelige scenarier for at finde andre typer fejl. Til sidst er der manuel test hvor der sidder en flok aber og taster løs, for at finde de fejl en maskine ikke er bygget til at finde.
Nå ja - og så har de også en mængde beta-testere og dernæst resten af verdens befolkning til at spotte evt. fejl.
Men nogen fejl kan selvfølgelig være sværere at finde end andre...
Det er et stort emne, og det er ikke noget nyt, at der er fejl i software. Det er dog (stadig) aldrig godt at finde fejl i vitale og centrale dele...
Sproget har ikke meget at sige ifbm. softwaretestDet har bestemt rigtig meget at sige i forhold til hvilke fejl man kan begå.
Jeg kan love dig at Microsoft gør alle de ting du nævner til overflod. Men test er per definition ukomplet. Det er bestemt altid godt at finde fejl i vitale og centrale dele! For så er de fjernet.
#19
-> operatoren bruges også i C.
Men derfor ligner det stadig i meget høj grad et metode kald på et objekt.
Syntaktisk kunne det godt være kald af en function pointer gemt i en struct.
Men hvis man vil kode objektorienteret så vil man nok vælge C++ hvor de features er indbygget fremfor at emulere klasser via structs med function pointers.
-> operatoren bruges også i C.
Men derfor ligner det stadig i meget høj grad et metode kald på et objekt.
Syntaktisk kunne det godt være kald af en function pointer gemt i en struct.
Men hvis man vil kode objektorienteret så vil man nok vælge C++ hvor de features er indbygget fremfor at emulere klasser via structs med function pointers.
masterzeb (6) skrev:Der findes ikke fejlfri kode - kun kode hvor fejlene ikke er opdaget endnu...
Undskyld mig, men enhver software udvikler, der vil give dig ret i det burde skifte karriere.
Det er da den sygeste fanboy undskyldning jeg længe har hørt.
http://99-bottles-of-beer.net/language-perl-737.ht... - Find fejlen.A-Vizion (13) skrev:Sproget har ikke meget at sige ifbm. softwaretest.
Sprog har meget med fejlfinding at gøre. Faktisk synes jeg at folk undervuderer hvor meget et godt sprog har at sige for antallet af fejl i koden.
#23
Sproget har masser med at finde årsagen til fejl efter at man har fået at vide af QA at der er en fejl.
Og C/C++ er to af de værste at finde visse typer fejl i. Mystiske memory overskrivninger som giver fejl et helt andet sted end hvor de oprindeligt skete.
Men QA er bedøvende ligeglade med om det er et C++ eller et Java program de tester.
Sproget har masser med at finde årsagen til fejl efter at man har fået at vide af QA at der er en fejl.
Og C/C++ er to af de værste at finde visse typer fejl i. Mystiske memory overskrivninger som giver fejl et helt andet sted end hvor de oprindeligt skete.
Men QA er bedøvende ligeglade med om det er et C++ eller et Java program de tester.
Sproget har en hel del at gøre med at spotte (taste)fejl - Du havde højst sandsynligt fået mindst en warning hvis du lavede samme nummer i C# eller Java.
Når det så er sagt, skal funktionelle tests fange den her type fejl. Problemet med funktionelle tests er bare at man kun tester den funktionalitet man kan forestille sig kan ske. I C/C++ (whatever) er der masser af pointers og memory-management over det hele. Det betyder at en fejl af den her størrelse ikke behøver gøre noget 99% af gangene, men give BSOD den sidste 1% - Meget som threading-fejl.
-- Og nej, 100% code-coverage behøver heller ikke fange den her fejl :)
Når det så er sagt, skal funktionelle tests fange den her type fejl. Problemet med funktionelle tests er bare at man kun tester den funktionalitet man kan forestille sig kan ske. I C/C++ (whatever) er der masser af pointers og memory-management over det hele. Det betyder at en fejl af den her størrelse ikke behøver gøre noget 99% af gangene, men give BSOD den sidste 1% - Meget som threading-fejl.
-- Og nej, 100% code-coverage behøver heller ikke fange den her fejl :)
Du havde højst sandsynligt fået mindst en warning hvis du lavede samme nummer i C# eller Java.Forskellen er at den slags fejl slet ikke kan lade sig gøre at lave i Java. Man kan for det første slet ikke pille ved pointere på den måde, og ellers ville programmet simpelthen ikke kompilere på sådan en typefejl.
Og nej, 100% code-coverage behøver heller ikke fange den her fejlFaktisk er 100% code-coverage på ingen måde en indikation på at man har fanget den her type.
Når det så er sagt, skal funktionelle tests fange den her type fejl.Jeg har aldrig været den store fan af at løse den her type relativt simple problemer med timevis af manuelt arbejde. Microsoft skriver også at de har tilføjet det til deres tools, så de kan finde (de fleste) tilsvarende fejl automatisk under kodningen en anden gang.
Nu er det efterhånden mange år siden jeg programmerede i C/C++, men jeg husker TYDELIGT, at man hurtigt kunne løbe sur i at skulle fejlfinde håndteringen af pointers. Skulle det nu være *p eller **p eller &p eller ???? ;-)
Selv i et simpelt højniveau sprog som X++ kan der opstå fejl - jeg præsterede i dag at lave 8 fejl på 4 linjer - men så tog jeg også hjem *GGGG*
Selv i et simpelt højniveau sprog som X++ kan der opstå fejl - jeg præsterede i dag at lave 8 fejl på 4 linjer - men så tog jeg også hjem *GGGG*
Den originale blog post af Michael Howard er noget mere interessant mht. hvorfor fejlen ikke er fanget mv. end nyhedskilden. Der står desuden at pointer fejlen kun er i en intern ATL udgave og ikke i de frigivende ATL version.
http://blogs.msdn.com/sdl/archive/2009/07/28/atl-m...
http://blogs.msdn.com/sdl/archive/2009/07/28/atl-m...
Wassini (27) skrev:Nu er det efterhånden mange år siden jeg programmerede i C/C++, men jeg husker TYDELIGT, at man hurtigt kunne løbe sur i at skulle fejlfinde håndteringen af pointers. Skulle det nu være *p eller **p eller &p eller ???? ;-)
Pascal har også pointere og den slags fejl sker meget sjældent i Pascal.
Problemet er ikke kun pointere men at C/C++ generelt antager at programmøren ved hvad han laver. En virkeligt rar egenskab, hvis man skal lave noget avanceret a la styresystems kerne. Men lidt optimistisk for den gennemsnitlige programmør.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund