what is system testing ultimate beginner s guide
Què és la prova de sistemes en proves de programari?
La prova del sistema significa provar el sistema en general. Tots els mòduls / components s’integren per tal de verificar si el sistema funciona o no com s’esperava.
La prova del sistema es realitza després de la prova d’integració. Això té un paper important a l’hora de lliurar un producte d’alta qualitat.
Llista de tutorials:
El procés de provar un sistema integrat de maquinari i programari per verificar que el sistema compleix els requisits especificats.
Verificació : Confirmació per examen i aportació de proves objectives que han complert els requisits especificats.
Si una aplicació té tres mòduls A, B i C, les proves realitzades combinant els mòduls A & B o el mòdul B & C o el mòdul A & C es coneix com a proves d’integració. Integrar els tres mòduls i provar-lo com un sistema complet s’anomena prova del sistema.
Què aprendreu:
- La meva experiència
- Aproximació
- Per què les proves del sistema?
- Es tracta d'una prova de caixa blanca o de caixa negra?
- Com es realitza la prova del sistema?
- Avantatges
- Criteris d’entrada / sortida
- Pla de proves del sistema
- Procediment per escriure casos de prova del sistema
- Casos de prova del sistema
- Tipus de proves de sistemes
- Què és la prova d'integració de sistemes?
- Diferència entre el sistema i les proves d'acceptació
- Consells per realitzar la prova del sistema
- Conclusió
- Lectura recomanada
La meva experiència
Així que ... de debò creieu que trigarà una quantitat enorme de temps a provar, el que anomeneu Proves del sistema , fins i tot després d’haver dedicat molts esforços a les proves d’integració?
El client al qual ens vam apropar recentment per al projecte no estava convençut de l’estimació que proporcionàvem per a cada esforç de prova.
Vaig haver de tocar amb un exemple:
Mike, m'agradaria aprofundir en els nostres esforços i la importància de provar el sistema amb un exemple.
Dispara, va respondre.
Exemple de prova del sistema
Un fabricant de cotxes no produeix el cotxe com un cotxe sencer. Cada component del cotxe es fabrica per separat, com ara seients, direcció, mirall, trencament, cable, motor, bastidor del cotxe, rodes, etc.
Després de fabricar cada article, es prova independentment si funciona com s’ha de treballar i s’anomena prova d’unitat.
Proves de programari preguntes i respostes d'entrevistes de comportament
Ara, quan cada part es munta amb una altra part, es comprova aquesta combinació muntada si el muntatge no ha produït cap efecte secundari sobre la funcionalitat de cada component i si ambdós components funcionen junts com s’esperava i això s’anomena proves d’integració.
Un cop muntades totes les peces i el cotxe llest, en realitat no estarà llest.
Cal comprovar que el cotxe sencer tingui diferents aspectes segons els requisits definits, com ara si el cotxe es pot conduir sense problemes, es trenca, engranatges i altres funcions que funcionen correctament. generalment s’accepta i agrada el cotxe, es pot conduir per qualsevol tipus de carreteres, com per ser suaus i accidentades, descuidades i rectes, etc. Tot aquest esforç de proves s’anomena Prova de sistema i no té res a veure amb les proves d’integració.
L'exemple va funcionar tal com s'esperava i el client estava convençut dels esforços necessaris per a la prova del sistema.
He narrat l'exemple aquí per fomentar la importància d'aquestes proves.
Aproximació
Es realitza quan es completen les proves d’integració.
Es tracta principalment d’una prova de tipus Black-box. Aquesta prova avalua el funcionament del sistema des del punt de vista de l'usuari, amb l'ajut d'un document d'especificacions. No requereix cap coneixement intern de sistemes com el disseny o l'estructura del codi.
Conté àrees d’aplicació / producte funcionals i no funcionals.
Criteris d’enfocament:
Se centra principalment en el següent:
- Interfícies externes
- Funcionalitats complexes i multiprogrames
- Seguretat
- Recuperació
- Rendiment
- Interacció fluida de l’operador i l’usuari amb el sistema
- Instal·labilitat
- Documentació
- Usabilitat
- Càrrega / estrès
Per què les proves del sistema?
# 1) És molt important completar un cicle complet de proves i ST és l'etapa on es fa.
# 2) La ST es realitza en un entorn similar a l’entorn de producció i, per tant, les parts interessades poden tenir una bona idea de la reacció de l’usuari.
# 3) Ajuda a minimitzar la resolució de problemes posteriors al desplegament i les trucades d'assistència.
# 4 ) En aquesta etapa de STLC, es requereixen arquitectura d'aplicacions i requisits empresarials.
Aquestes proves són molt importants i juguen un paper important en el lliurament d’un producte de qualitat al client.
Vegem la importància d’aquestes proves a través dels exemples següents que inclouen les nostres tasques del dia a dia:
- Què passa si una transacció en línia falla després de la confirmació?
- Què passa si un article col·locat al carretó d’un lloc en línia no permet fer una comanda?
- Què passa si un compte de Gmail crea una etiqueta nova dóna un error en fer clic a la pestanya Crea?
- Què passa si el sistema es bloqueja quan augmenta la càrrega al sistema?
- Què passa si el sistema es bloqueja i no és capaç de recuperar les dades com es desitgi?
- Què passa si instal·lar programari al sistema triga molt més temps del previst i al final produeix un error?
- Què passa si un temps de resposta del lloc web augmenta molt més del previst després de la millora?
- Què passa si un lloc web es fa massa lent que l'usuari no pot reservar el seu bitllet de viatge?
A continuació, es mostren alguns exemples que mostren com afectaria la prova del sistema si no es fa de manera adequada.
Tots els exemples anteriors són només el resultat de les proves del sistema no realitzades o no realitzades correctament. S'haurien de provar tots els mòduls integrats per garantir que el producte funcioni segons els requisits.
Es tracta d'una prova de caixa blanca o de caixa negra?
La prova del sistema es pot considerar com una tècnica de prova de caixa negra.
Proves de caixa negra la tècnica no requereix coneixement intern del codi mentre que la tècnica de la caixa blanca requereix coneixement intern del codi.
Mentre es realitzen les proves del sistema funcionals i no funcionals, es cobreixen la seguretat, el rendiment i molts altres tipus de proves i es proven mitjançant una tècnica de caixa negra on es proporciona l'entrada al sistema i es verifica la sortida. No es requereix coneixement intern del sistema.
Tècnica de la caixa negra:
Com es realitza la prova del sistema?
Bàsicament és una part de les proves de programari i el pla de proves sempre ha de contenir espai específic per a aquesta prova.
Per provar el sistema en general, els requisits i les expectatives haurien de ser clars i el comprovador també ha d’entendre l’ús en temps real de l’aplicació.
A més, les eines de tercers més utilitzades, les versions dels sistemes operatius, els formats i l'arquitectura dels sistemes operatius poden afectar la funcionalitat, el rendiment, la seguretat, la recuperabilitat o la instal·labilitat del sistema.
Per tant, mentre proveu el sistema, pot ser útil una imatge clara de com s’utilitzarà l’aplicació i quin tipus de problemes pot afrontar en temps real. A més, un document de requisits és tan important com entendre l’aplicació.
El document de requisits clar i actualitzat pot salvar el provador de diversos malentesos, suposicions i preguntes.
En resum, un document de requisits acurat i nítid amb les darreres actualitzacions juntament amb una comprensió de l’ús de l’aplicació en temps real pot fer que ST sigui més fructífer.
Aquestes proves es fan de manera planificada i sistemàtica.
A continuació es detallen els diferents passos que s’han de dur a terme durant la prova:
- El primer pas és crear un pla de proves.
- Creeu casos de prova del sistema i scripts de prova.
- Prepareu les dades de prova necessàries per a aquesta prova.
- Executeu els casos i l'script de prova del sistema.
- Informeu dels errors. Torneu a provar els errors un cop solucionats.
- Proves de regressió per verificar l'impacte del canvi en el codi.
- Repetició del cicle de proves fins que el sistema estigui llest per desplegar-se.
- Inicieu la sessió a l’equip de proves.
Què provar?
Els punts que s’indiquen a continuació es tracten en aquesta prova:
- Proves d'extrem a extrem que inclou la comprovació de la interacció entre tots els components i juntament amb els perifèrics externs per garantir que el sistema funcioni bé en qualsevol dels escenaris que es cobreix en aquesta prova.
- Verifica que l'entrada proporcionada al sistema proporciona el resultat esperat.
- Verifica si es posen a prova tots els requisits funcionals i no funcionals i si funcionen com s’esperava o no.
- A això i es poden realitzar proves exploratòries en aquesta prova després de completar les proves amb script. Proves exploratòries i les proves ad-hoc ajuden a desplegar els errors que no es poden trobar en les proves amb guió, ja que dóna llibertat als provadors perquè el seu desig es basa en la seva experiència i intuïció.
Avantatges
Hi ha diversos avantatges:
- Aquesta prova inclou escenaris d'extrem a extrem per provar el sistema.
- Aquesta prova es realitza en el mateix entorn que l’entorn de producció, que ajuda a entendre la perspectiva de l’usuari i evita els problemes que es poden produir quan el sistema es posa en funcionament.
- Si aquesta prova es fa de manera sistemàtica i adequada, ajudaria a mitigar els problemes de postproducció.
- Aquesta prova posa a prova tant l'arquitectura d'aplicacions com els requisits empresarials.
Criteris d’entrada / sortida
Vegem detalladament els criteris d’entrada / sortida de la prova del sistema.
Criteris d'entrada:
- El sistema hauria d’haver superat els criteris de sortida de les proves d’integració, és a dir, s’haurien d’haver executat tots els casos de prova i no hauria d’haver cap error crític ni Priority P1, un error P2 en estat obert.
- Pla de proves per a aquesta prova s'ha d'aprovar i tancar la sessió.
- Els casos / escenaris de prova haurien d'estar preparats per executar-se.
- Els scripts de prova haurien d'estar preparats per executar-se.
- Tots els requisits no funcionals haurien d'estar disponibles i s'haurien d'haver creat casos de prova per al mateix.
- L'entorn de proves hauria d'estar preparat.
Criteris de sortida:
- S'han d'executar tots els casos de prova.
- No hi ha cap error crític o prioritari o relacionat amb la seguretat en un estat obert.
- Si algun error de prioritat mitjana o baixa es troba en estat obert, s’hauria d’implementar amb l’acceptació del client.
- S'ha d'enviar l'informe de sortida.
Pla de proves del sistema
El pla de prova és un document que s’utilitza per descriure la finalitat, l’objectiu i l’abast d’un producte a desenvolupar. Què s’ha de provar i què no s’ha de provar, estratègies de prova, eines que s’utilitzaran, entorn necessari i tots els altres detalls estan documentats per continuar amb la prova.
El pla de proves ajuda a procedir amb les proves d’una manera molt sistemàtica i estratègica i això ajuda a evitar qualsevol risc o problema mentre es realitzen les proves.
El pla de proves del sistema inclou els punts següents:
- El propòsit i l'objectiu es defineixen per a aquesta prova.
- Abast (es detallen les funcions a provar, les funcions que no s’han de provar).
- Criteris d’acceptació de la prova (els criteris en què s’acceptarà el sistema, és a dir, els punts esmentats en els criteris d’acceptació haurien d’estar en estat d’aprovació).
- Criteris d'entrada / sortida (defineix els criteris per començar les proves del sistema i quan s'ha de considerar complet).
- Programa de proves (estimació de les proves que s'hauran de completar en un moment concret).
- Prova d’Estratègia (Inclou tècniques de prova).
- Recursos (nombre de recursos necessaris per fer proves, les seves funcions, disponibilitat de recursos, etc.).
- Entorn de prova (sistema operatiu, navegador, plataforma).
- Casos de prova (Llista de casos de prova a executar).
- Supòsits (si hi ha hipòtesis, s’han d’incloure al pla de proves).
Procediment per escriure casos de prova del sistema
Els casos de prova del sistema cobreixen tots els escenaris i casos d’ús i també cobreixen casos de prova relacionats amb la interfície d’usuari, funcionals i no funcionals. Els casos de prova s’escriuen de la mateixa manera que s’escriuen per a proves funcionals.
Els casos de prova del sistema inclouen els camps següents a la plantilla:
- Identificador de cas de prova
- Nom de la prova
- Descripció: descriu el cas de prova que cal executar.
- Passos: procediment pas a pas per descriure com realitzar proves.
- Dades de prova: les dades fictícies es preparen per provar l'aplicació.
- Resultat esperat: el resultat esperat segons el document de requisits es proporciona en aquesta columna.
- Resultat real: el resultat després de l'execució del cas de prova es proporciona en aquesta columna.
- Passar / Fallar: la comparació del resultat real i esperat defineix els criteris de Passar / Fallar.
- Observacions
Casos de prova del sistema
A continuació, es mostren alguns casos d’exemple de prova per a un lloc de comerç electrònic:
- Si el lloc s’inicia correctament amb totes les pàgines, funcions i logotip rellevants
- Si l'usuari pot registrar-se / iniciar sessió al lloc
- Si l'usuari pot veure els productes disponibles, pot afegir productes al seu carretó i pot fer el pagament i pot obtenir la confirmació per correu electrònic, SMS o trucada.
- Si les funcions principals com ara cercar, filtrar, ordenar, afegir, canviar, llista de desitjos, etc. funcionen com s’esperava
- Si el nombre d’usuaris (definit com al document de requisits) pot accedir al lloc simultàniament
- Si el lloc s’inicia correctament en tots els principals navegadors i en les seves darreres versions
- Si les transaccions es fan al lloc mitjançant un usuari específic, són prou segures
- Si el lloc s’inicia correctament a totes les plataformes compatibles com Windows, Linux, Mobile, etc.
- Si la política de devolució del manual / guia de l'usuari, la política de privadesa i les condicions d'ús del lloc estan disponibles com a document separat i útils per a qualsevol principiant o usuari per primera vegada.
- Si el contingut de les pàgines està correctament alineat, ben gestionat i sense errors ortogràfics.
- Si el temps d'espera de la sessió està implementat i funciona com s'esperava
- Si un usuari està satisfet després d’utilitzar el lloc o, dit d’una altra manera, a l’usuari no li costa utilitzar-lo.
Tipus de proves de sistemes
ST s’anomena superconjunt de tot tipus de proves, ja que s’hi inclouen tots els tipus principals de proves. Tot i que el focus en els tipus de proves pot variar en funció del producte, els processos d’organització, la cronologia i els requisits.
El conjunt es pot definir a continuació:
Proves de funcionalitat: Per assegurar-vos que la funcionalitat del producte funciona segons els requisits definits, dins de les capacitats del sistema.
Proves de recuperabilitat: Per assegurar-vos que el sistema es recupera de diversos errors d’entrada i altres situacions d’error.
Proves d'interoperabilitat: Per assegurar-vos que el sistema pot funcionar bé amb productes de tercers o no.
Proves de rendiment: Per assegurar-vos del rendiment del sistema en diverses condicions, en termes de característiques de rendiment.
Proves d’escalabilitat: Per assegurar-vos de les capacitats d’escala del sistema en diversos termes, com ara l’escala d’usuari, l’escala geogràfica i l’escala de recursos.
Proves de fiabilitat: Per assegurar-vos que el sistema pugui funcionar durant més temps sense que es produeixin errors.
Proves de regressió: Per assegurar-se de l’estabilitat del sistema en passar per la integració de diferents subsistemes i tasques de manteniment.
Proves de documentació: Per assegurar-vos que la guia de l'usuari del sistema i altres documents sobre temes d'ajuda siguin correctes i utilitzables.
Proves de seguretat: Assegureu-vos que el sistema no permet l'accés no autoritzat a dades i recursos.
Proves d’usabilitat : Per assegurar-vos que el sistema sigui fàcil d’utilitzar, aprendre i operar.
Més tipus de proves de sistemes
# 1) Prova gràfica d’interfície d’usuari (GUI):
Les proves de la GUI es fan per verificar si la GUI d'un sistema funciona com s'esperava o no. La GUI és bàsicament el que és visible per a un usuari mentre utilitza l'aplicació. La prova GUI implica provar botons, icones, caselles de selecció, quadre de llista, quadre de text, menús, barres d’eines, quadres de diàleg, etc.
# 2) Prova de compatibilitat:
Proves de compatibilitat es fa per garantir que el producte desenvolupat sigui compatible amb diferents navegadors, plataformes de maquinari, sistema operatiu i bases de dades segons el document de requisits.
# 3) Gestió d'excepcions:
Es realitzen proves de manipulació d'excepcions per verificar que, fins i tot si es produeix un error inesperat al producte, ha de mostrar el missatge d'error correcte i no permet que l'aplicació s'aturi. Gestiona l'excepció de manera que es mostra l'error mentre el producte es recupera i permet al sistema processar la transacció incorrecta.
# 4) Prova de volum:
La prova de volum és un tipus de prova no funcional en què les proves es fan mitjançant una gran quantitat de dades. Per exemple, el volum de dades augmenta a la base de dades per verificar el rendiment del sistema.
# 5) Proves d’estrès:
La prova d’esforç es fa augmentant el nombre d’usuaris (alhora) d’una aplicació fins al punt que es descompon. Això es fa per verificar el punt en què es desglossarà l'aplicació.
# 6) Proves de seny:
Proves de seny es realitza quan s'allibera la compilació amb un canvi en el codi o la funcionalitat o si s'ha solucionat algun error. Verifica que els canvis fets no han afectat el codi i que no s'ha produït cap altre problema a causa d'això i que el sistema funciona com abans.
Si es produeix algun problema, la compilació no s'accepta per a proves posteriors.
Bàsicament, no es fan proves exhaustives de la construcció per estalviar temps i costos, ja que rebutja la construcció per un problema trobat. Les proves de seny es fan per al canvi realitzat o per al problema solucionat i no per al sistema complet.
# 7) Prova de fum:
Proves de fum és una prova que es realitza a la compilació per verificar si la compilació es pot provar o no. Verifica que la compilació és estable per provar i que totes les funcionalitats crítiques funcionen bé. Les proves de fum es fan per al sistema complet, és a dir, es fan proves de punta a punta.
# 8) Proves exploratòries:
Proves exploratòries com el propi nom indica, es tracta d'explorar l'aplicació. No es realitzen proves amb guió en proves exploratòries. Els casos de prova s’escriuen juntament amb la prova. Se centra més en l'execució que en la planificació.
El provador té la llibertat de provar tot sol mitjançant la seva intuïció, experiència i intel·lecte. Un provador pot triar qualsevol funció per provar primer, és a dir, a l’atzar pot triar la funció per provar-la, a diferència de la resta de tècniques en què s’utilitza la forma estructural per realitzar proves.
# 9) Proves adhoc:
Proves adhoc és una prova informal on no es fa documentació ni planificació per provar l'aplicació. El provador prova l'aplicació sense cap cas de prova. L'objectiu d'un provador és trencar l'aplicació. El provador utilitza la seva experiència, suposició i intuïció per trobar els problemes crítics de l'aplicació.
# 10) Prova d'instal·lació:
Proves d'instal·lació és verificar si el programari s’instal·la sense cap problema.
Aquesta és la part més important de les proves, ja que la instal·lació del programari és la primera interacció entre l'usuari i el producte. El tipus de proves d’instal·lació depèn de diversos factors, com ara el sistema operatiu, la plataforma, la distribució de programari, etc.
Casos de prova que es poden incloure si la instal·lació es realitza a través d'Internet:
- Velocitat de xarxa incorrecta i connexió interrompuda.
- Tallafocs i seguretat.
- Es pren la mida i el temps aproximat.
- Instal·lació / descàrregues simultànies.
- Memòria insuficient
- Espai insuficient
- Instal·lació interrompuda
# 11) Proves de manteniment:
Un cop el producte es posa en funcionament, el problema es pot produir en un entorn actiu o pot ser que calgui alguna millora al producte.
El producte necessita manteniment un cop es posa en funcionament i l’equip de manteniment l’encarrega. Les proves realitzades per a qualsevol problema, millora o migració al maquinari pertanyen a les proves de manteniment.
Què és la prova d'integració de sistemes?
És un tipus de proves en què es comprova la capacitat del sistema per mantenir la integritat i el funcionament de les dades en coordinació amb altres sistemes del mateix entorn.
Exemple de proves d'integració de sistemes:
Posem l'exemple d'un lloc de reserva d'entrades en línia conegut: http://irctc.co.in.
Es tracta d’un servei de reserva d’entrades; una instal·lació de compra en línia interactua amb PayPal. En general, el podeu considerar com A * B * C = R.
Ara, a nivell de sistema, es pot provar el sistema de manera independent el servei de reserva d’entrades en línia, el servei de compra en línia i l’opció de pagament en línia, seguit de la verificació de realitzar proves d’integració per a cadascun d’ells. I aleshores s’ha de provar sistemàticament tot el sistema.
Llavors, on apareixen les proves d’integració de sistemes?
El portal web http://Irctc.co.in és una combinació de sistemes. Podeu fer proves al mateix nivell (sistema únic, el sistema de sistemes), però a cada nivell us podeu concentrar en diferents riscos (problemes d’integració, funcionalitat independent).
- Mentre proveu el servei de reserva d’entrades en línia, podeu verificar si podeu reservar entrades en línia. També podeu considerar problemes d’integració Per exemple, La funció de reserva d’entrades s’integra amb el back-end amb el front-end (IU). Per exemple, com es comporta el front-end quan el servidor de bases de dades tarda a respondre?
- Prova de la instal·lació de reserva d’entrades en línia amb la compra en línia. Podeu verificar que el centre de compres en línia estigui disponible per als usuaris connectats al sistema per reservar entrades en línia. També podeu considerar la verificació de la integració al centre de compres en línia. Per exemple, si l’usuari és capaç de seleccionar i comprar un producte sense problemes.
- Prova de la integració de la instal·lació de reserva d’entrades en línia amb PayPal. Podeu verificar si, després de reservar els bitllets, es van transferir diners del vostre compte de PayPal al compte de la reserva de bitllets en línia. També podeu considerar la verificació de la integració a PayPal. Per exemple, Què passa si el sistema posa dues entrades en una base de dades després de domiciliar només una vegada els diners?
Diferènciaentre la prova de sistemes i la prova d'integració de sistemes:
La diferència principal és:
- Les proves de sistema vetllen per la integritat d’un sistema amb un entorn rellevant
- Les proves d’integració de sistemes vetllen per la integritat de diversos sistemes, ja que es troben en el mateix entorn.
Per tant, la prova del sistema és el començament de proves reals en què proveu un producte en conjunt i no un mòdul / característica.
Diferència entre el sistema i les proves d'acceptació
A continuació es detallen les principals diferències:
| Proves del sistema | Proves d'acceptació | |
|---|---|---|
| 1 | La prova del sistema és la prova d’un sistema en general. Es realitzen proves de punta a punta per comprovar que tots els escenaris funcionen com s’esperava. | Les proves d’acceptació es fan per verificar si el producte compleix els requisits del client. |
| 2 | Les proves del sistema inclouen proves funcionals i no funcionals i les realitzen els verificadors. | Les proves d’acceptació són proves funcionals i les realitzen tant els verificadors com els clients. |
| 3 | Les proves es realitzen utilitzant les dades de prova creades pels provadors. | S’utilitzen dades reals / de producció mentre es realitzen les proves d’acceptació. |
| 4 | Es prova un sistema en general per comprovar la funcionalitat i el rendiment del producte. | Les proves d’acceptació es fan per verificar aquest requisit empresarial, és a dir, que resol el propòsit que busca el client. |
| 5 | Es poden corregir els defectes trobats a les proves. | Qualsevol defecte detectat durant la prova d’acceptació es considera un error del producte. |
| 6 | Les proves d’integració de sistemes i sistemes són tipus de proves de sistema. | Les proves Alpha i Beta estan sotmeses a proves d’acceptació. |
Consells per realitzar la prova del sistema
- Repliqueu escenaris en temps real en lloc de fer proves ideals, ja que el sistema serà utilitzat per un usuari final i no per un provador entrenat.
- Verifiqueu la resposta del sistema en diversos termes, ja que a l’humà no li agrada esperar ni veure les dades equivocades.
- Instal·leu i configureu el sistema segons la documentació, perquè això és el que farà l'usuari final.
- Amb la participació de persones de diferents àrees, com ara analistes de negocis, desenvolupadors, verificadors, els clients poden enviar un sistema millor.
- Les proves regulars són l'única manera d'assegurar-se que el més petit canvi del codi per solucionar l'error no hagi inserit cap altre error crític al sistema.
Conclusió
Les proves del sistema són molt importants i, si no es fan correctament, es poden afrontar problemes crítics a l’entorn en viu.
Un sistema en el seu conjunt té diferents característiques per verificar. Un exemple senzill seria qualsevol lloc web. Si no es provi en general, és possible que l'usuari consideri que el lloc sigui molt lent o que el lloc es bloquegi quan un gran nombre d'usuaris iniciï la sessió al mateix temps.
I aquestes característiques no es poden provar fins que el lloc web no es provi en el seu conjunt.
Espero que aquest tutorial sigui molt útil per entendre el concepte de proves de sistemes.
Lectura recomanada
- Tipus de proves de programari: diferents tipus de proves amb detalls
- Proves alfa i proves beta (guia completa)
- Què és la prova d’integració de sistemes (SIT): apreneu amb exemples
- Proves funcionals contra proves no funcionals
- Procés d’integració contínua: Com millorar la qualitat del programari i reduir el risc
- Top 10 d'eines de proves d'integració per escriure proves d'integració
- Què és la prova d'integració (Tutorial amb exemple de prova d'integració)
- Què és la prova de resistència en proves de programari (exemples)