A sociedade está cada vez mais dependente de sistemas embarcados, sendo que na grande maioria das vezes eles operam de maneira invisível aos seus usuários. Essa dependência torna esses usuários vulneráveis a riscos, devido às falhas que podem ocorrer. Essas falhas podem provocar perdas de vidas ou sérios danos materiais e financeiros. Devido a estes fatos, a qualidade destes produtos torna-se um ponto essencial para se ter um sistema estável, livre de erros e com todas as suas funcionalidades sendo executadas. De encontro a isso, a etapa de teste apresenta-se como indispensável e de relevada importância para a obtenção de um produto com uma boa qualidade. Devido ao alto custo de produção e energia gasto com testes, surge a necessidade de novos estudos, sobre diversificados métodos, para se testar um sistema embarcado. Neste contexto, este trabalho tem como objetivo apresentar os estudos iniciais do teste de um Sistema Operacional Embarcado (SOE), através de um estudo de caso focado na rotina de tratamento de exceção do eCos (Embedded Configurable Operating System), pois ela apresenta uma forte interação entre software e hardware, sendo que esta interação é um dos principais desafios encontrados no teste de um software embarcado. Com isso, este trabalho pretende dar o passo inicial para pesquisas relacionadas aos testes de um Sistema Operacional Embarcado. Após a análise dos experimentos, pôde-se notar que a principal característica do Sistema Operacional Embarcado eCos, a configurabilidade, é um ponto de dificuldade extra para a realização dos testes, pois exige um estudo detalhado do código do SOE, o qual é totalmente genérico, antes do planejamento dos testes, podendo ser gasto muito tempo nessa atividade. Outro ponto é que o teste torna-se totalmente dependente do hardware. Entretanto, os resultados experimentais apresentados para o estudo de caso do presente trabalho foram satisfatórios. / Society is increasingly dependent on embedded systems, which in most cases operate in an invisible manner to its users. This dependence makes the user vulnerable to risks due to failures that may occur. These failures can cause loss of lives or serious property and financial damage. Because of these facts, the quality of these products becomes a key point to have a stable system, free of errors and with all the features running. This testing is of essential importance to obtain a product with good quality. Due to the high cost of production and energy spent on tests, there is a need for further studies on different methods, to test an embedded system. In this context, this work aims at presenting the initial studies as the testing of the Embedded Operating System. The case study was focused on the exception handling routine of the eCos (Embedded Configurable Operating System), because it has a strong interaction between software and hardware, and this interaction is one of the main challenges encountered in testing embedded software. Therefore, this work aims at taking the first steps towards research related to testing an Embedded Operating System. After analyzing the experiments, it was noted that the main feature of the Embedded Operating System, eCos, the configurability, is an extra point of difficulty for the tests. It requires a detailed study of the code eCos, which is completely general, before the planning of tests, and could be spent much time in this activity. Another point is that the test becomes totally dependent on hardware. However, the experimental results presented for the case study of this study showed satisfactory.

A sociedade está cada vez mais dependente de sistemas embarcados, sendo que na grande maioria das vezes eles operam de maneira invisível aos seus usuários. Essa dependência torna esses usuários vulneráveis a riscos, devido às falhas que podem ocorrer. Essas falhas podem provocar perdas de vidas ou sérios danos materiais e financeiros. Devido a estes fatos, a qualidade destes produtos torna-se um ponto essencial para se ter um sistema estável, livre de erros e com todas as suas funcionalidades sendo executadas. De encontro a isso, a etapa de teste apresenta-se como indispensável e de relevada importância para a obtenção de um produto com uma boa qualidade. Devido ao alto custo de produção e energia gasto com testes, surge a necessidade de novos estudos, sobre diversificados métodos, para se testar um sistema embarcado. Neste contexto, este trabalho tem como objetivo apresentar os estudos iniciais do teste de um Sistema Operacional Embarcado (SOE), através de um estudo de caso focado na rotina de tratamento de exceção do eCos (Embedded Configurable Operating System), pois ela apresenta uma forte interação entre software e hardware, sendo que esta interação é um dos principais desafios encontrados no teste de um software embarcado. Com isso, este trabalho pretende dar o passo inicial para pesquisas relacionadas aos testes de um Sistema Operacional Embarcado. Após a análise dos experimentos, pôde-se notar que a principal característica do Sistema Operacional Embarcado eCos, a configurabilidade, é um ponto de dificuldade extra para a realização dos testes, pois exige um estudo detalhado do código do SOE, o qual é totalmente genérico, antes do planejamento dos testes, podendo ser gasto muito tempo nessa atividade. Outro ponto é que o teste torna-se totalmente dependente do hardware. Entretanto, os resultados experimentais apresentados para o estudo de caso do presente trabalho foram satisfatórios. / Society is increasingly dependent on embedded systems, which in most cases operate in an invisible manner to its users. This dependence makes the user vulnerable to risks due to failures that may occur. These failures can cause loss of lives or serious property and financial damage. Because of these facts, the quality of these products becomes a key point to have a stable system, free of errors and with all the features running. This testing is of essential importance to obtain a product with good quality. Due to the high cost of production and energy spent on tests, there is a need for further studies on different methods, to test an embedded system. In this context, this work aims at presenting the initial studies as the testing of the Embedded Operating System. The case study was focused on the exception handling routine of the eCos (Embedded Configurable Operating System), because it has a strong interaction between software and hardware, and this interaction is one of the main challenges encountered in testing embedded software. Therefore, this work aims at taking the first steps towards research related to testing an Embedded Operating System. After analyzing the experiments, it was noted that the main feature of the Embedded Operating System, eCos, the configurability, is an extra point of difficulty for the tests. It requires a detailed study of the code eCos, which is completely general, before the planning of tests, and could be spent much time in this activity. Another point is that the test becomes totally dependent on hardware. However, the experimental results presented for the case study of this study showed satisfactory.

