В данной статье описывается такой метод тестирования программного обеспечения, как модульное по стратегии «WhiteBox», на конкретной задаче.
Ключевые слова: модульное тестирование, банк Приморье, программное обеспечение.
Сегодня никому не нужно доказывать преимущества использования информационных технологий. Ничто так не способствует контролю и анализу деятельности на предприятии как внедрение комплексной автоматизированной информационной системы (АИС). Внедрив автоматизированную информационную систему, руководство предприятия получит полную и наглядную картину происходящего. АИС поможет принять правильные решения по повышению эффективности отдельных процессов, снизит затраты, улучшит коммуникации, что несомненно поспособствует занятию новых высот для предприятия [4].
Стратегия успешного тестирования программного обеспечения в автоматизированной информационной системе начинается с процесса его обсуждения на стадии составления спецификаций требований к будущему программному продукту. Тестирование деталей следует проводить на высоком и низком уровне, причем оно должно проводиться сначала разработчиками, а затем конечными пользователями или заказчиками. По мере повышения сложности программного обеспечения увеличивается значение эффективного, хорошо спланированного тестирования [1].
На сегодняшний день существует множество методов тестирования программного обеспечения. Все они направлены на достижение двух основных целей: демонстрация заказчикам и разработчикам программного продукта, который соответствует заданным требованиям и выявление ситуаций, при которых продукт будет считаться некорректным или не соответствующим заданным критериям.
Затрагивая один из основных признаков, по которым принято производить классификацию видов тестирования, а именно «по степени изолированности компонентов», можно выделить три основных процесса: интеграционное тестирование, системное тестирование [2] и, наконец, модульное тестирование, о котором далее пойдет речь.
Модульное тестирование это процесс, при котором проверяется функциональность разработанной части приложения, а также осуществление поиска дефектов в отдельных частях приложения, которые тестируются отдельно. Данному процессу подлежат модули программ, классы, функции и т. д. Целью этого тестирования является изоляция исходного кода, т. е. отдельной части программы и демонстрация ее работоспособности. Это позволяет оперативно и максимально достоверно проверить, не привело ли очередное изменение кода к ошибкам в уже оттестированных частях программы, а также облегчает их обнаружение и устранение. Для данного вида тестирования характерно использование стратегии «White Box» или «Белый ящик».
«White Box» используется с целью поиска и обнаружения проблем во внутренней структуре приложения или его части. Это требует от тестировщика глубокого знания его внутреннего наполнения и, следовательно, не может быть выполнено обычным пользователем. Основное преимущество всех типов стратегий тестирования «White Box» следующее: при тестировании принимается во внимание структура всей программы, что облегчает обнаружение ошибок даже в том случае, когда спецификации программного обеспечения недостаточно определенные или неполные. Обеспечение проверки каждого шага по алгоритму программы это основная цель такого тестирования.
Тестирование по блокам заключается в проверке блока отдельно от остальной системы. Обычно блок представляет собой функцию или небольшой набор функций, которые выполняются одним программистом. Основная отличительная характеристика блока состоит в том, что он достаточно небольшой по объему для проведения тщательной проверки, которую можно назвать исчерпывающей. Обычно тестирование «белый ящик» проводится разработчиками. Небольшой размер блоков позволяет обеспечить высокий уровень проверки кодов. Таким образом, легче обнаружить и устранить ошибки на данном уровне тестирования.
Одним из наиболее сложных аспектов разработки программного обеспечения являются интеграция и тестирование больших подсистем. Интегрированная система часто дает существенные и необъяснимые сбои, которые трудно устранить. Тестирование в таком случае состоит в проверке нескольких блоков, которые образуют модуль или подсистему. Тестирование интегрированной системы в основном направлено на интерфейс между блоками, что должно гарантировать совместимость блоков и их корректную совместную работу.
Стратегия «Белого ящика» включает в себя следующие методы тестирования:
1. покрытие операторов (подразумевает выполнение каждого оператора программы, по крайней мере, один раз);
2. покрытие решений (необходимо составить такое число тестов, при которых каждое условие в программе примет как истинное значение, так и ложное значение);
3. покрытие условий (если после составления тестов у нас останутся не покрытые операторы, то мы должны дополнить свой набор тестов таким образом, чтобы каждый оператор выполняется не менее одного раза);
4. покрытие решений и условий (необходимо составить тесты так, чтобы результаты каждого условия выполнялись хотя бы один раз, результаты каждого решения так же выполнялись хотя бы один раз, и каждый оператор должен быть выполнение хотя бы один раз);
5. комбинаторное покрытие условий (все возможные комбинации результатов условий в каждом решении, а также каждый оператор выполнились по крайней мере один раз) [3].
Описанный выше метод тестирования используется в банковской сфере, а именно, сотрудники отдела сопровождения информационной системы банка (далее ОСИСБ) в ОАО АКБ «Приморье» (Головной офис банка расположен в городе Владивосток [4]), используя данную стратегию, производят тестирование программного обеспечения (далее ПО) или модульных разработок, которые, в случае успешного тестирования, будут установлены на основной сервер по желанию заказчика, в среду «InvoRetail», в которой находятся основные модули, обеспечивающие проведение и отслеживание всех банковских операций физических и юридических лиц на протяжении 24-ёх часов.
Тестирование программного обеспечения можно описать следующим единым алгоритмом, независимо от вида поступившей заявки на доработку или исправление модуля в среде «InvoRetail»:
1. ответственный сотрудник ОСИСБ, получив от программистов готовое ПО устанавливает его на тестовом сервере, согласно инструкции по установке, которая должна входит в инсталляционный пакет и приступает к тестированию ПО;
2. сотрудник ОСИСБ составляет собственную карту тестирования и проводит комплексное тестирование ПО, фиксируя результаты в карте тестирования. Карта должна наиболее полно включать все возможные варианты выполнения технологических действий пользователя, с применением разработанного ПО. Файл карты тестирования формируется в программе Microsoft Office Excel. Образец заполнения карты тестирования, представлен на рисунке 1;
Рис. 1. Образец заполнения карты тестирования
3. если в процессе тестирования обнаружены ошибки, ПО возвращается на доработку программисту ОПОБТ (далее Отдел программного обеспечения банковских технологий) с описанием выявленных замечаний;
4. карта тестирования с результатами тестов заносится в модуль «ИТ-планирование», который находится в автоматизированной банковской системе (далее АБС) «InvoRetail» на основном сервере;
5. при планировании организации тестирования с участием нескольких подразделений, согласно окончательному перечню в описании технологического процесса к заявке (далее ОТП), начальник ОСИСБ (или ответственный сотрудник ОСИСБ) запрашивает по электронной почте руководителей всех подразделений ФИО сотрудников, участвующих в тестировании. Руководители соответствующих подразделений направляют в ОСИСБ перечень ФИО сотрудников, которые тестировали задачу;
6. также в процессе тестирования может быть выполнена, при необходимости, корректировка перечня подразделений, затрагиваемых внедряемым функционалом;
7. при успешном завершении тестирования, ответственный сотрудник ОСИСБ передает ПО и карту тестирования на согласование даты внедрения начальнику отдела ОСИСБ, ОПОБТ и Куратору заявки, согласно перечню в описании технологического процесса [5].
Для того, чтобы конкретно показать, как работает данный механизм тестирования, необходимо взять для примера действующую заявку, которая поступила в ОСИСБ в виде служебной записки от заказчика, и разработка по ней не была внедрена, а находится на стадии тестирования в ОСИСБ. А именно, существует заявка 8467 «Изменение баланса для отражения несанкционированного овердрафта (далее НСО) в АБС «InvoRetail.Частные вклады», суть её заключается в следующем: согласно разъяснению по вопросам, связанным с применением Положения Банка России от 16 июля 2012 года № 385-П «О правилах ведения бухгалтерского учета в кредитных организациях, расположенных на территории Российской Федерации», в случае несанкционированного проведения расходной операции с банковского счета, сумма задолженности должна отражаться на счете 30233 %, сумма резерва должна отражаться на счете 30226 %, в н. в. сумма задолженности отражается на счете 47423 %, резервы отражаются на счете 47425 % в балансовых группах (далее БС).
В связи с этим необходимо:
1. выполнить перенастройки в АБС «Частные вклады» так, чтобы в будущем счета, связанные с данной операцией, открывались так, как указано в разъяснении;
2. для всех карточных лицевых счетов, уже открытых в АБС «Частные Вклады», в случае наличия ненулевого остатка по счету %47423 автоматически необходимо открыть счета %30233 и %30226;
3. также требуется автоматически перенести остатки со счетов %47423 на счета %30233 и со счетов %47425 на %30226 в разрезе клиентов в АБС «Частные вклады». Далее, настроить механизм формирования резервов по остаткам на счетах %30233, аналогичным счетам %47423, в т. ч. изменить настройки по портфелям [6].
В процессе тестирования механизма изменения баланса для учета задолженности по овердрафту в данной подсистеме будет установлен модуль, предложенный московскими разработчиками, который поможет решить поставленную задачу. В ходе тестирования будет проанализирована пошаговая работа модуля 800 «Перевод НСО на новые БС2», а также, для осуществления процесса изменения балансовых групп и переноса денежных остатков с одних счетов на другие, одновременно будет прослеживаться работа модулей 1 — «Объединенное рабочее место», 2 — «Картотека счетов» и 500 — «Рабочее место по кредитам» в среде «InvoRetail.Частные вклады». В процессе работы результаты тестов будут отражены в карте тестирования. Описание процесса тестирования модуля 800 представлено на рисунке 2 в виде блок-схемы.
Рис. 2. Блок-схема алгоритма тестирования модуля 800 «Перевод НСО на новые БС2»
Для решения поставленной задачи в АБС «InvoRetail.Частные вклады» создаются новые балансовые группы (30233 и 30226), к которым будут отнесены все счета с их ненулевыми остатками (т. е. в виде исходных данных у нас будут использованы пустые балансовые группы и старые счета %47423 и %47425 с ненулевыми остатками). После того, как группы 30233 и 30226 будут занесены в картотеку счетов (это модуль 2 «Картотека счетов), необходимо установить файл xmove_nro.fmx (модуля 800) на тестовый сервер АБС «InvoRetail.Частные вклады» через программное приложение «Toad for Oracle, version 12.1».
В случае неудачной установки модуля на тестовую среду АБС «InvoRetail.Частные вклады», ответственному сотруднику необходимо направить обращение с описанием ошибки в отдел разработки (ОПОБТ) с просьбой доработать форму, далее ожидать ответа от разработчиков.
В случае успешной установки необходимо открыть модуль 800 в тестовой среде и произвести загрузку счетов из БД старых групп %47425 и %47423 с ненулевыми остатками в модуль. Затем необходимо прописать соответствие старых и новых балансовых групп и произвести запуск операции перевода счетов. Программа предложит три варианта дальнейших действий: перевод счетов по балансовой группе в окне, перевод по текущей балансовой группе и отказ операции. Необходимо выбрать вариант «перевод счетов по балансовой группе в окне», так как нам нужно выполнить операцию для всех балансовых групп сразу, а не для каких-то отдельно. В случае успешной операции (без ошибок) ответственному сотруднику ОСИСБ необходимо выполнить проверку отображения всех сформированных проводок по всем счетам сразу в модуле 800 «Перевод НСО на новые БС2» по кнопке «Таблица соответствия балансовых счетов» (остатки отображаются еще на старых счетах). В случае неудачной операции тестировщику необходимо направить куратору заявки запрос или служебную записку со скрином окна с выведенными ошибками и описанием к ним. После устранения ошибок, тестировщику следует произвести запуск операции повторно.
После того, как по всем счетам произошло формирование проводок НСО, сотруднику ОСИСБ необходимо выполнить операцию разноски по реальным остаткам через модуль 2 «Картотека счетов». В случае неудачной операции, тестировщику необходимо выбрать счета, по которым разноска не произошла, и проверить по ним информацию в модуле 1 «Объединенное рабочее место» или в модуле 500 «Рабочее место по кредитам». Когда ошибки по счетам будут устранены, операцию разноски по реальным остаткам необходимо выполнить еще раз. В альтернативном случае, информацию по разнесенным проводкам следует проверить в окне модуля 800 «Перенос НСО на новые БС2» (остатки после разноски будут отображаться уже по новым счетам). Далее в модуле 1 «Объединенное рабочее место» выборочно необходимо проверить, что старые счета %47423 и %47425 отвязались от карточных счетов %40817, а новые счета %30233 и %30226 привязались.
Результаты по проведенному тестированию модуля 800 «Перевод НСО на новые БС2» были занесены в карту тестирования по заявке 8467 «Изменение счета для отражения НСО в ПО «Частные вклады». Этот документ является основанием для внедрения данного модуля в рабочую среду АБС «Частные вклады» и дальнейшей его эксплуатации. В ходе проведенного тестирования, ошибок в работе модуля обнаружено не было, поэтому на данный момент решается вопрос об утверждении и установке его на основной сервер Банка Приморье. Модуль удовлетворяет всем своим требованиям: функциональным характеристикам, надежности и корректности работы, информационной и программной совместимости, составу аппаратных и программных средств, составу программной документации.
Подводя итог вышесказанному, следует отметить, что данный метод модульного тестирования позволяет протестировать работу отдельной части программы (модуль 2, 500 и 1, где отображались полученные счета и проводки), проанализировать всю работу модуля 800, а также отследить процесс взаимодействия данного модуля с вышеперечисленными. Но, как и любое тестирование, модульное, все же не позволяет выявить абсолютно все ошибки программы, только их большую часть. Здесь невозможно трассировать все возможные пути выполнения программы. Технология также бессильна при тестировании на производительность. Поэтому чтобы отследить все нюансы, необходимо использовать модульное тестирование в совокупности с другими видами тестирования.
Литература:
1. Тестирование систем [Электронный ресурс] www.rus-lib.ru. Режим доступа: http://www.rus-lib.ru/book/38/men/21/3.7..html
2. Тестирование [Электронный ресурс] http://www.viva64.com. Режим доступа: http://www.viva64.com/ru/t/0093/print/
3. Тестирование белого ящика (White box) [Электронный ресурс] http://tplit.wikispaces.com. Режим доступа: http://tplit.wikispaces.com/Тестирование+белого+ящика+(white box);
4. Бедрина С. Л., Богданова О. Б. ПЕРСПЕКТИВЫ ВНЕДРЕНИЯ ERP-СИСТЕМ НА ПРЕДПРИЯТИЯХ ПРИМОРСКОГО КРАЯ//Современные проблемы науки и образования. — 2013. — № 6; URL: www.science-education.ru/113–11486;
5. Порядок выполнения работ сотрудниками ОПОБТ и ОСИСБ Департамента ИБТ при разработке и внедрении Программного обеспечения № 50-А. [Текстовый документ];
6. Служебная записка по задаче 8467 «Изменение счета для отражения НСО в ПО «Частные вклады» [Текстовый документ].
