Selenium WebDriver - "Automação sem Limites"

Hoje abordarei de forma rápida a utilização do Selenium WebDriver juntamente com o framework de teste unitário em Java.: JUnit. O objetivo principal do Webdriver é automatizar ações executadas em diversos browsers distintos, consumindo e utilizando seus recursos nativos. Já o JUnit permite a execução e validação de testes unitários a partir de testes reproduzidos no Webdriver do Selenium.

O Selenium WebDdriver, também conhecido como Selenium 2, nasceu da fusão entre as ferramentas Selenium RC e WebDriver, logo todas as deficiências encontradas no Selenium 1 foram supridas com a utilização dos recursos do WebDriver principalmente no que tange à independência de cada navegador, substituindo o JavaScript que era embutido nas aplicações testadas. Essa característica permite a criação e execução de testes mais robustos, além de um maior controle na automação e limites de segurança impostos pelo Javascript.

Para realizar o download do Selenium WebDriver, basta acessar o link.

Se você baixou o Eclipse para executar o teste no post anterior, a última versão dessa IDE já contempla o framework JUnit não havendo a necessidade de baixá-la. Caso contrário, você pode encontrá-lo no seguinte link.

Da mesma forma que o Selenium RC, é possível realizar testes no Selenium IDE e exportá-lo para linguagem de programação da sua preferência. Portanto, vamos executar uma ação simples no site de uma calculadora online desenvolvida pelo Elias Nogueira em um de seus desafios selenium e exportar o caso de teste como.: Java / Junit / WebDriver

Posteriormente, devemos dar continuidade com os seguintes passos.:

1 - Inserir arquivo webdriver no projeto (Obs.: Não há necessidade de levantar o Servidor Selenium RC)
2 - Importar classe gerada no selenium IDE ao projeto. A classe JUnit contém sempre um método que realiza ações básicas necessárias antes do teste (setUp()) e um método que realiza verificações posteriores a execução do teste (tearDown()).
3 - Realizar alterações no código e criar casos de teste conforme necessidade. No caso, realizei da seguinte forma.:

    1°) Caso de Teste Ok
    2°) Caso de Teste Nok - Resultado Numérico Errado
    3°) Caso de Teste Nok - Resultado Alfanumérico
    4°) Caso de Teste Nok - Resultado sem valor

  
5 - Executar teste (Download ucSoma.java)
6 - Analisar resultados

Abaixo estou disponibilizando alguns links interessantes com vasto conteúdo para ampliar o conhecimento de quem tiver maior interesse na ferramenta.:

• SeleniumHQ
• SeleniumGoogleCode  
• Seu Enium 
• SlideShare 1 
• SlideShare 2  

Testar é garantir a informação!

Selenium RC - "Flexibilidade na Automação de Testes"

O Selenium RC (Remote Control) permite a construção de testes mais complexos, pois possui uma estrutura básica que contém um servidor que atua como uma ponte para o browser e algumas bibliotecas específicas. Além disso, por suportar algumas linguagens de programação possui várias possibilidades de tratamentos, condicionais e utilização de recursos e comandos característicos de cada linguagem. No exemplo simples que criaremos no decorrer do post, iremos apenas mostrar a possibilidade de automação do teste utilizando uma linguagem de programação específica com o servidor do Selenium-RC startado. No caso, estarei utilizando a linguagem Java, portanto faz-se é necessário alguns pré-requisitos em seu computador.:

Download do Kit de Desenvolvimento Java
Download do Selenium RC
Download de uma IDE em Java* 
*Não é obrigatório, mas facilita o desenvolvimento de posteriores aplicações e testes.

Após realizar todos os downloads e configurações iniciais, vamos criar um novo projeto no Eclipse.:

1°)Criar o projeto 'teste selenium rc' no Eclipse
2°)Criar a classe 'SeleniumRC' contendo o método principal
3°)Adicionar o arquivo java (.jar) do selenium RC ao projeto java
4°)Agora, existem algumas formas de iniciar o servidor do Selenium RC.

•  Clicando duas vezes no arquivo do selenium-server
• Abrir o prompt do Windows, entrar no diretório no qual o selenium-rc foi baixado e digitar a seguinte linha de comando.: java -jar selenium-server-standalone-<version-number>.jar
• Criando uma classe em java contendo o seguinte código.: 

