Test
Development testing
Este test tiene tipos de pregunta que se abren en el reproductor de siempre.
Preguntas del test (26)
1Development testing includes all testing activities carried out by the [blank_start]team developing the system[blank_end].
- Ateam developing the system
2Development testing consists of [blank_start]three[blank_end] types of testing methods.
- Athree
31) U[blank_start]nit[blank_end] testing
2) C[blank_start]omponent[blank_end] testing
3) S[blank_start]ystem[blank_end] testing- Anit
- Bomponent
- Cystem
4Unit testing is the process of testing [blank_start]individual components[blank_end] in [blank_start]isolation[blank_end].
- Aindividual components
- Bisolation
5It is a [blank_start]defect[blank_end] testing process
- Adefect
6Units may be:
> Individual [blank_start]methods[blank_end] within an [blank_start]object[blank_end]
> Object [blank_start]classes[blank_end] with [blank_start]attributes[blank_end] and [blank_start]methods[blank_end]
> [blank_start]Composite[blank_end] components with defined [blank_start]interfaces[blank_end] to access their functionality- Amethods
- Bobject
- Cclasses
- Dattributes
- Emethods
- FComposite
- Ginterfaces
7Complete test coverage of a class involves:
> Testing all [blank_start]operations[blank_end] associated with an object
> Setting and interrogating all object [blank_start]attributes[blank_end]
> Exercising the object in all possible [blank_start]states[blank_end]- Aoperations
- Battributes
- Cstates
8Whenever possible, unit testing should be [blank_start]automated[blank_end] so that tests are run and checked without manual intervention.
- Aautomated
9[blank_start]Unit testing[blank_end] framework, such as [blank_start]JUnit[blank_end], can write and run program tests. They provide [blank_start]generic[blank_end] test [blank_start]classes[blank_end] that can be [blank_start]extended[blank_end] to create [blank_start]specific[blank_end] test [blank_start]cases[blank_end].
- AUnit testing
- BJUnit
- Cgeneric
- Dclasses
- Eextended
- Fspecific
- Gcases
10Automated test components include a [blank_start]setup[blank_end] part, where you [blank_start]initialise[blank_end] the system with the [blank_start]test case[blank_end], namely the [blank_start]inputs[blank_end] and [blank_start]expected outputs[blank_end]. Next, there is a [blank_start]call[blank_end] part, where you call the [blank_start]object[blank_end] or [blank_start]method[blank_end] to be tested. Finally there is an [blank_start]assertion[blank_end] part, where you compare the [blank_start]result[blank_end] of the [blank_start]call[blank_end] with the [blank_start]expected output[blank_end].
- Asetup
- Binitialise
- Ctest case
- Dinputs
- Eexpected outputs
- Fcall
- Gobject
- Hmethod
- Iassertion
- Jresult
- Kcall
- Lexpected output
11These unit test cases should show that, when used [blank_start]as expected[blank_end], the component you are testing does [blank_start]what it is supposed to do[blank_end]. If there are [blank_start]defects[blank_end] in the component, they should be [blank_start]revealed[blank_end] by the test cases.
- Aas expected
- Bwhat it is supposed to do
- Cdefects
- Drevealed
12This leads to [blank_start]two[blank_end] types of test cases: the first should reflect [blank_start]normal operation[blank_end] of a program, and should show that the component works [blank_start]as expected[blank_end]. The other kind should be based on [blank_start]testing experience[blank_end] of where [blank_start]common[blank_end] problems arise. It should use [blank_start]abnormal[blank_end] inputs to check that these are properly processed, and do not crash the component.
- Atwo
- Bnormal operation
- Cas expected
- Dtesting experience
- Ecommon
- Fabnormal
13General testing guidelines include choosing inputs that force the system to generate all [blank_start]error messages[blank_end], forcing [blank_start]computation[blank_end] results to be too [blank_start]large[blank_end] or [blank_start]small[blank_end], and [blank_start]repeating[blank_end] the same input numerous times.
- Aerror messages
- Blarge
- Csmall
- Dcomputation
- Erepeating
14Component testing involves [blank_start]several individual units[blank_end] being integrated to create [blank_start]composite components[blank_end].
- Aseveral individual units
- Bcomposite components
15Component testing should focus on showing that the [blank_start]component[blank_end] interface behaves according to its [blank_start]specification[blank_end].
- Acomponent
- Bspecification
16The objectives of interface testing is to detect [blank_start]faults[blank_end] due to interface [blank_start]errors[blank_end] or [blank_start]invalid assumptions[blank_end] about interfaces.
- Afaults
- Berrors
- Cinvalid assumptions
17Interface types include:
P[blank_start]arameter[blank_end] interfaces - data passed from one [blank_start]method[blank_end] to another
S[blank_start]hared memory[blank_end] interfaces - [blank_start]block of memory[blank_end] is shared between methods
M[blank_start]essage passing[blank_end] interfaces - [blank_start]sub-systems[blank_end] request [blank_start]services[blank_end] from other [blank_start]sub-systems[blank_end]- Aarameter
- Bmethod
- Chared memory
- Dblock of memory
- Eessage passing
- Fsub-systems
- Gservices
- Hsub-systems
18There are [blank_start]three[blank_end] types of interface errors.
- Athree
19Interface [blank_start]misuse[blank_end]: a calling component calls another component, but makes an error in its use of interface, e.g. the [blank_start]parameters[blank_end] are in the [blank_start]wrong order[blank_end].
- Amisuse
- Bparameters
- Cwrong order
20Interface [blank_start]misunderstanding[blank_end]: a calling component embeds [blank_start]assumptions[blank_end] about the behaviour of the called component which are incorrect.
- Amisunderstanding
- Bassumptions
21[blank_start]Timing[blank_end] errors: the called and calling component operate at [blank_start]different speeds[blank_end], and [blank_start]out of date[blank_end] information is accessed.
- ATiming
- Bdifferent speeds
- Cout of date
22Interface testing guidelines include designing tests so that parameters to a called procedure are at the [blank_start]extreme ends[blank_end] of their ranges, testing [blank_start]pointer[blank_end] parameters with [blank_start]null pointers[blank_end], designing tests which cause the component to [blank_start]fail[blank_end], and using [blank_start]stress[blank_end] testing in [blank_start]message passing[blank_end] systems.
- Aextreme ends
- Bpointer
- Cnull pointers
- Dfail
- Estress
- Fmessage passing
23System testing involves integrating [blank_start]components[blank_end] to create a [blank_start]version[blank_end] of the system, and then testing the integrated system.
- Acomponents
- Bversion
24System testing checks that [blank_start]components[blank_end] are [blank_start]compatible[blank_end].
- Acompatible
- Bcomponents
25System testing tests the [blank_start]emergent[blank_end] behaviour of a system.
- Aemergent
26During system testing, components developed by [blank_start]different team members[blank_end] may be integrated. System testing is a [blank_start]collective[blank_end] rather than an [blank_start]individual[blank_end] process.
- Adifferent team members
- Bcollective
- Cindividual
Información
- Descripción
- Games Development Test sobre Development testing, creado por Kerrie Callaghan el 08/05/2017.
- Autor
- Kerrie Callaghan
- Idioma
- English
- Visitas
- 0
- Etiquetas
- Valoración
- Aún sin valoraciones Valora este test