Mostrando postagens com marcador Execução de Teste. Mostrar todas as postagens
Mostrando postagens com marcador Execução de Teste. Mostrar todas as postagens

quarta-feira, 6 de janeiro de 2010

VSTS – Visual Studio Team System para Testadores – Unit Test

Após o primeiro post sobre o VSTS – Visual Studio Team System para Testadores – Introdução vamos dar continuidade falando um pouco sobre teste unitário no VSTS.

O título desse post fala que é para Testadores, mas se você é um Desenvolvedor de software e não faz Unit Test, está mais do que na hora de começar a fazê-los. Dizem que propaganda é a alma do negócio, certo? Eu digo que Qualidade é o coração do sistema. Não pense que testar é responsabilidade única e exclusiva dos testadores.

O teste unitário (Unit Test) ou de unidade é um tipo de teste que foca na verificação da menor unidade do projeto de software. É realizado o teste de uma unidade lógica, com uso de dados suficientes para se testar apenas a lógica da unidade em questão. Um exemplo em sistemas desenvolvidos em linguagens orientadas a objetos, como C# e Java, essa unidade pode ser identificada como um método, uma classe ou mesmo um objeto.

Podemos dizer que este tipo de teste foca na arquitetura do sistema e é de responsabilidade do próprio desenvolvedor criar esses testes em tempo de implementação do sistema, isto é, após codificar uma classe, por exemplo, ele planeja, codifica e executa o teste de unidade.

Em resumo, um teste unitário executa um método individualmente e compara uma saída conhecida após o processamento da mesma.

Considero o teste unitário o principal teste na cadeia de teste e que vai garantir que o código que foi desenvolvido para o sistema em questão tenha “qualidade”. Claro que todos os outros testes da cadeia são extremamente importante, mas como o teste unitário está no início da cadeia, devemos fazer a coisa certa desde o início.

Para vocês verificarem como o teste unitário é importante, basta olhar no Modelo V de desenvolvimento, esse teste é o primeiro da cadeia.

Modelo V

Se observamos o Agile Testing Quadrants [1] iremos constatar que o Q1, ou seja, primeiro quadrante tem o nosso bom e velho amigo Teste Unitário.

Agile Testing Quadrants

  • Q1 – São os testes que focam na arquitetura. A responsabilidade é dos desenvolvedores e os analistas de teste auxiliam na elaboração dos testes unitários automáticos
  • Q2 – São os testes que focam no negócio. A responsabilidade é dos analistas de teste em conjunto com outros envolvidos no projeto(clientes, usuários, etc..). Ajuda no entendimento das funcionalidades
  • Q3 – São os testes que focam no negócio e encontrar defeitos. A responsabilidade é dos analistas de teste
  • Q4 – São os testes que focam na arquitetura, estrutura do software. A responsabilidade é dos analistas de teste

Bem, agora que já falamos um pouco sobre teste unitário vamos colocar a mão na massa. Para isso, vamos criar um novo projeto Class Library como exemplo chamado Text Validation na nossa Solution. Para fazer isso bastar clicar com o botão direito na Solution, acessar o menu Add / New Project. Na parte esquerda da tela selecionar a opção Visual C# como Project types e na parte direita da tela selecionar Class Library como Template. Feito isso, basta digitar o nome Text Validation no campo Name e confirmar a operação pressionando o botão OK.

A idéia é utilizar essa Class Library como o projeto que será aplicado o teste unitário.

Add New Class Library

Após a criação com sucesso, a Solution é apresentada com a Class Library criada da seguinte forma:

Class Library Text Validation Created

Agora vamos alterar o nome do arquivo Class1.cs para Text_Validation.cs. Neste caso, selecione o arquivo Class1.cs e pressione F2 que o mesmo entrará em modo de edição do nome do arquivo e digite Text_Validation.cs. Pronto, já estamos preparados para inserir o código da nossa Classe.