import org.openqa.selenium.server.SeleniumServer;
 
public class ServerRC {   

    public static void main(String[] args) {
       
        SeleniumServer server = null;
       
            //Iniciar Servidor Selenium
            try {               

              server = new SeleniumServer();
              server.start();
              
            } catch (Exception e) {
               
                System.out.println("Falha Servidor");
                e.printStackTrace();
            } 
    }
}

5°)Feito isto, o servidor já está iniciado e podemos construir qualquer espécie de teste utilizando recursos específicos de cada linguagem.

Agora, você poderá criar casos de testes com o Selenium IDE, salvar a suíte de teste (e os casos de teste) e executá-la com o TestRunner do Selenium. Para isso, digite a seguinte linha de código no prompt do Windows.: java -jar selenium-server.jar -multiwindow -htmlSuite "*firefox" "http://www.URLdoTeste.com" "C:\Selenium_Tests\Suite.html" "C:\Selenium_Tests\resultados.html". Após a execução do teste, verifique na pasta especificada o html gerado contendo os resultados da execução.

Você pode também, realizar alterações no código para necessidades específicas do teste. O anexo a seguir contém um exemplo simples no qual verifico se o campo de busca da Google existe na página principal e se sua altura e largura estão corretas (Para verificar algumas das propriedades em elementos das páginas, é interessante a utilização da ferramenta fireBug), feito isto realizo a busca quantas vezes o usuário achar necessário para o teste ou até o usuário digitar a mesma busca duas vezes consecutivas. Ao final do teste é gerado um log contendo o resultado das buscas de cada dado entrada no Google. Perceba que não estou  utilizando nenhum framework de teste unitário, somente utilizo recursos do Java (estruturas de decisão, repetição, tratamento de erros e manipulação de arquivos) dentro do método principal da classe. Download - Arquivo Java
 
Veja abaixo na imagem o log final de execução dos testes.:

Testar é garantir a informação!

Selenium IDE - "Automação simples na prática!"

Conforme já havia informado anteriormente, passarei a postar de forma simples a utilização de cada ferramenta do Selenium. Portanto, neste post vamos explorar algumas funcionalidades do Selenium IDE, mas antes é interessante sabermos algumas características desta ferramenta.:

• É um plugin do Firefox que possibilita a automação de testes funcionais, logo será necessário que você possua este browser
• A utilização é intuitiva, simples e não há a obrigatoriedade de domínio de alguma linguagem de programação
• Possui comandos específicos chamados "Selenese" que basicamente são divididos em três categorias.: Actions (Operações que o usuário realiza na página web), Accessors (Armazena valores em variáveis, após a análise do estado em que a aplicação se encontra) e Assertions (Verifica o comportamento e se o resultado final da aplicação foi realizado conforme esperado).

Para baixar o Selenium IDE, basta acessar à página oficial do Selenium.
Após realizar o download e instalá-lo, o Selenium já estará acessível no menu principal do Firefox na opção 'Ferramentas'.

Ao executar o Selenium, sua interface se apresentará da seguinte forma.:

Legenda.:
1.  Página da aplicação a ser testada
2.  Velocidade da execução do teste
3.  Executa uma suíte de teste
4.  Executa um caso teste único
5.  Possibilita a definição de regras de agrupamento
6.  Suíte de Casos de Teste
7.  Lista de comandos (Tabela.: Comandos Selenium / Código-fonte.: Linguagem de programação específica)
8.  Botão Gravar.: Ao executar o Selenium, o botão já é acionado automaticamente.
9.  Campo Comando.: Nome que representa sua funcionalidade (obviamente, em inglês) e o mesmo pode ser obtido de três formas distintas.:

• Realizando a ação manualmente na página após clicar no botão 'Record' de gravação
• Clicando com o botão direito na página web e vendo a lista de comandos possíveis que o selenium disponibiliza  
• Inserindo manualmente na própria ferramenta, clicando com o botão direito na aba 'Tabela'

10. Campo Alvo.: Representa o local ou variável na qual o comando está sendo executado ou está direcionando
11. Campo Valor.: intuitivamente sabemos que é o conteúdo associado que terá cada comando quando necessário.
12. Resultado da execução
13. Log de execução
14. Descrições do comando (Reference / UI-Element), são extramente úteis no decorrer da utilização