A sociedade está cada vez mais dependente de sistemas embarcados, sendo que na grande maioria das vezes eles operam de maneira invisível aos seus usuários. Essa dependência torna esses usuários vulneráveis a riscos, devido às falhas que podem ocorrer. Essas falhas podem provocar perdas de vidas ou sérios danos materiais e financeiros. Devido a estes fatos, a qualidade destes produtos torna-se um ponto essencial para se ter um sistema estável, livre de erros e com todas as suas funcionalidades sendo executadas. De encontro a isso, a etapa de teste apresenta-se como indispensável e de relevada importância para a obtenção de um produto com uma boa qualidade. Devido ao alto custo de produção e energia gasto com testes, surge a necessidade de novos estudos, sobre diversificados métodos, para se testar um sistema embarcado. Neste contexto, este trabalho tem como objetivo apresentar os estudos iniciais do teste de um Sistema Operacional Embarcado (SOE), através de um estudo de caso focado na rotina de tratamento de exceção do eCos (Embedded Configurable Operating System), pois ela apresenta uma forte interação entre software e hardware, sendo que esta interação é um dos principais desafios encontrados no teste de um software embarcado. Com isso, este trabalho pretende dar o passo inicial para pesquisas relacionadas aos testes de um Sistema Operacional Embarcado. Após a análise dos experimentos, pôde-se notar que a principal característica do Sistema Operacional Embarcado eCos, a configurabilidade, é um ponto de dificuldade extra para a realização dos testes, pois exige um estudo detalhado do código do SOE, o qual é totalmente genérico, antes do planejamento dos testes, podendo ser gasto muito tempo nessa atividade. Outro ponto é que o teste torna-se totalmente dependente do hardware. Entretanto, os resultados experimentais apresentados para o estudo de caso do presente trabalho foram satisfatórios. / Society is increasingly dependent on embedded systems, which in most cases operate in an invisible manner to its users. This dependence makes the user vulnerable to risks due to failures that may occur. These failures can cause loss of lives or serious property and financial damage. Because of these facts, the quality of these products becomes a key point to have a stable system, free of errors and with all the features running. This testing is of essential importance to obtain a product with good quality. Due to the high cost of production and energy spent on tests, there is a need for further studies on different methods, to test an embedded system. In this context, this work aims at presenting the initial studies as the testing of the Embedded Operating System. The case study was focused on the exception handling routine of the eCos (Embedded Configurable Operating System), because it has a strong interaction between software and hardware, and this interaction is one of the main challenges encountered in testing embedded software. Therefore, this work aims at taking the first steps towards research related to testing an Embedded Operating System. After analyzing the experiments, it was noted that the main feature of the Embedded Operating System, eCos, the configurability, is an extra point of difficulty for the tests. It requires a detailed study of the code eCos, which is completely general, before the planning of tests, and could be spent much time in this activity. Another point is that the test becomes totally dependent on hardware. However, the experimental results presented for the case study of this study showed satisfactory.

