Stefan's Bastelkiste

• Neugier auf Neues
• Dinge voran bringen und verbessern

wird fortgesetzt...

Test Objekte sind die Firmware und teilweise Hardware der verschiedenen hergestellten Varianten der LTO Tape Libraries für diverse Hersteller. Die Bandbreite reicht von 1U Geräten mit 8 Bändern und 1 Laufwerk bis zu 7x6U Stacks mit 560 Bändern und 42 Laufwerken. Diese Datenspeicher haben die unterschiedlichsten Schnittstellen und zahlreiche Funktionen.

Schnittstellen:

• SCSI, über Fiber Channel und SAS
• Remote Management Interface (Web Page), über Netzwerk für Konfiguration, Steuerung und Status
• Operator Control Panel, Benutzerschnittstelle direkt am Gerät für Konfiguration, Steuerung und Status
• REST, für Konfiguration, Steuerung und Status z.B. in der Produktion oder Monitoring
• Hersteller spezifische Schnittstellen
• Remote Test Interface, für Test Automation (SSH/Serial)
• Neuere Modelle basieren auf Embedded Linux oder älter auf Nucleus RTOS.

Funktionen:

• Hauptfunktion ist der Zugriff auf die Bänder per SCSI für Backup Application und der per SCSI (Backup App) gesteuerte wechsel der Bänder je nach Konfiguration z.B. tägliches oder monatliches Backup, Kapazitätsgrenzen einzelner Bänder.
• Daten Verschlüsselung
• Partitionierung der Hardware in logische Libraries z.B. eine logische Library per Abteilung
• Benutzermanagement mit verschieden Zugriffsebenen, lokal oder LDAP
• Status Monitoring, aktiv per SNMP traps und Email oder passiv per lokalen Logs, SNMP, rsyslog,CVTL
• und vieles mehr

Aufgaben als Tester:

• Erstellen von Test Cases basierend auf Requirements und Spezifikationen, (Helix ALM)
• Mehrstufiges Review von Test Cases von anderen Team Mitgliedern, (Helix ALM)
• Automatisierung von Test Cases in Abhängigkeit von Komplexität und wahrscheinlicher Wiederholungsfrequenz. (Robot Framework, RIDE, Selenium)
• Durchführung von Smoke-, Acceptance-, Regressions-, Nicht Funktionalen- und Funktionalen-Test, Dokumentation der Ergebnisse
• Im Fehlerfall Analyse und Dokumentation. (Helix ALM)
• Retest von behobenen Fehlern
• Erweiterung der Testmöglichkeiten der Firmware durch Entwicklung von Keyword Libraries für Robot Framework. (Python, Eclipse, Visual Studio Code)
• Qualitätssicherung der automatisierten Test und Robot FW Libraries durch Code Review (SSCM)
• Unterstützung lokalen und internationalen Test Teams

Unterstützung externer Test Labore ( EMV, Shock & Vibe)

• Organisation, Aufbau und Konfiguration der für den Test erforderlichen Geräte (Server, Library, Drives)
• Erstellung der Dokumentation des Aufbaus
• Erstellung der Anleitungen für die benötigten Operationsmodi des Testaufbaus
• Unterstützung der externen Tester per Fernwartung und vor Ort

Aufgaben für die Administration und Überwachung aller Test Umgebungen des Test Centers

• Bereitstellung und Konfiguration der Netzwerk Infrastruktur
• Bereitstellung der Server und Services mit unterschiedlichen Konfigurationen u.a.
  • Active Directory
  • File-Server (Windows, Samba)
  • FTP-Server
  • Email-Server (Postfix, Exchange)
  • LDAP-Server (OpenLDAP, Active Directory)
  • HTTP (Apache, Lighttpd)
  • rsyslog
  • Kerberos
• Bereitstellung von virtuellen Windows Desktops mit Test Tools (Windows 7-10, Webbrowser in verschieden Versionen)

Projekte:

• Unterstützung von Kollegen durch Entwicklung von neuen grafischen Test Tools (Python, wxPython, tkInter) und Weiterentwicklung bereits existierenden grafischen Test Tools (C#) nach ihren Anforderungen.
• Optimierung der Reliability und Life Tests durch Entwicklung von automatischen Monitoring und Reporting Tools (Python)
• Automation vom Reliability Tests durch Entwicklung der Anbindung des Prüflings und einer Siemens Logo (SPS)
• Anbindung von physikalischen Benutzer Interfaces an die Test Automation, durch Entwicklung eines Prototypen des Hardware Interfaces, des REST Interfaces und der Robot Framework Library (Python, Raspberry pi)
• Aufbau kostengünstiger langzeit Überwachung von Temperatur und Video des Test Labors basierend auf Python, SNMP, Raspberry Pi

As you may know the to be tested software can depend on external service like SMTP or LDAP. Using the production environment is not the best idea, since there are very different goals on a goal sheet for an IT-guy and a tester.

Therefore someone (me) has to take care of it and provide all the required servers, desktop, services and tools.

To test our tape libraries we need e.g. SCSI, Email-, LDAP-, HTTP, CA-, vendor specific encryption key server like ESKM or SKLM, Active Directory, file servers and data to actually backup for the system integration with different Backup software vendors..

Almost every service can have a multitude of different configurations and performance for most of these systems is not the highest priority or if you choose the right version (Postfix vs. Exchange) they do not need a lot of resources.

A good way to share your certainly limited resources is virtualization.

This way it is easy to run like 6 Linux email servers with different security configuration with 1.5 GB RAM and 10 GB HDD including web mail. Others like the key servers need Windows and min 4GB RAM and you need like 3 Version and replication and and and... Or you need different version of IE or FF or Chrome

VMware, KVM, Xen are your friends.

Another big benefit of virtual machines are snapshots, you have a setup working server/desktop with all the needed tools an services. Freeze it with a snapshot and when a tester has managed to break it, simply reset it and it's working again.

Every thing is better with LEDs, right?

So my r/c car needed some. Options are just buy a kit and be stuck with the vendor possibilities or DIY.

Of course DIY!!!

After some brainstorming I decided to start small.

Level 1:

• head and tail lights
• break lights
• some blinking
• switch able from the remote

Lucky for me my remote control set has 3 channels and with it's already custom firmware I can program it to cycle throug -100%, -50%,... to 100%.

And a quick look into my electronic part bins showed yeah I have all needed parts.

BoM:

• 4x LEDs
• 4x matching resistors
• bains >> Arduino
• power main r/c battery
• some connectors ( for connecting the receiver and the LEDs, I want to be able to easily disconnect it )
• cables
• hot glue

Basically the Arduino is connected in parallel to channel 2 and 3 ( throttle and the button) The Arduino reads the PWN signals from the receiver and does some LEDs blinking.

Simple right? No? here is a schematic thing

HW version 1, kind of huge

HW version 2, better.

And a PCB idea

And the Fritzing project file rc-lights-v4-arduino-mini-pro.fzz

Software:

rclightv3_serialoutput.ino

/
RC Lights by Stefan.Schmidt@knallakoff.de

Utility.h for the foreach(), pachted for IDE 1.0
v4
pro mini

http://arduino.cc/playground/Code/Utility
patch http://markus.jabs.name/2011/12/arduino-kennt-wprogram-nicht-mehr/
/
#include <Utility.h>
boolean debug = false;

//def input for 3 channel
int channel1_pin = 14;
unsigned int channel1_pulse;
int channel2_pin = 15;
unsigned int channel2_pulse;
int channel3_pin = 16;
unsigned int channel3_pulse;


int lstates[8] = {0, 0, 0, 0, 0, 0, 0, 0};  //to stor the lights start.... only 1 used until now
// only 4 are used, more to come...
byte headr = 10;
byte headl = 11;
byte backr = 3;
byte backl = 6;
byte revl = 5;
byte tr = 9;
byte tl = 12;
byte ex1 = 13;

byte lights[8] = {headr, headl, backr, backl, revl, tr, tl, ex1};



void setup(){
    if (debug){
        Serial.begin(9600);
    }
    // input setup
    pinMode(channel1_pin, INPUT);
    pinMode(channel2_pin, INPUT);
    pinMode(channel3_pin, INPUT);

    // output setup
    foreach(lights, 8, pinMode, OUTPUT);
    // by default all LEDs are on, so you can see if they are working
    foreach(lights, 8, digitalWrite, HIGH);
}

void loop()
    {  
    // Read the channles, CH1 Steering, CH2 Throttle and 
    // CH3 multi position switch, -100%, -50%, 0%, 50% and 100% on my H-GT3b with 0.41 PSX Firmware, 4 of 8 are possible positions are used
    // CH1 disabled by default I do not use it (not connected) and this add delay so it does not blink so fast 

    //channel1_pulse = pulseIn(channel1_pin, HIGH, 20000);
    channel2_pulse = pulseIn(channel2_pin, HIGH, 20000);
    channel3_pulse = pulseIn(channel3_pin, HIGH, 20000);

    // Some Debug to see what is read from the channels
    if (debug){
        Serial.print("c1: ");
        Serial.print(channel1_pulse);
        Serial.print(" c2: ");
        Serial.print(channel2_pulse);
        Serial.print(" c3: ");
        Serial.println(channel3_pulse);
    }

    //begin switching depending on CH3 position
    //CH3 100% - some fast single blinking (
    if (channel3_pulse > 1900) {
        if (lstates[4]== 0){
            digitalWrite(lights[0], HIGH);
            digitalWrite(lights[1], LOW);
            digitalWrite(lights[2], LOW);
            digitalWrite(lights[3], LOW);
            } 
        if (lstates[4]== 1){
            digitalWrite(lights[0], LOW);
            digitalWrite(lights[1], HIGH);
            digitalWrite(lights[2], LOW);
            digitalWrite(lights[3], LOW);
            } 
        if (lstates[4]== 2){
            digitalWrite(lights[0], LOW);
            digitalWrite(lights[1], LOW);
            digitalWrite(lights[2], HIGH);
            digitalWrite(lights[3], LOW);
            } 
        if (lstates[4]== 3){
            digitalWrite(lights[0], LOW);
            digitalWrite(lights[1], LOW);
            digitalWrite(lights[2], LOW);
            digitalWrite(lights[3], HIGH);
            lstates[4]= -1;
            }
        lstates[4]++;    
    }

    //CH3 50% - some 4 LED blinking slower
    if ((channel3_pulse > 1700)and (channel3_pulse < 1900)) {
        if (lstates[4]== 0){
            digitalWrite(lights[0], HIGH);
            digitalWrite(lights[1], HIGH);
            digitalWrite(lights[2], HIGH);
            digitalWrite(lights[3], HIGH);
            lstates[4]= 1;
            } 
        else {
            digitalWrite(lights[0], LOW);
            digitalWrite(lights[1], LOW);
            digitalWrite(lights[2], LOW);
            digitalWrite(lights[3], LOW);
            lstates[4]= 0;
            }
        delay(150);
    }

    //CH3 0% - LEDs blinking in X pattern - slower

    if ((channel3_pulse > 1400)and (channel3_pulse < 1700)) {
        if (lstates[4]== 0){
            digitalWrite(lights[0], LOW);
            digitalWrite(lights[1], HIGH);
            digitalWrite(lights[2], LOW);
            digitalWrite(lights[3], HIGH);
            lstates[4]= 1;
            } 
        else {
            digitalWrite(lights[0], HIGH);
            digitalWrite(lights[1], LOW);
            digitalWrite(lights[2], HIGH);
            digitalWrite(lights[3], LOW);
            lstates[4]= 0;
            }
        delay(300);
    }

    //CH3 -50% - normal 4 LED on (normal light) if CH2 is beaking /reverse rear LEDs blink
    if ((channel3_pulse > 1200)and (channel3_pulse < 1400)) {
        digitalWrite(lights[0], HIGH);
        digitalWrite(lights[1], HIGH);
        digitalWrite(lights[2], HIGH);
        digitalWrite(lights[3], HIGH);
        lstates[4]= 0;
        if ((channel2_pulse < 1300)) {
            digitalWrite(lights[2], LOW);
            digitalWrite(lights[3], LOW);
            lstates[4]= 1;
            delay(30);
            }
        if ((channel2_pulse < 1300)and(lstates[4]== 1)) {
            lstates[4]= 0;
            digitalWrite(lights[2], HIGH);
            digitalWrite(lights[3], HIGH);
            delay(30);
            }
    }

    //CH3 -100% - lights off, if CH2 is beaking /reverse rear LEDs blink 
    if ((channel3_pulse > 900)and (channel3_pulse < 1200)) {
        digitalWrite(lights[0], LOW);
        digitalWrite(lights[1], LOW);
        digitalWrite(lights[2], LOW);
        digitalWrite(lights[3], LOW);
        if ((channel2_pulse < 1300)) {
            digitalWrite(lights[2], HIGH);
            digitalWrite(lights[3], HIGH);
            }
        } 
    }

Currently I'm a Software Test Engineer

Our test team is testing these tape libraries

Therefore I write, review and execute manual and automated tests case. These tests cover interfaces like web, REST, SCSI and some proprietary once. For the tests we need an environment which I do manage too.

For automation we use mainly Robot Framework, since the software we test runs on specialized hardware I had to extend robot framework with libraries for our libraries So I had to start wirte them myself and soon was joined by other team members. Now we have about 40 libraries with a lot of keywords, maybe 500-1000. And of cause we have to adapt and expand them continuously since there is always a new feature and changes in the next release.

Having these libraries made it possible to easily write some tools to make tedious tasks faster, more reliable and last but not least simpler for the testers. E.g. sending status mails around or collecting logs of long term reliability and live tests or just automate the constantly reoccurring task with 9 steps which has to be done for every second test case.