Agora vamos começar um teste simples de uma busca pelo 'Selenium 2' no Google. Simplesmente entraremos no Google, digitaremos 'selenium 2' na caixa de texto de busca e clicaremos no botão com a lupa representada. Perceba que esta ação, gerou três comandos específicos no Selenium.:

Open.: Abertura da página web
Type.: Entrada de dados
click.: Ação do usuário clicanco na lupa do google
 
Pois bem, agora sim começa a "brincadeira" e a partir destes conceitos acima descritos já é possível ir testando e descobrindo a ferramenta. No caso, realizei a inclusão de alguns comandos simples apenas para dar a noção das possibilidades que a ferramenta fornece ao testador.

No link a seguir, estou fornecendo o arquivo do teste para que você realize em sua máquina e o altere conforme sua necessidade para realização de quantos testes julgar necessário. Neste exemplo de teste, para cada comando inseri comentários que descrevem sua funcionalidade e necessidade dentro da aplicação.  Download - Teste Busca Google

É importante frisar que as abas 'Mensagens' e 'Reference' são extremamente úteis para elaboração e adequação dos testes, pois indicam os pontos de erros e demonstram claramente a funcão de cada comando. Além disso, os comandos de ponto de início, breakpoint e a possibilidade de regular a velocidade da execução (Fast/Slow) auxiliam na reprodução do teste.

Para finalizar, um grande entusiasta do Selenium na internet, Elias Nogueira, criou alguns desafios que possibilitam o usuário conhecer a ferramenta um pouco mais. Vale a pena conferir.:

Testar é garantir a informação!

Automação de Testes Funcionais com Selenium

Ultimamente, venho pesquisando com certa frequência as ferramentas para automação de testes de software disponíveis no mercado. Após uma longa pesquisa na internet, visualização de tutoriais, opiniões e experiências de profissionais da área, optei por estudar e testar a fundo a ferramenta Selenium.

Na realidade, o Selenium é um conjunto de ferramentas "Open Source" para automação de testes em aplicações web, suportando diversos browsers, plataformas e linguagens de programação. Além disso, sua flexibilidade possibilita ao profissional realizar testes funcionais, de regressão e até mesmo de desempenho.

No conjunto de ferramentas Selenium, encontramos os seguintes componentes.:

Selenium IDE.: É um plug-in para o Firefox que permite a captura e reprodução de ações realizadas pelo usuário no navegador.

Selenium RC.: Possui uma API e bibliotecas específicas para várias linguagens de programação, além de um servidor que atua como um proxy para requisições web. O Selenium RC, também chamado de Selenium 1, executa aplicações javascript dentro do navegador.

Selenium WebDriver.: A principal função é automatizar ações de usuários em qualquer navegador utilizando recursos nativos para controlá-lo de forma direta, possibilitando adequação do código-fonte para qualquer necessidade específica juntamente com a integração de algum framework de testes unitários (como por exemplo, o JUnit). Pode-se dizer que é uma evolução do Selenium RC.

Selenium Grid.: Possibilita a distribuição de testes em diversas máquinas para execução em paralelo.

Nos próximos posts, passarei a detalhar a instalação, configuração e a utilização de cada um dos componentes do Selenium. A idéia é explicar de forma simples o conceito de cada componente com exemplos práticos associados.

Testar é garantir a informação!

5 Características Importantes - Inspeção de Artefatos de Software

A inspeção de artefatos de software é um tipo de revisão que pode ser aplicado em todas as fases do ciclo de vida de um software, portanto quando aplicada da forma correta torna-se uma atividade cíclica e fundamental no processo de teste. Há algum tempo trabalho com inspeção de artefatos e é possível verificar que alguns problemas se repetem com certa frequência. Sendo assim, elencarei abaixo 5 características que o analista deve possuir para realização de uma boa inspeção de artefatos.:

• Comprometimento - O analista deve entender que a inspeção é um processo sério e formal, que implica em ações impeditivas para construção do software e/ou geração de indicadores que irão demonstrar a qualidade do produto que está sendo desenvolvido.

