Ministerul Educaie a Republica Moldova

Universitatea Tehnic a Moldovei

Facultatea Calculatoare Informatic i Microelectronic
Catedra Informatic Aplicat

Raport
Lucrarea de laborator Nr.1
Obiectul: APLN
Tema: Indexul Inversat

A executat:

Chirca Daniela
studenta gr MAI-141

A verificat:

Lazu Victoria
lector superior

Chiinu 2014

Tema: Indexul Inversat

Sarcina lucrrii
1. De gsit n Internet cinci texte din acelai domeniu, care ar
conine cel mult cinci sau ase propoziii.
2. Prima etapa: Tokenization
3. A doua etap: Normalization
4. A treia etap: Construirea indexului inversat (Inverted Index).
5. De elaborat un program care va prezenta una din etapele
enumerate mai sus, sau care va simula un motor de cutare al
informaiei.

Mersul Lucrrii:

Domeniul Sofware Testing

Textul 1
Software testing is an investigation conducted to provide stakeholders with information about the quality
of the product or service under test. [1] Software testing can also provide an objective, independent view of
the software to allow the business to appreciate and understand the risks of software implementation.
Test techniques include, but are not limited to the process of executing a program or application with the
intent of finding software bugs (errors or other defects).
Software testing can be stated as the process of validating and verifying that a computer
program/application/product:
Software testing, depending on the testing method employed, can be implemented at any time in the
software development process. Traditionally most of the test effort occurs after the requirements have
been defined and the coding process has been completed, but in the Agile approaches most of the test
effort is on-going. As such, the methodology of the test is governed by the chosen software development
methodology.

Textul 2
Testing can never completely identify all the defects within software. [2] Instead, it furnishes
a criticism or comparison that compares the state and behavior of the product againstoraclesprinciples
or mechanisms by which someone might recognize a problem. These oracles may include (but are not
limited to) specifications, contracts,[3] comparable products, past versions of the same product, inferences
about intended or expected purpose, user or customer expectations, relevant standards, applicable laws,
or other criteria.
A primary purpose of testing is to detect software failures so that defects may be discovered and
corrected. Testing cannot establish that a product functions properly under all conditions but can only
establish that it does not function properly under specific conditions. [4] The scope of software testing often
includes examination of code as well as execution of that code in various environments and conditions as
well as examining the aspects of code: does it do what it is supposed to do and do what it needs to do

Texul 3
In the current culture of software development, a testing organization may be separate from the
development team. There are various roles for testing team members. Information derived from software
testing may be used to correct the process by which software is developed. [5]
Every software product has a target audience. For example, the audience for video game software is
completely different from banking software. Therefore, when an organization develops or otherwise
invests in a software product, it can assess whether the software product will be acceptable to its end
users, its target audience, its purchasers and other stakeholders. Software testing is the process of
attempting to make this assessment.

Defects and failures

Not all software defects are caused by coding errors. One common source of
expensive defects is requirement gaps, e.g., unrecognized requirements which result in errors of
omission by the program designer.

Textul 4
Requirement gaps can often be non-functional requirements such
as testability, scalability, maintainability, usability, performance, andsecurity.
Software faults occur through the following processes. A programmer makes an error (mistake), which
results in a defect (fault, bug) in the software source code. If this defect is executed, in certain situations
the system will produce wrong results, causing a failure.[7] Not all defects will necessarily result in failures.
For example, defects in dead code will never result in failures. A defect can turn into a failure when the
environment is changed. Examples of these changes in environment include the software being run on a
newcomputer hardware platform, alterations in source data, or interacting with different software.[7] A
single defect may result in a wide range of failure symptoms

Textul 5
Input combinations and preconditions
A very fundamental problem with software testing is that testing under all combinations of inputs and
preconditions (initial state) is not feasible, even with a simple product. This means that the number
of defects in a software product can be very large and defects that occur infrequently are difficult to find in
testing. More significantly, non-functionaldimensions of quality (how it is supposed to be versus what it is
supposed to do)usability, scalability, performance, compatibility, reliabilitycan be highly subjective;
something that constitutes sufficient value to one person may be intolerable to another.
Software developers can't test everything, but they can use combinatorial test design to identify the
minimum number of tests needed to get the coverage they want. Combinatorial test design enables users
to get greater test coverage with fewer tests. Whether they are looking for speed or test depth, they can
use combinatorial test design methods to build structured variation into their test cases.