Nessa classe teremos 2 métodos:

  • GetDelimitator(): Retorna o delimitador de string utilizado na aplicação;
  • isEmail(string pStrEmail): Retorna sucesso (true) se o email informado para validação for um email com o formato válido.

Abaixo segue o código da classe que iremos utilizar como exemplo para o nosso teste unitário.

using System.Text.RegularExpressions;

namespace Text_Validation

{

    public class Text

    {

        /// <summary>

        /// Retorna o delimitador de string utilizado na aplicação

        /// </summary>

        public char GetDelimitator()

        {

            return ';';

        }

 

        /// <summary>

        /// Retorna sucesso (true) se o email informado para validação for um email com o formato válido

        /// </summary>

        /// <param name="pStrEmail">Email alvo para validação de formato</param>

        public bool isEmail(string pStrEmail)

        {

            string strRegex = @"^([a-zA-Z0-9_\-\.]+)@((\[[0-9]{1,3}" +

                  @"\.[0-9]{1,3}\.[0-9]{1,3}\.)|(([a-zA-Z0-9\-]+\" +

                  @".)+))([a-zA-Z]{2,4}|[0-9]{1,3})(\]?)$";

            Regex re = new Regex(strRegex);

            if (re.IsMatch(pStrEmail))

            {

                return true;

            }

            return false;

        }

    }

}

O próximo passo após a criação da nossa classe de exemplo para os testes unitários é criar o projeto de Teste. A forma mais fácil que recomendo para criar o projeto de teste é a seguinte:

  • Abrir a classe que deseja criar os testes unitários;
  • Clicar com o botão direito em qualquer lugar do código, aparecerá um menu;
  • Clicar na opção Create Unit Tests…;
  • A tela abaixo será aberta com a lista de todos os métodos da classe;

Create Unit Test Current Selection

  • Selecione os métodos que deseja criar os testes unitários. No nosso exemplo iremos habilitar todas as checkboxes;
  • No campo Output project, selecione a opção Create a new Visual C# test project… e confirme a operação selecionando o botão OK;
  • Após confirmar a operação, uma dialog será mostrada para o usuário inserir o nome do projeto no campo Enter a name for your new project. Neste campo entre com o nome Unit Test Text Validation e confirme a operação selecionando o botão Create;
  • Pronto, agora sua solution tem 2 projetos como mostrado abaixo.

Unit Test Project Created

O código gerado pelo Visual Studio deve ser alterado de acordo com a sua necessidade e cada teste que você deseja realizar. Se você abrir o arquivo TextTest.cs encontrará o seguinte código:

using Text_Validation;

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace Unit_Test_Text_Validation

{

    /// <summary>

    ///This is a test class for TextTest and is intended

    ///to contain all TextTest Unit Tests

    ///</summary>

    [TestClass()]

    public class TextTest

    {

        private TestContext testContextInstance;

        /// <summary>

        ///Gets or sets the test context which provides

        ///information about and functionality for the current test run.

        ///</summary>

        public TestContext TestContext

        {

            get

            {

                return testContextInstance;

            }

            set

            {

                testContextInstance = value;

            }

        }

 

        /// <summary>

        ///A test for isEmail

        ///</summary>

        [TestMethod()]

        public void isEmailTest()

        {

            Text target = new Text(); // TODO: Initialize to an appropriate value

            string pStrEmail = string.Empty; // TODO: Initialize to an appropriate value

            bool expected = false; // TODO: Initialize to an appropriate value

            bool actual;

            actual = target.isEmail(pStrEmail);

            Assert.AreEqual(expected, actual);

            Assert.Inconclusive("Verify the correctness of this test method.");

        }

 

        /// <summary>

        ///A test for GetDelimitator

        ///</summary>

        [TestMethod()]

        public void GetDelimitatorTest()

        {

            Text target = new Text(); // TODO: Initialize to an appropriate value

            char expected = '\0'; // TODO: Initialize to an appropriate value

            char actual;

            actual = target.GetDelimitator();

            Assert.AreEqual(expected, actual);

            Assert.Inconclusive("Verify the correctness of this test method.");

        }

 

        /// <summary>

        ///A test for Text Constructor

        ///</summary>

        [TestMethod()]

        public void TextConstructorTest()

        {

            Text target = new Text();

            Assert.Inconclusive("TODO: Implement code to verify target");

        }

    }

}

Se observarmos a classe unit test acima, facilmente identificamos suas diferenças se compararmos com uma classe básica (como no exemplo da classe Text que criamos no projeto Text Validation). A classe possui o atributo [TestClass], identificando que é uma classe de testes e cada método também possui um atributo [TestMethod] identificando o método como sendo de testes. [2]

Outro ponto importante é observar que o namespace (using Microsoft.VisualStudio.TestTools.UnitTesting; ) importado na nossa classe de teste é utilizado para disponibilizar diversas funcionalidades de testes que podem ser usadas na classe do seu unit test. Esse namespace disponibiliza também a classe Assert, que dispõe de diversos métodos estáticos para validação e execução dos testes. O método AreEqual, por exemplo, em uma de suas sobrecargas, recebe por parâmetro o valor esperado da execução do teste e o valor que será enviado para validação de acordo com o método chamado como exemplo abaixo:

[TestMethod()]

        public void GetDelimitatorTest()

        {

            Text target = new Text(); // TODO: Initialize to an appropriate value

            char expected = '\0'; // TODO: Initialize to an appropriate value

            char actual;

            actual = target.GetDelimitator();

            Assert.AreEqual(expected, actual);

            Assert.Inconclusive("Verify the correctness of this test method.");

        }

Além da criação das classes de teste, ainda é possível executá-las, saber o resultado e armazená-las para comparação posterior. Agora vamos executar todos os testes criados sem alterar uma linha de código para ver qual será o resultado. Para isso, acesse o menu Test / Windows / Test List Editor. Em seguida selecione todos os testes habilitando o checkbox ao lado esquerdo do teste e click na opção Run Checked Tests como mostrado na imagem abaixo.

Run Checked Tests

Após a execução dos testes você irá perceber que os testes não tiveram seu resultado como Passed, afinal, não fizemos nenhuma alteração do código e isso era o esperado. Neste caso, tivemos 2 testes com o resultado Inconclusive e 1 com o resultado Failed como podemos observar o resultado da nossa execução abaixo.

Test Executed No Changes

Como o nosso objetivo é ter todos os casos de teste unitário com o resultados Passed, vamos fazer as devidas alterações para testar o que queremos.

Primeiro, vamos alterar o TestMethod isEmailTest(). O objetivo do nosso teste é garantir que o método isEmail(string pStrEmail) da classe Text do nosso projeto Text Validation retorna true se o email informado para validação for um email com o formato válido. Para isso devemos fazer a seguinte alteração no nosso código:

        [TestMethod()]

        public void isEmailTest()

        {

            Text target = new Text();

            string pStrEmail = "teste@teste.com.br";

            bool expected = true;

            bool actual;

            actual = target.isEmail(pStrEmail);

            Assert.AreEqual(expected, actual);

        }

Segundo, vamos alterar o TestMethod GetDelimitatorTest(). O objetivo do nosso teste é garantir que o método getDelimitator() da classe Text do nosso projeto Text Validation retorna o delimitador de string utilizado na aplicação, que neste caso é o valor ';'. Para isso devemos fazer a seguinte alteração no nosso código:

        [TestMethod()]

        public void GetDelimitatorTest()

        {

            Text target = new Text();

            char expected = ';';

            char actual;

            actual = target.GetDelimitator();

            Assert.AreEqual(expected, actual);

        }