Os aplicativos móveis, desenvolvidos originalmente para a área do entretenimento, hoje estão presentes nos mais diversos domínios, sendo comuns inclusive em áreas de alto valor agregado, como: varejista, logística, bancária, médica, entre outras. Portanto, a qualidade e correção dos aplicativos móveis tornam-se obrigatórios e as atividades de teste essenciais. Porém a qualidade das aplicações móveis nem sempre é satisfatória. Isso ocorre devido ao fato dessas aplicações sofrerem com a pressão do mercado e passarem por um processo muito rápido de desenvolvimento, onde geralmente a fase de testes é negligenciada ou realizada de forma superficial, pela própria equipe de desenvolvimento, comprometendo assim a qualidade da aplicação. Este trabalho propõe uma abordagem baseada no Behavior Driven Development para ajudar na definição de testes de sistema para aplicativos nativos do Android. A abordagem proposta utiliza os arquivos de leiaute da aplicação para extrair informações sobre os componentes da interface e sobre os eventos esperados pelo sistema. A partir dessas informações, é possível verificar a cobertura dos cenários existentes em relação aos eventos disponíveis na interface com o usuário. Além disso, é possível identificar elementos do leiaute que não são exercitados pelos cenários existentes. A abordagem proposta é implementada por uma ferramenta chamada Android Behavior Testing Tool que, por meio da interpretação dos cenários do Behavior Driven Development, fornece uma visão geral do fluxo comportamental da aplicação ao testador (visão hoje não disponível), proporcionando assim uma noção de fácil compreensão sobre a cobertura dos testes em relação aos elementos da interface do aplicativo. Desta forma, o testador pode julgar a integridade dos casos de teste disponíveis em relação às funcionalidades implementadas e, se necessário, implementar novos testes. A ferramenta também faz uso dos arquivos de leiaute do aplicativo para identificar os componentes da interface que não foram testados e gera, neste caso, modelos de cenários no formato do BDD, automatizando assim a tarefa de escrita dos mesmos. A abordagem proposta foi utilizada em quatro aplicativos Android e se mostrou útil, uma vez que, em três estudos de caso foram detectados bugs oriundos de inconsistências lógicas nos cenários ou elementos não exercitados pelos cenários. / Mobile applications, originally developed for entertainment, nowadays are present in a wide range of domains, being common even in areas of high value such as retailer, logistics, banking, and medical, among others. However, the quality and correctness of mobile applications become mandatory and testing activities are essential. However, the quality of mobile applications is not always good enough. This is because these applications suffer from market pressure and pass through a very rapid development process where the testing phase usually is neglected or superficially performed by the development team itself, thus compromising the quality of the application. This work proposes an approach based on Behavior Driven Development to help to define system tests for native Android applications. The proposed approach uses the application's layout files to extract information about the interface components and the events expected by the system. From this information, it is possible to check out the coverage of existing test scenarios against events available in the user interface. In addition, it is possible to identify unexercised usage scenarios from the existing test scenarios. The proposed approach is implemented by a tool called Android Behavior Testing Tool which, through the interpretation of the BDD usage scenarios, provides to the tester an overview of the behavioral flow of the application (otherwise unavailable), thus providing a notion of easy understanding of test coverage in relation to the application interface elements. In this way, the tester can judge the integrity of the available test cases in relation to the functionalities implemented and, if necessary, implement new tests. The tool also makes use of the application's layout files to identify untested interface components and in this case generates test scenario models in the BDD format, thus automating the writing task of the scenarios. The proposed approach was used in four Android applications and proved to be useful, since in three case studies bugs were detected. Detected bugs originated from logical inconsistencies in the test scenarios or elements that were not exercised by the scenarios.

