Teste de Software

Antigamente, a realização de testes não era uma atividade popular na área de desenvolvimento de software, e isso gerava softwares com pouca qualidade. Hoje em dia, porém, quando falamos que o software está pronto, dizemos que ele já foi finalizado, testado e documentado.

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.

Teste é um conjunto de atividades que podem ser planejadas antecipadamente e conduzidas sistematicamente. Uma das características do teste é: Um bom teste tem alta probabilidade de encontrar um erro.

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.

“Otimismo é o risco ocupacional da programação; teste é o tratamento.” – Kent Beck

Existem diversas outras definições para Teste de Software:

• Avaliar se o software está fazendo o que deveria fazer, de acordo com os seus requisitos, e não está fazendo o que não deveria fazer;
• Processo de executar um programa ou sistema com a intenção de encontrar defeitos (Teste negativo) (Glen Myers — 1979);
• Qualquer atividade que a partir da avaliação de um atributo ou capacidade de um programa ou sistema seja possível determinar se ele alcança os resultados desejados (Bill Hetzel — 1988).

Considerando os conceitos definidos pela Engenharia de Software é importante destacar dois termos que habitualmente são tratados como sinônimos: ERROS e DEFEITOS.

• Um erro é alguma problema encontrada em um artefato da engenharia de software, ou em algum resultado a ser produzido, que é encontrado ANTES do software ser entregue ao cliente.
• Um defeito se refere a falhas encontradas DEPOIS do software ser entregue ao cliente (Pressman). É o resultado de um erro encontrado num código ou num documento.
• Falha: é a manifestação de um ou mais erros.
• Bug: um erro de lógica na programação de um determinado software.

Para a IEEE STD 610:

• Defeito: instrução ou comando incorreto (hardware/software fault).
• Erro: manifestação concreta de um defeito num artefato de software, que pode levar a falha (failure) no ambiente do usuário: comportamento operacional do software diferente do esperado pelo usuário.

Histórico

• Demonstração – década de 70:
  • Garantir que o produto funciona;
  • Testes feitos pelos desenvolvedores.
• Detecção – década de 80/90:
  • Garantir que o produto atende aos requisitos;
  • Testes feitos pelos desenvolvedores e usuários.
• Prevenção – década de 90/00:
  • Garantir que o produto funciona, atende aos requisitos e não tem defeitos;
  • Testes feitos pelos desenvolvedores, usuários e testadores.

Nas décadas de 1960 e 1970, os desenvolvedores dedicavam a maior parcela dos seus esforços nas atividades de codificação e nos testes unitários.

Visão Geral

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 a 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.

O teste de software pode ser visto como uma parcela do processo de qualidade de software. A qualidade da aplicação pode, e normalmente, varia significativamente de sistema para sistema. Os atributos qualitativos previstos na norma ISO 9126 são funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade. De forma geral, 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. Enquanto a especificação do software diz respeito ao processo de verificação do software, a expectativa do cliente diz respeito ao processo de validação do software.

Um desenvolvimento de software organizado tem como premissa uma metodologia de trabalho. Esta deve ter como base conceitos que visem a construção de um produto de software de forma eficaz. Dentro desta metodologia estão definidos os passos necessários para chegar ao produto final esperado.

Assim, quando se segue uma metodologia para o desenvolvimento de um produto de software, espera-se um produto final que melhor agrade tanto aos clientes quanto ao próprio fornecedor, ou seja, a empresa de desenvolvimento. Observando este aspecto, não faz sentido iniciar a construção de um produto de software sem ter uma metodologia de trabalho bem solidificada e que seja do conhecimento de todos os envolvidos no processo. Porém, além de uma crescente demanda por softwares de qualidade, as empresas de desenvolvimento de software sofrem cada vez mais pressão por parte dos clientes para que o produto seja entregue num curto período de tempo. Este fato pode fazer com que uma sólida metodologia de trabalho acabe por se desequilibrar.

Independentemente da metodologia de trabalho empregada no desenvolvimento de um software, para que se obtenha um produto final com um certo nível de qualidade é imprescindível a melhoria dos processos de engenharia de software.

Uma maneira viável para se assegurar a melhoria de tais processos seria tomar como base modelos sugeridos por entidades internacionais respeitadas no assunto. Dentro de uma gama de modelos, sejam eles para situações e ambientes específicos ou para soluções genéricas, existem alguns que são mais utilizados e tidos como eficientes, como por exemplo os SW-CMM, SE-CMM, ISO/IEC 15504 e o mais conhecido CMMI.

Outro fator com grande influência sobre a qualidade do software a ser produzido é o que diz respeito aos testes que serão executados sobre tal produto. 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.

De acordo com um estudo conduzido pelo NIST em 2002, os defeitos resultam num custo anual de 59,5 bilhões de dólares à economia dos Estados Unidos. Mais de um terço do custo poderia ser evitado com melhorias na infraestrutura do teste de software.

Testar software não é somente executá-lo com a intenção de encontrar erros, existem várias atividades como: planejamento e controle, escolha das condições de teste, modelagem dos casos de teste, checagem dos resultados, avaliação de conclusão dos testes, geração de relatórios como também a revisão dos documentos. Algumas pessoas confundem a atividade de depuração (debbuging) com a atividade de teste, mas elas diferem. Pois, a atividade de teste pode demonstrar falhas que são causadas por defeitos enquanto a depuração é uma atividade de desenvolvimento que repara o código e checa se os defeitos foram corrigidos corretamente para então ser feito um teste de confirmação por um testador com a intenção de certificar se o mesmo foi eliminado.

Princípios

São importantes princípios de testes a serem observados (Segundo Pressman e Sommerville):

• Teste completo não é possível, ou seja, mesmo para sistemas de tamanho moderado, pode ser impossível executar todas as combinações de caminhos durante o teste.
• Teste envolve vários estágios. Geralmente, primeiro, cada módulo é testado isoladamente dos demais módulos do sistema (teste de unidade). À medida que os testes progridem, o foco se desloca para a integração dos módulos (teste de integração), até se chegar ao sistema como um todo (teste de sistema).
• Teste deve ser conduzido, preferencialmente, por terceiros. Os testes conduzidos por outras pessoas que não aquelas que produziram o código têm maior probabilidade de encontrar defeitos. O desenvolvedor que produziu o código pode estar muito envolvido com ele para poder detectar defeitos mais sutis.
• Testes devem ser planejados antes de serem realizados. Um plano de testes deve ser utilizado para guiar todas as atividades de teste e deve incluir objetivos do teste, abordando cada tipo (unidade, integração e sistema), como serão executados e quais critérios a serem utilizados para determinar quando o teste está completo. Uma vez que os testes estão relacionados aos requisitos dos clientes e usuários, o planejamento dos testes pode começar tão logo a especificação de requisitos tenha sido elaborada. À medida que o processo de desenvolvimento avança (análise, design e implementação), novos testes vão sendo planejados e incorporados ao plano de testes.

Um princípio muitas vezes adotado ao testar um software é o de Pareto. Ele afirma que existe um forte desequilíbrio entre causas e efeitos, entre esforços e resultados e entre ações e objetivos alcançados.

Para Myers (2004), há princípios vitais para o teste de software. O caso de teste deve definir a saída esperada, de forma a reduzir a interpretação do critério de sucesso. A saída da execução do teste deve ser exaustivamente analisada. Os casos de teste devem verificar não somente as condições inválidas de execução, como também as condições válidas. Outro conceito apresentado é utilizar pessoas e organizações diferentes para a implementação e para a verificação. A entidade de teste possui uma visão destrutiva do sistema, em busca de erros, enquanto a entidade de programação possui uma visão construtiva, em busca da implementação de uma especificação.

Myers também aborda o esforço para se construir casos de teste. Deve-se evitar testes descartáveis, pois a qualidade do teste piora gradualmente com as iterações de desenvolvimento. Em contrapartida, há o teste de regressão, que permite quantificar a evolução da qualidade de software, mantendo e executando novamente testes realizados anteriormente.

O mesmo autor afirma que, diferente do que se poderia considerar senso comum, a probabilidade de existência de erros num certo trecho de código é proporcional à quantidade de erros já encontradas anteriormente. Basicamente, erros aparecem em grupos. Trechos específicos de código de um software qualquer estão mais propensos a ter erros que outros.

Teste Positivo: Teste verificando se o caminho feliz funciona para determinado sistema.

Teste Negativo: Teste verificando se os fluxo alternativos estão bem implementados.

O teste de software é um elemento de um aspecto amplo, que é frequentemente referido como verificação e validação.

Verificação: se refere ao conjunto de atividades que garante que o software implementa corretamente uma função específica. Estamos construindo o produto corretamente? Tem Bugs? Tem Erros?

Validação: se refere ao conjunto de atividades que garante que o software construído corresponde aos requisitos do cliente.  Estamos construindo o produto correto? Ele atende aos requisitos? É rápido como o cliente pediu? Tem a tela de cadastro que o cliente pediu?

A Verificação e Validação englobam muitas das atividades que são abrangidas pela garantia da qualidade de software (SQA), tais como:

• Revisões técnicas formais;
• Auditoria de qualidade e configuração;
• Monitoramento do desempenho;
• Simulação;
• Estudo de viabilidade;
• Revisão da documentação;
• Revisão da base de dados;
• Análise de algoritmos;
• Teste de desenvolvimento;
• Teste de usabilidade;
• Teste de instalação;

Classificação

Não existe uma classificação consensual de teste, estas são as mais exigidas em concurso:

IEEE

• Técnica de Teste.
• Níveis de Teste;
• Tipos de Teste.

Molinari:

• Técnica do Teste (como vou testar);
• Estado do Teste (o momento);
• Metas do Teste (o que tenho para testar);
• Onde será o Teste (o ambiente do teste).

Técnicas (Como Testar?)

