VerVal_parc_2022

A visually engaging illustration depicting safety-critical software systems testing, including elements like code, diagrams, and quality assurance symbols, in a modern tech setting.

Safety-Critical Software Testing Quiz

Test your knowledge on safety-critical software systems and testing methodologies with this comprehensive quiz. Dive into essential concepts of verification, validation, and quality assurance.

Key Topics Covered:

Safety-critical software characteristics
Testing levels and strategies
Verification and validation fundamentals
Quality attributes in software development

15 Questions4 MinutesCreated by TestingGuard42

Válasszuk ki biztonság kritikus szoftver rendszerekre jellemző igaz kijelentéseket

Biztonság kritikus szoftver alkotása lehetetlen

A biztonság kritikus szoftver rendszereket alkotása ugyanolyan, mint a „nem” biztonságos kritikus szoftver rendszereket alkotása csak többet kell tesztelni.

A biztonság kritikus szoftver típusait a kritikusság alapján különböző szintekre lehet osztályozni

A biztonság kritikus szoftver rendszereket alkotását szabványrendszerek szabályozzák

Válasszuk ki tesztelési szintekre jellemző igaz kijelentéseket

Automatizálni a tesztek tervezését és megalkotását lehet

Unittesztek nagyszámban készülnek és igazság értékük nagy

Acceptance tesztek kevesebb számban készülnek mint unittesztek és igazság értékük nagy

System tesztelés fókusza az architektúrai interfacek helyessége, tervezése

Válasszuk ki tesztelésre jellemző igaz kijelentéseket

Tesztelést mindig dedikált és szakavatott tesztelők végzik

Tesztelés összes tevékenységei automatizálható

Tesztelés célja a megfelelő eltérés felmutatása

Tesztelés egy mentális fogalom és célja minőségi software

Válasszuk ki Verifikáció, Validáció alapfogalmaira jellemző igaz kijelentéseket

Validáció hibamodellje a követelmények hiányosságai

Validáció egy objektiv folyamat

Verifikáció hibamodellje tervezési, implementációs hibák

Verifikáció egy szubjektiv folyamat

Válasszuk ki RIP modellre jellemző igaz kijelentéseket

A meghibásodás a szoftver belső állapota

A fault helye nem mindig elérhető

Restfull Integration Process röviditése

A softver,,fault" helye általában és mindig a szoftver „hibás” állapotához vezet mely mindig meghibásodás- hoz vezet

Válasszuk ki minőségre jellemző igaz kijelentéseket

Minőségi jellemzőket általában már a követelmények tartalmazzák

SLA -tartalmazhat minőségi jellemzőket

Minőségi jellemzőket a SCRUM nem tartalmaz

Minőségi jellemzőket ha lehet akkor quantitativan jellemezzük

Válasszuk ki Verifikáció, Validáció alapfogalmaira jellemző igaz kijelentéseket

Failure jelentése magyarul meghibásodás

MTBF és MTTR megbízhatóság egyes mércéi

MTBF egy qualitative jellemző

Debugging esetén keressük a meghibásodást

Válasszuk ki Scrum és minősegre jellemző igaz kijelentéseket

A minőség terv jellemzők egy része az User Story-ban található

Scrum esetében nincs értelme minőségi tervről beszélni

A minőségi terv jellemzők a backlogban található

A minőség terv jellemzők egy része a DoD-ban és Acceptance Criteriaban található

Válasszuk ki teszteset, testcase-re jellemző igaz kijelentéseket

Az unit teszteset egy automatizált teszteset a legkisebb meg tesztelhető programrészletről

A teszteset egy szöveges leírás

Mindegyik testcase egy futtatható (kisebb) code részlet

Válasszuk ki teszteset, testcase, unitteszt-re jellemző igaz kijelentéseket

Az unit teszteseteknek nagy az igazság értékük

A teszteset egyik legfontosabb gyenge pontja a hiányos követelmény/elvárás

A tesztesethez tartozó összes tevékenység (design, creation, stb..) automatizálható

Válasszuk ki a teszteset céljára jellemző igaz kijelentéseket

Cél az alkalmazás minőségével kapcsolatosan újabb információ

Cél az esetleges meghibásodások feltárása

Cél az alkalmazás helyes elvárásának feltárása

Válasszuk ki bejárási (Walkthrough) felülvizsgálatra jellemző igaz kijelentéseket

Bejárási felülvizsgálati jobb mint a Inspekció felülvizsgálati

A felülvizsgálat elsődleges célja az eltérések feltárása

A szerzők kezdik, először bemutatják saját munkájukat

A felülvizsgálat elsődleges célja a csoportos tudásnövelés

Válasszuk ki teszteset és coverage-re jellemző igaz kijelentéseket

Unit tesztelés esetén nem beszélhetünk test covarege-ről.

Hibasejtési módszer teszteset alkotásnál coverage soha nem alkalmazható

Black box tesztelésnek a coverage könyvtárak, keretrendszerek feltétlenül részei kell legyenek

White box tesztelés esetében,,Decision" alapú „coverage" általában nagyobb minőségi hozzájárulást biztosít mint a statement" coverage

Válasszuk ki teszt eset és döntési táblára jellemző igaz kijelentéseket

Kimeritő (exhaustive) tesztkészlet esetében egy helyesen kitöltött döntései tábla oszlopainak(rule) szá- ma „k" általában azonos a kimeritő (exhaustive) tesztkészlet elemeinek számával

Kimeritő (exhaustive) tesztkészlet esetében egy helyesen kitöltött döntései tábla oszlopainak(rule) száma „k” és pontosan megegyezik a 2^n-el ahol “n” a feltételek (condition) száma

Kimeritő (exhaustive) tesztkészlet esetében egy helyesen kitöltött döntései tábla oszlopainak(rule) száma ,,k" és pontosan megegyezik a feltételek (condition) számával

Válasszuk ki felülvizsgálatra jellemző igaz kijelentéseket

Felülvizsgálati kickoff értekezlet ne legyen elhanyagolható és igen fontos.

Felülvizsgálat során kevés (inkább kevesebb) logikai, design eltérést lehet feltárni

Sikeres felülvizsgálat során az eltérések pontos helyét nem ismerjük

Felülvizsgálat során az eltérések feltárása és ajánlások megfogalmazása történik

VerVal_parc_2022

Safety-Critical Software Testing Quiz

More Quizzes