Seu navegador não oferece leitura em voz alta. Você pode ler o guia normalmente.
Dois assuntos de engenharia de software aparecem em quase toda prova para cargos de TI: requisitos (o que o sistema deve fazer e com que qualidade) e testes (como saber se ele faz). As questões são conceituais, mas algumas pedem cálculo simples, como escolher os valores de teste de um intervalo. Este guia reúne o que é cobrado, e o exemplo de valor limite foi executado.
Requisitos: o que o sistema deve ser
Um requisito descreve uma necessidade que o software deve atender. A classificação básica:
| Tipo | Pergunta que responde | Exemplos |
|---|---|---|
| Funcional | o que o sistema faz? | cadastrar protocolo; emitir relatório; calcular pontuação |
| Não funcional | como, com que qualidade ou sob quais restrições? | tempo de resposta, segurança, disponibilidade, usabilidade, portabilidade, manutenibilidade |
| De domínio | regras do mundo em que o sistema atua | regra legal que o cálculo deve respeitar |
Requisitos não funcionais não são “menos importantes”: um sistema que faz tudo, mas fica fora do ar na hora de uso, falha. Eles muitas vezes definem a arquitetura. Também há restrições, como “usar determinado banco de dados” ou “seguir uma norma de segurança”.
Exemplo de classificação:
- “O sistema deve permitir que o servidor registre a entrada de um documento”: funcional.
- “O sistema deve responder às consultas em tempo definido sob determinada carga”: não funcional (desempenho).
- “Somente usuários autenticados podem alterar dados”: funcional ou não funcional, conforme o enfoque; o controle de acesso é geralmente tratado como requisito de segurança, ou seja, não funcional, embora gere funções. Em prova, siga o enunciado.
Boas características de um requisito
Um bom requisito é claro (sem ambiguidade), completo, consistente (sem conflito com outros), verificável (dá para testar) e rastreável (liga-se à origem e aos testes). “O sistema deve ser rápido” não é verificável; “a busca deve retornar em até certo tempo definido” é.
Etapas da engenharia de requisitos: levantamento (entrevistas, observação, questionários, prototipação), análise e negociação, especificação, validação e gestão (mudanças e rastreabilidade). Um requisito mudou? A gestão controla o impacto.
Níveis de teste
Teste de software é a atividade de executar o programa para encontrar defeitos. Um princípio clássico da área: o teste pode mostrar a presença de defeitos, mas não prova a sua ausência. Os níveis, do menor ao maior escopo:
| Nível | Foco | Quem costuma fazer |
|---|---|---|
| Unidade | uma função, método ou classe isolada | desenvolvedor |
| Integração | a comunicação entre módulos | desenvolvedores e testadores |
| Sistema | o sistema completo, em ambiente próximo ao real, incluindo requisitos não funcionais | equipe de qualidade |
| Aceitação | o cliente ou usuário confirma que atende à necessidade | cliente/usuário |
Tipos transversais: regressão (repetir testes após uma mudança para garantir que nada antigo quebrou), fumaça (verificação rápida do essencial), desempenho, carga e estresse, usabilidade e segurança. Testes de aceitação costumam ser divididos em alfa (na casa do desenvolvedor) e beta (com usuários em seu ambiente), terminologia que varia por autor.
Conceitos vizinhos: defeito (falha no código), erro (a ação humana que o provoca) e falha (o comportamento incorreto observado). Alguns autores usam as palavras de outra maneira; o edital manda.
Caixa-preta e caixa-branca
| Abordagem | Base do teste | Técnicas |
|---|---|---|
| Caixa-preta (funcional) | requisitos e comportamento externo, sem olhar o código | partição de equivalência, análise do valor limite, tabela de decisão |
| Caixa-branca (estrutural) | a estrutura interna do código | cobertura de comandos, de decisões (ramos) e de caminhos |
Partição de equivalência e valor limite (executado)
Considere a regra: a nota vai de 0 a 100; é aprovado quem tem 60 ou mais; fora do intervalo, a entrada é inválida.
Partição de equivalência divide as entradas em classes em que se espera o mesmo comportamento, e testa um representante de cada. Aqui há quatro classes: inválida abaixo de 0, válida reprovada de 0 a 59, válida aprovada de 60 a 100 e inválida acima de 100.
Análise do valor limite observa que os defeitos se concentram nas fronteiras. Testam-se os valores nas bordas e ao lado delas. A função foi implementada e rodada com estes valores:
| Entrada | Classe | Resultado obtido |
|---|---|---|
| -1 | inválida | inválida |
| 0 | reprovada (limite inferior) | reprovado |
| 1 | reprovada | reprovado |
| 59 | reprovada (limite superior) | reprovado |
| 60 | aprovada (limite inferior) | aprovado |
| 61 | aprovada | aprovado |
| 100 | aprovada (limite superior) | aprovado |
| 101 | inválida | inválida |
Com nove valores, as quatro classes e todas as fronteiras ficam cobertas. Um erro típico de implementação, escrever > em vez de >=, só seria revelado pelo teste do valor 60; um representante comum, como 80, não o pegaria. Esse é o argumento a favor do valor limite.
Cobertura na caixa-branca
Para o código:
def preco(valor, socio):
d = 0
if socio:
d = 10
return valor - dUm único teste, preco(100, True), que devolve 90, executa todos os comandos: 100% de cobertura de comandos. Mas o caminho em que socio é falso nunca foi exercitado: a cobertura de decisões (ramos) é de apenas metade, pois só o ramo verdadeiro foi percorrido. Um segundo teste, preco(100, False), que devolve 100, completa os dois ramos. Moral: cobertura de comandos é a mais fraca; cobertura de decisões é mais forte.
Testes automatizados e desenvolvimento orientado a testes
Testes de unidade automatizados podem rodar a cada alteração, dentro de um processo de integração contínua. No desenvolvimento orientado a testes (TDD), escreve-se primeiro um teste que falha, depois o código mínimo para passar, e depois refatora-se.
Erros comuns
- Achar que requisito não funcional é opcional.
- Confundir teste de integração (entre módulos) com teste de sistema (conjunto completo).
- Dizer que teste de aceitação é feito pelos desenvolvedores: quem valida é o cliente ou usuário.
- Atribuir à caixa-preta a leitura do código.
- Achar que 100% de cobertura de comandos garante ausência de defeitos.
- Testar apenas valores do meio do intervalo.
Fontes e atualização
Não há norma oficial brasileira sobre a engenharia de software; o conteúdo segue a literatura clássica da área. O teste de valor limite e o exemplo de cobertura foram executados em código de teste. Terminologias de teste variam entre autores e normas técnicas: confira a bibliografia do edital.
Próximos passos
- Veja os processos em ciclos de vida de software e métodos ágeis.
- Modele requisitos com UML: classes e casos de uso.
- Entenda a carreira em desenvolvedor de software no serviço público.