Процесс тестирования программного обеспечения и уровни тестирования

Процессы тестирования программного обеспечения

В своей серии «Тестирование программного обеспечения» я попытаюсь обсудить процесс тестирования программного обеспечения и уровни тестирования. Процессы тестирования программного обеспечения могут разрабатываться и изменяться от компании к компании и от человека к человеку. Я постараюсь вкратце объяснить общие процессы.

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

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

Таким образом, тестирование программного обеспечения - это бесконечный процесс.

1. Планирование

Это этап, на котором выполняется планирование тестирования. Определяется объем теста и оцениваются риски, связанные с тестами. Этап планирования - это часть, на которой определяется эффект от разработки и проводится анализ воздействия.

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

2. Создание сценариев

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

3. Подготовка тестовой среды и создание данных.

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

Предоставляются данные, необходимые для теста. После того, как тестовая среда подготовлена, данные, которые будут использоваться, определяются и подготавливаются в соответствии с объемом разработки. Это может быть пользователь, реклама или продукт.

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

4. Запустите сценарии.

Это этап, на котором запускаются тесты. На этом этапе применяются написанные сценарии тестирования.

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

5. Отчетность о результатах

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

Уровни тестирования

Когда мы говорим «тестирование», мы видим, что существуют разные типы тестов. Категоризация - это естественное явление, которое происходит спонтанно с течением времени. Типы тестов - это результаты, а не цели.

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

Модульное тестирование
Интеграционное тестирование
Системное тестирование
Приемочное тестирование

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

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

1. Модульное тестирование

Модульное тестирование - это термин, восходящий к древним временам, хотя его не очень часто можно услышать, поскольку язык программирования Smalltalk был разработан под руководством Алана Кея в 70-х годах. Модульное тестирование в информатике; Это процесс проверки того, правильно ли выполняет свою задачу блок кода (обычно метод), который вызывает или использует другой блок, путем отделения его от другого блока, с которым он связан. Модульные тесты завершатся ошибкой, если задача не будет выполнена правильно. То, что мы называем единицами, обычно является методом или функцией.

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

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

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

Его можно автоматизировать и легко использовать многократно.
Это должно быть легко написано.
После написания функция должна оставаться в том виде, в котором она использовалась.
Уметь работать должен каждый.
Его работа должна быть такой же простой, как нажатие кнопки.
Он быстро выполняет проверки.

Если вы не можете ответить Да на все следующие вопросы, вероятно, вы написали модульный тест:

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

Если ваш ответ на любой из приведенных выше вопросов отрицательный; Несмотря на то, что то, что вы пишете, является тестом, это определенно не модульный тест.

2. Интеграционное тестирование

«Как узнать, какую деталь нужно отремонтировать, если у вас сломалась машина? Двигатель состоит из множества различных частей, и все части работают вместе в гармонии. Ошибка могла произойти в любой из частей. Все компоненты объединяются и дают реальный результат: автомобиль движется. Вы можете думать об автомобиле как об интеграционном тесте. Если тест ошибочен, соединение частей неверно. Если тесты проходят гладко, значит, все части работают без сбоев.

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

Таким образом, интеграционный тест - это проверка работы двух или более подчиненных модулей как группы. Одним словом, интеграционное тестирование; проверяет комбинацию кодов, которую можно протестировать с помощью модульных тестов. Модульные тесты управляют только работой соответствующего модуля независимо от других модулей »[2].

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

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

3. Тестирование системы

Системное тестирование (или сквозное тестирование [E2E]). Это полное тестирование системы. Когда модульные тесты и интеграционные тесты тестируют части системы, этот нацелен на систему в целом. Это тестирование проводится тестировщиками QA. Например, тестирование всего приложения от входа до оформления заказа и проверка доставки электронных писем. Это делается с точки зрения пользователя, и не следует автоматизировать имитацию данных или поддельные запросы. Этот тип тестирования является наиболее сложным и требует много времени. Если ошибка была обнаружена во время тестирования E2E, это означает, что чего-то не хватало при модульном или интеграционном тестировании.

4. Приемочные испытания

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

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

Заключение

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

Я надеюсь, что эта статья поможет вам разобраться в процессах и уровнях тестирования. Спасибо за прочтение!