Программный комплекс учета оборудования торгового эквайринга для отделения ПАО "Сбербанк"

Размещено на http://www.allbest.ru/

СОДЕРЖАНИЕ

• ВВЕДЕНИЕ
• 1. АНАЛИЗ ПРОГРАММНО-ТЕХНИЧЕСКИХ РЕШЕНИЙ ПО УЧЕТУ ОБОРУДОВАНИЯ ТОРГОВОГО ЭКВАЙРИНГА
• 1.1 Анализ средств автоматизации учета оборудования
• 1.2 Обзор существующих вариантов решения
• 1.2.1 КОРУС 23.02 (ООО «СТАНС»)
• 1.2.2 IT Invent 1.60 (YuKoSoft)
• 1.2.3 Hardware Inspector (Database Harbor Software)
• 1.3. Выбор решения и его обоснование
• 2. РАЗРАБОТКА АРХИТЕКТУРЫ ПРОГРАММНОГО КОМПЛЕКСА УЧЕТА ОБОРУДОВАНИЯ
• 2.1 Реализация функций
• 2.2 Система управления контентом
• 2.3 Выбор CMS
• 2.4 CMS Joomla
• 2.5 Менеджер пользователей
• 3 РАЗРАБОТКА СТРУКТУР ДАННЫХ И БАЗ ДАННЫХ ПРОГРАММНОГО КОМПЛЕКСА УЧЕТА ОБОРУДОВАНИЯ
• 3.1 Пользователи системы
• 3.2 Определение категорий пользователей
• 3.3 Регистрация пользователей
• 3.4. Структура информационной базы данных
• 4. РАЗРАБОТКА АЛГОРИТМОВ АВТОМАТИЗАЦИИ УЧЕТА ОБОРУДОВАНИЯ
• 4.1 Алгоритмы действий пользователей
• 5. РАЗРАБОТКА И РЕАЛИЗАЦИЯ ПРОГРАММНЫХ МОДУЛЕЙ
• 5.1 Структура программного комплекса
• 5.2. Стандартные классы, методы и объекты Joomla, используемые в разработке
• 5.2.1Предопределенные константы
• 5.2.2Класс JFactory
• 5.2.3HTTP-запрос (класс JRequest)
• 5.2.4Приложение (класс JApplication). Очередь сообщений
• 5.2.5Перенаправление
• 5.3Структура компонента
• 5.3.1Парадигма MVC
• 5.3.2Файловая структура компонента
• 5.3.3Содержание каталога admin
• 5.3.4Содержание каталога site
• 5.4Разработка компонента
• 5.4.1. Примеры формирования запросов к БД
• 5.4.2Создание производных классов JTable
• 5.4.3Функция сохранения данных
• 5.4.4Функция вывода записей
• 5.4.5Проверка заполнения полей
• 6. ЭКСПЕРИМЕНТАЛЬНОЕ ТЕСТИРОВАНИЕ И ОТЛАДКА МОДУЛЕЙ
• 6.1 Тестирование программного обеспечения
• 6.2 Уровни тестирования
• 6.3 Статическое и динамическое тестирование
• 6.4 Тестирование «белого ящика» и «чёрного ящика»
• 6.5 Покрытие кода
• 6.5.1 Виды тестирований
• 6.5.2 Классификация по объекту тестирования
• 6.5.3 Классификация по знанию системы
• 6.5.4 Классификация по степени автоматизации
• 6.5.5 Классификация по степени изолированности компонентов
• 6.5.6 Классификация по времени проведения тестирования
• 6.5.7 Классификация по признаку позитивности сценариев
• 6.5.8 Классификация по степени подготовленности к тестированию
• 6.5.9 Использованные методы тестирования и их результаты
• 6.5.10 Руководство пользователя
• 7. ОЦЕНКА КАЧЕСТВА РАЗРАБОТАННОГО ПРОДУКТА
• 7.1 Сертификация
• 7.2 Вторичные стандарты качества
• 7.3 Государственные стандарты Российской Федерации
• 7.4 Определение оценки качества разработанного продукта
• ЗАКЛЮЧЕНИЕ
• СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
• ВВЕДЕНИЕ
• Целью данной выпускной квалификационной работы является создание программы учета оборудования торгового эквайринга в Вологодском отделении Сбербанка.
• Современный Сбербанк является одним из крупнейших банков в России и Европе. Это не мешает ему открыто и добросовестно конкурировать на банковском рынке и оставаться в курсе последних финансовых и технологических событий. Сбербанк не только остается в курсе веяний рынка, но и задает их, уверенно ориентируясь в стремительно меняющихся технологиях и предпочтениях клиентов.
• На долю Сбербанка в российском банковском секторе по общему объему активов приходится 28, 7% совокупных банковских активов (по состоянию на 1 января 2016 года).
• Сбербанк -- универсальный банк, предоставляющий широкий спектр банковских услуг. Его доля в общем объёме активов российского банковского сектора составляла на 1 января 2016 года 28, 7 %; на рынке частных вкладов -- 46 %; кредитный портфель соответствовал 38, 7 % всех выданных кредитов населению.
• Спектр услуг Сбербанка для розничных клиентов весьма многообразен: от традиционных депозитов и различных видов кредитования до банковских карт, денежных переводов, банковского страхования и брокерских услуг.
• Стремясь сделать обслуживание более удобным, современным и технологичным, Сбербанк с каждым годом все более совершенствует возможности дистанционного управления счетами клиентов. В банке создана система удаленных каналов обслуживания, в которую входят:

1) онлайн-банкинг «Сбербанк Онлайн» (более 13 млн активных пользователей);

2) мобильные приложения «Сбербанк Онлайн» для смартфонов (более 1 млн активных пользователей);

3) SMS-сервис «Мобильный банк» (более 17 млн активных пользователей);

4) одна из крупнейших в мире сетей банкоматов и терминалов самообслуживания (более 86 тыс. устройств).

Среди клиентов Сбербанка -- более 1 млн предприятий (из 4, 5 млн зарегистрированных юридических лиц в России). Банк обслуживает все группы корпоративных клиентов, причем на долю малых и средних компаний приходится более 35% корпоративного кредитного портфеля банка[1].

