Hej, är ny som medlem här på forumet men har hängt här och läst ett bra tag, gillar sidan. Hursomhelst, skulle behöva lite tips&feedback från er som är mer erfarna då det kommer till RAT's.

Håller alltså på att utveckla en RAT för tillfället, den är väl i stort sett klar och har de vanliga funktionerna, förutom att den använder lite okonventionella metoder. Hursomhelst, vad jag undrar är hur pass länge man bör beta-testa en RAT (på ett ungefär då) innan man släpper ut den? För jag vet ju själv hur trist det är de gånger man sätter sin tillit på en RAT, lyckas smussla in den i ett antal datorer och sen börjar den bugga ihop efter ett tag.

Nu har jag kört den från och till i några dagar på ett antal datorer, med gott resultat (enbart nån liten bugg som smygit sig in). Hur länge bör man fortsätta tycker ni innan man släpper den publikt? (Nu har jag iof inte bestämt mig säkert om jag kommer göra det, men med största sannolikhet).

det bästa är nog att testa ganska länge.
gärna ha flera som testar åt dej .
oftast hittar man buggar när du inte letar om du förstår vad jag menar.

bästa sättet är att ha en extra dator på nätverket och instalera på den , då kan du samtidigt se vad som händer.
testa flera saker samtidigt.

Enligt min personliga uppfattning:
Mjukvara du släpper kommer avgöra hur andra ser på dig som en kodare, men kan även medföra långtgående konsekvenser för ett eventuellt branschrykte för framtiden. Det är fortfarande så att den absoluta eliten som skriver säkerhetsverktyg gör sig ett positivt namn, men att stå bakom en misslyckad dussinvara är att riska att brännmärka sig som en MISSLYCKAD skapare av skadlig kod. Alla gillar en mästertjuv, men ingen gillar en halvdan skurk om du förstår vad jag menar?

Hur som helst, generellt för mjukvara så OM du ska testa ordentligt, testa det strukturerat!

Börja med att fråga dig vad ditt program gör, på hög nivå.
Fundera sedan på vad som kan gå fel.
Fundera sedan på om det finns yttre omständigheter som kan störa funktionaliteten.

Börja konkretisera detta till "Så... om jag drar ur nätverkskabeln när jag för över en fil, vad händer då? Krashar programmet med ett felmeddelande som är lika tydligt som en röd blinkande lampa?" eller "Vad händer om jag försöker föra över en fil till en mapp så total stränglängd i absolut path överstiger 256 tecken?"

Du börjar på hög nivå.
Du dokumenterar frågan du skall besvara, beslutad indata (alltså det som "orsakar" situationen) samt FÖRVÄNTAT utfall (t.ex. filöverföringen dör, strömmen stängs utan varning på min sida, och klienten stänger filhandtaget utan att visa meddelanden. På min sida skrivs en logghändelse om vilken fil som hämtades, ip, tip, klientID eller dylikt som gör att jag kan felsöka).

Efter det genomför du dina test.
Ska din programvara klara FWB? Hur hanterar den då marknadens vanligaste firewalls? Ska den klara UAC i vista?
Funkar den på win2000, winXP SP1, winXP SP2, Server2003, 2003R2?


Sen tror jag inte du behöver testa allt det här, men du förstår principen?

Som rent exempel:
Amerikanerna skickade tusentals soldater till vietnam med M16. De hade testats perfekt på armeens testanstalter i USA, som ligger i torrt ökenlandskap.
Det visade sig dock när man hamnade i träsken att lera fick slutstycket att kärva, och man stod då med ett vapen som klickade. Det kostade många soldater livet, man tvingades modifiera för enorma belopp och soldaterna kände aldrig tilltro till sitt vapen ens efter att man monterat ditt ett manuellt hammar-handtag för att mata slutstycket med våld.

Alltså, testa för hur den ska användas i verkligheten, inte efter vad som råkar vara en enstaka bekväm testmiljö hemma hos dig, utan sätt upp vmware med ett antal olika operativ och förutsättningar för de viktigaste testfallen.



Och slutligen. "Smussla" inte in den på folks datorer, se forumets regler

//Mja

Som du säkert vet så finns det också så många olika kombinationer av hårdvara och mjukvara som kan börja krångla så ett par betatestare är nog att föredra. Om det är en första release som man vet kan vara ostabil så bör man informera om det och be om buggar rapporterade, säg att det är en beta så att ingen tror något annat.

Tror man skall satsa på att få sitt program helt stabilt och sedan lägga till funktioner i tur och ordning så att man kan testa dessa och sådant som kan ha förändrads när man lagt till dessa så att man inte behöver testa precis allting varje gång.

Tack för utförligt svar. Jo, det är väl lite vad du pratar om som jag är inne på, vill inte gärna släppa något buggigt, varken för användarnas skull eller för mitt eget "ryktes" skull. Vill ju inte heller att folk ska sätta tilltro till något och att det sedan helt ska gå åt helvete pga av någon onödig bugg, det vet man ju själv hur irriterande det är. Har ett par frivilliga beta-testare som ska ta del av RAT:en imorrn, och så kommer jag ju fortsätta göra testkörningar själv så man kan förhoppningsvis börja upptäcka buggar snart. Har några stycken datorer hemma, och vmware monterat som jag gör testkörningarna på. Ska också lägga lite extra tid på att som du säger gå igenom olika scenarion.

Ang forumets regler, allt jag påpekade var att RAT's ofta används på "fel" sätt

Tack även ni andra för era svar. Men till huvudfrågan då, om jag har ett antal beta-testare och vi säger att jag får ihop en riktigt stabil RAT som fungerar bra i flera veckor under beta-test, ungefär hur länge ska man fortsätta att beta-testa tills man kan känna sig någorlunda säker? Hur länge brukar ni andra beta-testa era produkter?

De viktigaste testerna för att verifiera produkten är de testprogram man själv skriver innan eller under utvecklingens gång, beta-testning är mer för att få feedback från användare. Tiden för detta beror på vad som behövs åtgärdas.

Exempel på ramverk för tester:
Säg att du har all din nätverkskod i filen net.c. Detta är din nätverksmodul. Du har gränssnittet fastställt i en separat headerfil, net.h. Vad du bör göra då är att ha en tredje fil, netTest.c där du har testfunktioner för nätverksmodulen som arbetar mot gränssnittet fastställt i net.h och ser så att funktionerna arbetar som de ska. Tänk på vad Mja skrev, testa inte bara för det som ska hända utan även för det som inte ska hända. netTest.c har en egen entry (main() motsv.) som du använder istället för applikationsentryn (som traditionellt sätt finns i main.c eller <projektnamn>.c). Om du har en nätverksfunktion som heter netConnect har du en testfunktion för densamma i netTest.c som du döper till testNetConnect (namngivning är en smaksak).

Tänk också på att vara noga vid skrivandet av testfall. Självklart ska man alltid vara noga när man kodar, men det är extra viktigt då man skriver sina testfall då man som regel inte har testfall för testfallen.