Testes de Software
Testes devem ser entendidos e tratados com grande consciência por todos os envolvidos no desenvolvimento de um software. Desta forma, este capítulo visa atribuir um pouco mais de conhecimento sobre as técnicas de testes de software.
Iremos trabalhar com conceitos de teste de caixa-preta, ou ainda teste funcional, que visa procurar e identificar falhas existentes na programação. Outro teste, é o teste de caixa-branca, ou ainda teste estrutural, que é um teste que usa a estrutura de controle do projeto para derivar casos de testes.
Em sequência, falaremos também sobre testes de regressão, teste de carga, teste de estresse, teste de usabilidade e teste de segurança, que também são testes importantes e que devem ser conceituados e entendidos por todos os profissionais de tecnologia. Vamos começar nossos estudos?
Entendemos que o objetivo de testar é encontrar erros, e que um bom teste é aquele que tem alta probabilidade de encontrar um erro no sistema. Desta forma um engenheiro, um testador, ou ainda o profissional que irá trabalhar com testes, deve implementar ou projetar testes, que de uma forma ou de outra, possibilitam que o objetivo principal seja atingido; ou seja, atingir o mínimo de esforço para encontrar e resolver possíveis problemas (SOMMERVILLE, 2011).
Sendo assim, as técnicas de teste de software devem apresentar determinadas características importantes, como testabilidade, operabilidade, observabilidade, controlabilidade, decomponibilidade, simplicidade, estabilidade e compreensibilidade.
Quando falamos em testabilidade de software, estamos falando da simplicidade e a facilidade com que um programa de computador pode ser testado; já a operabilidade diz respeito quanto melhor funcionar, mais eficientemente pode ser testado. A observabilidade indica que o que você vê é o que você testa e controlabilidade diz respeito a quanto melhor pudermos controlar o software, mais o teste pode ser automatizado e otimizado. Em sequência, a decomponibilidade, na qual controlando o escopo do teste, podemos isolar problemas mais rapidamente e executar um reteste mais racionalmente. No que diz respeito a simplicidade, quanto menos tiver que testar, mais rapidamente podemos testá-lo; já a estabilidade, quanto menos alterações, menos interrupções no teste; e por fim, a compreensibilidade que diz que quanto mais informações tivermos, mais inteligente será o teste (PRESSMAN; MAXIM, 2016).
O teste de caixa-preta, ou teste funcional ou comportamental, é baseado nos requisitos funcionais do software, com foco nos requisitos da aplicação, nas ações que ela deve desempenhar. Esta técnica não está preocupada em como o sistema age internamente ou com o conteúdo do código, mas com o que é gerado como saída e entrada de dados.
Comparando com outros tipos de testes, podemos dizer que este é relativamente mais simples. Assim, um exemplo simples é que podemos verificar a consistência de dados que serão inseridos e que fazem relacionamento com a interface, ou ainda, inserir possíveis entradas incorretas dos dados e verificar como o sistema se comporta (PRESSMAN; MAXIM, 2016).
No entanto, essa técnica apresenta algumas dificuldades, como por exemplo, testar todas as entradas possíveis. Ela é essencial no desenvolvimento de um sistema, porém, não é suficiente para identificar alguns problemas que ocorrem em projetos de sistema (SOMMERVILLE, 2011).
O teste de caixa-preta é útil para tentarmos encontrar determinados erros, como por exemplo funções incorretas, erros de interface, erros em estrutura de dados ou acesso a base de dados, erros de comportamento ou desempenho, erros de iniciação e término.
Desta forma, ao realizar os testes, devemos buscar simular todo tipo e espécie de erros que qualquer usuário que utilizar o sistema pode cometer, como por exemplo: usar como data de nascimento um valor incorreto, como datas atuais ou futuras; preencher campos com um número insuficientes ou errados; usar valores negativos para números que só aceitam valores positivos, botões que não executam as ações que foram programadas e diversos outros (MOLINARI, 2013).
Segundo Pressman e Maxim, os testes funcionais devem responder às seguintes questões:
● Como a validade funcional é testada?
● Como o comportamento e o desempenho do sistema é testado?
● Que classes de entrada farão bons casos de teste?
● O sistema é particularmente sensível a certos valores de entrada?
● Como as fronteiras de uma classe de dados é isolada?
● Que taxas e volumes de dados o sistema pode tolerar?
● Que efeito combinações específicas de dados terão sobre a operação do sistema? (PRESS; MAXIM, 2016, p. 440)
Esses questionamentos são importantes e facilitam o entendimento de como são os testes funcionais, e claro, que tipo de características negativas devem ser trabalhadas no sistema.
Aplicar novas tecnologias pode auxiliar o desenvolvedor ou o pesquisador do software a executar determinados tipos de testes de uma melhor forma. Mas será que é melhor aplicar apenas métodos ágeis em testes de software?
Antes de iniciar o teste de caixa preta, devemos entender seus objetivos; após isso, deve ser definida uma série de testes. Em outras palavras, o teste de software começa criando um grafo de objetos importantes com suas respectivas relações, para que assim possam ser realizados os testes cabíveis nestes objetivos e relações, a procura de erros.
Pressman e Maxim dizem que:
Para executar esses passos, você começa criando um grafo — uma coleção de nós que representam objetos, ligações que representam as relações entre objetos, pesos de nó que descrevem as propriedades de um nó (por exemplo, o valor específico de um dado ou comportamento de estado), e pesos de ligação (link weights) que descrevem alguma característica de uma ligação. (PRESSMAN; MAXIM, 2016, p. 439)
Podemos verificar a representação simbólica de um grafo na figura a seguir:
Existem alguns métodos de teste comportamental que se utilizam de grafos, como o de modelagem de fluxo de transação, que é relacionado a conexão lógica e transações realizadas; a modelagem de estado finito, que está relacionado a estados observáveis por usuários; e diversos outros.
Este é um método existente no teste de caixa-preta e tem o intuito de dividir o domínio de entrada em classe de dados, e que a partir disso podem ser criados casos de testes, que por sua vez, descobrem uma classe de erros (RIOS; MOREIRA, 2013). Desta forma, podemos dizer que o projeto de casos de teste para particionamento de equivalência possibilita que as classes de equivalência sejam analisadas e avaliadas da melhor forma, dependendo de como são inseridas possíveis entradas.
Podemos verificar na imagem abaixo, um pouco mais sobre o particionamento de equivalência:
Classes de equivalência são estabelecidas conforme algumas regras, que podemos verificar a seguir:
1. Se uma condição de entrada especifica um intervalo, são definidas uma classe de equivalência válida e duas classes de equivalência inválidas.
2. Se uma condição de entrada requer um valor específico, são definidas uma classe de equivalência válida e duas classes de equivalência inválidas.
3. Se uma condição de entrada especifica um membro de um conjunto, são definidas uma classe de equivalência válida e uma classe de equivalência inválida.
4. Se uma condição de entrada for booleana, são definidas uma classe válida e uma inválida. (PRESSMAN; MAXIM, 2016, p. 441).
Estabelecer regras auxiliam na tratativa de problemas de forma adequada, estabelecendo problemas que podem, talvez, ser esquecidos ou tratados de forma errada.
A análise de valor limite é uma técnica de projeto de casos de teste na qual são selecionados possíveis casos de testes que empregam valores considerados limites e finaliza como particionamento de equivalência. Desta forma, dizemos que esta técnica destaca a seleção de casos de teste nas extremidades das classes; e em vez de dedicar-se a somente condições relacionadas a entrada, ela também trabalha com casos de testes relacionados a saída dos dados (MOLINARI, 2013).
A maioria dos engenheiros de software trabalham intuitivamente com a análise de valor limite, desta forma, ao aplicar essas diretrizes, o teste de fronteira será mais completo, podendo assim encontrar mais tipos de erros.
Este tipo de teste é uma técnica que usa informações contidas no modelo de requisitos como base para geração de casos de testes. Também é conhecido como Model-Based Testing – MBT.
Pressman e Maxim citam os cinco passos desta técnica, como podemos verificar a seguir:
1. Analise um modelo comportamental existente para o software ou crie um.
2. Percorra o modelo comportamental e especifique as entradas que forçaram o software a fazer a transição de um estado para outro.
3. Reveja o modelo comportamental e observe as saídas esperadas à medida que o software faz a transição de um estado para outro.
4. Execute os casos de teste.
5. Compare os resultados reais e esperado e tome a ação corretiva necessária. (PRESSMAN; MAXIM, 2016, p. 444).
Podemos dizer que este teste ajuda a descobrir erros no comportamento do software e é extremamente útil ao testar aplicações acionadas por eventos.
Temos a existência de técnicas que trabalham com a parte funcional e a parte estrutural do sistema. Sobre a técnica funcional, ou ainda denominada teste de caixa-preta, a alternativa que melhor a define é:
Esta técnica baseia-se na análise dos laços de repetição existentes em todo software desenvolvido.
Alternativa incorreta. A análise dos laços de repetição acontece na técnica da caixa branca.
Esta técnica é baseada nos requisitos funcionais do software, com foco nos requisitos da aplicação, nas ações que ela deve desempenhar.
Alternativa correta. Esta técnica não está preocupada com o sistema age internamente ou o conteúdo do código, mas com o que é gerado como saída e entrada de dados.
Esta técnica analisa a estrutura de controle, ou seja, como é a estrutura de execução do sistema.
Alternativa incorreta. Esta técnica pertence a técnica de caixa branca.
Esta técnica analisa os fluxos de dados de acordo com a sua localização no sistema.
Alternativa incorreta. Este tipo de teste pertence a técnica de caixa branca.
Esta técnica trabalha com o desenvolvimento de software sem as especificações corretas do sistema.
Alternativa incorreta. Não existe uma técnica que trabalha com esse tipo de característica.
Ao se falar em testes de software, além de entender conceitos, sempre devemos tratar do planejamento correto para se realizar testes de software. Um planejamento pode atribuir tipos de testes em determinados métodos/classes/módulos que podem conter determinados tipos de erros, dependendo das entradas inseridas. Nesse sentido, separamos um link muito interessante que fala sobre como planejar testes de software. Vamos verificar mais esse link e obter mais conceitos sobre o assunto? Acesse em: webinsider.com.br.
O teste de caixa branca também é conhecido como teste estrutural. Com ele, o engenheiro pode criar casos de testes que garantem que todos os caminhos independentes foram exercitados ao menos uma vez; exercitam todas as decisões lógicas; executam todos os ciclos de testes em seus limites e dentro de suas fronteiras operacionais, e exercitam estruturas de dados internas para assegurar a validade (PRESSMAN; MAXIM, 2013).
Neste teste, o testador tem total acesso à estrutura interna, e o fato de conhecer toda esta estrutura, faz com que os testes sejam mais precisos.
Segundo Molinari (2013, p. 166), o teste de caminho básico pode ser definido da seguinte forma:
O teste de caminho básico permite ao projetista de casos de teste derivar uma medida da complexidade lógica de um projeto procedimental e usar essa medida como guia para definir um conjunto base de caminhos de execução. (MOLINARI, 2013, p. 166).
Este tipo de teste trabalha com características relacionadas ao controle da execução do programa, analisando todos os comandos e desvios que pertencem ao mesmo, para que assim possa determinar quais estruturas são necessárias (PRESSMAN; MAXIM, 2016).
Podemos citar alguns critérios para essa técnica, como a chamada “Todos-nós”, que exige que cada comando presente no programa seja executado ao menos uma vez; outra que podemos citar é “Todos-caminhos”, que requer que todas as possibilidades de caminhos de execução no software sejam executados.
Bom, é claro que, se pensarmos globalmente no software, podemos dizer que executar todos os caminhos existentes é uma combinação ideal para um programa, já que podemos executar todas as ações e assim verificar os erros que podem ocorrer.
O teste de condição, como o próprio nome diz, analisa condições. Assim sendo, é um tipo de teste que põe à prova as condições lógicas do software desenvolvido (PRESSMAN; MAXIM, 2013).
Compreende-se que testar toda a condição do sistema é essencial. Esse tipo de teste realiza essa tratativa, além de encontrar outros tipos de erros no programa.
Como condição atrativa para determinadas ações, entende-se, assim, que se algo for verdadeiro, será executado um trecho de código; caso contrário, será executado outro. Assim, temos algumas condições existentes e que trabalham com expressões aritméticas, booleanas e relacionais. Dentro das condições podemos encontrar as simples, que tratam de análises com uma variável; já a composta, trabalha com uma ou mais condições.
Desta forma, podemos entender que os tipos de erros existentes nesse teste dizem respeito aos erros de operador booleano, de variáveis, parênteses, operadores relacionais e erros de expressões aritméticas (MOLINARI, 2013).
O teste de fluxo de dados elege possíveis caminhos de teste que um sistema pode tomar, porém isso depende de como estão localizados as definições e de como são utilizadas as variáveis no programa. As estratégias de fluxo de dados são úteis para selecionar caminhos de teste de um sistema que contenham instruções de laços e IF aninhados (MOLINARI, 2013).
Podemos dizer que uma motivação para a utilização deste teste é a constatação que os testes baseados no fluxo de controle não era suficientes; desta forma foram introduzidos critérios baseados em fluxo de dados, que eram mais adequados a determinados tipos de testes (PRESSMAN; MAXIM, 2016).
“É irreal supor que o teste de fluxo de dados será usado extensivamente ao se testar um grande sistema. No entanto, ele pode ser usado especificamente em áreas do software que sejam suspeitas”. (PRESSMAN; MAXIM, 2016, p.437).
Sabemos que os laços existentes em todos os tipos de programas são fundamentais para a execução de determinados tipos de atividades. Os Testes de laços, ou ainda Teste de Ciclos (loop) tem a finalidade de validar as construções destes laços (PRESSMAN; MAXIM, 2016).
Molinari fala da existência de quatro diferentes tipos de laços (MOLINARI, 2013, p. 166):
• Laços simples;
• Laços Aninhados;
• Laços Concatenados;
• Laços não estruturados
Os testes relacionados aos laços simples podem ser aplicados a estruturas simples de laços de repetição, onde n é o número máximo de vezes que o ciclo é executado (PRESSMAN; MAXIM, 2016).
Classes de ciclos:
Se fôssemos aplicar os testes de ciclos simples para os aninhados, o número de testes possíveis cresceria, desta forma, uma abordagem que ajudará a reduzir o número de testes é:
1. Comece pelo ciclo mais interno. Coloque todos os outros ciclos nos seus valores mínimos.
2. Faça os testes de ciclo simples para o ciclo mais interno mantendo, ao mesmo tempo, os ciclos externos em seus parâmetros mínimos de iteração. Acrescente outros testes para valores fora do intervalo ou excluídos.
3. Trabalhe para fora, fazendo testes para o próximo ciclo, mas mantendo todos os outros ciclos externos nos seus valores mínimos e outros ciclos aninhados com valores “típicos”.
4. Continue até que todos os ciclos tenham sido testados. (PRESSMAN; MAXIM, 2016, p. 438).
Os laços aninhados exigem um pouco mais de cuidado do que os laços simples, assim as abordagens citadas devem ser analisadas adequadamente e cuidadosamente
Testes concatenados podem ser definidos da seguinte forma:
Estes podem ser testados usando a abordagem de ciclos simples, se cada um for independente do outro. No entanto, se dois ciclos forem concatenados e a contagem para o ciclo 1 for usada como valor individual para o ciclo 2, então os ciclos não são independentes. Quando os ciclos não são independentes, é recomendada a abordagem aplicada a ciclos aninhados. (PRESSMAN; MAXIM, 2016, p. 438).
Neste teste, o testador tem total acesso à estrutura interna do sistema e assim possibilita que os testes sejam mais precisos. As características expostas se referem a uma técnica importante dos testes, e que está corretamente representada na alternativa:
Teste de Caixa Preta.
Alternativa incorreta. O conceito acima refere-se ao teste de caixa branca.
Teste de Caixa Branca.
Alternativa correta. Também conhecido como teste estrutural, nela o engenheiro pode criar casos de testes que garantem que todos os caminhos independentes foram exercitados ao menos uma vez e exercitam estruturas de dados internas para assegurar a validade.
Teste Funcional.
Alternativa incorreta. O conceito acima refere-se ao teste de caixa branca.
Teste Baseado em Grafos.
Alternativa incorreta. O conceito acima refere-se ao teste de caixa branca.
Teste de regressão.
Alternativa incorreta. O conceito acima refere-se ao teste de caixa branca.
A preocupação de um pesquisador também é a de executar os testes de software, e, claro, encontrar o máximo de erros e problemas possíveis, para que o software produzido seja entrega com uma grande qualidade ao cliente final. Desta forma, é essencial no aprendizado ter uma visão técnica a respeito dos testes apresentados. Assim sendo, apresentamos o link abaixo que contém um artigo sobre uma visão técnica do teste de caixa branca. Vamos conferir? Acesse: devmedia.com.br.
O teste de regressão nada mais é do que uma técnica que consiste na aplicação de versões mais recentes do software, a fim de verificar que não surgiram novos defeitos em componentes que já foram analisados. Assim, novos componentes ou componentes que foram atualizados são verificados a procura de possíveis problemas com a integração a componentes antigos.
Desta forma, se juntarmos novos componentes ou suas atualizações com os módulos restantes ao nosso software e assim surgirem novos defeitos em partes que não foram alteradas do sistema, dizemos que o sistema regrediu (PRESSMAN; MAXIM, 2016).
De acordo com o ISTBQ (International Software Testing Qualifications Board), um teste de regressão é realizado sempre após outros testes, para assegurar que todos os problemas foram resolvidos. Bom, até aqui conseguimos entender o conceito de testes de regressão. Mas como é que surge o teste de regressão? Novos componentes ou atualizações podem fazer com que partes do sistema falhem, causando defeitos não previstos na construção do sistema. Resumidamente, dizemos que “quebramos” um teste anterior com a nova funcionalidade adicionada.
Nesse conceito, podemos entender então que cada módulo que acrescentamos em um software, como parte do teste de integração, faz com que o mesmo mude, gerando novas informações, novos fluxos de dados, novas entradas e por aí vai. E, claro, essas alterações podem causar determinados problemas. O teste de regressão é a reexecução de um mesmo subconjunto de testes que já foram trabalhados anteriormente no software e que, assim, asseguraram que as alterações realizadas não tenham adicionado novos erros ao sistema. (PRESSMAN; MAXIM, 2016).
O teste de regressão também confirma se todas as mudanças ocorridas devido ao teste, ou por qualquer outra razão, não adicionaram um comportamento possivelmente inesperado, indesejado ou possíveis erros que surgiram ao sistema.
Mas como sabemos quando o teste de regressão deve ser utilizado? Usualmente, o teste de regressão é utilizado durante alguns processos do desenvolvimento do software, como por exemplo durante o desenvolvimento iterativo, depois da realização de depuração, quando iniciaremos a integração de módulos, na manutenção de software, entre outros.
E em relação aos softwares construídos dentro do escopo da orientação a objetos? Bom, não deixa de ser diferente em relação ao exposto anteriormente, porém é aplicado, claro, ao escopo deste paradigma; assim, é utilizado quando uma subclasse é desenvolvida, quando uma superclasse é alterada, quando uma classe é estendida, quando a classe é reusada em outro contexto, quando uma correção de falha é realizada, e assim por diante.
O teste de regressão pode tanto ser executado manualmente ou a partir de ferramentas automatizadas. No teste manual será re-executado o conjunto de todos os casos de testes; e os automatizados; e ainda irão permitir que o responsável pelos testes de software capture determinados casos de testes e possíveis segmentos para re-execução e comparação de informações (MOLINARI, 2013).
O conjunto de testes a ser executado no teste de regressão possui três vertentes diferentes de casos de testes:
• Uma amostra representativa dos testes que usam todas as funções do software.
• Testes adicionais que focalizam as funções de software que podem ser afetadas pela alteração.
• Testes que focalizam os componentes do software que foram alterados. (PRESSMAN; MAXIM; 2016, p. 411).
Devemos compreender também que, a medida que os testes de integração progridem, a quantidade de números de testes de regressão cresce, e muitas vezes, em grande escala. Desta forma, o conjunto de testes que realizam a regressão deve ser implementado de forma a atribuir somente determinados testes que trabalham com uma ou mais classes de erros que podem estar presentes em cada uma das funções principais do sistema (MOLINARI, 2013).
Teste de regressão são importantes para o desenvolvimento de um software. E claro, há diversos materiais e livros que explanam sobre esse tipo de teste. É importante compreender que todos levam a explicar o funcionamento e possíveis estratégias de aplicação deste tipo de teste. Desta forma, separamos um link interessante para leitura, que fala sobre estratégias e como otimizar este tipo de teste da melhor forma. Vamos conferir? Acesse: www.infoq.com/br.
As definições parecem um pouco complicadas, mas, a seguir, iremos apresentar algumas dicas que irão ajudar na identificação do que devemos ou não planejar e testar nesta etapa tão importante.
Bom, uma das dicas é manter mapeada uma rastreabilidade do software, o que nos permitirá saber o que pode ser afetado se aplicados determinadas mudanças no software. Por exemplo, um software de recursos humanos, se alterarmos o cálculo do imposto de renda, podemos verificar a partir da rastreabilidade o que essa alteração irá impactar a geração e emissão dos holerites, devido a possíveis faixas salariais, e no caso, isso deve ser planejado ao realizar as alterações.
Em relação a rotinas críticas, deverão ser identificadas quais rotinas são mais utilizadas pelos clientes, e assim identificar quais são as mais críticas e que não podem apresentar problemas. Devemos tomar cuidado também com testes redundantes e testes que podem falhar em seu objetivo
É uma técnica que consiste na aplicação de versões recentes do software, a fim de verificar a ocorrência de novos defeitos em módulos do software que já foram testados. Esta técnica se refere ao teste de:
Recuperação.
Alternativa incorreta. A definição exposta diz respeito ao teste de regressão.
Regressão.
Alternativa correta. Nesta técnica novos componentes ou componentes que foram atualizados são verificados a procura de possíveis problemas com a integração a componentes antigos.
Desempenho.
Alternativa incorreta. A definição exposta diz respeito ao teste de regressão.
Restauração.
Alternativa incorreta. A definição exposta diz respeito ao teste de regressão.
Disponibilização.
Alternativa incorreta. A definição exposta diz respeito ao teste de regressão.
“O teste de regressão é uma estratégia importante para reduzir “efeitos colaterais”. Execute testes de regressão toda vez que for feita uma alteração grande no software (incluindo a integração de novos componentes)” (PRESSMAN; MAXIM, 2016, p. 411).
A finalidade de um teste de carga é validar e avaliar os limites operacionais do sistema em relação a cargas de trabalho que ele aceita em um ambiente real, para que o mesmo permaneça constante. Em outras palavras, é verificar qual é o limite de dados processados pelo sistema, até que ele não consiga mais processar os dados (PRESSMAN; MAXIM, 2016).
E como esse tipo de teste pode auxiliar as empresas? Imagine você estar acessando um determinado sistema ou site e o mesmo parar de funcionar? É algo que não gostaríamos de passar, não é? Em empresas, pode gerar muito mais do que desgaste, usuário podem perder a produtividade imediatamente; além claro, de ocorrer custos financeiros ou jurídicos.
Desta forma, podemos verificar que os testes de carga auxiliam em prever investimentos desnecessários, realizando claro, planejamentos prévios. Quando bem implementado, o teste reduzirá significativamente o número de falhas (MOLINARI, 2013).
Podemos constatar que através do teste de carga é possível conseguir algumas características, como avaliar a atuação do software que recebe um fluxo de dados intenso, conseguimos avaliar a estabilidade de um sistema durante um período grande de recebimento de carga, e com isso estabelecer uma margem de operação de forma considerável (RIOS; MOREIRA, 2013).
Além disso, podemos verificar se alterações feitas no sistema afetam o seu desempenho e, com isso, podemos identificar pontos críticos. A partir disso, podemos monitorar o desempenho do sistema e assim fornecer métricas que retratam qual é a capacidade de operação do sistema (MOLINARI, 2013).
Temos alguns tipos de testes de carga que podem ser aplicáveis. Dentre eles, temos o constante, que é utilizado quando desejamos aplicar uma carga invariável por um período; o teste por etapa, que é realizado quando queremos aplicar progressivamente um volume de carga e após analisar o desempenho do software; e por fim, o teste baseado em meta, na qual é definido uma meta de desempenho para que o sistema esteja acessível (SOMMERVILLE, 2011).
Os testes de carga também podem ser chamados de teste de performance, e na imagem abaixo podemos verificar quando devemos aplicar, ou realizar estes possíveis testes. A imagem abrange de uma forma simples explicativa de como proceder.
Podemos verificar que temos alguns processos a serem seguidos, e esse ciclo se repete até que seja solucionado os problemas encontrados.
O teste de estresse é como se fosse uma continuação do teste de carga. Assim, também pode ser colocado como um teste de performance que verifica se um software possui robustez, disponibilidade e confiança diante de condições consideradas extremas (RIOS; MOREIRA, 2013).
São consideradas condições de estresse o alto acesso de usuários simultâneos, limitações de recursos computacionais e volume excessivo de dados, o que faz com que haja muita perda de recursos.
Esse tipo de teste é muito vantajoso para o sistema, pois fornece informações que permitem que toda a estrutura de um software seja construído de forma adequada, sendo possível sua evolução a partir da correção dos problemas.
Há alguns exemplos de problemas que ocorrem quando o sistema passa por algum problema relacionado ao estresse, como por exemplo dados perdidos/corrompidos; quando retornado a condições consideradas normais, determinados recursos continuam inaceitáveis e componentes continuam a falhar não atendo alguns comandos, até que o programa trava e para de funcionar (PRESSMAN; MAXIM, 2016).
Há algumas técnicas que devem ser aplicadas ao se trabalhar com testes de estresse, como podemos verificar abaixo:
Ainda sobre o teste de esforço, temos que existem uma variação chamada de alternância de pico, que tem como objetivo elevar a carga até a capacidade máxima, depois diminuí-la para condições normais, e por fim, aumentá-la novamente. Com isso você poderá verificar se o sistema se restabelece de forma adequada com o sobe e desce de instruções.
Vejamos na figura abaixo uma curva de esforço típico de desenvolvimento de uma aplicação web:
Vemos na imagem que dependendo do esforço, o sistema apresenta ciclos que podem causar mais problemas que outros, e que também, dependendo de algumas atualizações realizadas, podem ocorrer problemas de esforço.
O teste de usabilidade tem por objetivo verificar como que o software desenvolvido está sendo compreendido e se está sendo manipulado com facilidade, assim sendo também é analisado o comportamento dos usuários ao se utilizar do software (MOLINARI, 2013).
É um dos testes considerados mais importantes e pode identificar problemas como sistema lento, que averigua quanto um sistema demora para executar uma ação; baixa legibilidade relacionada a parte gráfica do sistema; disposição pouco intuitiva de botões; existência de menus confusos e diversos outros. A existência destes problemas podem ocasionar ao abandono do software por parte do usuário (RIOS; MOREIRA, 2013).
Outra definição que podemos citar é da ISO, com a IEC 9126, que diz que a “usabilidade refere-se a capacidade de uma aplicação ser compreendida, aprendia, utilizada e atrativa para o usuário, em condições de utilização”.
Partindo-se do exposto acima, podemos dizer que o teste de usabilidade também está ligado ao teste de aceitação, já que dependendo de como é a reação do usuário ao utilizar o sistema, o mesmo pode não ser aceito.
Bom, então resumidamente o objetivo deste teste é identificar possíveis problemas que prejudicam a usabilidade da ferramenta. Mas como esse teste é feito e quais os principais benefícios?
O teste pode ser realizado por usuários e a dinâmica é simples: deve-se estabelecer possíveis métricas e em suas execuções devem ser analisados o quanto foi gasto para a finalização, quais erros foram cometidos e qual a opinião dos envolvidos. Assim, após definir estas métricas, o teste é aplicado e os usuários devem realizar diversas tarefas (PRESSMAN; MAXIM, 2016).
Como benefício, podemos citar a minimização dos erros e a geração de um sistema com boa funcionalidade, o que pode gerar um produto atrativo em relação ao mercado de software.
E como sei que meu software é bom para o cliente? Bom, como vimos, a facilidade de uso, na memorização de comandos, segurança no uso e outros, fazem refletir na satisfação do usuário, que consequentemente se traduz na aceitação pelo usuário.
Isso significa que o sistema torna o usuário mais produtivo, já que o usuário não precisa interromper seu trabalho devido a erros ou problemas como travamento do software.
Como vantagens relacionadas a aplicação do teste de usabilidade, é que o custo do desenvolvimento passa a ser menor; faz com que o tempo de teste diminua no ciclo do desenvolvimento; e claro, que um cliente satisfeito irá querer sempre utilizar um sistema (MOLINARI, 2013).
Um dos modos de problemas serem identificados, é aplicando teste de heurística, que nada mais é do que resolver possíveis problemas a partir de experiências práticas. Dessa forma, pode-se adequar certos pontos dependendo da necessidade de um projeto, como por exemplo, a compreensão por parte do usuário, feedbacks, mensagens de erros claras, avaliações relacionadas à experiência e outros (RIOS; MOREIRA, 2013).
Quando falamos a respeito deste teste, o mínimo que um usuário sempre espera é que todo sistema funcione sem imprevistos e sem complexidade. Todo processo de desenvolvimento do software deve explorar isso, a experiência com o usuário; já que o usuário não “liga” para como um sistema é codificado.
Usabilidade faz parte do processo de desenvolvimento de um sistema. Desta forma, é essencial que os envolvidos neste processo entendam como é o funcionamento deste teste. Desta forma, planejar como deve ser realizado este tipo de teste se torna importante. Mas como planejar esse tipo de teste? É o que podemos verificar no link abaixo. Separamos um link bem bacana que nos trará um entendimento melhor sobre esse assunto. Vamos ler? Acesse: blog.ti.lemaf.ufla.br.
Este teste tem o intuito de garantir a segurança do software. Mas como é feito isso? A segurança diz respeito ao funcionamento da aplicação, que seja realizado como fora especificado. Desta forma, é verificado se o software continua funcionando mesmo passando por diversas tentativas ilegais de acesso. Desta forma, são testados todos os mecanismos que protegem o sistema (PRESSMAN; MAXIM, 2016).
Imagine você um site ou um software que manipule dados importantes e confidenciais, é de extrema importância que haja uma proteção recorrente. É mais comum do que imaginamos ocorrer situações como esta, ataques ocorrem a todo momento e isso deve ser trabalho do sistema.
Considerando os conceitos apresentados, o teste de segurança, ou ainda, security testing, visa verificar e determinar qual tipo de precaução deverá ser tomado para determinados tipos de ataques, que podem ser do tipo negação de serviço e diversos outros.
A validação de segurança de um sistema pode ser realizada localizando as falhas inseridas durante a fase de desenvolvimento do projeto, como por exemplo erros humanos no código. Esse tipo de análise pode ser realizada por inspeção de código. Outro tipo de validação, é a verificação da implementação durante a sua execução, na qual entradas de dados são fornecidas para verificar como reagem os mecanismos de segurança (RIOS; MOREIRA, 2013).
Existem diversos tipos de proteção que podem ser implementadas dependendo do tipo de aplicação desenvolvida. Podemos citar o firewall, que realiza filtros e bloqueios contra ataques; mecanismos de autenticação, que validam a identidade de clientes; criptografia, que codifica e protege dados; e diversos outros (PRESSMAN; MAXIM, 2016).
Justamente em cima destes mecanismos que os testes de segurança deverão ser projetados, assim, com o esforço aplicado poderão ser descobertos falhas. Para a aplicação de um projeto de teses, é necessário o conhecimento do funcionamento de cada elemento de segurança.
Teste de segurança ajudam a melhorar significativamente coisas como:
● Ponto de referência para as correções de segurança;
● Definição clara das atividades indicando falhas de segurança;
● Registro de status das atividades de segurança no que tange aos requerimentos para segurança da organização;
● Ajuda na análise de custo-benefício, ou seja, quanto custa a perda de algo? (MOLINARI, 2013, p.190).
Concluímos assim, que o teste de segurança visa aplicar penetrações no software, para que assim o sistema possa apresentar problemas, e posteriormente, serem corrigidos.
É um teste que verifica se o sistema possui robustez, disponibilidade e confiança diante de condições extremas. A alternativa que contempla corretamente tipo de teste definido é:
Regressão.
Alternativa incorreta. A definição acima diz respeito ao teste de estresse.
Estresse.
Alternativa correta. São consideradas condições de estresse o alto acesso de usuários simultâneos, limitações de recursos computacionais e volume excessivo de dados, o que faz com que haja muita perda de recursos.
Carga.
Alternativa incorreta. A definição acima diz respeito ao teste de estresse.
Segurança.
Alternativa incorreta. A definição acima diz respeito ao teste de estresse.
Desempenho.
Alternativa incorreta. A definição acima diz respeito ao teste de estresse.
“O teste de regressão é uma estratégia importante para reduzir “efeitos colaterais”. Execute testes de regressão toda vez que for feita uma alteração grande no software (incluindo a integração de novos componentes)” (PRESSMAN; MAXIM, 2016, p. 411).
Nome do livro: Teste de Software: Produzindo Sistemas Melhores e mais Confiáveis.
Editora: Érica
Autor: Leonardo Molinari
ISBN: 9788571949591
Temos que a qualidade de software tem sido uma das principais agregações ao longo do tempo. Desta forma, como devemos desenvolver sistemas usando essa ciência chamada de testes de software? Para obter esta resposta, devemos ler o livro e verificar que sua divisão em três partes: visão macro da qualidade de software e seus principais elementos, testes de software em detalhes e principais ou grandes áreas de teste. Além disso, o livro apresenta algumas ferramentas importantes que auxiliam no caso de testes.
Nome do filme: JOBS
Gênero: Drama
Ano: 2013
Elenco principal: Ashton Kutcher, Josh Gad, Dermot Mulroney, Matthew Modine, Lukas Haas
O filme conta a história de Steve Jobs, que em 1976 abandonou a faculdade e junto com seu amigo Steve Wozniak, iniciaram uma revolução com a invenção do Apple 1, o primeiro computador pessoal. O filme conta que o computador foi construído na garagem dos pais de Jobs e que a formação da empresa mudou o mundo completamente.
