Engenharia de software

 

Análise e Projeto Estruturado

 

  • Análise estruturada → introduz o uso de ferramentas de documentação gráfica: lista de eventos, diagrama de contexto, diagrama de fluxo de dados, dicionário de dados, diagrama de entidade relacionamento, diagrama de transição de estado;
    • Diagrama de contexto (DC)
      • documenta o âmbito do estudo, identifica os limites dos processos, as áreas envolvidas, os relacionamentos com outros processos;
    • Diagrama de fluxo de dados (DFD)
      • nomeado também como: diagrama de fluxo de trabalho, diagrama de modelo funcional/de processo, diagrama de bolha;
      • representação gráfica (terminadores, entidades, fluxo de dados, depósitos), em rede dos processos e funções;
    • Diagrama entidade-relacionamento (DER)
      • visualização das entidades e relação entre elas;
    • Diagrama de transição de estado (DTE)
    • Especificação de processos
      • descreva a política representada por cada processo de baixo nível do DFD; (português estruturado, árvore de decisão)
    • Dicionário de Dados
      • define o significado dos fluxos e depósitos de dados;
      • define os valores e unidades relevantes de partes elementares dos fluxos e depósitos de dados;
      • define a composição de pacotes de dados que se movimentam pelos fluxos;
  • Projeto estruturado
    • Programação estruturada
    • Desenvolvimento top-down
    • Equipes de programação
    • Revisões estruturadas
  • Análise essencial → propõe o particionamento do sistema por eventos;
    • Modelo ambiental
      • define a fronteira, determinando o que interno a ele e externo a ele
      • Declaração de Objetivos
      • Diagrama de Contexto
      • Lista de Eventos
      • Dicionário de Dados Preliminar (opcional)
    • Modelo comportamental
      • DFD Particionado
      • Diagrama ER (DER)
      • Diagrama de Transição de Estado (DTE)
      • Dicionário de Dados Preliminar (opcional)
      • Especificações de processos

 

Engenharia de requisitos

 

  • Visão geral
    • Análise do problema → define o problema de acordo com as partes interessadas (stakeholders);
    • Levantamento dos requisitos → atores, casos de uso, necessidades;
    • Gerência de requisitos → gerenciar expectativas de mudanças;
  • Desafios
    • Objetivos que não estavam claros;
    • Ignorar um grupo de clientes;
    • Requisitos e especificações incompletos, indefinidos, incompletos ou inconsistentes (divergentes);
    • Demandas de mudanças fora do escopo;
  • Conceitos
    • Requisitos → constituem uma especificação das características e propriedades do sistema, o que inclui a descrição dos objetivos, comportamentos, restrições de operação;
    • Requisitos (IEEE) → uma condição ou capacidade necessitada por um usuário para resolver um problema ou alcançar um objetivo;
    • Especificação → descrição rigorosa e minuciosa das características (dos requisitos);
  • Coleta de Requisitos
    • Documentação → draft é um documento preliminar, porém completo, de requisitos para verificação de conflitos, relevância;
    • Classificação → agrupar os requisitos coletados em categorias bem definidas;
      • Funcionais → descreve as funcionalidades e comportamentos do sistemas;
      • Não-funcionais → descreve como deve ser implementado (qualidade, performance, usabilidade, segurança, confiabilidade, regras de negócio)
  • Análise dos Requisitos
    • Desafios
      • As partes interessadas (stakeholders) podem não conhecer o problema ou objetivos a serem alcançados, ou ainda, problemas ou objetivos conflitantes entre as partes;
      • Fatores políticos e organizacionais podem influenciar os requisitos do sistema, como a mudança das partes interessadas, que podem ocasionar uma nova perspectiva de escopo e eventual conflito de requisitos;
    • Solução de conflitos
      • identificar as partes interessadas no levantamento de cada requisito;
      • procurar acordo entre as partes geradoras de requisitos conflitantes;
    • Atribuição de prioridades → definir prioridades dos requisitos com as partes interessadas;
      • Requisitos essenciais → Requisitos Importantes → Requisitos Desejáveis
    • Validação
      • Confirmar a demanda das partes interessadas (comunicação apropriada);
      • Revisão dos requisitos → análise manual e sistemática;
      • Prototipação → esboço (rascunho) de telas que retratam às partes interessadas para validar os requisitos;
      • Geração de casos de teste → testes específicos para avaliar os requisitos;
  • Gerenciamento de requisitos → controle das mudanças dos requisitos;
    • Rastreamento de requisitos
      • identificar as dependências entre requisitos e suas origens (partes interessadas);
      • relaciona os requisitos com as interfaces internas e externas do sistema;
      • identifica a governabilidade de subsistemas;
      • faz uso da tabela de rastreabilidade;
    • Rastreamento de projeto
      • identificar partes do projeto relacionadas aos requisitos;
    • Matriz de rastreamento
      • por meio de hypertexto ou referência cruzada;

 