В наши дни все большее количество торгово-сервисных точек (ТСТ) наряду с наличным расчетом принимает оплату по банковским картам, осуществляя операции посредством POS-терминалов. Сбербанк как раз является лидером в данной отрасли.

POS-терминал - это электронное программно-техническое устройство для приема к оплате денежных средств по пластиковым картам, оно может принимать карты с чип-модулем, магнитной полосой и бесконтактные карты, а также другие устройства, имеющие бесконтактный интерфейс. Также под POS-терминалом часто подразумевают весь программно-аппаратный комплекс, который установлен на рабочем месте кассира.

Под POS-терминалом также понимается аппаратно-программный комплекс, позволяющий осуществлять торговые операции, как и обычный кассовый аппарат. Помимо учёта продаж, POS-терминал может накапливать и другие данные для их последующего анализа. POS-терминал имеет интерфейс взаимодействия с пользователем для облегчения поиска нужного товара и получения его характеристик: цены, сроков годности, аннотации и т. д.; формирования фискальных чеков; подсчета сдачи; выполнения различных отчетов[2].

Поэтому требуется создать такой проект, который удовлетворял бы всем необходимым требованиям по учету POS-терминалов.

1. АНАЛИЗ ПРОГРАММНО-ТЕХНИЧЕСКИХ РЕШЕНИЙ ПО УЧЕТУ ОБОРУДОВАНИЯ ТОРГОВОГО ЭКВАЙРИНГА

1.1 Анализ средств автоматизации учета оборудования

Для учета банковского оборудования требуется специальная система, которая будет отвечать всем необходимым требованиям: учет POS-терминалов, пинпадов, сим-карт, которые используются для связи с банком, при проведении операции, дат установки, ремонта, замены, возврата оборудования. Исходя из этих требований, мной и будет разработана автоматизированная система учета оборудования торгового эквайринга.

Эквайринг (от англ. acquire -- приобретать, получать) -- приём к оплате платёжных карт в качестве средства оплаты товара, работ, услуг. Осуществляется уполномоченным банком-эквайрером (англ. acquiring bank) путём установки на торговых или сервисных предприятиях (ТСП) платёжных терминалов (POS-терминалов).

1.2 Обзор существующих вариантов решения

1.2.1 КОРУС 23.02 (ООО «СТАНС»)

КОРУС (компьютеры, оргтехника, расходные материалы - учет и сопровождение) - программа для учета, имеющегося вычислительного оборудования и техники. Ее предназначение - решение разнообразных задач, связанных с учетом компьютеров и оргтехники. Состоит из комплекта программ для учета оргтехники, расходных материалов, сетевого оборудования; автоматизации процесса плановой инвентаризации; печати отчетных документов (актов ввода, списания, технического состояния и пр.); администрирования системы.

Функции КОРУС:

1) учет закупок техники. Постановка техники на учет и списание (с формированием соответствующих актов);

2) учет перемещения техники по различным подразделениям организации;

3) учет производимых ремонтов техники, замены частей и производимой профилактики учитываемого оборудования;

4) настраивается на работу в сети и разных филиалах одной организации;

5) получение всевозможных отчетов, по любой хранимой информации в программе;

6) многопользовательская работа с разграничением прав доступа в программе;

7) возможность учета средств, находящихся в разных филиалах одной организации или в разных организациях, получение совместных и раздельных отчетов[3].

1.2.2 IT Invent 1.60 (YuKoSoft)

Данная программа позволяет вести инвентаризацию компьютеров, IT оборудования, программного обеспечения, комплектующих и расходных материалов. Учет ведется в рамках организаций и их филиалов.

Ключевые особенности программы:

1) учет компьютеров и сопутствующей офисной техники.

2) поддержка базы данных MS Access и MS SQL Server.

3) многопользовательский режим работы - все филиалы работают с единой базой.

4) возможность создания и настройки собственных дополнительных свойств различных типов.

5) прикрепление изображений и файлов к объектам учёта.

6) учет Заказов поставщикам на все виды учетных единиц.

7) модуль инвентаризации с автоматической обработкой результатов.

8) ведение истории изменений в ключевых полях объектов учета.

9) учет ремонтов и профилактических обслуживаний оборудования и компьютеров.

10) логическое связывание программ и комплектующих с оборудованием.

11) закрепление учетных единиц за сотрудниками организации. Акты приёма-передачи.

12) ведение базы поставщиков, сервисных организаций и прочих контрагентов.

13) гибкое разграничение прав доступа.

14) большое количество уже встроенных печатных форм и отчетов с возможностью их редактирования.

15) импорт и просмотр данных напрямую из Active Directory.

16) импорт данных из Excel/CSV файлов[4].

1.2.3 Hardware Inspector (Database Harbor Software)

Hardware Inspector - это программа предназначенная для автоматизированного учета компьютеров. Она позволяет всегда быть в курсе о всех ваших компьютерах, получать разнообразные отчеты, планировать его обслуживание, ремонт и обновление.

Основные возможности последней версии Hardware Inspector:

1) детальный учет устройств. На каждое устройство заводится технический паспорт, в котором отражается информация о его покупке, основных технических параметрах, его перемещение по рабочим местам и обслуживания.

2) учет лицензий на установленное программное обеспечение. На каждую лицензию заводится паспорт, в котором отражается вся информация: о покупке, параметрах, истории ее перемещений по рабочим местам.

3) встроенный учет заявок от пользователей, поступающих в ИТ-отдел. История сообщений в заявке, прикрепляемые файлы и прочее. Возможность совместной работы с веб-интерфейсом.

4) учет расходных материалов. Программа позволяет вести учет поступления на склад и выдачи расходных материалов, а также планирование их потребности на основе статистики расхода за прошлые периоды.

5) наглядное дерево подразделений и рабочих мест. Дерево рабочих мест организации может отображаться в двух разрезах: организационное представление (оргструктура) и территориальное (карта).

6) визуализация компьютеров на поэтажных планах. Расположение рабочих мест на плане помещения помогает визуальному восприятию размещения компьютеров в сети.

7) инвентаризация компьютеров. Механизм инвентаризации с использованием штрих-кодов показывает наличие устройств на рабочих местах в данный момент времени.