Os aplicativos móveis, desenvolvidos originalmente para a área do entretenimento, hoje estão presentes nos mais diversos domínios, sendo comuns inclusive em áreas de alto valor agregado, como: varejista, logística, bancária, médica, entre outras. Portanto, a qualidade e correção dos aplicativos móveis tornam-se obrigatórios e as atividades de teste essenciais. Porém a qualidade das aplicações móveis nem sempre é satisfatória. Isso ocorre devido ao fato dessas aplicações sofrerem com a pressão do mercado e passarem por um processo muito rápido de desenvolvimento, onde geralmente a fase de testes é negligenciada ou realizada de forma superficial, pela própria equipe de desenvolvimento, comprometendo assim a qualidade da aplicação. Este trabalho propõe uma abordagem baseada no Behavior Driven Development para ajudar na definição de testes de sistema para aplicativos nativos do Android. A abordagem proposta utiliza os arquivos de leiaute da aplicação para extrair informações sobre os componentes da interface e sobre os eventos esperados pelo sistema. A partir dessas informações, é possível verificar a cobertura dos cenários existentes em relação aos eventos disponíveis na interface com o usuário. Além disso, é possível identificar elementos do leiaute que não são exercitados pelos cenários existentes. A abordagem proposta é implementada por uma ferramenta chamada Android Behavior Testing Tool que, por meio da interpretação dos cenários do Behavior Driven Development, fornece uma visão geral do fluxo comportamental da aplicação ao testador (visão hoje não disponível), proporcionando assim uma noção de fácil compreensão sobre a cobertura dos testes em relação aos elementos da interface do aplicativo. Desta forma, o testador pode julgar a integridade dos casos de teste disponíveis em relação às funcionalidades implementadas e, se necessário, implementar novos testes. A ferramenta também faz uso dos arquivos de leiaute do aplicativo para identificar os componentes da interface que não foram testados e gera, neste caso, modelos de cenários no formato do BDD, automatizando assim a tarefa de escrita dos mesmos. A abordagem proposta foi utilizada em quatro aplicativos Android e se mostrou útil, uma vez que, em três estudos de caso foram detectados bugs oriundos de inconsistências lógicas nos cenários ou elementos não exercitados pelos cenários. / Mobile applications, originally developed for entertainment, nowadays are present in a wide range of domains, being common even in areas of high value such as retailer, logistics, banking, and medical, among others. However, the quality and correctness of mobile applications become mandatory and testing activities are essential. However, the quality of mobile applications is not always good enough. This is because these applications suffer from market pressure and pass through a very rapid development process where the testing phase usually is neglected or superficially performed by the development team itself, thus compromising the quality of the application. This work proposes an approach based on Behavior Driven Development to help to define system tests for native Android applications. The proposed approach uses the application's layout files to extract information about the interface components and the events expected by the system. From this information, it is possible to check out the coverage of existing test scenarios against events available in the user interface. In addition, it is possible to identify unexercised usage scenarios from the existing test scenarios. The proposed approach is implemented by a tool called Android Behavior Testing Tool which, through the interpretation of the BDD usage scenarios, provides to the tester an overview of the behavioral flow of the application (otherwise unavailable), thus providing a notion of easy understanding of test coverage in relation to the application interface elements. In this way, the tester can judge the integrity of the available test cases in relation to the functionalities implemented and, if necessary, implement new tests. The tool also makes use of the application's layout files to identify untested interface components and in this case generates test scenario models in the BDD format, thus automating the writing task of the scenarios. The proposed approach was used in four Android applications and proved to be useful, since in three case studies bugs were detected. Detected bugs originated from logical inconsistencies in the test scenarios or elements that were not exercised by the scenarios.

