Software for mobile devices is becoming increasingly popular. The limited resources and limited user interface brings new issues in software development process for mobile devices. These limitations should be considered especially in design and testing phases of software development process. The software for mobile devices can not be thoroughly tested, because unit tests can not be stored in mobile device due to the lack of storage on it. Testing results can not be easily observed on small screens of mobile devices. This work depictures the influence of mobile technologies to software development process. The influence is exemplified with a project “Mobile Professor”. This work concentrates on problems encountered in software testing process for mobile devices especially in unit testing. The work presents other authors suggested solutions for earlier mentioned problems, and also suggest the new approach for performing unit testing for mobile devices, which does not suffer for these limitations of mobile devices. Existing and suggested methods are compared and evaluated experimentally.

No description available.

Software verification is an important part of software development and themost practical way to do this today is through dynamic testing. This reportexplains concepts connected to verification and testing and also presents thetesting-framework Trassel developed during the writing of this report.Constructing domain specific languages and tools by using an existinglanguage as a starting ground can be a good strategy for solving certainproblems, this was tried with Trassel where the description-language forwriting test-cases was written as a DSL using Python as the host-language.

This work focuses on relative comparisons of individual method's performance. It is based on Stochastic Performance Logic, which allows to express, for example, that one method runs at most two times longer than another method. These results are more portable than absolute values. It extends standard unit tests with performance assumptions, which are evaluated during actual run-time of a released application. Dynamically added and removed instrumentation is used for automatic modification of the production code. Instrumentation part uses DiSL framework to be able to seamlessly measure even Java system classes. Methods are measured sequentially, the number of concurrently measured methods is dynamically changed and the measurement code is removed as soon as required data are obtained. The results show that this approach may bring appreciably lower overhead peaks than measuring all methods at once. The prototype was compared with JMH tool and the results show that it is able to accurately measure methods running longer than 1 ms. Powered by TCPDF (www.tcpdf.org)

Enhetstestning mot databaser inriktade mot geografiska informationssystem kan vara ett komplicerat arbete att utföra. Det innebär både att ha tillgång till användbart data samt att använda verktyg för att utföra dessa tester på. Denna studie har undersökt hur data bestående av ytor kan genereras och hur verktyg inriktade på enhetstestning mot databaser kan användas för att uppnå en förbättrad arbetsmetodik för enhetstestning mot databaser. Arbetet har resulterat i förslag på metoder som kan användas för att generera geografiska data. En applikation har utvecklats för att generera dessa data. Dessutom har en metod för att genomföra enhetstester mot en postgreSQL databas, baserad på verktyget pgTAP, presenterats. Föreslagna metoder kan möjliggöra en förbättring av arbetsmetodiken vid enhetstestning mot databasermen det finns fortfarande många förbättringar att utforska.

This paper studies how the newly released AI ChatGPT can be used to reduce the time and effort software developers spend on writing unit tests, more specifically if ChatGPT can generate quality unit tests. Another aspect of the study is how the prompting of ChatGPT can be optimized for generating unit tests, by creating a prompt framework. Lastly how the generated unit tests of ChatGPT compare to human written tests was tested. This was done by conducting an experiment where ChatGPT was prompted to generate unit tests for predefined code written in C# or Typescript which was then evaluated and rated. After the generated unit test had been rated, the next steps were determined, and the process was repeated. The results were logged following a diary study. The rating system was constructed with the help of previous research and interviews with software developers working in the industry which defined what a high-quality unit test should include. The interviews also helped in understanding ChatGPT’s perceived capabilities. The experiment showed that ChatGPT can generate unit tests that are of quality, though with certain issues. For example, reusing the same prompt multiple times revealed that the consistency in the responses was lacking. Inconsistencies included different testing approaches (how setup methods were used for example), testing areas and sometimes quality. The inconsistencies were reduced by using the deduced prompt framework, but the issue could be a current limitation of ChatGPT which could be handled with a future release.

<p>Att skriva enhetstester är en viktig del i nya populära systemutvecklingsmetoder som extreme programming. Med testdriven utveckling skriver man testerna innan den källkod som skall testas. Ett vanligt problem med dessa tester är att de blir beroende av delar i systemet som inte är intressant för själva testen. Mock objekt är en teknik som gör det enkelt att isolera tester från allt som inte är relaterat till det som skall testas.</p><p>Det finns två sätt att se på mock objekt. Den traditionella synen är att mock objekt skall användas som ett verktyg vid isolering av externa system. Den alternativa synen är att mock objekt är ett designverktyg som kan driva fram en bättre design i systemet. I denna uppsats utvärderas ett antal mock objekt bibliotek ur detta nyare perspektiv. Resultatet visar att det finns åtskilliga skillnader mellan biblioteken.</p>

