Home
Aqui você encontra tudo em softwares e aplicativos dos melhores fabricantes.
Ainda não é Cadastrado?
Clique Aqui e cadastre-se agora.
Softwares são fonte de bons negócios e ótima lucratividade, estamos cadastrando revendedores de todo Brasil.
Procuramos soluções para agregar ao nosso potifórlio e estamos prontos para distribuir os seus produtos e serviços à nossa base de clientes.
Teste de software
O teste do software é um processo realizado pelo testador de software que permeia outros processos da Engenharia de Software ,
e envolve ações que vão do levantamento de requisitos (necessidades)
até a execução do teste propriamente dito. O objetivo, por paradoxal
que pareça, é encontrar defeitos nos produtos, para que estes possam
ser corrigidos pela equipe de programadores, antes da entrega final. A
maioria das pessoas pensa que o teste de software serve para demonstrar
o correto funcionamento de um programa, quando na verdade ele é
utilizado como um processo da engenharia de software para encontrar
defeitos.
O processo de teste de software é voltado para o alcance de um nível
de qualidade de produto, que durante o processo de desenvolvimento de
software muda conforme avanço das atividadades - requisitos,
protótipos, modelo de dados lógico, modelo de dados físico,
código-fonte, módulos funcionais e finalmente um sistema.
O conceito de teste de software pode ser compreendido através de uma
visão intuitiva ou mesmo de uma maneira formal. Existem atualmente
várias definições para esse conceito. De uma forma simples, testar um
software significa verificar através de uma execução controlada se o
seu comportamento corre de acordo com o especificado. O objetivo
principal desta tarefa é encontrar o número máximo de erros dispondo do
mínimo de esforço, ou seja, mostrar aos que desenvolvem se os
resultados estão ou não de acordo com os padrões estabelecidos.
Introdução
Nem pode-se garantir que todos os programas funcionariam
corretamente, sem a presença de erros humanos, visto que os mesmos
muitas vezes possuem um grande número de estados com fórmulas,
atividades e algoritmos complexas. O tamanho do projeto a ser
desenvolvido e a quantidade de pessoas envolvidas no processo aumentam
ainda mais a complexidade.
Falhas podem ser originadas por diversos motivos, como os listados abaixo:
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 mas os atributos
qualitativos previstos na norma ISO 9126 que são: funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade.
Um desenvolvimento organizado de software 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. Esse é o campo de estudos da Qualidade de Software , uma sub-área da Engenharia de Software .
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 15504 e o mais conhecido CMMI .
Outro factor 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.
Técnicas de Teste
Atualmente 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 as três técnicas mais
conhecidas.
Caixa-Branca
Técnica de teste, também chamada de Teste Estrutural, que 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 e teste de caminhos lógicos. 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-se o código fonte e elaborando-se casos de
teste que cubram todas as possibilidades do componente de software.
Dessa maneira, todas as variações 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 (test cases) 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 a melhor performance 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 da Unidade e Teste da
Integração, cuja responsabilidade principal fica a cargo dos
desenvolvedores do software, que por sua vez conhecem bem o
código-fonte produzido.
Caixa-Preta
Técnica de teste, também chamado de Teste Funcional, em que o
componente de software a ser testado é abordado como se fosse uma
caixa-preta, ou seja, não se considera 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.
O componente de software a ser testado pode ser um método, uma
função interna, um programa, um componente, um conjunto de programas
e/ou componentes ou mesmo uma funcionalidade. A técnica de teste de
Caixa-Preta é aplicável a todas as fases de teste - fase de teste de
unidade (ou teste unitário), fase de teste de integração, fase de teste
de sistema e fase de 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 irá 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.
Outras Técnicas
Outras técnicas de teste podem e devem ser utilizadas de acordo com
necessidades de negócio ou restrições tecnológicas. Destacam-se as
seguintes técnicas: Teste de Performance, Teste de Usabilidade, Teste
de Carga, Teste de Stress, Teste de Confiabilidade e Teste de
Recuperação. Alguns autores chegam a definir uma técnica de Teste Caixa
Cinza, que seria um mesclado do uso das técnicas de Caixa Preta e Caixa
Branca, mas, como toda execução de trabalho relacionado à atividade de
teste utilizará simultaneamente mais de uma técnica de teste, é
recomendável que se fixem os conceitos primários de cada técnica.
Fases de Teste
Teste de Unidade
Também conhecida como Teste Unitário .
É a fase do processo de teste 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 os métodos dos objetos 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.
Teste de Integração
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 envio e recebimento de
dados. Por exemplo, um objeto A pode estar aguardando o retorno de um
valor X ao executar um método do objeto B, porém este objeto B pode
retornar um valor Y, desta forma 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 poderem ser testadas mesmo antes de o sistema estar
plenamente construído..
Teste de Sistema
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. 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 Aceitação
Fase de Teste em que o teste é conduzido por usuários finais do
sistema. Os testes são realizados, geralmente, por um grupo restrito 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 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 Operação
Fase de Teste em que o teste é conduzido pelos administradores do
ambiente final onde 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 e/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
backup e restore das bases 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.
Teste de Regressão
Teste de Regressão
é uma fase 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 ja 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. Para efeito de
aumento de produtividade e de viabilidade dos testes, é recomendada a
utilização de ferramentas de automação de testes, de forma que, sobre a
nova versão ou ciclo de teste, todos os testes anteriores possam ser
reexecutados com maior agilidade.
Testes Alpha, Beta e Gama
Em casos especiais de processos de desenvolvimento de software -
Sistemas Operacionais, Sistemas Gerenciadores de Bancos de Dados(SGBD),
e outros softwares comerciais disponibilizados no mercado 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 alpha e os testes executados nesse período, como testes
alpha. PRESSMAN afirma que o teste alpha é conduzido pelo cliente no
ambiente do desenvolvedor, com este “olhando sobre o ombro” do usuário
e registrando erros e problemas de uso.
Completada a fase alpha de testes, são lançadas a grupos restritos
de usuários, versões de teste do sistema denominadas versões beta. O
Teste Beta 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 alpha, o desenvolvedor geralmente não está presente.
Conseqüentemente, o teste beta é uma aplicação “ao vivo” 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.
Os testes Gama não são propriamente testes de software. A comunidade
do teste de software usa este termo de forma sarcástica referindo-se
aos produtos que são mal testados e são entregues aos usuários
("end-users") para que estes encontrem os defeitos já em fase de
produção.
Versões Candidatas (Release Candidates)
Ultimamente, e principalmente na comunidade de software livre, é comum utilizar o termo release candidate para indicar uma versão que é candidata a ser a versão final, em função da quantidade de erros encontradas.
As RC, como são chamadas, são um passo além do teste beta, sendo divulgadas para toda a comunidade.
Recursos Humanos
Líder do Projeto de Testes (ou Gerente de Testes)
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.
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).
Analista de Teste
É o técnico responsável pela operacionalização do processo de teste.
Deve seguir as orientações do gerente de teste e/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.
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 infra-estrutura que regem o ambiente. Ele
será responsável por tornar disponível o ambiente de teste.
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, bugs) 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.
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).
Papéis e Pessoas
Uma pessoa pode acumular mais de um dos papéis citados acima, 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.
Bibliografia
Ver também