Os aplicativos móveis, desenvolvidos originalmente para a área do entretenimento, hoje estão presentes nos mais diversos domínios, sendo comuns inclusive em áreas de alto valor agregado, como: varejista, logística, bancária, médica, entre outras. Portanto, a qualidade e correção dos aplicativos móveis tornam-se obrigatórios e as atividades de teste essenciais. Porém a qualidade das aplicações móveis nem sempre é satisfatória. Isso ocorre devido ao fato dessas aplicações sofrerem com a pressão do mercado e passarem por um processo muito rápido de desenvolvimento, onde geralmente a fase de testes é negligenciada ou realizada de forma superficial, pela própria equipe de desenvolvimento, comprometendo assim a qualidade da aplicação. Este trabalho propõe uma abordagem baseada no Behavior Driven Development para ajudar na definição de testes de sistema para aplicativos nativos do Android. A abordagem proposta utiliza os arquivos de leiaute da aplicação para extrair informações sobre os componentes da interface e sobre os eventos esperados pelo sistema. A partir dessas informações, é possível verificar a cobertura dos cenários existentes em relação aos eventos disponíveis na interface com o usuário. Além disso, é possível identificar elementos do leiaute que não são exercitados pelos cenários existentes. A abordagem proposta é implementada por uma ferramenta chamada Android Behavior Testing Tool que, por meio da interpretação dos cenários do Behavior Driven Development, fornece uma visão geral do fluxo comportamental da aplicação ao testador (visão hoje não disponível), proporcionando assim uma noção de fácil compreensão sobre a cobertura dos testes em relação aos elementos da interface do aplicativo. Desta forma, o testador pode julgar a integridade dos casos de teste disponíveis em relação às funcionalidades implementadas e, se necessário, implementar novos testes. A ferramenta também faz uso dos arquivos de leiaute do aplicativo para identificar os componentes da interface que não foram testados e gera, neste caso, modelos de cenários no formato do BDD, automatizando assim a tarefa de escrita dos mesmos. A abordagem proposta foi utilizada em quatro aplicativos Android e se mostrou útil, uma vez que, em três estudos de caso foram detectados bugs oriundos de inconsistências lógicas nos cenários ou elementos não exercitados pelos cenários. / Mobile applications, originally developed for entertainment, nowadays are present in a wide range of domains, being common even in areas of high value such as retailer, logistics, banking, and medical, among others. However, the quality and correctness of mobile applications become mandatory and testing activities are essential. However, the quality of mobile applications is not always good enough. This is because these applications suffer from market pressure and pass through a very rapid development process where the testing phase usually is neglected or superficially performed by the development team itself, thus compromising the quality of the application. This work proposes an approach based on Behavior Driven Development to help to define system tests for native Android applications. The proposed approach uses the application's layout files to extract information about the interface components and the events expected by the system. From this information, it is possible to check out the coverage of existing test scenarios against events available in the user interface. In addition, it is possible to identify unexercised usage scenarios from the existing test scenarios. The proposed approach is implemented by a tool called Android Behavior Testing Tool which, through the interpretation of the BDD usage scenarios, provides to the tester an overview of the behavioral flow of the application (otherwise unavailable), thus providing a notion of easy understanding of test coverage in relation to the application interface elements. In this way, the tester can judge the integrity of the available test cases in relation to the functionalities implemented and, if necessary, implement new tests. The tool also makes use of the application's layout files to identify untested interface components and in this case generates test scenario models in the BDD format, thus automating the writing task of the scenarios. The proposed approach was used in four Android applications and proved to be useful, since in three case studies bugs were detected. Detected bugs originated from logical inconsistencies in the test scenarios or elements that were not exercised by the scenarios.