Existem muitas maneiras de se testar um software. Mesmo assim, existem as técnicas que sempre foram muito utilizadas em sistemas desenvolvidos sobre linguagens estruturadas que ainda hoje têm grande valia para os sistemas orientados a objeto. Apesar de os paradigmas de desenvolvimento serem completamente diferentes, o objetivo principal destas técnicas continua a ser o mesmo, encontrar falhas no software. Abaixo estão descritas algumas das técnicas mais conhecidas.

Caixa-Branca

Testes de Caixa Branca/White Box/Caixa de Vidro/Estrutural/Orientado a Lógica: visam avaliar as cláusulas de código, a lógica interna do componente codificado, as configurações e outros elementos técnicos.  O oposto do black box, o objetivo é avaliar como está sendo feito o cálculo. O objetivo aqui é verificar a necessidade de refatoração de código, etc.

Também conhecido por teste estrutural ou orientado à lógica, é uma técnica de teste de software que 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 e teste de caminhos lógicos.

Também chamada de teste estrutural ou orientado à lógica, a técnica de caixa-branca 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.

A técnica de teste de caixa-branca também chamada 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. Segundo Pressman (6ª edição – pág.325): “O método de teste de fluxo de dados seleciona caminhos de teste de um programa de acordo com a localização das definições e dos usos das variáveis no programa.”

Os aspectos avaliados nesta técnica de teste dependerão da complexidade e da tecnologia que determinarem a construção do componente de software, cabendo portanto avaliação de mais aspectos que os citados anteriormente. O testador tem acesso ao código fonte da aplicação e pode construir códigos para efetuar a ligação de bibliotecas e componentes. Este tipo de teste é desenvolvido analisando o código fonte e elaborando casos de teste que cubram todas as possibilidades do componente de software. Dessa maneira, todas as variações relevantes originadas por estruturas de condições são testadas.

Um exemplo bem prático desta técnica de teste é o uso da ferramenta livre JUnit para desenvolvimento de classes de teste para testar classes ou métodos desenvolvidos em Java. Também se enquadram nessa técnica testes manuais ou testes efetuados com apoio de ferramentas para verificação de aderência a boas práticas de codificação reconhecidas pelo mercado de software. A aderência a padrões e boas práticas visa principalmente a diminuição da possibilidade de erros de codificação e a busca de utilização de comandos que gerem o melhor desempenho de execução possível. Apesar de muitos desenvolvedores alegarem que não há ganhos perceptíveis com essa técnica de teste aplicada sobre unidades de software, devemos lembrar que, no ambiente produtivo, cada programa pode vir a ser executado milhares ou milhões de vezes em intervalos de tempo pequenos. É na realidade de produção que a soma dos aparentes pequenos tempos de execução e consumo de memória de cada programa poderá levar o software a deixar de atender aos objetivos esperados. A técnica de teste de caixa-branca é recomendada para as fases de teste de unidade e teste de integração, cuja responsabilidade principal fica a cargo dos desenvolvedores do software, que por sua vez conhecem bem o código fonte produzido.

Há diversas técnicas de testes caixa-branca, cada uma delas procurando apoiar o projeto de casos de teste focando em algum ou vários aspectos da implementação. Dentre elas, podem ser citadas:

Testes de estrutura de controle: como o próprio nome diz, enfocam as estruturas de controle de um módulo, tais como comandos, condições e laços. Teste de condição é um tipo de teste de estrutura de controle que exercita as condições lógicas contidas em um módulo. Um teste de fluxo de dados, por sua vez, seleciona caminhos de teste tomando por base a localização das definições e dos usos das variáveis nos módulos. Testes de ciclo ou laço focalizam exclusivamente os laços (loops).

Teste de caminho básico: define uma medida de complexidade lógica de um módulo e usa essa medida como guia para definir um conjunto básico de caminhos de execução.

Caixa-Preta

Testes Caixa Preta/Black Box/Funcionais/Comportamental/Orientado a Dado/Orientado a entrada e saída: visam verificar a funcionalidade e a aderência aos requisitos, em uma ótica externa ou do usuário, sem se basear em qualquer conhecimento do código e da lógica interna do componente testado. Através de uma entrada, testa se a saída é a esperada. Considerando um software como caixa preta, sem desejar saber internamente como está sendo realizado.

A técnica de teste de software, também chamada de comportamental, é a técnica de caixa-preta. Lembre-se da Programação OO, os métodos (funções) são conhecidas como comportamentos. Se este teste testa as funcionalidades, as funções, ele está testando o comportamento.  Lembre-se que neste teste se passa os valores, e espera-se o retorno exato. Ou seja, não se testa o código, mas as funções.

Os Testes Funcionais ou Testes de Caixa Preta. São uma abordagem na qual os testes são derivados da especificação de programa ou de componente. O sistema é uma “caixa preta”. Cujo comportamento somente pode ser determinado estudando-se suas entradas e saídas relacionadas. A esse método também se dá o nome de Testes Funcionais. Porque o testador está preocupado somente com a funcionalidade, e não com a implementação do software. Essa abordagem é igualmente aplicável a sistemas que são organizados como funções ou como objetos. O testador apresenta as entradas ao componente ou ao sistema e examina as saídas correspondentes. Se as saídas não são aquelas previstas. Então o teste detectou com sucesso um problema com o software. O principal problema para o responsável pelos testes de defeitos é selecionar entradas que tenham grande probabilidade de ser membros do conjunto Entradas que causaram algum erro. Muitas vezes. A seleção desses casos de teste tem como base a experiência prévia dos engenheiros de teste. Eles utilizam o conhecimento de domínio para identificar casos de teste que possam revelar defeitos. Contudo. A abordagem sistemática da seleção de dados de teste. Discutida na seção seguinte, pode também ser utilizada para complementar esse conhecimento heurístico.

Também chamada de teste funcional, orientado a dado ou orientado a entrada e saída, a técnica de caixa-preta avalia o comportamento externo do componente de software, sem se considerar o comportamento interno do mesmo. Dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado previamente conhecido. Como detalhes de implementação não são considerados, os casos de teste são todos derivados da especificação.

Quanto mais entradas são fornecidas, mais rico será o teste. Numa situação ideal todas as entradas possíveis seriam testadas, mas na ampla maioria dos casos isso é impossível. Outro problema é que a especificação pode estar ambígua em relação ao sistema produzido, e como resultado as entradas especificadas podem não ser as mesmas aceitas para o teste. Uma abordagem mais realista para o teste de caixa-preta é escolher um subconjunto de entradas que maximize a riqueza do teste. Pode-se agrupar subconjuntos de entradas possíveis que são processadas similarmente, de forma que testar somente um elemento desse subconjunto serve para averiguar a qualidade de todo o subconjunto. Por exemplo, em um sistema que aceita um inteiro como entrada, testar todos os casos possíveis pode gerar pelo menos dezenas de milhares de casos de testes distintos. Entretanto, a partir da especificação do sistema, pode-se encontrar um subconjunto de inteiros que maximizem a qualidade do teste. Depende do propósito do sistema, mas casos possíveis incluem inteiros pares, inteiros ímpares, zero, inteiros positivos, inteiros negativos, o maior inteiro, o menor inteiro.

Essa técnica é aplicável a todas as fases de teste – teste unitário, teste de integração, teste de sistema e teste de aceitação. A aplicação de técnicas de teste leva o testador a produzir um conjunto de casos de teste (ou situações de teste). A aplicação combinada de outra técnica – técnica de particionamento de equivalência (ou uso de classes de equivalência) permite avaliar se a quantidade de casos de teste produzida é coerente. A partir das classes de equivalência identificadas, o testador construirá casos de teste que atuem nos limites superiores e inferiores destas classes, de forma que um número mínimo de casos de teste permita a maior cobertura de teste possível.

Uma abordagem no desenvolvimento do teste de caixa-preta é o teste baseado na especificação, de forma que as funcionalidades são testadas de acordo com os requisitos. Apesar de necessário, esse tipo de teste é insuficiente para identificar certos riscos num projeto de software.

Técnicas típicas de teste de caixa preta incluem:

• Testes baseados em Grafo;
• Particionamento de equivalência: divide o domínio de entrada de um módulo em classes de equivalência, a partir das quais casos de teste são derivados. A meta é minimizar o número de casos de teste, ficando apenas com um caso de teste para cada classe, uma vez que, a princípio, todos os elementos de uma mesma classe devem se comportar de maneira equivalente;
• Análise de valor limite: a prática mostra que um grande número de erros tende a ocorrer nas fronteiras do domínio de entrada de um módulo. Tendo isso em mente, a análise de valor limite leva à seleção de casos de teste que exercitem os valores limítrofes;
• Teste de tabela de decisão;
• Teste de todos os pares;
• Tabelas de estado de transição;
• Teste de caso de uso.

Caixa-cinza

A técnica de teste de caixa-cinza é um mesclado do uso das técnicas de caixa-preta e de caixa-branca. Isso envolve ter acesso a estruturas de dados e algoritmos do componente a fim de desenvolver os casos de teste, que são executados como na técnica da caixa-preta. Manipular entradas de dados e formatar a saída não é considerado caixa-cinza pois a entrada e a saída estão claramente fora da caixa-preta. A caixa-cinza pode incluir também o uso de engenharia reversa para determinar por exemplo os limites superiores e inferiores das classes, além de mensagens de erro.

Regressão

Técnicas de Regressão: visam garantir que o software permaneça intacto depois de novos testes serem realizados. Verificam se as funcionalidades antigas, depois da inserção de novas funcionalidades, continuam funcionando.

Essa é uma técnica de teste aplicável a uma nova versão de software ou à necessidade de se executar um novo ciclo de teste durante o processo de desenvolvimento. Consiste em se aplicar, a cada nova versão do software ou a cada ciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste anteriores do sistema. Inclui-se nesse contexto a observação de fases e técnicas de teste de acordo com o impacto de alterações provocado pela nova versão ou ciclo de teste.

