Teste de Software Parte 4

Teste de Software Parte 4
Ricardo de Almeida Falbo Tópicos Especiais – Qualidade de Software 2008/2 Departamento de Informática Universidade Federal do Espírito Santo

Tópicos Especiais - Qualidade de Software 2008/2
Agenda Teste de Integração Teste de Classe Teste de Interação Teste de Componente Teste de Caso de Uso Teste Baseado em Máquina de Estados Teste de Sistema Tópicos Especiais - Qualidade de Software 2008/2

Teste de Integração Objetivo: verificar se as partes, quando colocadas para trabalhar juntas, não conduzem a erros. Todas as técnicas de teste se aplicam, com destaque para o teste funcional. Questão importante: Como agrupar os módulos para se testar a integração entre eles? No paradigma procedimental (Pressman, 2006): Integração não incremental (big-bang) Integração Ascendente (bottom-up) Integração Descendente (top-down) E no paradigma OO? Tópicos Especiais - Qualidade de Software 2008/2

Teste de Integração OO Níveis de Teste de Integração: Teste de Classe: testa a interação entre métodos de uma classe, usando o conjunto de atributos de uma instância. Teste de Interação ou Interclasse: testa a colaboração / interação entre classes. Inicia-se sem prover ainda uma funcionalidade completa, avançando para a interação no contexto de um componente ou caso de uso. Tópicos Especiais - Qualidade de Software 2008/2

Teste de Integração OO Teste de Componente: Quando um componente é implementado usado a tecnologia de objetos, ele pode ser visto como um conjunto de classes que provê uma porção significativa de funcionalidade, acessível por meio de um conjunto de interfaces especificando os comportamentos disponíveis. Perspectiva do desenvolvedor de componente: testa a colaboração entre classes que compõem um componente, bem como as suas interfaces contratuais públicas. Técnicas funcionais e estruturais podem ser aplicadas, pois o código-fonte está disponível. Perspectiva do cliente de componente: quando um componente desenvolvido independentemente é integrado a uma aplicação, o código pode não estar disponível, dificultando a atividade de teste. Neste caso, apenas critérios funcionais são aplicáveis. Tópicos Especiais - Qualidade de Software 2008/2

Teste de Integração OO Teste de Caso de Uso: testa a colaboração entre classes no contexto de um caso de uso ou fluxo de eventos de um caso de uso. Teste de Subsistema: testa partes de um sistema, contendo vários componentes e realizando vários casos de uso. Tópicos Especiais - Qualidade de Software 2008/2

Teste de Classe Visto como um teste de integração, o teste de classe visa testar a integração de métodos e atributos de uma classes. Aspecto importante a verificar: restrições na ordem de invocação de suas operações (muitas vezes implícitas) estão sendo satisfeitas? Seqüência mínima de teste: aquele que exercita o histórico de vida comportamental mínimo de um objeto da classe. Além da seqüência mínima, há muitas combinações possíveis de invocação de operações (Pressman, 2006). Tópicos Especiais - Qualidade de Software 2008/2

Teste de Classe Seja a seguinte classe Conta. Qual a seqüência de testes mínima a ser feita? Que outros casos de teste são possíveis? Tópicos Especiais - Qualidade de Software 2008/2

Teste de Classe Seqüência Mínima abrir – estabelecerLimite – depositar – retirar – encerrar Outros casos de teste possíveis: Infinitos... Seqüências Válidas abrir – estabelecerLimite – depositar – [obterLimite | estabelecerLimite | depositar | retirar | obterSaldo | obterExtrato]n – retirar – encerrar Seqüências Inválidas estabelecerLimite – depositar – retirar – encerrar abrir – depositar – retirar – encerrar abrir – estabelecerLimite – retirar – encerrar abrir – estabelecerLimite – depositar – encerrar abrir – estabelecerLimite – depositar – retirar – encerrar - depositar etc Tópicos Especiais - Qualidade de Software 2008/2

Teste de Classe Necessidade de reduzir o número de casos de teste Teste Aleatório ou Randômico Casos de teste para diferentes seqüências (normalmente válidas) de operações são gerados aleatoriamente. Teste de Partição no Nível de Classe Análogo ao critério Particionamento de Equivalência. Casos de teste são projetados para exercitar cada categoria (válida ou inválida). Alguns critérios: Partição Baseada em Estado Partição Baseada em Atributo Partição Baseada em Categoria Tópicos Especiais - Qualidade de Software 2008/2

