Презентация "Введение в тестирование ПО"
Подписи к слайдам:
- Основы тестирования
- Модели жизненного цикла разработки
- Команда тестирования
- Типы и уровни тестирования
- Дефекты
- Портрет тестировщика ПО
Для начала мы ...
… удостоверяемся, все ли в порядке
Почему тестирование необходимо?- Тестирование необходимо, потому что люди склонны ошибаться. Одни ошибки незначительны, другие же опасны и дорого обходятся.
- Поскольку ошибки допускают все люди, мы должны внимательно проверять результаты своей (и чужой ;-) ) работы, всего, что мы делаем.
- Это процесс исполнения программы с целью обнаружения ошибок (“Искусство тестирования программ”, Г. Майерс, 1979)
- Процесс наблюдения за выполнением программы в специальных условиях и вынесения на этой основе оценки каких-либо ее аспектов ([ANSI/IEEE standard 610.12-1990: Glossary of SE Terminology. NY:IEEE, 1987])
- Техническое исследование программы для получения информации о ее качестве с точки зрения определенного круга заинтересованных лиц [С. Kaner, 1999]
- Проверка соответствия между реальным поведением программы и ее ожидаемым поведением на конечном наборе тестов, выбранном определенным образом [IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004]
1980
1987
1999
2004
Что такое тестирование? 2/2 Процесс, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этим результатов работ с целью определить, что они соответствуют описанным требованиям, показать, что они подходят для достижения заявленных целей, а также для нахождения дефектов. Определение тестирования «по частям» 1/5 Во-первых, тестирование – это процесс, а не единичное действие Определение тестирования «по частям» 2/5 Процесс тестирования включен во все активности жизненного цикла Определение тестирования «по частям» 3/5 Тестирование ПО может быть статическим и динамическим Статическое тестирование: Тестирование компонента или системы на уровне спецификации или реализации без исполнения кода программного продукта, например рецензирование или статический анализ кода. Динамическое тестирование: Тестирование, проводимое во время выполнения программного обеспечения, компонента или системы. Определение тестирования «по частям» 4/5- Планирование
- Подготовка
- Оценка
- Предоставление информации для принятия решений
- Повышение уверенности в уровне качества
- Обнаружение дефектов
- Предотвращение дефектов Тестирование помогает уменьшить общий уровень риска в системе после обнаружения и устранения дефектов и порождает уверенность в качестве ПО
- Объект тестирования (что сравнивается)
- Базис тестирования (с чем сравнивается)
- отдельный модуль
- компонент (несколько модулей)
- подсистема
- система
- документация с требованиями (маркетинговая, пользовательская, техническая)
- требования (функциональные , проектные, базы данных)
- модели, диаграммы, макеты
- сценарии использования
- код
- тестовые планы и сценарии
- проектная документация по автоматизации тестирования, код автоматизации тестирования
- другие документы или код
- Программа не делает чего-то, что она должна делать согласно техническим требованиям.
- Программа делает что-то, чего она не должна делать согласно техническим требованиям.
- Программа делает что-то, о чем в требованиях не упоминалось (?).
- Программа не делает чего-то, о чем не говорится в требованиях, однако подразумевается, что она должна делать это.
- Программа трудна для понимания, неудобна в использовании.
Ошибка (Error)
Дефект
(Defect)
Отказ
(Failure)
Связанные понятия: ошибка и отказ 2/2 Ошибка: Действие человека, которое приводит к неправильному результату . Отказ: Отклонение компонента или системы от ожидаемого выполнения, эксплуатации или результата. Демонстрация дефекта - Требования- На примере программы TestKnight
- Фрагмент требований:
- Диалоговое окно Опций
- Lines Number – размер шахматной доски (3…10)
- Cell Side – размер стороны клетки в пикселях
- Delay Between Moves, ms – пауза между движениями в процессе вычислений (0…5000). Используется для понимания принципов работы программы. Данную опцию следует использовать вместе с опцией
- Show …
- …..
- Нет проверки (забыли ;-) ) на диапазон обозначенный в требований 3-10
- Вводим в параметрах значение 0
- Нажимаем Ок
Дефекты появляются по разным причинам, но, как правило, их источником являются технические требования (спецификация).
Источники дефектов 2/2 Цена дефектов 1/2 Обнаружение и исправление дефекта программы после поставки обходится в 100 раз дороже, чем на стадии формирования требований и проектирования.Как отмечал Боэм в 1987 г., «именно это понимание заставляло разработчиков уделять главное внимание тщательному анализу требований и проектированию, ранней верификации и валидации, а также моделированию и имитации, которые помогали избежать затратных послепродажных работ по устранению неисправностей».
Цена дефектов 2/2Чем раньше дефект обнаружен, тем дешевле обходится его исправление
Терминология: «верификация» vs. «валидация» 1/3 Верификация: Доказанное объективными результатами исследования подтверждение того, что определенные требования были выполнены Терминология: «верификация» vs. «валидация» 2/3 Валидация - определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователей Терминология: «верификация» vs. «валидация» 3/3 «Вы создаете продукт правильно ?» «Вы создаете правильный продукт?» Тестирование и качество 1/9 Что такое качество?«Качество – это ценность для индивидуума…»
Дж. Вайнберг (1992)
Тестирование и качество 2/9 Вопрос: Отвечает ли тестировщик за качество?Обсуждение – 3 мин.
Тестирование и качество 3/9 В IT-индустрии широко используется два понятия, которые напрямую связаны с тестированием программных продуктов:- обеспечение качества (QA)
- контроль качества (QC) Зачастую роль тестирования понимается неправильно. Мы, как специалисты по тестированию, не обеспечиваем качество своей деятельностью.
- Тестирование
- Рецензирование кода
- Статический анализ кода
- Внешняя оценка и аудит В обеспечение качества входят :
- Усовершенствование процессов
- Контроль качества
- Управление изменениями
реактивные действия
реактивные и проактивные действия
Тестирование и качество 6/9 Тестирование выполняется для сбора информации. Поэтому тестирование – это лишь один из информационных сервисов.рабочий продукт
информация
Тестирование и качество 7/9 Как тестировщик может повлиять на качество? Тестирование - это возможный способ оценки качества программного обеспечения в терминах найденных дефектов, исполненных тестов и протестированных систем. Это может быть сделано как для функциональных требований, так и для нефункциональных требований и характеристик программного обеспечения. Когда во время тестирования находятся ошибки, качество систем программного обеспечения повышается, если эти дефекты исправлены. Тестирование и качество 8/9 Можно думать о себе, как о гаранте качества, но вы не создаете качество и не можете лишить продукт его. Качество должно закладываться создателями продукта и зачастую для них это становиться неподъемной ношей. Тестировщик призван помочь им решать эту задачу более эффективно. Тестирование и качество 9/9 Любой проект похож на езду по дороге. Проекты бывают легкие и типовые, но большинство напоминают заснеженную горную трассу. В этих проектах не обойтись без света фар. Как тестировщик, вы освещаете дорогу. 7 принципов тестирования Принцип 1 – Тестирование демонстрирует наличие дефектов Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет. Тестирование снижает вероятность наличия дефектов, находящихся в программном обеспечении, но, даже если дефекты не были обнаружены, это не доказывает его корректности. 7 принципов тестирования Принцип 2 – Исчерпывающее тестирование недостижимо Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо, за исключением тривиальных случаев. Вместо исчерпывающего тестирования должны использоваться анализ рисков и расстановка приоритетов, чтобы более точно сфокусировать усилия по тестированию. 7 принципов тестирования Принцип 3 – Раннее тестирование Чтобы найти дефекты как можно раньше, активности по тестированию должны быть начаты как можно раньше в жизненном цикле разработки программного обеспечения или системы, и должны быть сфокусированы на определенных целях. 7 принципов тестирования Принцип 4 – Скопление дефектов Большая часть дефектов, обнаруженных при тестировании или повлекших за собой основное количество сбоев системы, содержится в небольшом количестве модулей. 7 принципов тестирования Принцип 5 – Парадокс пестицида Если одни и те же тесты будут прогоняться много раз, в конечном счете этот набор тестовых сценариев больше не будет находить новых дефектов. Чтобы преодолеть этот “парадокспестицида”, тестовые сценарии должны регулярно пересматриваться и корректироваться, новые тесты должны быть разносторонними, чтобы охватить все компоненты программного обеспечения, или системы, и найти как можно больше дефектов.
7 принципов тестирования Принцип 6 – Тестирование зависит от контекста Тестирование выполняется по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем сайт электронной коммерции. 7 принципов тестирования Принцип 7 – Заблуждение об отсутствии ошибок Обнаружение и исправление дефектов не помогут, если созданная система не подходит пользователю и не удовлетворяет его ожиданиям и потребностям. Вот такие ошибки …- F-16 вверх ногами
- Испытания американского истребителя F-16 проводились, понятное дело, в северном полушарии. На заключительном этапе самолет решили проверить где-то в Латинской Америке, но уже с другой стороны экватора. При переводе самолета в режим автопилота он автоматически развернулся «вверх ногами».
- Правильно выбирайте типы данных
- Причиной взрыва 4 июня 1996 г. ракеты Ариан-5, была программная ошибка. В системе управления ракеты использовалось модифицированное программное обеспечение ранее успешно работавшее на Ариан-4, но Ариан-5 ускорялась быстрее предыдущей модификации, в результате когда на 40 секунде полета одна из вспомогательных подпрограмм попыталась преобразовать длинное целое значение в короткое без проверки величины значения, то вышло за границы типа, произошло отключение системы управления ракеты, и она была взорвана по команде на самоликвидацию. Прямой (вместе с ракетой-носителем был потерян коммуникационный спутник) и косвенный ущерб от этого программного сбоя был оценен в полмиллиарда долларов.
Тестирование – не обособленная процедура. Оно занимает свое место в жизненном цикле, который во многом определяет организацию тестирования.
Модель жизненного цикла разработки Под моделью обычно понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного цикла.- Этапы:
- анализ осуществимости; стратегическое планирование; анализ требований;
- проектирование (предварительное и детальное);
- кодирование (программирование);
- отладка и тестирование; интеграция;
- внедрение; эксплуатация и сопровождение.
- Результат работ на каждом этапе
- Ключевые события (точки принятия решений)
- Затраты/бюджет
- Сроки
- Приемлемое качество продукта Прозрачность
- Статус работ известен в любой момент проекта
- Даже если всё заканчивается хорошо, не знать этого до последнего момента - плохо...
- Реальные трудозатраты и сроки находятся в запланированных (сметных) пределах Управляемость
- Возможность внесения корректив по ходу проекта (изменяющиеся требования и др.) Сдерживание рисков
- Устойчивость к влиянию внешних факторов
- Каскадная модель
- Итеративная или инкрементальная модель
- Спиральная модель
Процесс разработки ПО зависит от выбранной модели разработки.
Каскадная модель Наиболее популярный пример – водопадная модель. Водопадная модель стала одной из первых разработанных моделей. Она предполагает строгое последовательное (во времени) выполнение всех фаз. Проекты, в которых за основу взята данная модель, развиваются путем последовательного перехода от фазы к фазе, от первоначального замысла к конечному продукту. Каскадная (водопадная) модель Каскадная (водопадная) модель Ключевые характеристики- Данная модель требует наличия четко-определенных требований, которые остаются неизменными на протяжении всего проекта.
- Четкое планирование: каждый этап и его составные части планируется и включается в график до начала работ.
- Продукт можно считать завершенным только после окончания последнего этапа.
- Четкое документирование: документируется каждая фаза проекта. Благодаря этому приходящим в проект людям легче включиться в работу
- Простая для понимания и использования
- Приспособлена для разработки ПО высокого архитектурного уровня и сложной структуры
- Невозможность вернуться на предыдущую фазу
- Высокий риск конструктивных дефектов
- Непригодна, если заказчик меняет требования.
- Подходит только для тех проектов, где требования не меняются на протяжении всего цикла разработки
- Нерациональное использование времени: пока проектировщики полностью не закончат работу, разработчики не могут приступить к написанию кода
- Требует много времени и документирования
- Количество тестирования непредсказуемо, велик риск не уложиться в сроки
Цикл «планирование-действие-проверка-корректировка»
Итеративная или инкрементальная модель Ключевые характеристики- Система разрабатывается повторяющимися циклами (итеративная модель). Одновременно разрабатываются лишь небольшие части системы (инкрементальная модель)
- В результате каждой итерации появляется рабочий продукт, являющийся частью конечного разрабатываемого продукта
- Гибкость в принятии новых требований или изменений
- Возможность адаптации процесса на основе уроков, извлеченных из предыдущих итераций
- Более короткие сроки вывода продукта на рынок: возможность получить отзывы от заказчиков/пользователей путем демонстрации рабочих частей системы Недостатки
- Стоимость продукта неизвестна
- Могут возникнуть проблемы с архитектурой системы, поскольку требования для всего жизненного цикла программы не собираются заранее
- Данная модель включает в себя большую часть этапов водопадной модели, и в том же порядке. Однако этапы отделены друг от друга планированием, оценкой рисков, прототипированием и имитацией.
- На каждой итерации по всему циклу продукт является расширением более раннего продукта (как в итеративной модели)
- Расширение модели осуществляется только после анализа рисков: во время каждого цикла проводиться поиск крупных рисков и делаются попытки по их устранению Спиральная модель предназначена для крупных, дорогостоящих и сложных проектов (с высокими проектными рисками)
- Лучший способ разработки систем с большим количеством неизвестных величин
- Одна из наиболее гибких моделей: изменения могут быть внесены позже в жизненном цикле
- Управление рисками – одна из встроенных функций данной модели, что делает ее более привлекательной по сравнению с другими моделями Недостатки
- Стоимость продукта неизвестна
- Чересчур трудный подход для проектов с четкими техническими требованиями к продукту
- каждому этапу разработки соответствует этап тестирования;
- каждый уровень тестирования имеет тестовые цели, характерные для данного уровня;
- анализ и проектирование тестов для данного уровня тестирования должны начинаться во время соответствующего этапа разработки;
- тестировщики должны начинать рецензирование документов, как только их черновые варианты становятся доступны.
- В реальной жизни …
- В реальных проектах …
- В реальных ситуациях …
- Модель в чистом виде используется редко
- Как правило используется адаптация модели под контурные нужны, что и было задумано, например для RUP, Agile и некоторых других моделей разработки
- Разработчики тестируют собственный код (низкий уровень независимости)
- Независимые тестировщики (например, из команды разработчиков)
- Независимая команда или группа тестирования из другой организационной группы или независимые тестировщики (например, специалисты по тестиро- ванию удобства использования и производительности)
- Независимые тестировщики, привлеченные на аутсорсинг или сторонние по отношению к организации.
Команда
Взаимодействие в проектной команде Роль тестировщика 1/6 Тестирование выполняет сервисную функцию. Как тестировщик, вы оказываете услуги по тестированию различным «заказчикам»: Руководитель проекта (PM): Руководитель проекта обязан быть в курсе деятельности тестировщика и влиять на нее. Тестировщик должен, в свою очередь, по запросу извещать PM’а о статусе тестирования, об обнаруженных серьезных проблемах, и не быть «бутылочным горлышком» для проекта. Роль тестировщика 2/6 Программист: Тестировщик облегчает работу программиста, сообщая ему о дефектах в его работе, причем, делая это быстро. О тестировщика требуется понимание своего ремесла и знание продукта, чтобы не тратить время программиста ошибочными или поверхностными отчетами. Роль тестировщика 3/6 Технический писатель: Специалисты, пишущие руководства, получают неполную информацию о продукте. Тестировщик может лучше объяснить им, как работает программа и предостеречь от тех или иных ошибок в документации. Писатели так же могут помочь группам тестирования. Изучая сам продукт и то, как он эксплуатируется, они могут предупредить тестировщиков о новых областях использования продукта, недочетах в тестовом плане и о дефектах, с которыми сталкиваются пользователи. Роль тестировщика 4/6 Техническая поддержка Тестировщики ставят группы поддержки в известность о тех аспектах продукта, которые могут доставить неудобства пользователям. Специалисты из службы поддержи так же помогают тестировщикам, поскольку могут обосновать необходимость исправления дефекта. Роль тестировщика 5/6 Отдел маркетинга: Отдел маркетинга должен знать есть ли в продукте что-либо несоответствующее его ключевым характеристикам, которые должны быть поставлены заказчику. Дефект, который кажется незначительным разработчикам, может оказаться критически важным для маркетинга. Также тестировщик может помочь отделу маркетинга в составлении точного отчета о возможностях продукта. Роль тестировщика 6/6 Пользователь: В сущности, тестировщик работает на пользователей продукта. Их удовлетворение является приоритетной задачей проекта и, конечно же, тестировщика Типы и уровни тестирования Уровень тестирования Уровень тестирования: группа задач по тестирования которые управляются совместно. Уровень тестирования связан с областями ответственности в проекте. Примерами уровней тестирования могут служить- компонентное тестирование,
- интеграционное тестирование,
- системное тестирование
- приёмочное тестирование.
- Цель
- Объекты тестирования
- Прослеживание связи с базисом тестирования (при наличии)
- Критерии входа и выхода
- Артефакты процесса тестирования, которые будет поставлять отдел тестирования - тестовые сценарии, протоколы тестирования, отчетность о результатах и другие
- Тестовые методики
- Измерения и метрики
- Инструментарий
Как правило, такое деление тестовых активностей по уровням делается для комплексных систем (системы систем) – системное тестирование на нижем уровне называется подсистемым
Компонентное тестирование Компонентное тестирование: Тестирование отдельных компонентов программного обеспечения Так же известно, как модульное тестирование Компонентное тестирование: общий обзор- Выполняется самим разработчиком (иногда модульное тестирование доверяется другому разработчику, не автору кода, для повышения уровня независимости)
- Тестирование функциональных и нефункциональных характеристик программы
- Могут быть использованы эмуляторы (заглушки и драйвера)
- Пример кода
- Модульный тест
- Далее эту программу запускаем, таким образом автоматически тестирую код.
- Цель
- Изолировать отдельные части программы и показать, что по отдельности все части работают.
- Объекты тестирования
- Компоненты
- Программы
- Модули БД
- Базис тестирования
- Требования к компонентам
- Детальный дизайн
- Код
- Критерии входа
- Бизнес- и функциональные требования выработаны и утверждены.
- Разработка компонентов закончена.
- Среда разработки стабильна.
- Документация по тестовым сценариям модульных тестов составлена.
- Критерии выхода
- Все тестовые сценарии модульных тестов исполнены. Тестовые результаты доступны.
- Обнаруженные дефекты исправлены и закрыты.
- Проверка кода завершена.
- Все обнаруженные серьезные дефекты закрыты.
- Отчетность
- Как правило, дефекты устраняются по мере обнаружения, без составления отчетов.
- Тестовые методики
- Тестирование операторов
- Тестирование ветвей
- Тестирование условий
- Тестирование путей
- Метрики и измерения
- Покрытие операторов
- Покрытие альтернатив
- Покрытие путей
- Инструментарий
- Инструмент отладки
- Интегрированная среда модульного тестирования
- Junit
- Nunit
- Другие
- Возможность протестировать часть программы, не ожидая готовности остальных частей
- Раннее обнаружение дефектов
- Программисты обнаруживают и мгновенно исправляют проблемы. Упрощенная отладка
- Лучшее структурное покрытие кода
- Модульное тестирование экономичнее других этапов тестирования
- Упрощенная интеграция
- Время от времени требуется реализовывать заглушки и драйвера
- Модульное тестирование основано, в первую очередь, на написанном коде. Поэтому, если что-то было пропущено, модульное тестирование этого не покажет
- Как правило, следует за компонентным тестированием
- Выполняется разработчиками или тестировщиками, специализирующихся на интеграционном тестировании (редкая квалификация)
- Тестирование функциональных и нефункциональных характеристик программы
- Цель
- Удостовериться, что взаимодействие двух или более компонентов дает результат, отвечающий функциональным требованиям
- Обнаружить проблемы интерфейса
- Объекты тестирования
- Подсистемы
- Инфраструктура
- Интерфейсы
- Базис тестирования
- Проект программы и системы
- Архитектура
- Технологический процесс (workflow)
- Сценарии использования
- Критерии входа
- Модули для интеграционного тестирования закончены
- Компонентное тестирование закончено
- Проблемы, обнаруженные в компонентном тестировании, исправлены и закрыты
- Сценарии интеграционного тестирования закончены
- Среда интеграционного тестирования готова
- Критерии выхода
- Дефекты, обнаруженные во время интеграционного тестирования, исправлены и закрыты
- Все тестовые сценарии исполнены; для каждого сценария есть результаты тестирования
- Методы интеграционного тестирования
- «Большой взрыв» (“Big Bang)”
- «Сверху вниз» (“Top down”)
- «Снизу вверх» (“Bottom up”)
- Методы подробно разбираются в тренинге «SQA-028 Основы тест-дизайна»
- Большая стабильность по сравнению с тестированием графического пользовательского интерфейса
- Положительно влияет на внутренний дизайн программы
- Ранняя и более легкая локализация дефектов интерфейса на стадии системного тестирования Недостатки Тестировщик должен читать код, а временами и писать его
- Выполняется тестировщиками
- Тестирование функциональных и нефункциональных характеристик программы
- Системное тестирование является разновидностью тестирования методом черного ящика, а, следовательно, не требует знания внутренней структуры кода или логики
- Включает тестирование взаимодействия с операционной системой и системными ресурсами
- Цель
- Протестировать законченную, интегрированную систему, чтобы оценить ее соответствие указанным требованиям (функциональным/нефункциональным)
- Объекты тестирования
- Система в целом
- Базис тестирования
- Функциональная спецификация (FRS)
- Спецификация системных требований к ПО (SRS)
- Сценарии использования
- Отчеты об анализе степени риска
- Критерии входа
- Модульное и интеграционное тестирование всех модулей закончено.
- Окружение для системного тестирования готово.
- Спецификации продукта закончены и утверждены.
- Сценарии системного тестирования отражены в документах.
- Пользовательский интерфейс и тестируемый функционал заморожены.
- Критерии выхода
- Программа отвечает всем требованиям и обладает требуемым функционалом.
- Дефекты, обнаруженные во время системного тестирования, исправлены и закрыты.
- Все сценарии системного тестирования исполнены, а результаты доступны.
- Техники тест-дизайна
- Эквивалентное разбиение
- Анализ граничных значений
- Тестирование таблицы решений
- Тестирование всех пар (pairwise)
- Тестирование состояний и переходов
- Тестирование по сценариям использования
- Измерения и метрики
- Покрытие требований
- Покрытие классов эквивалентности
- Покрытие граничных значений
- Отчетность
- Данные по обнаруженным дефектам, как правило, заносятся в отчет и в систему управления дефектами
- Инструментарий
- Тестовые компараторы
- Инструменты захвата/воспроизведения
- Инструменты тестирования защищенности
- Инструменты тестирования производительности
- …
- Выполняется заказчиком или пользователем системы
- Поиск дефектов не является главной целью
- Пользовательское приемочное тестирование проверяет готовность системы для использования; Эксплуатационное тестирование проверяет насколько система пригода для эксплуатации в конкретном операционном окружении
- Альфа тестирования выполняется в стенах компании, которая разрабатывает программный продукт. Бета тестирования выполняется заказчиком/пользователем на его оборудовании
- С исполнением и без исполнения кода: статическое / динамическое
- Различные знания о структуре кода: черный ящик / серый ящик / белый ящик
- По свойствам тестируемого объекта: функциональность, производительность, совместимость, надежность, удобство…
- По изменениям: регрессионное тестирование, подтверждающее тестирование
- По типу прогона тестов: ручное и автоматическое
- Код
- Документация с требованиями
- Сценарии использования
- Руководства .. и прочая проектная документация
- раннее обнаружение и исправление дефектов
- улучшение продуктивности разработки
- уменьшение времени разработки
- уменьшение времени и стоимости тестирования
- сокращение стоимости жизненного цикла
- уменьшение числа дефектов и улучшение коммуникаций
- могут быть найдены упущения в требованиях
- Модуль
- Интерфейс
- Система
- Например, продукт тестируется методом черного ящика, но тестовые сценарии разрабатываются с разрабатываются с учетом знаний о внутренней структуре продукта.
- тестирование на основе структуры
- структурное тестирование
- тестирование прозрачного ящика
- тестирование методом прозрачного ящика –
- Функциональное тестирование
- Тестирование установки (инсталляции)
- Тестирование графического пользовательского интерфейса
- Нефункциональное тестирование
- Тестирование производительности, нагрузочное тестирование, стрессовое тестирование
- Тестирование обеспеченности технической поддержкой
- Тестирование локализуемости
- Тестирование практичности
- Тестирование защищенности
- …
- Тестирование настройки и лицензирования
- Тестирование графического пользовательского интерфейса
- …
- пароли
- шифрование
- аппаратные устройства доступа
- уровни доступа к информации
- авторизация
- скрытые каналы
- безопасность на физическом уровне
Тестирование производительности: в инженерии программного обеспечения тестирование, которое проводится с целью определения, как быстро работает система или её часть под определённой нагрузкой. Также может служить для проверки и подтверждения других атрибутов качества системы, таких как масштабируемость, надёжность и потребление ресурсов. http://ru.wikipedia.org/
Тренинг "SQA-033 Основы тестирования производительности"
Нагрузочное тестирование Нагрузочное тестирование: Тип тестирования производительности, проводимый с целью оценки поведения компонента или системы при возрастающей нагрузке, например количестве параллельных пользователей и/или операций, а также определения какую нагрузку может выдержать компонент или система. Стрессовое тестирование Стрессовое тестирование: Вид тестирования производительности, оценивающий систему или компонент на граничных значениях рабочих нагрузок или за их пределами, или же в состоянии ограниченных ресурсов, таких как память или доступ к серверу Тестирование удобства использования Тестирование удобства использования: Тестирование с целью определения степени понятности, легкости в изучении и использовании, привлекательности программного продукта для пользователя при условии использования в заданных условиях эксплуатации. Тестирование по изменениям… Подтверждающее тестирование: Тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок. Регрессионное тестирование: Тестирование уже протестированной программы, проводящееся после модификации для уверенности в том, что процесс модификации не внес или не активизировал ошибки в областях, не подвергавшихся изменениям. Проводится после изменений в коде программного продукта или его окружении По типу прогона тестов.. Ручное тестирование: Процесс ручного тестирования продукта. Тестировщик играет роль конечного пользователя, используя максимальное количество функций программы, чтобы удостовериться в их корректной работе. Автоматизированное тестирование: Использование программного обеспечения (помимо тестируемого ПО) для контроля выполнения тестов, сравнения полученных результатов с эталонными, установки предусловий тестов и других функций контроля тестирования и организации отчетов. Дефекты Дефекты – основная продукция тестировщиков Отчет о дефекте – основной продукт работы большинства тестировщиков. Хорошими отчетами тестировщик зарабатывает себе хорошую репутацию. Плохие отчеты, написанные в критикующей манере и недостаточно обоснованные, создают дополнительную работу для программистов, тратят их время и формируют негативное впечатление от работы тестировщика. Отчет о дефекте Отчет о дефекте: Документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. Инструмент управления дефектами Система управления дефектами: Инструмент, обеспечивающий фиксирование дефектов и изменений, а также поддержку их состояний. Часто имеет процессно-ориентированные возможности для поддержки и контроля распределения, исправления и повторной проверки дефектов, а также возможности отчетностиТренинг "SQA-024 Основы управление дефектами"
Жизненный цикл отчета об ошибке Термин «ЖЦ отчета об ошибке» относится к различным стадиям, которые дефект проходит в инструменте управления дефектами за время своего жизненного цикла. В большинстве проектных команд установлены правила о том, кто может менять статус дефекта или назначать его кому-либо. Например, только руководитель проекта может принять решение отсрочить исправление дефекта или же только тестировщик имеет разрешение на закрытие дефекта. Пример ЖЦ дефекта 1/3 Пример ЖЦ дефекта 2/3 После сообщения о дефекте, отчет изучается коллегой тестировщика, сообщившего о нем, или руководителем тестирования. Если при рецензировании дефект подтвердиться, открывается отчет о дефекте, и проектная команда должна принять решение, исправлять дефект или нет. В случае, если дефект подлежит исправлению, назначается программист для решения задачи. Как только программист исправит дефект, отчет о нем возвращается тестировщику на подтверждающее тестирование. Если исправления не будут подтверждены результатами тестирования дефект будет переоткрыт и переназначен. Пример ЖЦ дефекта 3/3 После подтверждения тестировщика об устранении дефекта, отчет о нем закрывается. Работы по нему заканчиваются. Любой статус помимо «отклонен», «отложен» или «закрыт» требует работ по устранению дефекта до окончания проекта. У отчета о дефекте в таком статусе есть владелец, ответственный за переход инцидента в следующий статус. Стрелками на схеме показаны допустимые направления таких переходов. Отчет о дефекте 1/6 Идентификатор. Уникальный ID, присваиваемый отчету о дефекте, который может быть использован при его поиске и упоминании о нем. Краткое описание. Краткое описание дефекта. Подробное описание. Детальное описание дефекта. Влияние. Критичность и серьйозность дефекта. IEEE 829 Standard for Software Test Documentation Отчет о дефекте 2/6 Краткое описание – очень важное поле, на которое будут обращать внимание руководитель проекта и прочие руководители, и исполнители, изучая список дефектов, которые не были или не будут устранены. Должно включать в себя:- краткое, но конкретное описание, которое даст читателю представление о характере проблемы
- краткое описание границ и зависимостей дефекта (насколько узки или широки обстоятельства, обуславливающие данный дефект?)
- краткое описание влияния или последствий данного дефекта
- Время и дата
- Имя тестировщика
- Аппаратные и программные конфигурации
- Входные данные
- Шаги процедуры
- Ожидаемые результаты
- Фактические результаты
- Попытки воспроизвести дефект, описание испытанных средств
- Прочие наблюдения и информация, которые могут помочь программисту обнаружить дефект
- Критичность. Важность воздействия конкретного дефекта на систему.
- Приоритет. В какой мере дефект в данном месте системы влияет на ценность продукта в глазах заказчиков и пользователей,
- Полный отказ системы, потеря данных, повреждение данных, бреши в защите
- Операционная ошибка, неверный результат, потеря функциональности
- Небольшие проблемы, орфографические ошибки, разметка пользовательского интерфейса, редкие случаи
- Предложения по улучшению Обычно критичность не меняется до тех пор, пока не вскрываются скрытые последствия дефекта.
- Требует немедленного устранения, делает невозможным дальнейшее тестирование, явный дефект
- Должен быть устранен до релиза
- Устранить, когда будет время
- Желательно устранить, но не препятствует релизу продукта По мере развития проекта приоритеты могут меняться
- Комментарии: Несоответствующие/некорректные/дезориентирующие или пропущенные комментарии в исходном коде
- Ошибка в вычислениях: Неправильный расчет по формуле/ неправильная бизнес валидация в коде
- Ошибка данных: Некорректная совокупность данных/обновление БД
- Ошибка базы данных: Ошибка в схеме/структуре БД
- Упущения при проектировании: Проектные данные/методы проектирования упущены/не отражены в документации и не отвечают требованиям
- Некорректное или условно-оптимальное проектирование: Проектные данные/методы проектирования требуют корректировки для того, чтобы считаться полными. Описанные конструктивные особенности не являются оптимальными для требуемого решения
- Неправильное проектирование: Неправильное или неточное проектирование
- Нечеткое проектирование: Проектные данные/методы проектирования не ясны для рецензента. Слова допускают двоякое толкование, проектные данные нечетки
- Граничные условия не учтены: Граничные условия некорректны/не учтены
- Ошибка интерфейса: Внутренние или внешние по отношению к приложению ошибки интерфейса, некорректная обработка переданных параметров, неправильное расположение полей и объектов, неудобное положение окна/ экрана
- Логическая ошибка: Отсутствующая, недостаточная, неактуальная или неоднозначная функциональность в исходном коде
- Ошибки в сообщениях: Несоответствующие/некорректные/ошибочные или отсутствующие сообщения об ошибках в исходном коде
- Ошибка навигации между объектами: Навигация неправильно воплощена в исходном коде
- Ошибка производительности: Ошибка, связанная с производительностью/ оптимальностью кода
- Пропущенные требования: Неявные/явные требования были пропущены/не отражены в документах на стадии сбора требований
- Неполноценные требования: Требования нуждаются в расширении для того, чтобы быть полными
- Некорректные требования: Ошибочные или неточные требования
- Нечеткие требования: Требования не ясны рецензенту. Используются слова, допускающие двоякое толкование (например, вроде, возможно, может быть и т.д.)
- Ошибка настроек времени/очередности: Ошибка, вызванная неверными/отсутствующими расчетами времени ожидания и очередности
- Стандарты: Не соблюдаются стандарты, например, стандарты по проектированию/сбору требований/кодированию, имеющие отношение к проекту
- Системная ошибка: Аппаратные ошибки и ошибки ОС, потеря доступа к памяти, системный сбой
- Ошибка тестового плана/сценария: Неполноценные/неверные/нечеткие/дублирующие или пропущенные тестовые планы/сценарии, неполная/неверная конфигурация тестов
- Типографическая ошибка: Орфографические/грамматические ошибки в документации/исходном коде
- Ошибка объявления переменных: Неверная декларация / использование переменных, ошибка несоответствия типов в исходном коде
- 5 мин на размышления
- 10 мин на разбор
- Использование программных систем
- Знание предметной области или бизнеса
- Участие в различных этапах разработки ПО, включая анализ, разработку и техническую поддержку
- Участие в тестировании ПО
- “Lessons Learned in Software Testing” by Cem Kaner, James Bach and Bret Pettichord
- “Foundations of Software Testing” by Dorothy Graham, Erik van Veenendaal, Isabel Evans, Rex Black
- “Software testing” by Ron Patton
- “Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах” Роман Савин
- “How to Break Software: A Practical Guide to Testing” James A. Whittaker
Информатика - еще материалы к урокам:
- Презентация "Программирование на языке Паскаль. Часть II. Массивы"
- Презентация "Основы алгоритмизации и программирования на языках высокого уровня"
- Презентация "Тестирование документации и требований"
- Презентация "Среда проектирования Visual Basic"
- Презентация "Объектно-ориентированное программирование"
- Презентация "Рекурсивные алгоритмы"