Capítulo 29 — Perícia digital e análise de malware: medição
Mapa da aula
Aula 29 publicada. Mapa, exemplo, EX085.
flowchart TD
N0["29.1 O que medir"]
N1["29.2 Projeto do teste de exatidão"]
N2["29.3 Completude"]
N3["29.4 Tempo"]
N4["29.5 Protocolo"]
N5["29.6 Incerteza"]
N6["29.7 Linha de base"]
N7["Quem mede"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX085"]
Desenho lógico
flowchart LR
N0["29.1 O que medir"]
N1["29.2 Projeto do teste de exatidão"]
N2["29.3 Completude"]
N3["29.4 Tempo"]
N4["29.5 Protocolo"]
N5["29.6 Incerteza"]
N6["29.7 Linha de base"]
N7["Quem mede"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX085"]
[29.1 O que medir]
|
v
[29.2 Projeto do teste de exatidão]
|
v
[29.3 Completude]
|
v
[29.4 Tempo]
|
v
[29.5 Protocolo]
|
v
[29.6 Incerteza]
|
v
[29.7 Linha de base]
|
v
[Quem mede]
|
v
[Exemplo resolvido] --> [Exercício EX085]
Objetivos de aprendizagem
Você vai (1) definir medições para o EvidenceDesk; (2) medir exatidão, tempo e completude; (3) projetar um protocolo de medição; (4) relatar medições com sua incerteza.
29.1 O que medir
Exatidão: a verificação sinaliza corretamente as cópias alteradas e aprova as inalteradas? Completude: todos os campos obrigatórios estão presentes? Tempo: quanto demoram a entrada e a verificação? Cada medida se vincula a um requisito. A exatidão corresponde ao FR3, a completude ao FR1 e ao FR2, e o tempo ao NFR4. Medir coisas que não correspondem a nenhum requisito ainda pode ser interessante, mas esses resultados vão para um apêndice separado, para que o relatório principal continue ligado ao que foi prometido. Cada medida também declara, antes de qualquer coleta de dados, que resultado contaria como falha.
29.2 Projeto do teste de exatidão
Um conjunto sintético de 200 cópias: 100 inalteradas e 100 com alterações de um único byte em posições aleatórias. Esperado: 100 aprovadas e 100 reprovadas. Qualquer outro resultado é um defeito. As posições aleatórias são escolhidas com uma semente registrada, para que o conjunto exato possa ser regenerado. Priya também inclui posições de borda: o primeiro byte, o último byte e os bytes de cada lado de uma fronteira de bloco, já que é ali que os erros de leitura costumam se esconder. Os resultados esperados são escritos num arquivo antes da execução, e a comparação é feita por script, e não a olho.
29.3 Completude
Em 50 entradas sintéticas feitas por usuários de teste, conte os registros com campos obrigatórios faltando. A meta é zero; o projeto deveria torná-lo impossível. Os usuários de teste recebem uma pressão realista: alguns itens chegam em lotes, e um usuário é interrompido no meio de uma entrada. A contagem inclui registros completos mas obviamente errados, como um horário de apreensão no futuro, porque a validação também deveria pegá-los. Um único campo faltando significa uma falha de projeto, não um erro do usuário. Cada defeito encontrado assim recebe uma correção e um novo teste.
29.4 Tempo
Meça o tempo de verificação por terabyte no hardware de Northfield, repetindo as execuções para ver a variação. Relate a mediana e a amplitude. As execuções repetidas captam efeitos como o cache de disco, as tarefas em segundo plano e a redução de desempenho por calor. Priya limpa os caches entre as execuções quando possível e registra as condições. Ela relata minutos por terabyte, e não os tempos brutos, para que os resultados de imagens de tamanhos diferentes possam ser comparados. Os detalhes do hardware, incluindo o tipo de armazenamento, acompanham cada número. As execuções que falham no meio também ficam no registro.
29.5 Protocolo
Escrito antes da execução: entradas, procedimento, resultados esperados, critérios de aprovação. Os resultados são registrados com a versão da ferramenta e o hardware. Escrever o protocolo primeiro impede que o sucesso seja redefinido discretamente depois de ver os dados. Se uma execução revelar uma falha no próprio protocolo, como um caso de teste faltando, a mudança é registrada como um aditamento com data e motivo, e os resultados de antes e depois do aditamento são relatados separadamente. O protocolo é assinado por Priya e por Hugo antes da primeira execução, e a cópia assinada é guardada com os resultados. Um leitor pode então comparar, linha por linha, o que foi planejado com o que foi feito.
29.6 Incerteza
Cinco execuções cronometradas de 31, 33, 32, 35 e 32 minutos por TB dão uma mediana de 32 e uma amplitude de 31–35. Relatar apenas "32 minutos" esconde a variação. Cinco execuções bastam para mostrar a variação, mas não para estimá-la com precisão, e o relatório diz isso. Se o NFR4 exige 1 TB em menos de quatro horas, até a execução mais lenta, de 35 minutos por terabyte, passa com folga. Declarar a margem em relação ao requisito é mais útil para os gestores do que uma longa discussão estatística. Seriam necessárias mais execuções antes de qualquer afirmação sobre a velocidade típica em outro hardware.
29.7 Linha de base
Meça também o antigo processo em papel, para que a melhoria seja demonstrada, e não presumida. Priya cronometra a entrada em papel dos mesmos cinquenta itens sintéticos e conta os campos faltando nos formulários resultantes. O papel é mais rápido por item, mas deixa lacunas em muitos formulários, enquanto o EvidenceDesk é um pouco mais lento e não deixa nenhuma. Sem a linha de base, o tempo de entrada maior poderia parecer uma regressão, ao passo que a comparação mostra o que o tempo extra compra. Os números da linha de base são guardados para comparações posteriores. Os tempos do papel excluem a digitação posterior dos dados.
Quem mede
As medições executadas pelo desenvolvedor podem ser favoráveis sem que ele perceba. Priya pede a um colega que não construiu o sistema que execute o protocolo escrito, e registra quem executou cada teste. Quando os resultados diferem do esperado, os dois revisam os logs antes que alguém mude o código, para que nunca se faça uma correção para bater com um número que era ele próprio um erro. Os registros de medição são guardados ao lado do protocolo, da versão da ferramenta e da descrição do hardware, para que a gerente da qualidade possa auditá-los depois. Priya também anota quais requisitos ainda não têm medição, para que as lacunas fiquem visíveis em vez de esquecidas.
Exemplo resolvido
Execução de exatidão: 100 inalteradas aprovadas, 100 alteradas reprovadas. Completude: 0 de 50 entradas incompletas. Linha de base em papel: 9 de 50 incompletas. Priya relata essas contagens com a referência ao protocolo.
Caso sintético. Os resultados são inventados.
Erros e limites
As alterações sintéticas testam o que simulam; o truncamento e os arquivos trocados precisam de casos próprios.
Exercícios
- EX085 — Projeto da exatidão. Descreva o teste de exatidão com 200 cópias. Rubrica: 3 = 100 inalteradas, 100 com alteração de um único byte; esperado 100/100; 2 = parcial; 1 = vago; 0 = nada.
- EX086 — Relato do tempo. Relate corretamente as cinco execuções cronometradas. Rubrica: 3 = mediana de 32, amplitude de 31–35 min/TB; 2 = uma delas; 1 = só a média; 0 = nada.
- EX087 — Valor da linha de base. Por que medir o processo em papel? Rubrica: 3 = mostra a melhoria em vez de presumi-la (9/50 contra 0/50); 2 = parcial; 1 = sem motivo; 0 = nada.
Síntese
Meça em relação aos requisitos, com protocolos escritos, linhas de base e variação relatada com honestidade.
Continue estudando — capítulo 29 de 50
← Capítulo 28 (rascunho) · Índice de capítulos do curso · Capítulo 30 (rascunho) →