Войти
Ручное тестирование - это процесс ручного тестирования программного обеспечения на наличие дефектов. Для этого требуется, чтобы тестировщик играл роль конечного пользователя, при этом он использовал большинство функций приложения для обеспечения правильного поведения. Чтобы гарантировать полноту тестирования, тестировщик часто следует письменному плану тестирования, который проводит его через набор важных тестовых примеров.
Ключевым этапом процесса является тестирование программного обеспечения на предмет правильного поведения перед выпуском для конечных пользователей.
Для небольших инженерных работ (включая прототипы) исследовательского тестирования может быть достаточно. При таком неформальном подходе тестировщик не следует какой-либо строгой процедуре тестирования, а скорее изучает пользовательский интерфейс приложения, используя как можно больше его функций, используя информацию, полученную в предыдущих тестах, для интуитивного проведения дополнительных тестов. Успех исследовательского ручного тестирования во многом зависит от компетентности тестировщика в предметной области, потому что недостаток знаний приведет к неполноте тестирования. Одним из ключевых преимуществ неформального подхода является интуитивное понимание того, каково это использовать приложение.
Крупномасштабные инженерные проекты, основанные на ручном тестировании программного обеспечения, следуют более строгой методологии, чтобы максимально увеличить количество обнаруживаемых дефектов. Системный подход фокусируется на заранее определенных тестовых примерах и обычно включает следующие шаги.
Строгий подход, основанный на тестовых примерах, часто является традиционным для крупных проектов разработки программного обеспечения, которые следуют модели Waterfall. Однако, по крайней мере, одно недавнее исследование не показало резкой разницы в эффективности обнаружения дефектов между исследовательским тестированием и тестированием на основе тестовых примеров.
Тестирование может быть через черно-, бело- или тестирование серого ящика. При тестировании методом белого ящика тестировщик занимается выполнением операторов через исходный код. При тестировании методом черного ящика программное обеспечение запускается для проверки на наличие дефектов и меньше заботится о том, как выполняется обработка входных данных. Тестировщики «черного ящика» не имеют доступа к исходному коду. Тестирование методом серого ящика связано с запуском программного обеспечения с пониманием исходного кода и алгоритмов.
Также можно использовать статический и динамический подходы к тестированию. Динамическое тестирование включает запуск программного обеспечения. Статическое тестирование включает проверку требований, синтаксиса кода и любых других действий, которые не включают фактический запуск кода программы.
Тестирование можно разделить на функциональное и нефункциональное. При функциональном тестировании тестировщик проверит вычисления, любую ссылку на странице или любое другое поле, которое при заданном вводе может ожидаться выводом. Нефункциональное тестирование включает в себя, среди прочего, тестирование производительности, совместимости и пригодности тестируемой системы, ее безопасности и удобства использования.
Есть несколько этапов. Они есть:
Автоматизация тестирования может снизить или исключить стоимость фактического тестирования. Компьютер может выполнять запрограммированную последовательность шагов быстрее, чем человек, и он может запускать тесты в течение ночи, чтобы представить результаты утром. Однако труд, сэкономленный при реальном тестировании, должен быть потрачен вместо создания тестовой программы. В зависимости от типа тестируемого приложения и выбранных инструментов автоматизации это может потребовать больше труда, чем ручной подход. Кроме того, некоторые инструменты тестирования предоставляют очень большой объем данных, что потенциально создает трудоемкую задачу интерпретации результатов.
Такие вещи, как драйверы устройств и библиотеки программного обеспечения, необходимо тестировать с помощью тестовых программ. Кроме того, тестирование большого числа пользователей ( тестирование производительности и нагрузочное тестирование ) обычно моделируется в программном обеспечении, а не выполняется на практике.
И наоборот, графические пользовательские интерфейсы, макет которых часто меняется, очень трудно тестировать автоматически. Существуют тестовые среды, которые можно использовать для регрессионного тестирования пользовательских интерфейсов. Они полагаются на запись последовательностей нажатий клавиш и жестов мыши, затем их воспроизведение и наблюдение за тем, что пользовательский интерфейс каждый раз реагирует одинаково. К сожалению, эти записи могут не работать должным образом при перемещении или изменении метки кнопки в следующем выпуске. Автоматический регрессионный тест также можно обмануть, если выходные данные программы сильно различаются.