1.TOKENIZATION
Textul 1
software

understand

method

testing

risks

employed

is

implementation

implemented

techniques

at

investigation

include

any

conducted

but

time

to

are

in

provide

not

development

stakeholders

limited

traditionally

with

process

most

information

executing

effort

about

occurs

the

program

after

quality

application

requirements

of

intent

have

product

finding

been

or

bugs

defined

service

errors

coding

under

other

has

test

defects

completed

can

be

agile

also

stated

approaches

objective

as

ongoing

independent

validating

such

view

verifying

methodology

allow

that

governed

business

computer

by

appreciate

depending

chosen

and

on

Textul 2
testing
can

never
completely

identify
all

the
defects
within
software
instead
it
furnishes
a
criticism
or
comparison
that
compares
state
and
behavior
of
product
againstoracles
principles
mechanisms
by
which
someone
might
recognize
problem
these
oracles
may
include

but
are
not
limited
to
specifications
contracts
comparable
products
past
versions
same
inferences
about
intended
expected
purpose
user
customer
expectations
relevant
standards
applicable
laws
other
criteria
primary
is
detect
failures
so

be
discovered
corrected
cannot
establish
functions
properly
under
conditions
only
does
function
specific
scope
often
includes
examination
code
as
well
execution
in
various
environments
examining
aspects
do
what
supposed
needs

be
separate
from
team
there
are
various
roles
for
members
information

derived
used
to
correct
process
by
which
is
developed
every
product

Textul3
in
the
current
culture
of
software
development
a
testing
organization
may

has
target
audience
example
video
game
completely
different
banking
therefore
when
an
develops
or
otherwise
invests
it
can

assess
whether
will
acceptable
its
end
users
purchasers
and
other
stakeholders
attempting
make
this
assessment
defects
failuresnot
all

caused
coding
errors
one
common
source
expensive
requirement
gaps
eg
unrecognized
requirements
result
omission
program
designer

a
programmer
makes
an
error
mistake
which
results
in
defect
fault
bug
source
code
if
this
is
executed
certain
situations
system
will
produce

wrong
causing
failure
not
all
defects
necessarily
result
failures
for
example
dead
never
turn
into
when
environment
changed
examples
of
these
changes
include

Textul 4
requirement
gaps
can
often
be
non
functional
requirements
such
as
testability
scalability
maintainability
usability
performance
andsecurity
software
faults
occur
through
the
following
processes

being
run
on
newcomputer
hardware
platform

alterations
data
or
interacting
with
different

single
may
wide
range
symptoms

occur
infrequently
are
difficult
to
find
more
significantly
nonfunctional
dimensions
quality
how
it
supposed
versus
what
do
usability
scalability
performance
compatibility
reliability
highly
subjective
something
constitutes
sufficient
value
one
person
may
intolerable
another

developers
test
everything
but
they
use
combinatorial
design
identify
minimum
tests
needed
get
coverage
want
enables
users
greater
fewer
whether
looking
for
speed
or
depth
methods
build
structured
variation
into
their
cases

Textul 5
input
combinations
and
preconditions
a
very
fundamental
problem
with
software
testing
is
that
under
all
of
inputs
initial
state
not
feasible
even
simple
product
this
means
the
number
defects
in
can
be
large

Normalizarea:

Textul Nr1
software

risk

depend

testing

implementation

method

to be

technique

employ

investigation

include

implement

conduct

limit

time

provide

process

development

stakehold

execute

traditionally

information

program

effort

quality

application

occur

product

intent

requirement

service

find

to have

test

bug

define

can

error

code

objective

defect

complete

independent

to be

agile

view

state

approach

business

validate

methodology

appreciate

verify

govern

understand

computer

chose

mechanism
someone
recognize
problem
oracle
include
limite
specification
contract
comparable
product
past
version
inference

intend
expect
purpose
user
customer
expectation
relevant
standard
applicable
law
criteria
primary
detect
failure

Textul Nr 2
complete
identify
defect
software
instead
furnish
criticism
comparison
compare
state
behavior
product
storacles
principle

discover
correct
establish
function
properly
condition
to do
function

specific
scope
often
include
examination
code
well
execution

various
environment
examining
aspect
suppose
need

derive
use
correct
process
to be
develope
product
have
target
audience
example
video
game
complete
defects
failuresnot
all
caused
coding
errors
one

