Anotações da disciplina

Prévia do material em texto

Teste de Software
Unidade 1
Fundamentos de teste de software
	O que podemos entender sobre teste? Segundo Sommerville (2011, p. 144), o teste tem a função de mostrar as funcionalidades de um programa e encontrar possíveis falhas no momento anterior ao seu uso. No momento em que o software é testado, o programa é executado, e os resultados almejados visam a encontrar erros ou informações de requisitos não funcionais pertencentes a ele.
	O desenvolvimento de sistemas de software requer um conjunto de ações ligadas à criação, na qual possíveis erros humanos poderão ficar em evidência. As falhas tendem a surgir no início do processo, pois os objetivos determinados podem estar erroneamente especificados, além de erros posteriores nas etapas de projeção e de desenvolvimento. Estas possibilidades fazem com que o desenvolvimento de software esteja ligado à garantia de sua qualidade (PRESSMAN, 1995, p.786). 
	As atividades ligadas aos testes de software são consideradas elementos críticos da garantia de qualidade e simbolizam a análise mais recente de especificação, projeção e codificação.
O pensamento que devemos ter em relação ao desenvolvimento de software é que a atividade de teste exige descartar e superar uma série de conflitos que possam surgir quando as falhas são observadas.
Quando observamos os objetivos da atividade de teste, Myers (1990 apud PRESSMAN, 1995, p. 788) define um conjunto de normas que servem de objetivos.
A primeira norma determina que a atividade de teste deve ser vista como um processo capaz de executar um programa com o objetivo de encontrar erros. Na visão de Sommerville (2011, p. 145), este processo de teste visa também expor tanto a profissionais de desenvolvimento quanto a clientes que o produto software consegue atender suas solicitações. Para os softwares considerados “customizados” haverá ao menos um teste destinado a cada requisito, pertencente ao documento de requisitos. No caso dos chamados softwares “genéricos”, haverá testes para todos os aspectos do sistema, além das combinações estabelecidas, inseridas ao release do produto. Estes são exemplos de testes de validação, pelos quais o sistema é executado de maneira adequada, adotando uma série de casos de teste que simbolizam a utilização prevista pelo sistema.
Outra regra considera que um bom caso de teste apresenta probabilidade elevada de expor uma falha, mesmo que ainda não tenha sido revelada. Sommerville (2011, p. 144) frisa ainda que cabe ao teste de software observar possibilidades do software de se apresentar de forma incorreta e distinta das especificações definidas. Cabe aos testes de defeito eliminar os comportamentos inadequados do sistema.
Outro aspecto que devemos frisar é o fato do teste fazer parte de um extenso processo de verificação e validação (V&V), que tem o objetivo de verificar se o software em desenvolvimento consegue atender às suas especificações e disponibilizar a funcionalidade aguardada por quem usará o software.
Esse processo começa quando as solicitações estão disponíveis, e se mantém em todas as etapas do processo de desenvolvimento.
A verificação visa checar se o software consegue suprir as suas necessidades funcionais e não funcionais. Para Sommerville (2011, p. 145) a validação é um processo mais generalista, cuja função é assegurar que o software consiga suprir as necessidades de clientes. A validação é fundamental, pois as especificações de requisitos nem sempre suprem as demandas dos usuários do sistema.
Os processos de verificação e de validação têm o objetivo de determinar um nível de confiança garantindo que o software atenderá seus propósitos. O sistema precisa ser, dentre outros aspectos, das expectativas dos usuários.
A finalidade do software está relacionada ao seu nível de confiança, necessário para um software ser utilizado no sistema, atingir as expectativas de usuários, que já se acostumaram, de certa maneira, aos erros presentes no sistema, porém, com o amadurecimento do software, esperam que sejam realizados testes mais completos nas versões posteriores.
O processo de verificação e validação (V&V) inclui inspeções e revisões responsáveis por avaliar e observar, dentre outros aspectos, os atributos do sistema. Podemos considerar estes aspectos como as chamadas técnicas “estáticas’” de V&V, que se caracterizam pelo fato de o usuário não ter a necessidade de executar o software para analisá-lo.
É preciso compreender que as inspeções se concentram no código-fonte de um sistema, principalmente; entretanto, seus requisitos ou modelos de projeto, de fato, podem ser inspecionados.
Segundo Sommerville (2011, p. 147), podemos observar basicamente três vantagens ou benefícios de utilizar a inspeção de software em relação aos testes:
· No momento em que os testes são realizados, possivelmente alguns erros poderão impedir a visualização de outros erros.
· Existe a possibilidade de as versões incompletas de um sistema serem inspecionadas sem o acréscimo de custos. Caso um programa se encontre incompleto, é preciso criar mecanismos de testes específicos para realizar as análises das partes que se encontram disponíveis.
· Além de ter a função de encontrar falhas em um programa, uma inspeção se caracteriza por levar em consideração outros requisitos de qualidade inerentes a um programa, como a portabilidade e a manutenibilidade (SOMMERVILLE, 2011, p.147).
As inspeções não substituem os testes de software tradicionais. As inspeções não são adequadas, por exemplo, para encontrar falhas oriundas de interações realizadas em partes diferentes de um programa.
Os casos de teste são conceituados como especificações presentes nas entradas do teste e da saída prevista pelo sistema. Além disso, é possível obter uma declaração dos componentes que estão sendo testados. É possível verificar que os dados de teste representam as entradas geradas para a realização dos testes no sistema, porém a execução destes testes pode ocorrer de forma automatizada. Os resultados previstos serão os resultados alcançados de forma automatizada, o que dispensa a busca por falhas na execução dos testes.
Duas classes de entrada são disponibilizadas durante os processos de teste: a primeira classe trata da configuração de software, que insere uma especificação de requisitos de software, especificação do projeto, além do código-fonte; a segunda classe simboliza uma configuração de teste que se caracteriza por inserir um plano e um procedimento referente aos testes, além das ferramentas que serão empregadas e seus casos de testes com os resultados almejados. Uma configuração de teste é compreendida como um subconjunto pertencente à configuração de um software (PRESSMAN, 1995, p. 789).
O processo de depuração trata da imprevisibilidade no processo de teste. Para se ter uma ideia, uma possível falha que indique um nível de discrepância entre os resultados desejados e os reais pode levar um tempo considerável para ser identificado e solucionado.
Quando se fala em desenvolvimento de software, não podemos esquecer de mencionar o projeto de casos de testes. O projeto de teste de software pode ser visto como um desafio, assim como o projeto elaborado inicialmente do próprio produto. Entretanto, assim como já visualizamos, as atividades de testes são tratadas por boa parte de profissionais de engenharia de software como uma espécie de análise tardia ao criar casos com resultados previsíveis e de baixa garantia de totalidade. As atividades de teste visam projetar, dentre outros aspectos, testes com elevada capacidade de descoberta de erros em tempo e com esforço mínimos.
Segundo Pressman (1995, p. 791), independentemente do produto ou serviço projetado pelo engenheiro ou engenheira de software, as duas formas de testá-lo são: tendo conhecimento da função determinada que precise realizar o produto ou serviço, sobre o qual os testes podem ser executados para comprovar que cada função é feita operacionalmente; e conhecendo como funciona internamente um produto, permitindo que os testes sejam realizados para assegurar que a operaçãointerna do produto apresente um comportamento adequado às suas especificações.
Neste contexto, vamos nos deparar com duas conceituações referentes à abordagem de teste: o teste de caixa preta e o teste de caixa branca.
o termo “teste de caixa preta” trata dos testes feitos dentro das interfaces de um software. Este teste tem o objetivo de localizar possíveis erros, porém, além desta funcionalidade, ele é empregado para comprovar que as funções atribuídas aos softwares são operacionais, ou seja, a entrada é aceita de maneira adequada assim como a saída produzida corretamente, além de garantir a integridade das informações de origem externa. Este modelo de teste, contudo, não precisa necessariamente a estrutura lógica interna do software que venha a ser adotada.
O teste em si é um processo de input e análise de output. O teste, na prática, envolve pensar em quais são os inputs que podem estimular possíveis rotinas com defeitos para conseguir analisar o resultado no final e descobrir quais são os defeitos a serem corrigidos.
Para testar uma aplicação é necessário saber apenas os requisitos dela, podendo até ser escrito antes do código.
Desenvolvimento de software e teste de software
Normalmente, um projeto trata da criação de um produto ou serviço. Se associarmos este conceito ao desenvolvimento de um software, perceberemos que este produto é intangível e que apresenta uma série de variações complexas, o que dificulta sua criação e qualificação.
Um processo relacionado ao de desenvolvimento de software é definido como uma série de atividades padronizadas e organizadas, que estabelecem, desenvolvem, avaliam e mantêm um software. Por sua vez, objetiva, dentre outros aspectos, determinar as atividades a serem realizadas, o momento em que elas serão executadas, quem irá realizar estas tarefas e qual o nível de padronização adotado ao longo do desenvolvimento de um software.
A primeira atividade a ser realizada é de levantamento de requisitos, que tem como objetivo ter uma noção geral do problema, a partir do qual profissionais e usuários vão compartilhar visões para a solução do problema encontrado.
A fase seguinte consiste na análise de requisitos, também conhecida como especificação de requisitos. É neste momento que profissionais irão avaliar detalhadamente os dados coletados na fase anterior e começar a desenvolver modelos que simbolizem o sistema de software que será desenvolvido. Compreender de maneira total os requisitos de software é essencial para um desenvolvimento de software bem feito. Segundo Pressman (1995, p. 231), não importa se um programa é bem projetado ou codificado se ele for mal avaliado ou especificado, pois isso trará uma série de problemas a quem o desenvolve. A análise de requisitos de software, para uma melhor conceituação, pode ser divida em cinco subáreas. Segundo Pressman (1995, p. 232), elas são: identificação de problema, avaliação e síntese, modelagem, especificação e revisão.
Chegamos à etapa na qual é possível visualizar como o sistema irá funcionar internamente, visando atender os requisitos de clientes. É o passo inicial para realizar o desenvolvimento de qualquer produto ou sistemas ligados à engenharia. Nesta etapa, devemos levar em consideração alguns aspectos essenciais, tais como a arquitetura do sistema, a linguagem de programação adotada, as características do sistema gerenciador de banco de dados (SGBD) utilizado, entre outros. É no projeto que a descrição computacional é apresentada e o usuário fica sabendo o que o software deverá realizar, lembrando que esta descrição deve estar alinhada com a descrição executada na análise de requisitos.
Segundo Pressman (1995, p. 415), o objetivo de qualquer projetista é criar modelos ou simbolizar qualquer um que seja desenvolvido posteriormente. Vale ressaltar que o procedimento pelo qual o modelo é criado é fruto de uma combinação que envolve alguns aspectos, como:
· Intuição e análise com base na experiência de desenvolver entidades parecidas;
· Princípios que norteiam a forma pela qual o modelo é desenvolvido;
· Critérios que permitam que a qualidade seja avaliada;
· Interação que leve a uma representação do projeto final.
Os conceitos relacionados à engenharia de software abrangem tarefas relacionadas à criação de software, dos requisitos, até o gerenciamento do sistema instalado. Dentro deste contexto, a fase considerada mais crítica neste processo se refere à implementação do sistema, que é responsável por criar uma versão executável do software. Segundo Sommerville (2011, p. 135), a implementação aborda o desenvolvimento de programas, independentemente do nível de linguagens de programação utilizado. Nesta fase, o sistema será codificado, levando em consideração a descrição computacional da etapa do projeto, inserido em outra linguagem, na qual é permitido compilar e gerar o código executável, visando o desenvolvimento do software.
De acordo com Sommerville (2011, p. 136), determinados aspectos referentes à implementação são essenciais para a engenharia de software, e que geralmente não são abordados em textos de programação. São eles:
· Reuso: Os softwares mais modernos são formados através do reuso de elementos existentes ou por conta dos sistemas. No momento em que um software for desenvolvido, é preciso utilizar, de maneira extensiva, os códigos já existentes;
· Gerenciamento de Configuração: Ao longo do processo de desenvolvimento, são desenvolvidas versões diferentes de cada elemento de software. Caso o usuário não acompanhe as versões inseridas no sistema de gerenciamento de configuração, certamente haverá a possibilidade de inserir versões errôneas destes elementos dentro do sistema;
· Desenvolvimento Host-Target: A criação de um software geralmente não executa no mesmo computador como no ambiente de desenvolvimento de software. É preciso desenvolver em um computador (o sistema host) e executar em outro (o sistema target). Os sistemas host e target apresentam normalmente o mesmo modelo, porém por diversas vezes são distintos.
Quando tratamos de implementação, é preciso falar de projeto orientado a objeto. A fase de projeto orientado a objeto detalhado (Object-Oriented Design – OOD) é parecido com os projetos de detalhes que utilizam qualquer metodologia de projeto de software.
Várias atividades de testes são realizadas com o intuito de validar o produto de software. Isso ocorre quando testes são executados a cada funcionalidade pertencente aos modelos, considerando a especificação realizada na etapa de projeto. O relatório de testes é o resultado mais imediato, pois apresenta um conjunto de informações importantes sobre as falhas visualizadas no sistema além da sua performance em diversos.
Normalmente, um sistema de software disponibilizado comercialmente atinge três níveis ou estágios de testes, sobre os quais trataremos com maior detalhamento nas seções posteriores. São eles:
· Teste de Desenvolvimento: Com os quais o sistema é avaliado para buscar defeitos ou bugs ao longo do processo de desenvolvimento, e se caracteriza por incluir projetistas, programadores e programadoras neste processo;
· Teste de Release: Com os quais uma equipe independente de análise realiza testes no sistema antes de disponibilizá-lo ao cliente final, observando se o sistema consegue suprir as solicitações dos stakeholders de sistema;
· Teste de Usuário: Com os quais os usuários são responsáveis por testar o ambiente dentro do seu próprio ambiente. Os chamados testes de aceitação são considerados um modelo de teste do usuário com que clientes avaliam de maneira formal o sistema, para definir se ele será aceito por quem o fornecerá ou se será preciso desenvolvimento incremental.
Segundo Sommerville (2011, p. 147), o teste manual se caracteriza pelo fato do avaliador ou avaliadora executar o programa utilizando um conjunto de dados de teste e comparar os resultados obtidos com as suas previsões, a quem cabe verificar e informar as possíveis distorções aos desenvolvedores do programa. Já os testes automatizados se caracterizam pelofato de os testes estarem codificados em programas executados toda vez que houver testes realizados em sistemas em desenvolvimento.
Níveis de Teste
Os testes são inseridos em destinos diferentes, em estágios distintos ou em níveis que exigem certo esforço de trabalho. Normalmente, esses níveis se diferenciam por conta destas funções, que são habilitadas de maneira mais efetiva para conduzir e projetar testes, nos quais as técnicas utilizadas são mais apropriadas para testes de cada nível.
Teste de desenvolvimento
Esta modalidade de teste se caracteriza por incluir todas as atividades de testes executadas pela equipe responsável pelo desenvolvimento do sistema. Normalmente, o responsável pelo teste do software é o próprio programador ou programadora que o criou. Segundo Sommerville (2011, p. 148), ao longo do desenvolvimento, o teste pode ser executado basicamente em níveis de detalhamento: testes unitário, de componentes e de sistema. Verificaremos cada um deles.
Teste unitário
O teste unitário é o primeiro nível, e se caracteriza pelo fato dos elementos de programa ou até mesmo as classes de objetos serem avaliadas de maneira individualizada. Esta modalidade de teste foca na verificação da funcionalidade dos objetos ou da metodologia adotada. Para Sommerville (2011, p. 149), um teste automatizado consiste basicamente em três partes: a da configuração, na qual o usuário dá início ao sistema com o caso de teste, indicando as entradas e saídas previstas; a chamada, que se caracteriza pelo fato do usuário chamar o objeto ou o método que será testado; e a afirmação, em que o usuário estabelece comparações do resultado da chamada com o resultado previsto, ou seja, se a afirmação analisada for considerada verdadeira, podemos considerar o teste bem-sucedido. Caso contrário, o teste será considerado falho.
É preciso, então, redigir dois modelos de casos de teste: um que represente o funcionamento habitual do programa do componente; e outro que tenha como referência os testes de experiência, dos quais aparecem problemas mais cotidianos.
· Teste de Partição: No qual é possível reconhecer os grupos de entradas que apresentam aspectos comuns e que recebem o mesmo tratamento. É necessário que o usuário selecione os testes em cada um desses grupos;
· Teste com base em diretrizes: As quais o usuário utiliza para selecionar casos de teste. Tais diretrizes indicam a experiência anterior dos tipos de erros normalmente cometidos pelos programadores no momento de desenvolver componentes.
Teste de componente
Outra subdivisão dos testes de desenvolvimento consiste nos chamados “testes de componentes”, nos quais diversas unidades individuais passam a ser integradas para desenvolver elementos compostos de diversos objetos que interagem. Os testes de componentes compostos precisam estar centrados em apresentar o comportamento da interface de componente, que deve estar alinhado a sua especificação, lembrando que o usuário pode assumir que os testes unitários aplicados nos objetos individuais já foram finalizados dentro do componente.
Certamente você pode deduzir que existe uma variedade de interfaces entre os componentes de programa. A primeira interface que podemos tratar são as interfaces de parâmetro, em que as referências de dados ou funções são transmitidas entre os componentes. É possível observar também a interface de memória compartilhada, na qual um bloco de memória é partilhado entre componentes, sendo que os dados são inseridos na memória através de um subsistema e podendo ser recuperado por outros.
Também não podemos deixar de citar as interfaces de procedimento, nas quais um componente encapsula uma série de processos, que podem posteriormente ser chamados por outros componentes. 
Por fim, temos a interface de passagem de mensagem, em que um componente faz a requisição de serviço de outro enviando-lhe uma mensagem. Lembrando que uma mensagem de retorno abrange resultados da execução de um serviço.
Diversas interfaces podem gerar diferentes tipos de erros de interface, que são as formas mais comuns de erros em sistemas complexos. Os erros podem ser provenientes, por exemplo, do mau uso da interface, no qual um componente chamador chama outro e comete uma falha na utilização da sua interface.
Teste de sistema
Esta modalidade de teste analisa se existe compatibilidade entre os componentes, se há uma interação adequada entre eles e se conseguem transferir dados assertivos em momento propício através de suas interfaces.
No momento da realização do teste de sistema, por exemplo, pode haver uma integração dos componentes reusáveis criados separadamente e os chamados “sistemas de prateleira”, juntamente com os componentes desenvolvidos recentemente. Nesta condição, o sistema completo será testado. Outro aspecto importante é que, nesta fase, os componentes criados por membros distintos do grupo poderão ser de fato integrados.
Teste de release
Um segundo estágio de teste de software é o teste de release, que, segundo Sommerville (2011, p. 157), consiste no ato de testar um release privativo de um sistema para ser utilizado fora da equipe de desenvolvimento, ou seja, o que normalmente é para clientes e usuários.
Basicamente, existem duas distinções importantes entre os testes de release e os testes de sistema ao longo do processo de desenvolvimento: primeiramente, a equipe responsável pelo teste de release é aquela que não esteve presente no processo de desenvolvimento do sistema. A segunda distinção é que os testes de sistema realizados pela equipe de desenvolvimento são centralizados na busca por bugs no sistema, os chamados “testes de defeitos”. Isso indica que o objetivo do teste de release é analisar se o sistema consegue suprir os seus requisitos e se ele é bom para o uso externo.
O processo de teste de release visa persuadir o fornecedor sobre a qualidade do sistema. Se isto de fato for uma condição verdadeira, o sistema pode ser apresentado como um produto ou até mesmo disponibilizado a clientes, desde que ofereça níveis de funcionalidade, desempenho e confiança determinados.
Testes baseados em requisitos
Os requisitos precisam ser testáveis, ou seja, o requisito precisa ser redigido de tal maneira que um teste seja planejado para ele. Nesta condição, o indivíduo responsável pelos testes irá observar se o requisito foi de fato atendido. Os testes que se baseiam em requisitos, portanto, são considerados uma abordagem sistemática destinada aos projetos de casos de teste, de que o usuário considera cada requisito e cria uma série de testes para eles.
Testar um requisito não se trata apenas de escrever um único teste. Geralmente, é preciso redigir diversos testes para assegurar a cobertura dos requisitos, em que é preciso manter registros de rastreabilidade dos testes que se baseiam em requisitos, que unem os testes aos requisitos específicos.
Teste de cenário
Podemos entender que o teste de cenário é uma abordagem de teste de release no qual o usuário idealiza cenários para auxiliarem no desenvolvimento de casos de teste direcionados ao sistema.
Cenários devem ser realistas, e usuários reais do sistema devem ser capazes de se relacionar com eles. Um teste de cenário deve, dentre outros aspectos, estabelecer uma relação entre os stakeholders e acreditar na importância do sistema ser aprovado no teste. Estes testes precisam ser de fácil avaliação e, na ocorrência de problemas com o sistema, a equipe responsável precisa identificá-los.
Teste de desempenho
Os testes de desempenho são projetados para garantir que o sistema processe as atividades destinadas a ela. Assim como ocorre na execução de outros testes, os testes de desempenho normalmente demonstram que o sistema consegue atender os seus requisitos, no que se refere à localização de problemas e falhas no sistema. 
Trata-se de uma série de testes que indicam a combinação efetiva de trabalho manipulado pelo sistema. A maneira mais eficiente de encontrar os defeitos é projetando testes até os limites sistêmicos. É o que denominamos dentro dos testes de desempenhocomo “estressar o sistema” ao realizar demandas que se encontrem além dos limites de projeto do software.
	Este “teste de estresse” normalmente apresenta uma dupla funcionalidade: primeiro, é testar o comportamento de falha do sistema. Vale ressaltar que as circunstâncias podem aparecer através de uma combinação esporádica de situações, em que a carga exercida sobre o sistema ultrapassa a carga prevista. Diante deste cenário, é essencial que os erros do sistema não corrompam os dados ou causem perdas de serviços do usuário.
	A outra função é causar certo nível de “estresse” ao sistema para apresentar defeitos que geralmente não são revelados.
