Типовая Программа и методика тестирования типового программного комплекса, эксплуатируемого в системе Банка России, на соответствие 2000 году (разработана Департаментом информатизации ЦБР 6 января 1999 г.)

Типовая Программа и методика тестирования
типового программного комплекса, эксплуатируемого в системе Банка России, на соответствие 2000 году
(разработана Департаментом информатизации ЦБР 6 января 1999 г.)


Одобрена Рабочей группой по решению Проблемы 2000 г.
в информационных системах Банка России 26 января 1999 г.)


1. Объект тестирования


1.1. Объектом тестирования является программное обеспечение типового прикладного программного комплекса или типовой информационной системы (далее - ТПК), обеспечивающее необходимую информационно-программную поддержку банковской задачи при ее решении до, во время и после наступления 2000 года.

1.2. Состав предъявляемого для тестирования ТПК должен обеспечивать проведение тестирования в полном объеме согласно настоящей Программе и соответствовать принятой стратегии тестирования.


2. Цель тестирования


2.1. Целью тестирования является проверка ТПК на соответствие 2000 году, при этом его производительность и функциональность, определенные Техническим заданием, не изменятся после приведения ТПК в готовность к 2000 году по следующим критериям.

1) Никакое значение для текущей даты не должно вызвать прерывания в работе.

2) Функциональные возможности ТПК, связанные с датой, должны быть одинаковыми до, во время и после наступления 2000 года.

3) Во всех интерфейсах, базах данных (БД), архивах столетие в любой дате должно определяться либо явно, либо недвусмысленными алгоритмами или правилами логического вывода.

4) 2000 год должен распознаваться как високосный.

2.2. Основным содержанием тестирования ТПК является проверка надежности программного обеспечения с точки зрения выполнения заданных функций ТПК в соответствии с "Постановкой задачи" в условиях соблюдения критериев соответствия ТПК 2000 году согласно п.2.1.

2.3. В качестве дополнительных компонентов предложенного для тестирования ТПК могут рассматриваться следующие компоненты.

2.3.1. Информационное обеспечение в части:

- соответствия структуры БД (архива) ТПК;

- информационного обмена между компонентами ТПК.

2.3.2. Обеспечение информационной безопасности в части:

- проверки правомерности доступа пользователя;

- защиты от несанкционированного доступа.


3. Общие положения


3.1. Настоящая программа и методика тестирования ТПК предназначены для Разработчика ТПК при проведении им тестирования ТПК на соответствие 2000 году.

3.2. Тестирование ТПК проводится на стенде тестирования Разработчика в соответствии с "Постановкой задачи" на тестируемый ТПК, настоящей Программой и методикой тестирования в сроки по согласованию с Заказчиком (в лице Департамента информатизации Банка России).

3.3. Тестирование ТПК проводит Разработчик с участием представителя поставщика (производителя) системно-технического обеспечения ТПК и представителя Заказчика. Заказчик представляется группой экспертов, уполномоченной на подписание итогового Протокола.

3.4. Все компоненты системно-технического обеспечения ТПК, а также компоненты его прикладного обеспечения должны быть предварительно локально протестированы на соответствие 2000 году. Разработчик должен иметь документ, подтверждающий готовность входящих компонентов к 2000 году.


4. Объем тестирования


4.1. Соответствие ТПК 2000 году осуществляется проверкой его надежности с точки зрения выполнения заданных в "Постановке задачи" функций, включая проверку ошибок при вводе, функционирование в заданных режимах, выполнение программы обработки в случае ошибочных ситуаций, восстановление результата при сбое ТПК.

4.2. Проверка надежности осуществляется по трем определяющим ее критериям согласно ГОСТ Р ИСО/МЭК 9126-93: стабильность, устойчивость к ошибке, восстанавливаемость.

4.2.1. Проверка стабильности ТПК включает:

- правильность обработки входного документа (файла);

- полноту обработки ошибочных ситуаций;

- контроль корректности входных данных;

- проверку параметров по диапазону значений;

- обработку граничных значений;

- обработку неопределенностей.

4.2.2. Проверка устойчивости ТПК к ошибке включает:

- диагностирование ошибочно заданного формата даты во входных данных;

- возможность автоматического обхода ошибочной ситуации при вводе неправильного формата даты;

