4.9 Testes e Avaliação de Qualidade de Software
4.9.1 Qualidade de Software
Área de conhecimento da engenharia de software que objetiva garantir a qualidade do software através da definição e normatização de processos de desenvolvimento. Apesar dos modelos aplicados na garantia da qualidade de software atuarem principalmente no processo, o principal objetivo é garantir um produto final que satisfaça às expectativas do cliente, dentro daquilo que foi acordado inicialmente. A qualidade é o grau em que um conjunto de características inerentes a um produto, processo ou sistema cumpre os requisitos inicialmente estipulados.22
A engenharia de software objetiva garantir a qualidade através da definição e normatização de processos de desenvolvimento, com um produto final que satisfaça às expectativas do cliente.
Os atributos qualitativos previstos na norma ISO 9126 são: funcionalidade confiabilidade usabilidade eficiência manutenibilidade portabilidade.
Mensurar o bom funcionamento de um software envolve compará-lo com elementos como especificações, outros softwares da mesma linha, versões anteriores do mesmo produto, inferências pessoais, expectativas do cliente, normas relevantes, leis aplicáveis, entre outros.
A verificação compara o software com a especificação, enquanto que a validação compara com a expectativa do cliente.
A melhoria de processos tem base em modelos tidos como eficientes, como por exemplo os SW-CMM, SE-CMM, ISO 15504 e o mais conhecido CMMI.
4.9.1.1 CMM
TI para concursos
O "CMM - Capability Maturity Model for Software /SEI" é uma estrutura (framework), que descreve os principais elementos de um processo de desenvolvimento de software. Organizações de software evoluem o seu ciclo de desenvolvimento de software através de sua avaliação contínua, identificação e ações corretivas dentro de uma estratégia de melhoria dos processos. Este caminho de melhoria é definido por cinco níveis de maturidade:
inicial, ad hoc, sem ambiente estável de desenvolvimento ou processos estruturados, que excedem prazos e orçamentos.
repetitivo, um minimo de disciplina nos processos para repetir sucessos anteriores, podendo utilizar ferramentas de gerência de projetos para administrar custos e prazos, e status do projeto visíveis (marcos e término).
definido, um conjunto de processos padrão estabelecidos e melhorados periodicamente gerenciado, com utilização de indicadores de qualidade
otimizado, com a procura constante de inovação e a realização de um processo controlado e mensurado para melhoria contínua
O CMMI possui duas representações: "contínua" ou "por estágios". Estas representações permitem a organização utilizar diferentes caminhos para a melhoria de acordo com seu interesse.
Representação Continua, que possibilita à organização utilizar a ordem de melhoria que melhor atende os objetivos de negócio da empresa. É caracterizado por Níveis de Capacidade (Capability Levels):
Nível 0: Incompleto (Ad-hoc) Nível 1: Executado (Definido) Nível 2: Gerenciado
Nível 3: Definido
Nível 4: Quantitativamente gerenciado Nível 5: Em otimização
Representação Por Estágios, que oferece uma seqüência pré-determinada para melhoria baseada em estágios que não deve ser desconsiderada, pois cada estágio serve de base para o próximo. É caracterizado por Níveis de Maturidade (Maturity Levels):
Nível 1: Inicial (Ad-hoc) Nível 2: Gerenciado Nível 3: Definido
Nível 4: Quantitativamente gerenciado Nível 5: Em otimização
4.9.1.2 Garantia de qualidade de software
A Garantia da Qualidade de Software (GQS) é a área-chave de processo do CMM cujo objetivo é fornecer aos vários níveis de gerência a adequada visibilidade dos projetos, dos processos de desenvolvimento e dos produtos gerados. A GQS atua como “guardiã”, fornecendo um retrato do uso do Processo e não é responsável por executar testes de software ou inspeção em artefatos.23
Obtendo a visibilidade desejada, a gerência pode atuar de forma pontual no sentido de atingir os quatro grandes objetivos de um projeto de desenvolvimento de software, quais sejam, desenvolver software de alta qualidade, ter alta produtividade da equipe de desenvolvimento, cumprir o cronograma estabelecido junto ao cliente e não necessitar de recursos adicionais não previstos.
Para conseguir esses objetivos a área-chave de processo GQS estimula a atuação das equipes responsáveis pelo desenvolvimento de software em diversas frentes objetivando internalizar comportamentos e ações, podendo-se destacar:
o planejamento do projeto e o acompanhamento de resultados; o uso dos métodos e ferramentas padronizadas na organização; a adoção de Revisões Técnicas Formais;
o estabelecimento e a monitoração de estratégias de testes;
a revisão dos artefatos produzidos pelo processo de desenvolvimento;
23http://pt.wikipedia.org/wiki/Qualidade_de_software
a busca de conformidade com os padrões de desenvolvimento de software; a implantação de medições associadas a projeto, processo e produto;
a utilização de mecanismos adequados de armazenamento e recuperação de dados relativos a projetos, processos e produtos;
a busca de uma melhoria contínua no processo de desenvolvimento de software.
4.9.2 Teste 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.
O teste é um processo realizado pelo testador de software, que permeia outros processos da engenharia de software, e que envolve ações que vão do levantamento de requisitos até a execução do teste propriamente dito.
Não se pode garantir que todo software funcione corretamente, sem a presença de erros, visto que os mesmos muitas vezes possuem um grande número de estados com fórmulas, atividades e algoritmos complexos. O tamanho do projeto a ser desenvolvido e a quantidade de pessoas envolvidas no processo aumentam ainda mais a complexidade. Idealmente, toda permutação possível do software deveria ser testada. Entretanto, isso se torna impossível para a ampla maioria dos casos devido à quantidade impraticável de possibilidades. A qualidade do teste acaba se relacionando à qualidade dos profissionais envolvidos em filtrar as permutações relevantes.
Falhas podem ser originadas por diversos motivos. Por exemplo, a especificação pode estar errada ou incompleta, ou pode conter requisitos impossíveis de serem implementados, devido à limitações de hardware ou software. A implementação também pode estar errada ou incompleta, como um erro de um algoritmo. Portanto, uma falha é o resultado de um ou mais defeitos em algum aspecto do sistema. Todas as metodologias de desenvolvimento de software têm uma disciplina dedicada aos testes. Atualmente esta é uma tarefa indispensável, porém muitas vezes efetuada de maneira ineficiente, seja pelo subestimar dos que desenvolvem, pela falta de tempo ou mesmo pela falta de recursos humanos e financeiros.
O gerenciamento de projetos define alguns princípios em relação aos testes:24 Testar é um exercício de gerência de risco
Treinamento em teste reduz custos a longo prazo
As estimativas de teste devem ser baseadas no risco do negócio
A estratégia de teste deve ser elaborada através de um trabalho conjunto entre as áreas envolvidas É melhor encontrar um defeito nas primeiras fases do que em produção
Um plano de testes deve passar por alguns estágios: Planejamento Estratégia de Teste Cronograma básico Plano de Teste Cronograma final Análise de Risco
Análise de Pontos deTeste Elaboração
Elaborar Cenário de Teste Elaborar Caso de Teste Procedimento de Teste Implementar Teste Execução Casos de Teste Roteiros de Teste Controle Relatórios de Defeitos Relatórios de Progresso
TI para concursos
As pessoas envolvidas nos testes podem assumir os papéis de:
Líder ou Gerente de teste, responsável pela liderança de um projeto de teste específico
Arquiteto de Teste, responsável pela montagem do ambiente de teste (infra-estrutura) e escolha das ferramentas
Analista de Teste, responsável pela modelagem e elaboração dos casos de testes e scripts de teste Testador, responsável pela execução dos casos de teste e scripts de teste
A definição de quem irá executar os testes dependerá do nível ou estágio do teste: Teste Unitário - Desenvolvedores
Teste de Integração - Analistas de Sistemas Teste de Sistema - Analistas de Teste
Teste de Aceitação - Usuários e Analistas de Teste
Existem técnicas de testes chamadas de funcionais, que verificam se o sistema faz o que deveria:25 Teste de caixa-branca - Também chamado de teste estrutural ou orientado à lógica, avalia o
comportamento interno do componente de software. Essa técnica trabalha diretamente sobre o código fonte do componente de software para avaliar aspectos tais como: teste de condição, teste de fluxo de dados, teste de ciclos, teste de caminhos lógicos, códigos nunca executados.
Teste de caixa-preta - Também chamado de teste funcional, orientado a dado ou orientado a entrada e saída, avalia o comportamento externo do componente de software. Dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado previamente conhecido. Há, por outro lado, as técnicas não funcionais, que testam como a operação correta do sistema se comporta em situações anormais, como casos de entradas inválidas ou inesperadas.
teste de desempenho com teste de carga, verifica se o software consegue processar grandes quantidades de dados nas especificações de tempo de processamento exigidas, o que determina a escalabilidade do software.
teste de usabilidade, necessário para verificar se a interface de usuário é fácil de se aprender e utilizar. teste de confiabilidade, usado para verificar se o software é pode assegurar o sigilo dos dados
armazenados e processados.
teste de recuperação, usado para verificar a robustez do software em retornar a um estado estável de execução após estar em um estado de falha.
4.9.3 Documentos de Teste
IEEE 829-1998, também conhecido como o Padrão 829 para Documentação de Teste de Software, é um padrão IEEE que especifica a forma de uso de um conjunto de documentos em oito estágios definidos de teste de software, cada estágio potencialmente produzindo seu próprio tipo de documento. O padrão especifica o formato desses documentos mas não estipula se todos eles devem ser produzidos, nem inclui qualquer critério de conteúdo para esses documentos.26
Documentação de Teste consiste em um conjunto de documentos relacionados ao teste das diversas classes e seus relacionamentos no sistema. Dentre eles pdemos ter:27
Plano de Teste, que prescreve o escopo, a abordagem, os recursos e o cronograma de testes. No mínimo os seguintes tópicos devem ser tratados:
Descrição do programa a ser testado: o que faz; estrutura
Objetivo dos testes: por exemplo, se são testes caixa branca ou caixa preta, se são testes de integração ou de unidade
Escopo dos testes: que itens serão testados, quais não serão
Projetos de Teste, que detalha o planejamento de testes e identifica os elementos a serem testados. No caso de testes de unidades, cada unidade é um item. Definção das estruturas provisórias (drivers, stubs, arquivos ou bancos de dados criados para os testes, entre outros) que serão usadas nos testes.
Casos de Teste especificados no projeto. A descrição de cada caso de teste deve conter os seguintes tópicos:
Identificação do caso de teste Itens a testar
Entradas: valores dos campos de entrada Saídas esperadas: valores dos campos de saída
25http://pt.wikipedia.org/wiki/Teste_de_software
26http://se.inf.ethz.ch/teaching/ss2005/0050/exercises/REMOVED/IEEE%20Std%20829-1998%20test.pdf 27http://www.ic.unicamp.br/~eliane/Cursos/Planos_Testes/Documentos/plantestes.doc.
Ambiente: necessidade de hw, sw, ferramentas e estruturas provisórias que sejam específicas desse caso de teste
Procedimentos: identificação do procedimento de teste (dentre os já listados na seção anterior) que será usado para executar o caso de teste
Dependências: condições prévias para a execução do caso de teste, inclusive outros casos de teste que devam ser executados obrigatoriamente antes deste
Saídas observadas: resultados fornecidos pelo item em teste ou anomalias ocorridas durante a execução Impacto: consequências do incidente de teste (evento indesejável que tenha ocorrido durante os testes).
Como para a inspeção, classificá-los em categorias:
MA: maior. Causa resultados errados/anomalia na execução do programa ME: menor. Causa outro tipo de problema que não afeta a execução do programa
Procedimentos de Teste, que especifica os passos para execução. Definição dos procedimentos associados ao conjunto de testes:
Uma identificação do procedimento . O objetivo do procedimento.
Os requisitos especiais para a execução do procedimento (por exemplo, usar o arquivo DadosTeste) O fluxo passo a passo do procedimento detalhado o suficiente para que possa ser executado manualmente
por um operador ou convertido em um script de teste. Descrição de cada um dos casos de teste gerado.
Resultados do teste, contendo os registros dos testes realizados em ordem cronológica.
Relatório de incidentes, contendo o registro dos problemas encontrados durante os testes que mereçam ser investigados.
Relatório de resumo dos teste, contendo um resumo dos resultados das atividades projetadas e fornecendo avalições baseadas nestes resultados. O relatório fecha a etapa de testes realizada, permitindo uma avaliação da eficácia dos mesmos, indicação do nível de qualidade do produto, se há necessidade de testes adicionais ou a reconstrução de alguns itens sob teste. O relatório de resumo pode conter:
Identificador do relatório resumido
Contexto: quais os itens testados, com respectivos números de versão e revisão
Variações: descrever as possíveis variações dos testes realizados em relação ao previsto na especificação, justifiando o motivo de tais variações
Abrangência: avaliar se a cobertura foi suficiente, conforme o planejado. Indicar possíveis deficiências nos testes, caso existam.
Sumário dos resultados: resumir os incidentes ocorridos
Avaliação: fornecer uma avaliação global da eficácia dos testes; uma base para isso pode ser o número de defeitos classificados como MA que foram encontrados.
Sumário das atividades: para cada item testado, indicar o tempo previsto e os efetivamente gastos para as tarefas de teste
Aprovações: indicar se o item testado foi considerado aprovado ou não.
4.10
Exercícios
36. (ICMS-SP 2009) Quanto aos requisitos de software, considere:
I. É importante que se estabeleçam práticas para encontrar, documentar, organizar e rastrear os requisitos variáveis de um sistema.
II. Etnografia (observação e análise dos fluxos de trabalho) e sessões de JAD são práticas que podem ser aplicadas na elicitação.
III. Elicitar significa descobrir os requisitos de um sistema por meio de entrevistas, de documentos do sistema existente, de análise do domínio do problema ou de estudos do mercado.
Está correto o que se afirma em 36
(a) I, apenas. (b) I e II, apenas. (c) I, II e III.xx (d) II e III, apenas. (e) III, apenas.
TI para concursos 37. (ICMS-SP 2009) Considere:
"Os requisitos expressam as características e restrições do produto de software do ponto de vista de satisfação das necessidades do usuário. Em geral, independem da tecnologia empregada na construção da solução, sendo uma das partes mais críticas e propensas a erros no desenvolvimento de software”.
Quanto aos requisitos de software, a descrição acima está 37
(a) incoerente ao afirmar que expressam restrições. (b) incoerente ao afirmar que independem da tecnologia.
(c) incoerente ao afirmar que expressam características do ponto de vista de satisfação das necessidades do usuário.
(d) totalmente coerente.xx
(e) incoerente ao afirmar que os requisitos são uma das partes mais críticas e propensas a erros.
(ICMS-SP 2009) Instruções: Para responder às duas próximas questões, considere:
“É necessário que o software calcule os salários dos diaristas e mensalistas e emita relatórios mensais sumariados por tipo de salário. Entretanto, a base de dados deve estar protegida e com acesso restrito aos usuários autorizados. De qualquer forma, o tempo de resposta das consultas não deve superar os quinze segundos, pois inviabilizaria todo o investimento nesse sistema. Devo lembrar que os relatórios
individuais dos departamentos, nos quais constam os salários dos funcionários, devem ser emitidos quinzenalmente em razão dos adiantamentos e vales que recebem. É fundamental que o software seja operacionalizado usando código aberto. Necessito, ainda, forte gerenciamento de risco, prazo e custo, porque a entrega do produto final não pode ultrapassar o prazo de oito meses a contar da data de início do projeto. A frase acima, expressa por um funcionário do cliente, aborda alguns requisitos de software
especificados para um sistema de gestão de pessoal. 38. (ICMS-SP 2009) No texto, são requisitos não-funcionais:38
(a) não pode ultrapassar o prazo de oito meses e necessário que o software calcule os salários dos diaristas e mensalistas.
(b) os relatórios individuais dos departamentos, nos quais constam os salários dos funcionários, devem ser emitidos quinzenalmente e em razão dos adiantamentos e vales que recebem.
(c) É fundamental que o software seja operacionalizado usando código aberto e os relatórios individuais dos departamentos, nos quais constam os salários dos funcionários, devem ser emitidos quinzenalmente. (d) tempo de resposta das consultas não deve superar os quinze segundos e entrega do produto final não
pode ultrapassar o prazo de oito meses.xx
(e) pois inviabilizaria todo o investimento nesse sistema e em razão dos adiantamentos e vales que recebem.
39. (ICMS-SP 2009) No texto, são requisitos funcionais:39
(a) calcule os salários dos diaristas e mensalistas e os relatórios individuais dos departamentos, nos quais
constam os salários dos funcionários, devem ser emitidos quinzenalmente.xx
(b) Necessito, ainda, forte gerenciamento de risco, prazo e custo e a base de dados deve estar protegida e com acesso restrito aos usuários autorizados.
(c) é fundamental que o software seja operacionalizado usando código aberto e emita relatórios mensais sumariados por tipo de salário.
(d) emita relatórios mensais sumariados por tipo de salário e necessito, ainda, forte gerenciamento de risco, prazo e custo.
(e) a base de dados deve estar protegida e com acesso restrito aos usuários autorizados e entrega do produto final não pode ultrapassar o prazo de oito meses.
40. (ICMS-SP 2009) O processo de confirmação que um software vai ao encontro das especificações de software se trata de um conceito-chave de qualidade denominado 40
(a) Validação.
(b) Verificação.xx
(c) Precisão. (d) Acurácia. (e) Confiabilidade.
41. (ICMS-SP 2009) Garantir que um ou mais componentes de um sistema combinados funcionam corretamente é o objetivo do tipo de teste 41
(a) de sistema.
(b) de integração.xx
(c) de configuração. (d) operacional. (e) funcional.
42. (ICMS-SP 2009) O teste de ameaça normalmente deve ser aplicado dentro de um projeto de software nas etapas de 42
(a) desenvolvimento inicial e desenvolvimento intermediário. (b) desenvolvimento intermediário e teste de aceitação. (c) desenvolvimento intermediário e teste de sistema. (d) teste de integração e teste de aceitação.
43. (ICMS-SP 2009) Na prática de garantia de qualidade de software, contrapondo com o controle de qualidade de software, se aplica a atividade: 43
(a) executar teste de software. (b) desenvolver casos de testes.
(c) definir métricas e medição.xx
(d) definir estratégias de testes.
(e) definir planos de desenvolvimento de teste.
44. (ICMS-SP 2009) O processo de engenharia de software denominado ciclo de vida clássico refere-se ao modelo 44
(a) em cascata.xx
(b) incremental. (c) evolucionário. (d) prototipagem. (e) de processo unificado
45. (ICMS-SP 2009) O conceito de sprint aplica-se ao modelo ágil do processo de engenharia de software denominado 45 (a) XP. (b) DAS. (c) DSDM. (d) Scrum.xx (e) Crystal.
46. (ICMS-SP 2009) A engenharia de software está inserida no contexto 46
(a) da engenharia de sistemas, apenas.
(b) das engenharias de processo e de produto, apenas. (c) das engenharias de sistemas e de processo, apenas. (d) das engenharias de sistemas e de produto, apenas.
(e) das engenharias de sistemas, de processo e de produto.xx
47. (FCC - 2008 - TRT) A frase "o tempo médio de resposta do sistema não deve ultrapassar 5 segundos" indica
47
(a) uma funcionalidade do sistema.
(b) uma atividade do cronograma do sistema. (c) uma função executada pelo usuário do sistema. (d) uma possível definição de requisito não funcional.xx
(e) um ponto de controle nas etapas de desenvolvimento do sistema.
48. (FCC - 2008 – TCE AL) Em um sistema cujo objetivo principal seja emitir guias de cobrança de impostos e fazer o controle de contribuintes, NÃO é um produto inerente ao trabalho de levantamento de requisitos48
(a) uma descrição da relação possível entre as linhas de código com os pontos de função.xx
(b) uma declaração da necessidade e da viabilidade. (c) uma descrição do ambiente técnico do sistema. (d) uma afirmação limitada do escopo do sistema.
(e) um conjunto de cenários que fornecem informações sobre o uso do sistema sob diferentes condições de operação.
49. É correto afirmar que 49
(a) um relatório não é um artefato de sistema.
(b) segurança não é um requisito não funcional de sistema.
(c) um executável é um artefato de sistema.xx
(d) os atributos de uma classe UML são especificações dos seus métodos. (e) confiabilidade é um requisito funcional de sistema.
50. O modelo FURPS, para melhoria de qualidade de software, representa as dimensões, que são mais relevantes para os clientes: 50
(a) Funcionalidade, Usabilidade, Confiabilidade, Desempenho e Suportabilidade.xx
(b) Funcionalidade, Usabilidade, Reusabilidade, Pontualidade e Suportabilidade. (c) Flexibilidade, Usabilidade, Conformidade, Desempenho e Atendimento. (d) Flexibilidade, Usabilidade, Reusabilidade, Performance e Suportabilidade. (e) Integridade, Usabilidade, Conformidade, Portabilidade e Atendimento.
51. Segundo o modelo CMM, migrar do nível 3 de maturidade para o nível 4 representa uma melhoria da