Partição Baseada em Estado
O termo “estado” neste contexto designa o estado interno de um objeto dado pelo seu conjunto de atributos e não apenas os estados definidos por uma máquina de estados da classe. Categoriza as operações em duas grandes classes: operações que podem mudar o estado de um objeto da classe, ou seja, que alteram o valor de atributos da classe e operações que não podem mudar o estado de um objeto da classe. Tópicos Especiais - Qualidade de Software 2008/2

Casos de teste são projetados de modo a exercitarem separadamente as operações que mudam o estado e aquelas que não mudam o estado (Pressman, 2006). A seqüência mínima de teste é usada como base. Introduzem-se operações da partição nessa seqüência, respeitando a ordem da seqüência mínima, para gerar casos de teste com seqüências válidas. Tópicos Especiais - Qualidade de Software 2008/2

Seja a seguinte classe Conta. Que operações mudam o estado? Que casos de teste considerar? Tópicos Especiais - Qualidade de Software 2008/2

Operações que mudam o estado: estabelecerLimite, depositar, retirar Operações que não mudam o estado: obterLimite, obterSaldo, obterExtrato Seqüência Mínima abrir – estabelecerLimite – depositar – retirar – encerrar Partições Válidas: abrir – estabelecerLimite – depositar – [estabelecerLimite | depositar | retirar ]n – retirar – encerrar abrir – estabelecerLimite – depositar – [obterLimite | obterSaldo | obterExtrato]n – retirar – encerrar Tópicos Especiais - Qualidade de Software 2008/2

Partição Baseada em Atributo
Categoriza as operações com base nos atributos que elas usam (Pressman, 2006): Operações que usam o atributo sem modificá-lo Operações que modificam o valor do atributo Operações que não usam o atributo Tópicos Especiais - Qualidade de Software 2008/2

Seja a seguinte classe Conta. Que operações usam / modificam / não usam cada um dos atributos? Tópicos Especiais - Qualidade de Software 2008/2

Atributo limiteCredito Usam: obterLimite, obterSaldo, obterExtrato, retirar Modificam: estabelecerLimite Não usam ou modificam: abrir, depositar, encerrar Atributo saldo Usam: obterSaldo, obterExtrato, encerrar Modificam: abrir, depositar, retirar Não usam ou modificam: estabelecerLimite, obterLimite Casos de Teste: pelo menos um caso de teste dentro de cada uma das partições. Tópicos Especiais - Qualidade de Software 2008/2

Partição Baseada em Categoria
Categoriza as operações com base na função genérica que cada uma realiza. Por exemplo, uma categorização que estende a partição baseada em estado: Operações de inicialização Operações de consulta (que não alteram o estado da classe) Operações com atribuição (que alteram o estado da classe) Operações de término Tópicos Especiais - Qualidade de Software 2008/2

Partição Baseada em Categoria
Operações de inicialização: abrir Operações de consulta: obterLimite obterSaldo obterExtrato Operações de atribuição: estabelecerLimite depositar retirar Operações de término: encerrar Tópicos Especiais - Qualidade de Software 2008/2

Teste de Classe Para cada classe, é importante definir se a mesma deve ser testada de forma separada ou no contexto de uma parte maior do sistema (p.ex., componente, caso de uso etc). Essa definição deve baseada nos seguintes fatores (McGregor e Sykes, 2001): Papel da classe no sistema (criticidade) e risco associado à mesma Complexidade da classe, medida em termos do número de estados, operações e associações com outras classes Esforço associado com o desenvolvimento do driver de teste da classe. Tópicos Especiais - Qualidade de Software 2008/2

