| Summary: | Före lansering av ny mjukvara så är det vitkigt att veta mjukvarans begränsningar innan användarna gör det. Det kan vara både en tidskrävande och svår uppgift. En erfaren testare kan luta sig tillbaka på erfarenhet som pekpinne vart man kan börja titta på den stora mängden data från ett lasttest och avgöra dess begränsningar. Den här studien föreslår ett program som förenklar proceduren genom att upptäcka flaskhalsar med hjälp av schematiska regeldefinitioner som gör det möjligt att anpassa detektionsbeteendet utefter domänen. Kombinerat med välkända algoritmer från signalbehandling som lägger märke till f örändringar i alla typer av rå data kan f öreslå vilken typ av begränsning som finns i systemet. Pålitligheten av programmet testas med hjälp av fyra olika experiment som använder rå data som innehåller flaskhalsar för CPU, minne eller nätverk eller inget. Resultaten föreslår att programmets pålitlighet motiverar fortsatta studier eftersom den gissar rätt väldigt ofta vilken typ av begränsning som finns i systemet när något sådant är på plats. Dock är resultaten f ör det fjärde experimentet när ingen flaskhals finns i systemet riktigt dåliga vilket f öreslår att ett annat sätt att upptäcka avsaknaden av begränsningar behövs. Experimentet visar att metoden kan användas f ör att bygga tillägg eller funktioner som assisterar oerfarna lasttestare f ör väldigt simpla begränsningar. === Before launching new software it is imperative to know the limits of the application before the users do. It can be both a timeconsuming and a difficult task. A seasoned performance tester may rely on experience to know where to start looking at great amounts of data from performance tests to detect its limits. This study implements and tests the reliability of an application by applying a model to simplify the procedure of detecting bottlenecks with the help of a schema defining metric connections specific to a target application domain. Combined with well known signalprocessing algorithms for detecting changes in any raw data can suggest what type of bottleneck is present in a system. The reliability of the application is assessed by four types of experiments carried out to detect the bottleneck from raw data containing bottlenecks of the types CPU, memory or networ or nothing. The results suggests that the applications reliability motivates further study since it presents a very strong ratio of correct guesses when a bottleneck is present within a system. However, the results for the fourth experiment where no bottleneck is present in a system are very bad, suggesting a different model for detecting no bottlenecks is needed. The experiment shows that the method suggested can be used to build add-ons or features that may assist inexperienced performance testers for very simple bottlenecks.
|
|---|
