4. 2.3. Форма поиска информации
Форма поиска (рисунок 12) содержит единственное поле для ввода аргумента поиска, в которое можно ввести только одну цифру и таблицу для вывода найденной информации. Так же нужно выбрать условие, по которому будет вестись поиск.
Рисунок 12 – Форма поиска информации
4.2.4. Форма поиска информации
Для вывода информации используются таблицы главного окна, находящиеся на вкладках «Рабочие» и «Должности» (рисунок 13 (а) и (б) соответственно).
(а)
(б)
Рисунок 13 – Таблицы вывода информации о рабочих (а) и о должностях(б)
5. Характеристика программы
Объем программы вместе с файлами данных – 1.63 Мб.
Программа не требовательна к аппаратному обеспечению компьютера. Минимальные требования для работы программы:
процессор класса Pentium
32Mб оперативной памяти
10Mб свободного места на жестком диске
ОС не ниже Windows 98.
Для успешной компиляции программы необходимо наличие следующих модулей: Windows.pas, Messages.pas, SysUtils.pas, Variants.pas, Classes.pas, Graphics.pas, Controls.pas, Forms.pas, Dialogs.pas, Menus.pas, ExtCtrls.pas, Buttons.pas, Grids.pas, ComCtrls.pas, StdCtrls.pas, Spin.pas, наличие которых предполагается в стандартной версии системы программирования Turbo
Delphi 7.0.
Для компиляции в среде Turbo Delphi необходимо открыть файл проекта программы – files_workers.dpr и нажать клавиши Ctrl+F9.
Для запуска программы нужно воспользоваться исполняемым файлом files_workers.exe.
6. Описание входных данных
Входными данными является информация о рабочих и о должностях, вводимая пользователем.
Программа предусматривает следующие режимы запуска:
Запуск программы в первый раз. В этом режиме используемые для хранения информации файлы создадутся и будут пустыми.
Последующие запуски. В этом режиме к входным данным относятся файлы списка рабочих и должностей.
К входным данным также относится аргумент поиска, передаваемый в процедуру поиска.
7. Описание выходных данных
Для данного программного продукта выходными данными являются файлы, хранящие информацию о рабочих и должностях. Поля записей файла рабочих включают в себя: код рабочего, ФИО, код должности. Файл должностей имеет записи со следующими полями: код должности, название и зарплата.
К выходным данным также относятся результаты поиска.
8. Выбор стратегии тестирования и разработка тестов
Для подготовки такого набора тестов, который позволит при заданном интервале времени, отведенном на тестирование, выявлять значительное ошибок в программном средстве (ПС), необходимо, во-первых, заранее планировать этот набор, и, во-вторых, использовать рациональную стратегию тестирования. Возможны разные подходы к выработке стратегии проектирования тестов, которые можно условно разместить (рисунок 14) между двумя крайними подходами. Левый крайний подход заключается в том, что тесты проектируются только на основании изучения спецификаций ПС (внешнего описания, описания архитектуры и спецификации модулей). Строение модулей при этом никак не учитывается. Фактически такой подход требует полного перебора всех наборов входных данных, так как в противном случае некоторые участки программ ПС могут не работать при пропуске любого теста, то есть, содержащиеся в них ошибки могут не проявляться. Однако тестирование ПС полным множеством наборов входных данных практически неосуществимо. Правый крайний подход заключается в том, что тесты проектируются на основании изучения текстов программ с целью протестировать все пути выполнения каждой программы ПС. Если принять во внимание наличие в программах циклов с переменным числом повторений, то различных путей выполнения программ ПС может оказаться также чрезвычайно много, так что их тестирование будет практически неосуществимо.
Рисунок 14 – Спектр подходов к проектированию тестов
Оптимальная стратегия проектирования тестов расположена между этими крайними подходами ближе к левому краю. Она включает проектирование значительной части тестов по спецификациям, но также требует проектирования некоторых тестов и по текстам программ. При этом в первом случае эта стратегия базируется на принципах:
На каждую используемую функцию – хотя бы один тест;
На каждую область и на каждую границу изменения какой-либо входной величины – хотя бы один тест;
На каждую исключительную ситуацию, указанную в спецификациях – хотя бы один тест.
Во втором случае эта стратегия базируется на принципе: каждая команда каждой программы ПС должна проработать хотя бы на одном тесте.
Оптимальную стратегию проектирования тестов можно конкретизировать на основании следующего принципа: для каждого программного документа (включая текст программ), входящего в состав ПС, должны проектироваться свои тесты с целью выявления в нем ошибок.
В качестве примера приведем тестирование добавления записи в файл рабочих.
Проверка заполненности полей: если хотя бы одно из полей не заполнено, то кнопка «ОК» будет неактивна и запись в файл невозможна (см. рисунок 15).
Рисунок 15-Вывод сообщения об ошибке
2. Проверка на несовпадение введенного кода с уже существующим:
при попытке добавления уже существующегономера система выдаст сообщение об ошибке (рисунок 16) и запись в файл не будет произведена.
Рисунок 16 – Попытка добавить запись с уже существующим номером
3. Проверка правильности ввода номера: при попытке ввода в поле номера букв, отрицательных чисел или прочих символов система не будет реагировать на нажатия клавиш.