Se, ao juntar o novo componente ou as suas alterações com os componentes restantes do sistema surgirem novos defeitos em componentes inalterados, então considera-se que o sistema regrediu.

Para efeito de aumento de produtividade e de viabilidade dos testes, é recomendada a utilização de ferramentas de automação de teste, de forma que, sobre a nova versão ou ciclo de teste, todos os testes anteriores possam ser executados novamente com maior agilidade. Elas conseguem um resultado mais exato do teste executando exatamente os passos seguidos para o teste das primeiras versões já que elas permitem a gravação do teste.

Alguns tipos de ferramentas:

• Rational functional tester – IBM
• Mercury quick teste professional – HP
• JUnit – Java

Nos últimos anos, técnicas de otimização matemática foram proposta para problemas em teste de regressão (como seleção de casos de teste e priorização de casos de teste).

Teste de regressão é a reexecução de algum subconjunto de testes que já foi conduzido para garantir que as modificações não propaguem efeitos colaterais indesejáveis. Esse subconjunto contém 3 diferentes classes de casos de teste:

• Uma amostra representativa de testes que vão exercitar todas as funções do software;
• Testes adicionais que focalizam funções do software, que serão provavelmente afetadas pela modificação;
• Testes que focalizam os componentes de software que foram modificados.

Técnicas não Funcionais

Outras técnicas de teste existem para testar aspectos não-funcionais do software, como por exemplo, a adequação a restrições de negócio, adequação a normas, ou restrições tecnológicas. Em contraste às técnicas funcionais mencionadas acima, que verificam a produção pelo sistema de respostas adequadas de suas operações, de acordo com uma especificação, as técnicas não funcionais verificam atributos de um componente ou sistema que não se relacionam com a funcionalidade (por exemplo, confiabilidade, eficiência, usabilidade, manutenibilidade e portabilidade).

Uma delas é o uso conjunto de Teste de Desempenho e Teste de Carga, que verifica se o software consegue processar grandes quantidades de dados, e nas especificações de tempo de processamento exigidas, o que determina a escalabilidade do software. O Teste de Usabilidade é necessário para verificar se a interface de usuário é fácil de se aprender e utilizar. Entre verificações cabíveis estão a relação da interface com conhecimento do usuário, a compreensibilidade das mensagens de erro e a integridade visual entre diferentes componentes. Já o Teste de Confiabilidade é usado para verificar se o software é seguro em assegurar o sigilo dos dados armazenados e processados. O 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.

Fases ou Níveis (Quando Testar?)

Uma prática comum é testar o software após uma funcionalidade ser desenvolvida, e antes dela ser implantada no cliente por um grupo de profissionais diferente da implementação. Essa prática pode resultar na fase de teste ser usada para compensar atrasos do projeto, comprometendo o tempo devotado ao teste. Outra prática é começar o teste no mesmo momento que o projeto, num processo contínuo até o fim do projeto.

Em contrapartida, algumas práticas emergentes como a programação extrema e o desenvolvimento ágil focam o modelo de desenvolvimento orientado ao teste. Nesse processo, os testes de unidade são escritos primeiro (TDD) por engenheiros de software. Antes da implementação da unidade em questão, o teste falha. Então o código é escrito, passando incrementalmente em porções maiores dos casos de teste. Os testes são mantidos junto com o resto do código fonte do software, e geralmente também integra o processo de construção do software.

Segundo Pressman (6ª edição, Engenharia de Software, pag. 291 – 4ª edição, Engenharia de Software, pag. 840):

1. Testes de unidade estão associados com o código fonte
2. Testes de integração estão associados com problemas de projeto
3. Testes de validação estão associados com requisitos
4. Testes de sistema estão associados com a engenharia de sistemas

Uma estratégia de teste que é escolhida por grande parte das equipes de software adota uma visão incremental do teste, começando com o teste de unidades individuais de programa, avançando para testes projetados a fim de facilitar a integração das unidades e culmina com testes que exercitam o sistema construído.

Testes de desenvolvimento incluem testes unitários, nos quais são testados objetos e métodos específicos; testes de componentes, nos quais são testados diversos grupos de objetos; testes de sistema, nos quais são testados sistemas parciais e sistemas completos.

Na direção dos tipos de teste focados pela engenharia de software, os testes de integração cuidam dos tópicos associados com os problemas de verificação do projeto do software.

No V-Model, que mapeia os tipos de teste para cada fase do desenvolvimento de software

Teste de Unidade

Teste individual de componente de software.

Teste realizado com os componentes individuais de um software, na maioria das vezes feito pelo desenvolvedor.

Também conhecida como teste unitário ou teste de módulo, é a fase em que se testam as menores unidades de software desenvolvidas (pequenas partes ou unidades do sistema). O universo alvo desse tipo de teste são as sub-rotinas ou mesmo pequenos trechos de código. Assim, o objetivo é o de encontrar falhas de funcionamento dentro de uma pequena parte do sistema funcionando independentemente do todo.

Estágio mais baixo da escala de testes, focaliza o esforço de verificação na menor unidade de projeto de software. É considerado um apêndice do passo de codificação. Os testes unitários verificam o funcionamento de um pedaço do sistema ou software isoladamente ou que possam ser testados separadamente.  Testa o código interno dos componentes. Ex.: Classe utilizando o JUnit.

O teste de unidade focaliza o esforço de verificação na menor unidade de projeto do software – o componente ou módulo de software. Usando a descrição de projeto no nível de componente como guia, caminhos de controle importantes são testados para descobrir erros dentro dos limites do módulo.

O teste de unidade é normalmente considerado um apêndice ao passo de codificação. O projeto de teste de unidade pode ser realizado antes que o código seja iniciado (TDD) ou depois de o código-fonte ter sido gerado.

No paradigma estruturado, a menor unidade refere-se a um procedimento ou função. No paradigma orientado a objetos pode-se considerar uma classe ou um método;

Tipos de testes:

• Testes de interface;
• Estrutura lógica de dados;
• Condições-limites;
• Caminhos independentes;
• Caminhos de manipulação de erros.

Teste de Integração

Teste realizado com a finalidade de expor defeitos nas interfaces e nas interações entre componentes (Teste de Integração de Componentes) ou sistemas integrados (Teste de Integração de Sistemas).

Teste realizado com a finalidade de expor defeitos nas interfaces e nas interações entre componentes ou sistemas integrados.

Na fase de teste de integração, o objetivo é encontrar falhas provenientes da integração interna dos componentes de um sistema. Geralmente os tipos de falhas encontradas são de transmissão de dados. Por exemplo, um componente A pode estar aguardando o retorno de um valor X ao executar um método do componente B; porém, B pode retornar um valor Y, gerando uma falha. Não faz parte do escopo dessa fase de teste o tratamento de interfaces com outros sistemas (integração entre sistemas). Essas interfaces são testadas na fase de teste de sistema, apesar de, a critério do gerente de projeto, estas interfaces podem ser testadas mesmo antes de o sistema estar plenamente construído.

O teste de componentes compostos concentra-se, principalmente, em verificar se a interface de componente se comporta de acordo com sua especificação.

Teste de Integração: seu objetivo é, a partir de componentes testados no nível de unidade, construir uma estrutura de programa determinada pelo projeto. Testa se os componentes se encaixam conforme o planejado, para verificar se eles funcionam corretamente juntos, conforme as especificações.

O teste de integração é alimentado pelos módulos previamente testados individualmente pelo teste de unidade, agrupando-os assim em componentes, como estipulado no plano de teste, e resulta num sistema integrado e preparado para o teste de sistema.

O propósito do teste de integração é verificar os requisitos funcionais, de desempenho e de confiabilidade na modelagem do sistema. Com ele é possível descobrir erros de interface entre os componentes do sistema.

O teste de integração é uma técnica sistemática para construir a arquitetura do software enquanto, ao mesmo tempo, conduz testes para descobrir erros associados às interfaces. O objetivo é, a partir de componentes testados no nível de unidade, construir uma estrutura de programa determinada pelo projeto.

Abordagens

A integração pode seguir abordagem incremental ou não. Enquanto na abordagem não incremental o sistema é agrupado por completo, na abordagem incremental o sistema é agrupado em etapas, facilitando assim o isolamento do erro. Abordagens incrementais diferem entre si na forma em que se constroem as etapas de agrupamento de módulos. Por exemplo, na abordagem descendente os módulos de alto nível são testados e integrados primeiro, permitindo encontrar primeiro os erros de lógica e fluxo de dado de alto nível. Por outro lado, a abordagem ascendente requer o teste e integração dos módulos de baixo nível primeiro.

Observe a figura abaixo:

Integração ascendente ou bottom-up: Nessa abordagem, primeiramente, cada módulo no nível inferior da hierarquia do sistema é testado individualmente. A seguir, são testados os módulos que chamam esses módulos previamente testados. Esse procedimento é repetido até que todos os módulos tenham sido testados. Neste caso, apenas drivers são necessários. Seja o exemplo da figura. Usando a abordagem de integração ascendente, os módulos seriam testados da seguinte forma. Inicialmente, seriam testados os módulos do nível inferior (E, F e G). Para cada um desses testes, um driver teria de ser construído. Concluídos esses testes, passaríamos ao nível imediatamente acima, testando seus módulos (B, C e D) combinados com os módulos por eles chamados. Neste caso, testamos juntos B, E e F bem como C e G. Novamente, três drivers seriam necessários. Por fim, testaríamos todos os módulos juntos.