UML

 

  • Contexto histórico
    • OMT − Object-Modeling Technique (James Rumbaugh, 1991)
      • método de análise para entendimento e simulação do problema, bem como visualização alternativa;
      • divide-se nos modelos objeto (classe e objeto), dinâmico (sequência e estado) e funcional (fluxo);
    • OOSE − Object-oriented software engineering (Ivar Jacobson, 1992)
      • método de design (projeto) inclui artefatos que envolvem a visão do usuário;
      • divide-se nos modelos de requisitos, análise, design, implementação e teste (similar aos diagramas de casos de uso, sequência e estado);
    • OOD − Object-oriented Analysis and Design (Grady Booch, 1993)
      • método de design (projeto) inclui artefatos voltados a implementação e codificação;
      • divide-se nos diagramas de interação, sequência, módulos, classe, objeto e estado;
  • Introdução
    • Não é método ou metodologia, não é modelo, não é processo, não é uma linguagem natural;
    • Não depende de tecnologia, de paradigma de programação (não requer orientação a objetos) ou de linguagem de programação;
    • Fundamento → modelo é uma representação simplificada e abstrata a partir de determinada perspectiva¹ (conceito amplo);
    • UML → especialização da representação de modelos para descrever, expressar e comunicar ideias de sistemas, em alto nível de abstração;
    • Forma da UML → é uma linguagem visual² para visualização, especificação, construção e documentação em diagramas¹;
      • perspectivas estáticas → diagramas estruturais;
      • perspectivas dinâmicas → diagramas comportamentais;
      • ¹perspectiva → cada diagrama representa um diferente ponto de vista;
      • ²linguagem visual → menos ambígua que a linguagem natural e menos detalhada que o próprio código;
    • levantamento e análise de requisitos → suas etapas trabalham com o domínio do problema e compressão das necessidades e expectativas das partes interessadas;
    • prototipação → produzir obrigatoriamente um protótipo;
    • análise → determina o domínio do problema (funcionalidade e restrições);
    • projeto → determina o domínio da solução;
    • manutenção;
  • Linguagem para especificação de restrições em objetos (OCL)
    • Uma linguagem declarativa utilizada para descrever regras de negócio de forma mais precisa do que com o uso dos diagramas;
    • Reduz eventuais ambiguidades ou interpretações diversas daquela desenhada;
    • Possui sintaxe e semântica formais que podem ser traduzidas para códigos, scripts, etc;
  • Relacionamentos → relações lógicas entre elementos dos diagramas;
    • Associação simples (–––>) → instâncias de um objeto possuem instâncias de outro objeto;
      • Nome da associação;
      • Navegabilidade → direção de acessos aos dados; unidirecional (→)  ou bidirecional (↔ ou −);
      • Multiplicidade → número de ocorrências (1 ou *);
      • qualificada → identifica um atributo único ou chave primária (ex: CPF) em uma associação 1→* (ListaDePessoas[CPF] → Pessoa);
      • notação de linha sólida com ou sem setas;
    • Associação por agregação (–––◊) → Uma classe B (parte) pode ser usada por outras classes distintas de A◊––B (ex: A:time de futebol e B:pessoa); a parte pode ser compartilhada com outros relacionamentos, e não necessita ser excluída em cascata (não determina o ciclo de vida);
      • notação linha sólida com losango aberto ao lado da classe principal;
    • Associação por composição (–––♦) → Uma classe B (parte) existe especificamente ou pertence exclusivamente para atender a classe A♦––B (ex: A:empresa e B:departamento); a parte é exclusivo e não pode ser compartilhado com outro relacionamento; e é excluída em cascata (determina o ciclo de vida);
      • notação linha sólida com losango fechado ao lado da classe principal;
    • Dependência (– – –>) → indica que mudanças em um elemento pode causar mudanças no outro, como alterações em interfaces ou em pacotes;
      • notação linha tracejada com seta ao lado do elemento consequente;
    • Generalização (–––∇) →representa o conceito de herança, ou seja, relacionamento entre um objeto específico e outro genérico∇;
      • notação linha sólida com triângulo ao lado do elemento mais genérico;
    • Realização (– – –∇) → classe que implementa uma interface, um pacote que implementar outro pacote, etc;
      • notação linha tracejada com triângulo ao lado da interface∇;
      • notação linha sólida com circulo fechado que representa a interface;
    • Dependência e Realização (notação apenas)
      • notação linha sólida com bola-soquete; soquete representa a dependência, e a bola representa a interface;
  • Diagramas estruturais  → análise do sistema sob perspectivas estáticas;
    • Diagrama de classes
      • representa um conjunto de classes, interfaces e relacionamentos;
      • classes → formam-se por nome, as propriedades (atributos) e os comportamentos (operações) das classes do sistema;
        • o nível de detalhamento do diagrama é discricionário, podendo conter apenas o nome da classe até informações completas das propriedades;
        • as classes ou operações abstratas são apresentados em itálico;
        • as propriedades ou operações de classe (escopo estático) e são apresentados sublinhados, caso contrário, são de instância;
        • os comportamentos são formados pela visibilidade, nome da operação, nomes e tipos de parâmetros, tipo do retorno e {restrições}; a operação a definição do comportamento, o método é cada implementação da operação;
        • as propriedades são formadas pela visibilidade, nome do atributo, tipo do dado, multiplicidade[0..5] (número de elementos), valor padrão e {restrições};
      • interfaces → representa-se como classe com estereótipo <<interfaces>> ou pelo elemento Ο (bola) com nome embaixo;
      • modificadores de visibilidade
        • +pública → acessível por qualquer outra classe;
        • #protegida →acessível pela própria classe ou por suas subclasses;
        • ~pacote → acessível pelas classes que estão no mesmo pacote, incluindo a própria classe;
        • −privada → acessível pela própria classe;
    • Diagrama de objetos
      • representa os objetos a partir de um snapshot do sistema, equivalente a uma instância do diagrama de classe;
      • fornece uma visão (somente) dos valores dos atributos de cada objeto e vínculo entre os objetos, similar a um componente de depuração;
      • não contém as operações!
        • notação similar ao diagrama de classe, porém, possui apenas a listagem dos atributos (chave) e seus valores, bem como as ligações entre objetos;
    • Diagrama de componentes (partes implementáveis de um sistema)
      • um componente possui interfaces e comportamentos bem definidos (coesão e baixo acoplamento), pode ser uma classe, um subsistema, um aplicativo;
      • representa componentes implementáveis do sistema (módulos, código fonte, bibliotecas, formulários, arquivos de ajuda) e seus relacionamentos por meio de interfaces;
      • fornece uma visão da estrutura e interação dos componentes, seja em tempo de ligação (compilação) ou execução (comunicação);
        • notação por meio de retângulo com conector no canto superior direito;
    • Diagrama de pacotes (agrupamento de elementos UML)
      • representa as grandes divisões (pedaços) do software, como subsistemas ou submódulos e sua composição;
      • fornece agrupamentos lógicos de elementos UML para auxílio a demonstração da arquitetura ou a definição de camadas do sistema;
      • agrupa casos de uso, componentes, classes, e qualquer outro elemento UML;
        • notação por meio de um envelope com guia no canto superior esquerdo que contém o nome do pacote;
        • os elementos agrupados podem ser representados dentro do envelope ou em forma hierárquica cuja raiz é representada por ⊕;
    • Diagrama de implantação
      • representa as necessidade de configuração física (hardware) ou ambiente de execução (servidores de aplicação), incluindo estações de trabalho, topologias, e protocolos de comunicação;
      • artefatos → empacotamentos de software (arquivos war/ear), de código-fonte, de código binário, de executáveis (arquivos exe);
      • determina a distribuição dos módulos do sistema entre servidores por meio de nós (processamento e memória próprio) e artefatos;
        • notação por meio retângulos (navegador, cliente desktop, servidor web, servidor de aplicação) interligados pela forma de comunicação (http, RMI, JDBC);
    • Diagrama de estrutura composta
      • descreve a estrutura interna (classes, objetos e interfaces) de um classificador modelando colaborações;
      • descreve estruturas de partes (instâncias contidas em outro elemento) ou instâncias interconectadas por portas (ponto de interação entre os elementos);
      • usado para associar o diagrama de objetos com o diagrama de classes/interfaces em tempo de execução;
        • notação de um círculo tracejado (colaboração para execução de determinada atividade) que contém partes de diagramas de objetos e partes de classes estruturadas;
    • Diagrama de perfis (UML 2.2);
      • trata-se de um mecanismo de extensão simplificada da linguagem por meio da criação de tipos padronizados de estereótipos, valores rotulados e restrições;
      • permite adaptar os modelos UML para diferentes plataformas e domínios;
      • ao criar um diagrama de perfil define-se propriedades comuns a todo o sistema, e evita-se a especificação de estereótipos em cada classe;
  • Diagramas comportamentais → análise do sistema sob perspectivas dinâmicas, mudanças com o passar do tempo;
    • Diagrama de caso de uso → usado nas fases de levantamento e análise dos requisitos do sistema para:
      • descrever um conjunto de cenários (não especifica implementação);
      • identificar atores (pessoa, hardware, outro sistema) são sempre uma entidades externas ao sistema;
      • identificar ou apresentar funcionalidades e características (tornar claro os requisitos);
      • delimitar o escopo do sistema;
      • representar uma sequência de ações (fluxo alternativos, fluxos de exceção, etc), interações e relacionamentos entre atores, sistemas e entidades externas, a fim de gerar valor observável;
      • a documentação (≠diagrama) de um caso de uso não possui um formato específico;
      • elementos
        • stick man ou <<actor>> → representam os atores;
        • círculo → é um caso de uso, em que um diagrama é a representação gráfica formada por um conjunto de casos de uso;
        • inclui (– – –>) → o caso de uso incluído é de execução obrigatória e é incluído por mais de um caso de uso (A inclui – – –> B);
        • estende (– – –>) → o caso de uso estendido é de execução opcional (A estende – – –> B);
      • tipos
        • concreto → é iniciado por atores e possuem um fluxo completo de eventos;
        • abstratos (em itálico) → não são referenciados (instanciados) por atores diretamente, sendo incluídos, estendidos ou generalizações;
    • Diagrama de atividade (workflow)
      • descreve os passos (ações) até a conclusão (nó final) de uma determinada atividade por meio de algoritmos, processos de negócio, fluxos de trabalho ou métodos;
      • elementos
        • nó inicial (círculo fechado);
        • ações (caixas) → * é usado para representar a concorrência dinâmica (ocorrência de um laço, durante o estado de ação);
        • fluxo (seta) → liga uma ação a outra;
        • decisões (losango) →indica controle por meio de expressões booleanas (não há processamento paralelo);
        • união (losango) → une os fluxos de uma decisão;
        • nó de bifurcação ou separação (barra horizontal) → indicam processamento paralelo;
        • nó de junção (barra horizontal) → conclui um processamento paralelo;
        • nó final (círculo semi-fechado);
        • swimlanes (raias) → determina qual entidade é responsável por cada ação (partição das ações por unidade de negócio);
    • Diagrama de máquinas de estado
      • representa os vários estados possíveis de um objeto individual;
      • a mudança (transição) de estado decorre de um evento interno ou externo ao sistema associado ou não a uma [condição de guarda];
      • estados aninhados → estados dentro de outro estado;
      • estados concorrentes → um estados distinto para cada região de concorrência a qual ele pertence;
      • fronteira da concorrência →separação de duas regiões que podem ser executadas em paralelo;
      • pseudo-estado de histórico → grava o estado em determinado momento;
      • elementos
        • estados → valores possíveis de um objeto (permanecem em um estado quanto satisfazem uma condição ou realiza determinada atividade);
        • transições → eventos podem implementar [condição de guarda] para executar uma ação durante a mudança de estado;
        • ações → são executadas em caso de mudança de estado;
        • atividades → são executadas durante um estado;
    • Diagramas de interação → análise do sistema sob perspectivas dinâmicas e seus relacionamentos (dinâmica entre objetos);
      • Diagrama de sequência
        • representa especificação da implementação ou regra de negócio para solucionar determinado problema;
        • ênfase na ordem temporal que as mensagens são trocadas entre os objetos;
        • participantes orientados no eixo horizontal e ordem temporal de cima para baixo;
        • elementos
          • evento gerador (círculo fechado) → inicia o processo modelado;
          • participante (retângulo com nome:tipo) → objetos ou atores;
          • linha de vida (linhas pontilhadas ou barra de ativação partir do participante) → período em que o participante existe;
          • mensagem (seta aponta para barra de ativação) → chamada de uma operação (método) de outro ou do próprio objeto (seta entre linhas de vida);
            • síncrona (linha sólida com seta fechada) → a conclusão da operação é necessária para continuar a execução;
            • assíncrona (linha sólida com seta aberta) → a execução independente da conclusão da operação;
          • barra de ativação → operação (método) chamada ou construtor em execução;
          • mensagem de retorno (linha pontilhada com seta aberta) → retorno da operação;
          • auto-chamada (mensagem, ativação, retorno) → chamada de operação do próprio objeto;
          • criação de participante (seta aponta para um participante);
          • destruição de participante (X no fim da linha vida) → auto destruição ou por meio de mensagem por outro objeto;
      • Diagrama de comunicação (colaboração)
        • fortemente associado (equivalente) a o diagrama de sequência, apenas com ênfase distinta;
        • representa especificação da implementação ou regra de negócio para solucionar determinado problema;
        • ênfase na ordem estrutural (relacionamento entre os objetos) que as mensagens são trocadas entre os objetos;
        • participantes posicionados livremente, com mensagens sequenciadas obrigatoriamente em virtude da ausência do eixo do tempo (vertical);
      • Diagrama de tempo (temporização)
        • descreve objetos cuja mudança de estado esteja relacionada a temporização, bem como a duração em que permanecem em determinado estado;
        • determina condições (restrições) temporais (tempo mínimo ou máximo) que implicam na mudança de estado do objeto;
      • Diagrama de interação geral (UML 2.0);
        • visão geral de um sistema ou processo de negócio;
        • usado para associar o diagrama de atividades (workflow) com o diagrama de sequência (comunicação ou tempo) em que o segundo é integra um ação (caixa) da atividade;
        • pode referenciar (ref) outros diagramas em vez de apresentar no mesmo diagrama;

 

