Manual control and purchase of travel cards: problems

Unfortunately, most of us have to deal with the subway almost every day. There may be many things you don't like about it - it's a subjective matter. But hardly anyone is delighted with the rude attitude of controllers that has become the rule and norm. Receiving a “kick” in the legs from the turntable of the access machine, we also hear “student ID!”, or something else like this: “You have to show your student ID!! How long can you talk?!” It's annoying, isn't it?

In general, what is the essence of manual control? What is the “fun” of the so-called automatic cards in this case?? And does she even see the photo in your student photo or maybe see how valid it is? Of course not, and she doesn’t need it!! God… The main thing is to let me shout.

Well, these are emotions. Now the second case that finally brought me out and forced me to rummage through the legislation in search of an answer and consolation. This is an acquisition, more precisely extension of the student single ticket. We had magnetic cards and we lived in peace - a card, a student card and money - and you got a ticket.
Gave it to us smart cards(so-called “smart” cards). OK. They took the money and screwed it up. God bless him. But when I went to get it for the first time, they told me “passport”. I am a patient person - the next day I came with my passport. I rode quietly for a month.
It's time to renew. I give the usual set: smart card, student card, money and hear “passport”. I couldn’t stand it here. “But there’s my last name and photograph!! Here’s a student’s card. Not enough???” - I was surprised. " I can’t do it without a passport!!!" was the answer.

This, excuse me, is absurd! Who said that a student's card is not an identity document? Although this issue may be controversial. Well, what about a driver's license? Yes, there is a presidential decree according to which the passport is recognized as the main identification document, but this does not mean at all that it is the only one!

Well, let’s not discuss this topic now - you will see that this is not necessary at all.

“I can’t do it without a passport.” We read the answer in the Order of the Transport Committee of the Administration of St. Petersburg dated June 24, 2002 N 81-r “On approval of the Temporary Regulations on the procedure for the sale, circulation, use and control of tickets based on contactless smart cards for students of secondary specialized educational institutions and students institutions of higher education": When selling travel tickets at metro ticket offices, Students present their student ID and BSC(contactless smart card). When reading the BSK in the cash register, the Student’s data is authorized in the database and his right to purchase a Travel Ticket is checked (clause 3.1). Moreover, this is also supplemented by clause 3.12: The student is denied the sale of a Travel Ticket for the next validity period and the BSC coding if:

Presentation of BSK that is on the list of prohibited for use;

If the information in the metro database does not correspond to the data presented at the student ticket office, BSK;

If the registered documents (student ID, BSK) do not correspond to the identity of the bearer.

Like this! So now you can calmly shout and threaten the administration.

Now " You must show your student ID!! How long can you talk?!". Clause 3.13 of the same order gives an answer that satisfies us: If the station has the mode " Manual control of student travel tickets", then a red cross lights up on the turnstile display. In this case, the Student must approach the metro controller, present your travel card and after checking, go through the manual control point.

And who is that evil aunt after this?? Swear back! :)

By the way, although there are no problems with this (even with magnetic cards), when controlling fares on city ground passenger transport, the Student is required to have a paper ticket for the current month with the BSK attachment (clause 4.1) - note, without the student’s ticket.

Holders magnetic cards Don't be upset either. For them, the Order of the Transport Committee of the Administration of St. Petersburg dated April 27, 2002 N 45-“On improving the procedure for the sale and use of travel tickets for pupils and students” applies. Here, When purchasing a magnetic card for the first time you need a passport(clause 2.2), and in subsequent ones no longer(clause 2.3)! But with this card, unfortunately, you will have to present a student card in ground transport and during manual control in the metro (clauses 3.1 and 3.2).

Like this. Know your rights and defend yourself... with angry shouts and threats. ;)

Manual control, as stated above, is usually used in the early stages of development. All design decisions made at one stage or another should be analyzed for their correctness and appropriateness as early as possible, while they can be easily revised. Since there is no possibility of practical testing of such solutions at the early stages of development, their discussion, which is carried out in various forms, is of great importance.

There are static and dynamic approaches to manual control. With a static approach, the structure, control and information connections of the program, its input

And output. At dynamic - perform manual testing., i.e., they manually simulate the process of program execution on given initial data.

The initial data for such checks are: technical specifications, specifications, structural and functional diagrams of the software product, diagrams of individual components

And etc., and for later stages - algorithms and program texts, as well as test sets.

It has been proven that manual inspection contributes to a significant increase in productivity and reliability of programs and can be used to find from 30 to 70% of logic design and coding errors. Therefore, one or more of the manual inspection methods must be used in every software project.

The main methods of manual control are:

source text inspections,

end-to-end views,

check at the table,