- правильное завершение работы ТПК при "неправильном" обозначении проблемного года;

- проверку устойчивости работы ТПК при искаженном представлении "проблемной" даты;

- возможность автоматического обнаружения ошибочно выдаваемой даты службой системного времени (BIOS, OS), выдачу диагностических сообщений.

4.2.3. Проверка восстанавливаемости ТПК включает:

- функционирование средств восстановления ТПК в случае появления ошибки при вводе или обработке;

- время формирования заданного результата при задании ошибочной ситуации (неправильной "проблемной" даты) согласно Приложению.

4.3. Проверка по указанным критериям осуществляется путем обработки стандартного и необходимого объема "копий реальных" данных с помощью комплексного теста, подготовленного согласно Приложению.

"Копии реальных" данных на обработку передаются разработчиком в виде файла на магнитном носителе в формате входного документа (или входного массива при взаимодействии с системой передачи данных). Допускается представление экспертами дополнительных тестов по оценке ТПК на соответствие 2000 году.

4.4. Результаты тестирования считаются верными, если при последовательной обработке комплексных тестов (см. Приложение) они в полной мере отвечают требованиям метрики качества "Полнота программного обеспечения" согласно ГОСТ Р ИСО/МЭК 9126-93, то есть подтверждаются:

- реализация всех основных функций;

- реализация всех частных функций;

- реализация всех алгоритмов;

- реализация всех взаимосвязей;

- реализация всех межмодульных интерфейсов;

- реализация возможностей настройки;

- реализация интерфейсов с пользователями.

При этом сформированные выходные данные (отчеты) отвечают "Постановке задачи".


5. Условия и порядок проведения тестирования


5.1. Сроки проведения тестирования за 2 недели согласуются Разработчиком с Заказчиком (в лице Департамента информатизации) на основании предложения Разработчика.

5.2. Тестирование осуществляется на стенде, использующем системно-технические средства, включая ТС, ОС, СУБД и средства разработки приложений, прошедшие тестирование на соответствие 2000 году по критериям п.2.1.

5.3. Тестирование заканчивается оформлением итогового протокола согласно п.6.2, который подписывается руководителем коллектива Разработчика, представителем поставщика и группой экспертов.


6. Отчетность


6.1. В процессе тестирования ведется "Журнал тестирования", в котором отмечается прохождение комплексного теста согласно разделам 1, 2, 3 Приложения.

В Журнале фиксируются даты, вызвавшие ошибочное выполнение или сбой программы.

6.2. Тестирование завершается оформлением "Протокола о результатах тестирования", в котором отражаются полученные результаты тестирования в соответствии с п.4.4 настоящей Программы и дается заключение о степени соответствия программного обеспечения ТПК критериям 2000 года.

Допускается составление "Протокола об ошибках", выявленных в ходе тестирования, в котором указываются сроки их устранения и при необходимости - срок повторного тестирования.


Приложение


Рекомендации для подготовки комплексных тестов


Тестирование ТПК на соответствие 2000 году должно подтвердить, что функциональность и производительность ТПК не подвержены влиянию даты до, во время и после наступления 2000 года. Для оценки такого соответствия необходимо в контрольных примерах предусматривать следующие тесты.

В тесты следует включать допустимые для ТПК значения дат.


1. Тесты для критерия 1:

"Никакое значение для текущей даты не должно вызвать прерывания в работе"


1.1. ТПК должен осуществить обработку входных данных, использующих следующие переходы от даты к дате:


От даты К дате Причины проверки
31 декабря 1998 1 января 1999 Последняя смена года перед 2000 годом
28 февраля 1999 1 марта 1999 Распознавание 1999 года как невисо-
косного
8 апреля 1999 9 апреля 1999 Проблемы 9999 по юлианскому календарю
не существует (9 апреля 1999 - 99-й
день 1999 года)
9 апреля 1999 10 апреля 1999 Проблемы 9999 по юлианскому календарю
не существует (9 апреля 1999 - 99-й
день 1999 года)
31 августа 1999 1 сентября 1999 Первый раз встретились хх/9/99
8 сентября 1999 9 сентября 1999 Проблемы 9999 по григорианскому ка-
лендарю не существует (9 сентября
1999 - 9/9/99)
9 сентября 1999 10 сентября 1999 Проблемы 9999 по григорианскому ка-
лендарю не существует (9 сентября
1999 - 9/9/99)
31 декабря 1999 1 января 2000 Первый раз встретилась ситуация, в
которой может выдаваться "нулевой"
год
9 января 2000 10 января 2000 Первая дата, требующая 7-символьного
поля даты (2000-1-10)
31 января 2000 1 февраля 2000 Конец первого месяца 2000 года
27 февраля 2000 28 февраля 2000 Существующая функциональность остает-
ся неизменной
28 февраля 2000 29 февраля 2000 2000 год распознается как високосный
29 февраля 2000 1 марта 2000 2000 год распознается как високосный
31 марта 2000 1 апреля 2000 Конец первого квартала 2000 года
9 октября 2000 10 октября 2000 Первая дата, требующая 8-символьного
поля даты (2000-10-10)
31 декабря 2000 1 января 2001 Смена года с 00 на 01
28 февраля 2001 1 марта 2001 Распознавание високосного года рабо-
тает для лет после 2000 года (2001
год - невисокосный)
28 февраля 2004 29 февраля 2004 Распознавание високосного года рабо-
тает для лет после 2000 года
29 февраля 2004 1 марта 2004 Распознавание високосного года рабо-
тает для лет после 2000 года

1.2. Если обычный диапазон обрабатываемых дат выходит за вышеуказанный диапазон, должны выполняться дополнительные тесты.

1.3. Если ТПК производит обработку трансакций, должны разрабатываться тесты для имитации трансакций, возникающих на выборке вышеуказанных границ.

1.4. Если ТПК осуществляет прогнозные вычисления, должна выполняться проверка правильности восприятия будущей даты.


2. Тесты для критерия 2 и критерия 4:

"Функциональные возможности ТПК, связанные с датой, должны быть одинаковыми до, во время и после 2000 года", "2000 год должен распознаваться как високосный"


2.1. Если ТПК проверяет входные данные, они должны тестироваться для следующих значений:


Правильные даты
31 декабря 1998 1 января 1999
27 февраля 1999 28 февраля 1999
1 марта 1999 9 сентября 1999
31 декабря 1999 1 января 2000
27 февраля 2000 28 февраля 2000
29 февраля 2000 1 марта 2000
31 декабря 2000 1 января 2001
28 февраля 2001 1 марта 2001
28 февраля 2004 29 февраля 2004
1 марта 2004  
Неправильные даты
31 апреля 1998 29 февраля 2001
29 февраля 1999 30 февраля 2004
30 февраля 2000  
1 января 00 1 января 99

2.2. Если ТПК выполняет сортировку или вычисления, включающие даты и промежутки времени, должны тестироваться следующие периоды времени:


Промежуток времени Причина проверки
С середины 1999 до 1999-12-31 Обработка последнего года перед
наступлением 2000 года
С середины 1999 до 2000-01-01 Граница столетия обрабатывается
правильно
С середины 1999 до 2000-02-28 Високосный день обрабатывается
правильно
С середины 1999 до 2000-02-29 Високосный день обрабатывается
правильно
С середины 1999 до 2000-03-01 Високосный день был добавлен
С середины 1999 до 2000-04-01 Високосный день был добавлен
С середины 1999 до середины 2001 2000 год имеет 366 дней
С середины 2000 до середины 2001 Граница между 2000-12-31 и
2001-01-01 обрабатывается правиль-
но

Для проверки правильности подсчета числа дней между двумя датами и увеличения или уменьшения даты на число дней можно воспользоваться следующими данными:


Начальная дата Конечная дата Число дней
1999-12-31 1999-12-31 0
1999-12-31 2000-01-01 1
1999-12-31 2000-02-28 59
1999-12-31 2000-03-01 61
1999-02-28 1999-02-29 Ошибка
1998-12-31 1999-03-01 60
1995-12-31 1996-02-28 59
1995-12-31 1996-03-01 61

Для проверки правильности формирования порядковой даты могут использоваться следующие данные:


Дата День года Порядковая дата
1999-02-28 59 1999059
1999-02-29 Ошибка Ошибка
1999-12-31 365 1999365
2000-01-01 1 2000001
2000-02-28 59 2000059
2000-02-29 60 2000060
2000-03-31 61 2000061

2.3. Если ТПК вычисляет дни недели на основе дат, программное обеспечение должно тестироваться на правильность работы в следующих условиях:


Тест Причина проверки
1 января 1900 был понедельник (но-
мер дня недели - 1)
Существующая функциональность оста-
ется неизменной
28 февраля 1900 была среда (номер
дня недели - 3)
Существующая функциональность оста-
ется неизменной
1 марта 1900 был четверг (номер дня
недели - 4)
Не было 29 февраля 1900 года
вследствие правила столетия
28 февраля 1999 будет воскресенье
(номер дня недели - 7)
Существующая функциональность оста-
ется неизменной
1 марта 1999 будет понедельник (но-
мер дня недели - 1)
Существующая функциональность оста-
ется неизменной
31 декабря 1999 будет пятница (но-
мер дня недели - 5)
Существующая функциональность оста-
ется неизменной
1 января 2000 г. будет суббота (но-
мер дня недели - 6)
Отличить эту дату от 1900-01-01
(понедельник)
28 февраля 2000 г. будет понедель-
ник (номер дня недели - 1)
Отличить эту дату от 1900-02-28
(среда)
29 февраля 2000 г. будет вторник
(номер дня недели - 2)
Не было 29 февраля 1999 года
вследствие правила столетия
1 марта 2000 г. будет среда (номер
дня недели - 3)
Проверить, что 2000-02-29 учитыва-
ется
1 января 2001 г. будет понедельник
(номер дня недели - 1)
Проверить, что 2000 год обрабатыва-
ется как имеющий 366 дней
28 февраля 2004 г. будет суббота
(номер дня недели - 6)
Проверить, что вычисления, связан-
ные с високосным годом, выполняются
правильно
29 февраля 2004 г. будет воскре-
сенье (номер дня недели - 7)
Проверить, что вычисления, связан-
ные с високосным годом, выполняются
правильно
1 марта 2004 г. будет понедельник
(номер дня недели - 1)
Проверить, что вычисления, связан-
ные с високосным годом, выполняются
правильно

2.4. Если ТПК выводит дату на экраны или в отчеты, следует проверить правильность и однородность отображения.

2.5. Если ТПК обрабатывает вводимый файл, должны разрабатываться тесты для проверки правильности использования даты, вводимой файлом.

2.6. Если ТПК отмечает в поле записи текущую дату и/или время, должны разрабатываться тесты для проверки правильности записи и следующего чтения отмеченной даты.


3. Тесты для критерия 3:

"Во всех интерфейсах, базах данных, архивах столетие в любой дате должно определяться либо явно, либо недвусмысленными алгоритмами или правилами логического вывода"


3.1. Если ТПК хранит даты, следует проверить все операции с поиском даты. Если используются правила логического вывода, то должны проверяться все граничные условия. Например, если ТПК делает вывод, что даты со значением года 50<=уу<=99 представляют на самом деле годы 19уу, а даты 00<=уу<=49 представляют годы 20хх, то тесты для уу=48, 49, 50, 51, 99, 00, 01, 02 должны выполняться подпрограммами ТПК, использующими дату.

3.2. Если ТПК импортирует/экспортирует дату, необходимо тестировать правильность работы ТПК при:

- импортировании неправильных дат и правильных дат с двухсимвольными годами;

- импортировании неправильных дат и правильных дат с четырехсимвольными годами;

- экспортировании диапазона дат с 1 января 1950 года по 31 декабря 2050 года.

3.3. Если дата передается другому ТПК (например, через канал связи), должны разрабатываться тесты для дат в пересылаемых данных, обрабатываемых программой-получателем.



Типовая Программа и методика тестирования типового программного комплекса, эксплуатируемого в системе Банка России, на соответствие 2000 году (Разработана Департаментом информатизации ЦБР 6 января 1999 г. Одобрена Рабочей группой по решению Проблемы 2000 г. в информационных системах Банка России 26 января 1999 г.)


Текст программы опубликован в "Вестнике Банка России" от 31 марта 1999 г., N 20


Откройте нужный вам документ прямо сейчас или получите полный доступ к системе ГАРАНТ на 3 дня бесплатно!

Получить доступ к системе ГАРАНТ

Если вы являетесь пользователем интернет-версии системы ГАРАНТ, вы можете открыть этот документ прямо сейчас или запросить по Горячей линии в системе.