Para o entendimento de Sommerville (2011, p. 159), os testes de estresse são importantes para sistemas distribuídos que se baseiam em redes de processadores.
Teste de usuário
O teste de usuário é considerado um estágio em que usuários ou clientes disponibilizam entradas e conselhos sobre o teste de sistema. 
Ele é fundamental, mesmo que a sua atuação ocorra em sistemas abrangentes ou até mesmo quando os testes de release tenham ocorrido. Isso ocorre por conta das interferências no ambiente corporativo do usuário que impactam, por exemplo, a confiabilidade e o desempenho de um sistema.
Os testes de usuário são subdivididos em:
· Teste alfa: Pelo qual os usuários do software atuam em paralelo com a equipe de desenvolvimento para realizar testes no software dentro do local do desenvolvedor;
· Teste beta: Pelo qual o release do software fica disponível aos usuários para ser testado, além dos problemas encontrados pelos desenvolvedores do sistema;
· Teste de aceitação: Ao final, pelo qual clientes realizam testes no sistema, visando a decidir a aceitação pela equipe de desenvolvimento de sistemas e posteriormente serem implantados dentro do ambiente de clientes.
Nos testes alfa, os usuários e os desenvolvedores atuam conjuntamente para realizar testes em um sistema desenvolvido. Já no teste beta vamos observar que o mesmo acontece quando um release antecipado de um sistema de software fica disponível a clientes-usuários para que seja avaliado. O teste beta é fundamental para verificar os problemas que envolvem a interação entre o software e os aspectos do ambiente no qual este produto é utilizado. Por fim, há o teste de aceitação, que, segundo Sommerville (2011, p. 160), é a parte considerada no desenvolvimento de sistemas mais customizados, que normalmente ocorre depois do teste de release. Ele aborda o teste formal de um sistema através de um usuário para verificar a sua aceitação.
	
Unidade 2 – Classificação de teste de software
Técnicas de teste de software
Embora muitas empresas acreditem que isso gere um custo desnecessário, é necessário utilizar testes de software, a fim de evitar prejuízos nas empresas. Apresentaremos, então, técnicas para testar os aplicativos. Normalmente, separa-se os testes em duas classes de técnicas, a técnica de teste de caixa-preta e a técnica de teste de caixa-branca. Existem, ainda, os testes de caixa-cinza, que muitos definem como teste de caixa-preta e branca.
TÉCNICAS DE TESTE DE SOFTWARE CAIXA-PRETA
	
Nos testes de caixa-preta, o testador não acessa os códigos, tampouco analisa o ambiente interior do código. Nesse tipo de teste, a análise ocorre somente na interface externa.
Pode-se dizer o teste de caixa-preta abrange os níveis mais externos de teste, pois consiste em uma análise da interface visual, e não do código. Veja, a seguir, os exemplos de erros que os testes de caixa-preta avaliam:
· O programa possui campos de texto de formulário marcados como obrigatórios, mas não obriga o usuário a preenchê-los;
· O software possui campos de opção sim ou não, mas permite que o usuário ative tanto o sim quanto o não simultaneamente;
· O programa permite campos de datas de nascimento com datas futuras;
· O sistema aceita valores campos de número, como quantidade e idade, negativos;
· Botões de mudança de tela não levam à tela correta;
· Existem NullPointers, ou seja, botões que não funcionam, links vencidos etc.
Já que essa técnica analisa os códigos externos, ela abrange os níveis mais externos, ou seja, o programa por fora. Os níveis mais externos são: de integração, de sistema, de aceitação, teste alfa e teste beta.
TÉCNICAS DE TESTE DE SOFTWARE CAIXA-BRANCA
	
Nos testes de caixa-branca, o testador acessa os códigos e analisa seus erros. Os testes de caixa-branca podem ser de dois tipos e ter os seguintes subtipos:
· Cobertura lógica;
· Cobertura de decisões;
· Cobertura de condições;
· Método dos caminhos básicos.
Cobertura lógica de decisões e condições testam as estruturas de tomada de decisões e espaços sem programação, onde usuários não conseguem realizar algumas opções, como por exemplo, não conseguir voltar para uma determinada página. Quando isso ocorre, dizemos que as condições não estão totalmente acobertadas, ou seja, existem espaços nulos no sistema.
De acordo com os autores Pressman e Maxim, que publicaram o livro Engenharia de software: uma abordagem profissional, em 2016:
Os testes caixa-branca focam a estrutura de controle do programa. São criados casos de teste para assegurar que todas as instruções do programa foram executadas pelo menos uma vez durante o teste e que todas as condições lógicas foram exercitadas (p. 520).
O método dos caminhos básicos tem por objetivo fazer com que o programa tenha caminhos rápidos entre o comando do usuário e a saída na tela. A vantagem desse método é simplificar o código, uma vez que, quanto mais simples e objetiva for a sequência de ações, mas fácil será sua alteração.
O método de caminhos básicos realiza testes para avaliar a qualidade dos fluxos através das seguintes ações:
· Testar todos os caminhos do programa pelo menos uma vez;
· Testar todas as condições de falso e verdadeiro;
· Descobrir se o programa possui caminhos redundantes.
Recomenda-se começar pelos testes de caixa-preta e, depois, passar para os de caixa-branca.
Tipos de teste de software
Existem alguns tipos de teste de software e cada tipo pode pertencer à técnica caixa-branca, à caixa-preta ou às duas caixas. Pode-se antecipar que, neste momento, abordaremos os seguintes tipos:
· Teste de funcionalidade;
· Teste de desempenho;
· Teste de funcionalidade;
· Teste de segurança;
· Teste de configuração;
· Teste de falhas e recuperação;
· Teste de carga ou de estresse.
Já vimos até agora o que são níveis de teste, técnicas de teste e agora veremos os tipos de teste. Os níveis correspondem à abrangência do teste (unidade, integração, sistema, aceitação, alfa, beta e regressão), as técnicas correspondem ao modelo de abordagem interno ou externo (caixa-branca e caixa-preta).
O teste de funcionalidade verifica se o programa está funcionando normalmente, checando as seguintes dúvidas: o e-mail está conseguindo receber e enviar mensagens? O botão de gravar está enviando os dados ao banco de dados? A opção de salvar está funcionando? O programa permite salvar dados sem ao menos o usuário digitar? O jogo pode ser pausado e reiniciado do ponto onde estava? Dessa forma, o teste é realizado sob a ótica do usuário final.
O teste de desempenho verifica eficiência do programa, isto é, o tempo gasto. Para realizar tarefas, por exemplo, o tempo gasto para enviar um e-mail, o tempo gasto para fazer uma transferência, o tempo gasto para um robô responder o chat, o tempo gasto para fazer uma transferência, tempo de postagem de fotos na rede social etc. O tempo afeta diretamente a qualidade do uso do software e os usuários podem ficar insatisfeitos caso o sistema esteja muito lento.
O teste de usabilidade serve para testar a experiência. Muitos autores definem usabilidade com a utilidade, ou seja, quão útil é um sistema. Logo, de nada adianta ter um programa muito bonito e, ao mesmo tempo, inútil. Sendo assim, é importante descobrir as necessidades do cliente ou da empresa que irá usar esse programa. Outro ponto fundamental é a escolha de cores, leiautes e logo, uma vez que ele deve ter uma aparência agradável. No aspectoestético, a navegação deve ser intuitiva e divertida.
O teste de segurança avalia se o sistema tem vazamento de dados ou ausência de criptografia. Há empresas que contratam hackers para tentar achar brechas no sistema operacional e, então, descobrir as falhas do sistema.
O teste de configuração é útil para descobrir se o software funciona do mesmo jeito em outros sistemas operacionais e em outros aparelhos e máquinas. Um sistema deve ser adaptável, isto é, deve funcionar em vários sistemas e computadores diferentes. Por isso, é muito importante testar não apenas a instalação, como também o comportamento do programa em máquinas de memória interna e em discos com tamanhos diferentes.
O teste de estresse ou de carga coloca o programa em situações extremas. Por exemplo, imagine que muitos usuários acessam um sistema ao mesmo tempo, ou então que muitas pessoas estão usando a rede da empresa ao mesmo tempo; essas situações devem ser simuladas para saber até que ponto o sistema suporta tais cargas. Além disso, outras situações devem ser testadas, como a operação do software em um sistema com pouca memória ou com ausência de recursos compartilhados.
O teste de falhas e recuperação avalia se o software consegue salvar os dados caso haja uma queda de energia ou de rede. Essa queda pode ocorrer no cliente e no servidor, por isso, o teste de falhas deve avaliar se os programas guardam as últimas operações. Uma ação importante que os softwares precisam avaliar é a sincronização do aplicativo no computador local com a nuvem, por exemplo, avaliar se as fotos do celular são armazenadas na nuvem em forma de backup diariamente. Técnicas como desligar o computador no meio de um processo, desligar o servidor sem salvar um arquivo ou desligar a rede em uma transação ajudam a avaliar se o sistema está protegido.
Sintetizando
	Com o objetivo em nos aproximar da prática, essa Unidade abordou a utilidade do teste de software. Desse modo, foi dito que é recomendável gastar uma fatia de tempo e dinheiro para fazer testes, pois muitas vezes a falta de testes pode resultar em problemas com o público-alvo e necessidade de refazer o código. 
Falamos, também, sobre as técnicas de teste de software. Nesee contexto, dividimos a classe "teste de software" em "classe caixa-branca" e "classe caixa-preta". A caixa-branca analisa o programa internamente, ou seja, analisa o código, verificando se ele possui algum erro de cobertura ou de condição. 
Erros de cobertura fazem com que o código despreze alguma situação, por exemplo, o programa pode não calcular o frete para um dos estados cadastrados no sistema. Já erros de condição lógica fazem um caminho errado, por exemplo, após clicar no botão adicionar, o sistema multiplica. Cabe ressaltar que a caixa-branca avalia o código em si e a caixa-preta, por outro lado, é um teste que avalia o programa externamente, do ponto de vista de usuário. Assim, foi visto que o teste de caixa-preta é feito em níveis de testes externos do programa, como testar se botões estão levando à tela certa, se tem algum problema na hora de preencher formulários etc. 
Como foi visto, existem vários tipos de teste de software, vimos que o teste de funcionalidade verifica se o programa funciona bem, e que o teste de usabilidade avalia a experiência do usuário. Além disso, vimos que o teste de estresse avalia como o programa se comporta caso muitos usuários acessem o mesmo recurso ao mesmo tempo e que o teste de falhas e recuperação que avalia como o programa salva os dados caso acabe a energia ou a internet. Para concluir, vimos que o teste de segurança avalia se há brechas no sistema e também aprendemos sobre a utilidade dos testes de desempenho e de configuração.
Vimos, também exemplos, práticos de rotinas de testes no Excel e operações de testes do programa Eclipse, através da linguagem Java, o que é muito importante para profissionais que desejam fazer testes que checam se as funções de igualdade e de cálculo funcionam corretamente. Para isso, abordamos a forma de instalar o Eclipse, bem como a criação de um exemplo prático de teste com a função assertEquals; esse documento teve como objetivo preparar o profissional para adentrar no mundo dos testes, que usa, com bastante frequência, a extensão JUnit.
Unidade 3 – Casos de testes: conceitos fundamentais
Extração de casos de teste
Podemos considerar a especificação das expectativas criadas por um investidor como um aspecto que interfere significativamente na capacidade de equipes de projeto de garantir suas solicitações em relação ao software.
Mesmo sem a definição destas especificações de requisitos, os casos de teste são métodos capazes de auxiliar a formação das expectativas que os investidores criam, possibilitando que elas sejam analisadas e validadas.
A equipe responsável pelos testes precisa planejá-los, de modo que os requisitos sejam validados apropriadamente no momento em que um conjunto de requisitos se encontre disponível. A validação do software em comparação aos requisitos é realizada de maneira distinta, a depender do modelo de requisito.
Para tratarmos da extração de casos de teste, precisamos entender que um caso de teste tem a finalidade imediata de solucionar um questionamento: o que vamos testar? O usuário do sistema desenvolve um caso de teste visando estabelecer o que será validado, para assegurar o funcionamento correto aliado a um nível de qualidade elevado. Dentro desse contexto, um conceito devemos entender: o de suítes de teste, que consiste na coleção de casos de teste agrupados para executá-los.
Os modelos de processos precisam ser detalhados em nível elevado, para que as regras de extração dos testes sejam aplicadas, permitindo o destaque dos componentes operacionais de cada atividade do processo. Tais regras podem ser implementadas a partir da aquisição de requisitos candidatos, que se baseiam basicamente em três passos:
· Seleção de atividades: É a seleção das atividades que podem ser realizadas pelo sistema, por indivíduos que o utilizam, ou através de atividades manuais passíveis de automatização. As atividades classificadas como manuais e que não forem consideradas para a automatização serão descartadas, por não possuírem os requisitos determinados;
· Identificação dos requisitos candidatos: Consiste na fase em que os modelos de processos relacionados aos negócios são avaliados considerando uma série de heurísticas, que são responsáveis por analisar a estrutura e a semântica dos modelos de processos;
· Consolidação de requisitos candidatos: Consiste na fase em que os requisitos candidatos observados na etapa anterior são analisados, e são geradas informações referentes, por exemplo, aos sistemas que poderão invocá-los.
A análise da estrutura está baseada em padrões de workflow e supre todas as possibilidades existentes de fluxos de atividades simbolizadas por um modelo de processo. Em relação à avaliação semântica, podemos levar em consideração os componentes pertencentes aos modelos, como o requisito de negócios. A semântica destes elementos vai apontar as funcionalidades implementadas nos serviços que apoiam o processo.
No momento posterior à identificação dos requisitos candidatos, existe a possibilidade de estabelecer a extração dos casos de teste, através dos seguintes procedimentos:
· Definir a modelagem dos processos de negócio;
· Aplicar os métodos de identificação de requisitos;
· Determinar os casos de teste por métodos de criação de casos de teste utilizados em outros modelos.
Neste terceiro passo, as heurísticas que visam à aquisição dos casos de teste são utilizadas (SOUSA et al., 2014). Vamos ver quais regras são utilizadas.
· Heurísticas de requisitos básicos (HRB):
· HRB1: Um requisito candidato deve ser identificado da regra de negócio;
· HRB2: Um requisito candidato precisa ser identificado para cada informação de entrada de uma tarefa (requisito de leitura). Da mesma maneira, um requisito candidato de dado precisa ser identificado para cada informação de saída de uma atividade (requisito de escrita) desdeque as informações se encontrem relacionadas a portadores de informação;
· HRB3: Um requisito candidato precisa ser inserido para cada atividade automatizada.
· Heurísticas de padrão de workflow (HPW):
· HPW1: Um requisito candidato precisa ser identificado de uma série de atividades executadas, de maneira sequencial e automatizada, ou apoiadas por um sistema;
· HPW2: Um requisito candidato deve ser identificado de uma estrutura do workflow em que tarefas podem ser realizadas de maneira repetitiva.
· Heurísticas de cobertura de cenário (HCC):
· HCC1: Um fluxo de cenário é identificado no momento em que existir uma sequência de tarefas executadas entre um evento inicial e um final. Na possibilidade de haver diversos fluxos a ser seguidos, todos deverão ser levados em consideração;
· HCC2: Um fluxo de cenário é identificado quando existir uma sequência de tarefas executadas entre eventos, independentemente de sua localização, por exemplo, entre eventos inicial e intermediário ou eventos intermediário e final.
· Critérios de cobertura (CC):
· CriCob1: todos os requisitos identificados pelas heurísticas precisam ser levados em consideração nos casos de teste, no mínimo uma vez, em um fluxo retirado do processo direcionado a negócios;
· CriCOb2: todos os fluxos identificados pelas heurísticas devem ser considerados, nos casos de teste, no mínimo uma vez.
Para observar os exemplos de extração dos casos de teste, precisamos observar as técnicas de derivação adotadas. Quando tratamos da derivação dos casos de teste provenientes dos casos de uso, os casos de uso são vistos como uma técnica de busca de requisitos inserida, de imediato, no método Objectory, sendo já considerados componentes essenciais da linguagem de modelagem unificada (UML).
Os casos de uso simbolizam as prováveis interações que serão apresentadas nos requisitos do sistema. Não existem diferenças entre cenários e casos de uso que atuam de maneira simplificada e rápida. Alguns usuários do sistema podem considerar os casos de uso como cenário único, entretanto outros usuários encapsulam diversos cenários dentro de um único caso de uso. Estes casos podem realizar interações individualizadas entre os sistemas ou com os seus usuários, e todo caso de uso precisa ser documentado utilizando uma descrição textual que pode ser relacionada a outros modelos UML, criando um cenário com maior detalhamento.
Diante desse contexto, os casos de teste direcionados a um teste funcional são derivados dos casos de uso, para a qual se destina o teste. É preciso criar um conjunto de casos de teste para cada cenário desenvolvido de um caso de uso. Por sua vez, os cenários de caso de uso são reconhecidos através da apresentação de alternativas que seguem o fluxo básico, até finalizá-lo.
O fluxo básico se caracteriza como uma alternativa mais simples no caso de uso, já o fluxo alternativo se origina do fluxo básico e, diante de uma condição específica, será executado posteriormente. É importante salientar que um fluxo alternativo pode retornar a um básico, se for originário de outro fluxo alternativo, ou até mesmo encerrar o caso de uso sem retornar a um fluxo.
Outro modelo de extração de casos de teste vem da derivação destes casos em especificações suplementares. Nem todos os requisitos de uma destinação do teste serão apresentados nos componentes de requisitos funcionais, como as especificações de casos de uso. Diante desse cenário, os requisitos não funcionais e os de configuração acabam especificando aspectos adicionais do destino do teste.
Derivando casos de teste para testes de desempenho:
· Verificar se existe no mínimo um caso de teste identificado para cada sentença dentro da especificação suplementar, que representa um critério de desempenho. Normalmente esses critérios são apresentados através do tempo por transação ou percentis;
· Verificar se há pelo menos um caso de teste identificado para cada caso de uso crítico. Os casos de uso críticos são vistos nas instruções realizadas anteriormente ou em documentos que analisam a carga de trabalho que precisa ser ao utilizar medidas de comportamento.
Assim como nos casos de teste direcionados aos testes funcionais, geralmente haverá mais de um caso de teste por cenário ou requisito de uso. É comum definir vários casos de teste: que se encontra abaixo do valor delimitado de desempenho (taxa média de transações), dentro do parâmetro (taxa alta de transações), ou acima do valor limite (taxa máxima de transações).
Os agentes que atuam no sistema e os casos de uso descrevem a interação existente entre os usuários externos do sistema e as ações realizadas pelo sistema, com o objetivo de criar os valores para os agentes. Os sistemas complexos apresentam diversos agentes ou atores, sendo assim, é importante criarmos casos de teste que assegurem que eles consigam executar os casos de uso. Isso vai acontecer se as diferenças presentes no fluxo de eventos do caso de uso forem notadas, baseadas no modelo de atores.
Derivando casos de teste para testes de configuração:
Podem existir diversas combinações entre o hardware e software que têm suporte dentro dos sistemas distribuídos mais comuns. O teste deve ser realizado com o intuito de observar se ele funciona ou se a sua execução ocorre de maneira oportuna em configurações diferentes. O teste abrange, também, um conjunto de combinações de elementos para identificar erros oriundos das interações de vários componentes.
A aquisição de um caso de teste destinado aos testes de configuração depende da adoção de algumas diretrizes. São elas:
· Observar no mínimo a existência de um caso de teste que reconheça cada configuração crítica. É preciso apenas identificar uma série de configurações inseridas no hardware e software, adequadas para o ambiente de objetivo do teste e priorizá-las, assegurando que as mais comuns sejam testadas em primeiro lugar;
· Verificar a existência de pelo menos um caso de teste para a configuração suscetível a problemas. Tais configurações podem apresentar, por exemplo, recursos de hardware com performance ruim, software co-residente com um histórico de problemas de compatibilidade, além de clientes que utilizam o servidor por uma conexão mais lenta.
Derivando casos de teste para testes de instalação:
No teste de instalação, é preciso verificar a possibilidade de instalação do seu objetivo em todos os cenários possíveis. Tais cenários de instalação podem inserir o objetivo de teste em primeiro lugar ou uma versão nova ou build desse objetivo. O teste de instalação também precisa assegurar que o objetivo do teste seja realizado de maneira cabível no momento em que as condições forem consideradas anormais.
Os casos de teste precisam abordar cenários de instalação do software, como a mídia de distribuição. Os programas de instalação direcionados ao software cliente-servidor possuem uma série específica de casos de teste. O programa de instalação normalmente é dividido entre o servidor e o cliente, ao contrário dos sistemas baseados em host. Dessa maneira, é essencial que o teste de instalação realize a instalação de todos os componentes do objetivo do teste, incluindo o cliente, as camadas intermediárias e os servidores.
Derivando casos de teste para outros testes não funcionais:
Do ponto de vista da extração de casos de teste, a situação considerada ideal é que o usuário consiga visualizar todos os recursos necessários para adquirir os casos de teste em todos os modelos até aqui citados. Porém, não é estranho que o usuário necessite complementar os que forem encontrados, como:
· Casos de teste para testes operacionais;
· Casos de teste que investigam gargalos de desempenho, recursos de volume do sistema, ou que forçam falha no objetivo do teste.
Derivando casos de teste para testes de aceitação do produto:
O teste de aceitação do produto é considerado o experimento final na fase anterior à implementação do software, cujo objetivo é observar se o software está pronto e pode ser usado para atender as suas especificações. Trata-se de um teste que envolvea preparação do software e os produtos de trabalho disponibilizados aos clientes.
A derivação dos casos de teste destinado a produtos de trabalho de um software é descrita nas seções abordadas anteriormente. A depender do nível e do formalismo do teste de aceitação do produto, os casos de teste serão similares aos reconhecidos anteriormente ou um subconjunto. A profundidade dos casos de teste não interfere no fato de haver a necessidade de estabelecer um acordo com os critérios de aceitação do produto antes da implementação e execução do teste do produto.
Criando casos de teste
Ao idealizar a execução de um teste de software, é importante ter em mente dois aspectos essenciais que precisam ser geridos: um se refere ao custo, e o outro ao benefício gerado pela atividade de testes, lembrando que uma ação está relacionada à outra.
Ao realizarmos testes em aplicações com alto nível de complexidade, os custos pertinentes aos testes normalmente aumentam de maneira rápida, o que pode ocasionar a perda das vantagens disponibilizadas. As técnicas (métodos) apresentadas nas próximas seções auxiliam a criação de cenários de testes, e certamente diminuem os custos ligados ao planejamento e à execução das atividades.
Nestas condições, os custos de execução serão elevados e, geralmente, não há tantos recursos disponíveis na realização das atividades de teste. Portanto, devemos considerá-la entendendo as limitações de custo, esforço e tempo, pois estes aspectos, por inúmeras razões, impedem a realização de testes exaustivos ou os testes dos cenários de software. O custo da qualidade gerado a partir de uma infraestrutura e de um tempo de desenvolvimento de teste desejados, pode trazer benefícios superiores em relação ao custo de ter uma falha presente no software.
Utilizar técnicas para reduzir o custo da qualidade é melhor do que simplesmente testar o software, se levados em consideração os custos elevados de planejamento e execução dos testes. Geralmente, a falta de conhecimento sobre a dificuldade de se planejar e executar testes, por exemplo, faz com que o software seja desnecessariamente testado de maneira completa.
A qualidade de um sistema de software não é atingida por meio de fórmulas ou padrões. Por conta disso, é normal a utilização de técnicas estatísticas. É possível, portanto, entender que existe um nível de dificuldade para garantir a qualidade do software, porém, o maior desafio é levar este conhecimento técnico a quem não o possui.
O passo final é estabelecer as entradas e verificar se o software vai se desempenhar de maneira adequada. Porém, é preciso compreender que o ato de testar é uma atividade com alto nível de complexidade e que precisa ser realizada levando em consideração as limitações impostas. Desta maneira, é necessário atuar no sentido de maximizar o nível de cobertura dentro das restrições de recursos definidos.
GERAÇÃO DE CASOS DE TESTES DO TIPO CAIXA-PRETA
Para tratarmos da criação de um caso de teste específico para caixa-preta, é preciso detalhar as abordagens utilizadas. As principais são: random sampling, pairwise testing e N-wise testing. Vamos falar sobre cada uma delas.
A random sampling (amostragem aleatória) consiste em um método de amostragem, na qual uma amostra selecionada apresenta o mesmo grau de probabilidade de outra. Se uma amostra for selecionada de maneira aleatória, sua representação precisa ter aspectos de imparcialidade em relação à população total de amostras. Caso isso não ocorra, este tipo de variação é denominado “erro de amostragem”.
A amostragem aleatória é considerada uma das maneiras mais comuns de e mais simples de buscar e coletar dados da população total. Neste tipo de amostragem, cada componente de um subconjunto tem a mesma chance de ser selecionado como parte do processo de amostragem. Entretanto, uma das desvantagens de seu uso se dá pela sua exigência para ser inserida uma listagem completa da população de amostras.
Geralmente, o planejamento e a realização dos testes nos projetos são curtos. Nessas condições, os analistas são obrigados a escolher combinações assertivas para buscar a maior quantidade de defeitos de maneira acelerada. Para solucionar esse problema e assegurar o nível de qualidade, os analistas de teste adotam técnicas mais específicas.
Neste contexto, podemos citar o pairwise testing, que consiste na combinação das entradas prováveis de um sistema usando uma forma inteligente para criar uma quantidade mínima de saídas de teste e elevar o nível de variação das entradas do sistema. Através desta técnica, as combinações de casos de teste e o custo de realização do teste serão reduzidos.
Esta técnica é realizada de forma manual, adotando o uso de matrizes definidas a priori, visando à criação de variações de casos de teste, através das variáveis do sistema que se encontram na entrada. De imediato precisamos selecionar a matriz mais adequada, e a quantidade de colunas dessa matriz será considerada o número de entradas, se acrescentando mais uma. Em seguida pegamos as chances de entradas, e realizamos a multiplicação dos dois maiores números.
Verificaremos que o resultado obtido desta operação consiste no número de linhas da matriz e a quantidade de possíveis casos de teste. Após a seleção da matriz, é preciso realizar as correlações entre a definição de cada linha e coluna da matriz. Depois das correlações, o analista de teste pode retirar uma combinação de teste, caso for constatada invalidez.
O teste N-wise, por fim, é um método para testes de interação do tipo combinada. Ao dar prioridade ao teste, os casos de teste serão reorganizados com mais importância e detalhamento mais aprofundado. Uma nova metodologia para a criação de casos de teste N-wise vem sendo adotada com o intuito de atender três critérios diferentes, referentes à prioridade dada para cobertura de interação, peso e divergência. A metodologia sugerida vai criar um grupo pequeno de casos de teste em N, sendo que casos com elevado nível de prioridade vão surgir de imediato e com frequência.
GERAÇÃO DE CASOS DE TESTES AUTOMÁTICA
Para falarmos sobre este modelo de criação de casos de teste, é preciso ter em mente o método utilizado como linguagem de especificação e modelagem: o RPOO (Redes de Petri Orientadas a Objetos). Os sistemas testados serão modelados dentro dessa linguagem. A ferramentas denominadas JMobile tem a função de receber especificações na condição de entrada, e vão criar o seu espaço de estados na forma de sistemas de transições rotuladas (LTS). Importante frisar que as metas a serem alcançadas pelos testes são especificadas no seu LTS respectivo.
O RPOO é um formalismo desenvolvido para aproveitar os modelos com características estruturais disponibilizadas, pela orientação a objetos, em paralelo aos modelos comportamentais das redes de Petri. O RPOO sugere um modelo de sistemas com base em projeções oriundas da semântica ligada à orientação de objetos e das redes de Petri. Os modelos RAPOO conseguem, por meio de uma perspectiva orientada a objetos, apresentar as classes de um sistema e as relações estabelecidas entre os objetos. Desta maneira, sempre existirá para cada classe do sistema de objetos uma rede de Petri responsável por exibir a sua performance interna.
Boa parte das ferramentas utilizadas na criação e na escolha automática de casos de teste adota o LTS (Sistemas de Transições Rotuladas) como um procedimento formal de entrada. Para que esta transformação se concretize, é preciso falar da implementação do JMobile. o JMobile Tools tem como função principal auxiliar as ferramentas utilizadas nas simulações de modelos RPOO e na criação de espaços nos estados, apresentando a sua API classes e metodologias que disponibilizam acessos às informações pertinentes a este modelo e às simulações realizadas. Paralelo a este API, é possível apresentar um protótipo de ferramenta que possua habilidade de executar a simulação de modelos RPOO, e a criação de um espaço de estados respectivos.
A TGV, por sua vez, é conhecida como uma ferramenta de auxílioaos chamados testes funcionais (caixa-preta), que se baseia em metodologias de análise de modelos responsáveis por implementação automática dos casos de testes do tipo funcional, direcionados aos sistemas reativos, por exemplo. Vale dizer que o algoritmo de criação inserido por TGV tem como base aqueles usados para a avaliação de modelos, cujas funções estão ligadas às escolhas das realizações no sistema que atendam às requisições do teste. Ao terminar este procedimento, os casos de teste escolhidos serão disponibilizados em LTS, e, através da utilização de outras ferramentas, poderão ser transformados em outras modalidades de formato.
Boa parte das ferramentas de seleção dos casos de teste recebe o sistema especificado em LTS e utiliza a técnica adquirida por meio de algoritmos para a criação de testes de software, como ocorre no uso do TGV (Test Generation Based on Verification Techniques), que consiste em ferramentas responsáveis pelo desenvolvimento de casos de teste. Ele recebe o modelo de sistema na entrada e o objetivo de teste já especificado, além de escolher, através da especificação, os casos de testes baseados nestes objetivos. Diante disso, os casos de teste são disponibilizados em LTS, o que permite sua implementação ou conversão para outro tipo de linguagem.
GERAÇÃO DE CASOS DE TESTES EM TAREFAS
Sem dúvida os casos de teste são idealizados com a função de cobrir completamente os requisitos funcionais e extremamente assertivos na busca de possíveis erros ou falhas sistêmicos.
Para exemplificar uma criação de casos de teste em tarefas é possível explorar o modelo navegacional do UsaTasker++. Através dele é viável extrair casos de teste de um grafo simbolizando a execução de uma tarefa. Considerando que determinada tarefa pode ser opcional, desordenada ou repetida, existe a possibilidade de realizar uma atividade de maneiras distintas.
Existem diversos caminhos do ponto inicial ao final da atividade. Com isso, o principal objetivo do UsaTasker++ é buscar todas essas alternativas, transformando cada chance em um caso de teste. Uma série de algoritmos foi criada para processar um grafo direcionado, levando em consideração as funcionalidades do modelo navegacional, com o objetivo de criar todas as alternativas que apresentam eventos iniciais e finais em comum. Técnicas distintas são adotadas para processar o grafo, disseminadas nos seguintes passos:
· Calibrar grafo: Desenvolver uma lista adjacente que simbolize o grafo básico e acrescente novas arestas;
· Descoberta de caminhos: Buscar todos os caminhos básicos inseridos no grafo;
· Aplicação do método de redução: Retirar todos os caminhos considerados inválidos;
· Processamento fora de ordem: Desenvolver caminhos incrementais para simbolizar os eventos considerados fora de ordem;
· Processamento de ciclo: Desenvolver alternativas adicionais para acrescentar os eventos repetidos.
Automação de testes
Se pensarmos em um sistema real, perceberemos que ele pode apresentar uma quantidade expressiva de cenários de teste. Sabemos que um sistema precisa passar por uma evolução de maneira rápida, além de apresentar uma capacidade de controlar, o mais rápido possível, as prováveis falhas ocorridas na segurança.
Porém, é praticamente impossível analisar de maneira especifica as alterações às quais o sistema está sujeito e verificar se alguma mudança surtiu efeito.
Diante deste contexto, para que a análise do sistema seja otimizada e os comportamentos desejados sejam alcançados, é fundamental o uso de métodos relacionados à automação de testes. Ela é vista como importante para uma série de funcionalidades, como as aplicações extensas de Web, já que consegue reduzir de maneira significativa o tempo para executar os testes e auxiliar a disponibilização de produtos menos defeituosos.
Como podemos definir um teste automatizado e quais as suas funcionalidades? Um caso de teste realizado de maneira automatizada é considerado um script que provém de uma sequência de ações, realizada dentro das interfaces gráficas de uma aplicação, aliada ao uso de dados importantes. Depois que as pré-condições são configuradas, a execução dos testes é realizada para comparar posteriormente os resultados alcançados (reais) com os resultados desejados. Ao final de um relatório de teste, eles são apresentados para definir o status do resultado.
Em vez de de focar a estrutura, a condição interna do sistema ou as características temporais, a automação normalmente vai focar o desempenho das entradas e saídas. Sendo assim, os scripts são formados por comandos que simulam as entradas no sistema, além das análises para definir comparações para as saídas. Boa parte dos instrumentos de automação dão suporte ao processo de gravação das tarefas no desenvolvimento de script de teste correspondente e na sua execução dentro de um navegador.
Tais métodos são denominados de Capture and Replay, isto é, gravar e repetir, cujas vantagens do seu uso estão relacionadas à redução de tempo na codificação manual e simplificada dos scripts. Outro aspecto está relacionado à chance de realizar a execução dos casos, de teste de acordo com a necessidade, de maneira ágil e simplificada. Estas ferramentas são amplamente adotadas no mercado e são essenciais, por exemplo, para elevar o nível de qualidade das aplicações web.
Entretanto, as ferramentas Capture and Replay são desvantajosas em alguns aspectos, pois eventualmente os scripts desenvolvidos apresentam certo nível de ineficiência, exigindo interferências manuais por diversas vezes. Outra questão está ligada aos testes de regressão, nos quais qualquer alteração na interface gráfica do sistema pode ocasionar em erros e impedir sua execução.
Dentro de uma demanda, é normal solicitar a automação de testes. Nesse contexto, os instrumentos de automação geralmente vão ocupar uma função fundamental, pois são considerados os principais responsáveis pela realização desta modalidade de atividade.
A primeira ferramenta da qual vamos falar é o Selenium. De antemão, é possível dizer que o Selenium é atualmente a estrutura de automação de testes mais empregada. Surgiu em 2004 e, desde então, não parou de evoluir, tornando-se a principal escolha para testadores de código aberto que trabalham com aplicativos inseridos na web.
Além de liderar no setor, o Selenium serve de referência para outras ferramentas de automação, como o Katalon Studio, e dá suporte a vários ambientes operacionais.
A ferramenta Robotium se caracteriza por ser um framework muito conhecido destinado a aplicativos Android. É totalmente compatível com aplicações, sejam elas nativas ou híbridas, e possibilita a escrita simplificada da automação de testes de caixa-preta. Sua função principal é criar uma simulação de metodologias que normalmente serão executadas pelo indivíduo que analisa os testes realizados. Isso pode incluir algumas atividades, como a inclusão de cadastro.
A ferramenta Appium é um instrumento de categoria open source direcionado à automação de aplicações nativas ou híbridas. De característica multiplataforma, ela disponibiliza auxílio para simuladores móveis e para dispositivos reais. O Appium se diferencia do Robotium, pois também pode ser utilizado na automação de testes de softwares da plataforma iOS, o que aumenta o interesse dos desenvolvedores. Através dele é possível executar testes sem levar em consideração a linguagem de programação selecionada.
Outra ferramenta é o UFT, que consiste em um instrumento de teste comercial bastante conhecido no que se refere aos testes funcionais de software. Esta ferramenta disponibiliza um conjunto de recursos direcionado à APIs e testes GUI de softwares para desktop, por exemplo. Além disso, adota o uso do VBScript com o objetivo de deixar registrado os procedimentos de teste e controle.
Por fim, há o Watir, que também é adotado para realizar a automação de testes em código aberto na web. Este procedimento se baseia em bibliotecas de código Ruby e se caracteriza por ser compatível com testes para navegadores distintos, como MozillaFirefox e Opera. Também oferece suporte a outros testes orientados a dados, integrando-se a ferramentas do tipo BBD.
É importante frisarmos que a execução de testes de software consiste em uma atividade repetitiva e exaustiva. Não há possibilidade de descartar esta etapa de desenvolvimento quando o objetivo é disponibilizar um produto de qualidade para o cliente final. Portanto, a automação se torna uma excelente alternativa.
Uma das vantagens do instrumento de automação é possibilitar que o código seja redigido uma única vez, indicando à máquina os testes que foram redigidos para o software que vai executar, dentro de uma periodicidade. O resultado disso gera um elevado nível de confiança na equipe de desenvolvimento, já que se torna viável a alocação de tempo direcionada aos testes em tarefas, como a autocorreção das falhas possíveis, verificadas pelos testes automatizados.
Outra vantagem da automação de testes está ligada ao aumento da produtividade na criação do software e ao atendimento das requisições do cliente, que vai receber o produto ou serviço isento de falhas.
A execução de testes automatizados está em ascensão, pois existe a possibilidade de análise das funcionalidades do software de forma mais célere, com eficiência e esforço mínimo. Todo o processo se caracteriza pela facilidade de realizar a repetição dos esforços contínuos visando o teste da aplicação. Também existe a possibilidade de realizar combinações complexas para testar a qualidade do software de maneira mais eficiente, desconsiderando a falha do ser humano, o que dá aos testes mais objetividade. Os casos de verificação do software geralmente são executados através de códigos descritos e compreendidos por um computador. Sendo assim, existe a possibilidade de elevar o grau de dificuldade dos testes, realizando várias combinações que a mão de obra humana não teria capacidade.
Os testes automatizados são considerados as melhores alternativas para analisar a qualidade das aplicações, e podem agregar valor e mais destaque ao produto. Por conta disso, podemos observar os benefícios que os testes automatizados podem trazer para a qualidade do seu software a seguir:
· Custo inferior: O custo inicial pode ser mais elevado, porém após sua inserção, o custo dos testes automatizados é reduzido, se comparado aos manuais. Normalmente eles evitam bugs e questões operacionais, o que diminui o custo referente à manutenção do software;
· Feedback mais rápido: A eficiência e a rapidez fazem com que os testes automatizados possibilitem um retorno mais acelerado dos clientes e dos usuários. Assim, os bugs que podem surgir ocasionalmente podem ser corrigidos rapidamente;
· Mais eficiência: Testes manuais precisam de um extenso tempo para realizar o ciclo de desenvolvimento de um software. As melhorias simples na eficiência dos testes impactam no custo final de um projeto. Com os testes automatizados, é necessário menos tempo para serem realizados;
· Mais motivação à equipe: Quando os feedbacks dos testes são demorados, a equipe de desenvolvimento se sente desmotivada. Isso cria insatisfação tanto nos testadores quanto na equipe de desenvolvimento. Os testes automatizados encerram esse ciclo e motivam a equipe de desenvolvimento do software;
· Segurança de informação: Apresentar coberturas de testes é fundamental para o êxito do projeto. Normalmente profissionais passam horas corrigindo bugs inseridos na produção em sistemas nos quais a segurança é deficitária. Graças aos testes automatizados é possível fazer verificações contínuas de segurança, o que evita a presença de hackers em um código falho.
Gerenciamento de defeitos
Quando nos referimos à garantia de qualidade de um software, tratamos da busca e correção de erros presentes no produto. A qualidade é medida pela quantidade de erros visualizados ao longo da realização dos testes.
Geralmente as pessoas indicam que a busca por defeitos é a uma função privativa do teste de software. Seu objetivo principal é mensurar a qualidade da aplicação executável ou dos itens adotados no desenvolvimento de um sistema.
A falha, dentro deste contexto, é proveniente de algum erro ou defeito cometido, certamente por uma disparidade entre a solicitação do usuário através dos requisitos e o desempenho disponibilizado pela aplicação executável.
O sistema é extenso e complexo. Além de cumprir normas de qualidade, qual solução podemos encontrar? Uma solução viável consiste na utilização de um procedimento para gerir defeitos que estejam em integração com o ciclo de vida, criação e teste de um software.
Compreender as ações de um processo de gestão de defeitos e selecionar o instrumento apropriado para gerar um nível de automatização na gestão do ciclo de vida de um defeito são atividades essenciais.
Quando analisamos o processo de gestão de defeitos, precisamos verificar que a sua principal funcionalidade é antecipar possíveis erros e reduzir os riscos inerentes a um projeto. O uso da ferramenta automatizada apresenta uma base comum disponibilizada para a entrada de informações. Além disso, a gestão de defeitos expõe uma forma de promover relação entre as equipes de desenvolvimento e de testes.
De maneira genérica, o termo "erro" é utilizado para apontar as distinções ocorridas entre o valor alcançado em comparação ao valor desejado. Porém, seguindo o padrão IEEE 610.12-1990, é possível diferenciar terminologias que normalmente causam confusão no momento do gerenciamento. São elas:
O termo "defeito" é utilizado genericamente para referenciar um erro, engano, defeito ou falha. Diante disso, os elementos essenciais de um processo de gestão de defeitos podem ser enumerados da seguinte maneira:
· Prevenção de defeitos: Inserir ações de prevenção e programação de contingências baseadas na observação dos riscos críticos do projeto para reduzir o impacto, caso os riscos se transformem em algo mais contundente;
· Linha base entregáveis: Determinar linhas de base formalizadas, chamadas baselines, através de uma gerência de configuração inserida no software. Cada linha base estabelece os requisitos disponíveis e que passarão por testes;
· Identificação do defeito: Estabelecer os métodos necessários para a busca e a classificação dos defeitos, da mesma maneira que os critérios para identificá-los;
· Solução do defeito: Estabelecer as tarefas destinadas para correção e notificação posteriores do defeito. Diversas das tarefas são determinadas pela gerência de configuração de software, visando assegurar o histórico e o acompanhamento das alterações através do controle de versões;
· Melhoria do processo: Verificar as medições e relatórios de gestão para a compreensão dos problemas e realizar a melhoria do processo de maneira contínua;
· Relatório de gestão: Criar relatórios baseados em dados para acompanhar a evolução dos testes e o nível de qualidade do sistema, de modo que algumas métricas sejam inseridas para melhorar o processo.
A qualidade de um sistema pode ser mensurada pela quantidade de defeitos visualizados durante a realização dos testes. Sua execução é realizada formalmente, por meio de testes estruturais ou funcionais, ao longo do uso do sistema ou em desenvolvimento. Os defeitos podem ser classificados nas seguintes categorias:
Assim que o defeito é localizado, intencional ou acidentalmente, o procedimento seguinte é o relato desse defeito, através do procedimento definido na gestão de defeitos. Este mecanismo pode ser uma simples planilha, até uma ferramenta automatizada.
Quando o defeito for reportado, ele passará por um ciclo de vida estabelecido anteriormente pelo processo de gestão de defeitos, cuja finalidade é estabelecer os fluxos percorridos pelo defeito até sua finalização.
Como já observamos, os relatórios consistem em uma das partes essenciais do processo de gestão de defeitos, porém são colocados em uma condição secundária. Algumas diretrizes precisam ser seguidas quando o relato de um defeito está sendo realizado. Um relatório deve ser preciso e claro, pois cabe ao usuário identificar se o defeitoobservado é um desvio da performance esperada, e não uma falha de compreensão.
Um relatório também precisa ser generalizante, pois um problema pode ocorrer em outras situações pertinentes ao software, e mostrar que o defeito pode ser reproduzível, descrevendo os procedimentos adequados para a sua reprodução.
Por fim, um relatório precisa ainda evidenciar a existência do defeito visualizado através de arquivos de saída, e a revisão, tendo a descrição e os passos para que o defeito seja reproduzido.
Outro aspecto deixado em segundo plano é a classificação da severidade e prioridade pertinentes aos defeitos, geralmente interpretada de maneira errônea em diversas situações. Tal interpretação colabora para a priorização ineficiente e a correção dos defeitos realizada de maneira agendada. Consequentemente teremos um mau uso destes recursos, por conta da correção de defeitos com nível de prioridade inferior.
De maneira sintetizada, a severidade de um defeito estabelece sua interferência no funcionamento de uma aplicação. Em contrapartida, a prioridade aponta a ordem na qual os defeitos serão corrigidos. Os defeitos vistos como mais severos são tratados com mais prioridade. No entanto, podem existir diversas situações em que não podemos aplicar essa regra. Vejamos a seguir os critérios para determinar a severidade dos defeitos analisados.
A seguir é possível verificar os critérios para determinar a prioridade dos defeitos analisados.
Outra ferramenta importante é o Mantis, instrumento de open source executado de forma automatizada e redigido em PHP, cujo objetivo é auxiliar a gestão de defeitos. O Mantis se caracteriza por controlar todas as etapas do ciclo de vida de um defeito através de fluxos personalizáveis.
O Mantis apresenta um conjunto de funcionalidades, que podem ser realizadas em qualquer plataforma que suporte PHP/Apache/MySQL. Além disso, colabora dentre outros aspectos em:
· Desenvolvimento ilimitado de projetos e relatos de defeitos;
· Gestão do controle de acesso e níveis de permissões para usuários;
· Ciclo de vida dos defeitos (workflow) personalizável;
· Gerador interno de relatórios e gráficos;
· Estrutura para a criação de campos personalizáveis;
· Notificações por e-mail automáticas ou através de RSS Feeds;
· Integração com ferramentas de controle de versões (Subversion e CVS);
· Interface Webservice (SOAP) para integração com outras ferramentas;
· Mantis WAP – Suporte a dispositivos móveis.
Sintetizando
Verificamos que a equipe que cuida dos testes precisa planejá-los para que os requisitos sejam validados adequadamente, quando um conjunto de requisitos esteja disponível. Observamos que a validação do software é feita de maneira diferente em relação aos requisitos adotados.
Ainda vimos que, ao projetar a realização de um teste de software, é importante verificar o custo-benefício criado pela atividade de testes, pois aplicações complexas aumentam os custos rapidamente, ocasionando perdas nas vantagens disponibilizadas.
Outro aspecto relevante de que tratamos foi dos sistemas reais, que se caracterizam por apresentar um número grande de cenários de teste. É importante frisar que um sistema passa por rápida evolução e uma capacidade de controle dos possíveis erros que ocorrem na segurança.
Por fim, vimos o conceito relacionado à garantia de qualidade de um software, no intuito de corrigir erros que surgirem. Normalmente a busca por defeitos é a uma função privativa do teste de software, cujo objetivo é medir a qualidade de um sistema na aplicação executável e os itens adotados.
Unidade 4 – Medidas, gerenciamento e execução de testes de software
Métricas para o teste de software
A experiência na criação de softwares e desenvolvimento web tem mostrado que as empresas precisam lidar com problemas e processos. Posto isso, podemos dizer que problemas são erros, como adaptação de tela inadequada, erros de código, algoritmos que não funcionam, entre outros; ao passo que processos se referem a formas de trabalhar e estruturar a rotina, bem como a atender clientes e usuários.
Tendo isso em mente, pode-se afirmar que é relativamente comum que muitas empresas apresentem a seguinte objeção: "sabemos que a qualidade é importante, mas ela nos custa tempo e dinheiro em demasia para obter o nível de qualidade de software que realmente desejamos" (PERES, 2016, p. 25).
Geralmente, percebemos que existem erros de gestão que afetam a qualidade de software, uma vez que, na ausência de uma rotina estruturada em função de prioridades da manutenção de software, os programadores e testadores muitas vezes somente “apagam incêndios” ao invés de se utilizarem do tempo disponível para focar na qualidade, e esta rotina reativa não dá espaço a uma rotina preventiva e proativa. Neste tipo de cotidiano, por estarem o tempo inteiro reparando erros, os programadores não têm tempo – nem cabeça – para utilizar a criatividade a fim de prevenir problemas e criar aplicações incríveis. Portanto, se faz necessário criar modelos e métricas em testes de software que possam identificar rapidamente quando um erro se torna um padrão.
MÉTRICAS DE PROFUNDIDADE, DE QUANTIDADE E DE SEVERIDADE
A métrica de profundidade pode ser explicada como a capacidade de testar os programas até suas partes mais profundas, isto é, o banco de dados. Outro exemplo de métrica é relativa à quantidade de erros encontrada para cada tipo de problema, como, por exemplo, uma empresa que realizou um teste e avaliou dez erros de cobertura, três erros de mudança de tela e um erro de operação lógica. Por fim, outro exemplo de métrica é relativa à severidade dos erros, na qual o testador pode criar indicadores referentes a níveis de erros críticos, níveis de relativa atenção e níveis menos prejudiciais. Logo, podemos resumir estes três indicadores da seguinte forma: 
· Métrica que avalia a profundidade do teste: O exame avalia até a caixa-preta? Ou seja, ele avalia até a camada que abrange a tela, os campos e os botões? O exame avalia até a caixa-branca? Ou seja, ele avalia mais que a tela, analisando também os códigos? O exame avalia o funcionamento do banco de dados? Ou seja, avalia também a qualidade da gestão de dados no servidor SQL realizada pelos administradores de banco de dados (ou DBA - Data Base Administrator)? Em outras palavras, além de avaliar a tela e os códigos, o exame avalia a forma com que os dados são gerenciados no banco de dados? O exame avalia, além do supracitado, o modo de alimentação do banco de dados? Ou seja, avalia também a qualidade das fontes de cadastros de dados, ao realizar perguntas como: o departamento de estoque preenche os dados corretos? As fontes de dados são confiáveis? As fontes de dados são abundantes? As fontes, por algum viés, permitem valores nulos ou errantes?
· Métrica que avalia a quantidade de erros: Um exemplo amplamente utilizado é o intervalo escalar, como, por exemplo, de 0 até 10 erros, de 11 até 20 ou mais que 21; cada escala de erros pode ser avaliada perante um indicador. Dois exemplos de indicadores, medidos sob o prisma do intervalo escalar, são: 
· Quantidade de erros lógicos (0-10, 11-20 ou mais que 21);
· Quantidade de erros de documentação (0-10, 11-20 ou mais que 21).
Existem testadores que, em vez de de utilizar quantidade, empregam porcentagem: encontrou-se 30% de erros de cálculo e 70% de erros de mudança de interface, por exemplo.
· Métricas que avaliam severidade: Erros de nível crítico ou urgente;
Erros de nível intermediário, que exigem relativa atenção;
Erros de nível leve.
É fato que nenhuma empresa quer gastar tempo ou dinheiro com testes dispensáveis. No entanto, a prática tem mostrado que não existem testes que sejam supérfluos, mas sim prioridades diferentes. Cabe à empresa escolher bem as ferramentas ideais para testar seus softwares, uma vez que cada empresa programa em determinada linguagem, além de possuir tipos específicos de programa. As empresas, geralmente, possuem um programa para criar softwares, um programa para testá-los e uma linguagem de programação, além de algumas