Integração descendente ou top-down: A abordagem, neste caso, é precisamente o contrário da anterior. Inicialmente, o nível superior (geralmente um módulo de controle) é testado sozinho. Em seguida, todos os módulos chamados por este módulo testado são combinados e testados como uma grande unidade. Essa abordagem é repetida até que todos os módulos tenham sido incorporados. Neste caso, apenas stubs são necessários. Tomando o exemplo da figura, o teste iniciaria pelo módulo A e três stubs (para B, C e D) seriam necessários. Na sequência seriam testados juntos A, B, C e D, sendo necessários stubs para E, F e G. Por fim, o sistema inteiro seria testado.

Muitas outras abordagens, algumas usando as apresentadas anteriormente, podem ser adotadas, tal como a integração sanduíche, que considera uma camada alvo no meio da hierarquia e utiliza as abordagens ascendente e descendente, respectivamente para as camadas localizadas abaixo e acima da camada alvo. Outra possibilidade é testar individualmente cada módulo e só depois de testados individualmente integrá-los (teste big-band). Neste caso, tanto drivers quanto stubs têm de ser construídos para cada módulo, o que leva a muito mais codificação e problemas em potencial.

Teste de Sistema

Avalia o software em busca de falhas por meio da utilização do mesmo, COMO SE FOSSE um usuário final. Dessa maneira, os testes são executados nos mesmos ambientes, com as mesmas condições e com os mesmos dados de entrada que um usuário UTILIZARIA no seu dia-a-dia de manipulação do software. Verifica se o produto satisfaz seus requisitos.

São realizados pela equipe de testes, visando a execução do sistema como um todo ou um subsistema (parte do sistema) (Atenção, não existe base para isso – a FCC disse isso em uma questão – mas todas as fontes informam que Teste de Sistema testa o sistema por inteiro), dentro de um ambiente operacional controlado, para validar a exatidão e perfeição na execução de suas funções. Neste estágio de testes deve ser simulada a operação normal do sistema, sendo testadas todas as suas funções de forma mais próxima possível do que irá ocorrer no ambiente de produção. São usados dados de teste e situações de teste de modo a tentar evitar a ocorrência de defeitos em ambiente de produção. Esses testes são feitos pela equipe de teste de software.

Testa um sistema integrado para verificar se ele atende aos requisitos especificados. Realizado pelos testadores.

Na fase de teste de sistema, o objetivo é executar o sistema sob ponto de vista de seu usuário final, varrendo as funcionalidades em busca de falhas em relação aos objetivos originais. Os testes são executados em condições similares – de ambiente, interfaces sistêmicas e massas de dados – àquelas que um usuário utilizará no seu dia-a-dia de manipulação do sistema. De acordo com a política de uma organização, podem ser utilizadas condições reais de ambiente, interfaces sistêmicas e massas de dados.

Teste de Sistema: o software é apenas um elemento de um sistema maior baseado em computador (pessoal, hardware, informação). Esses testes saem do escopo do processo de software e não são conduzidos somente por engenheiros de software. Testam se o software vai funcionar no sistema maior que é a organização. São realizados pela equipe de testes, visando a execução do sistema como um todo ou um subsistema (parte do sistema), dentro de um ambiente operacional controlado, para validar a exatidão e perfeição na execução de suas funções. Neste estágio de testes deve ser simulada a operação normal do sistema, sendo testadas todas as suas funções de forma mais próxima possível do que irá ocorrer no ambiente de produção. São usados dados de teste e situações de teste de modo a tentar evitar a ocorrência de defeitos em ambiente de produção. Esses testes são feitos pela equipe de teste de software.

Teste de Sistema são uma série de testes cuja finalidade principal é exercitar por completo o Sistema de Informação Baseado em Computador.

Em termos de teste de sistemas, são técnicas utilizadas para verificar a operação correta do sistema em relação a casos inválidos ou inesperados de entrada. Trata-se de técnicas não funcionais

Testes de Release

Como já foi abordado, alguns autores consideram este o teste de release

Testes de Release, temos:

Teste Funcional

Sendo os atores:

Equipe de teste independente – ou seja, não é feito pela equipe de desenvolvimento tem o objetivo de Validação

Tipos:

• Testes baseados em Requisitos: o requisito deve ser escrito de modo que um teste possa ser projetado para ele
• Testes de Cenário: você imagina cenários típicos de uso e os usa para desenvolver casos de teste para o sistema
• Testes de Desempenho, como por exemplo o testes de estresse. Que se utiliza do Perfil Operacional: conjunto de testes q refletem a mistura real de trabalho q será manipulado pelo sistema.

Teste de Aceitação (Acceptance Testing)

São realizados geralmente por um restrito grupo de usuários finais do sistema. Esses simulam operações de rotina do sistema de modo a verificar se seu comportamento está de acordo com o solicitado.

Teste formal relacionado às necessidades dos usuários, requisitos e processos de negócios. É realizado para estabelecer se um sistema satisfaz ou não os critérios de aceitação e para possibilitar aos usuários, aos clientes e às outras entidades autorizadas decidir aceitar ou não determinado sistema.

Teste formal relacionado à necessidade dos usuários e aos requisitos e processos de negócio. Realizado pelos usuários/stakeholders para estabelecer a confiança no sistema.

Geralmente, os testes de aceitação são realizados por um grupo restrito de usuários finais do sistema, que simulam operações de rotina do sistema de modo a verificar se seu comportamento está de acordo com o solicitado. Teste formal conduzido para determinar se um sistema satisfaz ou não seus critérios de aceitação e para permitir ao cliente determinar se aceita ou não o sistema. Validação de um software pelo comprador, pelo usuário ou por terceira parte, com o uso de dados ou cenários especificados ou reais. Pode incluir testes funcionais, de configuração, de recuperação de falhas, de segurança e de desempenho.

Teste de Validação/Aceitação/Homologação: começa no fim do teste de integração, quando componentes individuais já foram exercitados, o software está completamente montado como um pacote, e os erros de interface foram descobertos e corrigidos. Testa se os requisitos foram implementados corretamente, Testados com a ajuda do usuário.

São os testes finais de execução do sistema, realizados pelos usuários, visando verificar se a solução atende aos objetivos do negócio e a seus requisitos, no que diz respeito à funcionalidade e usabilidade, antes da utilização no ambiente de produção.

Para alguns autores este teste também pode ser chamado de teste de usuário. Pois o teste de Operação (chamado por estes autores de Release) é desempenhado por uma equipe especial. Então quando ouvir falar de teste de Release saiba que ele pode estar se referindo a teste executado por um grupo especial de pessoas. Porém, esta não é a definição mais aceita, mas a FCC a utiliza de vez em quando.

O teste de aceitação é composto de 6 Estágios:

1. Definir critérios de aceitação;
2. Planejar testes de aceitação;
3. Derivar testes de aceitação;
4. Executar testes de aceitação;
5. Negociar resultados de teste;
6. Rejeitar/Aceitar sistema.

Teste de Operação (Teste de Release)

Nessa fase o teste é conduzido pelos administradores do ambiente final em que o sistema ou software entrará em ambiente produtivo. Vale ressaltar que essa fase é aplicável somente a sistemas de informação próprios de uma organização, cujo acesso pode ser feito interna ou externamente a essa organização. Nessa fase de teste devem ser feitas simulações para garantir que a entrada em produção do sistema será bem sucedida. Envolve testes de instalação, simulações com cópia de segurança dos bancos de dados, etc.. Em alguns casos um sistema entrará em produção para substituir outro e é necessário garantir que o novo sistema continuará garantindo o suporte ao negócio.

Garantir o funcionamento correto do software para atender as expectativas do cliente é o objetivo da homologação de sistemas. Nessa fase, que precede à implantação, os testes mais comuns são os testes funcionais, de usabilidade e de aceitação. Nesse momento o usuário irá validar se a funcionalidade pedida foi implementada, verificará se o software é usável e também confirmará se a saída da funcionalidade está de acordo com o solicitado, aceitando ou não o software.

Testes Alfa e Beta

Em casos especiais de processos de desenvolvimento de software – sistemas operacionais, sistemas gerenciadores de bancos de dados e outros softwares distribuídos em escala nacional e internacional – os testes requerem fases também especiais antes do produto ser disponibilizado a todos os usuários.

O período entre o término do desenvolvimento e a entrega é conhecido como fase alfa e os testes executados nesse período, como testes alfa. PRESSMAN afirma que o teste alfa é conduzido pelo cliente (único) no ambiente do desenvolvedor, com este “olhando sobre o ombro” do usuário e registrando erros e problemas de uso.

Testes Alfa: são executados quando o desenvolvimento está próximo à sua conclusão. Este tipo de teste é geralmente realizado por usuários ou outros usuários internos e não pelos programadores ou equipe de testes. Teste executado por usuários em ambiente controlado.

Completada a fase alfa de testes, são lançadas a grupos restritos de usuários, versões de teste do sistema denominadas versões beta. Ele também é um teste de aceitação voltado para softwares cuja distribuição atingirá grande número de usuários de uma ou várias empresas compradoras. PRESSMAN afirma que o teste beta é conduzido em uma ou mais instalações do cliente, pelo usuário final do software. Diferente do teste alfa, o desenvolvedor geralmente não está presente. Consequentemente, o teste beta é uma aplicação do software num ambiente que não pode ser controlado pelo desenvolvedor. O cliente registra todos os problemas (reais ou imaginários) que são encontrados durante o teste beta e os relata ao desenvolvedor em intervalos regulares. Com o resultado dos problemas relatados durante os testes beta, os engenheiros de software fazem modificações e depois se preparam para liberar o produto de software para toda a base de clientes.

Testes Beta: são executados quando o desenvolvimento e testes estão praticamente concluídos, e o maior número possível de defeitos/problemas precisam ser encontrados antes da ―release‖ final. Teste executado por usuários em ambiente aleatório, ad-hoc.