Processos de desenvolvimento de software

 

  • Características do Software
    • Desenvolvido ou projetado por engenharia;
    • Mantém suas funcionalidades ao longo do tempo;
  • Ciclo de vida de software → considerar a natureza do projeto e da aplicação para definição de métodos, ferramentas, controles e produtos a ser entregues;
    • Ciclo de vida clássico (cascata) → modelo mais antigo com abordagem sequencial e sistemática;
      • Análise e engenharia de sistemas → levantamento de requisitos gerais, de hardware, pessoas, banco de dados
      • Análise dos requisitos → coleta de requisitos específicos do software
      • Projeto → estrutura de dados, arquitetura do software, detalhes procedimentais, caracterização de interfaces;
      • Codificação → implementação;
      • Testes → validação dos aspectos lógicos aderentes ao requisitos;
      • Manutenção → mudanças por erros, inconformidades, ajuste de desempenho;

 

Processo Unificado (UP)

 

  • Conceitos
    • originado da Engenharia de Software de componentes;
    • centrado na arquitetura, orientado por casos de uso e com foco na redução de riscos;
    • fluxo de processo iterativo e incremental, o que recepciona as mudanças necessárias durante o processo de desenvolvimento;
    • agrega um valor real à organização que necessita manter padrões relativos às comunicações externas e à comunicação com a equipe de desenvolvimento;
    • promove o uso de seis melhores práticas:
      • desenvolvimento iterativo;
      • gerencia requisitos;
      • arquiteturas de componentes;
      • modelagem visual (UML);
      • verifica a qualidade de software continuamente;
      • gerencia mudanças;
  • Perspectivas do Processo Unificado
    • Dinâmica ou horizontal (1º dimensão) → representa o aspecto dinâmico do processo, onde estão representadas suas fases e interações (ciclos), às quais estão associados marcos que determinam sua finalização;
      • Fases → Iniciação/concepção, Elaboração, Construção e Transição;
      • As iterações aprimoram o entendimento do problema por meio de refinamentos sucessivos;
    • Estática ou vertical (2º dimensão) → representam as disciplinas, que agrupam logicamente as atividades.
      • Disciplinas → Modelagem de negócios, Requisitos, Análise e design (projeto), implementação, teste, implantação, gerenciamento de configuração e mudanças, gerenciamento de projetos e ambiente;
      • As disciplinas estão presentes em todas as fases, apenas a disciplina de implantação não se encontra na fase de iniciação/concepção, ou seja, as demais disciplinas estão presentes em todas as fases, com maior ou menor pico de trabalho;
  • Fases e disciplinas do Processo Unificado → as disciplinas abrangem diversas fases, sendo separadas didaticamente pela fase em que ocorre maior pico de trabalho da disciplina;
    • Iniciação (concepção) → visão, riscos, caso de negócio, plano de desenvolvimento, plano de interação, casos de desenvolvimento, ferramentas e glossário;
      • Modelagem de negócios → descrição do negócio, identificação dos processos e no desenvolvimento do modelo de domínio;
      • Requisitos → definição formal dos requisitos;
    • Elaboração → protótipos, lista de riscos, atualização do casos de desenvolvimento, instalação das ferramentas, documento de arquitetura de software, modelo de design, modelo de dados, modelo de implementação, atualização da visão, atualizar o plano de desenvolvimento de software, avanço conclusivo do modelo de casos de uso, especificação de requisitos não-funcionais, teste implementados e executados, arquitetura para automação dos teste;
      • Análise e design (projeto) → modelos de arquitutura, modelos de componente, modelos de objeto e modelos de sequência;
    • Construção → sistema executável, plano de implantação, execução do conjunto de testes a cada release, manuais de usuário e treinamento, plano de iteração à fase de transição, atualização do modelo de design, refinamento dos casos de desenvolvimento, utilização de ferramentas da de construção e atualização do modelo de dados;
      • Implementação → protótipos (iniciação), esboços da arquitetura (elaboração), modelo de implementação e integração (construção) e correções de falhas (transição);
      • Teste → processo iterativo realizado em conjunto com a implementação e ao final dela;
      • Implantação → distribuição de uma versão do produto;
      • Gerenciamento de configuração e mudanças → Gerenciar Solicitações de Mudanças e Planejamento de Controle do Projeto e Configuração de Mudanças;
    • Transição → o sistema pronto, notas de lançamento (release), artefatos para instalação, conclusão do material de treinamento, material de suporte para aprendizagem, utilização e manutenção.
      • Gerenciamento de projetos → observa a abordagem empresarial de gerência de projetos;
      • Ambiente → disponibilização de ferramentas de software apropriadas as peculiaridades de cada projeto;

 