• Análise Crítica - O analista deve sempre entender que não existe defeito "bobo", simplesmente existe defeito! Portanto é essencial que o analista tenha uma visão pontual do artefato que está inspecionando e a visão global do processo. Também vale a pena ressaltar que "cada artefato é único", isto significa que o artefato deve ser inspecionado de forma isolada desconsiderando o que já foi inspecionado anteriormente (O analista deve se libertar da idéia: "Já inspecionei isto antes!"). O requisito do cliente é determinante, e uma vez que este seja previsto em checklists de verificação deve ser considerado como referência exclusiva.

• Conhecimento - Este é requisito básico e primordial para a inspeção. Um bom analista que realiza inspeção deve possuir atributos técnicos, conhecimento de negócio, entendimento de processo e documentação, bem como uma série de outros atributos. Aqui temos um ponto de atenção, pois este tipo de profissional quando alcança um certo grau de maturidade na função pode entender que alguns defeitos não são relevantes para o processo ou realizar a inspeção de forma automática, somente focando em pontos principais que defeitos ocorrem com maior frequência.

• Precisão e Autonomia - Deve-se ter a certeza absoluta de que o defeito identificado no artefato realmente é pertinente e passível de apontamento. Lembrando que qualquer apontamento realizado de forma incorreta, poderá acarretar em conflitos desnecessários e gerar enfraquecimento da imagem equipe de qualidade.

• Escrita - Ao identificar os defeitos, os mesmos serão documentados em alguma ferramenta ou documento específico. Dessa forma, o analista deve descrever o defeito com clareza, de forma sintética e buscando não ofender os responsáveis pela construção do artefato.

Testar é garantir a informação!

Simplificando... Garantia da Qualidade x Controle da Qualidade

Atualmente vemos uma grande confusão no mercado referente aos termos Garantia da Qualidade e Controle da Qualidade. Sem dúvidas que isto se deve ao fato de que em muitos casos os profissionais da área de tecnologia da informação não estão muito interessados na parte conceitual e teórica de seu trabalho. No entanto, este é um problema pois como posso trabalhar com algo que não sei nem explicá-lo? Ou pior, como posso querer trabalhar com algo que não quero nem explicá-lo? Pois é, e você sabe que este cenário é uma constante em nossa área.
 
Portanto, baseado em experiências de mercado, artigos de internet e livros específicos da área, neste post irei mostrar de forma simples e direta as diferenças entre Garantia e Controle da Qualidade de Software. Para distinguirmos estes termos, precisamos entender ao que se refere a Qualidade. "Qualidade é o grau no qual um conjunto de características inerentes satisfaz aos requisitos" (NBR ISO 9000:2005). No caso específico da Qualidade de Software, podemos entendê-la justamente da mesma forma, porém aplicada às necessidades e anseios do cliente referentes ao produto final de software, ou seja, o software deve estar em conformidade com todos os seus requisitos pré-determinados.

A Garantia da Qualidade de Software é um processo macro composto por algumas atividades como por exemplo o Teste de Software, Gerenciamento de Configuração e Controle da Qualidade. Na garantia de Qualidade o foco é na definição dos processos que darão subsídios e fornecerão confiança para que os produtos seja construídos corretamente de acordo com seus requisitos.

Diante desta definição, já podemos perceber que a Garantia da Qualidade é um processo macro que contempla em sua própria estrutura o Controle da Qualidade. Este por sua vez é focado em revisões e inspeções baseadas em checklists como foco na detecção e remoção de defeitos antes que os produtos sejam finalizados.

Na imagem abaixo, podemos verificar a relação entre os termos.:

A tabela abaixo demonstra as principais diferenças entre as duas atividades.:

Quality Assurance	Quality Control
1. Garantia da qualidade garante que o processo é definido e apropriado.	1. As atividades de controle da qualidade focam na descoberta de defeitos em i específicos.
2. Metodologia e padrões de desenvolvimento são exemplos de garantia da qualidade.	2. Um exemplo de controle da qualidade poderia ser: "Os requisitos definidos são os requisitos certos?".
3. Garantia da qualidade é orientada a processo.	3. Controle da qualidade é orientado a produto.
4. Garantia da qualidade é orientada a prevenção.	4. Controle da qualidade é orientado a detecção.
5. Foco em monitoração e melhoria de processo.	5. Inspeções e garantia de que o produto de trabalho atenda aos requisitos especificados.
6. As atividades são focadas no inicio das fases no ciclo de vida de desenvolvimento de software.	6. As atividades são focadas no final das fases no ciclo de vida de desenvolvimento de software.
7. Garantia da qualidade garante que você está fazendo certo as coisas e da maneira correta.	7. Controle da qualidade garante que os resultados do seu trabalho são os esperados conforme requisitos.