Por último, vamos alterar o TestMethod TextConstructorTest(). Neste caso, o nosso objetivo é simplesmente garantir que conseguimos criar um objetivo do tipo Text não nulo. Para isso devemos fazer a seguinte alteração no nosso código:

        [TestMethod()]

        public void TextConstructorTest()

        {

            Text target = new Text();

            Assert.IsNotNull(target);

        }

Pronto, agora é mandar executar os testes e verificar o resultado :-). Se tudo deu certo, todos os seus testes estão com o status Passed como na imagem abaixo:

Test Executed Passed

Para quem não percebeu, todos os métodos de teste que tinham o método Assert.Inconclusive foram removidos, mas por que isso aconteceu?

O método Assert.Inconclusive indica que uma declaração não pode ser comprovado verdadeiro ou falso ou para indicar uma declaração que ainda não foi implementada. Por isso que depois de implementar todas as nossas alterações, removemos esse método. Segue a lista de sobrecarga para este caso:

Nome

Descrição

Inconclusive() Indica que a declaração não pode ser verificada.
Inconclusive(String) Indica que a declaração não pode ser verificada. Exibe uma mensagem.
Inconclusive(String, Object[]) Indica que a declaração não pode ser verificada. Exibe uma mensagem e aplica a formatação especificada pra ele.

Espero que tenham gostado!

Até+,

Quezada

Referências:

  1. Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin and Janet Gregory
  2. Visual Studio Team System Rocks by Alércio Bressano, Alexandre Tarifa, Andrey Sanches, Clementino Mendonça, Emerson Facunte, Fábio Câmara, Fábio Hirota, Hélio Sá Moreira, Igor Abade V. Leite e Mauro Sant’Anna

terça-feira, 15 de dezembro de 2009

VSTS – Visual Studio Team System para Testadores – Introdução

Antes de falar um pouco sobre o Visual Studio Tem System (VSTS), devemos entender um pouco sobre o papel do testador no ciclo de desenvolvimento de software. Resumidamente, podemos dizer que a função do testador é garantir a qualidade do produto e, para isso, o trabalho dele no ciclo de desenvolvimento de software é:

  • Auxiliar os desenvolvedores na elaboração dos testes unitários automáticos;
  • Montar e configurar o ambiente e infra-estrutura de teste;
  • Escrever casos de teste;
  • Executar testes;
  • Automatizar casos e tarefas de teste;
  • Evidenciar os resultados;
  • Acompanhar os defeitos encontrados;
  • Desenvolver novas habilidades;
  • O Analista de Teste é “o cara que aprova”. Nada é considerado “pronto” sem que ele diga que está.

Bem, agora que você já sabe um pouco sobre o papel do testador no ciclo de desenvolvimento de software, é necessário saber quais os testes que podem ser aplicados ao projeto (qualquer projeto que está sendo desenvolvido e que o testador esteja participando) de teste. Abaixo temos alguns exemplos:

Unit e Component Tests: São os testes que focam na arquitetura. Esses testes são executados automaticamente e a responsabilidade é dos desenvolvedores. Os testadores devem auxiliar os desenvolvedores na elaboração desses testes.

Functional e Story Tests, Simulations, Prototypes: São os testes que focam no negócio. Esses testes são executados automaticamente/manualmente e a responsabilidade é dos testadores em conjunto com outros envolvidos (clientes, usuários, etc.) no projeto. Neste caso, esses tipos de teste ajudam no entendimento das funcionalidades.

Scenarios, Exploratory, Usability, User Acceptance Testing: São os testes que focam no negócio e encontrar defeitos. Esses testes são executados manualmente e a responsabilidade é dos testadores. Neste caso, esses tipos de teste ajudam a encontrar o maior número de defeitos possível.

Performance, Load e Security Testing: São os testes que focam na arquitetura e estrutura do software. Esses testes são executados por ferramentas capazes de simular cenários de testes, por exemplo: Ter 10.000 usuários registrados no sistema simultaneamente. A responsabilidade da execução desses testes é dos testadores. Neste caso, esses tipos de testes ajudam identificar se a aplicação/software que está sendo testado é robusto suficiente.

Neste momento, já sabemos o papel do testador no ciclo de desenvolvimento de software e também quais os testes que podem ser aplicados aos projetos. Agora chegou o momento de criar um Projeto de Teste e incluir todos os seus artefatos de teste. Para isso, basta acessar o menu File / New / Project. Após acessar este menu, a janela abaixo será aberta e basta você selecionar a opção Test Project / Test Documents no menu (árvore) da esquerda. Feito isso, selecione o template Test Project informando o nome do projeto no campo Name.

VSTS New Test Project

Feito isso chegou a hora de Conhecer a IDE de Testes no Visual Studio.

A IDE (Integrated Development Environment) possui um leque amplo de ferramentas para manipular testes e que auxiliam muito o testador no dia-a-dia de trabalho. Para acessar as funcionalidades relacionadas com testes do Visual Studio, basta acessar o menu Test / Window. Abaixo temos a lista das principais funcionalidades:

  • Solution Explorer: essa janela apresenta uma listagem dos arquivos presentes em cada solution envolvendo projetos, arquivos de teste, etc;

VSTS Solution Explorer 

  • Test Manager: através dessa janela é possível executar os testes visualizando-os de diversas formas, adicionar novos testes, agrupar, ordenar e localizar testes na listagem;

VSTS Test Manager

  • Test Result: com essa opção, podemos visualizar todos os resultados de testes executados no projeto. Essa janela demonstrará se o teste foi executado com sucesso ou se houve erros durante a execução. A partir dessa janela também é possível reexecutar o teste que acabou de ser rodado;

VSTS Test Result

  • Code Coverage Results: se essa opção estiver habilitada, é possível visualizar as coberturas de códigos em determinadas execuções de teste, observando o percentual de código executado para cada método;

VSTS Code Coverage Results

  • Test Runs: essa janela permite acompanhar uma fila de execução de testes, a fim de identificar testes que estão esperando para serem executados, testes em execução, já executados e diversas opções desse gênero;

VSTS Test Runs

  • Test View: a janela Test View é a forma mais rápida de executar um teste. Através dela podemos executar inclusive em modo Debug, podendo acompanhar a execução passo a passo do método selecionado. Além disso, podemos configurar diversas propriedades de cada testes presente nessa janela.

VSTS Test View

Até+,

Quezada

 

Referências:

  1. Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin and Janet Gregory
  2. Visual Studio Team System Rocks by Alércio Bressano, Alexandre Tarifa, Andrey Sanches, Clementino Mendonça, Emerson Facunte, Fábio Câmara, Fábio Hirota, Hélio Sá Moreira, Igor Abade V. Leite e Mauro Sant’Anna

quinta-feira, 13 de agosto de 2009

Execução e Relatório de Teste

Para continuar com o assunto “Relatório de Execução de Teste”, hoje vamos mostrar um pouco mais sobre Execução de Teste. A idéia deste post é auxiliar você com as atividades de planejamento, execução e relatórios de teste.

Após a fase de Análise e Design de Teste ser concluída, chega à hora de entrar na fase de Execução de Teste. A primeira coisa que deve ser feita antes de começar a execução efetivamente é planejar e/ou rever o planejamento dessa fase. Para ajudar nesse planejamento uma boa prática é utilizar um Gráfico para mostrar o planejado versus o atual e, neste caso, nada melhor do que o Gráfico Curva-S. Abaixo temos a Tabela 1 – Gráfico Curva-S, a qual é utilizada para fazer o planejamento da execução dos casos de teste.


Tabela 1 – Gráfico Curva-S