8) аудит рабочих мест. Данный инструмент проведения инвентаризации выявляет отклонения информации в базе данных от реального состояния конфигурации.

9) кроссировка сети. Механизм кроссировки в сети позволяет отображать или планировать сетевые подключения внутри организации.

10) реестр документов. С помощью реестра осуществляется связь устройств с бухгалтерской документацией, а так же позволяет следить за отчетными документами по поставкам техники партиями, отслеживать выполнение поставок поставщиком и отчитываться бухгалтерии по документам.

11) перемещение устройств и лицензий. Оборудование или лицензия может перемещаться между рабочими местами.

12) автоматизированное добавление устройств посредством импорта их описаний из отчетов различных программ занимающихся анализом оборудования.

13) большой набор различных отчетов. Отчеты могут экспортироваться в форматы: PDF, MS Word, MS Excel, Open Office и другие.

14) механизмы поиска информации. Фильтры поиска.

15) гибкое разграничение доступа. Большой перечень прав доступа к доступным функциям и данным позволяет удобно настроить возможности каждого оператора базы данных.

16) многопользовательский доступ к базе данных[5].

1.3 Выбор решения и его обоснование

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

При работе в банковской системе важно, чтобы информация о POS-терминале обновлялась как можно быстрее, для этого необходимо размещение данного ресурса в глобальной сети Интернет. Однако, создавать сайт с нуля- это трудоемкий процесс, который занимает большое количество времени. Существуют свободно распространяемые системы управления контентом, которые позволяют развернуть сайт на веб-сервере или хостинге в самые короткие сроки. Одной из самых распространенных и функциональных CMS является Joomla, на которой я и остановил свой выбор. Данные о сравнении программного обеспечения представлены ниже в таблице 1.1.

Основными характеристиками Joomla являются:

1) полностью основанный на БД движок с использованием PHP/MySQL.

2) встроенный модуль безопасности для многоуровневой аутентификации пользователей и администраторов.

3) полностью настраиваемые схемы расположения элементов, включая всевозможные блоки меню.

4) работа под такими операционными системами как Linux, FreeBSD, MacOSX, Solaris, AIX, SCO, WinNT, Win2K.

5) является свободно распространяемым программным обеспечением

6) имеет регулярную поддержку и обновление

Проект предполагается выполнить в виде расширения Joomla.

Инструментальные средства разработки:

– CMS Joomla 2.5.6

– Веб-сервер IIS 7.0

– PhpMyAdmin 4.0.4.2

– Язык программирования PHP, JavaScript;

– СУБД MySQL 5.6.13

Таблица 1.1 - Сравнение программного обеспечения

Название программы	Обновление программы	Бесплатная версия	Создание отчетов	Поддержка баз данных	История действий пользователей	Работа сайта в сети интернет	Разграничение прав
КОРУС	+	нет бесплатных версий	+	-	+	Более дорогая версия	-
IT Invent	+	до 200 записей	импорт данных в Excel	+	+	+	+
Hardware Inspector	+	нет бесплатных версий	+	+	+	+	+
CMS Joomla	+	свободно распространяемое ПО	+	+	+	+	+

2. РАЗРАБОТКА АРХИТЕКТУРЫ ПРОГРАММНОГО КОМПЛЕКСА УЧЕТА ОБОРУДОВАНИЯ

2.1 Реализация функций

За реализацию функций отвечают две составляющие:

Аппаратная - технические средства для реализации программных функции (это сервер и сопутствующее серверное оборудование);

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

Аппаратная часть включает в себя сервер со следующими основными характеристиками:

– Процессоры:Intel®xeon®CPUX5650(2.67ГГц)(2шт.);

– ОЗУ:12Gb

– Программная часть:

– ПО сервера:

– OS:Windows Server 2008 R2

– Web-server:IIS7.0

– PHP5.3.27

– ПО, используемой для разработки:

– CMS Joomla 2.5.6

– СУБД MySql

Данный сервер является стандартным для Сбербанка.

Общий вид программно-аппаратного комплекса представлен ниже.



Структура программно-аппаратного комплекса

Функциональный анализ

программный учет оборудование эквайринг

2.2 Система управления контентом

Система управления содержимым (контентом) (англ. Content management system, CMS) -- информационная система или компьютерная программа, используемая для обеспечения и организации совместного процесса создания, редактирования и управления контентом (то есть содержимым).

Основные функции CMS:

Управление содержимым: хранение, контроль версий, соблюдение режима доступа, управление потоком документов и т. п.

Представление информации в удобном виде.

В системе управления контентом находятся самые различные данные: документы, мультимедиа данные, телефонные номера, научные данные и так далее[7].

2.3 Выбор CMS

Так как согласно задачам создаваемого проекта к системе должны иметь доступ пользователи с разными правами, для реализации проекта выберем CMS Joomla, где уже организованы списки контроля доступа Access Control List (ACL). Это список контроля доступа, в котором отображаются и настраиваются права доступа на веб-сайте, включая пункты: просматривать, создавать, редактировать, удалять, вход в систему.

2.4 CMS Joomla

Система подходит для различного вида корпоративных сайтов или информационных проектов. Приведем основные характеристики Joomla:

– Полностью основанное на БД ядро программы с использованием PHP/MySQL;

– Многоуровневый модуль безопасности для аутентификации пользователей/администраторов;

– Разделы тем могут быть добавлены авторами;

– Полностью настраиваемые схемы расположения элементов, включая левый, правый и центральный блоки меню;

– Форум/Опросы/Голосования для эффективной обратной связи;

– Работа под такими операционными системами как Linux, FreeBSD, MacOSX, Solaris, AIX, SCO, WinNT, Win2K.

2.5 Менеджер пользователей

В Joomla пользователям уделяется все больше внимания и постепенно расширяются возможности настройки. Менеджер пользователей в Joomla 2.5.6 имеет большой набор функций управления и расширенные настройки - это создание групп пользователей, добавление заметок с категориями к пользователям, задание уровней доступа, настройка и отправка массовой рассылки и управление правами групп пользователей.

При установке Joomla существует стандартный набор прав и групп пользователей: гости, зарегистрированные, авторы, редакторы, издатели, менеджеры, администраторы и супер-администраторы.

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

Рисунок 2.1- Настройка прав доступа пользователей

