logo

Automação além do código - Exemplo de Caso

Quando nós, QA/Tester, ouvimos a palavra automação, logo nossa mente já deixa em cache libs como selenium, protractor e processos de teste de API.
Isso é normal e faz parte do nosso dia a dia, mas é sempre bom lembrar que existe vida além do tradicional Web/API Testing.

Meu último projeto de Automação de Teste foi garantir o End-to-End de um combo entre hardware + software e acredito que ele pode te ajudar a ter uma perspectiva diferente sobre automação, aumentando ainda mais seu repertório sobre como pensar em soluções que fujam do tradicional.

Vou mostrar esse Caso de exemplo explicando quais decisões e processos levaram a desenvolver a solução, dificuldades encontradas no caminho e possíveis soluções.
Por razões de contrato e afins, o código utilizado não será disponibilizado (nem adianta pedir!).


1 - Idéia Geral do Projeto & Codificação Inicial

Um dos holofotes de marketing sobre o produto é que ele tem autonomia mínima de 72h sem nenhuma falha. Em linhas gerais o produto é uma câmera que filma em 360 fazendo live streaming.
Essa câmera possui 4 sensores (lentes) e é conectada à um 'box' (mini computador) que realizada o processo de stitching dos 4 sensores (criando o vídeo 360) e faz o streaming utilizando protocolo RTMP.

Precisávamos ter um End-to-End que fosse o mais fiel a um cenário de produção e que fosse possível executar via Integração Contínua e ou para validar as 72h mínimas de funcionamento prometido.

O projeto já contava com testes de performance do servidor que faz o stitching e também existe testes que validam leaks de memória, mas nenhum teste usando a verdadeira câmera.

Para o meu projeto end-to-end, as validações principais foram feitas através de uma API que retorna um status com a saúde da aplicação, ou seja, a API retorna se a câmera está conectada, se o preview da câmera está sendo feito o "stream", se o "stitching" está funcionando corretamente, se plugin de broadcast estava operando, etc.

Como um bom tester, não devemos nos dar por satisfeitos só porque a Própria aplicação nos diz que está tudo bem com ela, sendo assim, optei por utilizar uma ferramenta chamada ffprobe (https://ffmpeg.org/ffprobe.html) que pega um bytes de uma stream (via protocolo RTMP) ou um arquivo de video / som inteiro e retorna as informações gerais como por exemplo, bitrate de audio e video, codecs utilizado, quantos canais de audio, etc.

Com isso a suite básica de teste com Mockup da câmera já estava pronto e eu podia começar o processo de adicionar a câmera real ao processo de teste e integração continua.

2 - Câmera

Tirando câmeras de segurança, câmeras normais não foram feitas para ficarem 100% do tempo ligadas (não foram projetadas para isso), sendo assim precisávamos de uma forma pra desligar-la toda hora que o teste finalizava ou quando ele não estava sendo executado.

A câmera era conectada ao box através de PoE (https://pt.wikipedia.org/wiki/Power_Over_Ethernet) o que geralmente vem com USB como forma de alimentação.

Eu sabia que era possível controlar um relay via sockets usando uma placa controladora + relay + raspberry, porém o custo + curva de aprendizado (pouca mas ainda assim considerável) + quantidade de cabos e o perigo de se mexer com eletricidade me fez optar pela solução de automação doméstica da Belkin, o WEMO Switch (http://www.belkin.com/us/F7C027-Belkin/p/P-F7C027).

Esse aparelho se conecta na sua rede Wifi e existe uma biblioteca python que ajuda você a integrar o aparelho aos seus scripts E custa só 39 euros (raspberry + placa + relay dá mais que 100 euros).

Outra coisa que me deixou incomodado é que com o script que eu tinha, eu não conseguia dizer 100% que o que vinha da câmera era uma imagem valida, ou seja, poderia ser white_noise com codec e bitrate válido.

3 - Ambiente Físico para Câmera

Eu já havia feito um teste de sincronização de Audio e Vídeo (basicamente o teste verificava se o audio BEEP correspondia a uma sinal visual do video) utilizando Imagem Matchmaking do Opencv2 (http://opencv.org/)
porém qualquer alteração na posição ou tamanho da imagem, a pontuação da imagem varia, sendo quase impossível utilizar isso fora de um ambiente físico 100% controlável e estável

Para ter esse ambiente, resolvi fazer uma caixa de madeira onde a luz e as marcações visuais fossem sempre as mesmas, mas ao fazer a lição de casa e pesquisar sobre como faria a iluminação, como seria o processo de atualização ou troca da câmera, com seria a exaustão do calor e qual seria o peso de tudo isso ( uma caixa de madeira que não fica bamba é uma coisa pesada e não pode ficar em qualquer lugar) , resolvi refatorar a idea.

Comecei a estudar cascades e identificação de objetos via OpenCV e até cheguei a fazer algumas coisas mas elas não eram 100% estáveis para colocar em produção, sendo assim abortei a ideia de criar meu próprio Cascade mas reparei que todos os exemplos em posts da internet usavam o cascade de rostos (cascade sólido da INTEL)(https://github.com/opencv/opencv/tree/master/data/haarcascades) (exemplo de script para deteção de rostos https://github.com/shantnu/FaceDetect/)

BINGO!

No momento que terminei de testar fotos de rostos com diferentes exposições de luz e diferente posicionamento da câmera e fotos e todas deram certo, sabia que não precisava de um ambiente 100% fechado nem algo que deixasse a câmera travada.

Poderia usar uma um compensado de madeira mais fino e flexível e com uma porta grande para poder passar cabos e afins.

Também usei o periférico da Magwell para validar se a saída HDMI do box também estava de acordo com o que era captado pela câmera.
(http://www.magewell.com/usb-capture-hdmi)

Galeria de Fotos do projeto:

comments powered by Disqus