Тестирование программы
Многие организации, занимающиеся созданием программного обеспечения, до 50% средств, выделенных на разработку программ, тратят на тестирование, что составляет миллиарды долларов по всему миру в целом. И все же, несмотря на громадные капиталовложения, знаний о сути тестирования явно не хватает и большинство программных продуктов неприемлемо ненадежно даже после «основательного тестирования».
О состоянии дел лучше всего свидетельствует тот факт, что большинство людей, работающих в области обработки данных, даже не может правильно определить слово «тестирование», и это на самом деле главная причина неудач.
«Тестирование – процесс, подтверждающий правильность программы и демонстрирующий, что ошибок в программе нет. Основной недостаток подобного определения заключается в том, что оно совершенно неправильно; фактически это почти определение антонима слова «тестирование». Читатель с некоторым опытом программирования уже, вероятно, понимает, что невозможно продемонстрировать отсутствие ошибок в программе. Поэтому определение описывает невыполнимую задачу, а так как тестирование зачастую все же выполняется с успехом, по крайней мере с некоторым успехом, то такое определение логически некорректно. Правильное определение тестирования таково: Тестирование – процесс выполнения программы с намерением найти ошибки.
Урок 2: Введение в Тестирование ПО — QA с Нуля — Что Такое QA
Невозможно гарантировать отсутствие ошибок в нетривиальной программе; в лучшем случае можно попытаться показать наличие ошибок. Если программа правильно ведет себя для солидного набора тестов, нет основании утверждать, что в ней нет ошибок; со всей определенностью можно лишь утверждать, что не известно, когда эта программа не работает. Конечно, если есть причины считать данный набор тестов способным с большой вероятностью обнаружить все возможные ошибки, то можно говорить о некотором уровне уверенности в правильности программы, устанавливаемом этими тестами.
Психологические эксперименты показывают, что большинство людей, поставив цель (например, показать, что ошибок нет), ориентируется в своей деятельности на достижение этой цели. Тестовик подсознательно не позволит себе действовать против цели, т. е. подготовить тест, который выявил бы одну из оставшихся в программе ошибок. Поскольку мы все признаем, что совершенство в проектировании и кодировании любой программы недостижимо и поэтому каждая программа содержит некоторое количество ошибок, самым плодотворным применением тестирования будет найти некоторые из них. Если мы хотим добиться этого и избежать психологического барьера, мешающего нам действовать против поставленной цели, наша цель должна состоять в том, чтобы найти как можно больше ошибок. Сформулируем основополагающий вывод:
Если ваша цель – показать отсутствие ошибок, вы. их найдете не слишком много. Если же ваша цель – показать наличие ошибок, вы найдете значительную их часть. Надежность невозможно внести в программу в результате тестирования, она определяется правильностью этапов проектирования. Наилучшее решение проблемы надежности – с самого начала не допускать ошибок в программе.
Учителям. Моя рабочая программа всего 4 страницы. Рассказываю как упростить.
Однако вероятность того, что удастся безупречно спроектировать большую программу, бесконечно мала. Роль тестирования состоит как раз в том, чтобы определить местонахождение немногочисленных ошибок, оставшихся в хорошо спроектированной программе. Попытки с помощью тестирования достичь надежности плохо спроектированной программы совершенно бесплодны.
2.6.2 Виды и методы тестирования
Тестирование программы методом «черного ящика».
Одним из способов изучения поставленного вопроса является исследование стратегии тестирования, называемой стратегией «черного ящика», тестированием с управлением по данным или тестированием с управлением по входу-выходу. При использовании этой стратегии программа рассматривается как «черный ящик».
Иными словами, такое тестирование имеет целью выяснение обстоятельств, в которых поведение программы не соответствует спецификации. Тестовые же данные используются только в соответствии со спецификацией программы (т. е. без учета знаний о ее внутренней структуре). При таком подходе обнаружение всех ошибок в программе является критерием исчерпывающего входного тестирования. Последнее может быть достигнуто, если в качестве тестовых наборов использовать все возможные наборы входных данных. Если такое испытание представляется сложным, то еще сложнее создать исчерпывающий тест для большой программы.
Построение исчерпывающего входного теста невозможно. Это подтверждается двумя аргументами: во-первых, нельзя создать тест, гарантирующий отсутствие ошибок; во-вторых, разработка таких тестов противоречит экономическим требованиям.
Тестирование программы методом «белого ящика»
Стратегия «белого ящика», или стратегия тестирования, управляемого логикой программы, позволяет исследовать внутреннюю структуру программы, В этом случае тестирующий продукт получает тестовые данные путем анализа логики программы. Сравним способ построения тестов при данной стратегии с исчерпывающим входным тестированием стратегии «черного ящика».
Непосвященному может показаться, что достаточно построить такой набор тестов, в котором каждый оператор исполняется хотя бы один раз; нетрудно показать, что это неверно. Не вдаваясь в детали, укажем лишь, что исчерпывающему входному тестированию может быть поставлено в соответствие исчерпывающее тестирование маршрутов.
Подразумевается, что программа проверена полностью, если с помощью тестов удается осуществить выполнение программы по всем возможным маршрутам ее потока (графа) передач управления. Последнее утверждение имеет два слабых пункта. Первый из них состоит в том, что число не повторяющих друг друга маршрутов в программе — астрономическое.
Второй слабый пункт утверждения заключается в том, что, хотя исчерпывающее тестирование маршрутов является полным тестом и хотя каждый маршрут программы может быть проверен, сама программа будет содержать ошибки. Это объясняется следующим образом. Во-первых, исчерпывающее тестирование маршрутов не может дать гарантии того, что программа соответствует описанию. Например, вместо требуемой программы сортировки по возрастанию случайно была написана программа сортировки по убыванию. В этом случае ценность тестирования маршрутов невелика, поскольку после тестирования в программе окажется одна ошибка, т. е. программа неверна.
Во-вторых, программа может быть неверной в силу того, что пропущены некоторые маршруты. Исчерпывающее тестирование маршрутов не обнаружит их отсутствия.
При восходящем подходе программа собирается и тестируется «снизу вверх». Только модули самого нижнего уровня тестируются изолированно, автономно. После того как тестирование этих модулей завершено, вызов их должен быть так же надежен, как вызов встроенной функции языка или оператор присваивания. Затем тестируются модули, непосредственно вызывающие уже проверенные.
Эти модули более высокого уровня тестируются не автономно, а вместе с уже проверенными модулями более низкого уровня. Процесс повторяется до тех пор, пока не будет достигнута вершина. Здесь завершается и тестирование модулей, и тестирование сопряжений программы.
При восходящем тестировании для каждого модуля необходим драйвер: нужно подавать тесты в соответствии с сопряжением тестируемого модуля. Одно из возможных решений — написать для каждого модуля небольшую ведущую программу.
Тестовые данные представляются как «встроенные» непосредственно в эту программу переменные и структуры данных, и она многократно вызывает тестируемый модуль, с каждым вызовом передавая ему новые тестовые данные. Имеется и лучшее решение: воспользоваться программой тестирования модулей — это инструмент тестирования, позволяющий описывать тесты на специальном языке и избавляющий от необходимости писать драйверы. Здесь отсутствуют проблемы, связанные с невозможностью или трудностью создания всех тестовых ситуаций, характерные для нисходящего тестирования. Драйвер как средство тестирования применяется непосредственно к тому модулю, который тестируется, где нет промежуточных модулей, которые следует принимать во внимание. Не существует также и трудностей с незавершенностью тестирования одного модуля при переходе к тестированию другого, потому что при восходящем тестировании с применением нескольких версий заглушки нет сложностей с представлением тестовых данных.
Нисходящее тестирование (называемое также нисходящей разработкой) не является полной противоположностью восходящему, но в первом приближении может рассматриваться как таковое. При нисходящем подходе программа собирается и тестируется «сверху вниз». Изолированно тестируется только головной модуль.
После того как тестирование этого модуля завершено, с ним соединяются (на пример, редактором связей) один за другим модули, непосредственно вызываемые им, и тестируется полученная комбинация. Процесс повторяется до тех пор, пока не будут собраны и проверены все модули. Нисходящий метод имеет как достоинства, так и недостатки по сравнению с восходящим.
Самое значительное достоинство — то, что этот метод совмещает тестирование модуля, тестирование сопряжений и частично тестирование внешних функций. С этим же связано другое его достоинство: когда модули ввода-вывода уже подключены, тесты можно готовить в удобном виде. Нисходящий подход выгоден также в том случае, когда есть сомнения относительно осуществимости программы в целом или когда в проекте программы могут оказаться серьезные дефекты. Преимуществом нисходящего подхода очень часто считают отсутствие необходимости в драйверах.
Нисходящий метод тестирования имеет, к сожалению, некоторые недостатки. Основным из них является то, что модуль редко тестируется досконально сразу после его подключения. Дело в том, что основательное тестирование некоторых модулей может потребовать крайне изощренных заглушек.
Программист часто решает не тратить массу времени на их программирование, а вместо этого пишет простые заглушки и проверяет лишь часть условий в модуле. Второй тонкий недостаток нисходящего подхода состоит в том, что он может породить веру в возможность начать программирование и тестирование верхнего уровня программы до того, как вся программа будет полностью спроектирована.
Эта идея на первый взгляд кажется экономичной, но обычно дело обстоит совсем наоборот. Большинство опытных проектировщиков признаёт, что проектирование программы — процесс итеративный. Редко первый проект оказывается совершенным. Нормальный стиль проектирования структуры программы предполагает по окончании проектирования нижних уровней вернуться назад и подправить верхний уровень, внеся в него некоторые усовершенствования или исправляя ошибки, либо иногда даже выбросить проект и начать все сначала, потому что разработчик внезапно увидел лучший подход. Если же головная часть программы уже запрограммирована и оттестирована, то возникает серьезное сопротивление любым улучшениям ее структуры.
Источник: kazedu.com
Тестирование информационных систем
разработана в соответствии с ФГОС:
Федеральный государственный образовательный стандарт среднего профессионального образования по специальности 09.02.07 Информационные системы и программирование. (приказ Минобрнауки России от 09.12.2016 г. № 1547)
составлена на основании учебного плана:
Информационные системы и программирование Профиль получаемого профессионального образования при реализации программы среднего общего образования: технический
утвержденного учёным советом вуза от 27.04.2021 протокол № 6.
Рабочая программа одобрена на заседании Совета колледжа
Протокол от 26.03.2021 г. № 5
Срок действия программы: 2021-2022 уч. г.
Заведующий отделением
канд.ист.наук, Карпенко Е.А.
1. Цели освоения дисциплины
| овладение студентами теоретическими знаниями и практическими навыками в области тестирования современных информационных систем, используемых для решения проблем (задач), в различных областях деятельности человека |
2. Место дисциплины в структуре ППСЗ
| Цикл (раздел) ППСЗ: МДК.05 |
3. Компетенции обучающегося, формируемые в результате освоения дисциплины
| ОК 01: Выбирать способы решения задач профессиональной деятельности, применительно к различным контекстам | |
| ОК 02: Осуществлять поиск, анализ и интерпретанцию информации, необходимой для выполнения задач профессиональной деятельности | |
| ОК 03: Планировать и реализовывать собственное профессиональное и личностное развитие | |
| ОК 09: Использовать информационные технологии в профессиональной деятельности | |
| ОК 10: Пользоваться профессиональной документацией на государственном и иностранном языке | |
| ПК 5.2: Разрабатывать проектную документацию на разработку информационной системы в соответствии с требованиями заказчика | |
| ПК 5.5: Осуществлять тестирование информационной системы на этапе опытной эксплуатации с фиксацией выявленных ошибок кодирования в разрабатываемых модулях информационной системы | |
| ПК 5.6: Разрабатывать техническую документацию на эксплуатацию информационной системы | |
| В результате освоения дисциплины обучающийся должен | |
| Знать: | |
| основные виды и процедуры обработки информации, модели и методы решения задач обработки информации; основные платформы для создания, исполнения и управления информационной системой; методы и средства проектирования, разработки и тестирования информационных систем; систему стандартизации, сертификации и систему обеспечения качества продукции; |
|
| Уметь: | |
| осуществлять постановку задач по обработке информации; проводить анализ предметной области; использовать алгоритмы обработки информации для различных приложений; решать прикладные вопросы программирования и языка сценариев для создания программ; создавать и управлять проектом по разработке приложения; проектировать и разрабатывать систему по заданным требованиям и спецификациям; |
|
| Иметь навыки и (или) опыт деятельности (владеть): | |
| обеспечения сбора данных для анализа использования и функционирования информационной системы; использования критериев оценки качества и надежности функционирования информационной системы; применении методики тестирования разрабатываемых приложений; определении состава оборудования и программных средств разработки информационной системы; разработки документации по эксплуатации информационной системы; проведении оценки качества и экономической эффективности информационной системы в рамках своей компетенции; |
|
| Раздел 1. Отладка и тестирование информационных систем | ||||||
| 1.1. | Отладка и тестирование информационных систем | Сам. работа | 6 | 20 | ОК 01 | Л1.1, Л2.1 |
| 1.2. | Организация тестирования в команде разработчиков | Лекции | 6 | 8 | ОК 01, ПК 5.2 | Л1.1, Л2.1 |
| 1.3. | Виды и методы тестирования (в том числе автоматизированные) | Лекции | 6 | 6 | ОК 01 | Л1.1, Л2.1 |
| 1.4. | Тестовые сценарии, тестовые варианты. Оформление результатов тестирования | Лекции | 6 | 6 | ОК 01 | Л1.1, Л2.1 |
| 1.5. | Инструментарии анализа качества программных продуктов в среде разработке. | Лекции | 6 | 6 | ОК 01, ПК 5.2 | Л1.1, Л2.1 |
| 1.6. | Обработка исключительных ситуаций. Методы и способы идентификации сбоев и ошибок. | Лекции | 6 | 6 | ОК 01, ПК 5.2 | Л1.1, Л2.1 |
| 1.7. | Выявление ошибок системных компонентов. | Лекции | 6 | 8 | ОК 01, ПК 5.5 | Л1.1, Л2.1 |
| 1.8. | Реинжиниринг бизнес-процессов в информационных системах. | Лекции | 6 | 6 | ОК 01 | Л1.1, Л2.1 |
| 1.9. | Лабораторная работа «Разработка тестового сценария проекта» | Лабораторные | 6 | 4 | ОК 01 | Л1.1, Л2.1 |
| 1.10. | Лабораторная работа «Разработка тестовых пакетов» | Лабораторные | 6 | 4 | ОК 01 | Л1.1, Л2.1 |
| 1.11. | Лабораторная работа «Разработка тестовых пакетов» | Консультации | 6 | 2 | ОК 01 | Л1.1, Л2.1 |
| 1.12. | Лабораторная работа «Использование инструментария анализа качества» | Лабораторные | 6 | 4 | ОК 01, ПК 5.2, ПК 5.5, ПК 5.6 | Л1.1, Л2.1 |
| 1.13. | Лабораторная работа «Анализ и обеспечение обработки исключительных ситуаций» | Лабораторные | 6 | 6 | ОК 01, ПК 5.2, ПК 5.5 | Л1.1, Л2.1 |
| 1.14. | Лабораторная работа «Функциональное тестирование» | Лабораторные | 6 | 6 | ОК 01 | Л1.1, Л2.1 |
| 1.15. | Лабораторная работа «Тестирование безопасности» | Лабораторные | 6 | 6 | ОК 01 | Л1.1, Л2.1 |
| 1.16. | Лабораторная работа «Нагрузочное тестирование, стрессовое тестирование» | Лабораторные | 6 | 6 | ОК 01, ПК 5.2, ПК 5.5, ПК 5.6 | Л1.1, Л2.1 |
| 1.17. | Лабораторная работа «Тестирование интеграции» | Лабораторные | 6 | 6 | ОК 01, ПК 5.2, ПК 5.5 | Л1.1, Л2.1 |
| 1.18. | Лабораторная работа «Конфигурационное тестирование» | Лабораторные | 6 | 6 | ОК 01, ПК 5.2, ПК 5.5, ПК 5.6 | Л1.1, Л2.1 |
| 1.19. | Лабораторная работа «Тестирование установки» | Лабораторные | 6 | 6 | ОК 01, ПК 5.5 | Л1.1, Л2.1 |
5. Фонд оценочных средств
6. Учебно-методическое и информационное обеспечение дисциплины
| 6.1. Рекомендуемая литература | ||||
| 6.1.1. Основная литература | ||||
| Авторы | Заглавие | Издательство, год | Эл. адрес | |
| Л1.1 | Черткова Е. А. | Программная инженерия. Визуальное моделирование программных систем: учебник для СПО | Юрайт, 2018 | https://urait.ru/bcode/428746 |
| 6.1.2. Дополнительная литература | ||||
| Авторы | Заглавие | Издательство, год | Эл. адрес | |
| Л2.1 | Казанский А. А. | Программирование на visual c# 2013: учебное пособие для СПО | Юрайт, 2018 | https://urait.ru/bcode/414752 |
| 6.2. Перечень ресурсов информационно-телекоммуникационной сети «Интернет» | ||||
| Название | Эл. адрес | |||
| Э1 | Тестирование информационных систем | https://portal.edu.asu.ru/course/view.php?id=9803 | ||
| 6.3. Перечень программного обеспечения | ||||
| ОС Windows OC Linux Приложения MS Office Приложения LibraOffice 7-Zip AcrobatReader Стандартное специализированное ПО в соответствии с наименованием кабинетов |
||||
| 6.4. Перечень информационных справочных систем | ||||
| Информационная справочная система: СПС КонсультантПлюс (инсталлированный ресурс АлтГУ или http://www.consultant.ru/) Профессиональные базы данных: Электронная библиотечная система Алтайского государственного университета (http://elibrary.asu.ru/); Научная электронная библиотека elibrary (http://elibrary.ru) |
||||
7. Материально-техническое обеспечение дисциплины
| 203Н | кабинет математики; кабинет математических дисциплин; кабинет статистики; кабинет математики и информатики; кабинет информационных систем в профессиональной деятельности – учебная аудитория для проведения занятий всех видов (дисциплинарной, междисциплинарной и модульной подготовки), групповых и индивидуальных консультаций, текущего контроля и промежуточной аттестации | Учебная мебель на 54 посадочных места; рабочее место преподавателя; маркерная доска – 1 ед.; компьютер (модель: Aquarius) с доступом в информационно-телекоммуникационную сеть Интернет – 1 ед.; интерактивная доска (марка: Smart) – 1 ед.; проектор (марка: Smart) – 1 ед..; калькуляторы; чертежные принадлежности; модели геометрических тел; раздаточный дидактический материал; учебно-методические издания; таблицы. |
| 410Н | лаборатория информационно-ком-муникационных технологий; лаборатория информационных систем в профессиональной деятельности; лаборатория учебная бухгалтерия; лаборатория информатики; лаборатория систем электронного документооборота; лаборатория информатики и информационно-коммуникационных технологий в профессиональной деятельности; лаборатория информационных технологий в профессиональной деятельности; лаборатория технических средств обучения — учебная аудитория для проведения занятий всех видов (дисциплинарной, междисциплинарной и модульной подготовки), групповых и индивидуальных консультаций, текущего контроля и промежуточной аттестации | Автоматизированные рабочие места на 10 обучающихся; автоматизированное рабочее место преподавателя (ноутбук); компьютеры (марка: HP) с доступом в информационно-телекоммуникационную сеть Интернет и электронную информационно-образовательную среду АлтГУ; маркерная доска — 1 ед.; тематические плакаты. |
8. Методические указания для обучающихся по освоению дисциплины
Источник: www.asu.ru
Процесс QA тестирования: Основные этапы, подходы и инструменты
Когда вы начинаете подумывать о том, чтобы стать тестировщиком, и читаете что-то на эту тему, новые термины и понятия встречаются буквально в каждом предложении. Процесс контроля качества, “черный ящик”, “белый ящик”, модульные тесты, регрессионные тесты, ручное и автоматическое тестирование, BrowserStack, Jira. Все это звучит так сложно! Складывается впечатление, что на то, чтобы освоить эту профессию, у вас уйдут годы.
Что ж, нужно признать: чтобы стать тестировщиком, потребуются определенные усилия. Но поверьте, это не так сложно, как может показаться на первый взгляд. Под умелым руководством вы можете обучиться основным навыкам довольно быстро.
Эта статья поможет вам разобраться в процессе QA, основных этапах тестирования программного обеспечения и наиболее часто используемых при этом инструментах.
Прочитав её, вы узнаете:
- В чем разница между процессом обеспечения качества (QA) и контролем качества (QС)
- Каковы основные этапы QA процесса при разработке программного обеспечения
- В чем разница между ручным и автоматическим тестированием
- Какие бывают виды тестов и подходы к тестированию
- Какие инструменты помогают оптимизировать процесс
Что такое процесс обеспечения качества (QA) и чем он отличается от контроля качества (QC)?
Процесс обеспечение качества при разработке программного обеспечения или QA (quality assurance) — это процесс, который предотвращает появление ошибок в конечном продукте и гарантирует, что компания выпустит по-настоящему качественное приложение. Процесс QA — это больше, чем просто контроль качества и тестирование. В то время как контроль качества (QC) сосредоточен на проверке конечного продукта, QA является частью всех этапов и стадий разработки программного обеспечения. Другими словами, QA — это комплекс мероприятий, направленных на предотвращение дефектов и ошибок, а QC — на их выявление. Правильно настроенный процесс QA гарантирует, что все члены команды будут работать эффективно, время, необходимое для разработки, сократится, а затраты снизятся.
Конечно, в разных компаниях процесс QA может отличатся. Однако, как правило, основные стадии и этапы совпадают. И если вы с ними знакомы, вам проще будет разобраться во всех этих новых терминах и концепциях.
Каковы основные этапы QA процесса?
Работа с требованиями
В современных компаниях процесс QA начинается на очень ранних этапах жизненного цикла разработки программного обеспечения — прямо на этапе анализа требований. Тестировщики проверяют требования и функциональные спецификации, чтобы убедиться, что они чёткие, непротиворечивые, полные, выполнимые и их возможно протестировать.
Планирование тестирования
После того, как тестировщики поняли требования, они могут начать разработку стратегии тестирования и планирование процедур по контролю качества. На этом этапе они определяют объем работ и бюджет, решают, какой подход использовать на каждом этапе разработки программного обеспечения, какие виды и типы тестирования потребуются, какие инструменты лучше использовать.
Разработка тестовых сценариев
Имея на руках план, пора разработать тестовые сценарии или тест кейсы, создать чек-листы, подготовить среду для выполнения тестов и создать сценарии для автоматического тестирования.
Тестирование программного обеспечения
На этом этапе всё готово для поиска ошибок и дефектов. Команда QA специалистов начинает выполнять различные типы тестов. Тестировщики сообщают обо всех обнаруженных ошибках.
Повторное тестирование
Как только группа разработчиков устраняет проблему, тестировщики повторно проверяют функциональность и проводят так называемое регрессионное тестирование, чтобы убедиться, что после внесённых изменений программное обеспечение по-прежнему работает правильно.
Завершение тестирования
После того, как все запланированные тесты выполнены и все исправления перепроверены, наступает время подготовки отчёта о результатах тестирования. В документации описываются все тесты, выполненные в течение жизненного цикла разработки программного обеспечения.
Какие типы или виды тестирования используются в QA процессе?
Теперь, когда мы понимаем, что представляет собой процесс QA, давайте поговорим о различных типах тестов, используемых при тестировании программного обеспечения. Да, их очень много. Но волноваться не стоит. Как только вы поймёте, по каким принципам тесты делятся на группы, вы легко сможете в них ориентироваться.
Функциональные и нефункциональные тесты
Основные категории тестов — это функциональные и нефункциональные тесты.
При функциональном тестировании мы проверяем, работает ли приложение должным образом. Другими словами, мы проверяем, соответствует ли фактический результат ожидаемому результату.
В нефункциональном тестировании мы проверяем, как наше приложение работает в различных условиях. Нагрузочные тесты, тесты безопасности, стрессовые тесты и тесты удобства пользования — все они попадают в эту категорию.
Знание исходного кода
Если тестировщики знают исходный код до тестирования, речь идет о тестировании “белого ящика” (white box testing). В противном случае мы имеем дело с тестированием “черного ящика” (black box testing), когда тестировщики оценивают только поведение приложения, не зная его внутреннего устройства. Тестирование “серого ящика” (grey box testing) представляет собой комбинацию этих двух подходов. Тестировщикам предоставляется ограниченная информация о внутренней структуре системы.
Подход к выполнению тестов
Некоторые тесты выполняются людьми, и мы говорим о ручном тестировании. При этом подходе тестировщики выполняют тестовые сценарии и создают отчеты о результатах.
Другие тесты выполняются компьютерами. Инженеры по автоматизации тестирования создают сценарии автоматического тестирования и пишут код, который многократно проверяет программное обеспечение на наличие ошибок. Здесь мы имеем дело с автоматическим тестированием.
У каждого из этих подходов есть свои плюсы и минусы. Они дополняют друг друга. Например, ручное тестирование лучше подходит для проверки небольших изменений. Во время ручного тестирования тестировщики часто могут найти такие проблемы, которые остались бы незамеченными, если бы они полагались только на автоматизированные тесты. Ручное тестирование не требует глубоких знаний языков программирования и его достаточно легко освоить.
В то же время, при работе над большими приложениями, тестирование без использования автоматических тестов может занять слишком много времени. Мы также не можем исключить вероятность человеческих ошибок.
Для каждого отдельно взятого проекта QA специалисты определяют идеальный баланс между ручным и автоматическим тестированием.
Фаза разработки программного обеспечения
Мы разделяем тесты на модульные, интеграционные, системные — в зависимости от того, на каком этапе цикла разработки программного обеспечения находится команда.
Вот еще несколько типов тестов, с которыми вы часто будете сталкиваться в публикациях:
Дымовые тесты (smoke tests) предназначены для проверки базовой функциональности приложения. Это быстро выполнимые тесты, с помощью которых тестировщики следят за тем, чтобы основные функции системы работали правильно.
Регрессионные тесты (regression tests) помогают проверить, работает ли приложение так, как оно должно работать, после внесения каких-либо изменений, например исправления дефектов.
Нагрузочные тесты (load tests) необходимы для проверки приложения как при средней, так и при пиковой нагрузке.
Кроссбраузерное / кроссплатформенное тестирование помогает анализировать поведение приложения в различных браузерах и системах.
Конечно, это не все типы тестов, которые используются в процессе разработки программного обеспечения. Но знание этих основных категорий поможет вам лучше ориентироваться в теме QA.
Инструменты тестирования
Теперь, когда мы знаем, что такое процесс QA и какие существуют методы, подходы и типы тестов, давайте поговорим о том, какие инструменты тестировщики используют в своей работе. Инструмент тестирования — это любой продукт, который помогает оптимизировать различные действия: сбор требований, планирование, выполнение тестов, создание отчётов и анализ результатов.
Существует огромное количество таких сервисов и приложений. Никто не будет ожидать от начинающего тестировщика знание всех этих продуктов. Но будет полезно ознакомиться с некоторыми из наиболее популярных, такими как Selenium, Jira или BrowserStack.
Selenium — самый популярный инструмент тестирования. Он не требует глубоких знаний языков программирования и удобен для новичков.
Jira — это распространённый инструмент для отслеживания ошибок и дефектов. Он также используется для управления проектами.
BrowserStack позволяет разработчикам тестировать свои приложения в разных браузерах, устройствах или операционных системах.
Заключение
Независимо от того, какие подходы или методы использует компания, конечная цель всегда одна — предоставить клиентам продукт высочайшего качества. Хорошо налаженный QA процесс помогает снизить затраты на разработку и улучшить качество программного обеспечения. И вы можете внести свой вклад в этот процесс.
И вы сможете внести свой вклад в этот процесс. Как видите, придётся многому научиться. Но когда вы понимаете основные концепции, методы и инструменты, разобраться во всём этом не так уж сложно.
Наши краткосрочные курсы помогают таким же людям, как вы, преодолеть свои первые страхи и начать строить новую карьеру в качестве тестировщика. Изучение основ под чутким руководством наших опытных преподавателей — это вопрос нескольких недель.
Анна Мороз
Автор, редактор, контент-менеджер.
Источник: www.careerist.com
Основы тестирования. Виды тестирования по критерию уровня
Существует множество видов тестирования. И в них иногда очень легко заблудиться. Поэтому с этой статьи мы с вами начинаем разбираться в видах тестирования.
Что за уровни тестирования? Что тестируется на каждом из них? Какие у них цели? Разберем в статье.
Чтобы было проще разбираться во всех терминах, давайте упростим изучение и разобьем виды тестирования на две составляющие:
1. Уровни тестирования
2. Типы тестирования
Причем, различные типы тестирования могут выполняться на разных уровнях тестирования. Зрительно это можно представить следующим образом:
В первую очередь рассмотрим уровни тестирования. Выделяют 4 основных уровня тестирования:
1. Компонентное/модульное тестирование (Component/Unit Testing).
2. Интеграционное тестирование (Integration Testing).
3. Системное тестирование (System Testing).
4. Приемочное тестирование (Acceptance Testing).
Каждый уровень тестирования направлен на определенную часть программы и выполняет свои цели.
Компонентное/модульное тестирование
Этот вид тестирования выполняется на самой ранней стадии разработки программы — во время написания кода. Обычно его выполняет сам программист, который пишет код. Следовательно, ошибки, в большинстве случаев, исправляются сразу же и не попадают к специалистам по тестированию.
Как видно из названия, модульное тестирование направлено на тестирование отдельных модулей и компонентов программы, которые изолированы от других модулей и компонентов. Поэтому его стоит совмещать с другими видами тестирования, сам по себе он малоэффективен.
Для этого уровня тестирования характерно несколько целей:
1. Проверка компонента на соответствие требованиям,
2. Обнаружение ошибок в компоненте,
3. Предотвращение пропуска ошибок на более высокие уровни тестирования.
С помощью компонентного тестирования мы снижаем риски и укрепляем свою уверенность в качестве продукта. К сожалению, этот уровень тестирования требует большой ответственности и ресурсов со стороны разработки, и в большинстве случаев на него нет времени. Поэтому, такое тестирование редко используется в компаниях.
Интеграционное тестирование
Интеграционное тестирование необходимо для того ,чтобы тестировать взаимосвязь между чем-либо.
В общем случае различают два вида интеграционного тестирования:
— Компонентное интеграционное тестирование. Как видно из названия, оно необходимо для того, чтобы протестировать работу модулей в связке друг с другом.
— Системноеинтеграционное тестирование. Если с предыдущим уровнем тестирования все понятно, то с системным интеграционным тестирование все несколько сложнее. Этот уровень необходим для тестирования систем друг с другом.
Давайте рассмотрим на примере. Предположим мы разрабатываем игру для смартфона. Сама игра является системой, которую необходимо протестировать. Кроме этого, есть еще сервисы, которые взаимодействуют с игрой и такое взаимодействие тоже должно быть проверено. Таких сервисов достаточно много, хотя на первый взгляд их трудно заметить.
Каждый из них является системой, которая интегрируется в нашу игру.Например, игра может поддерживать социальную сеть Facebook, чтобы можно было играть с друзьями. В этом случае, необходимо протестировать корректно ли работает вход в социальную игру через нашу игру, можем ли мы видеть список друзей и т.д.
Для этого уровня тестирования также характерно несколько целей:
1. Проверка интерфейсов на соответствие требованиям.
2. Обнаружение ошибок в интерфейсах.
3. Предотвращение пропуска ошибок на более высокие уровни тестирования.
С помощью интеграционного тестирования мы снижаем риски и укрепляем свою уверенность в качестве продукта.
Системное тестирование
Системное тестирование — это тестирование еще более высокого уровня. Напомню, что на компонентном тестировании мы тестируем отдельные модули, а на интеграционном — связь между компонентами. При системном тестировании наша задача уже состоит в том, чтобы убедиться в корректности работы в целом всей системы. Программа в этом случае должна быть максимально приближена к конечному результату. А наше внимание должно быть сосредоточено на общем поведении системы с точки зрения конечных пользователей.
Для этого уровня тестирования также характерно несколькоцелей:
1. Проверка системы на соответствие требованиям.
2. Обнаружение ошибок в системе.
3. Предотвращение пропуска ошибок на более высокие уровни тестирования.
С помощью системного тестирования мы снижаем риски и укрепляем свою уверенность в качестве продукта.
Приемочное тестирование
Приемочное тестирование — наиболее высокий уровень тестирования. Оно, также как и системное тестирование, необходимо для проверки работы программы в целом.
Тут также смещаются цели тестирования. Ошибок на этом этапе уже не должно быть. Скорее наоборот, программа должна быть максимально рабочей и пригодной для использования. Если на данном этапе обнаруживается критичные дефекты, то есть большая вероятность того, программа была плохо протестирована на предыдущих уровнях.
Этот уровень тестирования используется для подтверждения готовности продукта и проводится преимущественно в самом конце цикла разработки программы.
У приемочного тестирования есть также несколько целей:
1. Показать, что программа завершена и готова к использованию так, как от нее ожидалось.
2. Проверить, что работа программы соответствует установленному ТЗ или требованиям.
Также, на этом уровне тестирования мы показываем уверенность в качестве системы.
По версии ISTQB существует несколько форм приемочного тестирования:
1. Пользовательское приемочное тестирование.
2. Эксплуатационное приемочное тестирование.
3. Контрактное и нормативное приемочное тестирование.
4. Альфа- и Бета-тестирование.
Пользовательское приемочное тестирование предназначено для проверки программы, как если бы ее использовал конечный пользователь. В этом случае мы должны убедиться, что все функции и части работают так, как задумывалось в требованиях. Если вернуться к примеру с программой по поиску такси, то мы должны быть уверены, что такси вызывается корректно, можно оплачивать поездку через программу, оставлять отзывы, отменять вызов и так далее.
С другой стороны стоит эксплуатационное приемочное тестирование. Его отличие заключается в том, что мы проводим тестирование не с позиции пользователей, а с позиции тех, кто будет поддерживать работу программы. Наша задача — убедиться в работоспособности таких аспектов, как:
1. Возможность резервного копирования и восстановления данных.
2. Установка, удаление и обновление программы.
3. Восстановление после полного падения системы.
4. Управление пользователями.
5. Возможность сопровождения (обслуживания).
6. Возможность загрузки и миграции данных.
7. Отсутствия уязвимостей.
8. Хорошая производительность.
Если программа разрабатывается у сторонней компании, то иногда заключается контракт, в котором оговорены условия приемки. Проверка на соответствие таким критериям проводится при контрактном приемочном тестировании.
Альфа- и Бета- тестирование используется, когда есть необходимость в получении обратной связи от пользователей. Поэтому именно они участвуют в таких проверках. Отличие альфа-тестирования от бета-тестирования заключается в том, что альфа-тестирование проводится внутри компании на потенциальных пользователях, а бета-тестирование проводится в ограниченном кругу конечных пользователей программы.
Такое часто распространено в играх. Игрокам сначала показывается бета версия игры, а через некоторое время игра выходит в релиз и становится доступной для всех.
Для наглядности все уровни тестирования можно представить следующим образом:
В реальной жизни рисунок может быть и другой формы, например, прямоугольник или перевернутая пирамида.
Источник: sedtest-school.ru
Программы компьютерного тестирования.
Для компьютерного тестирования в отечественной образовательной практике чаще всего используется программы OpenTEST2, Асистент2, УТК (Универсальный тестовый комплекс), MyTest X т.
OpenTEST. Специализированная программа, предоставляющая возможность тестирования в локальной сети в интерактивном режиме. Данная технология с использованием открытого кода написания программы. ее ориентация на Интернет-технологии дает возможность установить только на сервере программу для тестирования а на локальных машинах никаких программ устанавливать не нужно. Благодаря написания программы OpenTest на PHP ее можно устанавливать как под Windows так и под Linux.
Интерфейс программы состоит из 5 больших модулей: тестирование — для проведения тестирования, статистика — для вывода различной статистической информации, студия тестов — для создания и редактирования тестов, управления пользователями — для контроля и управления пользователями, зона администрирования — для управлением тестовыми процессами в режиме on -line. Для создания и редактирования тестов модная использовать модуль студии тестов, или отдельную программу для создания тестов TestEditor.
Вопросы и ответы могут содержать в себе графические объекты, что позволяет использовать более интересные варианты тестов. Готовые тесты можно экспортировать и импортировать. Вся информация о тестах и тестирования сохраняется в базе данных на сервере и доступна с любой машины сети по паролю.
Асистент2. Программа имеет несложную форму создания тестов, используя простой текстовый редактор — блокнот. Созданные тесты легко можно изменить, но существенным недостатком программы является то, что не поддерживаются графические объекты. И во время прекращения тестирования можно получить 12 баллов ответив только на один первый вопрос. Сервер статистики показывает довольно неплохую статистическую информацию общего характера, которая также хранится на в виде текстового файла.
УТК (Универсальный тестовый комплекс). Программа создана для проведения тестирования в компьютерном классе. Сама программа состоит из двух частей — генератора и тестера. Из самого названия понятно, что генератор используется для создания тестов и отладки тестирования в классе, а тестер — модуль для локального тестирования.
Генератор тестов используется для создания и редактирования компьютерных и бланковых тестов, проведения сетевого тестирования и вывода отчетности. Программа широко использует Microsoft Word, поэтому эта программа должна быть установлена на компьютере. Для использования генератора в полной мере нужно зарегистрировать программу в Интернете (регистрация бесплатная).
Вопросы и ответы в УТК 1.51 могут быть трех типов А-выбор из предоставленных вариантов правильных, В — введение правильного ответа, D — построение правильной последовательности. Строение вопросов такова, что можно создать и распечатать бумажный вариант для тестирования в классе без использования компьютера. Готовые тесты достаточно легко экспортируются и импортируются в программу.
Программа тестер проводит тестирование и выдает ответы ученику что проходит тестирование. Недостатком является то, что варианты ответа не перемешиваются (возможно в платной версии этот недостаток исправлен). Результаты тестирования имеют красивый и понятный вид, хранятся в файле, их достаточно легко можно просмотреть и распечатать.
К тому же генератор работает только на одном компьютере и тестирование по локальной сети можно провести только при включенном и отлаженном генераторе тестов [2].
MyTest X это — система программ (программа тестирования учащихся, редактор тестов и журнал результатов) для создания и проведения компьютерного тестирования, сбора и анализа результатов, выставления оценки по указанной в тесте шкале. С помощью программы MyTest X возможна организация и проведение тестирования, экзаменов в любых образовательных учреждениях (вузы, колледжи, школы) как с целью выявить уровень знаний по любым учебным дисциплинам, так и с учебными целями.
Программа легкая и удобная в использовании. MyTest X работает с девятью типами заданий: одиночный выбор, множественный выбор, установление порядка следования, установление соответствия, указание истинности или ложности утверждений, ручной ввод числа, ручной ввод текста, выбор места на изображении, перестановка букв. В тесте можно использовать любое количество различных типов, можно только один, можно и все сразу. В задачах с выбором ответа (одиночный, множественный выбор, определение порядка, определения истинности) можно использовать до 10 (включительно) вариантов ответа.
Программа состоит из трех модулей: Модуль тестирования Редактор тестов и Журнал тестирования. Для создания тестов очень удобный редактор тестов. Любой учитель-предметник, что даже владеет компьютером на начальном уровне, может легко составить свои тесты для программы и использовать их на уроках.
В программе есть богатые возможности форматирования текста вопросов и вариантов ответа. Можете определить шрифт, цвет символов и фона, использовать верхний и нижний индекс, разбивать текст на абзацы и применять к ним расширенное форматирование, использовать списки, вставлять рисунки и формулы. Для большего удобства в программе есть собственный текстовый редактор.
К каждому заданию можно задать сложность (количество баллов по верный ответ), прикрепить подсказку (показ может быть за штрафные баллы) и объяснение верного ответа (выводится в случае ошибки в обучающем режиме), настроить другие параметры .
Есть возможность использовать несколько вариантов вопрос задачи, удобно создавать выборку заданий для учащихся, перемешивать задания и варианты ответов. Это значительно уменьшает возможность списывания во время прохождения одного и того же теста несколькими тестируемыми или его повторном прохождении.
В можно использовать любую систему оценивания. Система оценки и ее настройки можно задать или изменить в редакторе теста.
При наличии компьютерной сети можно, используя модуль журнала, можно легко: 1. Организовать централизованный сбор и обработку результатов тестирования. Результаты выполнения заданий выводятся учащемуся и отправляются учителю. Учитель может оценить или проанализировать их в любое удобное для него время.
2. Организовать раздачу тестов ученикам через сеть, тогда отпадает необходимость каждый раз копировать файлы тестов на все компьютеры. Раздавать можно сразу несколько разных тестов. 3. Непосредственно следить за процессом тестирования. Можете видеть кто и какой тест выполняет, сколько заданий уже выполнено и какова их результативность. С помощью программ X можно организовать как локальное так и сетевое тестирование.
Источник: studbooks.net