program evaluations.

Source text inspections. Source text inspections are a set of procedures and techniques for detecting errors when a group of specialists examines the text. This group includes: the program author, designer, testing specialist and coordinator - a competent programmer, but not the author of the program. The general inspection procedure involves the following operations:

group members are given a program listing and specification in advance;

the programmer talks about the logic of the program and answers the inspectors’ questions;

the program is analyzed against a list of questions to identify historically common programming errors.

The list of questions for source code inspections depends on both the programming language used and the specifics of the software being developed. As an example, below is a list of questions that can be used when analyzing the correctness of programs written in Pascal.

I. Controlling data access

Are all variables initialized?

Are the maximum (or actual) sizes of arrays and strings exceeded?

Are the rows and columns confused when working? with matrices?

Are there variables with similar names?

Are the files being used? If so, is file completion checked when entering from a file?

Do the types of values ​​written and read match?

Are untyped variables, open arrays, or dynamic memory used? If so, do the variable types match when "overlaying" the format? Do indexes go beyond array boundaries?

2. Calculation control

Are the expressions written correctly (the order of the operators)?

Are calculations performed correctly on non-arithmetic variables?

Are calculations performed correctly with variables of various types (including using integer arithmetic)?

Is it possible that there is a bit grid overflow or a machine zero situation?

Do the calculations meet the specified accuracy requirements?

Are there comparisons between variables of different types?

3. Control transfer control

Will the loops terminate correctly?

Will the program be completed?

Are there loops that will not execute due to violation of entry conditions? Will the calculations continue correctly?

Are there search cycles? Are “element found” situations handled correctly?

And "element not found"?

4. Monitoring of intermodule interfaces

Do the parameter and argument lists match in order, type, and units?

Does the routine change arguments that should not be changed?

Is there a scope violation for global and local variables with the same name?

In addition to directly detecting errors, the inspection results allow the programmer to see other errors he has made and have the opportunity to evaluate his programming style, choice of algorithms and testing methods. Inspection is a way of early identifying parts of a program that are more likely to contain errors, which allows testing to focus on these parts.

End-to-end views. Walkthrough, like inspection, is a set of methods for detecting errors carried out by a group of people viewing the program text. This review has much in common with the inspection process, but differs in the procedure and methods for detecting errors. The end-to-end control group consists of three to five people: a chairman or coordinator, a secretary who records all errors, a testing specialist, a programmer and an independent expert. End-to-end viewing involves performing the following procedures:

group members are given a program listing and specification in advance;

meeting participants are offered several tests;

meeting participants mentally perform each test in accordance with the logic of the program, while the state of the program (variable values) is tracked on paper or a board;

If necessary, the programmer is asked questions about the design logic and assumptions made.

IN Most end-to-end reviews find fewer errors when running the tests themselves than when interviewing a programmer.

Checking at the table. Historically, this method of manual testing was the first to appear, since it does not require a team of specialists. This is a source text check or end-to-end scan performed by one person who reads the program text, checks it for possible errors against a special list of frequently encountered errors, and “passes” test data through the program. Based on testing principles, testing at the table should be carried out by a person who is not the author of the program. The method is the least effective, since the verification is a completely disordered process, with no exchange of opinions and healthy competition.

Program evaluation. This method is not directly related to testing, but its use also improves the quality of programming. It is used to anonymously evaluate a program in terms of its overall quality, ease of use, and clarity. The purpose of the method is to provide a relatively objective assessment and self-assessment of programmers.

This assessment is performed as follows. A programmer is selected who must perform the duties of a process administrator. The administrator recruits a group of six to 20 participants who should develop similar programs. Each participant is invited to submit two programs for consideration, from his point of view - the best and the worst. Selected programs are randomly distributed among participants. They are given four programs - two best and two worst, but they are not told which programs are bad and which are good. The programmer reviews these programs and fills out a questionnaire in which he evaluates the quality of the programs on a seven-point scale.

After this, the assessment results are verified, and the evaluator provides general comments and recommendations for improving the programs.

9.3. Structural testing

Structural testing is called also by testing along “routes”, since in this case test sets are formed by analyzing the routes provided by the algorithm. In this case, subroutes are understood as sequences of program statements that are executed under a specific variant of the source data.

Structural testing is based on the concept of testing all program routes as completely as possible. So, if the program algorithm includes branching, then with one set of initial data a sequence of operators can be executed that implements the actions that one branch provides, and with the second - another. Accordingly, there will be routes for the program that differ in the option chosen during branching.

A program is considered to be fully verified if, with the help of tests, it is possible to execute the program along all possible routes of control transfers. However, it is easy to see that even in a program of average complexity the number of non-repeating routes can be very large, and, therefore, complete or exhaustive testing of routes is usually impossible.

