Методы тестирования очень большого приложения

10

У меня есть приложение PHP, которое очень большое. Обычно над ней работают 2-3 разработчика, и мы подошли к тому моменту, когда вносим изменения и создаем ошибки (кашляю!). Скажем, программное обеспечение не сложное, просто много чего происходит (35 контроллеров, примерно одинаковых моделей и т. Д.).

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

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

Может быть, нам нужен неполный рабочий день Q / A человек?

У любого есть какие-либо предложения / мысли.

Wizzard
источник
"... тогда проводим тесты", это должно было быть чем ?
ajax333221

Ответы:

25

Да, вам нужен персонал Q / A. Некоторые из многих причин включают

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

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

Килиан Фот
источник
3
+1. Мы слишком хорошо подготовлены, чтобы выявлять проблемы, с которыми сталкиваются обычные пользователи
superM
3

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

Затем спросите себя, можете ли вы автоматизировать некоторые или большинство тестов с разумными усилиями. Если ответ «да», вы должны их запрограммировать. Если ответ «нет», и вы думаете, что «человек, занятый неполный рабочий день» дешевле, то это должно быть то, что вам нужно. В большинстве случаев хорошей идеей будет иметь как специалиста по Q / A для ручного тестирования и изобретения новых тестов, так и множество автоматических регрессионных тестов.

Док Браун
источник
+1 за упоминание регрессионных тестов и указание, что модульные тесты - не единственное эффективное решение.
Джорджио
Привет, можешь подробнее рассказать о регрессионных тестах. Я считаю, что это предотвращает повторение старых ошибок - но с помощью методов вы предлагаете, чтобы это было сделано? Модульные тесты? «Контрольный список» вещей для проверки? Спасибо :)
Wizzard
@Wizzard: термин «регрессионные тесты» - это просто общий термин для любого вида тестов на уже существующие работающие функции (чтобы вы не нарушили его при смене приложения). Сюда входят тесты из контрольного списка, автоматические тесты через ваш веб-интерфейс (здесь, вероятно, ваш браузер), а также юнит-тесты. Я предлагаю сначала подумать о том, что тестировать, независимо от того , как вы собираетесь его тестировать (например, если вы говорите «мы попробовали модульный тест», вы уже на «как», а не на «что») ,
Док Браун
2

Наймите профессионального QA

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

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

Юсубы
источник
1

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

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

superM
источник
1

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

Существуют инструменты, которые могут в некоторой степени контролировать покрытие теста. Инструменты покрытия кода для PHP

Торстен Мюллер
источник
1
Извините, 35 контроллеров и примерно столько же моделей. Мммм, кажется, какая-то форма модульного тестирования поможет.
Wizzard