Pergunta

Estou trabalhando em uma tese sobre a qualidade de medição de um produto. O produto neste caso é um site. Identifiquei vários atributos de qualidade e técnicas de medição.

Um atributo de qualidade é "robustez". Quero medir isso de alguma forma, mas não consigo encontrar nenhuma informação útil como fazer isso de maneira objetiva.

Existe alguma métrica estática ou dinâmica que possa medir a robustez? Ou seja, como a cobertura do teste de unidade, existe uma maneira de medir a robustez como essa? Em caso afirmativo, existe alguma ferramenta (gratuita) que possa fazer isso?

Alguém tem alguma experiência com essas ferramentas?

Por último, mas não menos importante, talvez haja outras maneiras de determinar a robustez, se você tiver alguma idéia sobre isso, eu sou todos ouvidos.

Muito obrigado antecipadamente.

Foi útil?

Solução

Bem, a resposta curta é "não". Robusto pode significar muitas coisas, mas a melhor definição que eu posso encontrar é "executar corretamente em todas as situações". Se você enviar um cabeçalho HTTP ruim para um servidor web robusto, ele não deve travar. Ele deve retornar exatamente o tipo certo de erro e registrar o evento em algum lugar, talvez de maneira configurável. Se um servidor da Web robusto funcionar por muito tempo, sua pegada de memória deve permanecer a mesma.

Muito do que torna um sistema robusto é o manuseio de casos de borda. Bons testes de unidade fazem parte disso, mas é bem provável que não haja testes de unidade para nenhum dos problemas que um sistema tenha (se esses problemas fossem conhecidos, os desenvolvedores provavelmente os teriam corrigido e só então adicionou um teste) .

Infelizmente, é quase impossível medir a robustez de um programa arbitrário, porque, para fazer isso, você precisa saber o que esse programa deveria fazer. Se você tivesse uma especificação, poderá escrever um grande número de testes e executá -los contra qualquer cliente como teste. Por exemplo, observe o teste do navegador do ACID2. Ele mede cuidadosamente o quão bem qualquer navegador da Web está em conformidade com um padrão de uma maneira fácil e repetível. Isso é o mais próximo possível, e as pessoas apontaram muitas falhas com essa abordagem (por exemplo, é um programa que trava com mais frequência, mas uma coisa extra de acordo com a especificação mais robusta?)

Existem, porém, várias verificações que você pode usar como uma estimativa numérica e aproximada da saúde de um sistema. A cobertura do teste de unidade é bastante padrão, assim como seus irmãos, cobertura de filial, cobertura de funções, cobertura de declaração etc. Outra boa opção são programas "fiados" como o FindBugs. Isso pode indicar o potencial de problemas. Os projetos de código aberto são frequentemente julgados pela frequência e recentemente as comissões são feitas ou lançamentos divulgados. Se um projeto tiver um sistema de bugs, você poderá medir quantos bugs foram corrigidos e a porcentagem. Se houver uma instância específica do programa que você está medindo, especialmente um com muita atividade, o MTBF (tempo médio entre falhas) é uma boa medida de robustez (ver Resposta de Philip)

Essas medidas, no entanto, não dizem realmente o quão robusto é um programa. Eles são apenas maneiras de adivinhar. Se fosse fácil descobrir se um programa era robusto, provavelmente faríamos que o compilador verifique.

Boa sorte com sua tese! Espero que você invente algumas novas medidas legais!

Outras dicas

Você poderia olhar para tempo médio entre falhas como uma medida de robustez. O problema é que é uma quantidade teórica que é difícil de medir, principalmente antes de implantar seu produto em uma situação do mundo real com cargas do mundo real. Parte do motivo disso é que o teste geralmente não cobre problemas de escalabilidade no mundo real.

Em nosso livro Fuzzing (de Takanen, Demott, Miller), temos vários capítulos dedicados a métricas e cobertura em testes negativos (robustez, confiabilidade, teste gramatical, fuzzing, muitos nomes para a mesma coisa). Também tentei resumir os aspectos mais importantes em nossa empresa Whitepaper aqui:

http://www.codenomicon.com/products/coverrage.shtml

Trecho de lá:

A cobertura pode ser vista como a soma de dois recursos, precisão e precisão. A precisão está preocupada com a cobertura do protocolo. A precisão dos testes é determinada por quão bem os testes cobrem as diferentes mensagens de protocolo, estruturas de mensagens, tags e definições de dados. A precisão, por outro lado, mede com que precisão os testes podem encontrar erros em diferentes áreas de protocolo. Portanto, a precisão pode ser considerada como uma forma de cobertura de anomalia. No entanto, a precisão e a precisão são termos bastante abstratos, portanto, precisaremos analisar métricas mais específicas para avaliar a cobertura.

O primeiro aspecto da análise de cobertura está relacionado à superfície do ataque. A análise de requisitos de teste sempre começa, identificando as interfaces que precisam de teste. O número de diferentes interfaces e os protocolos que eles implementam em várias camadas define os requisitos para os fuzzhers. Cada protocolo, formato de arquivo ou API podem exigir seu próprio tipo de fuzzher, dependendo dos requisitos de segurança.

A segunda métrica de cobertura está relacionada à especificação que um difuso suporta. Esse tipo de métrica é fácil de usar com os detectores baseados em modelo, pois a base da ferramenta é formada pelas especificações usadas para criar o fuzzfer e, portanto, são fáceis de listar. Um fuzfer baseado em modelo deve cobrir toda a especificação. Visto que os detectadores baseados em mutação não cobrem necessariamente totalmente a especificação, pois a implementação ou a inclusão de uma amostra de troca de mensagens de uma especificação não garante que toda a especificação seja abordada. Normalmente, quando um suporte de especificação baseado em Fuzzher baseado em mutação, significa que é interoperável com os alvos de teste que implementam a especificação.

Especialmente em relação ao protocolo Fuzzing, a terceira métrica mais crítica é o nível de estado da abordagem selecionada. Um fuzfer totalmente aleatório normalmente testará apenas as primeiras mensagens em protocolos complexos de estado. Quanto mais consciente da abordagem de fuzzing você está usando, mais profundo o fuzzer pode ir em trocas de protocolos complexos. O estado é um requisito difícil de definir para as ferramentas de difamação, pois é mais uma métrica para definir a qualidade do modelo de protocolo usada e, portanto, pode, portanto, ser verificada apenas executando os testes.

Eu espero que isto tenha sido útil. Também temos estudos em outras métricas, como analisar a cobertura do código e outros dados mais ou menos inúteis. ;) Métricas é um ótimo tópico para uma tese. Envie -me um email para ari.takanen@codenomicon.com se estiver interessado em ter acesso à nossa extensa pesquisa sobre esse tópico.

A robustez é muito subjetiva, mas você pode dar uma olhada Fingbugs, Cobertura e Hudson que, quando combinado corretamente, pode dar uma sensação de segurança ao longo do tempo que o software é robusto.

Você pode analisar o tempo médio entre as falhas como uma medida de robustez.

O problema com o "MTBF" é que geralmente é medido no tráfego positivo, enquanto as falhas geralmente acontecem em situações inesperadas. Não fornece nenhuma indicação de robustez ou confiabilidade. Não importa se um site permanecer sempre no ambiente de laboratório, ele ainda será invadido em um segundo na Internet se tiver uma fraqueza.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top