The structured approach to testing has a number of disadvantages. So the test suites built using this strategy:

do not detect missing routes;

do not detect errors that depend on the data being processed, for example, in the if (a - b) statement< eps - пропуск функции абсолютного значения abs проявится только, если а < Ь;

do not guarantee that the program is correct, for example, if instead of sorting in descending order, sorting in ascending order is implemented.

To generate tests, the program is represented in the form of a graph, the vertices of which correspond to program statements, and the arcs represent possible options for transferring control. Below is the text of a program that determines the value of x depending on the values ​​of the procedure parameters. The algorithm of this program is presented in Fig. 9.2, a, and the corresponding graph of control transfers is in Fig. 9.2,6.

Procedure t(a, b: rеа1; var x: real); begin

if (a1) and (b=0) then x: =x/a; if (a=2) or (x>1) then x: =x+1;

The formation of test sets for testing routes can be carried out according to several criteria:

operator coverage;

coverage of decisions (transitions);

coverage conditions;

coverage of decisions/conditions;

combinatorial coverage of conditions.

Operator coverage. The operator coverage criterion implies a selection of tests such that each program operator is executed at least once. This is a necessary but not sufficient condition for acceptable testing. Let us explain this with an example.

For a fragment whose algorithm and graph are presented in Fig. 9.2, it would be possible to execute each statement once, setting as input data a = 2, b = 0, x = 3. But it follows from the second condition that the variable x can take any value, and in some versions of the Pascal language this value will not be checked (!).

Besides:

if, when writing a program, the first condition states: (a > 1) or (b = 0), then the error will not be detected;

if in the second condition instead of x > 1 x > 0 is written, then this error will also not be detected;

there is a path 1-2-4-6 (see Fig. 9.2, b), in which x does not change at all and, if there is an error here, it will not be detected.

Thus, although when testing it is indeed necessary to set the initial data so that all program statements are executed at least once, this is clearly not enough to test the program.

Coverage of solutions (transitions). To implement this criterion, it is necessary to have such a number and composition of tests that the result of checking each condition (i.e., the decision) takes the values ​​“true” or “false” at least once.

It is easy to see that the solution coverage criterion satisfies the operator coverage criterion, but is “stronger”.

The program, the algorithm of which is presented in Fig. 9.2, a, can be tested using the solution coverage method with two tests covering either paths: 1-2-4-6, 1-2-3-4-5-6, or paths: 1-2-3-4-6, 1-2-4-5-6, for example:

a = 3, b = 0, x = 3 - path 1-2-3-4-5-6;

a = 2, b = 1, x = I - path 1-2-4-6.

However, the path where x does not change will be tested with a probability of 50%: if in the second condition, instead of the condition x > 1, x is written< 1, то этими двумя тестами ошибка обнаружена не будет.

Coverage conditions. The condition coverage criterion is even “stronger” than the previous ones. In this case, a certain number of tests are generated, sufficient to ensure that all possible results of each condition in the solution are performed at least once.

However, as with solution coverage, this criterion does not always result in every statement being executed at least once. The criterion requires the addition that control must be transferred to each entry point at least once.

The program, the algorithm of which is presented in Fig. 9.2a, checks four conditions:

Tests that satisfy this condition:

A = 2, b = 0, x = 4 - path 1-2-3-4-5-6, conditions: 1 - yes, 2 - yes, 3 - yes, 4 - yes;

a = 1, b = 1, x = 1 - path 1-2-4-6, conditions: 1 - no, 2 - no, 3 - no, 4 - no.

The condition coverage criterion often satisfies the solution coverage criterion, but not always. Tests of the condition coverage criterion for the previously discussed examples cover the results of all solutions, but this is a coincidence. For example, tests:

a = 1, b = 0, x = 3 - path 1-2-3-6, conditions: 1 - no, 2 - yes, 3 - no, 4 - yes;

a = 2, b = 1, x = 1 - path 1-2-3-4-5-6, conditions: 1 - yes, 2 - no, 3 - yes, 4 - no

cover the results of all conditions, but only two of the four results of decisions: the result “true” of the first decision and the result “false” of the second are not satisfied.

The main disadvantage of the method is its lack of sensitivity to errors in logical expressions.

Decision/condition coverage. According to this method, tests must be designed so that all possible results of each condition and all results of each decision are executed at least once, and control is transferred to each statement at least once.

Manual control, as stated above, is usually used in the early stages of development. All design decisions made at one stage or another should be analyzed for their correctness and appropriateness as early as possible, while they can be easily revised. Since there is no possibility of practical testing of such solutions at the early stages of development, their discussion, which is carried out in various forms, is of great importance.

