A fenti szekvencia diagram végrehajtása inkonluzív, amennyiben a szenzor nem Faulty állapotban van.

A fenti szekvencia diagram azt állítja, hogy Faulty szenzor esetén a mért érték negáltját kell kell kivezérelnünk, vagyis: <[state==Faulty is true], !processSensorReading(data), ?processSensorReading(data), !actuate(-data), ?actuate(-data)>.

A fenti szekvencia diagram egy valid lefutása: <!actuate(data), ?actuate(data), [state==Faulty is true], !processSensorReading(data), ?processSensorReading(data)>, mivel strict fragmens nélkül a különböző lifeline-k közötti sorrend nem definiált.

A fenti szekvencia diagram szerint, ha a szenzor nem Faulty állapotban van, akkor a szenzormérés feldolgozása után, a Processor-nak mindenképpen kell vezérlést küldenie az Actuator felé, vagyis: <[state==Faulty is false], !processSensorReading(data), ?processSensorReading(data), !actuate(data), ?actuate(data)>.

A fenti szekvencia diagram egy valid lefutása az üres halmaz, hiszen ha a Processor nem kéri el az aktuális sebességet a szenzortól, akkor nincs szükség vészfékezésre sem.

A fenti szekvencia diagram egy valid lefutása: <[state==Working is true], !getSpeed(), ?getSpeed(), !speed, ?speed, !actuate(speed), ?actuate(speed)>, mivel az assert és a neg fragmens is teljesül.

A fenti szekvencia diagram lefutása akkor is valid, ha a szenzor nem Working állapotban van, hiszen az állapot invariáns nincs assert fragmensbe foglalva.

A fenti szekvencia diagram egyetlen valid lefutása: <[state==Working is true], !getSpeed(), ?getSpeed(), !speed, ?speed>.

A fenti szekvencia diagram végrehajtása inkonluzív, amennyiben a szenzor nem Faulty állapotban van.

A fenti szekvencia diagram azt állítja, hogy Faulty szenzor esetén a mért érték negáltját kell kell kivezérelnünk, vagyis: <[state==Faulty is true], !processSensorReading(data), ?processSensorReading(data), !actuate(-data), ?actuate(-data)>.

A fenti szekvencia diagram egy valid lefutása: <!actuate(data), ?actuate(data), [state==Faulty is true], !processSensorReading(data), ?processSensorReading(data)>, mivel strict fragmens nélkül a különböző lifeline-k közötti sorrend nem definiált.

A fenti szekvencia diagram szerint, ha a szenzor nem Faulty állapotban van, akkor a szenzormérés feldolgozása után, a Processor-nak mindenképpen kell vezérlést küldenie az Actuator felé, vagyis: <[state==Faulty is false], !processSensorReading(data), ?processSensorReading(data), !actuate(data), ?actuate(data)>.

Az ekvivalencia partíciók meghatározása általános folyamat, nem függ a specifikációtól.

Specifikáció-alapú tesztelésnél a kód belső felépítése ismert.

A másik három állítás közül egyik sem igaz.

A határérték analízis során tipikusan megtalált hiba a szöveges változók rossz tartalma.

A specifikáció alapú tesztelés kiváltja a struktúra alapú tesztelést.

A specifikációs és struktúra alapú tesztelés között a fő különbség az, hogy milyen tesztelési szoftverkeretrendszert alkalmazunk.

A kódlefedettség mérése alkalmas lehet még nem tesztelt kódrészletek azonosítására.

Az ekvivalencia osztályok lényege, hogy megtaláljuk azt az osztályt, amire minden teszteset illeszkedni fog és csak azt kelljen tesztelni.

Előfordulhat, hogy a turnOn esemény hatására start nélkül is végrehajtja az állapotgép az initialize viselkedést.

turnOn esemény hatására mindig a Working állapotba kerülünk.

A turnOff esemény hatására az állapotgép kiküldi a stop eseményt.

Az initialize esemény kiküldése mindig a start esemény hatására következik be, mivel csak így juthatunk a Working állapotba.

Igen, hiszen a kliens mindig megvárja előző üzenete megérkezését a szerverhez.

Igen, hiszen a két üzenet egymás után következik.

Nem, mert se az üzenet, se a lifeline nem közös, így nincsen biztos rendezettség.

Nem, mert attól, hogy egy esetet lemodellezünk, még bármi megtörténhet.