Para facilitar o entendimento da tabela acima, segue abaixo a descrição de cada coluna:
  • Data: data de execução planejada;
  • Total Planejado: número total de casos de teste planejado para execução;
  • Total Planejado Acumulativo: número total de casos de teste planejado acumulativo;
  • Total Passado Planejado: número total de casos de teste passados no dia;
  • Total Passado: número total de casos de teste passados acumulados;
  • Total Falhado Planejado: número total de casos de teste falhados no dia;
  • Total Falhado: número total de casos de teste falhados acumulados;
  • Total Bloqueado Planejado: número total de casos de teste bloqueados no dia;
  • Total Bloqueado: número total de casos de teste bloqueados acumulados;
  • Total Atingido: número total de casos de teste executados até o momento somando, total passado, total falhado, total bloqueado;
  • Comentário Execução: comentários gerais do planejamento.

Após a criação da tabela acima, basta gerar gráfico incluindo os campos Data, Total Planejado Acumulativo, Total Passado, Total Falhado, Total Bloqueado, Total Atingido, como mostrado abaixo na Figura 1 – Gráfico Curva-S.


Figura 1 – Gráfico Curva-S

Após a criação do Gráfico Curva-s, obtém-se o número total de casos de teste que foram planejados para execução incluindo os novos casos de teste, porcentagem de casos passados, falhados e bloqueados e casos de teste de regressão. Com isso é possível verificar se o planejamento feito anteriormente está de acordo com o atual, caso seja necessário, um novo re-planejamento deve ser feito e as partes interessadas informadas. Vale lembrar que a criação dos ciclos de teste deve ser planejada de acordo com o progresso da execução, estabilidade do software e critério de saída. Quando o planejamento está concluído, chega a hora da execução dos testes.
Os casos de teste são executados usando os procedimentos documentados e/ou automáticos do script de teste. Para que a fase de execução de teste seja executada com sucesso deve-se:

  • Executar os casos de teste usando o documento de procedimentos de teste e/ou scripts de teste;
  • Registrar o resultado atual;
  • Comparar o resultado atual com o resultado esperado;
  • Se necessário, repetir a execução de um caso de teste quando um incidente é encontrado, ou seja, devemos fazer o teste de confirmação;
  • Executar testes de regressão como planejado.

Devido ao alto risco de mudança do código entre a execução de um ciclo e outro, deve-se ter uma política de re-teste bem definida.
Em alguns casos, testes podem ser executados “informalmente” sem usar procedimentos de teste detalhado, como por exemplo: teste exploratório.

Relatórios de Teste
Sempre que é encontrado um incidente de teste na fase de execução é necessário relatar esse incidente. Para isso, deve-se definir os relatórios necessários para acompanhar o progresso do(s) projeto(s) de teste segundo a norma IEEE 829-1998. Os relatórios de teste que a IEEE sugere são os seguintes:

  • Relatório de Log de Teste;
  • Relatório de incidentes de Teste;
  • Relatório de Sumário de Teste.

Para ajudar no entendimento de como chegamos aos relatórios acima, segue abaixo a Figura 2 – Relação de documentos de teste para o processo de teste - IEEE 829.



Figura 2 – Relação de documentos de teste para o processo de teste - IEEE 829 -1998

Relatório de Log de Teste
Tudo o que for relevante durante a fase de execução de teste deve ser reportada no relatório de log de teste.
Segundo a norma IEEE 829 o relatório de log de teste deve ter as seguintes informações:
  • Identificador: identificador único e específico para o relatório, por exemplo, o nome do sistema com número do release mais data e hora do teste;
  • Descrição: identificar o que foi testado e o ambiente em que o teste foi executado incluindo hardware, quantidade de memória utilizada, etc;
  • Atividades e eventos: para cada evento, identificar data/hora, tempo utilizado e responsável;
  • Descrição da execução: descrever o que foi feito e identificar os responsáveis pela atividade incluindo testadores, observadores e operadores;
  • Resultados dos procedimentos: para cada execução, descrever os resultados encontrados podendo ser sucesso ou não;
  • Informações sobre ambiente de teste: informar qualquer condição específica do ambiente de teste, caso seja necessário;
  • Eventos imprevistos: descrever detalhadamente o que aconteceu antes e depois de uma atividade ou evento inesperado.

