Tipos de Testes de Software

Existem diversos tipos de testes de software.

• Teste aleatório: Técnica de teste caixa preta onde os casos de teste são selecionados de acordo com um perfil operacional, normalmente usando um algoritmo de geração pseudo-aleatória. Esta técnica pode ser usada para testar atributos não funcionais, como confiabilidade e performance.

• Teste alfa: Teste operacional, simulado ou real, executado por usuários/clientes em potencial ou por uma equipe independente de teste (de fora da organização) nas instalações do desenvolvedor. O teste alfa normalmente é usado como teste de aceite interno para softwares de prateleira.

• Teste back-to-back: Testes onde duas ou mais variantes de um sistema são executadas com as mesmas entradas. As saídas são comparadas e analisadas caso haja discrepância.

• Teste baseado em código: idem teste caixa branca (Teste de caixa-branca é uma técnica de teste que usa a perspectiva interna do sistema para modelar os casos de teste. No teste de software, a perspectiva interna significa basicamente o código fonte).

• Teste baseado em projetos: Técnica de teste onde os casos de teste são projetados com base na arquitetura e/ou projeto detalhado do sistema (por exemplo: testes de interface entre componentes ou sistemas).

• Teste baseado em requisitos: Técnica de teste onde os casos de teste são definidos com base nos objetivos do teste e as condições de teste derivadas dos requisitos. Por exemplo, testes que exercitam funções específicas ou investigam atributos não funcionais como confiabilidade ou usabilidade.

• Teste baseado em riscos: Testes orientados para explorar e fornecer informação a respeito dos riscos do produto.

• Teste baseado na especificação: idem teste caixa preta (Teste de caixa-preta é um teste de software para verificar a saída dos dados usando entradas de vários tipos. Tais entradas não são escolhidas conforme a estrutura do programa. Quanto mais entradas são fornecidas, mais rico será o teste).

• Teste baseado no processo do negócio: Técnica de teste onde os casos de teste são projetados com base nas descrições e/ou conhecimento do processo do negócio.

• Teste beta: Teste operacional realizado por usuários/clientes em potencial, fora das instalações do desenvolvedor, para determinar se um sistema satisfaz ou não suas necessidades e se encaixa nos processos do negócio. O teste beta normalmente é usado como um teste de aceite externo para softwares de prateleira para obter feedback do mercado.

• Teste big-bang: Um tipo de teste de integração onde os elementos do software ou hardware (ou ambos) são combinados todos de uma vez em um sistema, ao invés de serem combinados em etapas.

• Teste bottom-up: Um tipo de teste de integração incremental onde os componentes do nível mais baixo são testados e integrados primeiro. Este processo é repetido até que o componente do nível mais alto na hierarquia esteja testado. Facilita os testes dos componentes de nível mais alto.

• Teste comparativo: (1) Um padrão com o qual as medidas ou comparações podem ser feitas. (2) Um teste que pode ser usado para comparar componentes ou sistemas entre si ou com um padrão como em (1).

• Teste completo: idem teste exaustivo (Teste que inclui todas as combinações possíveis de valores de entrada e precondições).

• Testes de aceitação: Tem como objetivo confirmar que o sistema funciona de acordo com a especificação. Cada história deve estar associada a um conjunto de testes de aceitação. Tem como objetivo deixar claro para todos qual a expectativa do dono do produto (product owner) em relação ao requisito e a história do usuário.

• Teste de aceite: Teste formal das necessidades, exigências e processos de negócio do usuário conduzidos para determinar se um sistema satisfaz ou não os critérios de aceite e para permitir que o usuário, cliente ou outra entidade autorizada determinem se aceitam ou não o sistema.

• Teste de aceite do usuário: idem teste de aceite (Teste formal das necessidades, exigências e processos de negócio do usuário conduzidos para determinar se um sistema satisfaz ou não os critérios de aceite e para permitir que o usuário, cliente ou outra entidade autorizada determinem se aceitam ou não o sistema).

• Teste de aceite local: Teste de aceite executado por usuários/clientes nas suas instalações para determinar se o sistema satisfaz ou não as suas necessidades e se encaixa nos processos de negócio. Normalmente inclui hardware e software.

