Details
Nothing to say, yet
Comment
Nothing to say, yet
Listen to Aula 6_Tipos_Testes_Caixa_Preta_Branca by Marcelo B Santiago MP3 song. Aula 6_Tipos_Testes_Caixa_Preta_Branca song from Marcelo B Santiago is available on Audio.com. The duration of song is 22:44. This high-quality MP3 track has 248.223 kbps bitrate and was uploaded on 22 Mar 2024. Stream and download Aula 6_Tipos_Testes_Caixa_Preta_Branca by Marcelo B Santiago for free on Audio.com – your ultimate destination for MP3 music.
Comment
Loading comments...
This transcription is about software testing. The speaker discusses the different phases of testing such as unit testing, integration testing, validation testing, and system testing. They emphasize the importance of testing throughout the software development process and mention the need for an independent software testing group. The speaker also talks about the cost of fixing errors in different phases of development and discusses various testing strategies and techniques. They mention the importance of regression testing, smoke testing, and different types of integration testing. Finally, they discuss the objectives of software testing and its critical role in ensuring software quality. Aula 6. Teste de Software. O roteiro, modelo UV de teste, teste de unidade, teste de integração, teste de validação, teste de sistema. Contextualização desta aula, a gente vai falar então do RAPTO, ou seja, processo, gerência, depois o RAPIPA, requisito, análise, projeto, implementação, teste e operação, sendo que o teste, que é o que nós vamos falar agora, vai falar das estratégias de teste, técnicas de teste. Então, embora a fase de teste seja uma fase propriamente dita, o teste tem que fazer parte de todas as fases do desenvolvimento de software. Para toda a entrega produzida, é possível criar um conjunto de testes. Motivação. O que, como, quando testar? Uma boa prática de estudo de software, de engenharia de software, é definir um grupo independente de teste de software, que é o GITS, grupo independente de teste de software, GITS, que procura quebrar o software, não levar para o lado pessoal. O quanto antes achar um erro no software a ser entregue, mais barato fica para corrigir este erro. Se o software for implantado sem o erro, sem que o erro seja corrigido, você pode quebrar até uma empresa com esse problema. Tudo tem que ser testado antes. Objetivos principais. Teste de software é a investigação do software a fim de fornecer informações sobre sua qualidade em relação ao contexto. Isso inclui o processo de utilizar o produto para encontrar seus defeitos. O teste é um processo realizado pelo testador de software, que permeia outros processos da engenharia de software, e que envolve ações que vão de levantamento de requisitos até a execução do teste propriamente dito. Modelos V, testes, o requisito, análise, projeto e código, que seria então a especificação e verificação, que é o requisito, análise, projeto e código, e você tem um contrapartido, o teste de sistema, teste de validação, teste de integração e teste de unidade, que seria a execução ou a validação. Então você tem essa daqui, a seta pra cima. E o requisito, análise, projeto e código, a especificação e verificação, a seta pra baixo. Por isso que chamamos modelos V de testes. Se você especificou tudo e utilizou uma ferramenta case para implementação, a execução do teste pode ser feita de forma automática. Por exemplo, você pode preencher telas de formulários de uma forma automática, usar um software para armazenar todas as entradas que você digitou e depois para futuras modificações. Você pode executar essa bateria de testes, sendo considerado algo muito eficiente. Não custa muito executar o teste, mas sim custa para fazer a especificação do teste. A execução, se você utilizou uma ferramenta case, ela pode ser de forma automática. Vamos falar agora de estratégias, estratégia de teste. Bom, aqui você tem como se fosse um vocabulário, é isso, em que a camada mais externa é a engenharia de sistema. Então, nessa última camada, a engenharia de sistema, ela exige um teste de sistema. Na camada interior, a essa, você tem requisitos e ele exige o teste de validação. Na anterior, seja mais interna, você tem um projeto que precisa de testes de integração. E na última camada, você tem um código que necessita de teste unitário. Então, se você verificar que, ou seja, de fora para dentro da camada, você tem engenharia de sistema, requisitos, projeto e código, você tem então, na outra parte do OCambod, o teste unitário, teste de integração, teste de validação e teste de sistema. Então, de acordo com a fase, se você faz a engenharia do sistema, então se faz o teste do sistema. Se você faz o projeto, então se faz o teste de integração. Se você faz o código, se faz o teste unitário e assim por diante. Fase de testes total, depois do código, se faz todos os testes da seta indo para cima. Características genéricas do teste ou dos testes. A fase de teste começa no início do ciclo de vida. Diferentes técnicas de testes são adequadas em diferentes momentos. Deve ser conduzido pelo desenvolvedor do software em um GITS, que é o grupo independente de teste de software. A execução do teste começa nos componentes e prossegue para fora, em direção à integração de todo o sistema. A execução inicia no varejo, componente, e termina no atacado, todo o sistema. A diferença de teste e depuração. Teste, você procura encontrar erros. E a depuração, você tem o erro e tenta debulgar o código para corrigir esses erros. Custo de corrigir um sistema. Aqui você tem um plano cartesiano, onde no eixo X você tem o rapito, que é o requisito, análise, projeto, código, teste e operação. Ou seja, semelhante ao rapito, não é bem o rapito. É quase que um rapito. Requisito, análise, projeto, código, teste e operação. Isso no eixo X. E no eixo Y, você tem o custo. Essa variação varia como uma exponencial. Lá no requisito, começando a exponencial, lá embaixo, na parte baixa, e vai subindo com as fases do projeto do rapito. Então, por exemplo, quando você tem ali na fase de requisito, esse gráfico, só para lembrar, ele chama custo de corrigir um erro. Que é adaptado pelo Presma. Então, você tem no requisito, o custo é de 139 dólares para cada erro encontrado na fase de requisito. Ele passa, então, a fase de análise. E a fase de projeto, já, cada erro custa 455 dólares. Na fase de código, cada erro é 977 dólares. Na fase de teste, 7.136 dólares. E na fase de operação, já são 14.102 dólares por erro. Ou seja, que seria o ponto mais alto da exponencial, do gráfico exponencial. Teste de unidade. Tipos de teste, que é o teste de unidade. Ele usa as técnicas de teste caixa branca intensamente. Caixa branca é quando você pega o código e faz o teste da lógica do algoritmo. Verifica a menor unidade do projeto, componentes. Dê maior atenção aos componentes com maior. Complexidade ciclomática. Complexidade ciclomática está ligado ao número de condições lógicas. Quanto maior a quantidade de condições lógicas, maior a dificuldade em testar o sistema. Programadores desenvolvem testes de suas rotinas. No primeiro, no código, você tem o teste de unidade, que é o primeiro teste. Depois, no projeto, você tem o teste de integração, que é o segundo teste. Na análise, você tem o teste de validação, que é o terceiro teste. E na fase requisito, você tem o teste de sistema, que é o quarto teste. Ok? Vamos lá. Teste de unidade, também adaptado pelo figura 13.4 do PRESMA. Aqui a gente começa os casos de teste, ou seja, na interface, estrutura de dados locais, condição limite, caminhos independentes e caminhos de manipulação de erros. Aí você faz uma seta dos casos de teste até o pseudocontrolador main, principal. Do pseudocontrolador principal, vai para o módulo a ser testado. E do módulo a ser testado, você vai para o pseudocontrolado. Verifica resultado obtido igual ao esperado. Vamos falar agora de teste de integração. Teste caixa preta. Neste teste, você não quer saber sobre como o código foi implementado. Só quer saber sobre entradas e saídas. Então, teste caixa preta. É adequado o uso de teste caixa preta. Parte 2. Não use a abordagem BigBen, onde todos os componentes são integrados e depois testados. Se coloca toda a ideia em linhas de código e depois tenta testar, aí se perde. Que seria o teste BigBen. Teste regressão. Reexecução de algum subconjunto de teste para garantir que modificações não se propaguem. Ou seja, automatização de teste. Quanto mais ferramentas se usar, mais automatização de testes melhor. Teste fumaça. É o teste diário. Integração descendente. Primeiro em profundidade ou primeiro em largura. Próximo slide. E por fim, o teste ascendente. Validação primeiro na menor unidade do projeto. Componentes. E no próximo slide também nós veremos isso. Então vamos lá, gente. Integrações. Vamos falar do teste descendente. O teste descendente é separado em dois. O teste profundidade e o teste descendente largura. O teste profundidade, se a gente pegar aquele organograma que você tem do M1, que ele ramifica em três subprocessos, M2, M3, M4. Três submódulos. E do M2 para M2, M5, M6. Do M3 para M5, do M5 para o M7. A gente vai ver o seguinte. O teste descendente de profundidade, ele pega o M1, M2, M5, M7. Ou seja, ele vai descendo essa cadeia. Enquanto o teste largura, ele começa do M1 e vai para, no segundo nível, vai para o M3, M4 de forma largura, pela direita, na horizontal. Já o teste ascendente, ele começa de baixo para cima. Por exemplo, ele começa do M7, M5, M2, M1. Ou seja, ele sobe de profundidade. Então, ele é diferente dos testes descendentes. Teste de validação. As técnicas de teste caixa preta são as únicas usadas no teste de validação. Rastreia os requisitos do software visíveis ao usuário final. Verifica a funcionalidade de desempenho. Teste alfa, usuário mais desenvolvedor. Teste beta, apenas usuário. Teste de sistema. Fora dos limites da engenharia de software e sistema de SI, de informação. O software deve ser combinado com outros sistemas. E se a função de desempenho global do sistema é seguida. Depois, teste de recuperação. Garantir que erros não ultrapassem o sistema. Ou, no pior caso, deve reiniciar o sistema automaticamente. Teste de segurança. Teste de estresse. Teste de desempenho. O teste de estresse testa toda a capacidade de um banco de dados. E o teste de desempenho, se é aceitável o tempo de execução e etc. Então, agora, nós vamos para a segunda parte da aula. Nós vamos falar do teste de caminho básico, não é isso? A gente falou do teste V, que é o requisito, que é uma seta para baixo. Está dentro da elipse requisito, análise, projeto e código. E a gente sobe com a execução ou validação, que seria a outra elipse. E dentro tem o teste de unidade, teste de integração, teste de validação e teste de sistema. Motivação. O que, como, quando testar. O teste de software é um elemento crítico da garantia da qualidade de software. E representa a revisão final da especificação, análise, projeto e geração de código. Objetivos principais. Apresentar diferentes técnicas de teste, que serão utilizadas em diferentes momentos do ciclo de vida do desenvolvimento do software. Teste é um processo de execução de um programa para encontrar erros. Um bom caso de teste é aquele que tem alta probabilidade de encontrar erros ainda não descobertos. Princípios relacionados aos requisitos do cliente, planejados muito antes do início dos testes. Começa no varejo e termina no atacado. Não existe teste completo conduzido por terceiros. Aliás, não existe teste completo, é um tópico. E conduzido por terceiros, é outro tópico, que é outro princípio. E 80% dos erros descobertos são relacionados a 20% dos componentes. Então, isolar os componentes suspeitos e testá-los rigorosamente. Essa é um dos princípios. Testabilidade é a facilidade com que um programa é testado e pode ser obtido com o resultado de um bom projeto. Teste de caixa preta. Teste dos requisitos do software visíveis ao cliente final. Modelo para especificação de um caso de teste. 1. Objetivo. Descreve o objetivo do teste indicando o que se pretende como resultado da validação. 2. Condições. Lista as condições para o teste ser executado. 3. Procedimentos. Lista os procedimentos passo a passo em uma tabela para o teste poder ser realizado. Nesta tabela, devemos ter as seguintes colunas. Procedimento e resultado esperado. Teste de caixa branca. É baseado num exame rigoroso do detalhe procedimental, lógica do sistema, algoritmo, ou seja, ele testa o algoritmo. Observação. É impossível testar todas as entradas, mas é viável testar todos os possíveis caminhos distintos que ocorrem no código, chamados linearmente independentes, ou seja, independentes do algoritmo. É impossível testar todas as entradas, mas é viável testar todos os possíveis caminhos distintos, chamados linearmente LI, do algoritmo. Teste de caminho básico. É uma técnica de teste de caixa branca, definida em quatro passos. 1. Grafo de fluxo. 2. Complexidade ciclomática. 3. Caminhos LI. E 4. Casos de teste. Falando da construção de grafo, você tem, então, o seguinte. Quatro modelos aqui. O primeiro modelo é C. Ele ramifica para TRUE ou FALSE, e depois ele segue um caminho único. Ou seja, se algo acontecer, se for verdadeiro, você segue esse caminho. Se for falso, você segue o outro caminho. Que seria, então, esse daqui do TRUE e FALSE. É o C. Você tem o outro modelo, que é o ENQUANTO FAÇA. Enquanto essa condição for verdadeira, faça esse caminho. Então, enquanto faça TRUE, você tem um caminho, e FALSE, você tem outro caminho. Faça ENQUANTO. Então, faça ENQUANTO essa situação for verdadeira, este caminho. Se for falso, faça outro caminho. E você tem CASO. Então, CASO, você faz esse caminho, ou aquele caminho. Ou seja, são nós predicados, em vermelho. Então, você tem quatro. C, ENQUANTO FAÇA, FAÇA ENQUANTO, e o CASO. Conceitos. Grafo de fluxo, definido mediante um algoritmo. Complexidade ciclomática. É a métrica de software que fornece uma medida quantitativa da complexidade lógica de testar um programa definida por VG, arcos, nós, mais dois. Ou igual, hashtag, nós predicados, mais um. Ou igual, hashtag, regiões. 3, caminhos linearmente independentes, LI. E 4, casos de teste. Aqui, o sistema, o professor demonstrou um código. E nesse código, ele tem lá, está codificado com várias situações de programação lógica. Então, primeiro, se compara o grafo de fluxo. Então, esse grafo de fluxo tem 14 círculos, que eles são ligados por várias setas. Na verdade, são 13. 13 círculos ligados por várias setas. E eles são numerados de 1 a 13. E 2, ele tem a complexidade ciclomática, que é como se fosse aquela fórmula do Euler que lembra da face, mais os vértices, menos as arestas, é igual a 2. E é a mesma fórmula, só que se usa outros elementos, por exemplo. Regiões é igual às arestas, menos o nós, mais 2. Então, ele pega esse grafo de fluxo, ele conta quantas regiões tem, quantas arestas, quantos nós, e calcula o número de regiões, por exemplo. As arestas, menos o nós, mais 2. E ele tem o número de regiões. As regiões são, digamos assim, os pontos em que, por exemplo, 3 círculos estão unidos por setas. E essa região no meio, essa área, é uma região. 3 caminhos LI. Então, você pega essas bolinhas, que são numeradas, 1, 2, 3, até 13. Então, de acordo com o caminho que se faz, você tem um caminho, por exemplo, 1, 2, 10, 11 e 13. Caminho 2, 1, 2, 10, 12 e 13. Então, é isso que acontece com os caminhos que são colocados aqui. O algoritmo apresentado no livro prézimo. Então, ou seja, fazer a especificação de caso de teste dá muito trabalho. Então, para cada caso de caminho LI, porque você tenta chegar no caminho LI, é preciso fazer um caso de teste. Segundo, por exemplo, o modelo de teste caixa preta. Fazer caso de teste. Neste exemplo, fazer pelo menos 6 casos de teste, um para cada caminho linearmente independente. Ou seja, fornecer 6 entradas para o algoritmo e 6 resultados esperados, onde cada entrada passa pelo menos um caminho LI distinto, se existir, se não existir, justificar. É interessante definir o modelo para estes casos de teste semelhante ao apresentado para o teste de caixa preta. Aqui você tem as referências e o fim, então, da aula 6.
There are no comments yet.
Be the first! Share your thoughts.
