Automation of functional tests using JMeter (in Polish)Tieto Corporation
Presentation from a webinar dedicated to a user who don't have previous experience with automation of web applications tests using JMeter tool. At this virtual meet up you will get basic theoretical knowledge about automation test and some practical examples of using JMeter tool.
The webinar on YouTube: http://youtu.be/3_o3IOJEcxw
Tomasz Stupak is Senior Test Engineer working for 5 years in Tieto. During his profession career he has experience with software and hardware testing.
Dobry system musi być przetestowany pod względem wydajnościowym. Takie testy są zupełnie inne niż testy funkcjonalne: zamiast binarnego rezultatu (pass, fail), mamy ogromne ilości danych do zebrania, zaprezentowania i zinterpretowania. Podczas wystąpienie prelegent omówi cały cykl testów wydajnościowych: od przygotowania warunków testu, środowisk i danych testowych, poprzez przeprowadzenie testów, zebranie danych, ich prezentację i interpretacje, aż po przeprowadzenie procesów decyzyjnych wynikających z danych.
JDD 2016 - Wojciech Oczkowski - Testowanie Wydajnosci Za Pomoca Narzedzia JMHPROIDEA
W prezentacji pokażę jak wykorzystać narzędzie JMH do budowy microbenchmarków testujących wydajność zadanych kawałków kodu. Nabyte umiejętności pozwolą słuchaczom sprawdzić wydajność wybranych fragmentów kodu bez niebezpieczeństwa popełnienia, typowych dla tego typu testowania, błędów związanych z np. wygrzewaniem maszyny wirtualnej czy działalnością garbage collectora.
Apache JMeter™ to otwarte oprogramowanie, napisane w Javie i dedykowane do wykonywania testów obciążeniowych, wydajnościowych oraz funkcjonalnych. Oryginalnie było projektowane i rozwijane przez Stefano Mazzocchi z Apache Software Foundation, który napisał go do testowania wydajności Apache JServ (projektu, który został zastąpiony przez Apache Tomcat). Następnie JMeter został przeprojektowany i wyposażony w GUI celem rozszerzenia jego zastosowań do testów funkcjonalnych. W listopadzie 2011 roku JMeter stał się projektem Apache najwyższego poziomu (ang. top level), co oznacza, że zyskał społeczność odpowiedzialną za jego rozwój (ang. Project Management Commitee) oraz dedykowany serwis.
Apache JMeter jest używany do testowania wydajności statycznych oraz dynamicznych zasobów takich jak pliki, dynamiczne języki programowania serwisów internetowych, np. PHP, Java, ASP.NET, itp., obiekty Java, bazy danych i kwerendy, serwery FTP, itp. Z powodzeniem jest wykorzystywany do symulowania wzmożonego ruchu na serwerze, grupie serwerów, w sieci lub na „hartowanym” obiekcie. Służy również do analizowania całkowitej wydajności pod obciążeniem różnego typu, np. do graficznej analizy całkowitej wydajności lub do testowania zachowania się serwera / skryptu / obiektu przy wzmożonym i zrównoleglonym obciążeniu.
Apache JMeter™ to otwarte oprogramowanie, napisane w Javie i dedykowane do wykonywania testów obciążeniowych, wydajnościowych oraz funkcjonalnych. Oryginalnie było projektowane i rozwijane przez Stefano Mazzocchi z Apache Software Foundation, który napisał go do testowania wydajności Apache JServ (projektu, który został zastąpiony przez Apache Tomcat). Następnie JMeter został przeprojektowany i wyposażony w GUI celem rozszerzenia jego zastosowań do testów funkcjonalnych. W listopadzie 2011 roku JMeter stał się projektem Apache najwyższego poziomu (ang. top level), co oznacza, że zyskał społeczność odpowiedzialną za jego rozwój (ang. Project Management Commitee) oraz dedykowany serwis.
Apache JMeter jest używany do testowania wydajności statycznych oraz dynamicznych zasobów takich jak pliki, dynamiczne języki programowania serwisów internetowych, np. PHP, Java, ASP.NET, itp., obiekty Java, bazy danych i kwerendy, serwery FTP, itp. Z powodzeniem jest wykorzystywany do symulowania wzmożonego ruchu na serwerze, grupie serwerów, w sieci lub na „hartowanym” obiekcie. Służy również do analizowania całkowitej wydajności pod obciążeniem różnego typu, np. do graficznej analizy całkowitej wydajności lub do testowania zachowania się serwera / skryptu / obiektu przy wzmożonym i zrównoleglonym obciążeniu.
Na rynku mamy kilka/kilkanaście narzędzi to testów wydajnościowych. Jedne są lepsze inne tańsze. Niestety nawet te z górnej półki czasami zawodzą, i trzeba się posiłkować innymi rozwiązaniami.
W swojej prezentacji pokażę cztery problemy z testami wydajnościowymi – których nie daje się rozwiązać za pomącą HP LoadRunnera, a w których pomogły narzędzia darmowe:
Dlaczego nagrany skrypt, przy oddawaniu, generuje błędy – i jak go poprawić.
Jak znaleźć to, co się nie nagrało – i ewentualnie dodać do skryptu?
Dlaczego logowanie trwa tak długo?
Jak bez wyciągania ciężkich dział sprawdzić co jest wąskim gardłem.
Narzędzia które chciałbym krótko omówić to:
WinMerge,
Notepad++,
Filddler,
PerfMon
Automation of functional tests using JMeter Part II (in Polish)Tieto Corporation
Theoretical knowledge and practical examples about using more complicated functionalities of JMeter tool.
Presentation in Polish from a webinar that is dedicated to persons which have participated in our first training and have some previous experience with automation of web applications tests using JMeter tool.
http://www.slideshare.net/TietoCorporation/automation-of-functional-tests-using-j-meter-tool
Tomasz Stupak is Senior Test Engineer working for 5 years in Tieto. During his profession career he has experience with software and hardware testing.
Preface to a Strategic Plan for Data Science at the NIHPhilip Bourne
Summarizes the Associate Director for Data Science (ADDS) team's thinking on the strategy to use to positively impact how the NIH thinks about data science
This document discusses testing for Internet of Things (IoT) devices. It describes the challenges of testing IoT hardware, firmware, software and cloud integration. It proposes building a modular, scalable and reliable end-to-end automated testing environment to test IoT devices and scenarios. Example test cases are provided to demonstrate turning lights on and off from a mobile app and wireless switch. Vision system and test automation approaches are also summarized.
This document outlines a data science project focused on deriving insights from the website dsruption.com. The goals are to analyze article popularity on social media and automatically generate tags for articles. Technologies used include MongoDB, JavaScript, Node.js, D3.js, Hadoop, Python, and APIs from Facebook and Twitter. The project involves importing social media data, visualizing it with D3.js, identifying tags for companies from article text using Hadoop and MongoDB, and filtering noisy words from articles. Sentiment analysis and integrating additional datasets are proposed for future work.
Stickies on the wall will not help you if you are building crappy softwareWiktor Żołnowski
This document discusses how agile practices like stickies on a wall will not help if an organization has underlying issues like building poor quality software, lack of trust among employees, or basic communication problems. It emphasizes that good organizations choose practices that fit their needs and that true agility is about dividing large products into independent subproducts that can be developed and managed separately. Scaling agile is about decomposition, not just scaling individual methods. Having an agile mindset and understanding what agile means is more important than any single practice.
Automation of functional tests using JMeter (in Polish)Tieto Corporation
Presentation from a webinar dedicated to a user who don't have previous experience with automation of web applications tests using JMeter tool. At this virtual meet up you will get basic theoretical knowledge about automation test and some practical examples of using JMeter tool.
The webinar on YouTube: http://youtu.be/3_o3IOJEcxw
Tomasz Stupak is Senior Test Engineer working for 5 years in Tieto. During his profession career he has experience with software and hardware testing.
Dobry system musi być przetestowany pod względem wydajnościowym. Takie testy są zupełnie inne niż testy funkcjonalne: zamiast binarnego rezultatu (pass, fail), mamy ogromne ilości danych do zebrania, zaprezentowania i zinterpretowania. Podczas wystąpienie prelegent omówi cały cykl testów wydajnościowych: od przygotowania warunków testu, środowisk i danych testowych, poprzez przeprowadzenie testów, zebranie danych, ich prezentację i interpretacje, aż po przeprowadzenie procesów decyzyjnych wynikających z danych.
JDD 2016 - Wojciech Oczkowski - Testowanie Wydajnosci Za Pomoca Narzedzia JMHPROIDEA
W prezentacji pokażę jak wykorzystać narzędzie JMH do budowy microbenchmarków testujących wydajność zadanych kawałków kodu. Nabyte umiejętności pozwolą słuchaczom sprawdzić wydajność wybranych fragmentów kodu bez niebezpieczeństwa popełnienia, typowych dla tego typu testowania, błędów związanych z np. wygrzewaniem maszyny wirtualnej czy działalnością garbage collectora.
Apache JMeter™ to otwarte oprogramowanie, napisane w Javie i dedykowane do wykonywania testów obciążeniowych, wydajnościowych oraz funkcjonalnych. Oryginalnie było projektowane i rozwijane przez Stefano Mazzocchi z Apache Software Foundation, który napisał go do testowania wydajności Apache JServ (projektu, który został zastąpiony przez Apache Tomcat). Następnie JMeter został przeprojektowany i wyposażony w GUI celem rozszerzenia jego zastosowań do testów funkcjonalnych. W listopadzie 2011 roku JMeter stał się projektem Apache najwyższego poziomu (ang. top level), co oznacza, że zyskał społeczność odpowiedzialną za jego rozwój (ang. Project Management Commitee) oraz dedykowany serwis.
Apache JMeter jest używany do testowania wydajności statycznych oraz dynamicznych zasobów takich jak pliki, dynamiczne języki programowania serwisów internetowych, np. PHP, Java, ASP.NET, itp., obiekty Java, bazy danych i kwerendy, serwery FTP, itp. Z powodzeniem jest wykorzystywany do symulowania wzmożonego ruchu na serwerze, grupie serwerów, w sieci lub na „hartowanym” obiekcie. Służy również do analizowania całkowitej wydajności pod obciążeniem różnego typu, np. do graficznej analizy całkowitej wydajności lub do testowania zachowania się serwera / skryptu / obiektu przy wzmożonym i zrównoleglonym obciążeniu.
Apache JMeter™ to otwarte oprogramowanie, napisane w Javie i dedykowane do wykonywania testów obciążeniowych, wydajnościowych oraz funkcjonalnych. Oryginalnie było projektowane i rozwijane przez Stefano Mazzocchi z Apache Software Foundation, który napisał go do testowania wydajności Apache JServ (projektu, który został zastąpiony przez Apache Tomcat). Następnie JMeter został przeprojektowany i wyposażony w GUI celem rozszerzenia jego zastosowań do testów funkcjonalnych. W listopadzie 2011 roku JMeter stał się projektem Apache najwyższego poziomu (ang. top level), co oznacza, że zyskał społeczność odpowiedzialną za jego rozwój (ang. Project Management Commitee) oraz dedykowany serwis.
Apache JMeter jest używany do testowania wydajności statycznych oraz dynamicznych zasobów takich jak pliki, dynamiczne języki programowania serwisów internetowych, np. PHP, Java, ASP.NET, itp., obiekty Java, bazy danych i kwerendy, serwery FTP, itp. Z powodzeniem jest wykorzystywany do symulowania wzmożonego ruchu na serwerze, grupie serwerów, w sieci lub na „hartowanym” obiekcie. Służy również do analizowania całkowitej wydajności pod obciążeniem różnego typu, np. do graficznej analizy całkowitej wydajności lub do testowania zachowania się serwera / skryptu / obiektu przy wzmożonym i zrównoleglonym obciążeniu.
Na rynku mamy kilka/kilkanaście narzędzi to testów wydajnościowych. Jedne są lepsze inne tańsze. Niestety nawet te z górnej półki czasami zawodzą, i trzeba się posiłkować innymi rozwiązaniami.
W swojej prezentacji pokażę cztery problemy z testami wydajnościowymi – których nie daje się rozwiązać za pomącą HP LoadRunnera, a w których pomogły narzędzia darmowe:
Dlaczego nagrany skrypt, przy oddawaniu, generuje błędy – i jak go poprawić.
Jak znaleźć to, co się nie nagrało – i ewentualnie dodać do skryptu?
Dlaczego logowanie trwa tak długo?
Jak bez wyciągania ciężkich dział sprawdzić co jest wąskim gardłem.
Narzędzia które chciałbym krótko omówić to:
WinMerge,
Notepad++,
Filddler,
PerfMon
Automation of functional tests using JMeter Part II (in Polish)Tieto Corporation
Theoretical knowledge and practical examples about using more complicated functionalities of JMeter tool.
Presentation in Polish from a webinar that is dedicated to persons which have participated in our first training and have some previous experience with automation of web applications tests using JMeter tool.
http://www.slideshare.net/TietoCorporation/automation-of-functional-tests-using-j-meter-tool
Tomasz Stupak is Senior Test Engineer working for 5 years in Tieto. During his profession career he has experience with software and hardware testing.
Preface to a Strategic Plan for Data Science at the NIHPhilip Bourne
Summarizes the Associate Director for Data Science (ADDS) team's thinking on the strategy to use to positively impact how the NIH thinks about data science
This document discusses testing for Internet of Things (IoT) devices. It describes the challenges of testing IoT hardware, firmware, software and cloud integration. It proposes building a modular, scalable and reliable end-to-end automated testing environment to test IoT devices and scenarios. Example test cases are provided to demonstrate turning lights on and off from a mobile app and wireless switch. Vision system and test automation approaches are also summarized.
This document outlines a data science project focused on deriving insights from the website dsruption.com. The goals are to analyze article popularity on social media and automatically generate tags for articles. Technologies used include MongoDB, JavaScript, Node.js, D3.js, Hadoop, Python, and APIs from Facebook and Twitter. The project involves importing social media data, visualizing it with D3.js, identifying tags for companies from article text using Hadoop and MongoDB, and filtering noisy words from articles. Sentiment analysis and integrating additional datasets are proposed for future work.
Stickies on the wall will not help you if you are building crappy softwareWiktor Żołnowski
This document discusses how agile practices like stickies on a wall will not help if an organization has underlying issues like building poor quality software, lack of trust among employees, or basic communication problems. It emphasizes that good organizations choose practices that fit their needs and that true agility is about dividing large products into independent subproducts that can be developed and managed separately. Scaling agile is about decomposition, not just scaling individual methods. Having an agile mindset and understanding what agile means is more important than any single practice.
The document discusses the role of testers in Agile teams. It argues that while methodologies like Scrum and XP do not explicitly mention testers, they can still be valuable members of cross-functional teams. Testers bring a different perspective than programmers as they behave more like users. Their domain knowledge and ability to ask questions can help improve quality. Ultimately, the document says that while testers are not mentioned in Agile, they are still important team members, and that everyone on the team engages in a form of testing.
The document discusses reversing the traditional tests pyramid for legacy code. It proposes starting with end-to-end tests to give courage for refactoring code into testable units. This establishes a reversed tests pyramid to gradually introduce a new architecture. The goal is to keep technical debt low by refactoring and removing duplicated tests to improve software quality and the ability to change the system. Beware of refactoring just for its own sake and resist rewriting from scratch.
The document discusses reversing the traditional tests pyramid when dealing with legacy code. It notes that with legacy code, there may be no true units to unit test. Instead, it advocates starting with end-to-end tests to build confidence to refactor the code into units and add integration and unit tests. However, it warns that end-to-end tests are long to maintain. The goal is to slowly reverse the tests pyramid by refactoring code into units and adding tests at each level to manage technical debt over time. Paying down technical debt is important to maintain the ability to change software.
Agile, Scrum, Lean Startup, Testy A/B, Zwinny Marketing, Lean Canvas, Agile Coaching, Test Driven Development, User Stories, BDD, SBE, ATDD, TDD po wrzucania do jednego kotła i odpowiednim zamieszaniu otrzymujemy…(?) Przepis na sukces… Lub wiele mitów i nieporozumień!
Sukces lub totalną porażkę naszego produktu…
Współczesne metody wytwarzania oprogramowania, nowoczesne technologie i narzędzia, masowy klient/odbiorca oraz dobrze wykwalifikowani, wszechstronni developerzy dają nam możliwości, o których nie mogliśmy marzyć jeszcze kilka lat temu. Niemniej jednak nadal popełniamy wiele błedów i nasze projekt raczej stosunkowo niezbyt często kończą sie spektakularnym sukcesem.
Być może jednym z powodów tej niedoskonałości w procesach wytwarzania oprogramowania jest niekoniecznie dobre zrozumienie wspomnianych wyżej metod i narzędzi. A jeśli o zrozumienie chodzi to myślę, że najelpiej zacząć od początku naszego procesu czyli od wymagań. I właśnie o tym jest ta prezentacja… Jeśli wydaje Ci się, że wiesz już wszystko na temat BDD i wymagań w Agile to… Pewnie jesteś w błędzie… Nie, nie twierdzę, że na tym wykładzie dowiesz się wszystkiego w tym temacie… Być może jednak dowiesz się o rzeczach, które nie są oczywiste i które realnie pomoga Ci w pracy.
Jeśli uważasz, że User Stories, BDD, ATDD i SBE nie mają sensu to… Zgadzam sie z Tobą i z chęcią powiem Ci dlaczego w Twoim kontekście im tego sensu brakuje (wspomożemy się w tym celu Cynefin Framework).
Mowa będzie o mitach związanych z User Stories, Specification By Example, Behavior Driven Development, różnicy pomiędzy wymaganiami a specyfikacją, Cynefin Framework oraz Continuous Delivery.
This document discusses testing web applications in a distributed environment using Selenium Grid and Docker. It describes the challenges of testing on virtual machines and how containerization with Docker addresses those challenges by running tests within Docker containers managed by Docker Compose. Examples are provided of pulling pre-built Selenium images from Docker Hub and running a Selenium Grid configuration with a hub and node containers defined in a docker-compose.yml file. Links are also included for additional Selenium Grid and Docker resources.
Scrum and Kanban are not enough - Agile Slovenia 2013Wiktor Żołnowski
Scrum and Kanban are not enough to make an organization agile. Good organizations choose practices that fit their needs, like valuing individuals, working software, customer collaboration and adaptability. While common project methods focus on fixed plans, agile emphasizes adapting to changes. Scaling agile means dividing work into independent sub-products developed by autonomous teams with communication. Stickers on a wall won't help without addressing cultural and technical foundations for agility.
The document discusses four methods for predicting the number of defects remaining in software:
1. Tracking defects found during development, system testing, and deployment.
2. Modeling the number of defects based on factors like complexity, injection rate, and size.
3. Using reliability growth models like the Weibull distribution to plot defects over time/testing effort.
4. Dividing the software into cells to track defects found in each cell.
Przegląd najważniejszych założeń technologii ASP.NET MVC. Omówienie mechanizmów routingu, kontrolerów, widoków, bezpieczeństwa, walidacji danych, AJAX oraz rozszerzalności platformy. Prezentacja obejmuje fundamentalne założenia ASP.NET MVC 1, pozostające w większości nadal aktualne a także wybrane nowe mechanizmy ASP.NET MVC 2 i ASP.NET MVC 3.
Service workers - bądź online, nawet kiedy jesteś offline!The Software House
Tomasz Wylężek: Nazwa Service Workery na pewno niejednemu z nas kojarzy się z Web Workerami, dla których w większości aplikacji nie ma zbyt dużego zastosowania. Czy SW to tak samo mało pożyteczny "Worker", czy może krok milowy w rozwoju przeglądarek? Na prezentacji omówię podstawy Service Workerów i postaram się odpowiedzieć na wyżej zadane pytanie.
Prezentacja opisuje różne techniki optymalizacji aplikacji ASP.NET. Omawiane są role poszczególnych warstw wpływających na wydajność - od optymalizacji kodu po stronie klienta (techniki stosowane na poziomie kodu HTML i JavaScript) przez różne poziomy stosowania cache, wybrane ustawienia konfiguracyjne IIS aż po same techniki optymalizacji na poziomie kodu ASP.NET.
4Developers 2015: Przejrzysty i testowalny kod na Androidzie? Spróbujmy z Cle...PROIDEA
Michał Charmas
Language: Polish
Pisanie dobrego oprogramowania na platformę Android jest trudnym zadaniem.
Jednym z dużych problemów, zwłaszcza w przypadku sporych aplikacji, może być podział
logiki aplikacji tak, aby nasze Activity czy Fragmenty nie były nią przeładowane
oraz aplikacja była podatna na testowanie jednostkowe. Szukając pomysłu na
architekturę aplikacji, która będzie dobrze się skalowała wraz z rozwojem projektu,
natknąłem się na Clean Architecture zaproponowaną przez Boba C. Martina.
Podczas prezentacji zobaczymy czy i jak CA sprawdza się w przypadku
aplikacji mobilnych na Androida i na co pozwala jej zastosowanie. Oczywiście nie pominiemy
takich kluczowych kwestii jak pogodzenie tego wszystkiego z wszechobecną na Androidzie
asynchronicznością.
Flopsar APM Diagnostyka i monitoring aplikacji Java performance analysis debugging aplikacji, problemy aplikacji w produkcji proces wytwarzania oprogramowania skalowanie oprogramowania
O koncepcie Venia Storefront w Magento opowiadał podczas 6. edycji Meetupu Piotr Makowski - Senior Frontend Developer i Certyfikowany Magento Frontend Developer z VIRTUA
This document discusses Geb, a browser automation framework for writing end-to-end tests. It presents Geb's features like page object modeling using Groovy and jQuery-style content selection. The document also discusses problems with existing test architectures like tests being slow, unstable, and hard to maintain. It then proposes an alternative test architecture using page objects, controllers that gather page actions, and views that run test scenarios. Finally, it demonstrates implementing this architecture in Java without Geb by using page objects, method chaining for fluent interfaces, and default interface methods for controllers. Key benefits highlighted are improved readability, maintainability, and onboarding through a clearer test structure.
Kontrakt testy - KraQA 42 - Slawomir Radzyminskikraqa
The document discusses different approaches to testing services including end-to-end, isolation, and contract tests. It focuses on contract tests, explaining that they allow integration tests against mocks while ensuring the mocks accurately represent external dependencies. It provides details on consumer-driven and provider-driven contract tests, highlighting benefits of the consumer-driven approach. The document outlines the six key steps to implement contract testing in a continuous integration/continuous delivery pipeline using a pact broker to manage contracts.
The document discusses principles of continuous delivery including building quality in from the start, automating as much as possible while keeping everything in version control, testing in a production-like environment, and maintaining a simple and consistent delivery process. It emphasizes the importance of frequent releases to catch issues early, notes that testing does not ensure 100% confidence, and advocates for continuous improvement through a plan-do-study-act approach with each release representing the next stage. Continuous delivery helps reduce errors, lower stress, and gather valuable user feedback.
This document discusses the importance of treating infrastructure and pipelines as code for software development teams. It notes that while teams often focus on the application code being developed, they should also focus on how the code is built, released, and deployed. Describing these processes as code enables teams to test and assure the quality of their delivery pipelines. The document then outlines examples where infrastructure and pipelines are treated as code, such as with Jenkins Pipelines, configuration as code, and tools like Travis, Gitlab, and others. It invites readers to review examples of building pipelines as code using Jenkins and other related tools.
2. O czym nie jest ten wykład?
Akademicka teoria testów interoperacyjności
Nie jestem ekspertem
Gotowe rozwiązania – nic tylko kopiować!
Uwagi i inspiracje
Internet of Things
Następnym razem!
3. Agenda
Ogólnie o IOT
CWMP – wprowadzenie
IOT w CWMP w przykładach
Podsumowanie
4. IOT - Definicja
Interoperacyjność to cecha produktu lub systemu, którego interfejsy funkcjonują
w pełnej zgodności, tak by współpracować z innymi produktami lub systemami,
które istnieją, bądź mogą istnieć w przyszłości, bez jakiegokolwiek ograniczenia
dostępu lub ograniczonych możliwości implementacji
Źródło: http://interoperability-definition.info
5. Po co IOT?
Polepszenie jakości naszego produktu
Sprawdzenie jak nasz produkt wypada na tle konkurencji
Obsłużenie większej ilości przypadków brzegowych
Programy certyfikacyjna – prestiż, większa szansa sprzedaży
Ktoś płaci
6. IOT - Przykłady
Zgodność z systemem operacyjnym
Protokoły komunikacyjne (różne warstwy)
WiFi
GSM/3G/LTE…
9. IOT – Kompatybilność – Przykłady
Technologie internetowe
Testy przeglądarek (CSS, JavaScript)
Rozmiary i orientacja ekranu (responsie layouts)
Typy urządzeń (komputer, tablet, smartphone)
10. IOT – Interoperacyjność - Przykłady
Technologie bezprzewodowe
Wifi/wimax/gsm/lte
Technologie przewodowe
DSL/FTTH/DOCSIS
11. IOT – Jak zacząć?
1. Specyfikacja – Co jest przedmiotem testów?
2. Zakres testów – Które elementy będziemy testować?
3. Scenariusze – W jaki sposób będziemy testować?
4. Raportowanie – Jak będziemy raportować?
5. Automatyzacja – Co możemy zautomatyzować?
6. Usprawnianie – Jak wyniki testów wpływają na proces testowania?
12. CWMP
Customer-Premises Equipment WAN Management Protocol – protokół zdalnego
zarządzania urządzeniami. Umożliwia zmianę konfiguracji, przeprowadzanie
diagnosty, aktualizacje firmware, restartowanie, przywrócenie ustawień
fabrycznych.
Cechy:
TR-069 – dojrzały protokół, opublikowany w maju 2004
Obowiązujący standard w świecie telco
Wyspecyfikowany Data Model (np. TR-181)
13. CWMP – Przykłady urządzeń
Routery – Home Gateway (DSL, DOSIS, FTTH)
DHCP, WiFi, Voice
IP Phone
WiMAX/LTE
STB – Set Tob Box
Femtocele
Smart Home Gateway
18. CWMP - Metody
GetParameterNames – odkrywanie nazw parametrów
GetParameterValues – pobieranie wartości parametrów
SetParameterValues – zmiana wartość parametrów
GetParameterAttributes – pobieranie atrybutów
SetParameterAttributes – ustawianie atrybutów
Download/Upload – transfer plików (np. backup konfiguracji)
AddObject/DeleteObject – zarządzanie dynamicznymi tablicami (port
forewarding)
Reboot/FactoryReset – restartowanie i przywracanie domyślnej konfiguracji
19. Przykłady testów - TCP
Ilość połączeń TCP na sesje CWMP
Standard nie określa zachowania
Praktyka – Jedno połączenie TCP na sesje CWMP
Wielkość ramki TCP
Dramatyczny wzrost rozmiaru sesji (np. 200kb -> 8MB)
Retransmisje
„Urywanie” sesji CWMP
21. Przykłady testów – XML/SOAP
Poprawność XML
Zgodność z XSD
Domknięcia tagów
Znaki zabronione
np. backspace
Escepowanie wartości
Poprawność namespace’ów
<object name="InternetGatewayDevice.Time." access="readOnly" minEntries="1" maxEntries="1"
dmr:version="1.0">
<description>This object contains parameters relating an NTP or SNTP time client in the CPE.</description>
<parameter name="Enable" access="readWrite" dmr:version="1.4">
<description>Enables or disables the NTP or SNTP time client.</description>
<syntax>
<boolean/>
</syntax>
</parameter>
<parameter name="Status" access="readOnly" dmr:version="1.4">
<description>Status of Time support on the CPE. {{enum}}
The {{enum|Unsynchronized}} value indicates that the CPE's absolute time has not yet been set.
The {{enum|Synchronized}} value indicates that the CPE has acquired accurate absolute time; its current time
is
accurate.
The {{enum|Error_FailedToSynchronize}} value indicates that the CPE failed to acquire accurate absolute
time; its
current time is not accurate.
The {{enum|Error}} value MAY be used by the CPE to indicate a locally defined error condition.
</description>
<syntax>
<string>
<enumeration value="Disabled"/>
<enumeration value="Unsynchronized"/>
<enumeration value="Synchronized"/>
<enumeration value="Error_FailedToSynchronize"/>
<enumeration value="Error" optional="true"/>
</string>
</syntax>
</parameter>
24. CWMP - Sesja
Niepoprawne rozpoczynanie sesji
Inform/InformResponse i … ?
Poprawne zakańczanie sesji CWMP
Jakie niebezpieczeństwa niesie brak poprawnego zakończenia sesji?
Rozpoczynanie sesji w trakcie trwania poprzedniej
25. Przykłady testów - Inform
Podstawowa metoda – CPE rozpoczyna sesje
Poprawne parametry identyfikujące urządzanie (OUI/Serial number)
Poprawne typy Eventów
Boot/Bootstrap/Diagnostic Complete
Poprawny czas
Certyfikaty!
Obecność wymaganych parametrów
29. Przykłady testów – Transfery plików
Sesja CWMP
Download
RPC
Download
Response
Koniec sesji
CWMP
Transfer
pliku
Aplikacja
(Reboot)
Sesja CWMP
z TC
Transfer
Complete
Transfer
Complete
Response
Koniec sesji
CWMP
30. Przykłady testów – Transfery plików -
Problemy
Obsługiwane metody transferu
HTTP/S (z/bez autentykacji)
FTP (z/bez autentykacji)
Brak/niepoprawny Event w Inform
Brak TransferComplete
Niepoprawne czasy
Za krótki bufor na URL
Zła metoda HTTP (POST zamiast PUT przy Upload)
36. Format ma znaczenie
Dbaj o czytelność logów!
<ParameterValueStruct><Name>InternetGatewayDevice.ManagementServer.PeriodicInfor
mInterval</Name><Value
xsi:type="xsd:unsignedInt">3600</Value></ParameterValueStruct>
<ParameterValueStruct>
<Name>InternetGatewayDevice.ManagementServer.PeriodicInformInterval</Name>
<Value xsi:type="xsd:unsignedInt">3600</Value>
</ParameterValueStruct>
37. Przechowywanie wyników
Opis testów
Wewnętrzny (techniczny)
Dla klienta (marketingowy)
Reporty - template raportu
Przyśpiesza prace
Standaryzacja
Baza danych to dobry pomysł!
Statystyki
Polecanie dobrych urządzeń
38. Narzędzia
Wireshark
Języki skryptowe
Python
Bash
Parsery XML (validacja XSD)
Dedykowane rozwiązanie
Pełna kontrola nad testami
Duża inwestycja
39. Zagrożenia i wyzwania
Niedojrzała specyfikacja
Brak standardów
Niepełne standardy
Standardy pozwalające na dużą „dowolność”
Mnogość implementacji
Słaba jakość
Długi czas fixowania błedów
Odkrycie problemu -> Przygotowanie łatki w bibliotece TR-069 -> Testy ->
Inetgracja z firmware -> Testy integracji -> Testy u Operatora -> deployment
Urządzenie/systemy „chytruski”
Uwaga na wersje oprogramowania!
Dobrze jest robić MD5
40. Automaty? Tak, ale…
Dla bardzo złych CPE stopień skomplikowania testów zaczyna przeszkadzać
Pokrycie tylko znanych przypadków
Bardzo trudna weryfikacja faktycznego działania
Ręczne rozwiązywanie problemów
41. Poza IOT
Testy „Serwisowe”
Czy to naprawdę działa?
Wydajność
Jak dużo wiadomość CWMP urządzenie jest w stanie obsłużyć?
Stabilność
Czy moduł CWMP nie zawiesza się?
Programy certyfikacji
Budują zaufanie
Rozpoznawalność marki
42. Podsumwanie
IOT – ciężki kawałek chleba
CWMP – dobry protokuł managementowy (choć nie bez wad)
Przygotuj się na wszystko!
Dowolne błędy na dowolnym poziomie
Niedostatki i nieścisłości specyfikacji
Czynnik ludzki