3. РАЗРАБОТКА СТРУКТУР ДАННЫХ И БАЗ ДАННЫХ ПРОГРАММНОГО КОМПЛЕКСА УЧЕТА ОБОРУДОВАНИЯ

3.1 Пользователи системы

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

3.2 Определение категорий пользователей

Каждый пользователь имеет свой уровень доступа к имеющейся информации и свои возможности работы с системой. Категории пользователей с их функциями в системе приведены в таблице 3.1.

Таблица 3.1 - Категории пользователей

Наименование роли	Работник/Должностное лицо	Функция
Технический администратор	Техник, программист, инженер, инженер-программист	Регистрация пользователей, наделение их правами в системе, осуществление контроля над работой системы, предотвращение ошибок и устранение возникающих последствий, обновление/редактирование логической структуры БД, консультационная поддержка.
Сотрудник банка	Инженер	Просмотр имеющихся сведений, редактирование, добавление новых данных
Руководитель отдела	Начальник отдела/структурного подразделения	Просмотр имеющихся сведений, формирование отчетной документации.

3.3 Регистрация пользователей

Регистрация пользователей в системе осуществляется посредством стандартных средств CMS Joomla техническим администратором с выдачей данных авторизации - логина и пароля.

3.4 Структура информационной базы данных

База данных является основой создаваемого программного продукта, поэтому содержит в себе таблицы-справочники, позволяющие пользователю по минимуму сократить ввод данных при оформлении POS терминалов. Эти справочники заполняются и редактируются техническим администратором.

Таблицы базы данных, описание данных содержащихся в них подробно описаны в таблице 3.2.

Таблица 3.2 - Структура базы данных

Имя таблицы	Наименование поля	Тип/размер поля	Содержащееся значение
Name_pos	id_name	Int(3)	Первичный ключ
	name_pos	Varchar(50)	Наименование модели терминала
Operator	id_operatora	Int(3)	Первичный ключ
	name_operator	Varchar(10)	Название оператора связи
Region	id_region	Int(3)	Первичный ключ
	name_region	Varchar(50)	Название района установки
Interface_pos	id_interface	Int(3)	Первичный ключ
	name_interface	Varchar(20)	Тип интерфейса работы терминала
Pinpad	id_pinpad	Int(3)	Первичный ключ
	pinpad	Varchar(12)	Тип пин-пада
Pos_type	id_pos_type	Int(3)	Первичный ключ
	type	Varchar(30)	Тип терминала
Pos	id_name id_operatora id_region id_interface id_pinpad id_pos_type id_pos	Int(3) Int(3) Int(3) Int(3) Int(3) Int(3) Int(3)	Первичный ключ наименования модели Первичный ключ оператора Первичный ключ региона Первичный ключ интерфейса Первичный ключ пинпада Первичный ключ типа pos-терминала Первичный ключ pos-терминала
	data_ystanovki	Date	Дата установки
	data_remonta	Date	Дата ремонта
	address	Varchar(60)	Адрес установки терминала
	nomer_sim	Int(21)	Номер сим-карты
	sn_pos	Varchar(18)	Серийный номер терминала
	sn_pinpad	Varchar(15)	Серийный номер пинпада

ЛОГИЧЕСКАЯ СХЕМА БАЗЫ ДАННЫХ

Методология IDEF0 используется для моделирования широкого круга предметных областей, и применяться как технология проектирования систем на логическом уровне. Процесс моделирования систем в IDEF0 начинается с построения контекстной диаграммы. Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействие с внешней средой[8].

Контекстная диаграмма данной модели ИС представлена на рисунке 3.1.



Рисунок 3.1 - Контекстная диаграмма ИС

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

Описание стрелок контекстной диаграммы представлено в таблице 3.1.

Таблица 3.1 - Стрелки контекстной диаграммы

Наименование стрелки	Описание	Тип
Данные по оборудованию	Поступление данных о оборудовании	Input
Пользователи системы	Технический администратор, работники банка и клиенты банка.	Mechanism
Информационная система	Система, контролирующая процессы	Mechanism
Отчет по учету оборудования	Отчеты по учету оборудования	Output
Правила учета оборудования	Перечень правил учета оборудования	Control

Диаграмма декомпозиции 1-го уровня представлена на рисунке 3.2



Рисунок 3.2 - Диаграмма декомпозиции 1-го уровня

Сначала происходит авторизация пользователя, затем, пользователи попадают в главное меню. Последовательно вносятся данные об оборудовании, и создается отчет об учтенном оборудовании.

Диаграмма декомпозиции 2-го уровня представлена на рисунке 2.3.

Рисунок 3.3 - Диаграмма декомпозиции 2-го уровня

Диаграмма декомпозиции 2-го уровня представлена для блока «Вход в систему». В ней наглядно показано как происходит проверка данных идентификации пользователя и дальнейший переход в главное меню информационной системы. Описание функциональных блоков IDEF0 представлено в таблице 3.2.

Таблица 3.2. - Описание функциональных блоков IDEF0

Наименование блока	Описание решаемых задач
Вход в систему	Происходит вход в систему с доступом к имеющимся функциям.
Внесение данных о терминале	На этом этапе происходит занесение данных о терминале.
Ввод данных о пинпаде	Занесение данных о пинпаде и типе пинпада.
Внесение данных о сим-карте	Пользователь заносит данные о сим-карте
Создание отчета о оборудовании	На данном этапе составляется отчет о оборудовании.
Ввод логина и пароля	На этом этапе пользователь заполняет поля данными выданными ему техническим администратором.
Проверка правильности ввода	На этом этапе происходит проверка правильности ввода логина и пароля.

IDEF3 - это технология для сбора данных, которые требуются для проведения структурного анализа системы. Данная технология используется как дополнение к IDEF0 для разработки моделей, в которых изучается последовательность выполнения действий и взаимосвязей между ними[9].

Диаграмма IDEF3 для автоматизации учета оборудования представлена на рисунке 3.4.

Рисунок 3.4 - Диаграмма IDEF3

Описание функциональных блоков IDEF3 представлено в таблице 3.3.

Таблица 3.3 - Описание функциональных блоков IDEF3

Наименование блока	Описание решаемых задач
Получить данные о оборудовании из внешних источников	На этом этапе происходит получение информации из внешних источников.
Посмотреть данные о оборудовании	На этом этапе происходит просмотр данных о уже занесенном оборудовании.
Добавить данные о оборудовании	Добавление данных в систему.
Редактировать данные о оборудовании	Редактирование данных уже занесенного оборудования.
Сохранить добавленные или измененные данные	Производиться сохранение измененных данных о оборудовании.

Диаграммы потоков данных (Data Flow Diagram) используются для документирования механизмов передачи и обработки информации в моделируемой системе. Диаграммы DFD обычно строят для того чтобы наглядно отобразить текущую работу системы документооборота организации.

Диаграммы потоков данных DFD моделируют систему как набор действий, соединенных друг с другом стрелками, отражают передачу информации от одной функции к другой[10].

В диаграмме, изображенной на рисунке 3.5 имеются хранилища данных.

Рисунок 3.5 - Диаграмма DFD

Описание функциональных блоков DFD представлено в таблице 3.4.

Таблица 3.4 - Описание функциональных блоков DFD

Наименование блока	Описание решаемых задач
Занести данные в программу	Данные о оборудовании с внешних носителей заносятся в базу данных программы.
Выгрузить данные в виде отчета	Формируется отчет по дате оказания услуги. Создается выборка по заданному критерию

Основные элементы модели представлены в таблице 3.5.

Таблица 3.5 - Основные элементы модели

Список данных	Перечень объектов	Хранилища данных	Внешние сущности
Данные об оборудовании	Занести данные с внешних носителей в базу данных	Таблица выбора оборудования	Информация о оборудовании с внешних носителей База данных программы
Сформированный отчет	Выгрузить данные в виде отчета	-	Внешний документ отчета об оборудовании

4. РАЗРАБОТКА АЛГОРИТМОВ АВТОМАТИЗАЦИИ УЧЕТА ОБОРУДОВАНИЯ

4.1 Алгоритмы действий пользователей

На рисунке 4.1 представлен алгоритм действий технического администратора, для реализации различных функций в программе.

Рисунок 4.1 - Алгоритм действий технического администратора

На рисунке 4.2 представлен алгоритм реализации функций доступных сотрудникам банка.

Рисунок 4.2 - Алгоритм действий сотрудника банка

На рисунке 4.3 представлен алгоритм реализации функций доступных руководителю отдела.



Рисунок 4.3 - Алгоритм действий руководителя отдела

На рисунке 4.4 представлена работа алгоритма проверки уникальности оборудования. Данный алгоритм проверяет учтено ли уже данное оборудование.



Рисунок 4.4 - Алгоритм проверки уникальности оборудования.

5. РАЗРАБОТКА И РЕАЛИЗАЦИЯ ПРОГРАММНЫХ МОДУЛЕЙ

5.1 Структура программного комплекса

В качестве основания для серверной части программы используется ОС Windows 8.1, а также сервер БД MySQL версии 3.23.58, и PHP 5для обеспечения работы скриптов.

Выбранный в качестве СУБД, сервер баз данных MySQL - это компонент программной системы предназначенный для хранения и предварительной обработки всех данных используемых системой. Mysql - это масштабируемый высокопроизводительный SQL сервер баз данных, совершенный по простоте инсталляции, использования и обслуживания. MySQL является собственностью компании MySQL AB. Входит в LAMP.

Гибкость данного СУБД обеспечивается поддержкой большого количества типов таблиц, таких как: MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей[11].

Язык PHP - это скриптовый язык программирования, созданный для генерации HTML-страниц на веб-сервере и работы с базами данных. Входит в LAMP -- «стандартный» набор для создания веб-сайтов (Linux, Apache, MySQL, PHP (Python или Perl)). Интерпретатор PHP подключается к веб-серверу либо через модуль, созданный специально для этого сервера (например, для Apache или IIS), либо в качестве CGI-приложения. Кроме этого, он может использоваться для решения административных задач в операционных системах UNIX, GNU/Linux, Microsoft Windows, Mac OS X и AmigaOS. Реализация проекта в рамках CMS Joomla невозможна без использования стандартных средств используемой системы управления контентом. В ходе реализации будут применены предустановленные плагины, модули, классы и библиотеки.

5.2 Стандартные классы, методы и объекты Joomla, используемые в разработке

5.2.1 Предопределенные константы

В Joomla определен ряд констант, хранящих значения путей: JPATH_BASE - это путь к корневой директории текущего приложения; JPATH_ROOT - это путь к корневой директории сайта, JPATH_COMPONENT - это путь к директории компонента, JPATH_COMPONENT_SITE - это путь к фронтенду компонента, JPATH_COMPONENT_ADMINISTRATOR - это путь к бэкенду компонента и т.д. Все эти константы возвращают значения абсолютных путей в файловой системе. Если вам необходимо получить путь для использования в URL, следует воспользоваться методом JURI::base().

В файле index.php, расположенном в корневой директории Joomla, определена константа _JEXEC. Большинство PHP-файлов, написанных под Joomla, начинаются с выражения defined('_JEXEC') or die('Restricted access');

5.2.2 Класс JFactory

В Joomla существует статический класс JFactory, реализующий паттерн "фабрика". Методы данного класса (getApplication(), getDate(), getDbo(), getDocument(), getLanguage(), getURI(), getUser(), getMailer(), getEditor() и др.) позволяют получить доступ к соответствующим глобальным объектам фреймворка (JApplication, JDate, JDatabase, JDocument, JLanguage, JURI, JUser, JMail, JEditor и др.). Пример получения доступа к объекту JUser:

$user =& JFactory::getUser();

if ($user->guest)

echo "Вы не вошли на сайт";

else

echo "Вы вошли на сайт как ".$user->name;

5.2.3 HTTP-запрос (класс JRequest)

В Joomla вместо непосредственного использования глобальных массивов $_GET, $_POST, $_FILES, $_COOKIE, $_ENV, $_SERVER и $_REQUEST удобнее применять класс JRequest. Его методы пропускают данные, введенные пользователем, через фильтр во избежание инъекций.

Для получения переменных запроса GET/POST используется метод mixed getVar(string $name, string $default=null, string $hash='default', string $type='none', int $mask=0), где:

$nameимя переменной;

$defaultзначение по умолчанию, которое вернет метод getVar(), если значение переменной не задано;

$hashисточник данных, по умолчанию они будут получены из массива $_REQUEST. Явное указание массива GET или POST повысит безопасность кода;

$typeтип ожидаемого значения:

INT

INTEGER

FLOAT

DOUBLE

BOOL

BOOL

WORD

ALNUM допускает только буквенно-цифровые значения;

CMD

BASE64 допускает только те символы, которые могут быть представлены в кодировке base64 (т.е. a-z, A-Z, 0-9, /, + и =);

STRING

ARRAY

PATH исключает возможность атаки. Например, если исходное значение содержало /./ или/../, то вместо него метод вернет пустую строку;

USERNAMEудаляет управляющие символы (0x00 - 0x1F), 0x7F, <, >, ", ', % и &;

$maskконстанта, задающая опции фильтрации:

JREQUEST_NOTRIMне удалять пробелы в начале и конце строки;

JREQUEST_ALLOWRAWбез какой-либо фильтрации;

JREQUEST_ALLOWHTMLне удалять HTML-код, но пропустить значение через фильтр (в частности, удалить опасные теги - script, applet, iframe и др.).

Эти константы не заключаются в кавычки, т.к. это не строки, а статические переменные. Если ни одной опции не задано, то HTML-теги, а также пробелы в начале и конце строки будут удалены.

Например, получим массив $_POST:

$arr = JRequest::get('post');

Для присвоения переменным запроса значений используется метод string setVar(string $name, string $value=null, string $hash='method', bool $overwrite=true)

Если $overwrite=false и в запросе уже задано значение переменной $name, то метод просто вернет само это значение. В противном случае переменной будет присвоено значение $value, а метод вернет старое значение $name.

Класс JRequest содержит также методы, позволяющие получить значение определенного типа: getBool(), getCmd(), getFloat(), getInt(), getString(), getWord().

5.2.4 Приложение (класс JApplication). Очередь сообщений

В Joomla существует очередь сообщений - массив строк, которые будут выведены на экран при следующей загрузке какой-либо страницы. Стандартными являются три типа сообщений: message (собственно сообщение), notice(предупреждение) и error (ошибка).

Для добавления сообщений в очередь используется метод void enqueueMessage(string $msg, [string $type = 'message']), где:

$msg- текст сообщения;

$type- тип сообщения.Например:

global $app;

$app->enqueueMessage('Message');

$app->enqueueMessage('Notice', 'notice');

$app->enqueueMessage('Error', 'error');

5.2.5 Перенаправление

Для перенаправления пользователя к другому URL используется метод void redirect(string $url, string $msg='', string $msgType='message', bool $moved=false), где:

$url- URL, к которому перенаправляется пользователь;

$msg- сообщение, которое должно быть при этом выведено;

$msgType- тип сообщения;

$moved- при значении true браузер получит код состояния "301 Permanently Moved", в противном случае - "303 See Other".

Данный метод добавляет сообщение к очереди сообщений, перенаправляет браузер пользователя к заданному URL и завершает работу приложения Joomla[13].

5.3 Структура компонента

Разработка любого приложения начинается с анализа его структуры. Так как компонент создается на базе Joomla он должен соответствовать общим требованиям.

5.3.1 Парадигма MVC

В общем виде компонент Joomla состоит из следующих основных составляющих: это административная часть, или админка (Backend) и публичная, или пользовательская часть (Frontend). Первая предназначена исключительно для разработчика или администратора сайта и невидима для основных посетителей сайта. Она нужна для настройки параметров компонента. Вторая часть, или frontend, видна и доступна всем пользователям и является "лицом" компонента, поскольку именно она отображается посетителю сайта. В большинстве шаблонов публичной части компонента отводится вся центральная часть, где отображается основная информация сайта. В Joomla один из самых популярных и используемых стандартных компонентов - это com_content, который управляет отображением материалов и статей Joomla и выводит их по центру шаблона в виде текста статьи.

В свою очередь, как административная, так и пользовательская части каждая состоит из более мелких составляющих: это модель (model), представление (view) и контроллер (controller). Они тесно взаимодействуют между собой и образуют так называемую парадигму MVC (model-view-controller).

Контроллер (controller) - это специальный PHP-класс, который "принимает" входящий HTTP-запрос пользователя и отвечает за его дальнейшую маршрутизацию к другим частям компонента. Если представлять компонент как чёрный ящик, то контроллер - это вход в компонент. Когда пользователь переходит по страницам сайта Joomla, ходит по меню, разделам и т.д. первой частью компонента, с которым он работает в данный момент, всегда будет контроллер. Контроллер как бы "доводит" запрос пользователя до более глубинных частей компонента, таких как модель. Контроллер может в какой-то степени являться и выходом из компонента. Если данные оказываются неверными, компонент может перенаправить свое выполнение представлению

Модель (model) - это та часть компонента, которая предназначена как правило для получения данных из какого-либо источника (обычно из базы данных), для обработки этих данных и передачи обработанных данных на "выход" - т.е. для отображения пользователю сайта. Таким образом, модель как бы представляет собой промежуточный слой между базой данных и представлением, т.е. той частью компонента, которая отображает данные пользователю. Модель помимо обработки и получения данных может содержать в себе определенную структуру данных, характерную для конкретного компонента.

Представление (view) - это часть компонента, отвечающая за отображение данных пользователю, т.е. посетителю сайта. У каждого представления есть связанная с ним модель - чтобы представление могло посредством модели получить данные из базы данных и отобразить их пользователю[14].

5.3.2 Файловая структура компонента

После установки компонента через административную панель Joomla его файлы устанавливаются в два основных каталога на диске - это /administrator/components/com_<название_компонента> и/components/com_<название_компонента>. Разрабатываемый компонент называется posterm, тогда при установке компонента на сайт Joomla создаст два основных каталога:

<корень_сайта>/administrator/components/com_posterm

<корень_сайта>/components/com_posterm

Есть некоторые каталоги, имена которых должны быть стандартными - это каталоги views, models, controllers. Их имена не меняем, потому что движок Joomla будет искать файлы компонента по заранее установленным правилам.

