Quiz
Development testing
Este quiz tem tipos de pergunta que abrem no player de sempre.
Perguntas do quiz (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
Informações
- Descrição
- Games Development Quiz sobre Development testing, criado por Kerrie Callaghan em 08-05-2017.
- Autor
- Kerrie Callaghan
- Idioma
- English
- Visualizações
- 0
- Etiquetas
- Avaliação
- Ainda sem avaliações Avalie este quiz