Extreme Programming (XP)

 

  • Características
    • Desenvolvimento iterativo e envolvimento extremo do cliente;
    • Todos os requisitos são expressos como cenários (histórias de usuário e casos de uso);
  • Valores
    • Comunicação
    • Simplicidade
  • Práticas
    • Jogo de planejamento;
    • Planejamento incremental;
    • Pequenas versões;
    • Metáfora;
    • Projeto simples;
    • Time coeso;
  • Conceitos
    • Histórias de usuário (cartão de história) → como um [papel do usuário], quero [meta], para que eu possa [motivo].
    • Abordagem extrema → novas versões compiladas várias vezes ao dia, e entrega de incrementos em poucas semanas;
    • TDD (Test Driven Development) → define a interface e o comportamento esperado para a funcionalidade;

 

SCRUM

 

  • Conceito
    • Scrum é um framework para gerenciamento de projetos ágeis;
    • centrado em valores e entrega reais do produto;
    • abordagem iterativa e incremental para otimizar a previsibilidade e o controle a riscos;
  • Pilares → Princípios pétreos
    • Transparência →
    • Inspeção →
      • Daily scrum (meeting)
      • Sprint Review e Sprint Planning
      • Spreint Retrospective
    • Adaptação →
  • Papéis
    • Product Owner →
    • ScrumMaster →
    • Time →

 