Planejamento de Teste de Classe
Quem deve testar? Geralmente, classes são testadas pelos próprios desenvolvedores, sendo que seu plano de teste pode ser feito por outra pessoa. Vantagens: Minimiza o número de pessoas que devem conhecer a especificação da classe. Facilita a implementação dos casos de teste, pois o testador conhece a implementação da classe. Driver de teste pode ser usado para depuração. Desvantagens: Problemas no entendimento da especificação são propagados para o teste (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

O que testar? Basicamente, deseja-se testar se uma implementação reflete exatamente sua especificação e nada além disso. O esforço para testar se a implementação contém apenas o que foi especificado pode ser alto e, portanto, deve ser avaliado em relação ao risco associado à classe. Se após a execução de vários de casos de teste, ainda há código não coberto, é possível que exista comportamento indesejado na classe (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

Quando testar? Assim que uma classe está pronta para ser codificada, seu plano de teste pode ser elaborado. O teste de uma classe deve ser executado antes que a mesma seja usada em outras partes do software. Caso a implementação mude, os testes devem ser executados novamente podendo ser alterados ou não (quando não alterados, está-se aplicando teste de regressão) (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

Como testar? Classes são testadas através de drivers de teste, construindo o ambiente necessário à execução dos casos de teste (McGregor e Sykes, 2001). Uso de ferramentas pode ajudar, aumentando a produtividade do teste de classe. Tópicos Especiais - Qualidade de Software 2008/2

Quanto testar? Avaliar criticidade e riscos associados à classe (relação custo-benefício) (McGregor e Sykes, 2001). Aplicar técnicas de teste de classe para minimizar o número de casos de teste, mas com uma boa cobertura. Tópicos Especiais - Qualidade de Software 2008/2

Plano de Teste de Classe
Nome da Classe: Desenvolvedor: Testador: Criticidade: Seqüência Mínima: Considerações sobre o Projeto da Suíte de Teste Casos de Teste (organizados por tipo) Resultados Considerações sobre a Cobertura da Suíte de Teste Tópicos Especiais - Qualidade de Software 2008/2

Teste de Interação ou Interclasse
Uma interação é uma requisição feita por um objeto (o transmissor) a outro (o receptor) para executar uma das operações do receptor. Um programa OO consiste de uma coleção de objetos que colaboram para resolver um problema. Assim, a correta colaboração (ou interação) entre objetos em um programa OO é crítica para a correção do programa (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

Formas Típicas de Interação entre Classes
Mensagens passadas a outros objetos. Uma operação pública que recebe como parâmetro um ou mais objetos. Uma operação pública que retorna um objeto. Objeto que mantém uma referência a outro como parte de seus atributos (atributo implementando uma associação). Um método de uma classe que cria uma instância de outra classe como parte de sua implementação (muitas vezes, um objeto temporário). Tópicos Especiais - Qualidade de Software 2008/2

Teste de Interação Como testar? Usando classes de teste Usando o próprio programa de aplicação (p.ex., caso de uso + estrutura de acesso ao caso de uso) Teste funcional é o mais usado, mas observar o código pode ser importante para definir o que testar (para identificar quais formas de interação estão presentes e entre quais classes). Questão: Como agrupar classes para testar sua integração? Tópicos Especiais - Qualidade de Software 2008/2

Estratégia de Integração Baseada no Uso
Adaptação para o paradigma OO da estratégia ascendente de integração. Começa testando as classes servidoras ou primitivas, i.e., as classes que não usam outras classes. Depois de testar as classes primitivas, testam-se as classes dependentes (ou não primitivas) que dependem apenas das classes já testadas e assim sucessivamente. Tópicos Especiais - Qualidade de Software 2008/2

Teste Baseado no Caminho de Execução
Integra o conjunto de classes necessárias para responder a uma entrada ou um evento do sistema. Cada caminho de execução é testado e integrado individualmente. Teste de Componente e Teste de Caso de Uso se enquadram nesta estratégia. Tópicos Especiais - Qualidade de Software 2008/2

Teste de Interação Testes de interação baseados apenas nas especificações de operações públicas são consideravelmente mais diretos que os baseados nas implementações das mesmas. Quando a abordagem baseada no uso é aplicada integralmente, são necessários apenas testes baseados nas especificações de operações públicas. Quando algumas das classes não são testadas individualmente, contudo, tais testes podem não ser suficientes (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

Abordagem de Projeto e Teste
A abordagem de projeto (design) adotada tem grande influência no projeto de casos de teste. Ex.: Criação de objetos: teste na interface, aplicação ou domínio? É possível classificar as abordagens de projeto em duas grandes categorias: Abordagem defensiva: assume que pouca ou nenhuma checagem de valores de parâmetros vai ocorrer antes das mensagens serem enviadas para objetos da classe. Abordagem de projeto por contrato: assume que as pré-condições são checadas antes que a mensagem seja enviada e que a mensagem não é enviada se os parâmetros estão fora dos limites aceitáveis (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

Abordagem Defensiva de Projeto
Poucas pré-condições estabelecidas. Necessidade de muitas checagens internas de violação de restrições sobre atributos. Muitos resultados possíveis (sobretudo de exceção). Necessidade de um maior número de casos de teste nas classes que recebem mensagens, de modo a checar valores de entrada que produzem exceções e, por conseguinte, maior esforço no teste de classe (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

Abordagem de Projeto por Contrato
Muitas pré-condições estabelecidas. Pouca ou nenhuma checagem interna de violação de restrições sobre atributos. Poucos resultados possíveis (especialmente de exceção). Necessidade de um maior número de casos de teste nas classes que enviam mensagens, de modo a checar valores de entrada que produzem exceções e, por conseguinte, maior esforço no teste de interação (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

Teste de Componente: Perspectiva de Desenvolvedor de Componentes
Um componente pode ser visto como um agregado de objetos e, portanto, o teste de componentes é muito similar ao teste de interações entre conjuntos de objetos. Um componente é tipicamente maior do que uma classe e, por conseguinte, é mais difícil obter boa cobertura de código usando um critério funcional baseado na especificação do componente (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

Teste de Caso de Uso Testa a interação no contexto da realização de um caso de uso. O que testar? Testar as partes mais usadas e mais críticas com um alcance mais amplo de entradas do que as partes menos usadas e menos críticas. Perfil de uso: classificação dos casos de uso baseada em uma combinação de freqüência e criticidade. Riscos associados ao caso de uso devem ser levados em conta e estão fortemente relacionados à criticidade do caso de uso (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

Exemplo: Ferramenta GeRis
Teste de Caso de Uso – Perfil de Uso Projeto: Geris Documento Base: Documento de Especificação de Requisitos – Versão 1.1 Caso de Uso Fluxo de Eventos Tipo Freq. Criti. Importância 1 Controlar Versão de Plano de Riscos Criar Nova Versão de Plano de Riscos Curso Normal Baixa Alta Média Curso Alternativo Curso de Exceção Alterar Versão de Plano de Riscos Consultar Versão de Plano de Riscos Excluir Versão de Plano de Riscos 2 Identicar Riscos 3 Avaliar Risco Efetuar Avaliação de Risco Efetuar Avaliação de Risco: Ação de mitigação aplicada Efetuar Avaliação de Risco: Risco ocorreu Excluir Avaliação de Risco 4 Definir Riscos Gerenciados Tópicos Especiais - Qualidade de Software 2008/2

Teste de Caso de Uso – Perfil de Uso Projeto: Geris Documento Base: Documento de Especificação de Requisitos – Versão 1.1 Caso de Uso Fluxo de Eventos Tipo Freq. Criti. Importância 5 Planejar Ações Curso Normal Média Alta 6 Finalizar Versão de Plano de Riscos 7 Cadastrar Conseqüência Criar Nova Conseqüência Baixa Curso de Exceção Alterar Conseqüência Consultar Conseqüência Excluir Conseqüência Tópicos Especiais - Qualidade de Software 2008/2

Teste de Caso de Uso Um caso de uso contém um conjunto de fluxos de eventos, incluindo cursos normais, alternativos e de exceção. Cada fluxo de eventos inclui a ação tomada por um ator e a resposta produzida pelo sistema. Esses dois elementos correspondem às partes básicas de um caso de teste de caso de uso. Para a construção de um caso de teste, valores específicos de entrada são definidos, assim como os correspondentes resultados esperados. Selecionando diferentes valores para um fluxo de eventos, dá-se origem a diferentes casos de teste (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

Teste de Caso de Uso Partições de Equivalência podem ser criadas, levando-se em consideração fluxos de eventos normais, alternativos e de exceção. Para cada caso de uso / fluxo de exceção: Identificar os valores que devem ser informados pelo ator. Identificar partições de equivalência para cada entrada. Construir tabelas de combinações de valores das várias partições de equivalência. Construir casos de teste exercitando essas combinações (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

Teste de Caso de Uso Projeto: Geris Documento Base: Documento de Especificação de Requisitos Versão: 1.1 Caso de Uso Fluxo de Eventos Entradas Classe de Equivalência Válida Classe de Equivalência Inválida Saida Esperada 1 Controlar Versão de Plano de Riscos Criar Nova Versão de Plano de Riscos (curso normal) nome da versão cadeia de caracteres, exceto apenas espaços nova versão criada cadeia vazia Erro: nome inválido cadeia contendo apenas espaços nome já existente Erro: nome já existente Criar Nova Versão de Plano de Riscos (curso alternativo) versão base versão base selecionada nova versão criada contendo os dados da versão base Tópicos Especiais - Qualidade de Software 2008/2

Caso de Teste Entradas Classe de Equivalência Exercitada Critério Utilizado Saida Esperada Resultado da Execução do Teste 1.1.a nome da versão = "Versão 1" cadeia de caracteres, exceto apenas espaços Teste Funcional Sistemático: Valor típico esperado nova versão criada 1.1.b nome da versão = "Versão 1.0" Teste Funcional Sistemático: Valor típico esperado, 2o elemento 1.1.c nome da versão = <<cadeia vazia>> cadeia vazia Teste Funcional Sistemático: Valor ilegal Erro: nome inválido 1.1.d nome da versão = " " cadeia contendo apenas espaços 1.1.e nome da versão = 1.0 Teste Funcional Sistemático: Entrada válida, mas que pode ser interpretada como tipo ilegal 1.1.f nome já existente Erro: nome já existente 1.1.g nome da versão = 1.1 versão base selecionada nova versão criada contendo os dados da versão base versão base = 1.0 1.1.h nome da versão = 1.2 versão base = 1.1 Tópicos Especiais - Qualidade de Software 2008/2

Teste de Caso de Uso Projeto: Geris Documento Base: Documento de Especificação de Requisitos Versão: 1.1 Caso de Uso Fluxo de Eventos Entradas Classe de Equivalência Válida Classe de Equivalência Inválida Saida Esperada 3 Avaliar Risco Efetuar Avaliação de Risco (curso normal) risco a ser avaliado risco selecionado avaliação de risco criada para o risco selecionado probabilidade (p) 0 <= p <= 100% impacto (i) 0 <= i <= 10 nenhum risco selecionado p< 0 ou p > 100% Erro: probabilidade deve ser um valor entre 0 e 100% i < 0 ou i > 10 Erro: impacto deve ser um valor entre 0 e 10 Tópicos Especiais - Qualidade de Software 2008/2

CasoTeste Entradas Classe de Equivalência Exercitada Critério Utilizado Saida Esperada Resultado 3.1.a risco a ser avaliado = qualquer risco selecionado Teste Funcional Sistemático: Valor típico esperado avaliação de risco criada para o risco selecionado probabilidade (p) = 60% 0 <= p <= 100% impacto (i) = 5 0 <= i <= 10 3.1.b Teste Funcional Sistemático: Valor típico esperado, 2o elemento probabilidade (p) = 80% impacto (i) = 3 3.1.c risco a ser avaliado = nenhum nenhum risco selecionado Análise de Valor Limite: Condição de entrada especificando uma quantidade de valores: Nenhum valor de entrada 3.1.d risco a ser avaliado = quaisquer dois riscos mais de um risco selecionado Análise de Valor Limite: Condição de entrada especificando uma quantidade de valores: Qte máxima + 1 Tópicos Especiais - Qualidade de Software 2008/2

CasoTeste Entradas Classe de Equivalência Exercitada Critério Utilizado Saida Esperada Resultado 3.1.e probabilidade (p) = 0 (demais dados válidos) 0 <= p <= 100% Análise de Valor Limite: Condição de entrada especificando um intervalo de valores: Limite inferior avaliação de risco criada para o risco selecionado 3.1.f probabilidade (p) = 100% (demais dados válidos) Análise de Valor Limite: Condição de entrada especificando um intervalo de valores: Limite superior 3.1.g probabilidade (p) = -0.1% (demais dados válidos) p< 0 ou p > 100% Análise de Valor Limite: Condição de entrada especificando um intervalo de valores: Valor menor do que o limite inferior Erro: probabilidade deve ser um valor entre 0 e 100% 3.1.h probabilidade (p) = 100,1% (demais dados válidos) Análise de Valor Limite: Condição de entrada especificando um intervalo de valores: Valor maior do que o limite superior Tópicos Especiais - Qualidade de Software 2008/2

Teste Baseado em Máquina de Estados
Uma máquina de estados especifica as seqüências de estados pelos quais um objeto passa durante seu tempo de vida em resposta a eventos, juntamente com as respostas a esses eventos (Booch et al., 2006). Pela definição acima, testes baseados em uma máquina de estados aplicam-se a uma classe e, portanto, podem ser vistos como um tipo de teste de classe. Isso é verdade sobretudo quando um diagrama de estados é elaborado na fase de projeto, com as transições entre estados correspondendo a métodos da classe. Tópicos Especiais - Qualidade de Software 2008/2

Quando um diagrama de estados da fase de análise é usado como base para o teste, muitas vezes, as transições correspondem a fluxos de eventos de casos de uso. Assim, é necessário que cada um desses fluxos de eventos tenha sido testado e integrado. Nesta visão, um teste baseado em máquina de estados visa testar a integração de vários casos de uso, tendo como foco uma classe. Tópicos Especiais - Qualidade de Software 2008/2

Usar o diagrama de estados para determinar a seqüência de eventos a serem exercitados. Os casos de teste devem cobrir todos os estados. Cada uma das transições deve ser exercitada pelo menos uma vez. Eventos inválidos devem ser testados para ver se o sistema refuta a sua ocorrência. Tópicos Especiais - Qualidade de Software 2008/2

Teste de Subsistema Após testar casos de uso isoladamente ou no contexto de uma máquina de estados, pode ser útil, ainda, testar se os vários casos de uso se comportam adequadamente no contexto de um subsistema. Testes de ciclo de vida do domínio: realizar os processos de negócio (casos de uso) como eles tipicamente acontecem (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

Teste de Sistema Teste do sistema completo ou de um incremento a ser implantado provendo algum grau de funcionalidades para usuários finais. O foco dos testes de sistema não é exatamente procurar defeitos que conduzam a falhas, mas procurar defeitos que representem variações entre o que o sistema realmente faz e os requisitos especificados para ele. Os tipos de teste nesta fase estão direta ou indiretamente relacionados a requisitos, tanto funcionais quanto não funcionais. Tópicos Especiais - Qualidade de Software 2008/2

Teste de Sistema Os testes de sistema que enfocam requisitos funcionais são análogos aos testes de subsistema. Ou seja, visam testar se os vários casos de uso se comportam adequadamente no contexto, agora, do sistema (ou do incremento a ser implantado). Mas agora é muito importante também que usuários testem efetivamente o sistema, pois pode haver problemas na especificação dos requisitos. Testes dessa natureza são ditos testes de aceitação. Tópicos Especiais - Qualidade de Software 2008/2

Teste de Sistema Para testar requisitos funcionais, testes de ciclo de vida do domínio podem ser aplicados. A idéia de perfil de uso (teste de caso de uso) também pode ser aplicada. Para testar requisitos não funcionais (RNF), é necessário: Definir RNFs como atributos mensuráveis. Projetar casos de teste que detectem a presença ou ausência desses atributos. Executar os casos de teste e analisar os resultados. Tópicos Especiais - Qualidade de Software 2008/2

Teste de Sistema Há diversos tipos de testes de sistemas, focando alguma particularidade ou tipo de RNF, tais como: Teste de Implantação (instalação/remoção do sistema) Teste de Inicialização Teste de Configuração de Hardware e Software Teste de Ambiente (rodar vários programas ao mesmo tempo, simulando situações típicas do usuário) Teste de Exceção e Recuperação Teste de Desempenho Teste de Segurança Teste de Estresse etc Tópicos Especiais - Qualidade de Software 2008/2

Referências Booch, G., Rumbaugh, J., Jacobson, I., UML Guia do Usuário, 2a edição, Editora Campus, 2006. Delamaro, M.E., Maldonado, J.C., Jino, M., Introdução ao Teste de Software, Série Campus – SBC, Editora Campus, 2007. McGregor, J.D., Sykes, D.A., A Practical Guide to Testing Object-Oriented Software, Addison-Wesley, 2001. Pressman, R.S., Engenharia de Software. 6a edição, McGrawHill, 2006. Tópicos Especiais - Qualidade de Software 2008/2

Teste de Software Parte 4

Apresentações semelhantes

Apresentação em tema: "Teste de Software Parte 4"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

Teste de Software Parte 4

Apresentações semelhantes

Apresentação em tema: "Teste de Software Parte 4"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback