Transcript for:
Aula 3 - Engenharia de Software: Teste de Software

Boa noite a todos nesse momento conectados para a terceira aula síncrona da disciplina de engenharia de software do semestre 20241 do curso de informática para internet Campus IFCE Paracuru meus caros hoje segunda-feira dia 3 de Junho iniciamos então aí o último mês desse primeiro semestre e a gente dá seguimento aqui à nossa disciplina com a temática hoje voltada a teste de software principalmente antes da gente entrar no assunto das nossas discussões de hoje eu vou eh mostrar aqui para vocês um pouquinho a gente conversou Opa O Lucas tá conectando só um instante eu vou mostrar aqui para vocês só como é que ficou a questão aqui da da atividade que foi entregue tá é bom que o Lucas chegou agora ele pode verificar Vou compartilhar aqui toda a tela para que vocês possam ver o que vai ocorrer vai inicialmente vai acontecer aquele efeito de captura recursiva uma tela dentro da outra pronto então vamos lá aqui no Moodle Essas são as entregas real né a gente tem aqui qualquer um dos arquivos Eu testei com todos tá pegar aqui o primeiro no caso do Geová eu não sei se vocês estão visualizando agora tá aparecendo a a janelinha de salvar como né então salvando o arquivo diz que já existe pedi para substituir e agora vou pedir para abrir aqui no Excel Aí ele dá uma mensagem indicando encontramos um problema você quer que tentemos recuperar eu digo sim e a a mensagem que ele exibe é Microsoft Excel estava tentando abrir e reparar o arquivo para iniciar esse processo novamente escolha abrir e reparar na caixa de diálogo abrir arquivo tá deixa eu ver se eu consigo fazer isso procurar abrir arquivo abrir e reparar vamos ver se dá certo agora Aí ele diz encontramos um problema tentando que T corrigir e ele não consegue abrir o arquivo Tá certo eh eu posso tentar eventualmente instalar aqui o WPS ou ou até mesmo libreoffice ou Abrir Quem sabe no documento do Google não vou perder tempo com isso agora na no tempo da nossa aula a gente eu faço esse teste posteriormente e confirmo para vocês tá admitindo que eh não consiga abrir aqui o arquivo eu estendo o prazo e peço que vocês reenvie se vocês fizeram em planilha do Google na web eh Vocês podem mandar só o link ao invés de baixar o arquivo a entrega tava prevista para envio de texto também aí vocês podem copiar e colar o link lá na o link na na telinha lá de resposta tá certo desculpem antes de apresentar aqui o tema da aula vamos voltar aqui para me e vamos lá voltar aqui pro Moodle tá muito bem bom então indo aqui pra tela inicial terceira unidade vamos melhorar aqui o zoom confirmem aí se tá legível para vocês eu não sei se vocês estão sabendo acredito que sim o Google Meet antigamente a gente só conseguia ampliar a tela no dispositivo móvel fazia esse movimento de pinça e ele aumentava uma área da tela agora no computador isso também tá sendo possível tá se se vocês estiverem eh acompanhando participando de uma reunião pelo computador isso também é possível mas vamos lá unidade três material de apoio aqui a gente tem eh slides um vídeo que são testes unitários e o nosso material tá voltando para a unidade três nós temos aqui o fórum atividade previsto para realização né Olá caros estudantes neste fórum vamos tratar sobre testes de software a intenção é criar um espaço de discussão colaborativa onde cada um de vocês poderá compartilhar experiências dúvidas e conhecimentos sobre estratégias de teste aí vão as orientações fazer três postagens de acordo com os itens a seguir a avaliação será realizada de acordo com as postagens considerando a quantidade de postagens e a esse termo aqui é discutível pessoal tem gente que diz que é corretude tem outros que dizem que é corree eu prefiro e a correção das informações ou seja se elas estão corretas né Lembrando que este espaço é colabor e tal então segue voltando à unidade três aqui a gente tem a tarefa e posteriormente a gente vai ter aí outros arquivos da gravação e etc e tal certo o que é que a tarefa pede faço o download do arquivo na unidade TR tarefa um responda à tarefa proposta depois deposite sua sua atividade neste espaço eu vou abrir aqui o arquivo só para dar uma olhada rápida ele não tá aparecendo para vocês porque tá compartilhada a aba do navegador tá tarefa tem como objetivo proporcionar aos estudantes de experiência prática conceitos iniciais de teste aí vem aqui seis instruções critérios de avaliação e tal então depois deem uma olhadinha com calma se surgirem dúvidas eh coloquem pra gente e a gente vai discutindo e buscando esclarecer todas elas Tá certo então a unidade três como a gente já mencionou ela vai endereçar teste de software é o que a gente vai começar a ver agora um pouquinho a discussão bom interrompeu aqui o compartilhamento eu vou fazer o seguinte só um instante eu vou tirar aqui a aba do Google Meet colocar no segundo monitor E aí eu compartilho toda a tela e não dá mais aquele efeito de de captura recursiva E assim a gente ganha flexibilidade aqui ao longo das nossas discussões muito bem estamos aí com o slide Ok bom pessoal capitulando né É sempre bom a gente fazer um resgate daquilo que já foi feito do que foi discutido e estudado primeiro dia a gente teve uma discussão muito densa né com muita informação falando um pouquinho uma noção muito introdutória que envolvia a gerência de projeto falando sobre engenharia de software abordamos rapidamente estimativa o que era o conceito de medições de métricas e de indicadores Então realmente Foi uma discussão ão tência né e na semana passada nós endereçamos em mais detalhe aquela atividade aquele assunto que é de estimativa de software estimar software não é uma coisa trivial pelo caráter naturalmente abstrato que é você ter uma indicação de um requisito na forma de uma inscrição textual até você conseguir converter isso em um quantitativo de horas para implementar aquela funcionalidade de escrita né E ainda tem outros fatores né humanos que a gente e técnicos que a gente vê o que podem interferir eh linguagem ferramentas ambiente A maturidade do time Tecnicamente falando né e assim por diante Então hoje o foco da nossa discussão vai recair sobre teste de software que é um outro assunto de grande importância e que muitas vezes é negligenciado por que que é negligenciado porque entre você não ter um código não fazer um código e você tem um código que você sabe que pode ter algum erro eh muita gente termina preferendo preferindo sacrificar o teste porque diz não mas pelo menos eu entrego E aí quando eh o cliente identificar algum defeito eu corrigo né então assim isso é um caso clássico de não vou dizer nem de má práticas mas de péssimas práticas porque o que a engenharia de software se propõe é trazer para o desenvolvimento de software aquela coisa rigorosa da engenharia trabalho com método confiável né aquela coisa que eh assim você sabe onde começa e onde termina que é um processo controlado Então isso é muito difícil mas é possível de se atingir mas para que isso aconteça a gente também precisa se conhecer como organização de desenvolvimento então não adianta simplesmente você chegar e dizer eu vou colocar aqui os melhores programadores os melhores analistas que vai eh Todo projeto que eu desenvolver vai dar certo não vai ter problema porque eu tenho uma equipe extremamente capacitada uma coisa você tem uma um profissional amadurecido Tecnicamente falando outra coisa você tem uma organização de desenvolvimento de software madura são coisas bem diferentes Não adianta só você juntar gente boa experiente capacitada para você dizer o projeto vai sair no prazo sem defeito atendendo as expectativas do cliente com qualidade tudo bonitinho não é assim né o testes são um ponto de extrema importância pra gente garantir que não existem defeitos ou que se eles existirem que eles sejam conhecidos que possam ser documentados e obviamente corrigidos Em algum momento quando a gente testa software e existe um defeito e esse defeito não é detectado o que falhou não foi nemum sistema foi o teste tá então o teste é pra gente identificar F mesmo tem muita gente que às vezes durante a realização do teste fica com receio ahi meu Deus e se aparecer algum defeito que bom que apareça porque aí você pode corrigir se não aparecer se não identificar um um um defeito vai estourar na mão do cliente que é o pior cenário que a gente pode eh que pode ocorrer né então vamos lá o geor tá indicando aqui que tá fazendo teste não abriu no Excel abrir pelo libreoffice Está ok então George deixa isso fica aqui comigo eu vou eu verifico isso tá Não precisa se preocupar é alguma questão de incompatibilidade pode ser diversão não tem problema Ok nesse caso então admitindo que as quatro entregas não funcionar direitinho aí Garrido a extensão de prazo vai ser só para você tá certo para que você possa fazer a sua entrega tá bom muito bem então vamos lá testes eh a gente vai falar um pouquinho sobre alguns tipos de teste eh existem vários tipos eles se complementam a gente não vai falar aqui de um teste porque ele é melhor do que outro existem circunstâncias diferentes abrangências diferentes periodicidades diferentes Às vezes você tá aí na eminência de liberar uma versão de um produto de software e aí você libera às vezes para um grupo selecionado previamente identificado de usuários experientes para que eles de fato tentem levar o software a falha e se identificar ótimo porque esse erro ainda não não aparece para o cliente final pro usuário final a empresa pode corrigir e obviamente que quando chegar na versão final ela vai entregar um produto melhor né Então aí a gente tá falando de teste de software que é um termo geral a gente tem o chamado teste de release e de usuário teste de software como a gente já comentou né é uma atividade crítica para a qualidade do sistema que você tá desenvolvendo OK aí eh São apresentadas o que estão sendo colocadas como quatro dimensões o estado do teste ou seja o momento em que ele vai acontecer a técnica metas do teste tem um erro de digitação Deixa eu aproveitar e corrigir logo o que tenho que testar e onde será eh realizado o teste né Eh dependendo do cenário dependendo do projeto eh você tem às vezes um ambiente de produção separado do ambiente de teste o seu conjunto de dados de teste são Dados anonimizados Claro depende do da situação exemplo sistema bancário sistemas eh que envolvem questões de saúde você não pode Expor os dados você não pode quebrar o sigilo bancário nem o sigilo do prontuário de um paciente só porque você precisa testar como fazer isso né através de de técnicas de aleatorização de anonimização Ok eh então Seguindo aqui o objetivo da atividade é o qu né bom a gente precisa projetar um teste antes de executá-lo Claro pessoal testar não é depurar tem muita gente que diz que testou um sistema porque foi ali no depurador linha a linha e garante que a funcionalidade tá sem defeito né eh depurar ajuda sim Em algumas situações depurar extremamente útil notadamente quando você tá precisando entender o que é que está causando um defeito mas não dá pra gente dizer que um sistema está isento porque você depou é uma abordagem que não deve ser utilizada para garantir a qualidade de um software não sozinha você pode até utilizar faz todos os seus testes Quando você vai identificar o ponto exato do defeito eh a depuração pode ajudar né compreender a sequência de passos que tá acontecendo que tá levando o sistema ao erro então antes de testar obviamente a gente faz o projeto dos Testes né E esse projeto tem que fazer com que os testes descubram eh diferentes classes de erro aí você já começa a se questionar não é só erro que existe não que são essas classes de erro né Eh e é importante que isso faça assim sempre buscando minimizar o esforço né e o tempo para essa atividade tá atividade de testes não mostrará a ausência de bugs de defeitos mas mostrará se defeitos de software estão presentes Olha só testar e não encontrar erro não significa a ausência Pode ser que o teste tenha falhado Tem sim de fato um defeito mas eh ele pode ter simplesmente não ter sido capturado né então como lidar com isso né é a diversidade de testes que a gente vai vai eh verificar certo e a gente vai ter que lançar a mão objetivo da atividade de testes né primeiro o que são chamados erros graves tá eh um um erro grave pessoal ele normalmente impede que o sistema seja utilizado que o software seja utilizado tá eh ele impacta diretamente na qualidade e na confiabilidade do software Então imagina uma situação em que você tá carregando o sistema e ele dá um erro logo no processo de carga você não consegue fazer mais nada isso é um erro gravíssimo impossibilita o uso do do sistema pelo usuário né erros facilmente corrigíveis quando encontrados eles impactam na qualidade na confiabilidade né mas não de forma tão grave quanto os anteriores eles são portanto ditos aceitáveis na realidade Talvez o melhor termo nem seja aceitável mas tolerável Você concorda até em utilizar uma versão com defeito porque ela não te limita totalmente ela não te impede de chegar nos seus objetivos maiores Enquanto isso você espera que esses defeitos sejam corrigidos pelo desenvolvedor né então eles são considerados toleráveis ou os testes são inadequados para revelar erros graves verifiquem em softwares que às vezes são baixados geralmente eles têm eh na Sua documentação uma lista de erros conhecidos tá e geralmente são erros simples porque eles não vão impactar o uso do sistema não vão resultar em coisas aberrantes que impedem o a utilização tá se não for encontrado o erro a configuração de testes não foi suficientemente elaborada e podem existir erros eh escondidos tá no cenário ideal se você não identifica erro é porque ele não existe é o cenário que todo mundo gostaria né certeza disso a gente não pode ter a suspeita maior é de que se nenhum defeito foi identificado é porque o teste não conseguiu chegar lá no no ponto do er tá então a questão é todos nós já testamos algum projeto de alguma forma Tá certo e aí eu queria ouvir de vocês agora nesse cenário como é que vocês testaram e quais foram as principais dificuldades os principais desafios nesse processo né as disciplinas anteriores elas podem ser utilizadas como referencial que você vai pensar como é que eu fiz naquele trabalho foi que eu usei para testar foi assim Foi simples simplesmente eu fazer uma depuração ou não eu coloquei o sistema para rodar e sair colocando entradas digitando dados e verificando como é que vocês testaram mesmo que não tivessem uma um conhecimento mais e um conhecimento formal sobre teste né espaço tá aberto aí para vocês em menor escala Professor eu pedi para algum colega testar eh mandando o link né algum familiar abrir o o link antes de colocar realmente em na parte final né Você pede para alguém que não foi quem desenvolveu para testar o sistema né É para acessar como um usuário comum Por exemplo essa é uma ideia interessante Mas quais são as limitações dela dá pra gente fazer isso numa boa quando o sistema é de pequeno porte né É verdade por que essa abordagem ela se mostra limitada com softwares de médio e ou grande porte Eu acho que o público geral El ele vai utilizar várias plataformas diferent para acessar né navegadores por exemplo aparelhos também né sistemas operacional diferentes e se a gente pedir para um conhecido de repente vai ficar um ou dois só sistemas né Muito bem quem mais gostaria de falar da sua experiência de teste aí anteriores né suas experiências anteriores Professor eh Eh o meu contato com com a programação foi desde quando a gente começou o curso né E para teste mesmo assim eu lembro daquela disciplina que o senhor passou acho que era um projeto final daquela agenda o senhor passou até em dupla Acho que foi o contato maior que eu tive mas foi da maneira que o senhor falou ia botando o código tava para rodar ia vendo onde tava dando os erros para poder chegar no que o senhor tava exigindo acho que foi até foi eu e a Alessandra que fez e a gente foi aperfeiçoando tentando e colocar da a gente fez até algo mais do que foi pedido acho que era o sistema mvc que a gente estava implementando é um padrão na realidade não né isso isso foi o meu maior contato assim nessa questão certo ok e o que é que você destaca de positivo e as limitações desse trabalho que você fez que naquela época a nossa visão de testes era muito limitada né a gente na realidade tá estudando mais agora né isso a a dificuldade era muito grande na época Hoje em dia a gente vê assim que era uma coisa bem simples de fazer mas paraa época muito avançado a tive muito ajudar Alessandra que já já entendi um pouco mais da da disciplina eh e me limitado e ao final a gente vê o programa rodando ali é satisfatório né você vê que conseguiu chegar num no que era no objetivo né Mas eh e você fica querendo mostrar para alguém testa aí mandava o arquivo teste aí vê como é legal e mas assim a dificuldade foi bem grande da da época é é realmente é o é o processo natural da gente evoluindo e amadurecendo né Eh Será que quem desenvolve é um bom testador já leram algo Nesse sentido porque o cara conhece bem o código né é de se esperar que ele seja um bom ou um mau testador eu acho que é para ele ser um bom testador né nunca li nada a respeito mas se ele conhece o código ele que desenvolveu é para ele testar Mas sempre tem algo mais né tem quem quem tá de fora A visão é totalmente diferente mas por exemplo eu acho assim que se o eh o camarada ele ele me contratou para desenvolver um soft para ele e eu acho que o a melhor pessoa para testar é o cliente posso até sugerir eu eu fiz todos os testes como o sen eu mostrou aí no nos slides eh o o meu teste não encontrou nenhum erro eu posso chegar pro pro pro o o cliente e falar ó vou te dar um mês aí de teste você Testa o software aí e se tiver de acordo com o que você Tá exigindo eh o o o projeto tá entregue Não sei se tô tô raciocinando da forma seu áudio cortou um pouquinho no final mas eu acho que a gente conseguiu compreender né no finzinho você tava dizendo eu não sei se o raciocínio está com acho que é completo ou correto alguma coisa do tipo né É correto correto professor não sei se eu estou raciocinando correto da da maneira que eu expliquei tá eu eu entendi seu comentário Alguém gostaria de comentar sobre essa essa mesma pergunta que eu fiz aí a ao Garrido Será que o desenvolvedor ele é de fato um bom testador do seu próprio software um problema que eu vejo é que o o desenvolvedor Ele já sabe algum defeito eventualmente do do código né se por exemplo o código tá programado só para para receber uma string por exemplo aí ele quando ele for testar de repente ele vai colocar só frases lá né palavras enquanto que se ele botar uma pessoa qualquer a pessoa vai e digita um número aí o código pode pode quebrar né isso esse comentário aí que o Tiago fez agora por último é exatamente o entendimento que a a área da engenharia de software que a literatura traz porque o que acontece é o seguinte se por um lado o desenvolvedor ele conhece profundamente o seu próprio código por outro lado quando ele vai testar o seu raciocínio está o termo que a gente usa é viciado no sentido de que ele tende a dar entradas eh em conformidade com certos padrões que ele mesmo definiu durante a codificação Thiago exemplificou aí né Sistema espera uma cadeia de caracteres e o cara en fora cadeia então se for dada entrada na eh de um valor numérico hipotéticamente Pode ser que haja um problema por quê Porque você tá fornecendo como entrada de dados algo que o sistema não foi projetado né E aí eh muitas vezes o desenvolvedor ele não consegue perceber se é um caso simples essa questão de formato de tipo de dado de entrada é uma situação simples mas ela é relevante tá muitas vezes nós desenvolvedores percorremos o mesmo caminho a gente não consegue necessariamente enxergar todas as situações que o usuário vai passar e a gente deixa passar problema o que por si só já é um assim uma situação complicada porque pode ser que um determinado usuário não se depare com aquele defeito mas vai ter outro que vai e outro e outro e outro dependendo da quantidade de usuários você vai ter muita gente se deparando com né compromete a sua imagem seu resultado da sua organização né e assim por diante Ok então a estratégia Garrido que você mencionou de trabalhar em dupla com uma outra aluna ela é interessante porque aí eh isso permite se trabalhar com aquilo que nós chamamos de revisão em pares pelo menos já tem uma pessoa que não o próprio desenvolvedor que vai testar co então a chance de identificar defeito de fato é maior Ok mas ainda assim isso não elimina todas as questões relacionadas a teste Principalmente se o que a gente tiver falando é de dar uma determinada entrada muitas vezes até digitando no teclado para que o sistema processe aquela informação e apresente algum cálculo então eh a outra pessoa nos ajuda a verificar se essa entrada de dados tá coerente se não tá e eventualmente até forçar a aplicação ao erro mesmo que às vezes a nossa cabeça fica direcionada Ok então a gente tem alguns relatos típicos de teste acho que quem nunca passou por essa mesma situação eu já depo muito software é um trabalho complexo penoso né usando essa expressão um trabalho penoso porque às vezes dependendo do porte do sistema você vai passar horas e horas eh meio que procurando catando uma agulhinha no palheiro um defeito no meio de algumas milhares de linhas de solta né aí a gente chega num conceito interessante ou melhor dois conceitos que são verificação e validação ou validação e verificação como preferir são conceitos complementares não é que eh Às vezes a gente diz ah uma coisa e outra é porque um choca com o outro não são Ambos são importantes Qual é a ideia da validação a validação ela tem como objetivo assegurar que o eh a ferramenta em desenvolvimento ela está sendo feita com correção né para demonstrar que o sistema de softw corresponde às exigências do cliente e a verificação estamos desculpa eu eu troquei ó a validação é para verificar é para assegurar melhor dizendo que o sistema em desenvolvimento ele bate com a noção de requisitos do usuário ele vai efetivamente eh atender as necessidades desse usuário e a verificação por outro lado é a eh se ele tá em conformidade com a sua especificação né então eh a especificação É o quê É o requisito Será que eu implementei correto tenho que testar a validação é o qu Será que os requisitos do cliente foram compreendidos corretamente e foram todos documentados ou seja a validação ela tá com a preocupação o foco principalmente em dizer o seguinte o que o cliente quer o que ele precisa eu realmente consegui identificar documentar e registrar tá a verificação ela vai dizer o seguinte olha requisito até Ok não tô nem me preocupando com isso eu quero saber se o meu código está batendo com requisito né é uma etapa posterior Desse nosso esforço de desenvolvimento Ok o objetivo da da validação e verificação estabelecer a confiança né na adequação do sistema e do seu objetivo tá eh isso vai depender da finalidade né da expectativa do usuário e do ambiente de marketing né então qual é a finalidade do software o nível de confiança depende do quanto o software é crítico para uma organização e em relação às expectativas do usuário os usuários podem ter expectativas baixas em certos tipos de software quando a expectativa do usuário é baixa a chance de você surpreendê-lo é maior quando a expectativa é alta qualquer detalhe pode ser eh pode ser identificado e gerar um impacto negativo qualquer detalhe né daquilo que não foi atendido daquilo que não estiver correto e assim por diante e quanto ao chamado ambiente de marketing ele tem como objetivo colocar um produto em um mercado rapidamente né Eh e essa questão do tempo ela pode ser até mais importante do que a questão do defeito tá é uma afirmação polêmica aceita por muita gente porque é você se antecipar concorrência Então você sendo primeiro você tá criando mercado você tá provavelmente aumentando aquilo que nós chamamos de market Share que é o o compartilhamento do mercado com os outros concorrentes Mas você quer se posicionar na liderança né então às vezes eh a empresa que vai lançar um produto ela opta por reduzir o escopo eventualmente tolerar até alguns defeitos Desde que não sejam graves né Para que o seu produto chegue antes do produto do cliente me parece que nós por uma situação como essa há bem pouco tempo eu não sei se vocês acompanharam mas a openi lançou há algumas poucas semanas o que eles chamam de GPT for o de OM né Qual é a diferença do GPT qu OM para o GPT normal em termos de funcionalidade o GPT for All ele tem suporte a outras eh a outros modais de informação que não apenas o texto Então ele permite conversação ou seja ele extrai a semântica da sua fala e gera texto ele permite análise de outras fontes de informação como figuras por exemplo tá eh você pode colocar por exemplo escrever uma fórmula uma utilizando algum dispositivo de captura como a câmera do celular e você pode apontar sua câmera pra equação e pedir que ele resolva é é um negócio realmente bem interessante muito bem a Open fez isso numa determinada data e a Google ou o Google acho que dois dias depois lançou o 1.5 pro tá o o gemin é a solução do Google que já nasceu multimodal ele não era só texto como o chpt tá E aí o Google ele tem também e assim é uma solução robusta bem interessante e aí o que que os caras fazem eles vão dizer que lançaram primeiro foram Pioneiros foram inovadores em algum aspecto é para isso que eles têm é para isso que se considera Esse chamado ambiente de tá Para nós que somos da área técnica isso não é tão relevante o impacto dessa questão do marketing é que Muito provavelmente o tempo do desenvolvedor ele vai ser reduzido Olha é preciso entregar até a data tal depois dessa data não adianta mais tá então pra gente é pressão de desenvolvimento aí aqui a gente tem uma ilustração que eu acho que ela é bemu n no processo de verificação pessoal eu tô partindo do requisito segundo seguindo aquele ciclo clássico de desenvolvimento fazendo A modelagem a arquitetura e a codificação então eu tento buscar a coerência entre os meus requisitos e os artefatos que são derivados a partir dele então eu tô interessado em saber se a implementação do requisito está correta Ok E aí eh no caso da da validação aí você tem eh testes de vários tipos e tal até você também certificar que o sistema ele bom cliente me pediu isso eu tô entregando tá eh existe uma aquela preocupação né que a gente já mencionou Será que os requisitos foram todos capturados né E documentados tá então essas duas abordagens elas se complementam tá aí a gente menciona por exemplo a questão da chamada inspeção de de software tá quando a gente fala de inspeção eu tô fazendo uma checagem uma uma análise de algo tá eh e aí nesse caso essa análise ela vai se basear sobre algum tipo de artefato por exemplo o código fonte Então quando você tá analisando o código fonte você tá partindo para uma abordagem que é dita estática você tá vendo o código fonte você identifica você imagina que aquele código fonte ele não vai ser alterado ele está ali eh a versão que você tá inspecionando ela não vai sofrer mudanças porque se isso acontecer você termina perdendo a eh eh eh a a condição de de dizer que encontrou que não encontrou problemas né defeitos ou o que quer que seja certo pode ser inclusive um problema de processo algo que não foi seguido em conformidade com o processo modelo de qualidade tá por outro lado o teste ele já tem uma uma componente diferente da porque o teste ele tá preocupado em ver o sistema funcionando ele quer ver a execução então numa execução você passa um conjunto de valores de entrada e espera uma certa resposta numa outra execução você pode mudar completamente Eh esses dados né E você vai esperar uma outra resposta Tá certo em conformidade com os dados da segunda execução Ok então E para isso o programa tá lá funcionando né ele não tá mais focado naquilo que foi desenvolvido implementado no código fonte que derivou esse nosso sistema certo tipos de teste aí começa uma discussão sobre teste de caixa branca caixa preta agora já que a gente tá saindo aqui de ição e validação eu fiz aqui uma brincadeirinha com o chat GPT Deixa eu só localizar aqui deixa eu ver aqui janela tá fechada a não tá aqui muito bem Olha só vou criar aqui uma nova eh um novo promp que a gente chama tá Vou colocar aqui algumas perguntas para ele primeira pergunta deixa aumentar aqui o zoom para facilitar para vocês tá legível aí Aparentemente sim né aumentar aqui um pouquinho pronto primeira pergunta qual a diferença entre validação e verificação de software que que ele nos diz aqui né A resposta é um pouco longa né deixa ele concluir aí olha aqui pessoal nessa partezinha Aqui de baixo ele permite selecionar entre os modelos gratuitos né então vamos lá Ele explica primeiramente o que é validação e verificação né são processos cruciais que tem objetivos e enfoques diferentes distintos aqui está uma explicação sobre eles né verificação objetivo garantir que o produto de software está sendo construído corretamente eu tô partindo de um requisito eu não tô questionando se o requisito está certo ou errado eu simples estou admitindo o requisito né e o objetivo é o quê no caso eh assegurar que o sistema está ok né então estamos construindo produto corretamente Qual é o foco aqui O processo interno e técnico de assegurar que o softw atende aos requisitos especificados e segue as normas e metodologi definidas métodos comuns tá revisões e inspeções de código avaliação estática testes unitários avaliação dinâmica sistema tá em execução testes de integração também dinâmica análises estáticas de códo essa daí como o próprio nome já sugere não é o caso né de dinâm um operação estática walkthroughs e peer reviews né Eh você verificar o seu sistema fazer toda uma revisão eh e também fazer uso de peer reviews que é quando uma outra pessoa faz uma análise do seu código tá até contextualizada né temem conhecimento e tal eh mas ela vai eh e ela vai fazer o teste justamente com o objetivo de identificar problemas né Isso foi a verificação agora a validação Qual é a ideia aqui garantir que o produto de solta atende às necessidades e expectativas do usuário final Ok então É ele que vai eh definir em última instância se o sistema está ok né se ele tá atendendo as necessidades E por aí vai método foco avaliação externa eem prática de garantir que o software faz o que é esperado métodos comuns testes de aceitação de sistema de usabilidade demonstrações e protótipos além do próprio feedback né aqui é a comparação né do âmbito do tempo de execução de métodos ambos os processos são essenciais OK É isso mesmo então o objetivo de uma pergunta como essa não é a gente dizer Ah esse é melhor o outro é pior vamos a uma segunda pergunta aqui qual a referência utilizada na resposta anterior tá a gente fez uma pergunta agora a gente quer se certificar que que o chpt eh mandou né como resposta se tá correto se faz sentido e aí ele nos diz o seguinte informação de senso comum conceitos amplamente conhecidos na engenharia de software isso pra gente não é suficiente tá Por mais que esteja correto mas a gente normalmente espera encontrar referências né Então aí ele diz assim a resposta anterior foi baseada em conceitos amplamente reconhecidos não foi retirado diretamente de uma fonte segue né aí a outra pergunta que a gente poderia fazer aqui sim para referências específicas e mais detalhadas você pode consultar software enging praction appro cadê for sofw verific validation E também o guia do pmbx tá bom aí você chega e pergunta aqui já que ele tá indicando que essas referências utilizadas são de senso comum pode chegar e dizer ele dá o nome de um autor né Tem Um clássico na área o que presman estabelece sobre a sobre validação de software aí ele vai dizer direitinho Olha só Roger sesman noem seu livro software Engineering fornece uma visão detalhada sobre a validação de software definição e objetivo validação de software segundo o presman eh como processo de garantia que o software cumpre as suas funções previstas e atende as necessidades dos usuários finais e stakeholders a validação Responde à pergunta estamos construindo produto certo aí vem já um comentário sobre validação né eh muito bem aí OK aí você pode fazer mais uma perguntinha que seria e o que ele afirma sobre verificação agora que a gente já sabe sobre validação e sobre verificação mais uma vez né O que ele no caso presma estabelece sobre isso E aí ele vai dizer ó define a verificação como o processo de assegurar que o software foi eh construído de acordo com as especificações e padrões estabelecidos né e segue então isso daqui é muito bom pra gente acelerar consultas né esclarecimento de dúvidas e e assim por diante vamos em frente aqui retornando à nossa apresentação né a gente começar exatamente aqui sobre testes né tipos de teste teste chamado caixa branca e o teste chamado caixa preta por que que a gente usa essas expressões né caixa preta é aquela coisa que eh por ser preta ela não deixa a luz entrar saindo dessa analogia e voltando para o mundo real teste caixa preta você não verifica instrução a instrução você admite que a funcionalidade ali presente está correta tá ou se não estiver vai apresentar problemas e você vai conseguir identificar e corrigir certo E aí veio a expressão de teste caixa branca que é na realidade a proposta oposta ao do caixa preta vai fazer o basicamente é um tipo de teste uma outra abordagem que faz a checagem eh assim ele ele tem acesso a a às partes internas do código de uma função de um módulo de uma classe e com isso em tese o que se deseja é que você tenha uma melhor condição de assegurar que a sua aplicação está correta Ok estágios de desenvolvimento teste de release teste de usuário Olha só você tá desenvolvendo você faz o teste em paralelo com desenvolvimento aí então foi dado esse nome testes de desenvolvimento em segundo plano em segundo lugar nós temos os testes de release no caso equipe separ testa uma versão completa do sistema antes que ela seja liberada para os usuários foi o que a gente falou né você identifica alguém confiável dentro da sua base de usuários eh para que ela sendo um profissional experiente possa no caso fazer uma verificação mais criteriosa né do do seu sistema e os testes de usuário que que muda em relação ao teste release usuários ou potenciais usuários testam o sistema em seu próprio ambiente Ok ou seja saiu da mão da equipe de desenvolvimento caiu na mão do fatídico usuário né quando dá um problema eh Talvez o melhor teste é o do usuário né mas testes de desenvolvimento né que que eles fazem incluem todas as atividades de teste que não não são realizadas pela equipe de desenvolvimento né então teste unitário lembram da analogia caixa preta caixa branca teste unitário é teste caixa branca por quê Porque você vai ter acesso às instruções da funcionalidade daquela rotina teste de componentes em tese é qualquer coisa que você pode precisar reutilizar e finalmente o teste de sistema que é sistema como um todo né desenvolvimento dirigido a testes tá pessoal Deixa eu só verificar aqui uma coisa deixa eu só verar ficar aqui olha só mais uma vez eu fiz aqui uma brincadeirinha com chat PT vamos ver o que é que ele nos diz né Explique como realizar testes unitários pergunta quem aqui já fez implementação de teste unitário pessoal nas disciplinas anteriores vocês testaram eu não tô lembrando não Professor teste ário não né é bem provável que não até pelo próprio relato que vocês fizeram mais lá no início né então vamos tentar entender melhor o que é o teste unitário porque muitas vezes nessas disciplinas de engenharia de sof a gente fala porque tem um teste desse jeito Tem um teste daquele outro é muito linda a discussão mas quando a gente vai na hora do na frente lá do do ambiente de desenvolvimento como é que faz né de fato Então vamos dar uma olhadinha aqui né como realizar Explique como realizar testes unitários de software percebam que aqui não tá mencionando nenhuma linguagem né primeiro ele vai definir o que são testes unitários tem aqui código né escolha uma ferramenta de teste Python JavaScript Java e csharp são linguagens para cada uma delas você poderá encontrar uma ou mais ferramentas de teste unitário escreva testes simples e isolados O que são esses testes simples geralmente são eh chamadas que você vai fazer para ver se assim o código tá funcionando conforme o esperado né Eh cada teste deve ser simples e focado em uma pequena parte estrutura de um teste unitário vamos lá ele já deu um exemplo aqui no Python né e deu também no JavaScript tá eu até eu até tinha feito aqui tinha feito uma solicitação hoje mais cedo né era essa daqui você pode dar exemplos de código fonte muito bem vamos lá o que a gente tá vendo ali já é já é um exemplo tá soma ele até pegou acho que repeti quando eu tinha feito isso hoje mais cedo ele já ele na primeira ele só dava uma explicação Olha só código py Import unit test aqui você tem uma funin bem simples de soma a basse test soma ol só como é quea PR você vai criar aqui algumas funções teste soma positiva e aí você utiliza o comando acert equal para dizer o seguinte soma 1,2 O resultado é TR Então quando você executar um código que passa eh parâmetros reais no caso do teste você vai ter já um indicativo de resposta tá teste soma negativa aí você tá passando aqui ó -1 e -2 né Quanto vai ser o resultado disso é -3 isso daqui é o que a gente chama de classe de teste unitário Então você tem a sua classe é o código de produção que a gente chama e a classe de teste normalmente pessoal a classe de precede ê estrutura de teste unitário ele geralmente segue a estrutura arrange act ou acert eou né O que é o arrange configure as condições iniciais e variáveis necessárias o execute a unidade de teste e finalmente oer verifique se o resultado é o esperado né aqui tem um exemplo Zinho um outro com JavaScript executar os testes integração contínua prática de teste unitário Aí ele dá aqui ó mocking and stubing né que é o qu Qual é o objetivo disso isolar o comportamento de unidades individuais Ou seja você tá você tá definindo escopos mais precisos para o seu teste né refatoração e manutenção de teste isso daqui pode ser necessário quando você identifica que o seu código pode ser melhorado ou corrigido de alguma forma né então a medida em que o software evolui mantenha seus testes atualizados refat os testes no caso né junto do código para garantir que continuem verificando corretamente a funcionalidade aí foi quando eu fiz a pergunta né Você pode dar um exemplo aí ele põe lá DF soma a + b caso de teste unitário mesma coisa né exemplo dois função que verifica se o número é primo pergunta é primo aí os testes são feitos aqui né primeiro ele verifica se n é menor do que 1 retornando falso depois ele vai fazer o quê vai fazer aqui um laço de repetição para uma variável de controle I no intervalo que vai de dois até um certo valor né que o n é o parâmetro então elevado a meio significa a sua raiz quadrada mais um OK se n for diferente de I Ô Desculpe se n por i é igual a z0 eu vi o porcento e li foi diferente se n por i é igual a 0 o que que essa operação faz pega o resto né então se identificar ele retorna falso finaliza a execução e volta e quando termino o laço ele dá continuidade código de teste unitário Olha só não é tão pequenininho como quanto a interior né e Import unit test from primo Import e primo aí você tem a classe aqui test primo teste é primo e aí passando como parâmetro uma al referência aí vai lá ó Acer teste se não é primo ele vai passar aqui alguns exemplos do que não é primo né E se for um número primo muito grande D alguns exemplos certo classe de teste ou seja isso daqui é para testar isso aqui certo teste dois função que verifica se um número é primo a gente já viu teste três classe para manipulação de uma lista de tarefas E por aí vai tá certo então ele traz Aí alguns exemplos para pra gente eh verificar melhor e tentar compreender né o objetivo da gente a compreender aqui um pouco melhor e ele ainda diz mais ó como é que você executa Python - M unit test teste underline soma que é o nome do arquivo né Alguém escreveu alguma coisa aqui Diga lá gar Professor Existe alguma quantidade uma regra que diga ah você tem que fazer tantos testes para para que eu possa entregar o só dizer não o software agora tá Tá OK tá tudo rodando importante a sua pergunta não é uma questão de quantidade porque mais uma vez quantidade não significa qualidade no caso do teste Mas você tá falando de abrangência que é um percentual que que vai no final das contas resultar em um percentual de cobertura efetivamente quanto do seu código está tem teste de de tem código de de teste unitário correspondente né então o ideal é o quê trabalhar com 100% Às vezes isso não é factível né mas eh realmente A grande questão é a cobertura se a cobertura for de 80% dependendo do contexto pode ser aceitado tá então eh a resposta vai pela abrangência pela cobertura e não por um número absoluto de quantidade de teste certo isso Responde sua dúvida Ok professor entendi joi bom então aqui ele mostra até como realizar o teste né E aqui sendo ó teste to do esse daqui é o código [Música] fonte então isso daqui é depois se vocês quiserem eu posso exportar essa essas páginas de de comandos e respostas para que vocês possam dar uma olhada mas onde o que que eu acho que é mais interessante é vocês agirem com a ferramenta Tá bom então voltando aqui testes de desenvolvimento né o teste unitário de componentes de sistema E aí a gente vai falar agora sobre o que é o tdd que é uma sigla que vem do inglês né test driven development né Aí é um teste é uma na realidade uma abordagem uma metodologia para você desenvolver teste desculpa desenvolver software orientado a teste certo aí a ideia Olha só como a coisa valoriza como o modelo valoriza os testes né os testes são escritos antes do código fonte né E passar nos testes é o fator crítico de desenvolvimento depois código fonte é desenvolvido de forma incremental óbvio né você não vai conseguir desenvolver para todo o sistema de uma vez você tem que começar por um ponto e a partir daí vai expandindo né Essa abordagem foi definida pelo por um dos métodos ágeis que se chama Extreme programming tá de uma forma geral A ideia é simples A ideia é o quê você vai planejar o seu teste e depois você vai projetar né diferença is aqui é de nível de visão né mais alto nível planejar projetar Como vai fazer tá E aí você segue aqui até você chegar na cachinha de teste propriamente dito de execução né E aí tem uma tomada de decisão correto se sim você vem por aqui sen não você volta pra prancheta a o código submete novamente ao teste pode ficar fazendo isso ou eh segue adiante né se a resposta aqui for positiva você vai verificar se isso finaliza o seu sistema se sim joia Maravilha senão no caso o que que você faz você refat o seu teste Tá certo refatorar significa o quê Eh desculpa refatorar o código não o teste né Pode até ser que refat o teste também refatorar pessoal é fazer uma revisão que pode ser inclusive bem abrangente na literatura a gente vai ver que esse refatorar pode ser para você aprimorar o seu código melhorando desempenho eficiência bem são várias as situações né então vamos só ver aqui mais uma vez aqui verificar se teste é automatizado teste de usuário mais um e aqui a gente faz a seguinte pergunta o que é tdd em engenharia de software deixa ele responder aí pra gente olha aqui o o balãozinho né as respostas serão fornecidas pelo GPT 3.5 até que o seu limite após 22:15 seja redefinido ele é grato é grato ele é grátis mas eh com um teto baixo né mas mesmo assim ó eh vamos lá ele tá indicando né o significado da sigla que a gente já tinha mencionado desenvolvimento orientado a testes né Eh pessoal quando a gente se propõe a desenvolver software de forma realmente séria visando garantir que o sistema vai sair bem feito eh com o mínimo de erros possível não dá para você desenvolver código e só depois e pensar em testar a coisa tem que est entremeada podfic o testo codifica O testo tá eh mas o a implementação desse código de teste unitário ela precede o chamado código de produção tá aí ele diz assim é uma prática de desenvolvimento de software onde os testes são escritos testes são escritos antes do código funcional ok Porque você planeja o seu teste e ele não deve ser viciado você tem que pensar o seguinte o que é que é correto na funcionalidade que eu tô que eu vou implementar quando você já implementou você já pensou nos caminhos nos nas situações e tal e pode eventualmente eh cometer falhas também no no teste Lógico ninguém tá isento desse risco de de cometer falhas né seja criando teste antes ou criando teste em paralelo ou depois do código nós somos seres humanos e estamos sujeitos a a fal agora o que nós queremos evitar com isso que é codificar o teste antes é evitar aquilo que a gente falou mais lá pro início que é o próprio desenvolvedor testar o seu código E aí com isso alguns vícios podem vir para o teste e defeitos podem passar né Aí ele diz o tdd geralmente segue um ciclo curto e repetitivo de Três Passos o Red que é o primeiro vermelho escrever o teste unitário que falhe esse teste deve descrever uma nova funcionalidade ou comportamento desejado uma forma da gente fazer isso pessoal é a gente eh implementar uma funcionalidade só com a sua interface sem você colocar código ali né só o no caso do Python o p Ou seja é um método virtual né o teste falha porque a funcionalidade não foi implementada óbvio segundo segunda etapa Verde no caso né você vai escrever o código mínimo necessário para fazer com que o teste passe ou seja nós estamos preocupados em escrever um código que seja reduzido não é para que ele seja limitado é para que você preze sempre pela eficiência né Você tem dois pedaços de código que implementam digamos o mesmo cálculo um tem 100 linhas e o outro tem 1000 linhas e os dois fazem exatamente a mesma coisa qual é o que você deve eh preferir o de 100 que é mais leve é mais rápido tende a ser mais rápido é mais eficiente né então nós vamos tentar escrever o código o mais simples possível para fazer com que aquele teste que foi projetado no estágio vermelho anterior possa funcionar né Isso pode envolver a implementação de novas funções métodos ou classes bem como a modificação de algum existente e o terceiro terceiro estágio que é o de refatorar então uma vez que você fez teste unitário o o código do teste o código do da funcionalidade propriamente dita que vai executar Se tiver tudo OK aí você vai procurar possibilidades de melhorar o seu código como refatorando tá principais benefícios ele traz Aí qualidade de código manutenibilidade documentação e o design melhorado né Muito bem isso nos traz uma visão conceitual Tá mas vamos pedir aqui mais uma pista mais uma dica né Deixa eu fazer aqui o ajuste ele alterou já tá refazendo olha como ele é mais suscinto né escrever um teste fazer o teste passar e tal você pode exemplificar a técnica tdd explicada anteriormente com trechos de código Python muito bem e aqui isso vai significar Olha lá escrever o teste unitário tá eh aqui eu fiz uma outra execução mais cedo né ele dizia assim aqui seria apenas o p você não vai implementar a funcionalidade para ela passar de primeira né aí tem aqui ó teste soma unit Test Test Case aí coloca ali uma funin self acerte equal soma 1 e 2 resultado 3 né e neste caso aqui pessoal você tá exemplificando né para os parâmetros 1 e do resultado esperado é 3 aí depois você vai implementar o código que vai efetivamente fazer essa funcionalidade executar né O que que foi aqui a a falha no caso ele diz assim ó escrever um teste primeiro escreveremos um teste que descreve o comportamento que esperamos da função de soma na versão mais completa eu acho que ele não vai deixar não ele tá tá pedindo cartão de crédito aqui né Eh então assim na versão mais completa deixa eu ver aqui teste unitário eu tinha executado só fazer um teste aqui ó não aí como a a sessão já tá autenticada ele reconhece tá ele dá um tempo paraa pessoa poder fazer uso da da versão mais mais recente né bom vocês podem testar também e verificar Infelizmente aqui na hora da aula a gente não vai conseguir corrigir porque o tempo que ele tá dando para voltar a utilizar a versão mais completa é só depois mas o fato é simplificando na primeira versão Você não vai colocar o código da função você vai colocar apenas algo como p não faça nada só diga que a a função tá definida e depois você faz o seu teste que não precisa ser só uma linhazinha como essa tá pessoal aqui ele tá ilustrando de forma extremamente Econômica ele pode verificar se são eh se a soma de números positivos de números valores negativos de um positivo com um negativo de zero com zero tudo isso são situações hipotéticas que você pode eh pedir para ele verificar Tá certo depois você implementa a função para poder executar o teste esperando que ele de fato Rode e funcione depois você vai verificar existe espaço para melhoria no meu código fonte se sim refat ok então essa é a ideia vamos voltar aqui test de release tá e na realidade teste de release você tá prestes a a entregar a versão do seu sistema ele já tá bem adiantado já tá mais amadurecido desde quando os testes iniciaram né então esse daí vai ser o processo de teste uma versão particular Você quer que os usuários eventualmente um subgrupo de usuários credenciados confiáveis testem para ver se eles identificam um problema né Eh qual é o objetivo convencer o fornecedor de que o sistema é bom né é confiável geralmente são processos de teste caixa preta Por quê você não vai abrir o código fonte você quer ver o sistema funcionar para saber se ele tá ok né testes de usuário aí o primeiro foi de release né teste de usuário aquela etapa em que usuários ou clientes fornecem informações e conselhos sobre testes de sistema é Quando você vai colocar a pessoa da situação real né usuário aquele que às vezes é em Informática ou que ele tem algumas práticas no seu na sua rotina de trabalho que podem ente provocar defeitos então o cara vai colocar o sistema para funcionar dentro da sua realidade ele quer que o sistema se adeque as suas necessidades não que ele tenha que eh agir conforme as limitações do sistema né então os usuários ou clientes fornecem informações e conselhos as influências do ambiente de trabalho do usuário tem um efeito importante sobre a confiabilidade desempenho usabilidade e robustez tipos de teste de usuário alfa beta e de aceitação hoje mais cedo eu fiz aqui deixa eu só verificar tá aqui ó teste de usuário foi no no om for no no chat PT for né que é o om Quais são as designações para os testes de usuário no desenvolvimento de softw a ele tem aqui ó usabilidade aceitação teste Beta teste Alfa teste AB teste de campo de facilidade de aprendizado de confiabilidade e disponibilidade até mais do que aquilo que tá lá no slide né para cada um deles ele dá uma breve explicação tá a gente não vai ficar aqui para não ficar cansativo eu disponibilizo esse material para vocês mas é só para vocês verem que tem algo além né só os que são mencionados lá no slide O que é o teste Alfa realizar testes internos antes de liberar para o público um público maior teste Beta né são conduzidos por funcionários ou um grupo restrito de usuários externos selecionados teste Beta testes em um ambiente real por um grupo seleto de usuários externos antes do lançamento aqui você tá tentando chegar cada vez mais próximo da situação real e mais abrangente possível né teste de aceitação validar que o software atende aos requisitos especificados e adequad para uso no ambiente de produção Acho que eram esses né alfa beta e aceitação Ok testes automatizados que é uma outra coisa muito importante pra gente me diga uma coisa vocês acham que uma ferramenta como chpt é testável manualmente e você vai colocar uma legião de pessoas para sair testando as funcionalidades será que funciona desse jeito a gente pode até fazer um teste manual pessoal pode até se dar a esse luxo quando o sistema não é grande nem complexo suficiente eventualmente até dependendo de um certo porte se você tiver um grupo de pessoas dispostas a testar Ok mas o teste automatizado ele assim é a diferença entre a gente fazer um cálculo na mão e a gente pedir para um computador fazer um cálculo em termos de capacidade de você conseguir fazer algo muito mais abrangente né então você precis dispor de um programa ou um script que roda o seu programa e faz verificações automáticas em cima dos dos efeitos colaterais obtidos tá então daí vem a afirmação que a gente falou mais cedo né testar não é depurar testar e verificar presença de erros depurar é seguir o fluxo para identificar um erro conhecido testes automatizados né algumas dúvidas comuns onde comear qual linguagem escolher frameworks como executar os testes se ele executa local ou num determinado ambiente deixa eu verificar porque eu acho que eu fiz aqui Olha só testes automatizados né primeira pergunta o que são testes automatizados são processos Nos quais ferramentas script são utilizadas para executar testes em um programa de forma automática sem a necessidade eh de intervenção manual né E aí Segue tipos de teste automatizados isso é importante a gente ver o teste unitário que a gente já falou Ele é um tipo de teste automatizado porque você não vai executar na unha Rode esse agora Rode aquele o que você faz é dentro de um ambiente de integração contínua em que eventualmente eh você pode rodar periodicamente digamos todo dia de madrugada ele vai fazer a varredura rodar todos os testes unitários né Então aí você pode colocar o teste unitário como parte dessa sua metodologia de teste automatizado testes de Integração no que consiste né é Verificar como está ocorrendo a interação entre componentes né entre funções e coisas do tipo terceiro testes de sistem avalia um sistema como um todo verificando se todos os componentes funcionam corretamente né testes de aceitação ainda eh testes de aceitação são validados pelo usuário e tal teste automatizado que simula o uso de software testes de regressão verificam se novas alterações do código não introduziram efeito de sistema e tal regressão testes de desempenho né para você verificar Porque alguns sistemas têm requisito de desempenho né aplicação bancária é um exemplo que você eh tem muitas vezes um volume enorme de dados né você quer simular muitos usuários os Então tem que fazer teste de desempenho para ver se ele suporta hipoteticamente falando né Eh sei lá 500.000 requisições por segundo né só como ilustração benefícios rapidez eficiência consistência reusabilidade cobertura e o feedback rápido né algumas ferramentas e algumas considerações né Aí eu fiz outra pergunta você pode exemplificar mais detalhadamente o que é integração contínua e como implementá-la num projeto ele vai explicar né que é benefícios como implementar Ok deixa eu ver ver se tem mais alguma pergunta aqui a quantidade de benefícios é extensa né não chegou ao fim Ok voltando aqui para o nosso material eh por onde começo linguagem Framework como executar os testes aí gente não tem muito segredo não vai ter que ter alguma ferramenta que automatiza esse processo os projetos mais críticos você tem um ambiente chamado de integração contínua que vai compilar eh periodicamente o teu sistema E aí no no caso alguém adicionou código novo Testa o que é que ele faz esse ambiente de integração contínuo ele compila pega o executável e utiliza né para uma nova bateria de testes aqui pessoal são algumas das várias ferramentas para isso né aqui um exemplo de teste unitário no caso em JavaScript Ok e é isso é bastante informação também mas é um overview sobre essa parte de teste né OK dá pra gente sair daqui dizendo que vai automatizar teste que vai implementar teste unitário já sei fazer essa aula é uma visão inicial Tá tudo começa com a conscientização se a gente não para a o futuro profissional ele não vai sair com essa consciência de que é necessário que é preciso fazer ele vai querer manter a sua zona de conforto né OK então para você eh fazer um desenvolvimento de software bem feito software correto bonitinho tem que ter metodologia inclusive de teste e não tem jeito tem que testar para você verificar inclusive quais são assim percentual de cobertura percentual de falha de sucesso se você tá fazendo troca de mensagens entre componentes entre sistema e api tudo isso são situações diferentes em que é possível fazer teste né desempenho que a gente falou e assim por diante ok pessoal perguntas tudo certo pessoal muito bem a e elas fazem o teste só automático é automatizado e na realidade para você fazer um teste automatizado você tem que implementar alguns scripts tá com as chamadas de rotinas com configuração de ambientes não é uma coisa tão simples gar é algo que às vezes dependendo do porte da organização você tem um profissional ou até mais especializado focado nisso tá entendi eu pensei que o camarada jogava o código fonte lá e a ferramenta ia testar ela vai testar realmente né mas para que isso aconteça você antes tem que ter preparado as condições para isso né tem que ter lá o seu ambiente de integração contínua com alguma dessas ferramentas que a gente viu aqui cê né com alguma dessas ferramentas ou mais de uma vai depender aí da da cultura eh organizacional teste não é uma coisa simples também não é só chegar vou dizer vou testar teste dá trabalho tem que planejar bonitinho criar os scripts Aí sim preparar o ambiente Aí sim você eh você consegue fazer essa esse processo de automatização Imagina aí como é que você vai testar por exemplo se um sistema bancário é capaz de processar digamos 300.000 requisições por minuto né que mais gente não mais sem perguntas muito bem colocar então aqui a nossa chamada no chat pedindo que vocês respondam aí com presente é mais um ponto de controle né o jovan George Geová Lucas Garrido Thiago cadori muito bem pessoal então é isso se não temos mais perguntas agradeço aqui a vocês de novo a parceria né até esse momento e a gente vai se falando eu vou posteriormente dar um feedback a vocês aí sobre a a questão da da avaliação que a gente começou antes mesmo da da gravação né E sinalizo para vocês se vai haver necessidade de uma nova entrega tá bom Garrido eu vou aqui logo depois da da do encerramento já adicionar uma regra para que você possa enviar a a avaliação peço que você me indique aí no no pode ser no WhatsApp mesmo Qual é o Quais são as atividades que ficaram pendentes de entrega tá aí eu faço o ajuste também então é isso mais agradecer a todos vocês a gente se encontra na sexta-feira lá no laboratório né obrigado um abraço boa noite eh