Testes de software

 

  • Objetivo → encontrar os erros;
  • Características
    • Operabilidade;
    • Observabilidade;
    • Controlabilidade;
    • Decomponibilidade;
    • Simplicidade;
    • Estabilidade;
    • Compreensibilidade;
  • Estratégias de testes
    • Fornecer um roteiro;
    • definir equipe para elaboração do roteiro;
    • verificação do conjunto de tarefas por função;
  • Modelo V de testes (Desenvolvimento ← Teste)
    • ↓ Especificação de requisitos ← Teste de aceitação ↑;
    • ↓ Projeto de alto nível ← Teste de sistema ↑;
    • ↓ Projeto detalhado ← Teste de integração ↑;
    • ↓ Codificação ← Teste de unidade ↑;
  • Tipos de teste
    • Teste caixa-branca (estrutural ou caixa de vidro)
      • projetado em função da estrutura do componente (depende da implementação);
      • perspectiva interna, código fonte ou circuito, definição de entradas e análise da lógica;
      • exercita todas as decisões lógicas;
      • aplicável nas fases de unidade (tipicamente), integração, regressão e sistema;
      • não analisa a especificação ou a lógica de especificação;
    • Teste do caminho básico (uma técnica de caixa-branca)
      • identifica a complexidade lógica para descobrir os caminhos básicos, afim de verificar se todos os caminhos são executados;
    • Teste caixa-preta (funcional)
      • projetado em função dos requisitos funcionais (independe da implementação);
      • não há acesso ao código fonte;
      • identifica funções incorretas ou ausentes;
    • Teste baseado em modelo;

 


Reinaldo Gil Lima de Carvalho