There are static and dynamic approaches to manual control. At static approach, they analyze the structure, control and information connections of the program, its input

and output data. At dynamic - perform manual testing., i.e., they manually simulate the process of program execution on given initial data.

The initial data for such checks are: technical specifications, specifications, structural and functional diagrams of the software product, diagrams of individual components

etc., and for later stages - algorithms and program texts, as well as test sets.

It has been proven that manual inspection contributes to a significant increase in productivity and reliability of programs and can be used to find from 30 to 70% of logic design and coding errors. Therefore, one or more of the manual inspection methods must be used in every software project.

The main methods of manual control are:

Source text inspections,

End-to-end views

Checking at the table

Program evaluations.

Source text inspections. Source text inspections are a set of procedures and techniques for detecting errors when a group of specialists examines the text. This group includes: the program author, designer, testing specialist and coordinator - a competent programmer, but not the author of the program. The general inspection procedure involves the following operations:

Group members are given a program listing and specification in advance;

The programmer talks about the logic of the program and answers the inspectors’ questions;

The program is analyzed against a list of questions to identify historically common programming errors.

The list of questions for source code inspections depends on both the programming language used and the specifics of the software being developed. As an example, below is a list of questions that can be used when analyzing the correctness of programs written in Pascal.

I. Control of data access

Are all variables initialized?

Are the maximum (or actual) sizes of arrays and strings exceeded?

Are the rows and columns confused when working? With matrices?

Are there variables with similar names?

Are the files being used? If so, is file completion checked when entering from a file?

Do the types of values ​​written and read match?

Are untyped variables, open arrays, or dynamic memory used? If so, do the variable types match when "overlaying" the format? Do indexes go beyond array boundaries?

2. Control of calculations

Are the expressions written correctly (the order of the operators)?

Are calculations performed correctly on non-arithmetic variables?

Are calculations performed correctly with variables of various types (including using integer arithmetic)?

Is it possible that there is a bit grid overflow or a machine zero situation?

Do the calculations meet the specified accuracy requirements?

Are there comparisons between variables of different types?

3. Control transfer control

Will the loops terminate correctly?

Will the program be completed?

Are there loops that will not execute because the entry condition is violated? Will the calculations continue correctly?

Are there search cycles? Are “element found” situations handled correctly?

and "element not found"?

4. Control of intermodule interfaces

Are the parameter and argument lists consistent in order, type, and units?

Does the routine change arguments that should not be changed?

Is there a scope violation for global and local variables with the same name?

In addition to directly detecting errors, the inspection results allow the programmer to see other errors he has made and have the opportunity to evaluate his programming style, choice of algorithms and testing methods. Inspection is a way of early identifying parts of a program that are more likely to contain errors, which allows testing to focus on these parts.

End-to-end views. End-to-end review, like inspection, is a set of methods for detecting errors carried out by a group of people viewing the program text. This review has much in common with the inspection process, but differs in the procedure and methods for detecting errors. The end-to-end control group consists of three to five people: a chairman or coordinator, a secretary who records all errors, a testing specialist, a programmer and an independent expert. End-to-end viewing involves performing the following procedures:

Group members are given a program listing and specification in advance;

Participants in the meeting are offered several tests;

Participants in the meeting mentally perform each test in accordance with the logic of the program, while the state of the program (variable values) is tracked on paper or a board;

If necessary, the programmer is asked questions about the design logic and assumptions made.

Checking at the table. Historically, this method of manual testing was the first to appear, since it does not require a group of specialists. This is a source text check or end-to-end scan performed by one person who reads the program text, checks it for possible errors against a special list of frequently encountered errors, and “passes” test data through the program. Based on testing principles, testing at the table should be carried out by a person who is not the author of the program. The method is the least effective, since the verification is a completely disordered process, with no exchange of opinions and healthy competition.

Program evaluation. This method is not directly related to testing, but its use also improves the quality of programming. It is used to anonymously evaluate a program in terms of its overall quality, ease of use, and clarity. The purpose of the method is to provide a relatively objective assessment and self-assessment of programmers.

This assessment is performed as follows. A programmer is selected who must perform the duties of a process administrator. The administrator recruits a group of six to 20 participants who should develop similar programs. Each participant is invited to submit two programs for consideration, from his point of view - the best and the worst. Selected programs are randomly distributed among participants. They are given four programs - two best and two worst, but they are not told which programs are bad and which are good. The programmer reviews these programs and fills out a questionnaire in which he evaluates the quality of the programs on a seven-point scale.

After this, the assessment results are verified, and the evaluator provides general comments and recommendations for improving the programs.