«Стандартный» процесс тестирования

Question

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

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

До сих пор мы занимались в основном ручным тестированием.Мы пытаемся максимально автоматизировать.Я изучал некоторые инструменты, и вот типы тестов, которые, как мне кажется, мне нужны:

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

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

• Регрессионное тестирование - Кажется, мы получаем это бесплатно с нашими модульными тестами

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

• Функциональное тестирование - Это обычно делается в графическом интерфейсе?Есть ли хорошие варианты, управляемые кодом?

• Тестирование производительности и нагрузки - Убедитесь, что приложение быстро реагирует даже в условиях стресса.

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

Мои основные вопросы:

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

Большое спасибо!

Answer 1

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

интеграционное тестирование
Обычно это понимается как тестирование интеграции между компонентами вашего приложения.Это могут быть взаимодействия между модулями бизнес-уровня.Это могут быть взаимодействия между бизнес-объектами и объектами доступа к данным.За интеграционным тестированием скрывается много вещей.«связь между страницами» будет последней, о которой я подумаю.Это проверка «целостности» веб-приложения, но не многие здесь скажут, что это интеграционное тестирование.Возможно, начните с определения вики , отметьте ТАКИЕ вопросы .

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

Проверка целостности данных
Я не занимаюсь этим, но не уверен, правильно ли вы понимаете.Попробуйте поиск в Google ?

Функциональное тестирование
Функциональное тестирование обычно понимается как уровень графического интерфейса, но это не обязательно.Это может быть сделано на веб-сервисах, на EJB, даже на API.Проверьте это определение , чтобы прояснить это.
Что касается тестов на основе кода для GUI, существует множество решений.MSVS2010 - с его тестами CodedUI, HP QTP для многих технологий, есть инструмент от IBM, есть инструмент от Borland (Silk Test, теперь Borland принадлежит какой-то компании).Существуют инструменты с открытым исходным кодом: WatiN , Селен , Аббат , RobotFramework , многие другие.

Тестирование производительности
Тестирование производительности имеет множество разновидностей, стресс-тестирование, тестирование на замачивание, нагрузочное тестирование и многие другие.Проверьте это MS Reference для общего обзора.

Теперь основные вопросы:)

1. Вы можете делать всего понемногу, но вы просто поцарапаете поверхность.Кроме того, вам нужны люди, которые могут это сделать.Неуважение, но вы уверены, что ваши разработчики знают все это и могут это сделать?Что важнее, у них есть время, чтобы сделать все это?Начните с малого.Пройдите модульное тестирование, интеграционное тестирование компонентов, выполните регрессию на обоих из них.Начните автоматизировать функциональное тестирование, возможно попробуйте Acceptance Test Driven Development ( что-то здесь , что-то там ).Сосредоточьтесь больше на тех областях, где вы находите ошибки, максимизируйте свою рентабельность инвестиций: P (если у вас нет проблем с производительностью, может быть, слегка подумать о тестировании производительности?).
2. Настройка непрерывная интеграция .Часто выполняйте быстрые тесты, иногда запускайте медленные тесты, при необходимости выполняйте полную регрессию (на основе оценки риска).
3. Нет определенного правила относительно того, сколько часов потребуется для тестирования.Это будет зависеть от многих факторов.Самое главное, насколько глючит сам продукт?Больше ошибок -> больше исправлений -> больше регрессий = больше тестирования.Есть такие компании, как Google (один тестер для многих проектов) или Microsoft (до нескольких тестеров на одного разработчика).Трудно сказать априори проекту, без исторических данных (от вашей организации, для данных команд / типов проектов). Этот короткий пост может дать вам больше понимания.

Приветствия.

Answer 2

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

Итак, когда тесты разработчиков прошли успешно, и у вас есть работающая система, тогда пришло время для Системного теста (Вы можете отсортировать это, возможно, в Функциональное тестирование из ответа yoosiba) , И я бы не стал полностью автоматизировать эту часть (конечно, часть этого можно сделать автоматически).

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