A comunidade do teste de software usa o termo Testes Gama de forma sarcástica referindo-se aos produtos que são mal testados e são entregues aos usuários finais para que estes encontrem os defeitos já em fase de produção.

No RUP, podemos afirmar que no final da construção tem-se uma grande execução de teste alfa, e no inicio da transição uma grande quantidade de execução de teste beta.

Candidato a Lançamento

Ultimamente, e principalmente na comunidade de software livre, é comum utilizar o termo candidato a lançamento (release candidate) para indicar uma versão que é candidata a ser a versão final, em função da quantidade de erros encontradas. Tais versões são um passo além do teste beta, sendo divulgadas para toda a comunidade.

Tipos (O quê Testar?)

Teste Positivo: Garante que a aplicação vai funcionar no “caminho feliz” de sua execução.

Teste Negativo: Garante que a aplicação vai funcionar no “fluxo alternativo”.

Testes Back-to-back: o mesmo teste é executado em versões diferentes do software e os resultados são comparados. Buscando verificar se os resultados são idênticos.

Testes de Configuração: verificam se o software está apto a rodar em diferentes versões ou configurações de ambientes (hardware e software), como, por exemplo, diversos browsers ou versões de browsers. Todo software vem na caixa com a configuração mínima, este teste busca levantar estas informações.

Teste de Confirmação: realizado por um testador com a com a intenção de certificar que o erro foi mesmo eliminado depois de ter sido detectado e modificado. Afim de detectar se o código reparado foi corrigido corretamente:

• Todas as partes alteradas nos documentos, funcionalidades e informações devem ser retestadas como se fosse um produto novo.
• Todas as partes inalteradas que sejam influenciadas pelas partes alteradas ou por mudanças em um requerido sistema (de acordo com os conhecimentos específicos do testador) devem ser testadas na sua totalidade.
• Todas as outras partes que não foram alteradas ou influenciadas pelas alterações, não precisam ser testadas como sendo um novo produto. Elas podem ser testadas apenas partes representativas, por amostragem, ou através de um teste de regressão.

Testes de Compatibilidade: validam a capacidade do software de executar em um particular ambiente de hardware/software/sistema operacional/rede etc.

Testes de Usabilidade: verificam o nível de facilidade de uso do software pelos usuários.

Testes de Instalação: verificam o processo de instalação parcial, total ou a atualização do aplicativo.

Testes de Segurança: validam a capacidade de proteção do software contra acesso interno ou externo não autorizado.

Teste de Ameaça normalmente deve ser aplicado dentro de um projeto de software nas etapas de teste de integração e teste de sistema. Teste de ameaça está inserido no contexto de Teste de Segurança. Sabemos que o Teste de Segurança é realizado em 2 momentos: durante o teste de integração, pois nesse momento estamos verificando se os módulos são capazes de trabalharem junto; e no teste de sistemas, onde temos o teste de desempenho, recuperação, segurança e estresse.

Testes de Recuperação: validam a capacidade e qualidade da recuperação do software após ― crashes, falhas de hardware ou outros problemas catastróficos.

“O teste de recuperação é um teste de sistema que força o software a falhar de diversos modos e verifica se a recuperação é adequadamente realizada. Se a recuperação requer intervenção humana, o tempo médio para reparo é avaliado para determinar se está dentro de limites aceitáveis.”

O teste de sistema que força o software a falhar de diversos modos e verifica o retorno do processamento dentro de um tempo pré-estabelecido é um tipo de teste de recuperação

Testes de Desempenho/Performance: visam garantir que o sistema atende aos níveis de desempenho e tempo de resposta acordados com os usuários e definidos nos requisitos. busca extrair informações sobre o desempenho do sistema em cenários normais de uso;

Segundo Sommerville: “Após o sistema ter sido completamente integrado, é possível testá-lo em relação às propriedades emergentes, como desempenho e confiabilidade. Os testes de desempenho devem ser projetados para assegurar que o sistema pode operar na carga necessária. Isso envolve, geralmente, o planejamento de uma série de testes em que a carga é constantemente aumentada até que o desempenho se torne inaceitável. Como em outros tipos de teste, o teste de desempenho concentra-se tanto em demonstrar que o sistema atende aos requisitos como também em descobrir problemas e defeitos no sistema. (…) Um perfil operacional é um conjunto de testes que reflete uma combinação real de trabalho a que o sistema será submetido”.

Testes de carga: visam a avaliar a resposta de um software sob uma pesada carga de dados ou uma grande quantidade de usuários simultâneos para verificar o nível de escalabilidade, ou seja, o momento onde o tempo de resposta começa a degradar ou a aplicação começa a falhar. Busca extrair informações sobre o volume de usuários, transações, etc. o sistema suporta;

Teste de Estresse (Esforço): Devem ser aplicados durante os testes de sistema. Busca extrair informações sobre quando o sistema não suporta a carga aplicada, sendo muito importante para saber estruturar e dimensionar a arquitetura do sistema e prover informações para escalar o sistema.

“Os testes por esforço (estresse) servem para colocar os programas em situações anormais. (…) O teste por esforço usa um sistema de maneira que demande recursos em quantidade, frequência ou volumes anormais.” (Engenharia de Software – Pressman – 7a Ed – Capítulo 17, pág. 419)

“Em testes de desempenho, isso significa estressar o sistema, fazendo demandas que estejam fora dos limites de projeto do software. Isso é conhecido como ´teste de estresse´. Por exemplo, digamos que você está testando um sistema de processamento de transações que é projetado para processar até 300 transações por segundo. Você começa a testar esse sistema com menos de 300 transações por segundo; então, aumenta gradualmente a carga no sistema para além de 300 transações por segundo. até que esteja bem além da carga máxima de projeto do sistema e o sistema falhe.” (Engenharia de Software –  Sommerville – 9a Ed. – Capítulo 8, página 159).

Um perfil operacional é um conjunto de testes que reflete uma combinação real de trabalho a que o sistema será submetido

Teste Fumaça: teste utilizado na fase de integração, é projetado como mecanismo de marca-passo para projetos de prazo crítico, permitindo à equipe avaliar seu projeto em bases frequentes. Abrange as seguintes atividades:

• Componentes que foram traduzidos para código são integrados em uma “construção”, que inclui todos os arquivos de dados, bibliotecas, módulos reusáveis e componentes submetidos a engenharia, que são necessários para implementar uma ou mais funções do produto.
• Uma série de testes é projetada para expor erros que impeçam a construção de desempenhar adequadamente a sua função. O propósito deve ser descobrir erros “bloqueadores” que têm a maior probabilidade de colocar o projeto fora do cronograma.
• A construção é integrada com outras construções e o produto inteiro passa pelo teste fumaça diariamente.

Alguns benefícios esperados do teste fumaça:

• O risco de integração é minimizado;
• A qualidade do produto final é aperfeiçoada;
• Diagnóstico e correção de erros são simplificados;
• Progresso é fácil de avaliar.

Testes Funcionais: grupos de testes que avaliam se o que foi especificado foi implementado, normalmente servindo de base a um processo de verificação automática.

Testes de Qualidade de Código: grupos de testes com o intuito de verificar o código fonte dos programas em consonância com padrões, melhores práticas, instruções não executadas e outros.

Testes de Alterações: visam rastrear alterações de programas durante o processo de teste. Verificando impacto.

Testes de Recuperação de Versões: verificam a capacidade de retornar a uma versão anterior do sistema.

Testes de Interoperabilidade: avaliam as condições de integração com outros softwares e/ou ambientes. Por exemplo, se o sistema recebe informação de um outro, se alguma ação deve ser tomada e vice-versa.

Testes de Sobrevivência (ou Confiabilidade ou Disponibilidade): avaliam a capacidade do software em continuar operando mesmo quando algum elemento (software ou hardware) fica inoperante ou para de funcionar.

Testes Estáticos: Avaliam toda a documentação do projeto, tais como modelos, requisitos etc.

Testes Embutidos: Avaliam a integração entre o hardware e o software, como por exemplo, um sinal para que um equipamento entre em funcionamento.

Testes de Verificação do Site Web: verificam problemas que possa haver no site Web tais como links inválidos, arquivos órfãos, páginas lentas, ligações entre páginas/componentes e outros.

Testes de Conferência de Arquivos: Verificam alterações nos arquivos usados

Teste de aceitação do usuário: Testa se a solução será bem vista pelo usuário. Ex.: caso exista um botão pequeno demais para executar uma função, isso deve ser criticado em fase de testes. (aqui, cabem quesitos fora da interface, também).

Recursos

Stub: Um componente que contém funcionalidade para fins de teste. Um stub é “fictício”, simplesmente retornando alguns valores predefinidos, ou está “simulando” um comportamento mais complexo.

Exemplo: Digamos que tenhamos uma tela de cadastro, porém a parte de persistência ainda não esta pronta. Cria-se um stub simulando a persistência, para que a tela de cadastro possa ser testada. Assim o stub simulará um banco de dados, afinal de contas o que se deseja testar não é o banco, mas a tela de cadastro.

Driver de Teste (shell script): Um aplicativo ou módulo de software usado para disparar um teste e, muitas vezes, fornecer dados de teste, controlar e monitorar execução e relatar resultados de teste. O driver de teste controla a execução automatizada de um ou mais testes.  Um artefato em forma de pacote usado para agrupar conjuntos de scripts de teste, para determinar a sequência da execução dos testes e para oferecer informações úteis relacionadas ao Registro do Teste com as quais os Resultados do Teste podem ser definidos.

Um Driver é uma unidade que implementa chamadas às funcionalidades testadas. Stubs servem para substituir funcionalidades que ainda não foram implementadas ou que estão subordinadas ao módulo sendo testado.

Ciclo de Vida

Teste é uma abordagem sistemática, então deve haver um ciclo de vida do teste, que deve estar alinhado ao ciclo de vida do desenvolvimento do software. Fases de um ciclo de vida num processo de testes:

• Planejamento: Elaboração e revisão da Estratégia de Testes e do Plano de Teste. Também trata da definição das atividades de teste, das estimativas dos recursos necessários para realizá-las, dos objetivos, estratégias e técnicas de teste a serem adotadas e dos critérios para determinar quando uma atividade de teste está completa.
  • Projeto de Casos de Testes: é a atividade chave para um teste bem-sucedido, ou seja, para se descobrir a maior quantidade de defeitos com o menor esforço possível. Os casos de teste devem ser cuidadosamente projetados e avaliados para tentar se obter um conjunto de casos de teste que seja representativo e envolva as várias possibilidades de exercício das funções do software (cobertura dos testes). Existe uma grande quantidade de técnicas de teste para apoiar os testadores a projetar casos de teste, oferecendo uma abordagem sistemática para o teste de software.
• Preparação: Preparação do ambiente de teste, incluindo equipamentos, rede, pessoal, software e ferramentas, massa de teste. Como pode ser visto, o Planejamento e a Preparação fazem parte de todo o ciclo de vida, pois a todo momento se está planejando ou preparando algo.
• Especificação: Elaboração e revisão dos Casos de Teste ― scripts‖ (no caso de uso de ferramentas de automação de testes) e dos Roteiros de Teste e execução dos testes de verificação da documentação do sistema (testes estáticos).
• Execução: Execução dos testes planejados conforme os Casos de Teste ― scripts (no caso de uso de ferramentas de automação de testes) e dos Roteiros de Teste com os correspondentes registros dos resultados obtidos. Consiste na execução dos casos de teste e registro de seus resultados.
  • Análise dos Resultados: Detectadas falhas, os defeitos deverão ser procurados. Não detectadas falhas, deve-se fazer uma avaliação final da qualidade dos casos de teste e definir pelo encerramento ou não de uma atividade de teste.
• Entrega: Conclusão do processo de testes com a entrega do sistema para o ambiente de produção. Todo teste deve ter um relatório final concluindo quais os aspectos observados positivos e negativos do software.

O Processo de Testes de Software representa uma estrutura das etapas, atividades, artefatos, papéis e responsabilidades buscando padronizar os trabalhos para um melhor controle dos projetos de testes. O objetivo de um processo de teste (com metodologia própria, ciclo de vida, etc.) é minimizar os riscos causados por defeitos provenientes do processo de desenvolvimento como também a redução de custos de correção de defeitos, pois, o custo do software (desenvolvimento + manutenção) tendem a ser menor quando o software é bem testado.

A figura abaixo ilustra o processo de teste de software:

Artefatos de Entrada

As atividades de teste normalmente requerem os seguintes artefatos de entrada:

• Definição de Requisitos;
• Especificação de Requisitos;
• Especificação de Análise de Requisitos;
• Especificação de Design;
• Código-fonte dos programas / componentes.

Artefatos de Saída

Uma Especificação/Plano de Teste, que especifica os procedimentos de teste que a equipe de testes deverá adotar, contendo a estratégia de teste a ser seguida, bem como as técnicas de teste que deverão ser aplicadas. Os testes a serem conduzidos deverão ser detalhados através de um conjunto de casos de teste, que contém os pré-requisitos, os procedimentos a serem seguidos, e os resultados esperados de cada teste realizado;

Testware: Define toda a documentação de teste.

Caso de Teste: É uma descrição de um teste a ser executado. Um ou mais casos de teste costumam estar relacionados a um caso de uso.

Suíte de Testes: Pacote de casos de teste relacionados. Por exemplo: Suíte de cadastro, suíte de consulta.

Plano de Teste: É o documento de planejamento do projeto de teste é equivalente ao Plano de Projeto definido pelo PMI (Project Management Institute).

Script de Teste: É uma automação da execução de um caso de teste.

Fábrica de Teste

A fábrica de teste – FT é um aprimoramento do modelo de fábrica de software, a criação das fábricas de software incrementou a velocidade de desenvolvimento e manutenção de aplicações, mas não resolveu questões relacionadas à qualidade dos produtos entregues.

A FT é uma estrutura independente de profissionais com alta especialização e capacitação em processos e ferramentas de testes de software, tem como objetivo medir e avaliar a qualidade dos sistemas que estão sendo modificados, adaptados e construídos. O papel de um fábrica de testes é aplicar o maior volume de testes simulando os principais cenários de negócios avaliando antecipadamente a conformidade do produto com as especificações do cliente.

Nas figuras abaixo é possível visualizar a redução no prazo quando se utiliza a fábrica de testes com o processo de desenvolvimento de um software em paralelo com o de testes. No modelo de testes tradicionais a equipe de desenvolvimento consome 35 dias implementando novas funcionalidades solicitadas, após este período é liberada uma versão que será submetida aos testes para avaliar o comportamento do sistema em relação aos requisitos. Como existe uma forte pressão para cumprir os prazos, a equipe de desenvolvimento irá liberar uma versão mesmo que não esteja em condições de ser homologada, ou seja, com erros e com funcionalidades não implementadas.

No modelo da figura abaixo a FT concentra-se em reduzir o ciclo de desenvolvimento, atuando em paralelo à equipe de desenvolvimento, participando ativamente do projeto, planejando antecipadamente as atividades gerando resultados positivos. Uma das vantagens deste modelo é a possibilidade de validação do andamento do projeto através de “releases intermediários”, obtendo um real posicionamento sobre a situação do projeto, apontando exatamente quais funcionalidades estão com mais dificuldades de serem implementadas, possibilitando ações gerenciais antecipadas.

Testes bem planejados e automatizados permitem execuções de testes em grande escala, com rapidez e precisão, detectando as não conformidades do software, iniciando as correções pela equipe de desenvolvimento o mais breve possível.

Atributos de um Bom Teste

Atributos para um bom teste:

• Um bom teste tem alta probabilidade de encontrar um erro. “Não existe software bem programado, existe software mal testado”.
• Um bom teste não é redundante.
• Um bom teste deve ser “de boa cepa”. Deve ser capaz de detectar o problema e informar o local exato.
• “Um bom teste não deve ser muito simples nem muito complexo.” – Pressman.

Testabilidade

É o quão fácil um programa pode ser testado.

Características:

• Operabilidade: quanto melhor funciona, mais eficientemente pode ser testado.
• Observabilidade: o que você vê é o que você testa.
• Controlabilidade: quanto melhor você pode controlar o software, mais o teste pode ser automatizado e otimizado.
• Decomponibilidade: controlando o escopo do teste, podemos isolar problemas mais rapidamente e realizar retestagem mais racionalmente.
• Simplicidade: quanto menos houver a testar, mais rapidamente podemos testá-lo.
• Estabilidade: quanto menos modificações, menos interrupções no teste.
• Compreensibilidade: quanto mais informações temos, mais racionalmente vamos testar.

Papéis

Segue abaixo alguns dos papéis que uma pessoa pode desenvolver num projeto de teste de software. Uma pessoa pode acumular mais de um dos papéis citados, de acordo com características e restrições de projetos de desenvolvimento de software nas quais estejam inseridas. Nas fases de teste de unidade e de integração, por exemplo, os papéis de arquiteto de teste e analista de teste podem ser assumidos pelo analista de sistemas do projeto; o papel de testador pode ser assumido pelo programador ou por um segundo programador que atue num processo de programação em pares. Na fase de teste de sistema, num contexto em que haja uma equipe de teste independente, pode haver profissionais acumulando os papéis de arquiteto de teste, analista de teste e testador.

O líder (ou gerente) do projeto de testes é a pessoa responsável pela liderança de um projeto de teste específico, normalmente relacionado a um sistema de desenvolvimento, seja um projeto novo ou uma manutenção.

O engenheiro (ou arquiteto) de teste é o técnico responsável pelo levantamento de necessidades relacionadas à montagem da infraestrutura de teste, incluindo-se o ambiente de teste, a arquitetura de solução, as restrições tecnológicas, as ferramentas de teste. É também responsável pela liderança técnica do trabalho de teste e pela comunicação entre a equipe de teste e a equipe de projeto (ou equipe de desenvolvimento).

O analista de teste é o técnico responsável pela operacionalização do processo de teste. Deve seguir as orientações do gerente de teste ou do arquiteto de teste para detalhar a forma de execução dos testes e as condições de teste necessárias. Também deve focar seu trabalho nas técnicas de teste adequadas à fase de teste trabalhada. Também no campo de análise, o analista de ambiente é o técnico responsável pela configuração do ambiente de teste e pela aplicação das ferramentas necessárias para tal. Esse profissional deve ser especializado em arquiteturas de solução e nos sistemas operacionais e softwares de infraestrutura que regem o ambiente. Ele será responsável por tornar disponível o ambiente de teste.

O testador é o técnico responsável pela execução de teste. Ele deve observar as condições de teste e respectivos passos de teste documentados pelo analista de teste e evidenciar os resultados de execução. Em casos de execuções de teste mal-sucedidas, esse profissional pode também registrar ocorrências de teste (na maioria das vezes, defeitos) em canais através dos quais os desenvolvedores tomarão conhecimento das mesmas e tomarão as providências de correção ou de esclarecimentos.

Por fim, o automatizador de teste é o técnico responsável pela automação de situações de teste em ferramentas. Ele deve observar as condições de teste e respectivos passos de teste documentados pelo analista de teste e automatizar a execução desses testes na ferramenta utilizada. Normalmente são gerados scripts de teste que permitam a execução de ciclos de teste sempre que se julgar necessário, desde é claro, que sejam garantidas as mesmas condições iniciais do ciclo de teste (valores de dados, estados dos dados, estados do ambiente, etc.).

Artefatos

