Unit Testing

Note: This notes were strongly inspired by the following books: CSSLP Certification All in one and Official (ISC)2 Guide to the CSSLP CBK, Second Edition

Security Quality Assurance Testing

Standards for Software Quality Assurance

ISO 9216 – provides guidance for establishing quality in software products.
ISO 21827 SSE-CMM (Systems Security Engineering Capability Maturity Model) – addresses security engineering activities that span the entire secure system lifecycle.
OSSTMM (Open Source Security Testing Methodology Manual) – provides a scientific methodology for assessing operational security built upon analytical metrics.

Types of software QA Testing

functional testing – Software testing is performed to primarily attest the functionality of the software as expected by the business or customer.
unit testing
system/integration testing – assures that the overall system is compliant with the system-level requirements.
regression testing – performed to validate that the software did not break previous functionality or security and regress to a non-functional or insecure state.
non-functional testing – covers testing for the recoverability and environmental aspects of the software.
performance testing
- load testing – process of subjecting the software to volumes of operating tasks or users until it cannot handle any more, with the goal of identifying the maximum operating capacity for the software
- stress testing – aimed to determine the breaking point of the software, i.e., the point at which the software can no longer function.
user acceptance testing (smoke testing) – UAT is generally performed as a black box test which focuses primarily on the functionality and usability of the application.

Security testing methods

white-box testing – testing is performed on a system with the full knowledge of the working components including the source code and its operations.
black-box testing – the attacker has no knowledge of the inner workings of the software under test.

Type of security testing

scanning – automatic enumerations of specific characteristics of an application or network
cryptographic validation testing –
penetration testing – the main objective of penetration testing is
to see if the network and software assets can be compromised by exploiting the vulnerabilities that were determined by the scans.
fuzzing – brute-force method of addressing input validation issues and vulnerabilities.
simulation testing – testing the application in an environment that mirrors the associated production environment.

Very often in-memory instances of HSQLDB are used in the context of unit tests; the unit test starts a database instance (eventually on a random port), provision the database with some data, run the test against the database end then stop it.

Now, from time to time you need to debug the unit tests and sometimes you also need to run manually some queries on the in-memory database (using HSQLDB manager or any other software).

So here are the steps in order to be able to connect to an in-memory HSQLDB instance:

Start the DB in the “remote open db” mode.This is driven by the “server.remote_open” property that is false by default (you can look to the code of org.hsqldb.server.ServerProperties class to see other properties that might be interesting). The code that starts a dataabse instacne in remote open mode will look something like:

HsqlProperties props = new HsqlProperties();
props.setProperty("server.remote_open", true);
....add more properties here
Server server = new Server();
server.setProperties(props);
server.start();

Connect to the data base instance. Now that the database has started the next step is to connect to data base instance. Because we started an in-memory instance the connection url is a memory database url that looks like jdbc:hsqldb:mem:instanceName You will not be able to connect using this url because neither the host and the port are available, instead you should use a server database url that looks like jdbc:hsqldb:hsql://host:port/instanceName