Что такое тестирование программного продукта и зачем оно нужно

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

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

Тестирование – это процесс выполнения программы со стойким намерением найти ошибки.

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

Тестирование – это ряд действий, связанных с:

Проводится на этапах:

Как и любое другое ПО, программные продукты фирмы «1С» нуждаются в таком процессе как тестирование. Пользователи и разработчики 1С должны быть уверены в работоспособности конфигураций и после обновления платформы до последней версии, и после установки новых функций или в случае внесения каких-либо других изменений.

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

Когда функционал уже разработан, тестирование проводит аналитик.

Рассмотрим два этапа тестирования – внутреннее и внешнее.

Внутреннее – это тест на стороне исполнителя, то есть силами аналитика, без привлечения заказчика.

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

В некоторых компаниях есть отдельные сотрудники – тестировщики в должностные обязанности которых как раз и входит выявление всевозможных багов.

Баг — это отклонение фактического результата/действий от ожидаемого.

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

Результатом тестирования является список выявленных несоответствий и дефектов или выявление отсутствия таковых при идеальном раскладе.

Чтобы успешно проводить тестирование, необходимо знать ожидаемый результат, узнать фактический результат и сравнить эти результаты.

Получается, что процесс тестирования состоит из четырех стадий:

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

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

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

Как правило, функциональное и нефункциональное тестирование можно проводить параллельно.

В функциональном тестировании, в свою очередь, тоже можно выделить два уровня:

План работы по компонентному тестированию следующий:

Давайте теперь рассмотрим пример детального тестирования для нового справочника. При создании нового справочника нам нужно, во-первых, проверить наличие справочника в программе в режиме предприятия. Во-вторых, проверить размещение справочника, зайти в меню, найти его, при этом проверить все пути, которые указаны в ТЗ, если их несколько. Следующее – проверить наличие всех реквизитов в соответствии с ТЗ. Затем мы создаем новый элемент справочника и проверяем заполнение всех реквизитов в соответствии с ТЗ.

На следующем шаге тестирования для нового справочника необходимо пометить на удаление, снять пометку на удаление с нового элемента, проверить, соответственно, что никаких ошибок не выходит, все работает корректно, проверить соответствие структуры подчиненности и иерархии справочника на соответствие ТЗ.

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

Нефункциональное тестирование

Нефункциональное тестирование проверяет работу системы в целом: скорость работы, устойчивость работы, поиск глобальных ошибок при пересечении работы нескольких объектов системы.

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

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

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

И последнее, что мы проверяем – это эмоциональная реакция, т.е. то, как пользователь себя чувствует после завершения задачи. Растерян, испытал стресс, порекомендует ли пользователь систему своим коллегам или друзьям, здесь мы ожидаем положительную реакцию. Казалось бы, удобство пользования – это, в принципе, ерунда, пользователь, наверняка, сможет прожить без удобного интерфейса, но, на самом деле, комплекс таких мелочей может испортить в целом картину о системе.

Есть специальный термин Poka-yoke, который возник в Японии. Poka-yoke – это механизм или организация работы так, что ее можно выполнить только одним правильным способом, то есть чтобы не существовало даже возможности создания дефектов или багов.

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

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

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

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

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

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

Все вышеперечисленное – это работа и тестирование по позитивному сценарию, т.е. тесты, которые направлены на проверку корректности работы того, что было придумано и разработано по техзаданию. Но при тестировании нужно делать и наоборот, т.е. абстрагироваться от ТЗ и попробовать протестировать программный продукт по негативному сценарию.

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

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

Задача аналитиков – предусмотреть все возможные действия пользователей. Именно для этой цели необходимо негативное тестирование. В процессе тестирования по негативному сценарию воспроизводите критические ситуации. Проанализируйте возможные причины ошибки, тщательно опишите условия воспроизведения, оборудование, время, порядок действий. Это поможет разработчикам воспроизвести ошибку со своей стороны и понять причины ее возникновения. Также необходимо делать скриншоты ошибок или записывать на видео порядок действий при воспроизведении ошибки. Более подробно о работе аналитика в Курсе аналитика 1С.

Результаты тестирования могут быть следующими:

Результаты тестирования могут быть следующими:

● Задача соответствует требованиям заказчика и ТЗ (идеальный вариант).

● Выявлены баги/дефекты:

✔ Ошибки разработчика при программировании кода

✔ Ошибки аналитика при постановке ТЗ

✔ Недостаточная производительность. Возможные решения:

o Оптимизация ПО

o Изменение серверного окружения

o Смена программного продукта

● Новые требования.

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

Что делать с ошибками, выявленными при тестировании? Обязательно исправить, определив сроки на исправление.

Ошибки можно поделить условно на две категории:

Критичность ошибки и необходимость ее немедленного исправления можно определить самим или согласовать с заказчиком.

Как определять критичность ошибки?

Возможны следующие варианты:

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

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

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