Fonte: Quality Assurance is not Quality Control.

Bom, como vimos os conceitos não possuem nenhuma dificuldade fora do comum mas sem o conhecimento dos mesmos torna-se inviável a estruturação de qualquer equipe de qualidade e/ou o entendimento de áreas que atuam baseadas nestes conceitos. Cada vez mais as grandes organizações entendem e investem em Qualidade de Software, portanto o envolvimento e comprometimento nesta área por parte dos profissionais já é tratado como um diferencial mercadológico.

Testar é garantir a informação!

Roteiros de Teste Funcional - "Visualizando a funcionalidade na prática"

O Teste Funcional garante que todas as funcionalidades do sistema estão sendo executadas corretamente, bem como o comportamento do mesmo está ocorrendo conforme previsto na fase de levantamento de requisitos. Portanto, é essencial que criemos um roteiro de teste funcional levando em consideração a necessidade específica do usuário final, levando em consideração todas suas ações para com o sistema. 

Nesta fase, entende-se que as partes internas do componente está construída corretamente e agora iremos verificar se de fato a junção dos componentes está reagindo corretamente de acordo com as necessidades do usuário, funcionalidades e particularidades específicas do sistema. É importante lembrarmos que nesta fase também é necessária a modelagem dos casos de teste com erro em sua execução (Testes Negativos).

Existem diversas técnicas de modelagem de teste funcionais, abaixo estão elencadas algumas destas que estão descritas no Syllabus do exame CTAL-TA (ISTQB).:

Técnicas Baseada em Especificações
Partição de Equivalência
Análise de Valores-Limite
Tabela de Decisão
Gráficos Causa-Efeito
Testes de Transição de Estados
Técnicas de Testes Combinatórios
Teste de Caso de Uso
Teste de Estória de Usuário
Combinação de Técnicas

Técnicas Baseada na Experiência
Suposição de Erros
Teste Baseado em Checklists
Teste Exploratório

Teste de Características de Qualidade de Software
Teste de Acurácia
Teste de Adequação
Teste de Interoperabilidade
Teste de Usabilidade
Teste de Acessibilidade

Em outros post, entraremos a fundo em cada uma destas técnicas que influenciam na modelagem e levantamento dos casos de teste necessários para verificarmos corretamente o comportamento do sistema. 

Conceitualmente, para cada funcionalidade ou caso de uso do sistema deve haver um roteiro de teste funcional que deverá garantir que a mesma está gerando as saídas esperadas para o usuário final. Neste mesmo sentido, cada fluxo descrito no requisito deverá corresponder no mínimo a um caso de teste do roteiro, lembrando que existem fluxos básicos, alternativos e de exceção. O teste funcional deve sempre pensar no teste a partir da perspeciva do usuário do sistema.

Várias ferramentas de mercado realizam o gerenciamento e modelagem dos casos de teste, relacionando-os com seus casos de uso, fluxos e passos de execução,posteriormente também é possível gerar métricas e relatórios finais dos testes. Um exemplo é a ferramenta TestLink, em outros posts já disponibilizamos um guia específico de utilização deste software.

Abaixo estão descritos alguns casos de teste simples já relacionados com seus respectivos fluxos referentes ao caso de uso Consultar Cliente. Este exemplo contém apenas 1 fluxo básico, 1 alternativo e 1 de exceção.:




A estrutura do RTF é semelhante aos demais roteiros, porém seu conteúdo deve ser bem detalhado para que os executores do teste consigam realizar o teste corretamente.:

• Código/Número.: Normalmente pode-se colocar a referência do sistema a ser testado
• Funcionalidade/Caso de Uso.: Nomenclatura da funcionalidade
• Condição.: Cenário a ser testado
• Pré-Condições.: Situações necessárias para que o teste seja executado (Ex.: Perfis, Acessos, Configurações, Execuções anteriores)
• Dados de Entrada.: Passo-a-passo detalhado para que o testador consiga executar o teste com sucesso
• Resultado Esperado.: Saídas específicas geradas após a execução do teste
• Status do Teste.: Indicação da realização do teste (Ex.: Ok, Nok, Não testado)
• Local de Teste.: Indicação da tela, interface, local onde o executor realizou o teste
• Observações - Comentários pertinentes ao teste. Neste campo, pode-se indicar se refere a um Teste negativo, positivo ou regressão. Também pode-se indicar a técnica de teste utilizada ou ciclo de teste que está sendo executado.

Após esta breve descrição sobre Roteiro de Teste Funcional, encerramos esta série específica de três posts. Caso tenham alguma dúvida, sugestão ou necessidade específica entre em contato.

Testar é garantir a informação!

Roteiros de Teste integrado - "Consolidando Relacionamentos"

Após dissertarmos à respeito dos rtu's (roteiros de teste unitário), passaremos a explicar de forma macro todos os conceitos referentes 
ao teste de integração entre componentes, os RTI's. Aparentemente, parece simples porém na prática percebemos no mercado uma real dificuldade na identificação do que deve ser testado em nível de integração que ainda não tenha sido testado em nível unitário e não será posteriormente testado em nível funcional.

Sendo assim, inicialmente necessitamos ter bem definido em nossas mentes o conceito de teste integrado. Teste de integração é a fase do teste de software em que módulos são combinados e testados em grupo. Ela sucede o teste de unidade, em que os módulos são testados individualmente, e antecede o teste de sistema, em que o sistema completo (integrado) é testado num ambiente que simula o ambiente de produção (Origem: Wikipédia, a enciclopédia livre).

Nesta fase da elaboração do Roteiro de Teste Integrado, podemos utilizar ainda as técnicas de teste caixa-branca (Considerar a estrutura interna do componente) e caixa preta (Considerar a estrutura externa, front-end), pois em muitos casos é essencial sabermos os valores de entrada e saída de "n" variáveis distintas bem como a chamada de módulos específicos, liberação de marcas e mudança de status em flags do sistema.

É importante ressaltar que nesta fase, o resultado final da funcionalidade ainda não interessa, pois esta validação será feita na fase do Roteiro de Teste Funcional, por exemplo.: "Verificar se após o usuário digitar seu nome e senha, seus dados foram retornados corretamente conforme o esperado pela funcionalidade e definido anteriormente na fase de levantamento de requisitos junto ao cliente".

Basicamente, podemos testar componentes do sistema de forma integrada de acordo com as seguintes técnicas abaixo listadas (Lembrando que todas as integrações possíveis entre componentes devem ser consideradas e inseridas no roteiro).:

Teste Incremental.: Componentes ou sistemas são integrados e testados sozinhos ou em pequenos grupos por vez, até que todos os componentes ou sistemas sejam testados (Glossário de Termos de Teste - ISTQB, CTFL, Versão 1.3 ). Sendo assim, consideramos que os testes são construídos e testados pequenos incrementos, em que erros são mais fáceis de corrigir (Ex.: Top Down e Bottom Up).

Top Down.: Componente na parte superior da hierarquia de componentes é testado primeiro, e os componentes nos níveis mais baixos são simulados por stubs(Glossário de Termos de Teste - ISTQB, CTFL, Versão 1.3 ).

Bottom up.: Componentes de nível mais baixo são testados em primeiro lugar, e, então utilizados para facilitar o teste de componentes de nível mais alto(Glossário de Termo de Teste - ISTQB, CTFL, Versão 1.3 ).

Big bang.: Elementos de um software ou hardware, ou ainda de ambos, são combinados todos de uma vez, ao invés de em estágios, em um componente ou sistema geral(Glossário de Termos de Teste - ISTQB, CTFL, Versão 1.3 ). 

Teste de Regressão.: Quando um novo componente for integrado ao sistema, o mesmo pode apresentar erros que anteriormente não ocorriam. Portando, deve-se testar novamente os casos que já foram conduzidos anteriormente visando a descoberta de novas falhas.

Em muitos casos há a integração entre plataformas distintas (Ex.: Camada Front-End.NET e camada de negócios e acesso em Mainframe), e nestas situações também devem ser consideradas as interações entre os componentes para garantir a real eficácia e vínculo entre os argumentos e parâmetros dos mesmos. Além disso, também é importante testarmos situações de erro exceção, ou seja, casos em que a chamada do componente não é realizada com sucesso.

