As máquinas de estados do processamento de alertas e notificações são componentes muito importantes no sistema pois deles depende grande parte do sucesso do projecto. São estes pro- cessos que garantem o objectivo principal do projecto que é fazer chegar a notificação do alerta ao operador responsável ou ao seu substituto, o mais rapidamente possível. Estes processos usam grande parte dos componentes anteriormente testados, mas isso só não basta, tem de ser
testados também os algoritmos que fazem variar os estados das máquinas de estados. Para isso foi necessário encontrar todas as combinações possíveis de variação de estados que possam ocorrer.
Cada variação de estado dentro do processo, equivale a um caminho de teste. Para melhor organizar todos os caminhos possíveis, transformaram-se as máquinas de estados em Control Flow Graph (CFG). O grafo obtido dessa transformação inclui a máquina de estados do pro- cessamento de alertas representado pela Figura 6.11 e a máquina de estados do processamento de notificações representado pela Figura 6.12. Cada estado dessas máquinas deu origem a um nó do CFG. Foram acrescentados alguns nós para que, nos casos em que um estado pode voltar a si próprio, houvesse um nó intermédio que identificasse o motivo dessa alteração de estado. Assim, o CFG obtido está representado na Figura 8.1. Aos nós do grafo, foram atribuídas as seguintes designações de modo a obter uma "história"através de cada caminho de teste:
1. Selecciona operador 2. Sem operador
3. Inicia processo de notificação 4. Selecciona dispositivo 5. Sem dispositivo 6. Notificação expirada 7. Aguarda entrega 8. Não entregue 9. Entregue 10. Aguarda visualização 11. Expirada 12. Aguarda aceitação 13. Declinada 14. Tratamento 15. Conclusão
Recorrendo à aplicação online Graph Coverage Web Application [93] foram gerados cami- nhos de teste baseados em Prime Path Coverage [94]. Este tipo de teste de cobertura consiste em gerar todas as combinações possíveis de caminhos entre o primeiro e último nó, com even- tuais ciclos a serem percorridos, uma vez no máximo, em cada caminho.
Numa primeira abordagem, considerados todos os nós existentes, foram obtidos 52 cami- nhos. Numa segunda abordagem, foram procurados os caminhos impossíveis de percorrer, denominados infeasible sub paths [95] .
Relativamente ao sub-path [4,5,4], a passagem do nó 4 para o 5 ocorre num cenário em que o operador seleccionado não tem dispositivo móvel associado. Isso pode acontecer por dois motivos, nunca fez Login na aplicação móvel ou outro operador fez um Login mais recente num dispositivo anteriormente associado a ele. Como consequência, volta ao nó 4. Neste momento, o sistema está preparado para poder aguardar um pequeno período de tempo para dar
8.4. PROCESSAMENTO DE ALERTAS E NOTIFICAÇÕES
Figura 8.1: Control Flow Graph do processamento de alertas e notificiações.
oportunidade do operador sem dispositivo ser contactado, por meio alternativo, no sentido de ser solicitado a fazer Login na aplicação móvel de modo a ficar com dispositivo associado e, assim, poder receber a notificação que lhe é destinada. Contudo, actualmente, como o mecanismo de contacto alternativo não se encontra implementado (tendo ficado para trabalho futuro), o tempo de espera no nó 4 é nulo, pelo que não existe hipótese do operador sem dispositivo poder recuperar a notificação perdida, que corresponderia à passagem para o nó 7. Por este motivo, o sub-path[4,5,4,7] passa a ser um infeasible sub paths.
No nó 7, o sistema está preparado para aguardar o recibo de entrega da notificação. Como referido na Secção 7.1.10, idealmente, o recibo seria da entrega no dispositivo móvel mas, como a implementação actual não permite essa funcionalidade, o recibo é apenas da entrega no FCM. Ora, como todos os dispositivos móveis que usam a aplicação Cat|Mobile estão registados no FCM (dado que o registo é automático) esta confirmação de entrega é irrelevante e apenas existe para no futuro poder ser implementada como recibdo de entrega no dispositivo. Assim, a eventual falha de entrega, correspondente à passagem para o nó 8, nunca chega a acontecer enquanto os recibos forem de entrega no FCM e não do dispositivo. Por este motivo, o sub-path [7,8,4] é também um infeasible sub paths.
Não tendo sido encontrados mais infeasible sub paths, foi recalculada a Prime Path Cove- rage, desta vez tendo em conta os infeasible sub paths [4,5,4,7] e [7,8,4]. O resultado obtido, de 28 caminhos, pode ser consultado no Apêndice B.
Cada um desses testes corresponde a uma execução do processamento de alerta e notifica- ção. Com a execução destes testes, em modo black-box, está a ser testada a quase totalidade do sistema, desde o registo de operadores passando pelo registo de origem de alertas, registo de turnos e escalonamento, registo de dispositivo através da utilização da aplicação móvel, recep- ção de alertas, emissão de notificações até à resposta a alertas. Através de todas estas tarefas, é testado todo o ciclo de vida de um alerta e funcionalidades acessórias.
O teste número 22 da lista, por exemplo, é composto pela seguinte sequência de nós da Figura 8.1: [1, 2, 1, 2, 1, 3, 4, 7, 9, 10, 12, 14, 15], que corresponde à sequência de nós representado na Tabela 8.1. Neste teste pode-se verificar, por exemplo, que o operador é se- leccionado 3 vezes, correspondendo à selecção final do operador de terceira responsabilidade, testando, assim todo o processo de escalonamento dos operadores.
Tabela 8.1: Sequência de nós do teste 22 de Prime Path Coverage.
Ordem Nó Descrição 1 1 Seleciona operador 2 2 Sem operador 3 1 Seleciona operador 4 2 Sem operador 5 1 Seleciona operador
6 3 Inicia processo de notificação 7 4 Selecciona dispositivo
8 7 Aguarda entrega da notificação
9 9 Entregue
10 10 Aguarda visualização do alerta 11 12 Aguarda aceitação do alerta
12 14 Tratamento
13 15 Conclusão
Com todos os testes transcritos para sequências legíveis de estados, foi possível realizar todos os testes de Prime Path Coverage e assim cobrir todas situações possíveis que possam ocorrer com este sistema, garantindo que o sistema se encontra preparado para entrar em pro- dução com a confiança desejada.
8.5
Conclusão
Neste capítulo foram demonstrados os testes efectuados ao produto final do projecto de acordo com os requisitos iniciais. Com estes testes ficou demonstrada a qualidade obtida com a imple- mentação do projecto e a confiança que se pode esperar da solução.
Capítulo 9
Conclusão
Com este capítulo, dá-se por concluído o Relatório de Estágio, onde o autor tentou usar o espaço que teve disponível para descrever, com algum detalhe, as situações que entendeu terem conteúdo mais relevante, dentro da estrutura de base típica deste tipo de documento.
9.1
Objectivos cumpridos
Na opinião do autor, o estágio foi considerado muito interessante tendo em conta o desafio que lhe foi colocado com a proposta de estágio que esteve na origem do projecto. A complexidade do desafio foi bastante cativante e bastante útil a oportunidade de contactar com tecnologias que lhe eram estranhas e com as quais ficou familiarizado e motivado a poder continuar a usá-las profissionalmente. Continuando com a opinião, o autor entende que o estágio foi concluído com sucesso, os objectivos principais foram atingidos, grande parte das funcionalidades foram implementadas e foram criadas bases sólidas para upgrades futuros. Apesar de, por altura da escrita deste documento, ainda não ter sido usado em ambiente real, prevê-se que, pelos testes realizados, o sistema responda conforme esperado. Alguns detalhes acessórios ficaram por implementar devido ao rígido deadline de conclusão do projecto, contudo, a arquitectura com que foi desenvolvida a solução demonstrou, durante o desenvolvimento, a relativa facilidade com que podem ser adicionadas novas funcionalidades, acrescentando ou modificando lógica às existentes.