Pular para o conteúdo principal

Níveis de Testes - Parte 3: Testes de Sistema

Seguindo com os quatro principais níveis de testes do ciclo de vida de um software, abordaremos agora o terceiro nível, Testes de Sistema:

1. Testes Unitários
2. Testes de Integração
3. Testes de Sistema
4. Testes de Aceitação

Nos próximos posts abordaremos os itens seguintes.

Testes de Sistema

Teste de sistema de um software, ou hardware, é todo teste conduzido em um sistema completo e integrado com o objetivo de avaliar se o sistema está em conformidade com os requerimentos especificados.

Como comparação podemos ilustrar uma comparação entre os Testes de Integração e os Testes de Sistema:

Pode-se dizer, de forma geral, que o propósito dos Testes de Integração é detectar qualquer inconsistência entre as unidades de software que funcionam em conjunto ou entre qualquer inconsistência entre essas unidades e o hardware.

No caso dos Testes de Sistema, trata-se de um nível de teste mais limitado; o propósito dos Testes de Sistema é procurar defeitos tanto nas unidades integradas quanto no sistema como um todo.

Testes de Sistema referem-se a um nível de teste investigativo, onde o foco do analista de testes é, por base, ter uma atitude destrutiva* - buscando falhas e seguindo fluxos alternativos - não apenas testando a interface, mas também o comportamento do sistema e também as respostas do sistema em teste em relação às expectativas do cliente (ou usuário final).



Os Testes de Sistema devem considerar o software dentro do seu sentido mais amplo, ou seja, tudo que interage com o software, por exemplo: outro hardware, outro software, usuários, entre outros. Tais testes correspondem também a uma série de procedimentos que têm por objetivo verificar se todos os elementos do sistema foram integrados adequadamente e realizam corretamente suas funções.

Em suma, podemos citar que os Testes de Sistema são responsáveis não só pela validação das funcionalidades de um sistema, mas também pela busca de falhas no mesmo, além da procura por discrepâncias do sistema em relação aos seus requisitos.

*Em outros posts abordaremos os conceitos de testes destrutivos e testes não-destrutivos que não são apenas relacionados a testes de software mas também a outros tipos de testes.

Comentários

  1. Muito interessante os conceitos de teste de sistemas e integração.

    Vou acompanhar de perto o blog.

    Abraço.

    ResponderExcluir

Postar um comentário

Postagens mais visitadas deste blog

Testes no RUP (Parte 2)

Em muitas organizações, os testes começam muito tarde no processo de desenvolvimento de um software. Muitas vezes, começam tão tarde que o produto é lançado com uma quantidade irrisória de testes executados. Para solucionar esse problema, muitas empresas estão começando a adotar testes como um 'mal necessário'. Como contraste a esse panorama, o RUP modifica a abordagem de testes, distribuindo a mesma no decorrer do ciclo de desenvolvimento do software, agregando valor ao invés de arcar com custos excessivos decorrentes da ausência de testes. No post anterior , justificamos a pergunta 'por que testar cedo e com frequência?' com o gráfico de custos. A seguir vocês podem ver um gráfico similar, retirado do site da IBM (detentora da metodologia RUP): Muitas pessoas ainda veem a disciplina de Testes como algo secundário, por que isso acontece? Talvez porque não esteja diretamente ligado ao desenvolvimento do software e por isso é muitas vezes deixado para o final, depois do

O + do FURPS+

Segue a continuação do assunto FURPS: Posteriormente à definição do modelo FURPS, notou-se a necessidade da inclusão de mais atributos para encorpar e aumentar a cobertura do modelo. A partir dessa extensão, o acrônimo passou a ser mais comumente chamado de FURPS+ . Quais são os atributos do “+”? O + do FURPS refere-se a especificação de restrições que definirão determinados limites que deverão ser atendidos quando construímos um sistema. O + é composto dos seguintes requisitos não-funcionais: Design constraints – restrições de design: design nesse caso refere-se ao projeto, diretrizes e não a layout. A definição da utilização um banco de dados relacional no projeto é uma restrição de design, por exemplo. Implementation constraints – restrições de implementação: relacionado a limites impostos a código e construções. Como exemplo podemos citar a linguagem de programação que será utilizada para a codificação de um sistema. Interface constraints – restrições de interface: diretamente l

FURPS

Olá! Nesse post, pretendo falar um pouco sobre o modelo FURPS para ilustrar atributos que estão envolvidos em Qualidade de Software : Vamos começar pela sigla FURPS: o que significa cada uma dessas letras? Do F temos Functionality, traduzimos como Funcionalidade: Representa basicamente os requisitos funcionais do sistema. Do U temos Usability, traduzimos como Usabilidade: Representa basicamente a interface sistema-usuário. Do R temos Reliability, traduzimos como Confiabilidade: Representa basicamente a eficiência e o índice de falhas do sistema. Do P temos Performance, traduzimos como Desempenho: Representa basicamente tempos de resposta e capacidade de processamento do sistema. Do S temos Supportability, traduzimos como Suportabilidade: Representa basicamente esforços necessários para manutenção e configuração do sistema. As definições acima representam o básico de cada uma das letras que compõem a sigla FURPS. A seguir entraremos em detalhes sobre cada uma das categorias, não ante