different
bank
therefore
when
develop
otherwise
invest
can
accept
end
user
purchaser

scalability
maintainability
usability
performance
security
software
fault

occur
through
following
process
programmer
make
error

Textul Nr 3
current
culture
software
development
testing
organization
to be
separate
team
to be
various
role
member
information
other
stakeholders
attempting
make
this
assessment

common
source
expensive
requirement
gaps
eg
unrecognized

Textul Nr 4
requirement
gap
can
to be
functional
requirement
testability

mistake
result
defect
fault
bug
source
code
execute
certain
situation
system
will
produce
wrong

cause
failure
defect
necessary
result
failure
example
dead
turn
environment
change
example
change
include

being
run
computer
hardware
platform
alteration
data
interact
different
single
wide
range
symptom

difficult
to find
significant
nonfunctional
dimension
quality
suppose
versus
to do
usability
scalability
performance
compatibility
reliability
highly
subjective
constitute
sufficient
value
person
developer
test
they
to use

combinatorial
design
identify
minimum
test
need
to get
coverage
to want
enable
user
greater
to look
speed
depth
method
build
structure
variation
their
case

Textul Nr5
input
combination
precondition
fundament
problem
software
testing
to be
all
input
initial
state
feasible
simple
product
mean
number
defect
can
to be
large
occur
infrequent
to be

Inversion INDEX
Term

software
testing
to be
investigation
conduct
provide
stakehold
information
quality
product
service
test
can
objective
independent
view
business
appreciate
understand
risk
implementation
technique
include
limit
process
execute
program
application
intent
find
bug
error
defect
to be
state
validate
verify
computer
depend
method
employ
implement
time
development

Frecven
ta
5
3
9
1
1
1
2
2
2
5
1
3
5
1
1
1
1
1
1
1
1
1
4
2
3
2
1
1
1
2
2
3
6
8
3
1
1
2
1
2
1
1
1
2

Doc Id
[1][2][3][4] [5]
[1][3][5]
[1]-2,[3]-3,[4]-1,[5]-3
[1]
[1]
[1]
[1][3]
[1][3]
[1][5]
[1]-1,[2]-2,[3]-1,[5]-1
[1]
[1]-1,[5]-2
[1][2][3][4] [5]
[1]
[1]
[1]
[1]
[1]
[1]
[1]
[1]
[1]
[1]-1,[2]-1,[4]-2
[1][2]
[1]-1,[3]-1,[4]-1
[1][4]
[1]
[1]
[1]
[1][5]
[1][5]
[1],[3],[4]
[1]-1,[2]-1,[3]-1,[4]-2,
[5]-1
[1]-1,[3]-3,[4]-1,[5]-3
[1],[2],[5]
[1]
[1]
[1],[4]
[1]
[1]
[1]
[1]
[1]
[1],[3]

traditionally
effort
occur
requirement
to have
define
code
complete
agile
approach
methodology
govern
chose

1
1
3
4
1
1
3
3
1
1
1
1
1

identify
instead
furnish
criticism
comparison
compare
behavior
storacles
principle
mechanism
someone
recognize
problem
oracle
specificatio
n
contract
comparable
past
version
inference
intend
expect
purpose
user
customer
expectation
relevant

2 [2],[5]

[1]
[1]
[1],[4],[5]
[1]-1,[3]-1,[4]-2
[1]
[1]
[1],[2],[4]
[1],[2],[3]
[1]
[1]
[1]
[1]
[1]

1 [2]
1 [2]
1 [2]
1 [2]
1 [2]
1 [2]
1 [2]
1 [2]
1 [2]
1 [2]
2 [2],[3]
2 [2],[5]
1 [2]
1 [2]
1 [2]
1 [2]
1 [2]
1 [2]
1 [2]
1 [2]
2 [2]
1 [2]
3 [1],[3],[5]
1 [2]
1 [2]
1 [2]

standard
applicable
law
criteria
primary
detect
failure
discover
correct
establish
function
properly
condition
to do
specific
scope
examinatio
n
well
execution
various
environmen
t
examining
aspect
suppose
need
current
culture
organizatio
n
separate
team
role
member
derive
use
develope
have