The system test is very significant in the development life cycle of a telecommunication network node. Tools such as TITANSim are used to develop the test framework upon which a load test application is created. These tools need to be highly efficient and optimized to reduce the cost of the system test. This thesis project created a load test application based on the distributed scheduling architecture of TITANSim, whereby multiple users can be simulated using a single test component. This new distributed scheduling system greatly reduces the number of operating system processes involved, thus reducing the memory consumption of the load test application; hence higher loads can be easily simulated with limited hardware resources. The load test application used for system test of the HSS is based on the central scheduling architecture of TITANSim. The central scheduling architecture is a function test concept, where every user is simulated by a single test component. In the system test several thousand users are simulated by the test system. Therefore, the load application based on central scheduling architecture uses thousands of test components leading to high memory consumption in the test system. In this architecture, the scheduling of test components is centralized which results in a lot of communication overhead within the test system, as thousands of test components communicate with a master scheduling component during the test execution. On the other hand, in the distributed scheduling architecture the scheduling task is performed locally by each test component. There is no communication overhead within the test system. Therefore, the test system is highly efficient. In the distributed scheduling architecture the traffic flow of the simulated users are described using the Finite State Machines (FSMs). The FSMs are specified in the configuration files that are used by the test system at run time. Therefore, implementing traffic cases using the distributed scheduling architecture becomes simpler and faster as there is no (TTCN-3) coding/compilation. The HSS is the only node (within Ericsson) whose system test is performed using the central scheduling architecture of TITANSim. The other users (nodes) of TITANSim are using the distributed scheduling architecture for its apparent benefits. Under this circumstance, this thesis project assumes significance for the HSS. When a decision to adapt the distributed scheduling architecture is made for the system test of the HSS, the load application created in this thesis project can be used as a model, or extended for the migration of the test modules for the HSS from the central scheduling architecture to the distributed scheduling architecture. By creating this load application we have gained significant knowledge of the TITANSim framework; most importantly, the necessary modifications to the TITANSim framework required to create a distributed scheduling architecture based load application for the HSS. The load application created for this project was used to (system) test the HSS by generating load using real system test hardware. The results were analytically compared with the test results from the existing load application (which is based on the central scheduling architecture). The analysis showed that the load application based on distributed scheduling architecture is efficient, utilizes less test system resources, and capable of scaling up the load generation capacity / Systemet test är mycket betydelsefullt i utvecklingen livscykeln för ett telenät nod.Verktyg som TITANSim används för att utveckla testet ram på vilken ett belastningsprov program skapas. Dessa verktyg måste vara mycket effektiv och optimerad för att minska kostnaderna för systemet testet. Detta examensarbete skapat ett program belastningsprov bygger på distribuerad schemaläggning arkitektur TITANSim, där flera användare kan simuleras med hjälp av ett enda test komponent. Det nya distribuerade schemaläggning systemet minskar kraftigt antalet operativsystem inblandade system processer, vilket minskar minnesförbrukning av lasten testprogram, därav högre belastningar kan enkelt simuleras med begränsade hårdvara resurser. Lasten testa program som används för systemtest av HSS är baserad på den centrala schemaläggning arkitektur TITANSim. Den centrala schemaläggning arkitektur är ett funktionstest koncept, där varje användare simuleras med ett enda test komponent. I systemet testa flera tusen användare är simulerade av testsystemet.Därför använder belastningen program baserat på centrala schemaläggning arkitektur tusentals testa komponenter leder till hög minnesförbrukning i testsystemet.I denna arkitektur är schemaläggning av test komponenter centraliserad vilket resulterar i en mycket kommunikation overhead inom testsystem, som tusentals testa komponenter kommunicerar med en mästare schemaläggning komponent under testexekvering. Å andra sidan, i den distribuerade schemaläggning arkitekturen schemaläggning uppgiften utförs lokalt av varje test komponent. Det finns ingen kommunikation overhead i testsystemet. Därför är testsystemet mycket effektiv. I distribuerad schemaläggning arkitekturen trafikflödet av simulerade användare beskrivs med Finite State Machines (FSMs). Den FSMs anges i konfigurationsfiler som används av testsystemet vid körning. Därför genomföra trafiken fall med distribuerad schemaläggning arkitektur blir enklare och snabbare eftersom det inte finns någon (TTCN-3) kodning / sammanställning. HSS är den enda nod (inom Ericsson) vars system test utförs med hjälp av den centrala schemaläggningen arkitektur TITANSim. Den andra användare (noder) i TITANSim använder distribuerad schemaläggning arkitektur för sina uppenbara fördelar. Under denna omständighet, förutsätter detta examensarbete betydelse för HSS. När ett beslut att anpassa distribuerad schemaläggning arkitektur är gjord för systemet test av HSS, kan belastningen program som skapats i detta examensarbete kan användas som en modell, eller förlängas för migration av testet moduler för HSS från den centrala schemaläggningen arkitektur för distribuerade schemaläggning arkitektur. Genom att skapa denna belastning ansökan har vi fått stor kunskap om TITANSim ramen, viktigast av allt, de nödvändiga ändringar av TITANSim ramverk som krävs för att skapa en distribuerad schemaläggning arkitektur baserad belastning ansökan för HSS. Lasten program som skapats för detta projekt har använts för att (system) testa HSS genom att generera last använda riktiga maskinvarusystem test. Resultaten analytiskt jämfört med provresultaten från den befintliga belastningen ansökan (som är baserad på den centrala schemaläggning arkitektur). Analysen visade att belastningen ansökan baseras på distribuerad schemaläggning arkitektur är effektiv, använder mindre resurser testsystem, och kan skala upp kapaciteten last generation

Ziel der Arbeit war es, die Systemtestautomatisierung zu vereinfachen. Gerade in Hinblick auf Stabilität und Wiederverwendbarkeit konnten die in der Praxis eingesetzten Möglichkeiten nicht vollständig überzeugen. Der in der Abhandlung erarbeitet Zielzustand, die „strukturierte Automatisierung des SystemTests“ (SAST) integriert den Systemtest in „MOdel Compiler for generating Complete Applications“ (MOCCA), ein modelgetriebenes Anwendungsgenerierungsframework. MOCCA generiert aus Struktur- und Verhaltensmodellen voll-ständige Softwaresysteme. Er wurde an der TU Bergakademie Freiberg entwickelt. Zur leichtgewichtigen Modellierung des Anwendungsverhaltens wurde es durch die Dissertation von Dr. Liang (vgl. [Lian2013]) u. a. um eine Action Language eXtended Object Constraint Language (XOCL) erweitert. Diese Verhaltensbeschreibungsmöglichkeit wurde in SAST ebenso für die Verhaltensabbildung des Systemtests genutzt und bildet einen Pfeiler in dem erstellten Prototyp zur Systemtestgenerierung. SAST bezieht sich auf GUI-basierte Softwaresysteme. Sie bildet, wie es für den Systemtest charakteristisch ist, Fachprozesse anhand der Oberfläche ab. Zur Lösung wurden, neben dem Testverhalten, Artefakte zur Teststrukturierung, Schlüsselwortbildung und eine Ausführungs-Engine erstellt und in den bestehenden Generierungspro-zess von MOCCA eingefügt. Mit den grundlegenden Charakteristika der Lösung – modellgetrieben, schlüssel-wort-orientiert und in Testfällen strukturiert – unterstützt die Arbeit die angestrebten Verbesserungen: Wiederverwendbarkeit, Wartungsarmut und frühzeitige Testfallentwicklung. Eine Ausgestaltung für konkrete Testfälle ermöglicht schnelle Testschwerpunkte und -reduzierungen im Rahmen des risikobasierten Tests.:1 Einleitung 2 Theoretisches Fundament 3 Analyse bekannter Methoden für den Systemtest 4 Strukturierte Automatisierung des SystemTests 5 Prototypische Systemtestmodellierung 6 Proof of Concept: Anwendung ,TranscriptGenerator' 7 Abschließende Bewertung und weitere Möglichkeiten

