Über notepad++
Ersetze alle , durch ;
Ersetze alle . durch ,
Öffne die gespeicherte Datei einfach in Excel.
Über OpenOffice Calc
die .csv mit OpenOffice Calc öffnen -> der Wizard fragt alles Nötige ab.
Archiv der Kategorie: Ohne Schublade
Vorteile der Testautomatisierung
Noch einarbeiten: Beitrag bearbeiten „Inwiefern die Testautomatisierung über die Ablösung manueller Tester hinausgeht“ ‹ IT Kosmopolit — WordPress
Noch einarbeiten: Beitrag bearbeiten „Erfolgskriterien in der UI-basierten Testautomatisierung“ ‹ IT Kosmopolit — WordPress
Verweis auf: Beitrag bearbeiten „ROI der Testautomatisierung“ ‹ IT Kosmopolit — WordPress
Nachteile manueller Tests
| manuelle Tests sind teuer | Manuelle Tests: man zahlt für jeden Testrun immer höhere Summen, weil Tests immer umfangreicher werden müssen. Automatische Tests: man investiert zu Beginn und zahlt dann nur noch wenig für die kontinuierlichen Anpassung. ROI-Diagramm siehe unten |
| manuelle Tests sind unzuverlässig | Faktor Mensch: Konzentration lässt nach, Betriebsblindheit, Änderungen werden ignoriert, … |
| manuelle Tests sind grob | Testkombinatorik (z.B. verschiedene Browser testen) kaum möglich -> unentdeckte Bugs können sehr teuer werden. Testabdeckung wird durch Testautomatisierung höher. |
| manuelle Tests sind monoton | „Fließbandarbeit“ -> Jobattraktivität niedrig |
Zum verbreiteten Argument, dass manuelle Tests per se langsamer sind: siehe
Vorteile automatischer Tests
bereits bei niedriger Testabdeckung:
| Fast & Focussed Feedback | Die automatischen Tests sind die Grundvoraussetzung für Continuous Integration und all deren Vorteile sind somit die der Testautomatisierung. Dieser Punkt ist der wichtigste – hier ist der größte Effizienzhebel des Testautomatisierung für’s Softwareprojekt! Nightly build (Mindestziel bei Testautomatisierung): Nachts automatisch komplett testen und am nächsten Morgen haben Entwickler Kenntnis über mögliche Regressionen ihrer Codeänderungen. Focussed: – Je weniger Systemänderungen (nicht nur Commits, auch Plattformupdates etc.), die von einem Regressionstests erfasst werden, desto besser. Weil der „Ursachenraum“ entsprechend klein ist, kann die Ursache der Regression auch schneller gefunden werden. Dies spart gegenüber sog. Big Bangs sowohl Zeit als auch Geld über die gesamte Lebensdauer eines Projekts. Fast: – Je schneller die Tests erfolgen, desto frischer ist das Thema noch im Kopf des Entwicklers und er muss sich nicht nach 3 Wochen wieder in die Thematik aufwändig einarbeiten, um das Problem zu lösen. – Die Wahrscheinlichkeit, dass der regressions-verursachende Entwickler am nächsten Morgen noch da ist, ist größer, als am Ende eines Releasezyklus. Er könnte krank geworden oder in Urlaub gegangen sein. Ein Kollege müsste sich erst mühsam in fremden Code einarbeiten um die Regression zu beheben. – Vermeiden von Folgefehlern — Entwickler baut seine Lösung nicht auf einem wackligen Fundament weiter. Wegen des Defects müsste er eigentlich einen anderen Ansatz nehmen, weil er ihn aber nicht frühzeitig entdeckt, verschwendet er Zeit mit diesem Ansatz — Entwicklerkollegen (und auch der Entwickler selbst) bauen ihre Lösungen u.U. auf dem Defect auf, die Fehlerdichte kumuliert immer mehr und am Ende entsteht ein gordischer Knoten. Die technischen Schulden steigen |
| Heben Nachteile manueller Tests auf | * niedrigere Kosten * höhere Zuverlässigkeit * ausdifferenziertere Tests möglich (Kombinatorik) * höhere Jobattraktivität |
| Risikoärmere Hotfixes | Hotfixes müssen nicht mehr ungeprüft eingespielt werden bzw. können zeitnah nach dem Einspielen auf der Produktivumgebung nachgetestet werden. -> geringeres Risiko von teuren Bugs |
| Bessere Verteilung | Wenn alle Bugs erst zum monatlichen Regressionstests gefunden werden, reicht die Debuggingzeit möglicherweise nicht mehr aus, den Deploymenttermin zu halten. Monatliche Regressionstests werden selten ein zweites Mal nach dem Debugging durchgeführt, obwohl mit jedem Debugging potenziell eine weitere Regression stattfinden kann. |
ab hoher Testabdeckung:
| Kürzere Time-To-Market | Releasezyklen können stark verkürzt werden -> kürzere Time-To-Market: wichtige Features werden zeitnah und nicht erst beim nächsten Release wirksam. |
| Mutigeres Programmieren wird ermöglicht | Softwareentwickler müssen nicht mehr so defensiv programmieren, weil sie mit der Testautomatisierung ab einem bestimmten Level ein gutes Sicherheitsnetz haben. Defensives Programmieren kostet das Projekt unnötig Entwicklerzeit. |
VLC media player hacks
Frame-by-Frame-Stepping
In Ranorex beispielsweise kann man die Frame rate (also frames per second) einstellen. Die default-Einstellung liegt bei 15 Frames/Second. Wenn das Video so erstellt wurde, entspricht ein Frame also einem exakten Bruchteil einer Sekunde. Das habe ich selbst nachvollzogen und es scheint zu stimmen.
Bei einem anderen beliebigen Screnncast habe mal nachgezählt und die frame rate war nicht konstant:
- erste Sekunde: 15 frames
- zweite Sekunde: 10 frames
- dritte Sekunde: 13 frames
- vierte Sekunde: 14 frames
- fünfte Sekunde: 15 frames
Frame by Frame stepping: How to Go Frame by Frame in VLC (vlchelp.com)
Taste e drücken oder den Button
klicken ist identisch – das habe ich selbst ausprobiert). Ausnahme: dass man die e-Taste auch gedrückt halten kann und so schneller voranschreiten.
Zurück-Frame-Step ist nicht implementiert, obwohl es schon sehr lange, sehr vehement gefordert wird (siehe Kommentare).
Hack: mit Shift+Left kann man 3 Sekunden zurück (mit Shift+right kann man 3 Sekunden vor) und anschließend kann man ein paar Frames wieder nach vorne.
Tags: VideoLAN Client