Введение в тестирование по содержание
 Скачать 3.94 Mb.
|
Функциональное тестированиеФункциональное тестирование: Тестирование, основанное на анализе спецификации функциональности компонента или системы.Функциональное тестирование включает в себя:
Тестирование графического пользовательского интерфейса Тестирование установки и лицензированияТестирование установки: Вид тестирования, ориентированный на то, что требуется пользователям для успешной установки, настройки и регистрации программного продукта. Процесс тестирования может включать полный и частичный процесс установки/удаления, а так же обновления программы Тестирование целостности данных: Вид тестирования, главной целью которого является проверка целостности данных после различных транзакций (ввод/выбор/обновление). Как правило, целостность данных проверяется в тестированиях методом белого и черного ящикаТестирование защищенностиТестирование защищенности: Тестирование с целью оценить защищенность программного продуктаОбъекты тестирования:пароли шифрование аппаратные устройства доступа уровни доступа к информации авторизация скрытые каналы безопасность на физическом уровне Тестирование графического пользовательского интерфейсаТестирование графического пользовательского интерфейса: Тестирование графического пользовательского интерфейса продукта с целью удостовериться в том, что он отвечает спецификациямНефункциональное тестированиеНефункциональное тестирование: Тестирование атрибутов компонента или системы, не относящихся к функциональности, то есть надежность, эффективность, практичность, сопровождаемость и переносимость.Тестирование производительностиТестирование производительности: Процесс тестирования с целью определить производительность программного продуктаТестирование производительности: в инженерии программного обеспечения тестирование, которое проводится с целью определения, как быстро работает система или её часть под определённой нагрузкой. Также может служить для проверки и подтверждения других атрибутов качества системы, таких как масштабируемость, надёжность и потребление ресурсов. 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Краткое описание – очень важное поле, на которое будут обращать внимание руководитель проекта и прочие руководители, и исполнители, изучая список дефектов, которые не были или не будут устранены. Должно включать в себя:
краткое описание влияния или последствий данного дефекта Отчет о дефекте 3/6Описание инцидента может содержать следующую информацию:Время и дата Имя тестировщика Аппаратные и программные конфигурации Входные данные Шаги процедуры Ожидаемые результаты Фактические результаты Попытки воспроизвести дефект, описание испытанных средств Прочие наблюдения и информация, которые могут помочь программисту обнаружить дефект Отчет о дефекте 4/6Влияние касается приоритета и критичности дефектаКритичность. Важность воздействия конкретного дефекта на систему. Приоритет. В какой мере дефект в данном месте системы влияет на ценность продукта в глазах заказчиков и пользователей, Отчет о дефекте 5/6Уровни критичности:Полный отказ системы, потеря данных, повреждение данных, бреши в защите Операционная ошибка, неверный результат, потеря функциональности Небольшие проблемы, орфографические ошибки, разметка пользовательского интерфейса, редкие случаи Предложения по улучшению Обычно критичность не меняется до тех пор, пока не вскрываются скрытые последствия дефекта.Отчет о дефекте 6/6Приоритеты:Требует немедленного устранения, делает невозможным дальнейшее тестирование, явный дефект Должен быть устранен до релиза Устранить, когда будет время Желательно устранить, но не препятствует релизу продукта По мере развития проекта приоритеты могут менятьсяКлассификация дефектов 1/6Комментарии: Несоответствующие/некорректные/дезориентирующие или пропущенные комментарии в исходном коде Ошибка в вычислениях: Неправильный расчет по формуле/ неправильная бизнес валидация в коде Ошибка данных: Некорректная совокупность данных/обновление БД Ошибка базы данных: Ошибка в схеме/структуре БД Упущения при проектировании: Проектные данные/методы проектирования упущены/не отражены в документации и не отвечают требованиям Классификация дефектов 2/6Некорректное или условно-оптимальное проектирование: Проектные данные/методы проектирования требуют корректировки для того, чтобы считаться полными. Описанные конструктивные особенности не являются оптимальными для требуемого решения Неправильное проектирование: Неправильное или неточное проектирование Нечеткое проектирование: Проектные данные/методы проектирования не ясны для рецензента. Слова допускают двоякое толкование, проектные данные нечетки Граничные условия не учтены: Граничные условия некорректны/не учтены Классификация дефектов 3/6Ошибка интерфейса: Внутренние или внешние по отношению к приложению ошибки интерфейса, некорректная обработка переданных параметров, неправильное расположение полей и объектов, неудобное положение окна/ экрана Логическая ошибка: Отсутствующая, недостаточная, неактуальная или неоднозначная функциональность в исходном коде Ошибки в сообщениях: Несоответствующие/некорректные/ошибочные или отсутствующие сообщения об ошибках в исходном коде Ошибка навигации между объектами: Навигация неправильно воплощена в исходном коде Классификация дефектов 4/6Ошибка производительности: Ошибка, связанная с производительностью/ оптимальностью кода Пропущенные требования: Неявные/явные требования были пропущены/не отражены в документах на стадии сбора требований Неполноценные требования: Требования нуждаются в расширении для того, чтобы быть полными Некорректные требования: Ошибочные или неточные требования Классификация требований 5/6Нечеткие требования: Требования не ясны рецензенту. Используются слова, допускающие двоякое толкование (например, вроде, возможно, может быть и т.д.) Ошибка настроек времени/очередности: Ошибка, вызванная неверными/отсутствующими расчетами времени ожидания и очередности Стандарты: Не соблюдаются стандарты, например, стандарты по проектированию/сбору требований/кодированию, имеющие отношение к проекту Классификация требований 6/6Системная ошибка: Аппаратные ошибки и ошибки ОС, потеря доступа к памяти, системный сбой Ошибка тестового плана/сценария: Неполноценные/неверные/нечеткие/дублирующие или пропущенные тестовые планы/сценарии, неполная/неверная конфигурация тестов Типографическая ошибка: Орфографические/грамматические ошибки в документации/исходном коде Ошибка объявления переменных: Неверная декларация / использование переменных, ошибка несоответствия типов в исходном коде В реальности далеко не все найденные дефекты устраняются. Некоторые не устраняются вовсе, исправление же некоторых откладывается до следующего релиза.Причина 1 – Нехватка времени. В любом проекте приходится иметь дело с огромным количеством программных свойств. Людей, которые эти свойства могли бы записать в код и протестировать, как правило не хватает, не говоря уже о времени для завершения работ. Причина 2 – Дефект вовсе не дефект. Может, вам доводилось слышать фразу: «Это не дефект, а такое свойство!». Это часто приводит к непониманиям, ошибкам в тестах или изменениям в спецификации, поскольку потенциальные дефекты рассматриваются как свойства системы. Причина 3 – Устранять неисправность слишком рискованно. К сожалению, это случается очень часто. ПО – хрупкая и взаимосвязанная система. Устранение одной неисправности может привести к появлению других. Менять что-либо в программе незадолго до выпуска релиза может быть очень рискованной затеей. Лучше оставить в программе известный дефект, чтобы избежать риска появления новых, неизвестных. Причина 4 – Это того не стоит. Дефекты, которые будут проявляться очень редко или в малоиспользуемых функциях, могут быть оставлены без изменений. Дефекты, которые можно обойти или предотвратить, так же часто не устраняются. Все сводится к оценке рисков. Причина 5 – Неэффективный отчет о дефектах. Тестировщик недостаточно обосновал необходимость устранения определенного дефекта. В результате, дефект не был воспринят как таковой, был воспринят как не препятствующий выпуску продукта, как слишком рискованный для устранения или просто как не стоящий усилий по устранению.УпражнениеПредставьте, что вы тестируете калькулятор Windows, который выдает: 1+1=2, 2+2=5, 3+3=6, 4+4=9, 5+5=10 и 6+6=13. Напишите отчет о дефекте, который бы эффективно описывал проблему.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 |