Установка компонента происходит путем распаковки zip архива компонента, внутри которого находится все служебные каталоги и специальный установочный файл компонента -posterm.xml. Именно он отвечает за то, из какого каталога в ZIP-архиве брать файлы и куда их устанавливать уже на сайте.

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

1) В ZIP-архиве установочный дескриптор компонента - в нашем случае это posterm.xml располагается прямо в корне архива, а после установки он будет скопирован в<корень_сайта>/administrator/components/com_posterm/posterm.xml

2) В ZIP-архиве есть каталог /media, который может содержать различные мультимедиа файлы (изображения, видео и т.д.), которые будет использовать компонент в своей работе. Содержимое этого каталога при установке компонента будет скопировано в каталог<корень_сайта>/media/com_posterm/

3) Из ZIP-архива все содержимое каталога /site будет скопировано в front-end часть компонента, т.е. в каталог <корень_сайта>/components/com_posterm/

4) Из ZIP-архива все содержимое каталога /admin будет скопировано в back-end часть компонента, т.е. в каталог <корень_сайта>/administrator/components/com_posterm/

5.3.3 Содержание каталога admin

Файлы каталога admin при установке будут распакованы на сервере в каталог, отвечающий за администраторскую часть.

Каталог admin содержит папки:

1) controllers - тут будут храниться файлы с классами контроллеров back-end части

2) css - для хранения файлов CSS-стилей, используемых для отрисовки элементов компонента внутри админки Joomla

3) help - для хранения справки для нашего компонента (на разных языках). Понадобится, если мы захотим написать инструкцию по использованию компонента

4) helpers - для хранения классов-помощников

5) language - здесь будут размещаться языковые файлы компонента

6) models - сюда будем помещать модели для административной части

7) sql - в этом каталоге будут храниться файлы с SQL-запросами для создания всех таблиц компонента в базе данных Joomla

8) tables - тут будут располагаться классы для работы с таблицами компонента

9) views - тут будут храниться файлы представлений, которые будут рисовать всё, что мы увидим в админке Joomla - относительно нашего компонента

Помимо каталогов имеются файлы:

- access.xml - файл прав доступа для компонента для разных категорий пользователей;

- config.xml - файл всех параметров нашего компонента;

- controller.php - файл главного контроллера административной части;

- index.html - индексный файл, который предотвратит отрисовку содержимого каталога, если умный пользователь напрямую пропишет путь к админ-каталогу компонента;

- posterm.php - "входная" точка админ-части компонента. Его Joomla вызовет в первую очередь, когда мы будем обращаться через админку к компоненту.

5.3.4 Содержание каталога site

Файлы каталога site при установке будут распакованы на сервере в каталог, отвечающий за пользовательскую часть (frontend).

Каталог site содержит папки:

- css - для хранения файлов CSS-стилей, предназначенных для отрисовки компонента на сайте. Это все стили, которые и будут формировать внешний "облик" компонента - то, что увидит пользователь сайта;

- js - сюда будем помещать все JavaScript-файлы скриптов, jQuery-библиотеки, плагины jQuery и т.д., словом всё, что относится к скриптам. Они будут выполнять всю динамическую логику на стороне браузера, когда пользователь будет работать с частями компонента на сайте;

- language - сюда поместим файлы локализации - с сообщениями, которые будут встречаться в нашем компоненте;

- models - здесь будут храниться файлы моделей для frontend-части компонента;

- views - тут будут размещены файлы представлений, которые отрисуют разные части нашего компонента на сайте;

- controller.php - файл главного контроллера для frontend-части

- index.html - индексный файл, который предотвратит отрисовку содержимого каталога, если умный пользователь напрямую пропишет путь к frontend-каталогу компонента;

- posterm.php - "входная" точка frontend-части компонента. С неё всегда начинается исполнение компонента, когда пользователь работает с частями компонента на сайте Joomla.

5.4 Разработка компонента

Любой компонент включает в себя собственно программный код и запросы к БД.

5.4.1 Примеры формирования запросов к БД

Чтобы выполнить запрос к базе данных Joomla, необходимо осуществить пять операций:

- Получение ссылки на объект JDatabase.

- Формирование запроса.

- Задание запроса.

- Выполнение запроса.

- При необходимости - загрузка результата.

В старых версиях Joomla запросы формулировались в виде строки:

$query = 'SELECT * FROM #__categories';

В Joomla существует объект JDatabaseQuery, методы которого позволяют упростить создание сложных SQL-запросов. Названия этих методов практически совпадают с ключевыми словами языка SQL: select(), from(), where(), having(), join() и т.д. Сформируем запрос к БД для получения списка имеющихся в БД терминалов, у которых серийный номер начинается на 2565:

$db = JFactory::getDbo();//получение ссылки на него с помощью метода getDbo() статического классаJFactory:

$query = $db->getQuery(true);

$query->select('id_pos, address');

$query->from('pos');

$query->order('data_ystanovki');

$query->where('sn_pos LIKE \'2565%\'');

$db->setQuery($query);

echo $query->__toString();

В данном примере мы получаем из таблицы pos отсортированный по алфавиту список id и адресов установки терминалов, чьи серийные номера начинаются на "2565". Данный код выведет на экран следующий SQL-запрос:

SELECT id_pos, address FROM pos WHERE sn_pos LIKE '2565%' ORDER BY data_ystanovki;

Чтобы задать SQL-запрос для последующего выполнения, используется метод:

JDatabase setQuery(string $query, string $offset=0, string $limit=0);

где $query - это запрос, а $offset и $limit - соответственно смещение для начала выборки и количество выбираемых строк.

Например:

$db->setQuery($query, 0, 10);

5.4.2 Создание производных классов JTable

Для каждой таблицы, которая имеется необходимо создать класс, производный от JTable. Каждый такой класс размещается в папке tables компонента с именем «имя таблицы».php.

Для каждого поля таблицы также необходимо создать одноименное поле класса.

Кроме того, создается конструктор класса, принимающий ссылку на объект JDatabase. Конструктор вызывает родительский конструктор, передавая ему название таблицы, название поля, являющегося первичным ключом таблицы, и объект JDatabase.

Производный от JTable класс для таблицы pinpad будет таким:

class pinpad extends JTable