• Teste de acessibilidade: Teste para determinar qual o grau de facilidade com que usuários com necessidades especiais conseguem usar o sistema em teste.

• Teste de algoritmos [TMap]: idem teste de ramos (Teste que executa os ramos do software).

• Teste de arcos: idem teste de ramos (Teste que executa os ramos do software).

• Teste de armazenamento: idem teste de utilização de recursos (Teste que determina a utilização de recursos de um sistema).

• Teste de caixa-branca: é uma técnica de teste que usa a perspectiva interna do sistema para modelar os casos de teste. No teste de software, a perspectiva interna significa basicamente o código fonte.

• Teste de caixa-preta: é um teste de software para verificar a saída dos dados usando entradas de vários tipos. Tais entradas não são escolhidas conforme a estrutura do programa. Quanto mais entradas são fornecidas, mais rico será o teste.

• Teste de caminhos: Técnica de projeto de teste caixa branca onde os casos de testes são projetados para executar caminhos no software.

• Teste de campos: idem teste beta (Teste operacional realizado por usuários/clientes em potencial, fora das instalações do desenvolvedor, para determinar se um sistema satisfaz ou não suas necessidades e se encaixa nos processos do negócio. O teste beta normalmente é usado como um teste de aceite externo para softwares de prateleira para obter feedback do mercado).

• Teste de capacidade de recuperação: Processo de teste para determinar a capacidade de recuperação de um sistema.

• Teste de capacidade de serviço de manutenção: idem teste de manutenibilidade.

• Teste de casos de uso: Técnica de teste caixa preta onde os testes são projetados para executar cenários.

• Teste de cenário: idem teste de casos de uso (Técnica de teste caixa preta onde os testes são projetados para executar cenários).

• Teste de cobertura da lógica: idem teste caixa branca (teste que usa a perspectiva interna do sistema para modelar os casos de teste. No teste de software, a perspectiva interna significa basicamente o código fonte).

• Teste de comandos: Técnica de projeto de teste caixa branca onde os casos de teste são projetados para executar comandos.

• Teste de combinações de condições: idem teste de condições múltiplas (Uma técnica de projeto de teste caixa branca onde os casos de teste são projetados para executar combinações das consequências de cada condição (dentro de um comando)).

• Teste de combinações de condições dos ramos: idem teste de condições múltiplas (Uma técnica de projeto de teste caixa branca onde os casos de teste são projetados para executar combinações das consequências de cada condição (dentro de um comando)).

• Teste de comparação elementar: Técnica de projeto de teste caixa preta onde os casos de teste são projetados para executar combinações de entradas usando o conceito da cobertura de determinação de condições.

• Teste de compatibilidade: idem teste de interoperabilidade (Teste que determina a interoperabilidade do sistema).

• Teste de complacência: Processo de teste para determinar a complacência de um sistema.

• Teste de componente: Teste dos componentes de software individuais.

• Teste de concorrência: Teste para determinar como a ocorrência de duas ou mais atividades, no mesmo intervalo de tempo, iniciadas por intercalação de atividades ou execuções simultâneas, são tratadas pelo sistema.

• Teste de condições: Técnica de projeto de teste caixa branca onde os casos de teste são projetados para executar as consequências das condições.

• Teste de condições de decisão: Técnica de projeto de teste caixa branca onde os casos de teste são projetados para executar as consequências das condições e das decisões.

• Teste de condições múltiplas: Uma técnica de projeto de teste caixa branca onde os casos de teste são projetados para executar combinações das consequências de cada condição (dentro de um comando)

• Teste de confiabilidade: Processo de teste para determinar a confiabilidade de um sistema.

• Teste de confiança: idem teste de fumaça (Subconjunto de todos os casos de teste definidos/planejados que cobrem as principais funcionalidades do sistema, para verificar se eles funcionam, mas sem se preocupar com detalhes. Uma construção diária e o teste de sanidade estão entre as boas práticas da indústria).

• Teste de configuração: idem teste de portabilidade (Teste que determina a portabilidade de um sistema).

• Teste de confirmação: idem reteste (Teste de um programa previamente testado e que foi alterado para garantir que todas as partes não modificadas foram cobertas ou que não foram introduzidos defeitos nas partes não modificadas do software. Ele deve ser executado quando o software ou o ambiente for modificado).