The diploma thesis is focused on testing and design of a test system of merging unit which provides digital output according to IEC 61850-9-2. The parameters and distinguishing features of the test system are based on functional principles of merging unit and standards dealing with the testing of transducers. The proposed test system is based on modular PXI Express system from National Instruments. The desing is performed with respect to the possibility of generating test signals and measurements for voltage up to 38.4 kV and current up to 2000 A. The proposed test system meets the criteria for testing transducers of accuracy class up to 0.5. Assuming of calibration designed test system as a whole, this test setup has the potential to meet the technical requirements for testing transducers of accuracy class up to 0.1.

根據AMR Research的預估，全球的客戶關係管理(Customer Relationship Management，CRM)市場規模，從1998年23憶美元，預估西元2003年將達到168憶美元。以及由2002年底Siebel推出的解決方案來看，CRM的趨勢將針對各種應用系統如何做好整合。 本研究之目的，旨在整合現有客戶關係管理相關文獻，與日商B公司多年來的經驗，以流程再造為出發點，從而設計出新的客戶管理資訊系統中之「銷售」、「行銷」以及「客戶服務」等機制，以解決舊系統不敷使用的問題，並且提供新商品線銷售與服務的機制，以及整合部份內外部系統。研究過程中實踐了系統開發生命週期(System Development Lifecycle)的理論進行新系統之分析、設計、開發、測試，並進一步分析與探討新系統實際上為B公司帶來的效益。以期對於國內企業因應快速發展的CRM趨勢，本系統的實現提供了國內其它產業進行CRM資訊系統建置過程的參考價值。 / According to the prediction of AMR research, the marketing scale of global Customer Relationship Management will be expected to rise from 2.3 billions in 1998 to 16.8 billions in 2003. Viewing the CRM solution of Siebel in the end of 2002, the trend of CRM will focus on how to integrate other hundreds of applications. The objective of this study is to integrate the related references of present CRM and the publisher industry experiences within a Japanese company B. On the basis of Business Process Reengineering (BPR) theory, we design the Sales, marketing, and customer services in the new CRM system in order to solve the problems on the legacy system, to provide the new sale channels and services mechanism of new product line and to integrate parts of the inner and 3rd party information system. During the research process, we accomplished the theorem of System Development Lifecycle to analyze, design, develop, and test of the new system. And further analyze and discuss of the benefit to company B from the the new system. In order to match the trend of the rapid growth in the CRM market for local enterprises, this system supplied the referenced value during building the CRM information system for other local enterprises. / 目 錄 摘要……..………………………………………………………… I 目錄………….…………………………………………………… II 表目錄……………………………………………………………. IV 圖目錄………………….………………………………………… V 第一章 緒論………………….…………………………………... 1 1.1. 研究背景與動機……….……………………………… 1 1.2. 研究目的與範圍………………………………………. 3 1.3. 研究方法與論文結構………………………………….. 4 第二章 文獻探討…………………………………………………6 2.1顧客關係管理系統………………………………………..……6 2.2企業資訊系統整合………………………………….…..…..…10 2.3企業策略委外…………………………………………….……12 2.4企業流程再造…………………………………………….........13 第三章 案例背景與解決方案………………………………..….15 3.1案例背景分析…………………………………………………16 3.1.1 舊系統功能……………………………………….…...17 3.1.2 舊系統業務流程………………………………………25 3.1.3 舊系統流程分析………………………………………27 3.2 解決方案……………………………………………………...29 3.2.1 新系統流程分析………………………………………30 3.2.2 新系統功能設計重點…………………………………31 3.2.3 預期效益………………………………………………33 3.3 技術需求分析………………………………………………...34 3.3.1 系統分析與設計方法…………………………………34 3.3.2 技術選用………………………………………………41 第四章 系統架構…………………………………..…………….44 4.1系統分析………………………………………………..……..44 4.1.1 業務流程圖……………………………………………45 4.1.2 Data Modeling………………………………………….50 4.2 系統設計……………………………………………………...57 4.2.1平行設計……………………………………………….58 4.2.2 MVC設計概念………………………………………...59 4.2.3 系統雛形……………………………………………....62 4.2.4其他系統整合介面…………………………………….68 4.2.5系統架構圖…………………………………………….69 4.3 系統開發………………………………………………….…..71 4.3.1 Web功能模組……………………………………….....72 4.3.2 批次模組………………………………………………74 4.4 系統測試……………………………………………………...76 4.4.1系統整合測試………………………………………….77 4.4.2使用者接受度測試…………………………………….81 4.5 系統上線……………………………………………………...82 4.5.1教育訓練……………………………………………….82 4.5.2上線計畫……………………………………………….82 4.6 系統開發相關技術…………………………………………...86 4.7 效益評估……………………………………………………...91 第五章 結論與後續研究方向…………………………………..98 5.1 結論…………………………………………………………..98 5.2後續研究方向…………………………….…………………..99 參考文獻………………………………….………………….101 表目錄 表2-1 四大巨人CRM解決方案的銷售與趨勢分析表…………………………...8 表3-1 銷售系統功能簡述………………………………………………………….17 表3-2訂戶資料管理功能簡述……………………………………………………..19 表3-3 契約(訂單)管理功能簡述…………………………………………………...20 表3-4 債權管理功能簡述………………………………………………………….22 表3-5催款管理功能簡述…………………………………………………………..22 表3-6發貨管理功能簡述…………………………………………………………..23 表3-7舊系統功能分析……………………………………………………………..24 表3-8新系統解決方案重點………………………………………………………..29 表3-9新系統各部門人員動作概要說明…………………………………………..30 表3-10流程分析策略分析表………………………………………………………36 表3-11軟體生命週期模式比較表…………………………………………………38 表 3-12 系統建構模式與軟體品質評析表………………………………………..42 表3-13 J2EE與 .Net比較表……………………………………………………….43 表4-1 Table Schema 範例…………………………………………………………..52 表 4-2 系統測試分類表……………………………………………………………76 表4-3 Unit Test測試案例…………………………………………………………...79 表4-4 SIT測試案例………………………………………………………………...80 表4-5 上線計畫表執行細項……………………………………………………….84 圖目錄 圖1-1研究方法……………………………………………………………………….5 圖3-1舊系統功能架構圖一(依子系統) ……………………………………………18 圖3-2舊系統功能架構圖二(依部門) ………………………………………………18 圖3-3 舊系統訂購/出貨流程……………………………………………………….26 圖3-4 新系統訂購/出貨流程圖…………………………………………………….31 圖3-5 ERD範例……………………………………………………………………..35 圖3-6 應用系統平行開發的方……………………………………………………..40 圖3-7 系統雛形設計流程圖………………………………………………………..41 圖4-1 B公司整體業務流程圖………………………………………………………45 圖4-2 客戶註冊/訂購流程………………………………………………………….46 圖4-3個人資料變更流程……………………………………………………………46 圖4-4 訂單內容變更………………………………………………………………..47 圖4-5 信用卡入金流程……………………………………………………………..47 圖4-6 退款流程……………………………………………………………………..48 圖4-7 客戶服務……………………………………………………………………..48 圖4-8 物流再發送流程……………………………………………………………..49 圖4-9 名條列印與線上分析報表流程……………………………………………..49 圖4-10 Conceptual Data Model (E-R with Entity) ………………………………….51 圖4-11 Conceptual Data Model Sample(E-R with attributes)……………………….52 圖4-12 亞洲共通版系統設計概念圖………………………………………………58 圖4-13 各子系統功能概要圖……………………………………………………....59 圖4-14 i18n的技術應用範例……………………………………………………….60 圖4-15第一層級Prototype範例(訂單) ……………………………………………63 圖4-16第二層級Prototype範例(訂單) …………………………………………..64 圖4.17第三層級Prototype範例(訂單) …………………………………………..65 圖4-18新系統架構圖……………………………………………………………..69 圖4-19系統硬體部署圖…………………………………………………………..70 圖4-20 JDBC Connection Pooling Module………………………………………..88