Войти в систему
Войти с помощью соц. сетей:
Тестирование – это важная часть процесса разработки программного обеспечения и инструментарий достижения целей проекта в обеспечении должного качества модификаций и доработок ERP-системы.
Рассмотрим определение тестирования, которое дает PMBOK. Тестирование – это организованное и проводимое по определенному плану исследование с целью получить объективную информацию о качестве продукта или услуги, проходящих тестирование, в соответствии с требованиями проекта. Тестирование предназначено выявить ошибки, дефекты, неисправности или другие проблемы несоответствия в продукте или услуге. Тип, объем и глубина тестов, необходимых для оценки каждого требования, входят в состав плана управления качеством проекта и зависят от характера, сроков, бюджета и других ограничений проекта. Тесты могут проводиться на всем протяжении проекта, по мере того как становятся доступными различные компоненты проекта, а также в конце проекта, когда тестируются конечные поставляемые результаты. Проведение тестирования на ранних стадиях помогает выявить проблемы несоответствия и снизить стоимость исправления не соответствующих требованиям компонентов.
Подробное формальное описание процессов и методик тестирования, рекомендуемое для самостоятельного изучения, приведено в серии стандартов ISO 29119 (и ГОСТ Р по ним) «Системная и программная инженерия. Тестирование программного обеспечения»:
Далее рассмотрим основные моменты и понятия, которые нужно учитывать в проектах внедрения ERP-системы.
План тестирования – приложение к ТЗ, содержит входные и ожидаемые выходные данные (или действия) для функциональности системы для проверки работоспособности алгоритмов и соответствия их исходным требованиям к системе. Разработка плана тестирования позволяет лучше понять требование и его реализацию, т. к. заставляет формально описать данные на входе в функциональность и ожидаемые данные на выходе из нее. Такая информация позволяет разработчику лучше понять требования и отладить свой код и алгоритмы. План тестирования должен покрывать сценарии использования системы в бизнес-процессах компании. Успешное прохождение тестов (ручных или автоматических) – это критерий отметки успешности для данной функциональности в общем чек-листе тестирования.
Формирование плана тестирования модификации системы позволяет подключить процесс тестирования на стадии проектирования, до активной разработки модификации, и проверить «в уме» описанную в ТЗ функциональность. Иногда при подготовке плана тестирования вскрываются недостатки проектирования, когда в алгоритм не заложены значимые сценарии работы пользователей. Пренебрежение планом тестирования создает иллюзию экономии на проекте, но все в головах не удержать: разработчик закладывал что-то одно, тестировщик проверял совсем другое, а пользователь будет ожидать что-то третье. А план тестирования, как часть ТЗ, утверждается и является критерием приемки работоспособности функциональности, одинаковым для всех специалистов исполнителя и заказчика.
Специалистам заказчика порой проще понять и утвердить само ТЗ по описанию его плана тестирования, т. к. они как пользователи оперируют понятиями данных и действий с системой, а не ее алгоритмами и тонкостями их реализации.
Чек-лист тестирования системы – сводный высокоуровневый список спецификаций возможностей системы, необходимых для покрытия автоматизируемых бизнес-процессов компании. Является критерием приемки работоспособности системы для эксплуатации и, заполненный успешно пройденными тестирование пунктами, необходим для завершения фазы «Разработка». Причем отмечать (или хотя бы проверять достоверность) факт успешного прохождения должен руководитель заказчика как принимающая работу сторона.
Ручное тестирование – тесты выполняются вручную, без использования особых средств автоматизации. Тестировщик просто следует заранее написанному плану действий, фиксируя результат: было поведение функциональности системы ожидаемым или нет (в этом случае записывается, что пошло не так). Если детального плана тестирования нет, то тестировщик проявляет креатив, представляет себя на месте пользователя и моделирует его работу в различных сценариях по бизнес-процессам. Качество теста в этом случае сильно зависит от квалификации специалиста.
Автоматизированное тестирование – потребность в нем возникает, когда проект большой и ведется его активное развитие, чтобы не тратить время на повторный ручной прогон тестов, которые приходится повторять регулярно. Часто под автотестами понимают только юнит-тесты, хотя автоматизировать можно практически любой вид тестирования.
Unit testing – процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы. Юнит-тесты пишутся разработчиками для своего кода, проверяют код, передавая входные параметры и ожидая (проверяя) результат.
Нужно учесть, что часто бывает так, что затраты на поддержание автотестов значительно превышают затраты на ручное тестирование. Поэтому надо действовать аккуратно, оценив плюсы и минусы: какие-то редкие (уникальные) тесты оставить ручными, а автоматизировать массовые, повторяемые периодически тесты, например набор тестов для регрессионного тестирования.
Регрессионное тестирование – это проверка работоспособности системы после внесения модификаций и доработок, направленная на подтверждение того, что функциональность системы с новыми изменениями работает так же, как и раньше, без ухудшений. Тестирование затрагивает всю используемую функциональность, а не только модифицируемые в рамках текущей поставки (сборки релиза) участки. Необходимость проверки на возникновение ухудшений (собственно, самого регресса системы, от лат. regressio – «движение назад») обусловлена возможностью возникновения ошибок в коде, который не планировался к изменению, после исправления ошибок или добавления новых возможностей.
Бывает, что разработчики при исправлении какой-то ошибки или модификации системы в одном месте привносят ошибки в другие места. Такие ошибки не находятся ручными тестами по плану тестирования данной модификации, т. к. проявляются вне контура, который тестируется.
Поэтому требуется проверка на «неразвал» всей системы, так как локальные тесты модификаций могут успешно проходить, а места, которые никто специально не трогал, могут перестать работать корректно. Перед выпуском очередной сборки для переноса на рабочую базу конфигурацию пропускают через набор тестовых сценариев, подготовленных ранее. Если сами тесты не проходят по причине запланированного изменения функциональности, а не ошибок системы, то тесты нужно актуализировать.
Смоук-тест (англ. smoke testing, «дымовое тестирование») – минимальный набор тестов на явные ошибки. «Дымовой тест» обычно выполняется самим разработчиком в процессе отладки, или это минимальный набор автотестов проверки на неразвал (система «задымилась»). Не прошедшую этот тест систему не имеет смысла отдавать на более глубокое тестирование, нужно оперативно исправлять.
Нагрузочное тестирование (англ. load testing) – это вид тестирования производительности, проводимый с целью оценить поведение системы (или какой-то ее функции) под увеличивающейся нагрузкой (число одновременно работающих пользователей и/или количество транзакций). Нагрузочные тесты требуют создания обработок по генерации массива данных, которые будут создавать нагрузку для проверки алгоритмов системы. Без тестов этого типа неоптимальный код ручными тестами на малых выборках данных выявить сложно, опытная эксплуатация тоже пропустит такую функциональность, т. к. за несколько месяцев наработать критическую массу данных, когда начнет проявляться проблема, возможности нет. Массовую работу пользователей можно проверить симуляцией работы или практикой, организовав нагрузку на систему путем договоренности со всеми пользователями о выполнении ими их основных бизнес-процессов (эмуляция активной работы: ввод документов, построение отчетов) в системе в одно и то же время. В этот момент следим за показателями нагрузки на аппаратуру (процессоры, диски, память серверов) и мониторим состояние СУБД.
Игнорирование нагрузочных тестов (экономия на них, т. к. они требуют трудозатрат, а это сроки и бюджет) является «отложенным возмездием» или проектным риском, который может проявиться через годы использования системы (а может и не проявиться, если код изначально оптимальный или прирост данных не влияет на алгоритм), когда в системе накопится критический объем данных. Тогда нужно будет заниматься рефакторингом и оптимизацией алгоритмов. И эта задача будет уже на этапе сопровождения системы, за рамками жизненного цикла проекта внедрения.
Рассмотрим подробнее вопрос, для чего нужно автоматизировать процесс тестирования и какие инструменты для этого возможны. Цели автоматизации тестирования:
Автоматизация тестирования требует усилий: создание автотеста может быть в 2–3 раза более трудозатратно, чем проведение аналогичного ручного теста. Но если этот ручной тест нужно будет повторять 4–10 раз, то выигрыш от автотеста очевиден. Автотест может идти значительно быстрее, чем это делает человек, хотя сам автотест может эмулировать работу пользователя (кликает в интерфейсе системы) в реальном времени, но делает он это быстрее человека. Автотесты могут запускаться на ночь (так как множество тестов могут выполняться несколько часов) и высвобождать консультантов для других задач.
Инструментарий для автоматизации процесса тестирования проектов на 1С:ERP:
«1С:Автоматизированная проверка конфигураций» предназначена для автоматизированной проверки конфигураций, разработанных на платформе «1С:Предприятие 8», на соответствие стандартам и иным требованиям технического характера. АПК существенно расширяет платформенную проверку конфигурации и выполняет статический анализ технического качества конфигураций в автоматическом режиме, не требуя их запуска. Тестирование кода позволяет еще до тестирования самой функциональности отловить и устранить ряд проблем.
Это отдельная конфигурация для проверки других конфигураций, она может находить и регистрировать ошибки по коду конфигурации. АПК может интегрироваться с 1С:СППР и передавать найденные ошибки туда.
Типы проверок можно гибко настраивать. Какие-то ошибки могут быть просто особенностью – можно отметить их как исключение, и АПК не будет больше уведомлять об этой ошибке.
Для тестирования своего проектного кода на соответствие стандартам разработки нужно предварительно выполнить проверку АПК стандартной конфигурации и отметить все найденное как особенности, потом запускать проверку модифицированной конфигурации. Это позволит получить сообщения о проверках только по проектному коду.
«1С:Система проектирования прикладных решений» содержит возможности автоматизации тестирования: подготовка, выполнение сценариев тестирования и регистрация ошибок по результатам выполнения сценария. Поддерживаются сценарные тесты по методологии BDD (англ. Behavior-Driven Development, разработка через поведение). Для пользователей и партнеров 1С:ERP доступна также специализированная демонстрационная база, включающая в себя интегрированный инструмент «Тест-центр» и необходимые дополнительные тестовые обработки с готовыми тестовыми сценариями.
«1С:Корпоративный инструментальный пакет» предназначен для повышения производительности, масштабируемости и надежности информационных систем, работающих на платформе «1С:Предприятие 8», за счет решения широкого круга технических задач, возникающих на всех этапах жизненного цикла информационной системы.
Отдельный вопрос, который стоит рассмотреть в завершение раздела, – это прозрачность прохождения процесса тестирования для заказчика. Специалисты исполнителя используют для организации процесса регистрации ошибок и отслеживания статусов их исправления систему баг-трекера (например, тот же 1С:СППР, в котором эта опция есть). Нужно ли предоставлять доступ к ней сотрудникам заказчика? Если руководитель проекта со стороны заказчика хочет полностью контролировать ход процесса, то такой доступ он может запросить сам.
Организацию сбора ошибок от пользователей рекомендуется осуществлять с использованием баг-трекера, но с разделением доступа на внутренние ошибки команды исполнителя (их не видно пользователям) и внешние от самих пользователей (плюс им видны внутренние ошибки, отмеченные как внешние). Тогда до момента начала обучения пользователей процесс тестирования и ошибки, найденные в нем, от конечных пользователей скрыты, им дается готовая система, стабилизированная на момент начала ознакомления с ней. А вот дальше все ошибки пользователям интересны и должны быть видны, т. к. они затрагивают функциональность, с которой они работают непосредственно сейчас.
Войти с помощью соц. сетей: