1. Teste de Caixa Branca e Métricas de Código
Dupla: Aricelio e Késia
Instituto Federal do Norte de Minas Gerais - Campus Januária
Curso: Tecnologia em Análise e Desenvolvimento de Sistemas
Disciplina: Qualidade de Software
Prof.: Petrônio C. L. S.
2. Sumário
● Teste de Caixa Branca.
● Métricas de Código.
● DoctorJ - Java Analyzer.
● Ferramenta JDepend.
● Referências.
● Demonstração prática.
3. Testes de Software
● O teste do software é a investigação do software a fim
de fornecer informações sobre sua qualidade em
relação ao contexto em que ele deve operar.
● Isso inclui o processo de utilizar o produto para
encontrar seus defeitos.
5. Teste de Caixa Branca
● Teste de caixa-branca é uma técnica de teste que usa a
perspectiva interna do sistema para modelar os casos de
teste, [6].
● O analista tem acesso ao código fonte, conhece a
estrutura interna do produto sendo analisado e possibilita
que sejam escolhidas partes específicas de um
componente para serem avaliadas, [7].
6. Teste de Caixa Branca
● O Teste de caixa-branca é aplicável nas fases de
unidade, integração, regressão e sistema do processo
de teste, e geralmente usado na fase de unidade.
● Estratégias usadas no teste de caixa-branca incluem o
teste de fluxo de controle, fluxo de dados e ramificação
da execução, além da análise estática.
7. Teste de Caixa Branca
● Vantagem: Como a estrutura interna é usada como
referência, é fácil encontrar os valores de entrada mais
úteis para o teste, o que ajuda na otimização geral do
sistema.
● Custo maior devido aos testes serem baseados na
implementação e também exigir o conhecimento interno
do sistema.
9. Métricas de Código
● São ferramentas com as quais se é possível obter uma
visão de mais alto nível de todo o sistema, com
abstrações mais adequadas.
● E através dessas abstrações, gerar gráficos, relatórios,
matrizes, entre outros.
10. Métricas de Código
● As Métricas de Código não estão relacionadas apenas
com o software em si, mas também com os processos
de desenvolvimento e manutenção do mesmo.
● Consegue-se, a partir das métricas, dados quantitativos
que oferecem uma boa informação sobre o andamento
da construção.
11. Métricas de Código
A partir desses dados é possível:
● Estimar custos.
● Avaliar tendências.
● Melhorar o design.
● Até mesmo ter noção sobre a qualidade do sistema
produzido.
12. Métricas de Código
Através das métricas de código pode-se conhecer:
● A complexidade.
● Tamanho.
● Quantidade de métodos.
● Nível de coesão.
● Grau de acoplamento entre classes.
● E inúmeras outras possibilidades.
13. Métricas de Código
Em resumo as métricas são usadas para:
● Analisar qualidade e produtividade do processo de
desenvolvimento e manutenção bem como do produto
de software construído;
● Qualificar a performance técnica dos produtos do ponto
de vista do desenvolvedor.
● Embasar solicitações de novas ferramentas e
treinamentos
14. Métricas de Código
● Medidas funcionais são necessárias para qualificar a
performance dos produtos pela perspectiva do usuário.
● Utilizadas para comparar a produtividade de diferentes
técnicas e tecnologias.
● Entender e aperfeiçoar o processo de desenvolvimento.
● Reduzir frustrações e pressões de cronograma.
16. DoctorJ - Java Analyzer
● DoctorJ é uma ferramenta que analisa o código Java e
sua documentação, a fim de encontrar descuidos e
erros comuns que a ferramenta javadoc não encontra.
● É um software de código aberto.
● É gratuito tanto para uso pessoal e comercial.
17. DoctorJ - Java Analyzer
● A última versão foi lançada em 2006 e é compatível
com todos os sistemas operacionais POSIX (Linux /
BSD / UNIX-like).
19. JDepend
● O JDepend é uma ferramenta que analisa classes Java
e gera métricas sobre a qualidade do "Design" para
cada package Java, [8].
● O JDepend permite a equipe de Qualidade
automaticamente mensurar a qualidade do "Design" em
termos de suas extensibilidades, reusabilidade e
manutenibilidade para controle efetivo das
dependências dos packages Java.
21. JDepend
Esse relatório corresponde a um relatório resumido com as
métricas obtidas pelo JDepend. Os campos da tabela
podem ser interpretados da seguinte forma:
● TC: Número total de classes.
● CC: Número total de classes concretas.
● AC: Número total de classes abstratas.
● Ca: Acoplamento Aferente - número total de classes de
fora de um pacote que dependem de classes de dentro
do pacote.
22. JDepend
● Ce: Acoplamento Eferente - O número total de classes
de dentro de um pacote que dependem de classes de
fora do pacote.
● A: Nível de Abstração – Mede o quanto abstrato é um
pacote.
23. JDepend
● I: instabilidade - Mede a instabilidade de pacotes, onde a
estabilidade é medida calculando o esforço para mudar um
pacote sem gerar impacto em outros pacotes dentro da
aplicação.
● D: Distância da Seqüência Principal – Este valor relaciona a
Abstração e a Instabilidade.
Custo maior devido aos testes serem baseados na implementação, porque se a implementação mudar todo o teste deverá ser refeito.
Custo por exigir o conhecimento interno do sistema, porque requer um conhecimento maior por parte do testador.