Нужны ли нам данные испытаний или мы можем положиться на модульные тесты и ручное тестирование?

В настоящее время мы работаем над средним / большим проектом PHP / MySQL. Мы проводим модульное тестирование с помощью PHPUnit & QUnit, и у нас есть два постоянных тестера, которые вручную тестируют приложение. Наши тестовые (фиктивные) данные в настоящее время создаются с помощью сценариев SQL.

У нас проблема с поддержкой скриптов для тестовых данных. Бизнес-логика довольно сложна, и одно «простое» изменение тестовых данных часто приводит к нескольким ошибкам в приложении (которые не являются реальными ошибками, а являются продуктом неверных данных). Это стало большой нагрузкой для всей команды, потому что мы постоянно создаем и меняем таблицы.

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

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

testing unit-testing quality manual-testing Кристиан П
источник

Ответы:

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

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

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

РЕДАКТИРОВАТЬ: ОК, я понимаю, что вы спрашиваете. Ответ - да, потому что работа тестировщика не в том, чтобы генерировать тестовые данные, а просто в тестировании приложения. Вам необходимо создавать свои сценарии таким образом, чтобы упростить обслуживание и обеспечить вставку действительных данных. Без тестовых данных тестеру нечего будет тестировать. Сказав это, однако, если у вас есть доступ к среде тестирования , я не понимаю, почему вы не можете вставить тестовые данные вручную, а не с помощью сценариев.

АЕК
источник

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

Кристиан П

@ christian.p проверьте мои обновления относительно вашего разъяснения вопроса.

AJC

Таким образом, ваше решение состоит в том, чтобы отказаться от сценариев и просто добавить данные тестирования вручную через пользовательский интерфейс? Как насчет ответа, который предоставил P.Brian.Mackey, и своих ответов на соединение данных с пользовательским интерфейсом?

Кристиан П

@ christian.p Ну, я согласен, что вы должны использовать сценарии. НО не существует формальностей или правил, в которых говорится, что вы ДОЛЖНЫ. Основная причина использования скриптов для генерации фиктивных данных - скорость (автоматизация) и доступ (к тестовой среде). Если у вас есть доступ, и это делается быстрее и проще вручную, нет никаких причин, по которым вы не можете это сделать. (НО ведите журнал данных, с которыми вы тестировали).

AJC

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

Кристиан П

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

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

Начните делать рефакторинг. Сохраняйте улучшения небольшими, чтобы ими можно было управлять. Ищите анти-паттерны, такие как классы / методы Бога, не следуя СУХОЙ, единоличной ответственности и т. Д.

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

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

P.Brian.Mackey
источник

Мне нужно немного прояснить ситуацию: «Простое изменение тестовых данных приводит к ошибкам» - проблема здесь не в приложении - приложение работает нормально, когда данные действительны (и вы не можете добавить недействительные данные вручную) , Проблема здесь в том, что неверные тестовые данные могут привести к ошибкам при работе с этими данными. Таким образом, мы должны проверить данные теста также?

Кристиан П

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

P.Brian.Mackey

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

Кристиан П

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

P.Brian.Mackey

Но как нам решить проблему неверных фиктивных данных? Если мы продолжим создавать фиктивные данные для базы данных, как мы проверяем, в порядке ли фиктивные данные, или нет? Если бизнес-правило требует, чтобы значение X = 2 и база данных принимала X = 100 - как мы можем проверить целостность тестовых данных, когда бизнес-правило сложное?

Кристиан П

Это очень распространенная и очень сложная проблема. Автоматические тесты, которые запускаются на базе данных (даже в базе данных в памяти, такой как HSQLDB ), обычно медленны, недетерминированы и, поскольку сбой теста указывает только на наличие проблемы где-то в вашем коде или ваших данных, они не очень информативно.

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

Но если вы действительно хотите (или должны) автоматизировать тесты на постоянство, я бы порекомендовал вам прочитать « Растущее объектно-ориентированное программное обеспечение под руководством тестов» . В этой книге есть целая глава, посвященная тестам на стойкость.

Отавио Маседо
источник