1 [2]
1 [2]
1 [2]
1 [2]
1 [2]
1 [2]
4 [2]-1,[3]-1,[4]-2
1 [2]
2 [2],[3]
1 [2]
4 [2]-2,[4]-1,[5]-1
1 [2]
2 [2],[5]
2 [2],[5]
1 [2]
1 [2]
1 [2]
1 [2]
1 [2]
2 [2],[3]
2 [2],[4]
1 [2]
1 [2]
2 [2],[5]
2 [2],[5]
1 [3]
1 [3]
1 [3]
1 [3]
1 [3]
1 [3]
1 [3]
1 [3]
2 [3],[5]
3 [3],[5]
1 [3]

target
audience
example
video
game
different
bank
develop
invest
can
accept
end
purchaser
attempt
make
assessment
all
caused
coding
common
source
expensive
gaps
can
testability
scalability
maintainabi
lity
usability
performanc
e
security
fault
following
programme
r
make
mistake
result

1 [3]
1 [3]
3 [3]-1,[4]-2
1 [3]
1 [3]
2 [3],[4]
1 [3]
1 [3]
1 [3]
1 [3]
1 [3]
1 [3]
1 [3]
1 [3]
2 [3],[4]
1 [3]
2 [3],[5]
1 [3]
1 [3]
1 [3]
2 [3][4]
1 [3]
1 [3]
2 [4][5]
1 [4]
2 [4][5]
1 [4]
2 [4][5]
2 [4][5]
1 [4]
2 [4]
1 [4]
1 [4]
1 [4]
1 [4]
2 [4]

fault
source
certain
situation
system
will
produce
wrong
cause
necessary
result
dead
turn
change
change
being
run
computer
hardware
platform
alteration
data
interact
single
wide
range
symptom
input
combinatio
n
fundament
all
input
initial
feasible
simple
mean
number
large

1 [4]
1 [4]
1 [4]
1 [4]
1 [4]
1 [4]
1 [4]
1 [4]
1 [4]
1 [4]
1 [4]
1 [4]
1 [4]
1 [4]
1 [4]
1 [4]
1 [4]
1 [4]
1 [4]
1 [4]
1 [4]
1 [4]
1 [4]
1 [4]
1 [4]
1 [4]
1 [4]
1 [5]
1 [5]
1 [5]
1 [5]
1 [5]
1 [5]
1 [5]
1 [5]
1 [5]
1 [5]
1 [5]

infrequent
difficult
significant
dimension
versus
compatibilit
y
reliability
highly
subjective
constitute
sufficient
value
person
they
combinatori
al
design
minimum
to get
coverage
to want
enable
greater

1 [5]
1 [5]
1 [5]
1 [5]
1 [5]
1 [5]
1 [5]
1 [5]
1 [5]
1 [5]
1 [5]
1 [5]
1 [5]
1 [5]
1 [5]
1 [5]
1 [5]
1 [5]
1 [5]
1 [5]
1 [5]
1 [5]

Concluzii
n urma elaborrii acestei lucrri m-am familiarizat mai bine cu noiunea de tokenizare i a
indexului inversat, am gsit din sursele internet cinci texte pe aceai tem i folosind softul
masterca am separat cuvintele, apoi manual le-am transferat n forma ini ial, conform
regulilor. Dup ce am efectuat aceast procedur la fiecare din texte, am elaborat un program
care face tokenizarea automata a unui volum de text. Lucrarea dat mi s-a prut interesant i
folositoare.

Programul de tokenizare automata elaborat in C:

#include <string.h>

int main ()

{
char s[256];
strcpy(s, "Software testing is an investigation conducted to provide
stakeholders with information about the quality of the product");
char* token = strtok(s, " ");
while (token) {
printf("token: %s\n", token);
token = strtok(NULL, " ");
}
return 0;p
}
REZULTATELE PROGRAMULUI:
Output:

token: Software

token: testing

token: is

token: an

token: investigation

token: conducted

token: to

token: provide

token: stakeholders

10

token: with

11

token: information

12

token: about

13

token: the

14

token: quality

15

token: of

16

token: the

17

token: product

Concluzii
n urma elaborrii acestei lucrri m-am familiarizat mai bine cu noiunea de tokenizare i a
indexului inversat, am gsit din sursele internet cinci texte pe aceai tem i folosind softul
masterca am separat cuvintele, apoi manual le-am transferat n forma ini ial, conform
regulilor. Dup ce am efectuat aceast procedur la fiecare din texte, am elaborat un program

care face tokenizarea automata a unui volum de text. Lucrarea dat mi s-a prut interesant i
folositoare.