🧪 ATIVIDADE 09: QUALIDADE E TESTES DE SOFTWARE
Para realizar este laboratório com sucesso, certifique-se de ter compreendido os conceitos apresentados no:
👉 CAPÍTULO 09: FUNDAMENTOS DA MODELAGEM
Bem-vindo a mais uma etapa da sua jornada no curso de Gestão de TI / Desenvolvimento de Sistemas. Hoje vamos mergulhar em conceitos que conectam a teoria técnica diretamente com o padrão de excelência da qualidade, garantindo que o software seja robusto e confiável antes de chegar ao cliente final. 🛡️🧩
🎯 Objetivos de Aprendizagem do Laboratório
Ao final deste laboratório prático (estimativa: 4 horas presenciais / autoguiadas), você será capaz de:
- Diferenciar Verificação (Estamos construindo o produto certo?) de Validação (Estamos construindo o produto corretamente?).
- Redigir Casos de Teste (Test Cases) com passo a passo e resultados esperados.
- Aplicar a técnica de Teste de Caixa Preta (Black-Box), focando em testes positivos e negativos.
🏢 O Cenário Prático (Seu Desafio)
Na TecProExpress, os desenvolvedores terminaram o "App de Rastreamento". No entanto, no primeiro dia de uso, um motorista tentou digitar o número da placa e o sistema travou porque ele usou letras minúsculas. O cliente tentou rastrear um pedido inexistente e o App exibiu uma tela de erro técnica (código 500) em vez de uma mensagem amigável.
O custo de imagem da empresa foi lá embaixo.
"Seu desafio como Analista de QA (Quality Assurance) é criar um Plano de Testes. Você deve antecipar o erro humano e criar roteiros que garantam que, mesmo que o usuário faça 'bobagem', o sistema se comporte de forma segura e elegante."
🧠 Fundamentos: A Teoria Traduzida
Testar software não é apenas "clicar para ver se funciona". É tentar provar que o sistema falha.
O Caso de Teste (Test Case)
Um caso de teste é um experimento científico controlado. Ele tem:
- Ação: O que eu faço? (Ex: Digito a senha errada).
- Resultado Esperado: O que deve acontecer? (Ex: Mensagem de erro "Senha inválida").
Testes Positivos vs Negativos
- Positivo: O usuário faz tudo certo. (Ex: Login com dados corretos).
- Negativo: O usuário faz tudo errado ou tenta "quebrar" o sistema. (Ex: Colocar letras no campo de 'Quantidade' ou deixar campos obrigatórios vazios).
📊 Visualizando a Lógica
```mermaid flowchart LR A[Entrada de Dados] --> B{Filtro de Teste} B -- "Dados Válidos" --> C[Sucesso] B -- "Dados Inválidos" --> D[Tratamento de Erro Amigável] ```📖 Exemplo Guiado
Abaixo, veja como estruturar um Caso de Teste para o login da TecProExpress.
| ID | Título do Teste | Ação do Usuário | Resultado Esperado |
|---|---|---|---|
| CT01 | Login Vazio | Clica em 'Entrar' sem digitar nada. | O sistema deve exibir "Campos Obrigatórios". |
| CT02 | Formato CPF | Digita CPF sem pontos e traços. | O sistema deve formatar e aceitar o login. |
📊 A Pirâmide de Testes da Engenharia Profissional
flowchart TD
subgraph P [Níveis de Cobertura e Esforço]
direction BT
E2E["Testes de Interface / Ponta a Ponta (E2E)<br/>(Lentos / Altamente Frágeis / Cobertura Focada)"]
INT["Testes de Integração<br/>(Médio esforço / Valida comunicações entre APIs)"]
UNI["Testes de Unidade (JUnit)<br/>(Ultra rápidos / Baratos / Cobertura massiva)"]
UNI --> INT --> E2E
end
style UNI fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
style INT fill:#e1f5fe,stroke:#0288d1,stroke-width:2px
style E2E fill:#fffde7,stroke:#fbc02d,stroke-width:2px
🛠️ Estrutura do Roteiro de Teste
# CT03: Teste de Upload de Comprovante
**Objetivo:** Validar se o sistema aceita apenas imagens de comprovantes.
**Pré-condição:** Estar na tela de finalização de entrega.
**Passos:**
1. Clicar no botão "Anexar Foto".
2. Tentar selecionar um arquivo do tipo ".PDF".
3. Clicar em "Confirmar".
**Resultado Esperado:** O sistema deve bloquear a seleção do PDF e exibir o erro "Formato não permitido. Use JPG ou PNG".
🔍 Detalhamento do Processo:
- Note que o roteiro é tão detalhado que qualquer pessoa (mesmo quem não conhece o sistema) conseguiria executá-lo. Isso permite a Reprodutibilidade do Erro.
🛠️ Prática Obrigatória 1: Tabela de Casos de Teste
Cenário: O projeto semestral da sua equipe.
- Escolha 3 Requisitos Funcionais da sua Atividade 03.
- Para cada requisito, crie 2 Casos de Teste (um positivo e um negativo).
- Organize-os em uma tabela contendo: ID, Título, Ação e Resultado Esperado.
🏁 Resultado Esperado (Para sua Referência)
Uma tabela com 6 roteiros de teste (3 pares) que cubram as funcionalidades críticas do seu sistema.
💻 Suíte de Testes Automatizados em Python (Pytest)
Para transformar sua tabela de casos de teste em asserções automatizadas executáveis via pytest:
# test_entregas_qa.py
import pytest
def calcular_frete(peso_kg: float, distancia_km: float) -> float:
if peso_kg <= 0:
raise ValueError("O peso do pacote deve ser estritamente positivo.")
if distancia_km <= 0:
raise ValueError("A distância percorrida deve ser maior que zero.")
return 15.0 + (peso_kg * 1.5) + (distancia_km * 0.8)
# 1. Caso de Teste Positivo (Caminho Feliz)
def test_calcular_frete_sucesso():
valor = calcular_frete(peso_kg=10.0, distancia_km=50.0)
assert valor == 70.0, f"Esperado R$ 70.00, mas obteve R$ {valor}"
# 2. Caso de Teste Negativo (Entrada Inválida com Exceção)
def test_calcular_frete_peso_negativo():
with pytest.raises(ValueError, match="estritamente positivo"):
calcular_frete(peso_kg=-5.0, distancia_km=50.0)
🖥️ Saída Esperada no Terminal ao Executar pytest:
============================= test session starts =============================
platform win32 -- Python 3.11.2, pytest-9.1.1, pluggy-1.6.0
rootdir: D:\SourceCode\GitRepos\github.io\portal_mdbook
collected 2 items
test_entregas_qa.py .. [100%]
============================== 2 passed in 0.04s ==============================
🌐 Exemplo de Requisição cURL para Teste de Erro 422/400 (Swagger /docs)
# Teste Negativo: Enviando peso negativo para a API
curl -X POST "http://127.0.0.1:8000/api/v1/frete/calcular" \
-H "Content-Type: application/json" \
-d '{
"peso_kg": -10.0,
"distancia_km": 50.0
}'
🔹 Resposta de Erro Tratada (HTTP 422 Unprocessable Entity):
{
"detail": [
{
"loc": ["body", "peso_kg"],
"msg": "ensure this value is greater than 0",
"type": "value_error.number.not_gt"
}
]
}
📤 Instruções de Entrega (Microsoft Teams)
Após validar seus roteiros de teste:
- Salve o arquivo de documentação com o nome
Atividade_09.mdna pastaes-atv-09-testes/do seu repositório GitHub. - Certifique-se de fazer o commit e push para o repositório público.
- Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.
💡 Checkpoint de Lógica
Reflexão Profissional: O que é mais caro para uma empresa: encontrar um erro durante a fase de Requisitos (Atividade 03) ou encontrar esse mesmo erro depois que o software já foi entregue para 10.000 clientes? (Resposta: Depois da entrega. O custo de correção no mercado pode ser até 100x maior devido a recalls, suporte e perda de reputação). 🧠🛡️
📊 Rubrica Formativa de Avaliação
| Critério de Avaliação | Insuficiente (0% - 40%) | Regular (41% - 70%) | Excelente (71% - 100%) |
|---|---|---|---|
| Casos de Teste (Positivo & Negativo) | Menos de 6 roteiros ou contendo apenas testes positivos óbvios. | Cria 6 casos de teste mas sem clareza no resultado esperado. | Tabela completa com 6 casos de teste (3 pares Positivo/Negativo) cobrindo ID, Título, Ação e Resultado Esperado. |
| Teste de Caixa Preta & Defesa do Sistema | Omite o cenário de teste de validação de dados/caixa preta. | Descreve o cenário negativo sem indicar a ação de defesa do sistema. | Detalhamento impecável de teste de borda/caixa preta e comportamento defensivo da aplicação. |
| Entrega no GitHub | Entrega fora da pasta `es-atv-09-testes/`. | Arquivo entregue mas sem tabela organizada em Markdown. | `Atividade_09.md` publicado com formatação limpa e validada. |