Qualitätssicherung & Testing - IU-Internationale-Hochschule-Augsburg/fallstudie-thema-2-online-umfragesystem GitHub Wiki

Bisher sammeln wir erst einmal Ideen und Gedanken, wie wir Qualität sichern und welche Testmöglichkeiten es gibt

QS und Testing nach den Quality Gates

Qualitätssicherung:

• Pair Programming (haben wir schon gemacht :-))
• Anforderungen prüfen (Vollständigkeit, Konkretheit)
• Beschreiben der Komponenten (Quality Gate Q4)

Testing: parallel zur Implementierung werden Testfälle erstellt

• Statische Testverfahren wie Codeanalyse
• JUnit-Tests (Quality Gate Q4) - eine Quelle: https://spring.io/guides/gs/testing-web
• Testen durch Außenstehende (inkl. Checkliste, was das Online-Umfragesystem können soll)

=> eine weitere Quelle: https://docs.spring.io/spring-boot/docs/1.5.2.RELEASE/reference/html/boot-features-testing.html

Integrationstests und automatisierte Tests zu aufwendig/gehen zu weit?

Testen unter Linux (Manjaro):

Ich war positiv überrascht, unser Projekt lässt sich eigentlich zügig einrichten. Gradle lief super, die Encryption hat auch zügig funktioniert und auch die Datenbank ließ sich in intelliJ einfach integrieren. Das einzige, was mir beim Testen aufgefallen ist, ist die Position der "Fragen"-Übersicht im QuestionView:

Ich persönlich kann damit leben. Wenn wir es zeitlich noch schaffen, können wir uns das nochmal anschauen.

Statische Codeanalyse mit PMD:

Beim ersten Run von PMD:

Beim zweiten Run von PMD nach ein paar Changes:

Fazit:

Ein paar Violation-Hinweise waren wirklich sinnvoll wie Hinweise, dass lokale Variablen final sein könnten oder dass der Pfad in SurveyErrorController static sein könnte. Jedoch ist schon bemerkbar, dass PMD ein paar Eigenheiten von Spring Boot nicht kennt. Ein Beispiel hierfür sind die leeren Konstruktoren, die Spring Boot aber in den Entities benötigt. Diese werden mehrfach als Violation aufgeführt. Zu den Violations in Documentation würde ich persönlich sagen: Das ist Geschmackssache. Ich möchte nicht jede Deklaration einer Variable extra kommentieren, denn diese sind selbsterklärend. Die wichtigsten Methoden, die Erklärungsbedarf haben, sind bereits entsprechend kommentiert.

Daher möchte ich eigene Rules für PMD in XML festlegen.

Bisher habe ich einer eigenen .xml-Datei (unter: \fallstudie-thema-2-online-umfragesystem\MVP\survey-application\config\pmdRuleset.xml) festgelegt, welche Rules ich nicht haben möchte. Ob wir in Zukunft noch eigene Regeln festlegen, entscheiden wir noch.

Testen von SQL Injections

SQL Queries wie DROP TABLE survey; oder TRUNCATE TABLE question; sind beliebte Eingaben, um Sicherheitslücken einer Datenbank auszunutzen. Mit dem DROP TABLE Command kann eine Tabelle einer Datenbank gelöscht werden und mit TRUNCATE TABLE werden Inhalte aus einer Tabelle gelöscht.

Die Gefahr für SQL Injections besteht dann, wenn man SQL Queries selbst im Code zusammenbaut. Dadurch, dass wir das nicht selbst machen, sondern mithilfe von JPA und Hibernate bin ich von vornherein nicht davon ausgegangen, dass wir Opfer einer solchen SQL Injection werden können. Dennoch habe ich es getestet:

Ich lag richtig. Die eingegebenen SQL Queries werden so wie erwartet als String in der Datenbank gespeichert.

Code Review Checklist:

• Functionality: Does the code work as expected?
• Complexity: Are there any areas where code could be simplified?
• Naming conventions: Is everything properly and clearly named? A code review template can be especially helpful in this area.
• Comments and documentation: Are there any parts of the code that need further explanation?
• Consistency: Does the code make sense throughout?
• Context: Does the code fit within the company guidelines and the larger picture of the project?
• Adaptability: Will the code be easy to change for future improvements?