Uitleg over het begrip data concurrency

testen van multi userIn 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.

Voorbeeld
Stel er is een web applicatie ontwikkeld waarmee klantgegevens kunnen worden onderhouden. Daarbij zijn de adresgegevens, telefoonnummer en kortingspercentage vastgelegd in een (1) tabel in de database.

Bij het niet juist implementeren van concurrent gebruik kan het volgende scenario zich voor doen:
De klant “Big Business” is sterk aan het groeien en gaat verhuizen naar een ander adres, daarnaast is er besloten de klant een hogere volume korting te geven.

Op de servicedesk komt er een mail binnen met de adres wijziging. Een servicedesk medewerker gebruikt de applicatie om de klantgegevens te raadplegen en vervolgens de adresgegevens te wijzigen. Nadat de klantgegevens zijn gevonden en getoond (inclusief de kortingscode) op het scherm, krijgt de servicedesk medewerker een telefoontje. De medewerker is op dat moment nog niet in de gelegenheid geweest de gegevens aan te passen en op te slaan.

Gedurende het telefoongesprek van de servicedesk medewerker, gaat een medewerker van de commerciële binnendienst de gegevens van “Big Business” opvragen om de volume korting aan te passen. Stel dat het kortingspercentage 15% is en dat de binnendienst medewerker een nieuw percentage van 20% intikt. Vervolgens klikt de binnendienst medewerker op “opslaan” en worden de gegevens opgeslagen in de database. Tot nu toe is er niets verkeerd gegaan.

De servicedesk medewerker rond ondertussen het telefoongesprek af en handelt vervolgens de adreswijziging van “Big Business” af. De adresgegevens worden gewijzigd en vervolgens wordt er op de “opslaan” button geklikt. De applicatie slaat niet alleen het nieuwe adres op, maar alle gegevens uit dezelfde tabel. Dat is dus inclusief het oude kortingspercentage van 15%. Deze tweede update overschrijft derhalve het gewijzigde kortingspercentage.

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.

Ook interessant?

dataconversie

Wat is dataconversie?

Een onderdeel van Datamigratie is Dataconversie. Dit is de conversie van data van het ene formaat naar een ander data ...
Meer Lezen
data driven testen

Data driven testen

Data driven testen, wat is dat nu eigenlijk? Helaas is hierop geen eenduidig antwoord te geven. Er worden door verschillende ...
Meer Lezen
Integratietesten

Wat is integratietesten?

Doelstelling De integratietest heeft als doel om te bepalen of de verschillende modules, systemen of applicaties onderling correct gegevens kunnen ...
Meer Lezen
Functioneel testen

Functioneel testen

De requirements die gesteld worden aan software kunnen worden onderverdeeld in functionele en niet-functionele eisen. Functioneel testen richt zich op het ...
Meer Lezen
Blijf op de hoogte van onze nieuwste ontwikkelingen, schrijf je hier in voor de nieuwsbrief!