Vale lembrar que outras informações podem ser incluídas sempre que necessário.

Relatório de Incidentes de Teste
Toda e qualquer discrepância entre o resultado esperado e o encontrado na execução dos casos de teste devem ser reportados para o time de desenvolvimento com o máximo de detalhes possíveis. Nesse caso, é utilizado o relatório de incidentes de teste o qual é registrado todos os defeitos encontrados durante a fase de execução de teste.
Segundo a norma IEEE 829 o relatório de incidente de teste deve ter as seguintes informações:

  • Identificador do relatório: identificador único e específico para o relatório, por exemplo, release testado mais o identificador de um caso de teste ;
  • Sumário da ocorrência: uma breve descrição do incidente; identificar os itens de teste envolvidos indicando sua versão, caso seja necessário; adicionar referência para a especificação do caso de teste, assim o desenvolvedor que for corrigir o defeito terá uma base de documento de teste além do documento de requisitos e adicionar também o relatório de log de teste, se necessário;
  • Descrição do incidente: prover uma descrição do incidente incluindo os seguintes itens:
  • ==>Entradas;
  • ==>Resultados esperados;
  • ==>Resultados encontrados;
  • ==>Problemas;
  • ==>Data e hora do incidente;
  • ==>Procedimentos para reproduzir o problema;
  • ==>Ambiente;
  • ==>Tentativas para repetir o problema;
  • ==>Testadores;
  • ==>Observadores.

Vale lembrar que outras informações podem ser incluídas sempre que necessário e nem sempre todos os campos acima serão necessários.

  • Impacto: indicar qual o impacto que o incidente terá no plano de teste de execução podendo falhar, bloquear o(s) testes(s) ou até mesmo uma possível mudança no caso de teste ou requisitos. Se possível, informar a prioridade e severidade do incidente.
    Os incidentes de teste devem ser armazenados em um repositório e, caso necessário, revisar o relatório de incidentes de teste com as partes interessadas.

Relatório de Sumário de Teste
Fornecer um sumário das atividades de teste incluindo os resultados, como o próprio nome do relatório já diz, relatório de sumário de teste. A idéia é resumir as atividades realizadas na execução dos testes.
Segundo a norma IEEE 829 o relatório de sumário de teste deve ter as seguintes informações:

  • Identificador: identificador único e específico para o relatório, por exemplo, release e/ou projeto testado;
  • Sumário: sumarizar a evolução das atividades de teste identificando os itens testados e o ambiente utilizado para execução dos testes;
  • Variações: informar qualquer procedimento diferente do que estava especificado no plano de teste e procedimentos de teste; especificar o motivo da utilização do procedimento alternativo;
  • Avaliações do processo: avaliação resumida do processo adotado contra o especificado no plano de teste; identificar as funcionalidades ou combinações de teste que não foram exercitadas explicando a razão; qualquer ocorrência que possa impactar na qualidade do software/produto deve ser considerada;
  • Sumário dos resultados: sumarizar os resultados de teste identificando o número de casos de teste executados, número de defeitos encontrados, número de defeitos fechados e abertos, etc;
  • Avaliação do(s) teste(s): proporcionar uma avaliação global de cada item, incluindo suas limitações. Essa avaliação deve ser baseada nos resultados dos casos de teste e nos critérios de aprovação/reprovação;
  • Sumário de atividades: resumir os recursos envolvidos no projeto de teste, número total de horas utilizadas no projeto, tempo total utilizado para cada atividade principal, etc;
  • Aprovações: listar o nome e títulos das pessoas responsáveis pela aprovação do projeto de teste incluindo os relatórios.

Vale lembrar que outras informações podem ser incluídas sempre que necessário.

No post Relatório Parcial de Execução de Teste você pode encontrar informações adicionais sobre relatório de teste.

Até+,
Quezada