{

var $id_pinpad = null;

var $pinpad = null;

function __construct(&$db)

{

parent::__construct('pinpad, 'id_pinpad', $db);

}

Аналогичным образом создадим классы для оставшихся таблиц БД.

5.4.3 Функция сохранения данных

Для добавления информации в БД необходима функция сохранения:

function save()

{

$row =& JTable::getInstance('pinpad', 'Table');

if (!$row->bind(JRequest::get('post')))

{

echo "<script> alert('".$row->getError()."');

window.history.go(-1); </script>\n";

exit();

}

$row->question = JRequest::getVar('name_pinpad', '', 'post', 'string', JREQUEST_ALLOWRAW);

if (!$row->store())

{

echo "<script> alert('".$row->getError()."');

window.history.go(-1); </script>\n";

exit();

}

return $row;

}

5.4.4 Функция вывода записей

function showPinpad($option) {

$db =& JFactory::getDbo();

$query = "SELECT * FROM pinpad";

$db->setQuery($query);

$rows = $db->loadObjectList();

if ($db->getErrorNum())

{

echo $db->stderr();

return false;

Эта функция загружает все записи из таблицы pinpad.

5.4.5 Проверка заполнения полей

Для проверки заполенности полей используем JavaScript

<script type="text/javascript">

function proverka(Forma) {

var horosho = true;

if (Forma.id_name.value == "")

{

horosho = false;

alert("Выберите наименование терминала");

Forma. id_name.focus();

};

if (Forma.data_ystanovki.value == "") {

horosho = false;

alert("Введите дату установки терминала!");

Forma. data_ystanovki.focus();

};

if (Forma. data_remonta.value == "") {

horosho = false;

alert("Введите дату ремонта терминала!");

Forma.data_remonta.focus();

};

if (Forma.address.value == "") {

horosho = false;

alert("Введите адрес ТСТ!");

Forma.address.focus();

};

………

return horosho;

}

</script>

Скрипт вызывается при событии OnSubmite кнопки, которая сохраняет введенные данные. В случае, если какое-либо из полей не заполнено возникает всплывающее сообщение с ошибкой, а курсор устанавливается в место ошибки.

6. ЭКСПЕРИМЕНТАЛЬНОЕ ТЕСТИРОВАНИЕ И ОТЛАДКА МОДУЛЕЙ

6.1 Тестирование программного обеспечения

Тестирование программного обеспечения - это процесс исследования, испытания информационной системы, имеющий две различные цели:

1) продемонстрировать разработчикам и заказчикам, что программа соответствует требованиям;

2) выявить ситуации, в которых поведение программы является неправильным, нежелательным или не соответствующим спецификации.

На сегодняшний день не существуют методы тестирования ПО, которые позволяют однозначно и полностью выявить все дефекты и установить корректность функционирования анализируемой программы, поэтому все существующие методы тестирования действуют в рамках формального процесса проверки исследуемого или разрабатываемого ПО.

С точки зрения стандарта ISO 9126, качество программного обеспечения можно определить как совокупную характеристику исследуемого ПО с учётом следующих составляющих: надёжность, сопровождаемость, практичность, эффективность, мобильность, функциональность.

Полный список атрибутов и критериев можно найти в стандарте ISO 9126 [15].

6.2 Уровни тестирования

Модульное тестирование (юнит-тестирование) -- тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция.

Интеграционное тестирование -- тестируются интерфейсы между компонентами, подсистемами или системами. При наличии времени на данной стадии тестирование ведётся итерационно, с постепенным подключением последующих подсистем.

Системное тестирование -- тестируется интегрированная система на её соответствие требованиям.

Альфа-тестирование -- имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО.

Бета-тестирование - в редких случаях выполняется распространение предварительной версии для некоторой большей группы лиц с тем, чтобы убедиться, что продукт содержит достаточно мало ошибок.

Часто для свободного/открытого ПО стадия альфа-тестирования характеризует функциональное наполнение кода, а бета-тестирования -- стадию исправления ошибок.

6.3 Статическое и динамическое тестирование

Описанные ниже техники -- тестирование белого ящика и тестирование чёрного ящика -- предполагают, что код исполняется, и разница состоит лишь в той информации, которой владеет тестировщик. В обоих случаях это динамическое тестирование.

При статическом тестировании программный код не выполняется -- анализ программы происходит на основе исходного кода, который вычитывается вручную, либо анализируется специальными инструментами. В некоторых случаях, анализируется не исходный, а промежуточный код (такой как байт-код или код на MSIL).

Также к статическому тестированию относят тестирование требований, спецификаций, документации.

6.4 Тестирование «белого ящика» и «чёрного ящика»

При тестировании белого ящика, разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования, при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции -- работоспособны и устойчивы, до определённой степени. При тестировании белого ящика используются метрики покрытия кода или мутационное тестирование.

При тестировании серого ящика разработчик теста имеет доступ к исходному коду, но при непосредственном выполнении тестов доступ к коду, как правило, не требуется.

6.5 Покрытие кода

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

6.5.1 Виды тестирований

Существует несколько признаков, по которым принято производить классификацию видов тестирования. Обычно выделяют следующие:

6.5.2 Классификация по объекту тестирования

Функциональное тестирование (functional testing)

Тестирование производительности (performance testing)

Нагрузочное тестирование (load testing)

Стресс-тестирование (stress testing)

Тестирование стабильности (stability / endurance / soak testing)

Юзабилити-тестирование (usability testing)

Тестирование интерфейса пользователя (UI testing)

Тестирование безопасности (security testing)

Тестирование локализации (localization testing)

Тестирование совместимости (compatibility testing)

6.5.3 Классификация по знанию системы

Тестирование чёрного ящика (black box)

Тестирование белого ящика (white box)

Тестирование серого ящика (grey box)

6.5.4 Классификация по степени автоматизации

Ручное тестирование (manual testing)

Автоматизированное тестирование (automated testing)

Полуавтоматизированное тестирование (semiautomated testing)

6.5.5 Классификация по степени изолированности компонентов

Компонентное (модульное) тестирование (component/unit testing)

Интеграционное тестирование (integration testing)

Системное тестирование (system/end-to-end testing)

6.5.6 Классификация по времени проведения тестирования

Альфа-тестирование (alpha testing)