SóProvas


ID
1789276
Banca
CESPE / CEBRASPE
Órgão
TJ-DFT
Ano
2015
Provas
Disciplina
Engenharia de Software
Assuntos

Os processos de teste de software objetivam avaliar os programas implementados, bem como identificar possíveis erros em um programa antes da sua utilização. A esse respeito, julgue o próximo item.

Indica-se a automatização de testes para os testes de componentes e de sistema, visto que o uso de testes unitários é inviável, por dependerem de diversas possibilidades a serem avaliadas.

Alternativas
Comentários
  • Deve-se automatizar também testes unitários, para garantir que novos ou antigos bugs não sejam adicionados. Tanto é que existe uma ferramenta JUNIT muito utilizado para isso.

  • Componentes podem ser testados individualmente (testes unitários) ou de modo integrado (teste de integração), portanto o teste de unidade não é inviável nesse contexto. Além disso, o estágio de testes de unidade pode ser realizado de forma automatizada, por meio de ferramentas como o JUnit (Java).

    Bons estudos!
  • http://blog.caelum.com.br/heranca-e-testes-unidade/

  • Teste de Unidade: Teste em um nível de componente ou classe. É o teste cujo objetivo é um “pedaço do código”.
    Teste de Integração: Garante que um ou mais componentes combinados (ou unidades) funcionam. Podemos dizer que um teste de integração é composto por diversos testes de unidade
    Teste Operacional: Garante que a aplicação pode rodar muito tempo sem falhar.
    Teste Positivo-negativo: Garante que a aplicação vai funcionar no “caminho feliz” de sua execução e vai funcionar no seu fluxo de exceção. 
    Teste de regressão: Toda vez que algo for mudado, deve ser testada toda a aplicação novamente.
    Teste de caixa-preta: Testar todas as entradas e saídas desejadas. Não se está preocupado com o código, cada saída indesejada é visto como um erro.
    Teste caixa-branca: O objetivo é testar o código. Às vezes, existem partes do código que nunca foram testadas.
    Teste Funcional: Testar as funcionalidades, requerimentos, regras de negócio presentes na documentação. Validar as funcionalidades descritas na documentação (pode acontecer de a documentação estar inválida)
    Teste de Interface: Verifica se a navegabilidade e os objetivos da tela funcionam como especificados e se atendem da melhor forma ao usuário.
    Teste de Performance: Verifica se o tempo de resposta é o desejado para o momento de utilização da aplicação.
    Teste de carga: Verifica o funcionamento da aplicação com a utilização de uma quantidade grande de usuários simultâneos.
    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).
    Teste de Volume: Testar a quantidade de dados envolvidos (pode ser pouca, normal, grande, ou além de grande).
    Testes de stress: Testar a aplicação sem situações inesperadas. Testar caminhos, às vezes, antes não previstos no desenvolvimento/documentação.
    Testes de Configuração: Testar se a aplicação funciona corretamente em diferentes ambientes de hardware ou de software.
    Testes de Instalação: Testar se a instalação da aplicação foi OK.
    Testes de Segurança: Testar a segurança da aplicação das mais diversas formas. Utilizar os diversos papéis, perfis, permissões, para navegar no sistema.

  • Para mim está errado afirmar que os testes unitários é inviável.