Testes destrutivos são testes com o intuito de causar falhas de maneira não controlada em um determinado 'pedaço' de uma aplicação. O objetivo desse tipo de teste é verificar a robustez de um sistema.
Um exemplo de teste destrutivo é tentarmos causar uma negação de serviço (denial of service) de um sistema web. Ou seja, tentar tornar os recursos da aplicação indisponíveis para seus utilizadores. Tais recursos seriam invalidados por sobrecarga. Por exemplo, sobrecarga de memória.
Ao sobrecarregar a memória, o sistema não seria capaz de fornecer determinado tipo de serviço.
Testes de estresse (Stress Tests)
Dependendo da forma que os testes de estresse são conduzidos, podemos classificá-los como testes destrutivos. Tais testes tem por objetivo testar a estabilidade de um sistema inteiro ou de determinada entidade do mesmo.
Testes de estresse envolvem o consumo anormal (acima) das capacidades de um sistema, para testar a robustez, a confiabilidade e a capacidade do sistema, ou de determinado trecho do mesmo, de lidar com erros.
Como todo tipo de teste, temos os resultados esperados para que possamos considerar tais testes satisfatórios. No caso, o resultado esperado é que o sistema, ou a parte do sistema em teste, não venha a ficar indisponível, ou que o sistema ‘quebre’.
E qual a diferença entre testes de estresse e testes de carga?
Simples. Testes de estresse são utilizados para determinar em quais situações o sistema fica indisponível, ‘quebra’. Testes de carga servem para medir tempos de resposta de um sistema, diante da variação da carga de usuários, dados e transações.
Testes de estresse servem para encontrar os elos mais fracos do sistema.
Ainda comparando testes de estresse e carga, podemos fazer as seguintes observações:
1. Durante os testes de estresse, quando as transações são seletivamente ‘estressadas’, o banco de dados não necessariamente estará recebendo excesso carga.
2. Da mesma forma que, durante os testes de carga, o banco de dados pode ter uma carga pesada de dados, sem que isso signifique que as transações estejam sendo ‘estressadas’.
Não consideramos testes de carga como testes destrutivos pois dentre os objetivos, como citados anteriormente, não estão a busca por pontos fracos, nem a ‘quebra’ do sistema.
Para ilustrarmos melhor o conceito de testes destrutivos, podemos pensar em testes destrutivos de automóveis, conhecidos como crash tests.
Crash Tests nada mais são que testes de colisão para detectar se automóveis atendem as especificações de segurança necessárias. Caso não as atendam, isso significa que existem pontos fracos que foram destruídos e o automóvel precisará de ajustes na fabricação.
Foto de um Peugeot 307 durante um teste de colisão:
Exemplo de relatório de Crash Test:
http://www.euroncap.com/tests/peugeot_307_2001/107.aspx
Bom, é isso!
Comentários? Dúvidas? Sintam-se em casa!
Um exemplo de teste destrutivo é tentarmos causar uma negação de serviço (denial of service) de um sistema web. Ou seja, tentar tornar os recursos da aplicação indisponíveis para seus utilizadores. Tais recursos seriam invalidados por sobrecarga. Por exemplo, sobrecarga de memória.
Ao sobrecarregar a memória, o sistema não seria capaz de fornecer determinado tipo de serviço.
Testes de estresse (Stress Tests)
Dependendo da forma que os testes de estresse são conduzidos, podemos classificá-los como testes destrutivos. Tais testes tem por objetivo testar a estabilidade de um sistema inteiro ou de determinada entidade do mesmo.
Testes de estresse envolvem o consumo anormal (acima) das capacidades de um sistema, para testar a robustez, a confiabilidade e a capacidade do sistema, ou de determinado trecho do mesmo, de lidar com erros.
Como todo tipo de teste, temos os resultados esperados para que possamos considerar tais testes satisfatórios. No caso, o resultado esperado é que o sistema, ou a parte do sistema em teste, não venha a ficar indisponível, ou que o sistema ‘quebre’.
E qual a diferença entre testes de estresse e testes de carga?
Simples. Testes de estresse são utilizados para determinar em quais situações o sistema fica indisponível, ‘quebra’. Testes de carga servem para medir tempos de resposta de um sistema, diante da variação da carga de usuários, dados e transações.
Testes de estresse servem para encontrar os elos mais fracos do sistema.
Ainda comparando testes de estresse e carga, podemos fazer as seguintes observações:
1. Durante os testes de estresse, quando as transações são seletivamente ‘estressadas’, o banco de dados não necessariamente estará recebendo excesso carga.
2. Da mesma forma que, durante os testes de carga, o banco de dados pode ter uma carga pesada de dados, sem que isso signifique que as transações estejam sendo ‘estressadas’.
Não consideramos testes de carga como testes destrutivos pois dentre os objetivos, como citados anteriormente, não estão a busca por pontos fracos, nem a ‘quebra’ do sistema.
Para ilustrarmos melhor o conceito de testes destrutivos, podemos pensar em testes destrutivos de automóveis, conhecidos como crash tests.
Crash Tests nada mais são que testes de colisão para detectar se automóveis atendem as especificações de segurança necessárias. Caso não as atendam, isso significa que existem pontos fracos que foram destruídos e o automóvel precisará de ajustes na fabricação.
Foto de um Peugeot 307 durante um teste de colisão:
Exemplo de relatório de Crash Test:
http://www.euroncap.com/tests/peugeot_307_2001/107.aspx
Bom, é isso!
Comentários? Dúvidas? Sintam-se em casa!
Boa tarde! Tenho uma pergunta. Gostaria de saber a opinião de vcs sobre:
ResponderExcluirQual a melhor alternativa para evitar a repetitividade que nos leva ao paradoxo do pesticida? Qual o melhor teste para pegar os bugs desprevenidos?
Além disso, o que diferencia os testes de estresse dos testes destrutivos?
Muito obrigada e um grande abraço!