Um Roteiro de Teste Integrado estruturado de maneira simples, deve conter informações como.:

• Número do Caso de Teste.: Número Sequencial ou Código específico
• Condição ou Cenário.: Integração a ser testada
• Pré-Condições de execução.: Situações necessárias para que o teste seja executado (Ex.: Perfis, Acessos, Configurações, Execuções anteriores)
• Dados de Entrada.: Informações ou passos necessários para execução do teste
• Resultado Esperado.: Saídas geradas após a execução do teste
• Status do Teste.: Indicação da realização do teste (Ex.: Ok, Nok, Não testado)
• Local de Execução do Teste.: Local ou ferramenta em que a integração será testada
• Ciclo/Etapa do Teste.: Indicação do ciclo de teste a ser testado
• Observações.: Comentários pontuais pertinentes ao caso de teste

Para finalizar, vejamos na imagem abaixo todas as possibilidades e técnicas de integração que podem ser testadas no projeto "CalculoSimples".:

Testar é garantir a informação!

Roteiros de Teste Unitário - "Pequenas partes que garantem a qualidade"

De acordo com a definição do ISTQB (International Software Testing Qualification Board), o Teste Unitário (ou teste de componente) corresponde ao teste realizado com os componentes individuais de um software, considerando componente como um item mínimo de software que pode ser testado isoladamente. Trata-se de uma parte importantíssima do teste de software, pois garante que a menor unidade do sistema está funcionando corretamente considerando diversas possibilidades de entrada de dados.

Na prática, podemos entender como trechos de código específicos, consistências, métodos, rotinas, chamadas a outros módulos, entre outros testes que podem existir dentro de um item de software. Lembrando que há uma distinção de testes unitários para linguagens de plataforma distribuída (Por exemplo.: .NET, Java, PHP) e para Mainframe que basicamente se restringe a testes existentes em componentes construídos na linguagem Cobol. A quantidade de tipos distintos de itens de teste e componentes é muito maior na plataforma distribuída.

Portanto, vamos nos ater a um exemplo específico de uma classe do projetoCalculoSimples.

No roteiro de teste unitário, teremos uma cobertura mínima de 6 casos de teste (5 casos de sucesso e 1 de erro) e a variação da quantidade dependerá das entradas dos parâmetros que resultarão em saídas específicas.

É comum considerarmos no mínimo um caso de teste de execução com sucesso e todos os outros casos referentes à situações de erro, porém o ideal é criar casos de teste para todos as possibilidades e desvios lógicos existentes no componente. Neste caso específico só há uma situação de erro descrita, porém se  tivéssemos definido mais tratamentos, todos deveriam ser considerados no Roteiro de Teste Unitário. Já as chamadas dos métodos InserirValor() e TransacaoXAB01() serão considerados somente em nível de integração, pois fazem referência a outras classes.

Talvez você esteja se questionando como esta classe será testada, uma vez que este teste se refere a menor unidade do sistema e as demais partes que se relacionam com este componente talvez ainda não tenham sido construídas. Para isto, deve-se criar um componente Driver, ou seja, um componente controlador que irá realizar a chamada desta classe. Em algumas situações também pode-se criar um stub que é um dispositivo que serve para simular um componente chamado pelo programa principal, caso fosse o escopo do teste.

O ideal é que todo roteiro de teste ao ser criado considere algumas premissas básicas para que o teste seja executado com sucesso.:

 - Possibilidade de Automação
 - Possibilidade de Reprodução e Repetibilidade
 - Facilidade na Implementação
 - Execução Ágil
 - Possibilidade de Reuso / Uso Futuro

Minimamente todo roteiro de teste unitário deve conter as seguintes colunas.:

 - Número Sequencial do Caso/Item de teste
 - Condição que o caso de teste irá testar
 - Dados de entrada que possibilitarão o teste
 - Resultado esperado do teste
 - Local físico/lógico que o teste será executado
 - Status do teste
 - Observações pertinentes ao teste

No mercado existem diversos frameworks e técnicas de teste unitário que abordaremos detalhadamente em outros posts.

No imagem a seguir, pode-se visualizar um exemplo contendo o dois casos unitários modelados (1 positivo e 1 negativo) da classe Matemática.

Testar é garantir a informação!