• Teste de conformidade: idem teste de complacência (Processo de teste para determinar a complacência de um sistema).

• Teste de conversão: Teste usado para converter dados de um sistema existente para serem usados em sistemas que o substituam.

• Teste de decisão: Teste que executa as consequências das decisões.

• Teste de desenvolvimento: Teste formal ou informal conduzido durante a implementação do sistema. Geralmente é executado pelos desenvolvedores no ambiente de desenvolvimento.

• Teste de determinação de condições: Teste que executa uma condição cuja consequência afeta independentemente a consequência de uma decisão.

• Teste de documentação: Testa a qualidade dos documentos como, por exemplo, guia do usuário ou de instalação.

• Teste de eficiência: Teste que determina a eficiência do produto do software.

• Teste de entrada: Uma instância do teste de sanidade que decide se o sistema está pronto para testes mais detalhados. Um teste de entrada normalmente é feito no início da fase da execução do teste.

• Teste de escalabilidade: Teste que determina a escalabilidade de um sistema.

• Teste de estados: idem teste de transição de estados (Teste que executa transições de estados válidas e inválidas).

• Teste de fluxo de dados: Teste que executa definições e usa pares de variáveis.

• Teste de fumaça: Subconjunto de todos os casos de teste definidos/planejados que cobrem as principais funcionalidades do sistema, para verificar se eles funcionam, mas sem se preocupar com detalhes. Uma construção diária e o teste de sanidade estão entre as boas práticas da indústria.

• Teste de funcionalidade: Teste que verifica a funcionalidade de um sistema.

• Teste de grafos causa-efeito: Uma técnica de projeto de teste caixa preta onde os casos de teste são definidos a partir de grafos causa-efeito.

• Teste de instalabilidade: Testa a instalabilidade de um sistema.

• Teste de integração: Teste executado para encontrar defeitos nas interfaces e nas interações entre componentes ou sistemas integrados.

• Teste de integração de componentes: Testes executados para revelar defeitos nas interfaces e interações entre componentes integrados.

• Teste de integração de sistemas: Testa a integração dos sistemas e pacotes; testa as interfaces com organizações externas (por exemplo, troca eletrônica de dados, Internet).

• Teste de integração no grande: idem teste de integração de sistemas (Testa a integração dos sistemas e pacotes; testa as interfaces com organizações externas (por exemplo, troca eletrônica de dados, Internet)).

• Teste de integração no pequeno: idem teste de integração de componentes (Testes executados para revelar defeitos nas interfaces e interações entre componentes integrados).

• Teste de integridade do banco de dados: Testa os métodos, processos e regras usados para acessar e gerenciar os (bancos de) dados, para garantir que eles funcionem como esperado, e que, durante o acesso ao banco de dados, os dados não são corrompidos, apagados, alterados ou criados de forma inesperada.

Ferramenta para Captura de Tela

Seguem algumas ferramentas gratuitas, para captura de tela:

Greenshot: é uma ferramenta leve e gratuita, para Windows, capaz de criar screenshots de maneira inteligente. Com ela, você pode salvar a imagem daquela conversa no chat, telas de programas, sites e tudo o que desejar, diretamente no tamanho que necessita, pronto para imprimir, salvar ou enviar por e-mail. Tudo em uma interface limpa e simples de usar.

Lightshot: é um programa gratuito para Windows e Mac que permite tirar screenshots, ou prints de tela, do computador, fazer pequenas edições antes de salvar a imagem e ainda realizar o upload para obter um link quase instantâneo de compartilhamento. O app ainda oferece personalização das teclas de atalho, que podem capturar a tela inteira ou somente uma área retangular selecionada com o mouse, e pesquisa automática de imagens semelhantes no Google.

PrtScr: é uma ferramenta diferente para captura de tela, o famoso print screen. Ao contrário de vários outros softwares desta categoria, ele consegue salvar áreas irregulares, ou seja, não fica restrito a um retângulo ou círculo para selecionar a área deseja, permite que se crie qualquer formato de seleção.

