Integração contínua e a certificação digital do Pucomex - Quem vai digitar a senha???
Closed this issue · 11 comments
Caros colegas. estou enfrentando um problema bem difícil. O portal Único do Comercio Exterior - Pucomex está utilizando uma certificação digital, que abre uma janela para que se digite a senha do token, que, até onde me informaram, não é mapeável pelo dBehave.
Gostaria de saber se isso é verdade.
Não é possível mapear a janela de senha do token, para acessar o Pucomex? Eu já fui informado de que o próprio jBoss é quem solicita o token, e a senha, não sendo possível fazer exceções para bypassar o problema.
Os demais colegas, que trabalham com os testes automatizados do Pucomex, estão fazendo uma story com todos os testes pra rodar tudo de uma vez, e ter que digitar a senha do token apenas uma vez, mas eles estão partindo do zero (sim eles estão tendo que digitar a senha do token na mão, cada vez que se executa o teste automatizado, e rápido, para não haver estouro de tempo).
Eu tenho um legado, e o sistema de acesso antigo permitia a digitação de usuário e senha. Os testes, então , foram estruturados em jobs distintos. Cada teste tinha a sua execução independente, com um login no início. No caso há apenas uma story de reuso, o login.
Para fazer como os demais colegas do Pucomex estão fazendo, eu teria que fazer uma story pra rodar tudo e colocar as muitas story já desenvolvidas, cada qual com dezenas de cenários, como reuso. Quando eu tentei fazer isso, começaram a aparecer as duplicidades de cenários. são dezenas, e mais dezenas, de storys, cada qual com dezenas, e mais dezenas, de cenários.
Inobstante os meus problemas específicos, temos que prover uma solução, porque, da forma como está sendo feita, não vai ser possível a integração contínua, uma vez que a digitação da senha do token não vai ser feita pelo dBehave.
A pergunta que não quer calar... Se não for o dBehave, quem vai digitar a senha???
@malaguti, não é possível mapear a janela de token no DBehave, contudo esta questão já foi resolvida dentro do próprio SERPRO, e para evitar problemas por se tratar de questões de segurança normalmente tratamos internamente.
Outra maneira é utilizar uma solução já comentada em e-mails internos.
A issue que pode te ajudar nisso é a #258
@juliancesar. Eu li sua resposta, e, no afã de resolver o problema, deixei a minha educação de lado. Me desculpe, e obrigado pela ajuda.
@juliancesar. Passamos um pente fino no Sikuli, não só eu como Diego Serpa Neves, que também tentou me ajudar nas minhas dificuldades, e ele não funcionou. Tentamos de várias maneiras diferentes, mas nada.
A conclusão que nós chegamos é que o Sikuli está desativado, ou virtualmente desativado. Tudo que se lê sobre ele tem muito tempo. Todas as solicitações de ajuda nos foruns, e todas as soluções dadas, são muito antigas, e todos os links sugeridos não funcionam mais. Acho uma temeridade incorporar ao dBehave, uma ferramenta que, supostamente, vive seus piores dias de ostracismo. Eu continuo pedindo ajuda, para achar qualquer solução que nos permita a integração contínua, para o PUCOMEX, ainda que, exclusivamente, no desenvolvimento.
@malaguti, estranho que existem outras equipes que conseguiram contornar a situação, como a do próprio Luiz que comentei.
Da parte do DBehave não podemos ajudar muito mais, pois a ferramenta se limita a interagir com o Navegador/WebDriver/HTML e o programa que abre a senha não é conhecido por ela.
Você chego a tentar a técnica sugerida pelo Geraldo Calegari nas trocas de e-mails internos? Acredito que a solução de "retirar" a necessidade de certificado digital seja o caminho que maior probabilidade de sucesso, e para isso basta conversar com a equipe de desenvolvimento.
@juliancesar . O luis usou o sikuli à muito tempo. não era nem essa nova versão denominada de SikuliX, e o java não era esse que existe atualmente. E todos os foruns, levados pelo Google, que eu e o Diego entramos, tem post de, no máximo, 2014. Tentei botar pra funcionar, Diego tentou botar pra funcionar, mas nada. Sempre esbarramos em dependências que o Maven não consegue resolver. Mas, quando a ficha caiu (do desuso do sikulix), nós ficamos mais ainda de pé atrás. Vamos fazer uma tela mok, num servidor de testes, pra resolver isso. Mas, no dia que o cliente demandar teste automatizados em produção, vamos ter problemas. tento ser proativo, com relação à esse problema, e gostaria muito de ter uma solução pra isso.
@malaguti, posso estar enganado mas acredito que não seja recomendado e possivelmente existam até normas que impeçam os testes automatizados em produção, principalmente pq teríamos que ter certificados de produção para testes, o que por si só já inviabilizaria a realização, além de termos que ter outras dezenas de questões como instalar software de testes em produção e acessos entre ambientes de desenvolvimento e produção que são proibidos dentro do Serpro. Devido a estas questões entendo que a sua preocupação não seja necessária para ambientes que não tenham como objetivo fim os testes funcionais e não funcionais.
Obrigado pela colaboração.
@juliancesar. Testes automatizados em produção não precisam necessariamente de nenhuma comunicação entre a produção e o desenvolvimento além de um simples email automático, em caso de falha, e, opcionalmente, à uma consulta ao log de eventos do sistema. Testes automatizados na produção fazem com que o desenvolvimento deixe de ser reativo à um problema percebido pelo cliente, e passe a ser proativo, resolvendo problemas que, muitas vezes, o cliente nem percebeu. Claro que não podemos ter acesso à produção. Mas os programas são postos em produção, assim como os testes automatizados também seriam postos. certificados, softwares, e demais impedimentos, todos eles são perfeitamente contornáveis. E o ganho que o cliente vai ter é enorme. Um salto em qualidade. E o ganho que o desenvolvimento vai ter também é enorme, uma vez, repito, que sairíamos da reatividade, para a proatividade, sempre avisados pelo teste automatizado de produção. Quantas vezes, e quando vai rodar, oque vai testar, isso tudo é só uma questão de fazer acordos com o cliente. Quando o cliente acordar para o quanto ele tem a ganhar com isso, ele vai querer testes automatizados em produção, "rápido, e muito"...
@malaguti, entendo todos os seus ponto e concordo com muitos deles, mas acredito que o DBehave esteja na ponta de todo o processo que você quer iniciar dentro do Serpro. Por isso peço que primeiramente entre em contato com outras áreas (como por exemplo a área responsável pelo Centro de Dados - SUPCD ou até mesmo o Grupo de Testes do Serpro) para verificar a viabilidade da sua proposta, assim como uma conversa com o cliente explicando os ganhos e riscos a que ele serão expostos, depois de tudo isso acertado daremos início ao processo dentro da ferramente DBehave que poderá rodar em paralelo com alguns testes manuais inciais para avaliarmos.
@juliancesar. Essa discussão está muito acima de mim. Eu, na verdade não quero iniciar nada (imagina... quem sou eu, pra começar oque aqui dentro...). Eu apenas gostaria de me preparar, pra, quando o cliente bater na nossa porta, pedindo isso, já estar pronto. E, como eu trabalho desde a década de 70, com essa profissão, que é uma caixa de fazer doidos, e já vi esse filme passar várias vezes, acredito que, muito antes do que possamos supor, o cliente vai bater na nossa porta solicitando isso. E, quando isso acontecer, gostaria de já ter a solução na minha algibeira.
Meus filhos costumam dizer que eu tenho a boca maldita... Que tudo que eu falo que pode acontecer, acontece. Espero que esse não seja o caso.
@malaguti, se você conseguir, tente acessar esse site aqui:
http://voce.serpro/demoiselle-behave/blog/adicionar-a-api-sikuli-junto-com-dbehave
Resolveu aqui, no e-Processo (Salvador).
Não estou achando o exemplo que faz a digitação da senha.
Quando eu tiver um tempinho vou montar aqui no github um exemplo completo (com digitação e tudo que tiver direito) com o uso do Sikuli (estou usando a api na versão 1.1.0, não o SikuliX).
@rogernobre, muito obrigado. Vou estudar, e fazer uma tentativa segunda feira.