Spelling suggestions: "subject:"deste dde 8oftware"" "subject:"deste dde 5oftware""
201 |
Teste estrutural de integração par-a-par de programas orientados a objetos e a aspectos: critérios e automatização / Pairwise integration structural testing of object- and aspect-oriented programs: criteria and automationIvan Gustavo Franchin 19 April 2007 (has links)
Uma abordagem de teste estrutural de integração par-a-par para programas OO e OA escritos em Java e AspectJ é apresentada. A finalidade dessa abordagem é descobrir defeitos que possam existir na interface entre os pares de unidades que se relacionam em um programa. Para programas OO este tipo de teste envolve testar a interação entre os pares de métodos. Já para programas OA, o teste estrutural de integração par-a-par envolve testar a interação entre os seguintes pares de unidades: método-método, método-adendo, adendo-método e adendo-adendo. Para efetuar o teste estrutural de integração par-a-par deve-se considerar todo o fluxo de execução (fluxo de controle e de dados) que ocorre entre a unidade chamadora e a unidade chamada. Para isso é definido o grafo Def-Uso Par-a-Par (PWDU) que é uma abstração formada pela integração dos grafos Def-Uso Orientado a Aspectos (AODU) da unidade chamadora e da unidade chamada. Além disso, são propostos três critérios para derivar requisitos de teste para pares de unidades. Dentre eles, dois critérios são baseados em fluxo de controle: todos-nós-integrados e todas-arestas-integradas; e um critério é baseado em fluxo de dados: todos-usos-integrados. Uma ferramenta que apóia o teste estrutural de unidade de programas OO e OA escritos em Java e AspectJ, chamada JaBUTi/AJ, foi estendida para dar apoio à abordagem de teste de integração proposta. Exemplos de usos são discutidos para explicar a aplicação da abordagem / A pairwise integration structural testing approach for OO and AO programs implemented with Java and AspectJ is presented. The purpose of this approach is to find faults that may exist in the interface between the pairs of units that relate in a program. For OO programs this type of testing involves testing the interaction among pair of methods. For AO programs, the pairwise integration structural testing involves testing the interaction among the following pairs of units: method-method, method-advice, advice-method and advice-advice. To perform the pairwise integration structural testing, all the execution flow (control and data flow) that happens between the caller and the called unit must be considered. For this, it is defined the PairWise Def-Use graph (PWDU) that is an abstraction formed by the integration of the Aspect-Oriented Def-Use (AODU) graphs of the caller and called unit. Additionally, three new criteria to derive test requirements for pairs of units are proposed. Amongst them, two criteria are based on control flow: all-integrated-nodes and all-integrated-edges; and one criterion is based on data flow: all-integrated-uses. A tool that supports unit structural testing of OO and AO programs implemented with Java and AspectJ, called JaBUTi/AJ, was extended in order to support the proposed integration testing approach. Examples are discussed in order to explain the application of the approach
|
202 |
Abordagem semi-supervisionada para detecção de módulos de software defeituososOLIVEIRA, Paulo César de 31 August 2015 (has links)
Submitted by Fabio Sobreira Campos da Costa (fabio.sobreira@ufpe.br) on 2017-07-24T12:11:04Z
No. of bitstreams: 2
license_rdf: 811 bytes, checksum: e39d27027a6cc9cb039ad269a5db8e34 (MD5)
Dissertação Mestrado Paulo César de Oliveira.pdf: 2358509 bytes, checksum: 36436ca63e0a8098c05718bbee92d36e (MD5) / Made available in DSpace on 2017-07-24T12:11:04Z (GMT). No. of bitstreams: 2
license_rdf: 811 bytes, checksum: e39d27027a6cc9cb039ad269a5db8e34 (MD5)
Dissertação Mestrado Paulo César de Oliveira.pdf: 2358509 bytes, checksum: 36436ca63e0a8098c05718bbee92d36e (MD5)
Previous issue date: 2015-08-31 / Com a competitividade cada vez maior do mercado, aplicações de alto nível de
qualidade são exigidas para a automação de um serviço. Para garantir qualidade de
um software, testá-lo visando encontrar falhas antecipadamente é essencial no ciclo
de vida de desenvolvimento. O objetivo do teste de software é encontrar falhas que
poderão ser corrigidas e consequentemente, aumentar a qualidade do software em
desenvolvimento. À medida que o software cresce, uma quantidade maior de testes
é necessária para prevenir ou encontrar defeitos, visando o aumento da qualidade.
Porém, quanto mais testes são criados e executados, mais recursos humanos e de
infraestrutura são necessários. Além disso, o tempo para realizar as atividades de
teste geralmente não é suficiente, fazendo com que os defeitos possam escapar.
Cada vez mais as empresas buscam maneiras mais baratas e efetivas para detectar
defeitos em software. Muitos pesquisadores têm buscado nos últimos anos,
mecanismos para prever automaticamente defeitos em software. Técnicas de
aprendizagem de máquina vêm sendo alvo das pesquisas, como uma forma de
encontrar defeitos em módulos de software. Tem-se utilizado muitas abordagens
supervisionadas para este fim, porém, rotular módulos de software como defeituosos
ou não para fins de treinamento de um classificador é uma atividade muito custosa e
que pode inviabilizar a utilização de aprendizagem de máquina. Neste contexto, este
trabalho propõe analisar e comparar abordagens não supervisionadas e semisupervisionadas
para detectar módulos de software defeituosos. Para isto, foram
utilizados métodos não supervisionados (de detecção de anomalias) e também
métodos semi-supervisionados, tendo como base os classificadores AutoMLP e
Naive Bayes. Para avaliar e comparar tais métodos, foram utilizadas bases de dados
da NASA disponíveis no PROMISE Software Engineering Repository. / Because the increase of market competition then high level of quality applications
are required to provide automate services. In order to achieve software quality testing
is essential in the development lifecycle with the purpose of finding defect as earlier
as possible. The testing purpose is not only to find failures that can be fixed, but
improve software correctness and quality. Once software gets more complex, a
greater number of tests will be necessary to prevent or find defects. Therefore, the
more tests are designed and exercised, the more human and infrastructure
resources are needed. However, time to run the testing activities are not enough,
thus, as a result, it causes escape defects. Companies are constantly trying to find
cheaper and effective ways to software defect detection in earlier stages. In the past
years, many researchers are trying to finding mechanisms to automatically predict
these software defects. Machine learning techniques are being a research target, as
a way of finding software modules detection. Many supervised approaches are being
used with this purpose, but labeling software modules as defective or not defective to
be used in training phase is very expensive and it can make difficult machine learning
use. Considering that this work aims to analyze and compare unsupervised and
semi-supervised approaches to software module defect detection. To do so,
unsupervised methods (of anomaly detection) and semi-supervised methods using
AutoMLP and Naive Bayes algorithms were used. To evaluate and compare these
approaches, NASA datasets were used at PROMISE Software Engineering
Repository.
|
Page generated in 0.0416 seconds