Screenpresso: é um pequeno programa gratuito de Windows e iOS para captura de tela em formato de fotos ou vídeos. Por rastrear movimentos do mouse, e todas as ações que ocorrem na tela do computador, este software é indicado para quem precisa fazer tutoriais para a internet ou produzir material para apresentações. 

ScreenToGIF: como o próprio nome sugere, é uma ferramenta para transformar imagens capturadas a partir da sua Área de trabalho em um GIF animado. Assim, se você sempre quis fazer animações a partir de alguma imagem ou procedimento realizado diretamente no seu computador, pode encontrar aqui a ferramenta ideal para a tarefa.

Tiny Take: é um programa para Windows, que permite tirar fotos da tela do computador - os famosos prints - de maneira simples e cheia de recursos de edição. Além disso, o aplicativo possibilita a gravação de vídeos a partir da tela do computador.

Padrões Estruturais

Definição de padrões estruturais

Os padrões estruturais se preocupam com a forma como classes e objetos são compostos para formar estruturas maiores. Este tipo de padrão de projeto descreve maneiras de compor objetos para obter novas funcionalidades. A flexibilidade obtida pela composição de objetos provém da capacidade de mudar a composição em tempo de execução. Se utilizar o modelo de análise no contexto da estrutura da solução, o arquiteto pode começar a definir os frameworks no contexto dos padrões estruturais.

Padrão Adapter

Padrão Bridge

Padrão Decorator

Padrão Façade

Padrão Proxy

Padrões comportamentais

Os padrões classificados como comportamentais tratam da organização das linhas de código que focam nas relações entre os objetos, a fim de melhorar a comunicação entre eles. O objetivo é compartilhar um mesmo tipo de comportamento entre diferentes classes, fazendo uso de heranças de interfaces e classes abstratas.

Padrão Chain of Responsability

Padrão Mediator

Padrão Observer

Padrão Strategy

Padrão Visitor

Padrões de Criação

Conceitos de padrões de projeto

Os primeiros registros de design patterns ou padrões de projeto foram publicados por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, em 1994, no livro Design patterns: elements of reusable object-oriented software. Estes padrões ficaram conhecidos como padrões GoF – Gang of Four, em referência aos quatro autores.

Além dos padrões GoF, há diversos outros padrões de projeto. Craig Larman, em 2004, no seu livro Applying UML and patterns, reuniu um conjunto de padrões sob o acrônimo GRASP – General Responsibility Assignment Software Patterns (Padrões de Software para Atribuição de Responsabilidade Geral), que funcionam como um guia no desenvolvimento orientado a objetos, apoiando a organização por responsabilidades. O GRASP reúne nove padrões relevantes para o desenvolvimento de sistemas OO dirigidos por responsabilidades. Os nove padrões que compõem o GRASP são: Creator (criador); Information Expert (especialista); Low Coupling (baixo acoplamento); Controller (controlador); High Cohesion (alta coesão); Polymorphism (polimorfismo); Pure Fabrication (pura invenção); Indirection (indireção); Protected Variations (variações protegidas).

Os padrões de projeto descrevem os princípios fundamentais da atribuição de responsabilidades a objetos. Esses padrões exploram os princípios fundamentais de sistemas OO.

Embora a adoção de padrões não seja trivial para um programador iniciante, este conceito tem sido adotado pela comunidade de desenvolvedores e cada vez mais exigido por líderes nas fábricas de software.

Como visto anteriormente, um código-fonte de um programa pode degradar-se ao longo de sua vida. Por princípio, os padrões buscam isolar as partes do código que são estáveis daquelas que são/serão mais suscetíveis a mudanças. O resultado que se espera é ter aplicações nas quais seja mais fácil efetuar procedimentos de manutenção, cujo código seja mais facilmente compreendido pela equipe do projeto, aumentando assim seu tempo de vida e postergando o início da degradação.

Os patterns são uma coleção de padrões de projeto de software, que oferecem soluções para problemas conhecidos e recorrentes no desenvolvimento de software. Um pattern descreve uma solução comprovada para um problema recorrente, dando ênfase ao contexto em que o problema ocorre e mostrando as consequências e o impacto de sua solução.

Assim, os patterns são dispositivos que permitem que os programadores compartilhem conhecimento sobre o seu projeto.