O processo de teste de software pode produzir diversos artefatos. O caso de teste geralmente consiste de uma referência a um identificador ou requisito de uma especificação, pré-condições, eventos, uma série de passos a se seguir, uma entrada de dados, uma saída de dados, resultado esperado e resultado obtido. A série de passos (ou parte dela) pode estar contida num procedimento separado, para que possa ser compartilhada por mais de um caso de teste.

Um script de teste é a combinação de um caso de teste, um procedimento de teste e os dados do teste. Uma coleção de casos de teste é chamada de suite de teste. Geralmente, ela também contém instruções detalhadas ou objetivos para cada coleção de casos de teste, além de uma seção para descrição da configuração do sistema usado.

A especificação de teste é chamada plano de teste.

Plano de Teste

A finalidade do Plano de Teste é definir e comunicar a intenção do esforço de teste em determinada programação. Como em outros documentos de planejamento, o principal objetivo é ganhar a aceitação e aprovação dos envolvidos no esforço de teste. Para isso, o documento deve evitar informações que não serão compreendidas ou que serão consideradas irrelevantes pelos envolvidos.

Em segundo lugar, o plano de teste determina o framework no qual os papéis de teste funcionarão em determinada programação. Ele direciona, orienta e restringe o esforço de teste, priorizando os produtos liberados úteis e necessários.

Ao se inspecionar o conteúdo de um plano de testes, devem-se encontrar, entre outras, as seguintes descrições: escopo de testes, abordagens de teste, recursos para realização dos testes e cronograma das atividades de teste a serem realizadas.

Propriedades/Partes Principais que deve conter um Plano de Teste:

• Nome: Nome exclusivo usado para identificar o Plano de Teste.
• Descrição: Descrição resumida do conteúdo do Plano de Teste, geralmente com uma indicação de alto nível da complexidade e do escopo do teste.
• Finalidade: Explicação do que o Plano de Teste representa e por que ele é importante. Geralmente refere-se à iteração específica ou – no caso de um Plano de Teste Mestre – ao projeto ao qual o plano está relacionado.
• Itens de Teste e Avaliação Dependentes: Alguma forma de rastreabilidade ou de mapeamento de dependências para elementos específicos, como os Requisitos individuais que precisam ser consultados.

Caso de Teste

Um Caso de teste é um conjunto de entradas de teste, condições de execução e resultados esperados desenvolvidos para um objetivo específico como, por exemplo, testar o caminho de determinado programa ou verificar o cumprimento de um requisito específico.

No RUP, Um modelo de teste é tipicamente composto por casos de teste, os quais podem especificar como testar cenários específicos de casos de uso. Os casos de teste tipicamente especificam entradas, resultados esperados e outras condições relevantes para as verificações dos cenários.

Geralmente, os casos de teste são categorizados ou classificados pelo tipo ou requisito de teste ao qual estão associados e variam de acordo com isso. A melhor prática consiste em desenvolver pelo menos dois casos de teste para cada requisito de teste:

• Um caso de teste para demonstrar que o requisito foi atendido, geralmente conhecido como um caso de teste positivo,
• Outro caso de teste, conhecido como negativo, refletindo uma condição ou dados inaceitáveis, anormais ou inesperados para demonstrar que o requisito só pode ser atendido sob a condição desejada.

Obtenção de Casos de Teste a partir de Casos de Uso (requisitos funcionais).

Obtenção de Casos de Teste a partir de Especificações Suplementares (requisitos não funcionais):

• Obtenção de Casos de Teste para Testes de Desempenho.
• Obtenção de Casos de Teste para Testes de Acesso/Segurança.
• Obtenção de Casos de Teste para Testes de Configuração.
• Obtenção de Casos de Teste para Testes de Instalação.
• Obtenção de Casos de Teste para Outros Testes Não Funcionais.

Obtenção de Casos de Teste para Testes Unitários

• Testes caixa branca
• Testes caixa preta

Obtenção de Casos de Teste para o Teste de Aceitação do Produto.

Criação de Casos de Teste Para o Teste de Regressão.

Como pode ser observado o caso de teste pode ser criado para testar diversos itens, não somente funcionalidades (proveniente de casos de uso).

Os casos de teste para o teste funcional são derivados de casos de uso do objetivo do teste. É necessário desenvolver casos de teste para cada cenário de caso de uso. Os cenários de caso de uso são identificados através da descrição dos caminhos que percorrer o fluxo básico e os fluxos alternativos, do início ao fim, através do caso de uso.

Obtenção de Casos de Teste a partir de Casos de Uso (Heumann):

1. Para cada caso de uso, gerar uma lista de cenários de casos de uso;
2. Para cada cenário, identificar, ao menos, um caso de teste e as condições que o farão ser executado; e
3. Para cada caso de teste, identificar os dados que serão utilizados para o teste.

No primeiro passo, deve-se ler a descrição textual do caso de uso e identificar o fluxo principal e os fluxos alternativos.

No segundo passo, os casos de teste para cada cenário devem ser identificados. Para tanto deve-se analisar os cenários, revisar a descrição do caso de uso e então criar o caso de teste. Criar uma tabela que represente valores de entrada e saída pode ser muito útil neste ponto, ajudando na organização e montagem dos casos de teste.

No terceiro e último passo, deve-se revisar e validar os casos de teste para assegurar a meticulosidade e identificar casos de teste redundante ou faltantes. Depois de aprovados, os dados de teste devem ser identificados. Sem os dados de teste, os casos de teste não podem ser executados.

2º Passo: Identificar os Valores Válidos ou Inváldos.

3º passo:  Substituição da identificação de Válido, Inválido, por valores.

Bibliografia

Questões

• Engenharia de Software:
  • Teste de Software.

Resolução de Questões de Concursos Anteriores

RESPOSTA: A

RESPOSTA: D

RESPOSTA: A

I. Todas as partes alteradas nos documentos, funcionalidades e informações devem ser testadas como se fosse um produto novo. TESTE DE CONFIRMAÇÃO

II. ERRADO Todas as partes inalteradas que sejam influenciadas pelas partes alteradas ou por mudanças em um requerido sistema (de acordo com os conhecimentos específicos do testador) devem ser testadas por amostragem. ESSAS PARTES INFLUENCIADAS DEVERÃO SER TESTADAS NA SUA TOTALIDADE.

III. ERRADO Todas as outras partes que não foram alteradas ou influenciadas pelas alterações, devem ser testadas como sendo um novo produto.NESSE CASO PODERIA SER TESTADO UM PARTE REPRESENTATIVA, TESTE DE REGRESSÃO.

RESPOSTA:

RESPOSTA: B

É importante afirmar que nenhum teste pode garantir que não restam erros no sistema. Só isso já é motivo para invalidade o item I.

No item III o erro se encontra em afirmar que teste de sistema é feito pelo usuário. Os usuários participam dos Testes de Aceitação.

Testes de cenário: Você imagina cenários típicos de uso e os usa para desenvolver casos de teste para o sistema;

Testes Baseados em Requisitos: o requisito deve ser escrito de modo que um teste possa ser projetado para ele;

Testes de componentes: também conhecido como teste de unidade, testa cada componente ou unidade funcional de forma individualizada.

Testes de desenvolvimento: incluem testes unitários, nos quais são testados objetos e métodos específicos; testes de componentes, nos quais são testados diversos grupos de objetos; testes de sistema, nos quais são testados sistemas parciais e sistemas completos.

Testes de Desempenho: tem o perfil operacional, é o conjunto de testes q refletem a mistura real de trabalho q será manipulado pelo sistema. Ex: Testes de estresse.

Testes de usuário:

RESPOSTA: B

Teste de Aceitação (Acceptance testing): Teste formal relacionado às necessidades dos usuários, requisitos e processos de negócios. É realizado para estabelecer se um sistema satisfaz ou não os critérios de aceitação e para possibilitar aos usuários, aos clientes e às outras entidades autorizadas decidir aceitar ou não determinado sistema.

Testes de sistema: são realizados pela equipe de testes, visando a execução do sistema como um todo ou um subsistema (parte do sistema), dentro de um ambiente operacional controlado, para validar a exatidão e perfeição na execução de suas funções. Neste estágio de testes deve ser simulada a operação normal do sistema, sendo testadas todas as suas funções de forma mais próxima possível do que irá ocorrer no ambiente de produção. São usados dados de teste e situações de teste de modo a tentar evitar a ocorrência de defeitos em ambiente de produção. Esses testes são feitos pela equipe de teste de software.

Teste de Unidade: Teste individual de componente de software.

Teste de Integração: Teste realizado com a finalidade de expor defeitos nas interfaces e nas interações entre componentes (Teste de Integração de Componentes) ou sistemas integrados (Teste de Integração de Sistemas).

RESPOSTA: C

RESPOSTA: E

O Item II está incorreto pois o teste de unidade focaliza o esforço de verificação na MENOR unidade de projeto do software: o componente ou módulo de software. Como pode ser observado, apenas a letra E não informa que o item II está correto.

RESPOSTA: A

Segundo Sommerville: “Após o sistema ter sido completamente integrado, é possível testá-lo em relação às propriedades emergentes (veja Capítulo 2), como desempenho e confiabilidade. Os testes de desempenho devem ser projetados para assegurar que o sistema pode operar na carga necessária. Isso envolve, geralmente, o planejamento de uma série de testes em que a carga é constantemente aumentada até que o desempenho se torne inaceitável.

Como em outros tipos de teste, o teste de desempenho concentra-se tanto em demonstrar que o sistema atende aos requisitos como também em descobrir problemas e defeitos no sistema. (…) Um perfil operacional é um conjunto de testes que reflete uma combinação real de trabalho a que o sistema será submetido.”

RESPOSTA: B

RESPOSTA: A

RESPOSTA: C

Esta questão trata dos níveis de teste sendo:

Unidade: Teste realizado com os componentes individuais de um software, na maioria das vezes feito pelo desenvolvedor.

