use case use case testing complete tutorial
Per començar, entenem-ho 'Què és el cas d'ús?' i més endavant en parlarem 'Què és la prova de casos d'ús?' .
Un cas d'ús és una eina per definir la interacció necessària de l'usuari. Si intenteu crear una aplicació nova o fer canvis a una aplicació existent, es fan diverses discussions. Un dels debats crítics que heu de fer és com representareu el requisit de la solució de programari.
Els experts i desenvolupadors d’empreses han de tenir un coneixement mutu sobre el requisit, ja que és molt difícil d’assolir. Qualsevol mètode estàndard per estructurar la comunicació entre ells serà realment una gran ajuda. Al seu torn, reduirà les males comunicacions i aquí és el lloc on apareix el cas d’ús.
Aquest tutorial us proporcionarà una imatge clara sobre el concepte de casos d’ús i proves, cobrint així els diversos aspectes que hi intervenen amb exemples pràctics per facilitar la comprensió de qualsevol persona que sigui completament nova.
Què aprendreu:
- Cas d'ús
- Qui utilitza els documents 'Cas d'ús'?
- Tipus de casos d’ús
- Elements en casos d’ús
- Representació
- Com escriure un cas d'ús?
- Utilitzeu el diagrama de casos
- Accions de l'usuari
- Què és la prova de casos d'ús?
- Conclusió
- Lectura recomanada
Cas d'ús
L’ús de casos té un paper important en les diferents fases del cicle de vida del desenvolupament de programari. El cas d’ús depèn de “Accions de l’usuari” i de “Resposta del sistema” a les accions de l’usuari.
És la documentació de les 'accions' realitzades per l'actor / usuari i el 'comportament' corresponent del sistema a les 'accions' de l'usuari. Casos d’ús pot resultar o no en l’assoliment d’un objectiu de l’actor i usuari sobre les interaccions amb el sistema.
En el cas d’ús, el descriurem 'Com respondrà un sistema a un determinat escenari?' . Està 'orientat a l'usuari' i no 'orientat al sistema'.
Està 'orientat a l'usuari': Especificarem 'quines són les accions realitzades per l'usuari?' I 'Què veuen els actors en un sistema?'.
No està 'orientat al sistema': No especificarem 'Quines són les dades que es donen al sistema?' I 'Quines són les sortides produïdes pel sistema?'.
L’equip de desenvolupament ha d’escriure els ‘casos d’ús’, ja que en depèn molt la fase de desenvolupament.
L'ús de casos d'ús, els membres de l'equip i els clients contribuiran a la creació d'aquests casos. Per crear-los, hem de reunir un equip de desenvolupament i l’equip hauria de ser molt conscient dels conceptes del projecte.
Després d’implementar el cas, es prova el document i es comprova el comportament del sistema en conseqüència. En un cas, la majúscula 'A' indica 'Actor', la lletra 'S' indica 'Sistema'.
Qui utilitza els documents 'Cas d'ús'?
Aquesta documentació proporciona una visió completa de les diferents maneres en què l'usuari interactua amb un sistema per assolir l'objectiu. Una millor documentació pot ajudar a identificar el requisit d’un sistema de programari d’una manera molt més senzilla.
Aquesta documentació la poden utilitzar desenvolupadors de programari, verificadors de programari i grups d'interès.
Usos dels documents:
- Els desenvolupadors utilitzen els documents per implementar i dissenyar el codi.
- Els provadors els utilitzen per crear el fitxer casos de prova .
- Els grups d'interès empresarials utilitzen el document per entendre els requisits del programari.
Tipus de casos d’ús
N’hi ha de 2 tipus.
Ells són:
- Dia assolellat
- Dia plujós
# 1) Casos d'ús de dia assolellat
Són els casos principals que tenen més probabilitats de passar quan tot funciona bé. Aquests tenen una alta prioritat que els altres casos. Un cop hàgim completat els casos, el lliurem a l'equip del projecte perquè el revisi i assegurem que hem cobert tots els casos requerits.
java com crear una matriu d'objectes
# 2) Casos d'ús del dia de pluja
Es poden definir com la llista de casos de vora. La prioritat d’aquests casos vindrà després dels 'casos d’ús assolellats'. Podem demanar ajuda a les parts interessades i als gestors de productes per prioritzar els casos.
Elements en casos d’ús
A continuació es detallen els diversos elements:
1) Breu descripció : Una breu descripció que explica el cas.
2) Actor : Usuaris que participen en accions de casos d'ús.
3) Condició prèvia : Condicions a satisfer abans que comenci el cas.
4) Bàsica Flux : 'Flux bàsic' o 'Escenari principal' és el flux de treball normal del sistema. És el flux de transaccions realitzades pels actors en assolir els seus objectius. Quan els actors interactuen amb el sistema, ja que és el flux de treball normal, no hi haurà cap error i els actors obtindran la producció esperada.
5) Alternar flux : A part del flux de treball normal, un sistema també pot tenir un 'flux de treball alternatiu'. Aquesta és la interacció menys habitual que fa un usuari amb el sistema.
6) Excepció flux : El flux que impedeix que un usuari assoleixi l'objectiu.
7) Publicació Condicions : Les condicions que cal revisar després de completar el cas.
Representació
Un cas es representa sovint en un text pla o en un diagrama. A causa de la senzillesa del diagrama de casos d’ús, qualsevol organització considera que és opcional
Exemple de cas d'ús:
Aquí explicaré el cas de 'Inici de sessió' en un 'Sistema de gestió escolar'.
| Utilitzeu el nom del cas | iniciar Sessió | |
|---|---|---|
| 3b | L'identificador d'estudiant no vàlid s'ha introduït 4 vegades. S: L’aplicació tanca | |
| Descripció del cas d’ús | Un usuari que inicia sessió al sistema per accedir a la funcionalitat del sistema. | |
| Actors | Pares, estudiants, professor, administrador | |
| Condició prèvia | El sistema ha d’estar connectat a la xarxa. | |
| Post-Condició | Després d'un inici de sessió correcte, s'envia un correu de notificació a l'identificador de correu de l'usuari |
| Escenaris principals | serial No | Passos |
|---|---|---|
| Actors / Usuaris | 1 | Introduïu el nom d'usuari Introduir la contrasenya |
| 2 | Valideu el nom d’usuari i la contrasenya | |
| 3 | Permet l'accés al sistema | |
| Extensions | 1a | Nom d'usuari no vàlid El sistema mostra un missatge d'error |
| 2b | contrasenya invàlida El sistema mostra un missatge d'error | |
| 3c | La contrasenya no és vàlida durant 4 vegades Sol·licitud tancada |
Punts a destacar
- Els errors més freqüents que fan els participants amb el cas d’ús és que o bé conté massa detalls sobre un cas concret o no en té prou.
- Aquests són models textuals, si cal, podem afegir-hi o no un diagrama visual.
- Determineu la condició prèvia aplicable.
- Escriviu els passos del procés en l’ordre correcte.
- Especifiqueu els requisits de qualitat per al procés.
Com escriure un cas d'ús?
Els punts que es resumeixen a continuació us ajudaran a escriure aquests:
=> Quan intentem escriure un cas, la primera pregunta que hauríem de plantejar-nos és 'Quin és l'ús principal del client?' Aquesta pregunta us farà escriure els vostres casos des de la perspectiva de l'usuari.
=> Hem d’haver obtingut una plantilla per a aquests.
=> Ha de ser productiu, senzill i fort. Un cas d’ús fort pot impressionar el públic encara que tingui errors menors.
=> L’hauríem de numerar.
=> Hauríem d’escriure el pas del procés al seu ordre.
=> Poseu un nom propi als escenaris, el nom s’ha de fer segons la finalitat.
=> Aquest és un procés iteratiu, que significa que quan els escriviu per primera vegada no serà perfecte.
=> Identifiqueu els actors del sistema. És possible que trobeu un munt d’actors al sistema.
Exemple ,si teniu en compte un lloc de comerç electrònic com Amazon, hi podem trobar actors com compradors, venedors, comerciants majoristes, auditors, proveïdors, distribuïdors, atenció al client, etc.
Inicialment, considerem els primers actors. Podem tenir més d’un actor amb el mateix comportament.
Per exemple , tant el comprador com el venedor poden 'crear un compte'. De la mateixa manera, tant 'Comprador com Venedor' poden 'Cercar article'. Per tant, es tracta de comportaments duplicats i que s’han d’eliminar. A part d’utilitzar els casos duplicats, hem de tenir casos més generals. Per tant, hem de generalitzar els casos per evitar duplicacions.
=> Hem de determinar la condició prèvia aplicable.
Utilitzeu el diagrama de casos
El diagrama de casos d’ús és una representació pictòrica de les accions d’un usuari en un sistema. Proporciona una gran eina en aquest context, si el diagrama conté molts actors, és molt fàcil d’entendre. Si es tracta d’un diagrama d’alt nivell, no compartirà molts detalls. Mostra idees complexes d’una manera bastant bàsica.
Fig núm: UC 01
Com es mostra a Fig núm: UC 01 representa un diagrama on el Rectangle representa un 'Sistema', l'oval representa un 'Cas d'ús', la Fletxa representa una 'Relació' i l'home representa un 'Usuari / Actor'. Mostra un sistema / aplicació, mostra l'organització / persones que hi interactuen i mostra el flux bàsic de 'Què fa el sistema?'
Fig núm: UC 02
Fig núm: UC 03: diagrama de casos d'ús per iniciar la sessió
Aquest és el diagrama de casos d'ús del cas 'Inici de sessió'. Aquí tenim més d’un actor, tots estan situats fora del sistema. Es considera que els estudiants, els professors i els pares són els actors principals. Per això, es col·loquen tots a la part esquerra del rectangle.
L’administrador i el personal es consideren actors secundaris, de manera que els situem al costat dret del rectangle. Els actors poden iniciar sessió al sistema, de manera que connectem els actors i el cas d'inici de sessió amb un connector.
Altres funcions del sistema són Restablir contrasenya i Contrasenya oblidada. Tots estan relacionats amb el cas d'inici de sessió, de manera que els connectem al connector.
Accions de l'usuari
Aquestes són les accions que fa l'usuari en un sistema.
Per exemple: Cerqueu in situ, afegiu un element als preferits, intenteu contactar-vos, etc.
Nota:
- Un sistema és 'el que estigueu desenvolupant'. Pot ser un lloc web, una aplicació o qualsevol altre component de programari. Generalment es representa per un rectangle. Conté casos d’ús. Els usuaris es situen fora del 'rectangle'.
- Casos d’ús generalment es representen mitjançant formes ovals que especifiquen les accions al seu interior.
- Actors / Usuaris són les persones que fan servir el sistema. Però, de vegades, poden ser altres sistemes, persones o qualsevol altra organització.
Què és la prova de casos d'ús?
Es troba sota la tècnica de proves de la caixa negra funcional. Com que es tracta d'una prova de caixa negra, no hi haurà cap inspecció dels codis. En aquesta secció es detallen diversos fets interessants al respecte.
Assegura si el camí utilitzat per l'usuari funciona o no tal com es volia. Assegura que l'usuari pot realitzar la tasca amb èxit.
Alguns fets
- No es realitzen proves per decidir la qualitat del programari.
- Fins i tot si es tracta d’un tipus de proves de punta a punta, no garantirà la cobertura completa de l’aplicació de l’usuari.
- Basant-nos en el resultat de la prova conegut per les proves de casos d’ús, no podem decidir el desplegament de l’entorn de producció.
- Esbrinarà els defectes de les proves d’integració.
Exemple de prova de casos d'ús:
Penseu en un cas en què un usuari compri un article des d’un lloc de compres en línia. L’usuari primer iniciarà sessió al sistema i començarà a realitzar una cerca. L’usuari seleccionarà un o més articles que es mostren als resultats de la cerca i els afegirà al carretó.
Després de tot això, ho comprovarà. Per tant, aquest és un exemple de sèries de passos connectats lògicament que l'usuari realitzarà en un sistema per realitzar la tasca.
En aquesta prova es prova el flux de transaccions a tot el sistema de punta a punta. Els casos d’ús solen ser el camí que és més probable que utilitzen els usuaris per assolir una tasca específica.
Per tant, això fa que els casos d’ús siguin fàcils de trobar els defectes, ja que inclou el camí amb què és més probable que es trobin els usuaris quan l’usuari utilitza l’aplicació per primera vegada.
Pas 1: El primer pas és la revisió de documents de casos d’ús.
Hem de revisar i assegurar-nos que els requisits funcionals són complets i correctes.
Pas 2: Hem d’assegurar-nos que els casos d’ús siguin atòmics.
Per exemple: Penseu en un 'Sistema de gestió escolar que tingui moltes funcionalitats com' Inici de sessió ',' Mostra els detalls de l'estudiant ',' Mostra les marques ',' Mostra l'assistència ',' Contacteu amb el personal ',' Envieu les tarifes ', etc. En aquest cas, estem intentant prepareu els casos d'ús per a la funcionalitat 'Inici de sessió'.
Hem d’assegurar-nos que cap de les necessitats normals del flux de treball s’hagi de barrejar amb cap altra funcionalitat. Ha d'estar totalment relacionat només amb la funcionalitat 'Inici de sessió'.
Pas 3: Hem d’inspeccionar el flux de treball normal del sistema.
Després d’inspeccionar el flux de treball, hem de garantir que estigui complet. Basant-nos en el coneixement del sistema o fins i tot del domini, podem conèixer els passos que falten al flux de treball.
Pas 4: Assegureu-vos que el flux de treball alternatiu del sistema s'ha completat.
Pas 5: Ens hem d’assegurar que cada pas del cas d’ús es pugui comprovar.
Cada pas explicat a la prova del cas d’ús es pot comprovar.
Per exemple, algunes transaccions amb targeta de crèdit al sistema no es poden provar per motius de seguretat.
Pas 6: Un cop recuperats aquests casos, podem escriure els casos de prova.
Hem d’escriure casos de prova per a cada flux normal i altern.
Per exemple , Tingueu en compte el cas 'Mostra les marques dels estudiants', en un sistema de gestió escolar.
Nom del cas d'ús: Mostra les marques dels estudiants
Actors: Estudiants, professors, pares i mares
Condició prèvia:
1) El sistema ha d’estar connectat a la xarxa.
2) Els actors han de tenir un «DNI d’estudiant».
Cas d'ús per a 'Mostra les marques dels estudiants':
| Escenari principal | Número de sèrie | Passos |
|---|---|---|
| A: Actor / S: Sistema | 1 | Introduïu el nom de l'estudiant |
| 2 | El sistema valida el nom de l’alumne | |
| 3 | Introduïu l’identificador d’estudiant | |
| 4 | El sistema valida l’identificador d’estudiant | |
| 5 | El sistema mostra les marques dels estudiants | |
| Extensions | 3a | Identificador d'estudiant no vàlid S: mostra un missatge d'error |
Cas de prova corresponent per al cas 'Mostra les marques dels estudiants':
| Casos de prova | Passos | Resultat Esperat |
|---|---|---|
| A | Veure la llista de notes d'estudiants 1 -Flux normal | |
| 1 | Introduïu el nom de l'estudiant | L'usuari pot introduir el nom de l'estudiant |
| 2 | Introduïu l’identificador d’estudiant | L’usuari pot introduir l’identificador d’estudiant |
| 3 | Feu clic a Veure marca | El sistema mostra les marques dels estudiants |
| B | Mostra la llista de marques d'estudiants 2: identificador no vàlid | |
|---|---|---|
| 1 | Repetiu els passos 1 i 2 de Visualització de la llista de notes d’alumnes 1 | |
| 2 | Introduïu l’identificador d’estudiant | El sistema mostra un missatge d'error |
Tingueu en compte que la taula de casos de prova que es mostra aquí només conté la informació bàsica. A continuació s’explica detalladament com es crea la plantilla de casos de prova.
A la taula es mostra el 'cas de prova' corresponent al cas 'Mostra la nota dels estudiants', tal com es mostra més amunt.
La millor manera d’escriure casos de prova és escriure primer els casos de prova per a “l’escenari principal” i després escriure’ls per a “passos alternatius”. El ‘ Passos a casos de prova s'obtenen de documents de casos d'ús. El primer ‘ Pas ' del cas 'Mostra la marca de l'alumne', 'Introduïu el nom de l'alumne' es convertirà en el primer Pas al «cas de prova».
L'usuari / actor ha de poder entrar-hi. Això es converteix en el Resultat Esperat .
Podem buscar l’ajut de tècniques de disseny de proves com ara anàlisi del valor límit » , 'Particionament d'equivalència' mentre preparem els casos de prova. La tècnica de disseny de la prova ajudarà a reduir el nombre de casos de prova i, per tant, a reduir el temps de prova.
Com es crea una plantilla de cas de prova?
Quan estem preparant els casos de prova, hem de pensar i actuar com l’usuari final, és a dir, posar-se a la pell d’un usuari final.
Hi ha diverses eines disponibles al mercat per ajudar en aquest context. ' TestLodge ’n’és un, però no és una eina gratuïta. L’hem de comprar.
Necessitem una plantilla per documentar el cas de prova. Considerem un escenari comú, 'Inici de sessió de FLIPKART', que tots coneixem. El full de càlcul de Google es pot utilitzar per crear la taula de casos de proves i compartir-la amb els membres de l'equip. De moment, faig servir un document Excel.
Aquí teniu un exemple
=> DESCARREGUEU aquí aquesta plantilla de taula de casos de prova
Primer de tot, assigneu un nom adequat al full de casos de prova. Estem escrivint casos de prova per a un mòdul concret d’un projecte. Per tant, hem d’afegir el fitxer 'Nom del projecte' i la ‘Mòdul de projecte ’Columnes de la taula de casos de prova. El document ha d'incloure el nom del creador dels casos de prova.
Per tant, afegiu 'Creat per' i 'Data de creació' columnes. Algú ha de revisar el document (cap d’equip, cap de projecte, etc.), així que afegiu-lo 'Revisat per' columna i 'Data de revisió' .
La següent columna és 'Escenari de prova' , aquí hem proporcionat l'escenari de prova d'exemple 'Verifica l'inici de sessió de Facebook' . Afegiu les columnes 'Identificador d'escenari de prova' i 'Descripció del cas de prova' .
Escriurem per a cada escenari de prova ‘Casos de prova ’. Per tant, afegiu les columnes 'Identificador de cas de prova' i ‘Descripció del cas de prova ’. Per a cada escenari de prova, n’hi haurà 'Condició posterior' i 'Condició prèvia' . Afegiu les columnes 'Condició posterior' i 'Condició prèvia'.
Una altra columna important és 'Dades de prova' . Contindrà les dades que fem servir per fer proves. Un escenari de prova ha d'assumir un resultat esperat i el resultat real. Afegiu la columna 'Resultat Esperat' i 'Resultat real'. 'Estat' mostra el resultat de l'execució de l'escenari de prova. Pot ser passar / fallar.
Els verificadors executaran els casos de prova. L’hem d’incloure com a 'Executat per' i 'Data d'execució' . Afegirem 'Ordres' si n'hi ha.
Conclusió
Espero que tingueu una idea clara sobre casos d’ús i proves de casos d’ús.
Escriure aquests casos és un procés iteratiu. Només necessiteu poca pràctica i un bon coneixement d’un sistema per escriure aquests casos.
En poques paraules, podem utilitzar 'Prova de casos d'ús' en una aplicació per trobar els enllaços que falten, els requisits incomplets, etc. Si els trobeu i modifiqueu el sistema, obtindreu eficiència i precisió al sistema.
Teniu experiències anteriors amb casos d’ús i proves? No dubteu a compartir amb nosaltres a la secció de comentaris següent.
Lectura recomanada
- Proves funcionals contra proves no funcionals
- Tutorials Eclipse en profunditat per a principiants
- Proves alfa i proves beta (guia completa)
- Tutorial de proves DevOps: com impactarà DevOps en les proves de control de qualitat?
- Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
- Tutorial de proves d'usabilitat: una guia d'introducció completa
- Tutorial de proves de la GUI: una guia completa de proves de la interfície d'usuari (UI)
- Tutorial de proves destructives i proves no destructives