Como desenvolvedores, sabemos que, quando programamos, encontramos muitos problemas que ocorrem, ocorreram e irão ocorrer novamente. A pergunta que sempre fazemos é: “Como vamos solucionar este problema desta vez?”. Documentar um padrão é uma maneira de podermos reusar e possivelmente compartilhar uma informação que aprendemos em relação à melhor maneira de se resolver um determinado problema de software.

As vantagens de se utilizar design patterns são muitas e incluem as seguintes:

• Os padrões já foram provados e refletem a experiência, o conhecimento e as soluções dos desenvolvedores que tiveram sucesso usando-os em seus trabalhos.
• Os padrões são reutilizáveis e oferecem uma solução pronta que pode ser aplicada a diferentes problemas.
• Os padrões proveem um vocabulário comum que pode expressar muitas soluções, de forma sucinta e objetiva.

No entanto, é importante lembrar que os padrões, por si só, não garantem o sucesso do seu uso. A descrição do padrão indica quando ele pode ser aplicado, mas apenas a experiência pode determinar quando um padrão particular irá melhorar o projeto do sistema.

O principal objetivo de um design pattern é criar uma abstração de um problema recorrente e apresentar uma solução viável, além de poder compartilhar este conhecimento para que outras pessoas se beneficiem dele. Assim, a documentação de um design pattern deve ser feita de uma forma muito bem definida. De uma maneira geral, a documentação de um padrão inclui a definição dos seguintes itens:

• Objetivos ou pré-requisitos que devem ser satisfeitos antes de se decidir aplicar um padrão.
• A motivação ou o contexto em que o padrão se aplica.
• Uma descrição da estrutura do programa em que o padrão será definido.
• Consequências do uso do padrão, positivas e negativas.
• Exemplos de uso e aplicação do padrão

O catálogo de padrões GoF contém 23 padrões e está, basicamente, dividido em três seções:

• Creational (Padrões de criação).
• Structural (Padrões estruturais).
• Behavioral (Padrões comportamentais).

Os padrões de projeto GoF são soluções para problemas recorrentes no desenvolvimento de sistemas de software orientado a objetos. O quadro 2 (veja a seguir) mostra a divisão destes padrões, no contexto da programação orientada a objetos.

Os padrões de criação se referem à instanciação de objetos. Os estruturais estão ligados com a composição de classes ou objetos, e os comportamentais procuram caracterizar formas de interação entre classes e objetos. Um padrão GoF também é classificado segundo o seu escopo em 2 outros grupos:

• Padrões com escopo de classe: definidos por relacionamentos de herança e em tempo de compilação.
• Padrões com escopo de objeto: encontrados no relacionamento entre os objetos definidos em tempo de execução.

 

Definição de padrões de criação

Padrões de criação auxiliam na concepção de sistemas independentes do modo como os objetos são gerados, compostos e representados. De acordo com Gamma et al. (1995), este tipo de padrão abstrai o processo de instanciação, alterando a classe instanciada por meio de herança.

Assim, os padrões de criação concentram-se na composição de objetos complexos e no encapsulamento do comportamento de criação. Dessa forma, pretende-se evitar a ocorrência de códigos embutidos definindo pequenos grupos de características fundamentais, capazes de compor estruturas mais complexas.

Os padrões de criação podem ser competitivos ou cooperativos. Algumas técnicas se complementam, enquanto outras executam funções similares de formas distintas. As cinco abordagens presentes no modelo GoF são apresentadas a seguir:

Padrão Abstract Factory

Padrão Builder

Padrão Factory Method

Padrão Prototype

Padrão Singleton

Padrões de Arquitetura de Software

Definição de padrão arquitetural

Um padrão arquitetural determina a estrutura de um projeto de software. Portanto, trata-se de um conceito amplo que aborda questões como limitação de hardware, alta disponibilidade de uso e risco de negócio (BUSCHMANN et al., 2001).
Como sabemos, o desenvolvimento de algoritmos visa resolver problemas com o auxílio do computador. Já houve uma época em que os programadores tinham muita dificuldade com a escrita e a compilação do código. No entanto, esta dificuldade já foi superada com a ajuda de ferramentas que auxiliam o programador na sintaxe e semântica das linguagens de programação.
Temos agora um problema de segunda ordem que está relacionado a como organizar as linhas de código.
Muitas vezes, sabemos quais linhas de código atenderão um determinado requisito de negócio, porém ainda precisamos saber qual a melhor organização das linhas de código que evitará a degradação da aplicação.