Integrado: Teste realizado com a finalidade de expor defeitos nas interfaces e nas interações entre componentes ou sistemas integrados.

Sistema: Testa um sistema integrado para verificar se ele atende aos requisitos especificados. Realizado pelos testadores.

Aceitação: Teste formal relacionado à necessidade dos usuários e aos requisitos e processos de negócio. Realizado pelos usuários/stakeholders para estabelecer a confiança no sistema.

RESPOSTA: C

Técnicas típicas de teste de caixa preta incluem:

• Testes baseados em Grafo;
• Particionamento de equivalência;
• Análise de valor limite;
• Teste de tabela de decisão;
• Teste de todos os pares;
• Tabelas de estado de transição;
• Teste de caso de uso.

Teste de Integração não é uma técnica, é uma fase (ou nível) de teste.

RESPOSTA: A

Nesse momento o usuário irá validar se a funcionalidade pedida foi implementada, verificará se o software é usável e também confirmará se a saída da funcionalidade está de acordo com o solicitado, aceitando ou não o software.

RESPOSTA: B

Segundo Pressman (6ª edição, Engenharia de Software, pag. 291 – 4ª edição, Engenharia de Software, pag. 840):

1. Testes de unidade estão associados com o código fonte
2. Testes de integração estão associados com problemas de projeto
3. Testes de validação estão associados com requisitos
4. Testes de sistema estão associados com a engenharia de sistemas

RESPOSTA: A

Item II se refere ao Teste de Estresse. O Item III está incorreta, pois teste de software deve ser aplicado a qualquer software, não apenas àquele que apresenta defeito. Além disso a única meta de teste não é descobrir erro de comportamento (funcionalidade), erros de desempenho, dentre outros também fazem parte.

RESPOSTA: C

Conceito retirado do livro Engenharia de Software, de Roger S. Pressman, 6ª Ed. (página 306)

“O teste de recuperação é um teste de sistema que força o software a falhar de diversos modos e verifica se a recuperação é adequadamente realizada. Se a recuperação requer intervenção humana, o tempo médio para reparo é avaliado para determinar se está dentro de limites aceitáveis.”

RESPOSTA: A

Caixa Preta, também chamado de teste comportamental, focaliza os requisitos funcionais do software. Isto é, o teste caixa-preta permite ao engenheiro de software derivar conjuntos de condições de entrada que vão exercitar plenamente todos os requisitos funcionais de um programa.

Lembre-se da Programação OO, os métodos (funções) são conhecidas como comportamentos. Se este teste testa as funcionalidades, as funções, ele está testando o comportamento.  Lembre-se que neste teste se passa os valores, e espera-se o retorno exato. Ou seja, não se testa o código, mas as funções.

RESPOSTA: A

Conjunto básico de caminhos de execução são analisados utilizando técnicas de caixa-branca.

RESPOSTA: E

Ele fala do tipo de teste de Caixa Branca, e se o teste a aplicado a componentes (de forma individualizada) então está falando do teste unitário. Se estivesse falando “Aos componentes” poderíamos compreender que era o teste de integração.

RESPOSTA: B

RESPOSTA: E

O Plano de Testes é *resultado* (produto de trabalho) do processo de Planejar Testes. Você não vai registrar o PRÓPRIO processo no Plano.

O Plano de Teste não é um registro, é um planejamento de como serão realizadas todas as atividades relacionadas ao teste de um software.

O Teste Unitário (teste de módulo) é muito mais fácil do que o teste de integração, já que este é resultado do trabalho, muitas vezes, de múltiplas equipes, ondeserão testados diversos módulos e o acoplamento dos mesmos.

Os casos de testes devem ser definidos, e somente então iniciam a produção dos scripts de testes.

RESPOSTA: B

Em contraste às técnicas funcionais, que verificam a operação correta do sistema em relação a sua especificação, as técnicas não funcionais verificam a operação correta do sistema em relação a casos inválidos ou inesperados de entrada. É uma forma de testar a tolerância e a robustez do software em lidar com o inesperado.

RESPOSTA: B

É extremamente importante saber diferenciar os testes, principalmente os que possuem um conceito aparentemente próximo com outros. A exemplo disso temos os testes de desempenho, de carga e de estresse:

• Teste de desempenho: busca extrair informações sobre o desempenho do sistema em cenários normais de uso;
• Teste de carga: busca extrair informações sobre o volume de usuários, transações, etc o sistema suporta;
• Teste de stress: busca extrair informações sobre quando o sistema não suporta a carga aplicada, sendo muito importante para saber estruturar e dimensionar a arquitetura do sistema e prover informações para escalar o sistema.

RESPOSTA: B

RESPOSTA: E

Nesse caso, teste de ameaça está inserido no contexto de Teste de Segurança. Sabemos que o Teste de Segurança é realizado em dois momentos: durante o teste de integração, pois nesse momento estamos verificando se os módulos são capazes de trabalharem junto; e no teste de sistemas, onde temos o teste de desempenho, recuperação, segurança e estresse.

RESPOSTA: A

RESPOSTA: A

Na página 304 (Pressman, 6ª edição). Diz o seguinte:

“Quando um software sob encomenda é construído para um cliente, uma série de testes de aceitação é conduzida para permitir ao cliente validar todos os requisitos. Conduzido pelo usuário final em vez de pelos engenheiros de software, um teste de aceitação pode variar de uma “volta de teste” informal para uma série de testes planejada e executada sistematicamente.(…)”

“Se o software é desenvolvido como um produto a ser usado por vários clientes, não é prático realizar testes formais de aceitação com cada um. A maioria dos construtores de produtos de software usa os processos chamados de testes alfa e beta para descobrir erros que o usuário final parece ser capaz de descobrir.(…)”

Segundo Sommerville, na página 53 da 8a edição:

“O teste de aceitação é algumas vezes chamado de teste alfa. Os sistemas sob encomenda são desenvolvidos para um único cliente, o processo de teste alfa continua até que o projetista do sistema e o cliente concordem que o sistema liberado é uma implementação aceitável dos requisitos do sistema.”

O Teste Alfa é realizado em ambiente controlado, geralmente no ambiente de desenvolvimento.

RESPOSTA: D

Teste de Unidade não é uma técnica, é uma fase ou nível.

RESPOSTA: C

As únicas alternativas que podem estar corretas:

A) Um módulo não pode apresentar o mesmo resultado que suas unidades testadas individualmente, até porque esses resultados individuais serão computados pelo módulo que irá apresentar seu próprio resultado. O que podemos entender de forma errônea é que os módulos precisam apresentar resultados corretos assim como as unidades apresentam resultados corretos, mas não é isso que a alternativa nos apresenta.

C) Se um módulo é testado e apresenta os resultados sem nenhum erro podemos dizer que esse módulo atende aos requisitos de sua responsabilidade – Alternativa Correta.

Um porém, é que segundo Pressman (Pressman, 7ed, pág. 409) “O teste de integração é uma técnica para descobrir erros associados com as interfaces” e não com funcionalidade como diz a letra C – O que justificaria a anulação da questão. Ou não:

Os teste de integração testam as interfaces, e verificam se os módulos conseguem se comunicar de forma perfeita. Dessa forma podemos dizer que “as funcionalidade dos módulos testados atendem aos requisitos” pois se eles atendem, os módulos conseguirão se conectar como a especificação definiu.

RESPOSTA: E

“Em testes de desempenho, isso significa estressar o sistema, fazendo demandas que estejam fora dos limites de projeto do software. Isso é conhecido como ´teste de estresse´. Por exemplo, digamos que você está testando um sistema de processamento de transações que é projetado para processar até 300 transações por segundo. Você começa a testar esse sistema com menos de 300 transações por segundo; então, aumenta gradualmente a carga no sistema para além de 300 transações por segundo. até que esteja bem além da carga máxima de projeto do sistema e o sistema falhe.” (Engenharia de Software –  Sommerville – 9a Ed. – Capítulo 8, página 159).

“Os testes por esforço (estresse) servem para colocar os programas em situações anormais. (…) O teste por esforço usa um sistema de maneira que demande recursos em quantidade, frequência ou volumes anormais.” (Engenharia de Software – Pressman – 7a Ed – Capítulo 17, pág. 419)

RESPOSTA: B

A técnica de teste de caixa-branca também chamada 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.

Segundo Pressman (6ª edição – pág.325):

“O método de teste de fluxo de dados seleciona caminhos de teste de um programa de acordo com a localização das definições e dos usos das variáveis no programa.”

RESPOSTA: E

Segundo Pressman: “O teste de integração é uma técnica sistemática para construir a arquitetura de software ao mesmo tempo que conduz testes para descobrir erros associados com as interfaces.”

RESPOSTA: A

Testes de caminho básico é uma técnica de caixa branca, e possibilita que o projetista do caso de teste derive uma medida da complexidade lógica de um projeto procedimental e use essa medida como guia para definir um conjunto básico de caminhos de execução.

Isso está relacionado ao teste de McCabe, ou teste do caminho básico, que deve executar um conjunto básico do programa.

Um caminho básico é o conjunto de caminhos de execução em que um programa executa cada um de seus comandos pelo menos uma vez, e as condicionais são executadas tanto quando for verdadeiro quanto quando for falso.

Um caminho independente é um caminho que introduza um novo conjunto de comandos, ou uma condicional, em sua execução.

RESPOSTA: C

Teste: é um conjunto de atividades que podem ser planejadas antecipadamente e conduzidas sistematicamente. Uma das características do teste é: Um bom teste tem alta probabilidade de encontrar um erro.

Verificação: refere-se ao conjunto de atividades que garante que o software implementa corretamente uma função específica.

Validação: refere-se a um conjunto de atividades diferente que garante que o software construído corresponde aos requisitos do cliente.

Fonte: Pressman – 4ª edição.