Тестовые кейсы (сценарии) — это последовательность действий, по которой можно проверить, соответствует ли тестируемая функция установленным требованиям:

Самой последней строкой в тестовых сценариях обычно является отчетность.

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

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

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

Тест-дизайн – это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы), в соответствии с определенными ранее критериями качества и целями тестирования.

Методологии тест-дизайна:

Например, мы тестируем функциональность приложения, позволяющего покупать товары для взрослых. Задание: если покупателю меньше 18 — вывести сообщение «Слишком мало». Если от 50 до 100 лет — «слишком велик». Если значение поля трехзначное — вывести сообщение «Столько вообще не живут». И значение поля может быть только целое.

Метод эквивалентного разбиения позволяет минимизировать число тестов, не создавая сценарий для каждого возможного значения. В нашем примере их как минимум 100: от 0 до 100 лет. А выбрав только одно значение из целого класса и приняв за аксиому, что для всех значений данной группы результат будет аналогичным, в нашем примере выделяем диапазон значений вообще. Делим его на участки, где система ведет себя одинаково. В нашем случае мы делим на 4 отрезка. От 0 до 18, от 18 до 50, от 50 до 100 и больше 100 — всего 4 отрезка, т.е. аналитику не нужно писать 100 тестов для каждого возраста. Достаточно написать 4, по одному для каждой возрастной группы. Предположим, для группы от 0 до 18 можем взять значение 5. От 18 до 50 можем взять 25, от 50 до 100 можем взять значение 75 и больше 100 — значение 101. То есть на этих четырех значениях мы протестируем, как же работает себя система. В этом и заключается суть метода эквивалентного разделения.

Техника граничных значений основана на предположении о том, что большинство ошибок может возникнуть на границах эквивалентных классов. Эта техника достаточно тесно связана с техникой эквивалентного разбиения, из-за чего часто используется с ней в паре. Для нашего примера границами будут являться значениями 0, 18, 50 и 100. А граничными значениями будут 0, 1 и 17, 18, 19, 49, 50, 51, 99, 100 и 101. Вообще достаточно часто сложности возникают именно там, где возрастные категории указаны внахлёст. Например, от 0 до 18, от 18 до 50 и так далее. То есть часто не сразу понятно, например, в какую группу входит 50. От или до?

Метод предугадывания ошибки. Используя свои знания о системе, аналитик может предугадать, при каких же входных условиях есть риск ошибки.

Для этого нужно иметь соответствующий опыт и хорошо знать продукт. Для описанного выше примера нужно рассмотреть возможность появления отрицательной величины, ведь в требованиях не было ограничения на отрицательные числа. Мы должны ввести отрицательное число, например, – 5, и посмотреть, что же выдаст система. А если появляется дробное значение с разделительной точкой? А если в поле ввести SQL-запрос или вместо 50 цифр ввести слово 50? Даст ли программа ввести такое значение?

Преимущества этого метода: проверка эффективна в качестве дополнения к другим техникам и выявляет тестовые случаи, которые никогда не должны случиться.

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

Причина/Следствие. Используя данный метод, мы решаем, сколько вариантов развития могут быть у данного функционала. Частый вариант – это два исхода: положительный и отрицательный, т.е. или успешный, или неуспешный. Но на самом деле, может быть множество исходов входных данных.

Разумеется, этот список методик тест-дизайна далеко не полон и дает только самое общее представление о принципах тестирования и техниках тест-дизайна.

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

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

По сути, приемка заказчиком – это тоже этап тестирования, потому что заказчик проверяет разработанный функционал и тестирует его.

Приемка заказчиком – это внешнее тестирование функционала.

Существует несколько этапов или видов проверки функциональности заказчиком.

1. Юнит-тестирование (ЮТ). В процессе юнит-тестирования заказчику демонстрируются отдельные процессы или подпроцессы с учетом согласованных доработок. Заказчик перед юнит-тестом назначает со своей стороны экспертов или ключевых пользователей, которые будут принимать доработки. Очень важно, чтобы на встречах присутствовали те эксперты, чьи требования реализовывались на проекте. Иначе может возникнуть ситуация, что эксперт вообще не примет функционал, ведь не он же его ставил, и отправит переделывать. Аналитики к юнит-тесту предварительно готовят тестовые кейсы, примеры для показа заказчику в отдельной базе, справочники, настройки, набор операций. Все результаты юнитеста фиксируются в тестовых кейсах и в протоколах.

Плюсы:

Цели проведения:

2. Опытная эксплуатация

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

Подписывайтесь:

CORS Клуб - сообщество и образовательная среда для специалистов из IT-сферы https://cors.su/klub/

АБП -Сообщество специалистов по автоматизации бизнес-процессов и по использованию ИТ технологий в бизнесе https://t.me/analitiki_1c

Канал руководителей IT компаний и подразделений, CIO, СDO, CDTO https://t.me/cio_channel

CIO. Сообщество IT руководителей https://vk.com/cio_club