In veel van de hedendaagse applicaties kunnen meerdere gebruikers de applicatie op hetzelfde moment gebruiken. Het kan dan gebeuren dat meerdere gebruikers tegelijk dezelfde data willen bewerken. Dit wordt ook wel aangeduid met multi concurrency.

Bij het ontwikkelen van de software moet hier rekening mee gehouden worden. Het kan namelijk gebeuren dat de data die uit de database is opgehaald en getoond op het scherm even later niet meer aanwezig is in de database omdat een andere gebruiker de gegevens heeft verwijderd.

Concurrent gebruik van data en de mogelijke problemen die zich daarbij voordoen is op zich een bekend probleem. Voor een tester met weinig technische kennis of ervaring is het belangrijk deze problematiek te kunnen plaatsen. Dit inzicht helpt om een betere inschatting te kunnen doen over wat en hoe er getest moet worden.

Een van de problemen die kan ontstaan wordt hierna uitgelegd met behulp van een voorbeeld.

Nu kun je denken dat dit een situatie is die zeer waarschijnlijk niet gaat voorkomen in de praktijk. En de kans dat je gelijk hebt is zeer groot, echter geen 100%.

En “Big Business” zal ontevreden zijn mocht het onverhoopt toch gebeuren. In de praktijk zul je dan ook zien dat dit potentiële probleem in de software wordt opgelost.

De hiervoor geschetste situatie doet zich alleen voor als beide users exact dezelfde data te zien krijgen en dat alle data opnieuw wordt opgeslagen ook al is een deel van de data niet gewijzigd.

Voor het testen van concurrent gebruik moet een tester de gekozen technische oplossing kennen om de juiste testgevallen te kunnen opstellen.

Mogelijke oplossingen

Hierna worden een aantal oplossingen beschreven. Daarbij wordt tevens aangegeven hoe dit te testen.

Niets doen

In de hoop dat het probleem zich niet zal voordoen, wordt er in de software geen oplossing geïmplementeerd. Dit kan een heel bewuste keuze zijn omdat het gebruik van de applicatie zich daar voor leent. Neem bijvoorbeeld een applicatie waarmee je je eigen adresgegevens kunt wijzigen. De kans dat je als gebruiker dat op twee verschillende plekken op hetzelfde moment doet is erg klein.

Moet het dan wel getest worden?

In dit geval hoeft er niet zoveel getest te worden. Wel is het verstandig om aan te tonen dat daadwerkelijk de wijzigen van de gebruiker die als laatste op de “Opslaan” button heeft geklikt zijn opgeslagen.

Locking

Een veel gebruikte oplossing is locking. Bij deze aanpak worden gegevens die worden opgehaald uit de database, om waarschijnlijk te worden aangepast, gelocked. Het database manangement systeem (DBMS) zorgt er dan voor dat andere processen de betreffende gegevens niet kunnen ophalen om te wijzigen.

Mogelijke problemen met gebruik van locking

Niet alle DBMS’en ondersteunen locking op record niveau. Sommige ondersteunen page locking. Bij dit concept wordt er een groter deel (bijvoorbeeld 4KB) van data gelocked. In ons voorbeeld van “Big Business”, kan er dus ook van andere klanten gegevens gelocked worden. Er zijn ook DBMS’en die de gehele tabel locken. En dan kunnen de gegevens van geen enkele klant worden gewijzigd. En dan zijn er ook DBMS’en die helemaal geen locking ondersteunen.

In geval er een record gelocked is zal het DBMS wachten tot het proces dat de lock heeft geplaatst is afgerond of zal na x tijd een “time-out” geven. In de eerste situatie kan het wachten lang duren. Neem het voorbeeld van “Big Business” waarbij de servicedesk medewerker een telefoontje tussendoor krijgt. De binnendienst medewerker zal dan moeten wachten en kan dan geen andere acties uit voeren met de applicatie. In de tweede situatie kan de applicatie op het moment dat de “time-out” wordt gegeven, een melding geven aan de gebruiker dat de gegevens tijdelijk niet beschikbaar zijn. De periode waarna een “time-out” wordt gegeven kan in de regel in de configuratie van het DBMS worden opgegeven. Het is voor testen van belang om te weten voor hoeveel seconden de time-out is ingesteld.

Hoe dit testen

Situatie 1
Dit kan getest worden door gebruiker 1 zijn handelingen af te laten ronden, nadat gebruiker 2 de gegevens heeft opgevraagd. Het tonen van de gegevens voor gebruiker 2 zal pas uitgevoerd worden nadat gebruiker 1 zijn handelingen heeft afgerond. Gebruiker 2 dient in dit geval de door gebruiker 1 gewijzigde gegevens te zien.

Situatie 2
Dit kan getest worden door gebruiker 1 zijn handelingen niet af te laten ronden. Gebruiker 2 wacht tot het moment dat er een melding wordt gegeven door de applicatie dat de gegevens tijdelijk niet beschikbaar zijn. Gebruiker 1 handelt daarna zijn werkzaamheden af. Vervolgens voert gebruiker 2 zijn handelingen opnieuw uit en dient dan de door gebruiker 1 gewijzigde gegevens te zien.

Bij het gebruik van locking is het ook noodzakelijk dat er gedurende de lock de verbinding met het DBMS wordt behouden. Dit is niet altijd makkelijk te realiseren voor web applicaties die gebruik maken van het stateless HTTP protocol.

Lezen voor wegschrijven

Bij dit concept worden de opgehaalde gegevens tijdelijk ergens opgeslagen. Dit wordt ook wel aangeduid als de “before” image van de gegevens. Als de gebruiker de gegevens heeft gewijzigd worden deze ook apart opgeslagen. Dit wordt ook wel de “new” image genoemd. Voordat de gegevens worden opgeslagen in de database wordt de huidige (“current”) situatie van de gegevens uit de database opgehaald. De “current” situatie wordt vervolgens vergeleken met de “before” situatie. Wanneer er een verschil is, betekent dit dat de gegevens ondertussen door een andere gebruiker zijn gewijzigd. De applicatie zal dan de “new” situatie van de gegevens niet opslaan en een melding teruggeven aan de gebruiker dat de gegevens zijn aangepast nadat de gegevens door de gebruiker zijn opgehaald. De gebruiker zal de wijzigingen opnieuw moeten doorvoeren, maar dan op de meest actuele situatie.

Hoe dit te testen

Om dit te testen zijn er 2 testers nodig of moet je als tester 2 keer kunnen inloggen met verschillende accounts. Dit kan bijvoorbeeld op 2 verschillende computers of in 2 verschillende browsers. Daarna dient het volgende scenario in de juiste volgorde te worden uitgevoerd:

1. User 1 vraagt gegevens op om te wijzigen
2. User 2 vraagt exact dezelfde gegevens op om te wijzigen.
3. User 2 voert de wijzigingen door en slaat de gegevens op.
4. User 1 voert de wijzigingen door en wil de gegevens opslaan. Het systeem dient vervolgens een melding te geven dat er actuelere gegevens zijn. De wijzigingen van User 1 worden niet opgeslagen.
5. Er dient vervolgens middels raadplegen gecontroleerd te worden dat de wijzigingen van User 1 daadwerkelijk niet zijn doorgevoerd en die van User 2 wel. Dit kan ook door de gegevens in de database te controleren.

Gebruik van Timestamping

Bij deze methode bevat ieder record in de database een “last modified date/time” veld. De waarde van dit veld wordt aangepast wanneer er een wijziging wordt opgeslagen of wanneer nieuwe gegevens worden toegevoegd. Dit principe werkt eigenlijk hetzelfde als “lezen voor wegschrijven”. Het verschil is dat nu alleen de timestamp wordt bewaard als “before” en niet alle gegevens. Wanneer de gebruiker gegevens wijzigt en wil opslaan zal het systeem de “before” timestamp vergeleken met de actuele timestamp in de database. Is deze gelijk dan kunnen de gegevens worden opgeslagen. Zijn ze verschillend dan zijn er ondertussen door een andere user wijzigingen aangebracht. Het systeem zal dan een melding geven dat er actuelere gegevens zijn en dat de gebruiker de wijzigingen opnieuw moet verwerken.

Hoe dit te testen

Het testen kan op dezelfde manier gebeuren als beschreven bij “Lezen voor wegschrijven”

Samenvatting

Wanneer je betrokken bent bij het testen van een applicatie waarbij concurrent gebruik van data mogelijk is, is het voor het testen van belang om te weten welke oplossing is gekozen voor de multi concurrency problematiek.

Er zijn meer oplossingen mogelijk dan in dit artikel beschreven. Overleg dus goed met de developers over de oplossing en bedenk vervolgens de juiste teststrategie om het te testen.