Att skriva enhetstester är en viktig del i nya populära systemutvecklingsmetoder som extreme programming. Med testdriven utveckling skriver man testerna innan den källkod som skall testas. Ett vanligt problem med dessa tester är att de blir beroende av delar i systemet som inte är intressant för själva testen. Mock objekt är en teknik som gör det enkelt att isolera tester från allt som inte är relaterat till det som skall testas. Det finns två sätt att se på mock objekt. Den traditionella synen är att mock objekt skall användas som ett verktyg vid isolering av externa system. Den alternativa synen är att mock objekt är ett designverktyg som kan driva fram en bättre design i systemet. I denna uppsats utvärderas ett antal mock objekt bibliotek ur detta nyare perspektiv. Resultatet visar att det finns åtskilliga skillnader mellan biblioteken.

Capsules are modeling language elements which are sometimes used to develop real-time software. One way to test such capsule elements without relying on dependencies to other units is to use mock objects. The aim of the study was to look at existing object-oriented design patterns and investigate how they could be used for capsules, in order to perform mock testing. The focus was to find solutions that were usable from the programmers’ point of view, meaning that they should promote high user effectiveness, efficiency and satisfaction when implementing them. It was also important that program efficiency wasn’t affected negatively. 5 design- or refactoring patterns were adapted for capsules: Constructor Injection, Setter Injection, Parameterize Method, Factory Method and Abstract Factory. Those patterns were evaluated by 5 programmers in a usability test, where Incarnate Injection (an adaptation of Constructor Injection) and Abstract Factory were considered most usable. Incarnate Injection seemed to be easier to implement and promoted high user efficiency, while Abstract Factory was considered more flexible. The performance tests indicated that Abstract Factory compromises program efficiency when the factory product is resource-heavy and is required frequently by dependent capsules. The study showed that it is possible to adapt design patterns to capsules by looking at conceptual similarities between capsules and classes. However, there are cases when this adaptation is impossible. Furthermore, even when adaptation is possible, it was apparent that different patterns adapt differently well to capsules.

Submitted by Marlene Santos (marlene.bc.ufg@gmail.com) on 2016-06-09T17:02:10Z No. of bitstreams: 2 Tese - Eduardo Noronha de Andrade Freitas - 2016.pdf: 1936673 bytes, checksum: 4336d187b0e552ae806ef83b9f695db0 (MD5) license_rdf: 19874 bytes, checksum: 38cb62ef53e6f513db2fb7e337df6485 (MD5) / Approved for entry into archive by Luciana Ferreira (lucgeral@gmail.com) on 2016-06-10T11:14:00Z (GMT) No. of bitstreams: 2 Tese - Eduardo Noronha de Andrade Freitas - 2016.pdf: 1936673 bytes, checksum: 4336d187b0e552ae806ef83b9f695db0 (MD5) license_rdf: 19874 bytes, checksum: 38cb62ef53e6f513db2fb7e337df6485 (MD5) / Made available in DSpace on 2016-06-10T11:14:00Z (GMT). No. of bitstreams: 2 Tese - Eduardo Noronha de Andrade Freitas - 2016.pdf: 1936673 bytes, checksum: 4336d187b0e552ae806ef83b9f695db0 (MD5) license_rdf: 19874 bytes, checksum: 38cb62ef53e6f513db2fb7e337df6485 (MD5) Previous issue date: 2016-02-15 / Coordenação de Aperfeiçoamento de Pessoal de Nível Superior - CAPES / Fundação de Amparo à Pesquisa do Estado de Goiás - FAPEG / The creation of a suite of unit testing is preceded by the selection of which components (code units) should be tested. This selection is a significant challenge, usually made based on the team member’s experience or guided by defect prediction or fault localization models. We modeled the selection of components for unit testing with limited resources as a multi-objective problem, addressing two different objectives: maximizing benefits and minimizing cost. To measure the benefit of a component, we made use of important metrics from static analysis (cost of future maintenance), dynamic analysis (risk of fault, and frequency of calls), and business value. We tackled gaps and challenges in the literature to formulate an effective method, the Selector of Software Components for Unit testing (SCOUT). SCOUT was structured in two stages: an automated extraction of all necessary data and a multi-objective optimization process. The Android platform was chosen to perform our experiments, and nine leading open-source applications were used as our subjects. SCOUT was compared with two of the most frequently used strategies in terms of efficacy.We also compared the effectiveness and efficiency of seven algorithms in solving a multi-objective component selection problem: random technique; constructivist heuristic; Gurobi, a commercial tool; genetic algorithm; SPEA_II; NSGA_II; and NSGA_III. The results indicate the benefits of using multi-objective evolutionary approaches such as NSGA_II and demonstrate that SCOUT has a significant potential to reduce market vulnerability. To the best of our knowledge, SCOUT is the first method to assist software testing managers in selecting components at the method level for the development of unit testing in an automated way based on a multi-objective approach, exploring static and dynamic metrics and business value. / (Sem resumo)