A real life story about product testing with robotframework Lessons learned testing IoT devices wit…
En we creëren heet om je huis te lopen. Dus een beetje over de producten, we testen met een robot framework. We ontwikkelen een nieuw smartroomcontroller die veel radiointerfaces, wifi, 868Mhz en zelfs een ZigBee interface. Het is een bedrijf met een Android en iOS app. We supporten veel verschillende protocolen om hier van een apparaat te bevinden. We kunnen ook met apparaatjes van andere vandaars gebruiken. De meeste feature is zone control. We kunnen de temperatuur in de ruimtes controleren, individueel en niet als een hele systeem voor je huis. We maken ook de apparaatjes controleren. Het is de onderdeel van de apparaatjes die je ziet. Dat zijn de elektronici die de HMI geven. Controle de burner, pumps, fans, valves. De apparaatjes is met een businterface om de thermostat te connecten. Het heeft ook een veilig kritische deel, omdat we meestal gasapplies zijn in de sterkere regulaties. Dan een beetje over testautomatie, want als ik een businterface ben, als tester begon ik in een project van een prachtige product. We hadden een app en we waren aan het uitleggen. De manier waarom we dat doen, met manier testen, in ieder geval over en over, hadden we denk dat we iets meer nodig hebben voor dat. Dat is waarom we begonnen kijken in testautomatie. De eerste is waarom we want testautomatie. We willen feedback. Als je iets vervolgd hebt, wil je snel feedback over wat je vervolgd hebt, of dat werkt. De tweede is, we willen automatisch een repetitive regressie test. Er is niets minder behoorlijk dan over en over dezelfde job. We hebben ook tijd om de release te creëren, want nu is het met app-developement, maar ook voor ontdekend producten. We hebben de omgeving om te updaten, zodat we heel makkelijk kunnen creëren fixes of expanden functie. Dat leeft ons in de onderdeel, dat we willen ingewikkeld hebben in producten-developement, en dat we flexibel zijn in creëren producten-configuraties en de levering van frequent updates. Hoe hebben we dat gedaan? Het was een lange manier voor ons. De dingen die zijn op de gedeelte, zijn wel welk knowne voor je. Maar als je testautomatie begint, het klinkt veel makkelijker dan het eigenlijk is. Wat moet worden gedaan als je met testautomatie begint, moet je eerst besluiten wat je wilt testen op welke niveau. Je hebt natuurlijk unit-testing gedaan door de developer zelf.  Integratie-testing, het testen van partijen van je producten, en in de eind, de acceptantie testen, voordat je de producten releaset. Voor elke niveau moet je een testarchitectuur creëren. En wat je hier ziet, de testpyramide, als we op de testautomatie begonnen hebben, was het meer of meer of minder upside-down voor ons. Dus als je unit-testing hebt, dat zijn de meest makkelijkste testen om te creëren en te implementeren. Als je in je testpyramide hoort, naar de end-to-end testen, die testen, want je werkt met een zwart bocht, is het heel moeilijk om te implementeren. Je moet de systeem van de buitenkant veranderen. Je hebt niet veel kennis over de binnenkant, dus die testen zijn heel moeilijk om te implementeren. Daarom moet de meestal van de testen op unit-testing zijn, en alleen de end-to-end testen moeten als mogelijk minder zijn. Als we naar de robot-framing kijken, als we begonnen hebben, hadden we de testpyramide upside-down. En dit is eigenlijk de keuze waarin de robot-framing kan helpen. Een robot-framing behoort zich over... je kan veel interfaces overleven, maar het bedoelt de reale product van de functie. Als we naar de robot-framing kijken, een kleine historie, de robot-framing was eerst ontwikkeld in Nokia. Het is nu door de robot-framing, en natuurlijk kan je het gebruiken voor veel verschillende manieren. Maar het bevindt het als een test-automation-framing, dus het maakt je de toolen om proper testen te doen. Het meeste is dat het heel extendbaar is met libraries, en het bevindt je ook met goede functie-reporting. Bezins van de robot-framing is het besteld als een Python-modul. Dus natuurlijk moet je Python, en je kunt het easily extenden met andere toolen, ook Python-modulen. Bijvoorbeeld gebruiken we Modplotlip, PySerial, en je kan veel van andere deel nemen. We gebruiken Aconda als een package-management systeem als een setup of testenvironment, PyCharm om een robot-test en Python-librariëtes te rijden, die worden gebruikt door de robot-framing, en natuurlijk Jenkins als een build-automation-tool, waarin we de testen van bevinden. Dan een beetje over hoe we eigenlijk de robot-framing gebruiken tijdens de testen. Eerst zal ik een beetje over de smartroom-termostat vertellen, en dan zal mijn collega Windel over en je meer over hoe we testen of de controle uniten. Wat is de room-termostat? Het is goed om een beetje van hoe het systeem functions, dus we hebben de termostat in de midden.  Het kan de verschillende ruimte controleren met elektro-electric radiativels. Het heeft een buskonexie naar de applies. Natuurlijk hebben we de app en een backend om bevinden, en alle soorten parten. Dus als we het testen willen, dan zie je al wat interfaces naar de room-termostat. We moeten wel denken over een systeem hoe we het testen kunnen. Dus hier in deze foto hebben we de room-termostat, de verschillende modules die erin zijn, de main-control uniten, de wifi module, de HX8 module, we hebben nu de ZigBee. We hebben natuurlijk de connectie naar de applies, we hebben een backend connectie en we hebben een app. Eerst hebben we besloten, ja, toen we besloten over de testen, we hebben gezegd, oké, als we integratie testen, we willen alleen de room-termostat testen. En we willen de app separate testen. We hebben ook een testset te testen samen, maar dat leeft ons met de volgende setup. We hebben de app gestopt, we hebben de HX8 module gestopt, want dat is externelly gevolgd. We hebben gestopt, of applies, en we hebben alles geconnected tot een testexecutor. Als we de robot framework op de top van dat hebben we een testarchitectuur, die we hier kunnen zien. Op de top hebben we of testcases, die we proberen per functie te geven. Aangezien dat, zijn er resources, robot framework supply's met een manier om generische keywords te defineren. Bijvoorbeeld, we hebben een resource om de room temperatuur op 20 graden te zetten. En we kunnen dat in alle verschillende testen gebruiken. Met de resources zijn we heel handig, dus je kunt het uitleggen, of je hebt een heel mentaal testcase, want als je iets veranderd in je logiek, kan je het in de resources veranderen en moet niet veel testcases veranderen. Als we terug naar de onderdeel gaan, we hebben natuurlijk de robot framework zelf. En onder de robot framework hebben we de verschillende libraries. Deze zijn de libraries die we implementeren, maar de robot framework zelf komt ook met veel verschillende libraries die worden gegeven door veel mensen die robot framework gebruiken. Wat we hebben gedaan, is dat we een library hebben gecreëerd voor onze HX8-communicatie naar de radiële files. Dus we kunnen actief controleren hoe de user een radiële file gebruikt. We hebben een simulator die zegt oké, ik simulate, ik presse een button op de file en dan...  Our library provides that to the terminal status, so we could give a reaction and robot framework captures the reaction and checks if that is the desired function we want. By implementing this, in this way we can set up a dynamic environment, we can... Sorry? I have a question. Before going to the implementation, can you give us a small example of what we intend to do in the previous video? Because right now you are describing what you intend to do, how you intend to implement in that figure. What we integrate here is the behavior between the whole firmware of the main control unit. Sorry, you wanted to know what we are integrating in this figure. What we are integrating here is our firmware of the main control unit and the firmware of the Wi-Fi module. These are both supplied by ourselves and we want to be sure that they work fully together. Is that... And to end testing is... And to end testing is that we also include the app, so we change something on the app and we want to know what happens. For instance in the room, the user changes something with his or hers app. Okay, then back to the implementation, so we built a library for every interface we have. So here we can create a setup, for instance our house has four rooms with four thermostatic radiator valves or with only one thermostatic radiator valve in a room, multiple radiator valves and so on. So we can differentiate in how the setup is the user uses his or her thermostat. Also we have, on the other hand, have simulated or appliance connection. So we can simulate different appliances users have an open-term appliance for a competitor on-off appliance or also different appliances made by ourselves. Then in the middle we have the API, the app users. And we also have a debug connection by which we can control the device itself for instance to let it reboot to certain modes and so on. On the first slide about how we, how you should test and the bottom, it said create a testable product while for instance this debug interface is very handy for us to automate or test and it's really necessary to do good testing with our product. 