Автор работы: Пользователь скрыл имя, 07 Сентября 2014 в 22:54, курсовая работа
Актуальность исследования сведена к тому, что в настоящее время широкое распространение получили многочисленные локальные сети в самом разнообразном виде: от коммутации двух, рядом расположенных, компьютеров до вычислительных систем со сложной системой прав доступа к отдельным ресурсам сети и т.д. Естественно появляется проблема о наиболее удобном и рациональном способе хранении данных и получении возможности ими воспользоваться. Данный вопрос достаточно значим, т.к. безопасность и в тоже время интуитивно понятный интерфейс играют большую роль в процессе разработки и внедрения программы в структуру сети. Эту проблему решают файловые менеджеры. Основной задачей таких программ является предоставление удобного интерфейса для работы с файлами. Оболочки для работы с файлами написаны для многих операционных систем таких как: Windows, Linux, MS DOS, UNIX, OS\2 и т.д.
{удалим из его имени скобки}
Delete(FileName, 1, 1);
Delete(FileName, Length(Item.Name), 1);
{...выполним необходимые действия...} End; End;
Вместо «необходимых действий» можно организовать непосредственный вывод файла на экран, либо запомнить его для дальнейшей обработки.
Для вывода списка на экран логично воспользоваться компонентом ListView закладки Win32. Он позволяет создавать для каждой строки несколько колонок с описанием свойств объекта, а также отображать рядом иконку. Присвоим нашему компоненту ListView имя lvFiles.
После того как мы реализовали процедуру вывода списка файлов и каталогов переходим к реализации возможности выбора диска для работы.
Для выбора диска мы использовали компонент DriveComboBox закладки Win 3.1. Он автоматически определяет количество подключенных дисков, их метки, и отображает соответствующие иконки. Назовем наш компонент именем dcbxDrive.
В обработчике события OnChange следует произвести изменение текущего пути и вызвать вывод списка файлов и каталогов.
Пример кода:
CurrentFullPath:=dcbxDrive.
GetAndShowFiles;
Следующим шагом при программировании приложения «Файловый менеджер» была реализована процедура перемещения по каталогам системы.
После вывода списка файлов в lvFiles неплохо было бы позволить пользователю перемещаться по каталогам. Для этого следует отслеживать двойной щелчок мыши или нажатие Enter. В обработчик события необходимо вставить проверку строки, которую указал пользователь, чтобы определить, является ли выбранный объект каталогом. Если это действительно каталог, то следует изменить текущий путь на новый, и снова выполнить действия по выводу списка файлов и каталогов.
Одна из важнейших возможностей любого файлового менеджера это запуск приложений. Причем запускаться должна не только исполняемые файлы (exe, com, bat), но файлы типа avi, bmp, jpg, rar, doc, xls и др. Конечно на самом деле запускаются не сами эти файлы, а программы, которые способны их обработать. К счастью, Windows предоставляет нам такую возможность довольно легко. Делается это с помощью API-функции ShellExecute.
ShellExecute( HWND hwnd); // дескриптор порождающего окна
LPCTSTR lpOperation, // указатель на строку, с командой
LPCTSTR lpFile, // указатель на запускаемый файл
LPCTSTR lpParameters, // указатель на строку с параметрами запуска
LPCTSTR lpDirectory, // указатель на строку с рабочей директорией
INT nShowCmd); // режим запуска приложения
Возвращаемое значение является дескриптором запущенной программы либо кодом ошибки (если меньше 32).
Для простого запуска программ необходимо, чтобы lpOperation:=’open’ и nShowCmd:=SW_SHOWNORMAL.
Для начала необходимо в отловить двойной щелчок или нажатие Enter для компонента lvFiles и убедится, что выбранный объект является файлом. Затем необходимо подготовить параметры для функции ShellExecute и вызвать ее.
Пример кода:
Procedure ExecuteAnyFile(FileName:
Var WorkDir:String;
Begin
FileName:=FileName+#0;
WorkDir:=CurrentFullPath+#0;
ShellExecute(0, 'open', @FileName[1], nil, @WorkDir[1], SW_SHOWNORMAL); End;
Добавление кода нуля (#0) в конце строки и вызов через @FileName[1] необходимы для приведения типа String к типу PСhar.
Дальше мы приступили к разработке процедур, которые отвечают за операции с файлами и каталогами.
Файловый менеджер обязан уметь выполнять различные действия над файлами. Но прежде чем что сделать с файлом или каталогом нужно получить в свое распоряжение его имя и путь до него. Для этого необходимо отслеживать выделенный элемент из lvFiles и знать является ли он файлом или каталогом. Будем предполагать, что в переменной FileName мы будем передавать уже полученное имя файла или каталога.
Удаление файлов: файл удаляется с помощью функции DeleteFile. В качестве параметра передается полное имя файла, а результат истинен, если удаление прошло успешно.
Пример кода:
Procedure DeleteAnyFile(FileName:String)
Begin If SysUtils.DeleteFile(
{...удаление прошло успешно...}
Else {...удаление не удалось...}; End;
Использование конструкции SysUtils.DeleteFile необходимо, чтобы исключить конфликт с такой же API-функцией.
Удаление каталогов: удаление каталогов происходит аналогично удалению файлов, только вместо DeleteFile следует использовать RemoveDir.
Следует заметить, что удалить можно только пустой каталог.
Пример кода:
Procedure DeleteAnyDir(FileName:String);
Begin If RemoveDir (CurrentFullPath+FileName) Then
{...удаление прошло успешно...}
Else {...удаление не удалось...}; End;
Создать каталог также просто, как и удалить, используется функция CreateDir.
Пример кода:
Procedure CreateAnyDir(FileName:String);
Begin If CreateDir(CurrentFullPath+
{...создание прошло успешно...}
Else {...создание не удалось...}; End;
Для копирования файла необходимо использовать API-функцию CopyFile.
CopyFile(LPCTSTR lpExistingFileName); //указатель на имя файла-источника
LPCTSTR lpNewFileName, // указатель на имя файла-приемника
BOOL bFailIfExists // что делать, если файл-приемник уже существует
Если bFailIfExists=False, то в случае существования файла-приемника функция прервется, а если bFailIfExists=False, то файл будет перезаписан.
Пример кода:
Procedure CopyAnyFile(FileName, NewFullFileName:String);
Var FromF, ToF:String;
Begin FromF:=CurrentFullPath+
ToF:=NewFullFileName+#0;
If CopyFile(@FromF[1], @ToF[1], True) Then
{...копирование прошло успешно...}
Else {...копирование не удалось...}; End;
Переименование и перемещение как файлов, так и каталогов реализуется с помощью API-функции MoveFile.
MoveFile
LPCTSTR lpExistingFileName, // указатель на имя старого файла
LPCTSTR lpNewFileName // указатель на имя нового файла );
Пример кода:
Procedure RenMovAnyFileDir(FileName, NewFullFileName:String);
Var FromF, ToF:String;
Begin FromF:=CurrentFullPath+
ToF:=NewFullFileName+#0;
If MoveFile(@FromF[1], @ToF[1]) Then
{...переименование/
{...переименование/перемещение не удалось...};End;
Итак, мы рассмотрели особенности построения и работы алгоритма программы, основные процедуры, с помощью которых был реализован функционал программного продукта «Файловый менеджер».
Программный код созданного нами приложения «Файловый менеджер» находится в Приложении 2. Теперь перейдём к тестированию полученного программного продукта и выясним, насколько правильно работает наше приложение. Этой теме посвящён следующий параграф.
Стратегия тестирования - это план проведения работ по тестированию системы или её модуля, учитывающий специфику функциональности и зависимости с другими компонентами системы и платформы. Стратегия определяет типы тестов, которые нужно выполнять для данного функционала системы, включает описание необходимых подходов с точки зрения целей тестирования[5].
Стратегия тестирования отвечает на вопросы [8]:
Тестирование программного обеспечения (ПО) - это процесс выполнения программ на некотором наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ. Указанный набор данных называется тестовым или просто тестом [10].
Для оптимизации набора тестов, т.е. для подготовки такого набора тестов, который позволял бы при заданном их числе (или при заданном интервале времени, отведенном на тестирование) обнаруживать большее число ошибок в ПО, необходимо, во-первых, заранее планировать этот набор и, во-вторых, использовать рациональную стратегию планирования тестов. Проектирование тестов можно начинать сразу же после завершения этапа внешнего описания ПО. Возможны разные подходы к выработке стратегии проектирования тестов, которые можно условно графически разместить между следующими двумя крайними подходами (Рис. 2) [5].
Рис. 2. Спектр подходов к проектированию тестов.
Оптимальная стратегия проектирования тестов расположена внутри интервала между этими крайними подходами, но ближе к левому краю. Она включает проектирование значительной части тестов по спецификациям, но она требует также проектирования некоторых тестов и по текстам программ. При этом в первом случае эта стратегия базируется на принципах[6]:
Рассмотрим подробнее методики тестирования «чёрный ящик» и метод тестирования «белый ящик».
Метод тестирования «чёрный ящик». Долгое время основным способом тестирования было тестирование методом «черного ящика» - программе подавались некоторые данные на вход и проверялись результаты, в надежде найти несоответствия [9]. При этом, как именно работает программа, считается несущественным. Отметим, что даже при таком подходе необходимо иметь спецификацию программы для того, чтобы было с чем сравнивать результаты.
Этот подход до сих пор является самым распространенным в повседневной практике, но у него есть целый ряд недостатков. Во-первых, таким способом невозможно найти взаимоуничтожающихся ошибок, во-вторых, некоторые ошибки возникают достаточно редко (ошибки работы с памятью) и потому их трудно найти и воспроизвести.
Метод тестирования «белый ящик». Метод тестирования, которые изучают не только внешнее поведение программы, но и ее внутреннее устройство (исходные тексты). Такие методики обобщенно называют тестированием «белого ящика». Назовем некоторых представителей этого класса методик: чтение программ, формальные просмотры программ, инспекции и т.п.). Основной трудностью подобных методов является сложность отслеживания вычислений времени выполнения [8].
При тестировании программы методом «белый ящик» происходит проверка логики программы. Полным тестированием в этом случае будет такое, которое приведет к перебору всех возможных путей. Даже для средних по сложности программ числом таких путей может достигать десятков тысяч.
Критерии тестирования. Поскольку исчерпывающее структурное тестирование невозможно, необходимо выбрать такие критерии его полноты, которые допускали бы их простую проверку и облегчали бы целенаправленный подбор тестов. Наиболее слабым из критериев полноты структурного тестирования является требование хотя бы однократного выполнения каждого оператора программы. Более сильным критерием является критерий: каждая ветвь алгоритма (каждый переход) должна быть пройдена (выполнена) хотя бы один раз [15].
Изучение этих методов тестирования показывает, что они дополняют друг друга, то есть различные методы находят разные ошибки. Поэтому наиболее эффективные процессы разработки программного обеспечения используют некоторую комбинацию методик "черного ящика" и "белого ящика".
Теперь проведём тестирование созданного нами программного продукта «Файловый менеджер». Для тестирования приложения была выбрана комбинация методик «черного ящика» и «белого ящика».
Протестируем основные функции программы а это: открытие файлов, копирование файлов, перемежение файлов, удаление файлов, создание новых каталогов. Результаты тестирования приложения мы видим в Табл.1. Ниже приведены критерии тестирования программного продукта.
Таблица 1
Функции прилож. |
Открытие файлов |
Копирование файлов |
Перемещение файлов |
Удаление файлов |
Создание новых каталогов |
№ | |||||
1. |
+ |
+ |
+ |
+ |
+ |
2. |
+ |
+ |
+ |
+ |
+ |
3. |
+ |
+ |
+ |
+ |
+ |
4. |
+ |
+ |
+ |
+ |
+ |