O uso de padrões arquiteturais pode ser um dos direcionadores desta organização. Um único padrão pode auxiliar na solução das necessidades ligadas à organização do código, contudo, é possível usar uma combinação de padrões.
Vale lembrar que o conceito de padrões arquiteturais diferencia-se de padrões de projetos e ambos são assuntos tratados neste material.

IMPORTANTE
Arquitetura de software, segundo Booch, Rumbaugh e Jacobson (2005, p. 34) é o “conjunto de decisões significativas” acerca dos seguintes itens:

• a organização do sistema de software;
• a seleção dos elementos estruturais e suas interfaces, que compõem o sistema;
• seu comportamento, conforme especificado nas colaborações entre esses elementos;
• a composição desses elementos estruturais e comportamentais em subsistemas progressivamente maiores;
• o estilo de arquitetura que orienta a organização: os elementos estáticos e dinâmicos e suas respectivas interfaces, colaborações e composição.

De uma maneira mais simplificada, Pressman (2011, p. 230) define arquitetura de software como a “estrutura do sistema que abrange os componentes de software, as propriedades externamente visíveis destes componentes e as relações entre eles”. O autor ainda completa que a arquitetura

[...] não é o sistema operacional, mas sim uma representação que nos permite (1) analisar a efetividade do projeto no atendimento aos requisitos declarados, (2) considerar alternativas de arquitetura em um estágio quando realizar mudanças de projeto ainda é relativamente fácil e (3) reduzir os riscos associados à construção do software.

As seções a seguir descrevem os principais padrões arquiteturais, suas vantagens e desvantagens. Vale lembrar que existem muitos outros padrões possíveis, simples ou compostos, mas vamos nos ater aos mais utilizados nesta abordagem.

Padrão de arquitetura em camadas

De acordo com Buschmann et al. (2001), camadas são grupos de componentes reutilizáveis, similares e inter-relacionados, responsáveis por um nível de abstração particular, ou seja, as camadas executam tarefas específicas da aplicação consumindo e fornecendo recursos entre si.

Padrão de arquitetura Pipes and filters ou Pipeline

De acordo com Buschmann et al. (2001), o padrão arquitetural Pipes and filters, também denominado Pipeline, permite um processamento sequencial por meio de etapas encapsuladas em componentes chamados filters que, por sua vez, são acoplados por meio de conexões conhecidas como pipes.

Padrão de arquitetura Blackboard

O padrão Blackboard é utilizado para tratar problemas não determinísticos, como por exemplo, sistemas de inteligência artificial e reconhecimento de padrões. Neste padrão arquitetural, de acordo com Buschmann et al. (2001), diversos subsistemas unem seus conhecimentos para gerar uma possível solução parcial ou aproximada.

Model-View-Controller (MVC)

O padrão MVC é um modelo de camadas específico que divide a aplicação em três componentes:

• o Model, ou Modelo, que contém as funções básicas e o acesso aos dados;
• a View, ou visualizador, que exibe os dados para o usuário; e
• o Controller, ou controlador, que gerencia a interação entre as entradas do usuário e os dados do sistema.

Padrão de arquitetura Microkernel

O padrão arquitetural Microkernel se aplica a sistemas de software que devem ser capazes de se adaptar às necessidades de mudança do sistema. Ele separa um núcleo funcional mínimo de recursos estendidos e partes específicas. Este padrão também serve como um gerenciador para conectar essas extensões e coordenar a sua colaboração (BUSCHMANN et al., 2001).

Padrão de arquitetura Reflection

O padrão Reflection fornece um mecanismo para alterar a estrutura e o comportamento de sistemas de forma dinâmica. Neste padrão, a arquitetura é dividida em duas partes: um nível meta, que provê informações sobre as propriedades do sistema, e um nível base, que inclui a lógica da aplicação. Alterações realizadas em informações contidas no nível meta afetam o comportamento do nível base (BUSCHMANN et al., 2001).