Содержание
-
Тестированиепрограммногообеспечения
-
Содержание
1 2 3 Основные понятия тестирования Выполнение QA цикла Анализ и предоставление результатов
-
Цель тренинга
Процесс тестирования в рамках разработки программного обеспечения (ПО) Уровни, виды и методы тестирования Тестовые артефакты
-
Почему важен процесс тестирования?
Процесс разработки ПО невозможен без контроля качества разрабатываемого продукта
-
Почему так важен процесс тестирования?
Тестирование программного обеспечения – это процесс, который осуществляется специально подготовленными QC/QA инженерами. Результат работы тест команды – оттестированный программный продукт, не имеющий дефектов, ошибок и полностью соответствующий спецификации.
-
В чём смысл работы тестировщика?
Тестировщик умет профессионально сломать программу Знает спецификацию и требования к продукту, использует его функции с точки зрения пользователя Качество и надежность программного продукта повышается с каждым найденным/исправленным дефектом! 6
-
Определениетестирования
Тестирование - процесс исследования ПО с целью получения информации о качестве продукта. Тестирование ПО - Процесс проверки соответствия заявленных к продукту требований и реально реализованной функциональности, осуществляемый путем наблюдения за его работой в искусственно созданных ситуациях и на ограниченном наборе тестов, выбранных определенным образом.
-
Тестирование - это процесс, который требуетанализа, планирования и тщательной подготовки. В идеальном мире тестирование должно начинаться с момента появления «Идеи» создания нового программного продукта.
-
Даже после окончания тестирования продукт может содержать дефекты Безошибочных программ не существует Доводить программу до идеального состояния очень трудозатратно Все участники процесса разработки должны это осознавать и находить компромисс
-
Целитестирования
Передать заказчику готовый функциональный и стабильный продукт. Обнаружить ошибки до того, как это сделает заказчик
-
Рольтестирования в системеконтроля качества
Quality control (QC)–это процесс проверки качества каждой сущности и всех факторов, влияющих на процесс разработки.
-
Quality assurance (QA)–это ряд мероприятий, направленных на то, что все процессы и требования к качеству разрабатываемого продукта выполняются в полной мере. 12
-
Самостоятельность тестирования
Подпроект в рамках проекта Команда разработчиков отвечает только за модульное тестирование Тест Менеджер управляет бюджетом и всеми действиями связанными с тестированием Тест Менеджер несет ответственность за оценку рисков и приоритетов в тестировании
-
МП одобряет подход к тестированию и бюджет Критерии завершения тестирования определяются до начала тестирования Основой для тестирования являются требования пользователя, а не спецификации 14
-
Плюсы независимости тестирования Бюджет тестирования ведется и отслеживается отдельно, ресурсы на тестирование не выделяются по остаточному принципу
-
Участники проектной команды
Заказчик Менеджер проекта Системный архитектор Тест менеджер Team Leaders Разработчики Тестировщики Бизнес аналитики Технический писатель документации
-
Рольгруппытестирования
Роль тестирования состоит в получении объективной информации о качестве продукта.
-
Тестирование, требования, качество
Качествообъекта– этосовокупностьхарактеристикобъекта, относящуюся к егоспособностиудовлетворитьустановленныеилипредполагаемыетребования(ИСО 9000/2000)
-
Разработка ПО
Процесс разработки ПО – структура, согласно которой построена разработка программного обеспечения Существует несколько моделей такого процесса, каждая из которых описывает свой подход, в виде задач и/или деятельности, которые имеют место в ходе процесса. 19
-
20
-
Жизненный цикл проекта: Инициация; Планирование; Выполнение; Контроль и мониторинг; Завершение. 21
-
Стадии процесса: Анализ; Проектирование; Программирование; Документирование; Тестирование; Сопровождение. 22
-
Анализ Процесс сбора требований к ПО, их систематизация, документирование, анализ, выявление противоречий и разрешение конфликтов в процессе разработки ПО 23
-
Проектирование Процесс создания ПО; Определение внутренних свойств системы и детализация ее внешних свойств а основе требований к ПО. Нотации – схематическое выражение характеристик: Блок-схемы; ER-диаграммы; UML-диаграммы; Макеты. 24
-
Программирование – процесс создания программ Разработка комплекса алгоритмов; Написание исходного кода; Преобразование в машинный код (компиляция); Тестирование и отладка; 25
-
Документация Печатные руководства пользователя, диалоговая документация и справочный текст, описывающий функции и алгоритм использования ПО Виды: Архитектурная/Проектная; Техническая; Пользовательская; Маркетинговая 26
-
Тестирование …. …. …. 27
-
Сопровождение Сбор и анализ информации от пользователей; Создание отчетов об ошибках; Требования по выпуску исправлений (hot-fixes, updates, service packs etc) 28
-
Модели разработки
Виды моделей: Водопадная (Каскадная); V-модель; Спиральная; Итеративная. 29
-
Водопадная (Каскадная) Последовательность фаз, переходящих от одной к другой; Переход к следующей – только после полного завершения предыдущей 30
-
V-модель Дальнейшее развитие водопадной модели Разработка и тестирование идут одновременно; Цели: Минимизация рисков; Повышение качества; Уменьшение стоимости проекта; Коммуникация 31
-
32
-
33
-
Недостатки V-модели: Не предусматривает работу с параллельными событиями; Не предусмотрено внесение динамических изменения в требования; Тестирование в жизненном цикле происходит слишком поздно; Нет анализа рисков; Недостаточная визуализация результатов работы (только в Coding) 34
-
Итеративная Выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы Планирование-Реализация-Проверка-Оценка (plan-do-check-act) 35
-
36
-
Преимущества итеративного подхода: Снижение воздействия серьёзных рисков на ранних стадиях проекта; Организация эффективной обратной связи проектной команды с потребителем Акцент усилий на наиболее важные и критичные направления проекта; Непрерывное итеративное тестирование; Раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта; Более равномерная загрузка участников проекта; Реальная оценка текущего состояния проекта Затраты распределяются по всему проекту, а не группируются в его конце 37
-
Тестирование, требования, качество
Требование -- этопотребностьилиожидание, которое (а) установлено в явномвиде, или (б) «наследуется» какобязательноеиздругихсистемтребований (напр., государственных и ведомственныхзаконоположений), или (в) подразумевается (является «обычным») Примеры: (а) требованиеоговорено в контракте, SOW или SRS (б) требованиеоформлениядокументации в ЕСПД (в) функцияпечати в системеобработкифайловдокументов 38
-
Определение
Требование – Функциональная характеристика системы, необходимая заказчику (пользователю) для того чтобы решить проблему или достигнуть поставленных целей. Функциональная характеристика, которой должна обладать система для того чтобы соответствовать контракту, стандарту спецификации или другому формальному документу. Документ, описывающий функциональные характеристики обозначенные выше. 39
-
Выявление требований
Работа ведется с заказчиком системы и её будущими пользователями Цель этапа – точно определить функции продукта и способы его интеграции в существующие процессы 40
-
Первоочередная задача аналитиков - разработать систему требований и донести ее до проектной команды таким образом, чтобы реализованный по этой системе требований продукт соответствовал тому, что нужно Заказчику и система, действительно, вписывалась в бизнес Заказчика и была ему полезна.
-
Виды документов
Vision Document; Requirements Definition Document; System Requirements Specification; User Requirement Document; Functional Requirement Document; Техническое задание; Технический проект. 42
-
Типытребований
Бизнес требования Цели и задачи компании; Требования пользователей Потребности отдельных групп заказчиков/пользователей; Функциональные требования Описывают что должна делать система; Нефункциональные требования Описывают как должна работать система; Предположения и ограничения Специфика доменной области, которая накладывает ограничения на поведение или дизайн системы. 43
-
Кто должен тестировать требования
Для эффективного тестирования важно вовлекать различных специалистов За качество ответственна вся команда Тестировщики Аналитики Менеджер проекта Разработчики 44
-
Методы тестирования требований
Проверка документации; Анализ поведения системы; Прототипирование; 45
-
Проверка документации
Последовательный просмотр и проверка всех доступных требований; Позволяет проверить на корректность, полноту, прослеживаемость, важность, однозначность и измеримость Применяется Заказчиками; Аналитиками; ПМами; Тестировщиками. 46
-
Плюсы Простота использования; Отсутствие специальных требований к проверяющему; Покрывает много критериев качества; Меньше затраты времени. Минусы Качество проверки зависит от проверяющего; Вовлечение различных специалистов; Наличие документов с требованиями 47
-
Анализ поведения системы
Формирование требований в формате «вход-выход», «событие-последствие», «условие-ответ». Позволяет проверить на полноту, понятность, однозначность Применяется Тестировщиками (test cases); Аналитиками (use cases). 48
-
Плюсы Хорошо проверяет требования; Представляет требования в структурированном и понятном виде; Результаты легко использовать для создание тест кейсов. Минусы Требует большего количества времени; Требует специальной подготовки. 49
-
Прототипирование
Создание модели будущей системы. Позволяет проверить на полноту, корректность, реализуемость Применяется Архитекторами; Аналитиками. 50
-
Плюсы Пользователи получают возможность проверить решение; Наглядное пособие для разработчиков и тестировщиков; Проверка требования на реализуемость. Минусы Требует значительного времени; Специальная подготовка для создания прототипа. 51
-
Критерии качества требований
Корректность (Правильность) Каждое требование должно точно описывать то, что должно быть разработано. 52
-
Полнота Все требования задокументированы; Каждое требование содержит всю информацию для проектирования, разработки и тестирования; Нет ссылок не несуществующие данные (таблицы, иллюстрации, документы); 53
-
Однозначность Одинаковая интерпретация требования всеми участниками команды; Требование описано четко, просто, кратко; Все термины и аббревиатуры описаны и определены. 54
-
Непротиворечивость Требование не конфликтует с другими требованиями; Требование не конфликтует с под-требованиями; Требование не конфликтует с законами, стандартами. 55
-
Прослеживаемость Каждое требование должно иметь свой уникальный идентификатор; Система идентификации позволяет добавлять, удалять и разбивать требования без изменения идентификатора других требований 56
-
Реализуемость Каждое из требований возможно реализовать с учетом технических и организационных ограничений; Учитываются доступные ресурсы и время. 57
-
Тестируемость Требование должно быть сформулировано так, чтобы можно было доказать соответствие системы предьявленномутребованию; Требование не должно содержать неизмеримых или нетестируемых формулировок. 58
-
Классификациитестирования
Исполняетсяилинеисполняетсяпрограммныйкод статическоеvsдинамическое Используетсяилинетзнание о способереализации Чёрныйящик (black box) vsпрозрачныйящик(white box) По «уровню» unit, integration, subsystem, system, beta, acceptance По природеобъектатестирования/приложения mainframe, client-server, ОO, Web, real-time, scientific, E-business…
-
По способуразработкитестов методытест-проектирования: нисходящее, восходящее По свойствамобъектатестирования функциональность, производительность, совместимость, надёжность, удобство, ... По месту в циклетестирования Регрессионноетестирование, системноетестирование По способуреализации Ручное и автоматизированное 60
-
Стратегиипрозрачного и черногоящика
«Чёрныйящик» -- «прозрачныйящик» другаятерминология: “black box” -- opaque box; функциональноетестирование, хотяэтосужаетпонятие glass = transparent, white, box; structural testing Двесоответствующихгруппыметодовпроектированиятестов specification-based code-based
-
Типичныерискикода(white box testing)
Использованиерекурсии - невсекомпиляторы и невовсехслучаяхспособныправильноотрабатыватьрекурсию. Увеличениестепенивложенностипроцедур (функций)снижаетпроизводительность. Отсутствиесоглашения о именахстимулируетпоявлениедублей и непонятныхимен, чтотормозитразвитиепроекта. Использованиеуказателей.
-
Нецелевоеиспользованиепеременных и идентификаторов. Сюдапопадают и ошибкисвязанные с операциямичтения и записифайловдоихоткрытияилипослезакрытия. Это и присвоение в переменныхдоихинициализации. Это и наличиелишнихпеременных. Нецелевоеиспользованиеблоковданных. Подэтукатегориюпопадаютошибкисвязанные с распределениемпамяти, например, невозвращениеблоковпамятипослеихиспользования. 63 Присутствиеучастковкода,неисполнявшихся в теченииопределенноговремени. Такжепотенциальнаяошибка, таккакневыполненныйкодможетсодержатьошибки.
-
Уровнитестирования
модуль модуль готовый модуль компонент подсистема система Автономное тестирование Приемка готовых модулей Интеграционноетестирование Тестирование подсистем Системное тестирование
-
Типы тестирования в цикле разработки ПО
65
-
Ролипоуровнямтестирования
Автономноетестированиемодулей -- unit testing программист -- разработчикмодуля Интеграционное, «сборочное» тестирование -- integration testing разработчики и в некоторыхслучаяхтестировщики Тестированиеподсистем -- subsystem testing тестировщики
-
Системноетестирование -- system testing тестировщики Интеграционноесистемноетестирование – system integration testing тестировщики Приемочноетестирование -- acceptance testing заказчик с участием МП и тестировщиков 67
-
База тестирования
Требования к программномупродукту = базасистемного (и подсистемного) тестированияквалификационныйтиптестирования Надругихуровняхтестированиябазойобычноявляютсяпроектныеспецификациикомпонентноетестирование
-
Характеристикауровнейкомпонентноготестирования
Модульное тестирование Тестирование программы на уровне отдельно взятых модулей, функций или классов. Проводится разработчиками после того, как завершена разработка кода модулей/блоков. Цель модульного тестирования состоит в выявлении локализованных в модуле ошибок в реализации алгоритмов, а также в определении степени готовности системы к переходу на следующий уровень разработки и тестирования. Модульное тестирование проводится по принципу «белого ящика»
-
70 Интеграционноетестирование Тестированиечастисистемы, состоящейиздвух и болеемодулей. Цельинтеграционноготестирования - поискдефектов, связанных с ошибками в реализации и интерпретацииинтерфейсноговзаимодействиямеждумодулями. Интеграционноетестированиеоперируетинтерфейсамимодулей и подсистем и требуетсозданиятестовогоокружения, включаязаглушки (Stub) наместеотсутствующихмодулей. Комбинацияметодовпрозрачного и черногоящиков.
-
Характеристикауровнейквалификационноготестирования
Подсистемноетестирование Тестированиеотдельныхфункциональныхилиархитектурныхчастейотносительносоответствующегообъематребований Возможноиспользованиетест-драйверов. Возможнорегрессионноетестирование. Чёрныйящик.
-
Системноетестирование Системноетестированиерассматриваеттестируемуюсистему в целом и оперируетнауровнепользовательскихинтерфейсов Цельсистемноготестирования в выявлениидефектов, связанных с работойсистемы в целом, такихкакневерноеиспользованиересурсовсистемы, непредусмотренныекомбинацииданныхпользовательскогоуровня, несовместимость с окружением, непредусмотренныесценариииспользования, отсутствующаяилиневернаяфункциональность, неудобство в применении и томуподобное. 72 Черныйящик Регрессионноетестирование Разработкановойфункциональностизаморожена
-
Приемо-сдаточныеиспытания Тестированиенаплощадкезаказчика (формальноеилибета) Тестированиеотносительноожиданийзаказчика (валидация) 73
-
Сопровождение Тестированиесистемы в ходеэксплуатациидляизмеренияпараметровкачества, в томчислепроизводительности, использованиясистемныхресурсов, а такжедляопределениякорректирующихдействий. Тестированиеизменений Регрессионноетестирование 74
-
Анатомиятестирования
75 Error (ошибка) - несоответствие между вычисляемым, наблюдаемым, или измеренным значением или состоянием и ожидаемым теоретически правильным значением или состоянием. Failure (отказ, сбой) - неспособность системы или компонента системы выполнять требуемые функции при заданных требованиях к производительности. Bug - ошибка в программе, которая заставляет программу выполнять непреднамеренные или непредвиденные действия. Fault (неисправность) – неверный шаг, процесс или данные, которые влекут за собой непреднамеренные или непредвиденные действия в программе. Defect(дефект) – проблема внешнего вида программного продукта, поведения, несоответствующего спецификации, отсутствие ожидаемого функционала.
-
цикл тестирования develop product test failures? better product fix test failures? product раундтестирования/ исправлениядефектов Failure -- расхождение с ожидаемымрезультатом, отказ Fix/debug -- поискизъянов в продукте (причинотказа) и ихисправление fix Exit criteria achieved
-
Как проводится тестирование
-
Работы, выполняемые каждой из ролейв процессе тестирования
Тест-менеджер – выдает задание группе тестирования для проверки версии продукта. Тест-дизайнер – разрабатывает/изменяет(при изменении требований) тест-план и тестовые сценарии, готовит тестовые данные. При необходимости участвует в тестировании. Тестировщик– тестирует версию продукта согласно выданному тест-менеджером заданию и оформляет найденные дефекты. Группа разработки – исправляет выявленные ошибки, отлаживает версию продукта.
-
Варианты тестовых раундов
Обнаружение дефектов (полномасштабное) Тестируется вся функциональность. Цель – найти как можно больше дефектов и подробно их описать. Характерно для первого раунда в цикле системного тестирования Обнаружение дефектов (выборочное) Выполнение отдельных тестов, например, относящихся к критической функциональности или к разработанной новой функциональности 79
-
Smoke test (BATS – Build Acceptance Test Suite) Регрессионное тестирование для проверки работоспособности новой сборки Верификация исправления дефектов Проверка, что дефекты, исправленные разработчиками, действительно устранены (verification testing)
-
Регрессионный (полный) Повторное выполнение всех тестов, включая успешно выполненных ранее. Характерно для заключительного раунда Регрессионный (выборочный) повторное выполнение некоторых тестов, успешно выполненных ранее. На практике каждый раунд тестирования может объединять несколько вариантов. Например, в следующий билд войдут исправленные дефекты. Поэтому тестирование будет включать верификацию исправленных дефектов частичное регрессионное тестирование 81
-
Дефектыпрограммногопродукта
Определения дефекта, вытекающие из определения тестирования: Дефект есть несоответствие между фактическими и требуемыми характеристиками объекта тестирования Дефект есть несоответствие фактического поведения системы разумным ожиданиям пользователя Г. Майерс «Надежность программного обеспечения»
-
Дефектынаблюдаемыеи внутренние
Наблюдаемыйдефект- эторасхождение, неувязкамеждуожидаемым и полученнымрезультатом, неверноеповедениепрограммногопродукта. Отказэтосимптом = внешнеепроявлениевнутреннегоизъяна, наблюдаемоепринекоторыхусловиях Тестеры (и пользователи) наталкиваютсянаотказы/сбои, иначе: наблюдаютсимптомы
-
Внутреннийдефект, илиизъян– этопричинаотказа, то, чтопривелок отказу; как правило, дефектв кодепрограммы, но и: дефект в дизайне. Разработчикинаходят и исправляютвнутренниедефекты (ставятдиагноз и проводят «лечение») Изъянкодаможетнеприводить к отказу, т.е. можетбытьнезамечентестировщиком Одинизъянможетприводить к несколькимотказам в разныхчастяхсистемы
-
Ценадефекта
Чемраньшедефектобнаружен, темдешевлеобходитсяегоисправление
-
Язык рисков – новыйязык тестирования
Тестировщики должны описывать обнаруженные сбои, отказы и прочие дефекты продукта на языке, понятном менеджменту, т.е. в терминах возможных негативных последствий для проекта и продукта: «Если будет сбой в таком-то компоненте (а это вероятно, т.к. мы его не тестируем), то последствия для вас, как менеджера (спонсора), будут следующими …»
-
Тестировщики должны сделать продуктовые риски «прозрачными»; это позволит принимать решения о том, что включается в рамки/объём тестирования, а что нет Менеджер проекта и другие управляющие могут тогда сбалансировать риски и затраты на тестирование Становятся видны тесты, которые решено не делать Тестировщики видят задачу не в том, чтобы «побольше потестировать», а в том, чтобы на основе найденных ошибок представить информацию, достаточную для принятия решения менеджером 87
-
Risk-basedtesting
Риск от наличия ошибки в программе = ущерб * вероятность вероятностьстолкновения с ошибкой
-
Базадефектов
Нельзятерятьниоднойнайденнойошибки Базадефектов - этобазаданных, в которуюзаносятсяобнаруженные в приложениидефекты Зауправлениеперечнемдефектовприложенияобычноотвечаеттест-менеджер
-
Базадефектов. Основноеназначение
Основноеназначениебазыдефектов - слежениезаошибками с цельюисправлениявсехтехошибок, которыемогутбытьисправлены Каждый, ктодолжензнатьобошибке, узнает о нейсразужепослеееобнаружения Ошибканеможетостатьсянеисправленнойиз-затого, что о нейзабыли Ошибканеможетостатьсянеисправленнойиз-заприхотипрограммиста Ошибканеостаетсянеисправленнойиз-заплохоговзаимодействиямеждуменеджерами, разработчиками и тестировщиками
-
Зачем нужно управлятьдефектами
Улучшение качества разрабатываемого продукта – уменьшение количества существенных дефектов в конечном продукте Уменьшение времени цикла разработки Разработчики получают информацию о дефектах в их коде
-
Управление дефектами с помощью какого-либо инструментального средства Единое хранилище дефектов Определены атрибуты дефекта Определен жизненный цикл дефекта Механизмы нотификации членов проектной команды о новых дефектах и изменении состояний существующих дефектов Получение различных срезов информации по проектным дефектам 92
-
Defect tracking tools
ClearQuest(Rational) TestDirector, Quality Center (Mercury) Jira(Atlassian ) Bugzilla (Freeware) AQdevTeam(Automated QA) StarTeam (Borland) QACenter: TrackRecord (CompuWare) SilkCentral Issue Manager (Segue) …
-
Жизненный цикл дефекта
-
Жизненный цикл дефекта
-
ЖЦ дефекта по ролям
-
Роли в процессеуправлениядефектами
Менеджерпроекта Аналитик Тест-менеджер Тестировщик Менеджер группы технических писателей, технические писатели Разработчик (разработчик, аналитик, техническийписатель) Заказчик
-
Права и обязанностипоролям:Менеджерпроекта
Первичная настройка репозитория (роли, код проекта, и т.п) Назначение исполнителей дефектов, отслеживание выполнения, переназначение Контроль за отложенными дефектами Предварительный анализ дефекта (отклонение, планирование работ по фазам, дупликация) – вместе с разработчиками Определение процесса в рамках которого родился дефект – с участием архитектора, аналитика, ТМ
-
Права и обязанностипоролям:Аналитик
Анализ дефектов Поиск и определение возможных причин дефектов на уровне требований Исправление дефектов в требованиях
-
Права и обязанностипоролям:Тест-Менеджерпроекта
Настройка репозитория Система уведомления Настройка динамических списков Ведение номеров сборок Ведение списка сценариев тестирования (testcases) и logfolders Связь с системой поддержки требований Дополнительные запросы, отчеты, правила, поля в проекте Регистрация дефектов, полученных от заказчика, от членов проектной команды, не уполномоченных на регистрацию
-
Контроль за соблюдением правил регистрации и обработки дефектов Анализ списков дефектов, диаграмм распределения и трендов для планирования работ и отчетности Контроль за дефектами, обнаруженными вне раунда тестирования -> доработка планов тестирования Обработка отклоненных дефектов Контроль за неподтвержденными дубликатами 101
-
Права и обязанностипоролям:Тестировщик
Регистрациядефектов, обнаруженных в раундетестирования Контрольреализациизапросовнаизменения и исправлениядефектов, включаядубликаты Обработкаотклоненныхдефектовпозапросу ТМ
-
Права и обязанности по ролям:Технический писатель
Назначение исполнителей дефектов документации, отслеживание выполнения, переназначение Контроль за отложенными дефектамидокументации Предварительный анализ дефектов документации (отклонение, планирование работ по фазам, дубликаты) Определение процесса в рамках которого родился дефект
-
Права и обязанностипоролям:Разработчик
Исправлениедефектов и реализациязапросовнаизменение Передачасборкинатестирование
-
Виды тестирования без плана
Ad hoc testing – это тестирование без подготовки, экспромтом. Такое тестирование может быть выполнено любым человеком. Exploratory testing – совмещение проектирования теста и его выполнения.
-
Подготовка к тестированию
Очистите кэш браузера или системный кэш Проверьте, что внешние ресурсы (системы), используемые в работе вашего приложения работают корректно Убедитесь, что среда тестирования (версия и тип браузера, настройки ОС, версии используемых приложений и ресурсов и т.п) соответствует плану тестирования и стратегии тестирования Тестовые данные загружены
-
Дефекты - основная продукция тестировщиков
Дефект - это любое расхождение между ожиданием и полученным результатом Примеры дефектов: поведение программы, не соответствующее спецификациям поведение программы, противоречащее разумным ожиданиям пользователя
-
Анализ найденного дефекта
Определены наиболее простые и наиболее общие условия возникновения ошибки Найдены другие пути возникновения той же самой ошибки Установлены связанные проблемы Найдены последствия, к которым ошибка может привести Проверена устойчивость воспроизведения дефекта
-
Найдены последствия, к которым ошибка может привести Простая на первый взгляд ошибка может иметь самые серьезные последствия. Например, небольшой мусор в углу экрана может быть как небольшой локальной проблемой, так и первым симптомом серьезной проблемы, лежащей в основе. В последнем случае, вполне возможно, что поработав дополнительно с программой удастся установить, что программа почти незамедлительно падает сразу же после появления мусора на экране.
-
Б. Марек приводит такой пример («Working Effectively with Developers”). Проверяемая система не обрезала пробелы в начале и в конце имени, под которым пользователь идентифицировал себя в системе. Он мог бы описать такую ошибку, как «Допустим ввод имени, которое будет затем трудно прочитать». Серьезность описанной таким образом ошибки была бы установлена как Minor. Однако Марек знал, что имя пользователя являлось частью имени файла, в котором данные пользователя записывались на диск, и что у программы были проблемы при работе с именами файлов, содержащими пробелы. Поэкспериментировав с этими двумя обстоятельствами, он написал отчет, озаглавленный «Потеря всех данных за сессию (для имен с пробелами в конце)», что было гораздо более убедительным. 110
-
Зачем нужно хорошееописание дефекта
Улучшается качество программы Экономится время разработчиков Уменьшается жизненный цикл дефекта Устанавливаются нормальные отношения между разработчиками и тестировщиками
-
Хороший отчет о дефекте
Хороший отчет о дефекте должен удовлетворять следующим требованиям: Простота Полнота Объективность Нейтральность. Отчет о тестировании также не должен содержать необязательных слов или шагов.
-
При работе с ошибками необходимы не только точность, понятность, строгость описания ошибки, но и СВОЕВРЕМЕННСТЬ и АКТУАЛЬНОСТЬ их заведения и выставления/изменения статусов. Другими словами, если вы обнаружили ошибку и вам удалось ее еще раз воспроизвести — сразу заведите ее (и даже если воспроизвести второй раз не удалось), если вы протестировали исправленную ошибку и она не воспроизвелась — сразу же закройте ее (или переоткройте, ее, если она не исправлена). Это дает возможность группе разработки быстрее обрабатывать и исправлять ошибки
-
Простота не используйте сложные грамматические структуры или неоднозначные выражения для описания дефекта применяйте короткие ясные фразы, дабы избежать неоднозначных шагов или определений лучше всего подходит оформление в виде списка Полнота Объективность не указывать на виновника работа тестировщика - предоставить объективные данные для принятия верных решений
-
Нейтральность не вкладывайте эмоции в описание дефекта Не пользуйтесь формулировками юмористического или саркастического характера излагайте суть дефекта ясным и деловым языком
-
Использование нечётких или неоднозначных формулировок: В тексте сообщения об ошибке тестировщик использует терминологию, которая является неточной или неоднозначной. Например: тестировщик ссылается на «этот диалог» в сообщении об ошибке, и при этом под «диалогом» он подразумевает «обмен сообщениями между сторонами», а разработчик интерпретирует «диалог» как вспомогательное окно в пользовательском интерфейсе.
-
Использование нечётких или неоднозначных формулировок: Тестировщик пишет, что текстовое поле «разблокировано, в то время как оно должно быть заблокировано», в действительности имея в виду, что текстовое поле «доступно для редактирования, в то время как оно должно быть доступно только для чтения». 117
-
Важные составляющие описания дефекта
При описании дефекта важно указать следующие данные: Краткое описание дефекта Подробное описание Воспроизводимость и шаги для воспроизведения дефекта Серьезность дефекта
-
Важные составляющиеописания дефекта
Снимки экрана Делаете снимок части экрана - проблемной зоны (лучше в формате JPEG) Стоит использовать программы, которые приспособлены к такого рода действиям и имеют много очень полезных функций, например SnagIt, HyperSnap, HardCopy, RoboScreenCapture, FullShot 9, HyperSnap-DX 5, TNT 2. Снимок экрана нужно прикрепить к отчёту об ошибке.
-
120 Снимки экрана Снимки экрана, показывающие проявление ошибки или иллюстрирующие шаги её воспроизведения, являются эффективным способом фиксации информации, особенно для ошибок, связанных с пользовательским интерфейсом. Убедитесь, что тестировщики умеют прикреплять файлы в вашей системе управления дефектами, и поощряйте их использовать это. Прикреплённые изображения могут служить как удобным способом продемонстрировать разработчику, что ошибка действительно происходит, так и средством доказать тестировщику, что ошибка исправлена.
-
Описание дефекта:Краткое описание проблемы
Краткое (в одну строку) описание проблемы – очень важная часть описания дефекта. Будет использоваться менеджером проекта при анализе списка неисправленных дефектов. Будет использоваться при анализе дефектов, которые не предполагается исправлять. Позволит им выделить и подробнее рассмотреть только значимые дефекты.
-
122 Идеальное краткое описание дает читающему достаточно информации для того, чтобы решить, нужна ли ему дополнительная информация. Оно должно включать : Краткое, но достаточно точное описание, позволяющее понять суть дефекта. Краткое указание на область и условия проявления дефекта (насколько проявление дефекта зависит от условий выполнения программы) Указание на серьезность дефекта (помогающее представить последствия его наличия в продукте)
-
Описание дефекта:Подробное описание
Как можно подробнее опишите суть проблемы; не полагайтесь на сделанное краткое описание Будет использоваться менеджером проекта и разработчиком при углубленном изучении сути дефекта. Должно быть самодостаточным, концентрирующим в одном месте максимум информации о дефекте
-
124 Перечислите все переменные окружения (configи т.п.), не описанные в других полях отчета. Если ошибка трудновоспроизводима (требует специальных условий - специфических входных данных, предварительных действий, напрямую не связанных с этой ошибкой т.п.), то четко опишите эти условия. Правильное подробное описание не вызывает у читающего дополнительных вопросов.
-
Описание дефекта:Воспроизводимость
Всегда описывайте воспроизводимость дефекта. Никогда не говорите «да», пока не поймете, как добиться повторения этой ошибки. (Научитесь воспроизводить ошибку до составления отчета.) Если после неоднократных попыток воспроизвести ошибку не удается, то напишите «нет» и объясните, какие действия вы предпринимали для ее воспроизведения.
-
126 Всегда описывайте воспроизводимость дефекта. Если дефект проявляется нерегулярнои вы все еще не понимаете, почему, то напишите «иногда» и дайте поясните. Не всегда возможно воспроизвести ошибку. Например: дефект, описанный пользователем, проявляющийся в специфической ситуации, которую трудно воспроизвести. Обязательно! Тестировщик должен воспроизвести ошибку в присутствии разработчика, если разработчик говорит, что не может ее повторить.
-
Как воспроизвести дефект. Опишите шаги для воспроизведения этого дефекта. Начните описание с известного места (например, с запуска программы или открытия входного документа) и Затем опишите каждый шаг до проявления ошибки. НУМЕРУЙТЕ ШАГИ. Отделяйте шаги один от другого. Опишите ожидаемое и фактическое поведение. Разница между ними и будет сущностью дефекта.)
-
Описание дефекта:Итог
CemKaner “ … abugreportisatoolthatyouusetoselltheprogrammerontheideaofspendinghertimeandenergytofixabug …” Отчет о дефекте должен вызывать потребность исправить ошибку побуждать программиста исправить ошибку побуждать к принятию бизнес-решений преодолевать возражения
-
Распространенные ошибки при описаниидефектов
Тестировщики сохраняют эмоциональную и мыслительную дистанцию от продукта, которую разработчик не может сымитировать даже при всём желании. Тестирование — задача, требующая терпения, внимания к деталям и весьма непрямолинейного мышления. Иногда менеджеры делают ошибку, рассматривая тестирование как работу второго сорта, которую могут выполнять менее квалифицированные или более младшие сотрудники. Такое искажённое восприятие служит плохую службу как проекту, так и сообществу тестировщиков.
-
130 Однако наличие отдельной группы тестирования имеет распространённый побочный эффект — развитие отношений соперничества между тестировщиками и разработчиками. Это легко может случиться. Примеры того, как НЕ нужно сообщать об ошибках, которые можно использовать в качестве контрольного списка, чтобы удостовериться, что они не раздражают разработчиков Разработчики могут его использовать, чтобы идентифицировать источники трения между собой и группой тестирования.
-
Сокращение инструкции по воспроизведению ошибки Отсутствие описания ошибочного поведения Отсутствие описания ожидаемого поведения Отсутствие обоснования ожидаемого поведения Повторное открытие старых сообщений для новых ошибок с похожими признаками
-
132 Тестирование устаревшей версии программы Изобретение требований, основанных на личных предпочтениях Диагноз вместо описания симптомов Завышение приоритета дефекта Оправдание плохого покрытия плохими предположениями
-
Сокращение инструкции по воспроизведению ошибки Тестировщики полагают, что они могут сэкономить время, описывая обстоятельства, при которых проявляется дефект, в самых кратких возможных терминах. Сообщение об ошибке превращается в сокращённую запись основных действий, необходимых для воспроизведения ошибки, опуская все несущественные.
-
134 Сокращение инструкции по воспроизведению ошибки Будучи незнакомым с внутренней структурой приложения, тестировщик не может знать, какие из выполненных им действий наиболее существенны для диагностирования данной ошибки. Пренебрегая действиями, которые кажутся им незначительным, они повышают риск потери важной информации. Лучший способ избежать этой проблемы - просто перечислить все действия, которые необходимы для воспроизведения ошибочного поведения, иногда даже начиная с запуска приложения.
-
Отсутствие описания ошибочного поведения Описание в сообщении об ошибке заканчивается на простом утверждении о том, в каком состоянии находится приложение, без указания того, какой аспект этого состояния собственно является ошибкой. Например, сообщение об ошибке заканчивается так: «Появляется диалог Свойства», но тестировщик не добавляет, что «..., и элементы управления свойствами доступны, несмотря на то, что выбранный элемент доступен только для чтения».
-
Отсутствие описания ожидаемого поведения Даже когда сообщение об ошибке содержит описание ошибочного поведения, тестировщик иногда забывает объяснять, каково ожидаемое (правильное) поведение. Например, сообщение об ошибке заканчивается так: «файл молча сохраняется», но тестировщик не добавляет, что «..., но нет никакого визуального признака, что приложение занято выполнением операции сохранения. Курсор должен принять вид песочных часов и должен появиться модальный диалог с индикатором прогресса».
-
Отсутствие обоснования ожидаемого поведения Не всегда ясно, почему тестировщик решил, что наблюдаемое поведение ошибочно. В сообщение об ошибке может быть просто написано «должно случиться X» без объяснения того, почему X — правильное поведение. Ссылка на спецификацию требований — вполне подходящее обоснование. Если обоснование апеллирует к некоторому внешнему стандарту, ссылка на соответствующую часть этого стандарта тоже годится.
-
Повторное открытие старых сообщений для новых ошибок с похожими признаками Сообщение об ошибке помечено как FIXED, но в ходе дальнейшего тестирования тестировщик видит ошибочное поведение, которое очень похоже на то, которое было вызвано этой ошибкой. Рассуждая, что поведение является настолько похожим, что это должно иметь ту же самую причину, тестировщик делает вывод, что ошибка, ранее помеченная как FIXED , повторно всплыла, и изменяет статус сообщения об ошибке с FIXED на REOPEN . Это вызывает проблемы у разработчика, потому что повторное открытие ошибки подразумевает, что снова возникли первоначальные признаки ошибки, а не похожие признаки, замеченные тестировщиком. Тестировщик выдаёт разработчику неправильный диагноз ошибки вместо простого сообщения о наблюдаемом ошибочном поведении.
-
139 Повторное открытие старых сообщений для новых ошибок с похожими признаками Необходимо воздерживаться от повторного использования старых сообщений об ошибках, если наблюдаемое ошибочное поведение не в точности совпадает с тем, которое описано в старом сообщении. Если есть хотя бы малейшее сомнение, создавайте полностью новое сообщение об ошибке. Разработчик может всегда пометить его как дубликат старого сообщения об ошибке и повторно открыть старое сообщение самостоятельно
-
Тестирование устаревшей версии программы Всегда необходимо проверять, что тестирование происходит на новой версии (установлена версия, очищен кэш и т.п.)
-
Изобретение требований, основанных на личных предпочтениях Набор требований обычно не является исчерпывающим. Поэтому часть их может быть отнесена к «здравому смыслу». Например, требование типа «пользовательский интерфейс должен соответствовать Microsoft Windows User Interface Guidelines» является весьма широким и может быть сложно для интерпретации в каждом конкретном случае. Некоторые тестировщики пытаются подменить их требования собственной версией «здравого смысла», принося этим свои недопонимания и неверные толкования.
-
142 Изобретение требований, основанных на личных предпочтениях Например, бывают сообщения об ошибке, указывающие, что «подменю не должно появляться, если все подпункты в нём заблокированы». Тестировщик расценил это как «здравый смысл». Однако стандарты пользовательского интерфейса явно декларируют, что такие подменю должны всегда появляться, даже когда все их пункты заблокированы, чтобы пользователь мог по крайней мере видеть содержание подменю и знал, где найти специфическую опцию, когда она станет доступна. Но сообщение об ошибке заявляет, что поведение «должно» быть другим. Получается, что тестировщик сфабриковал требование и решил придать ему значимость, употребив слово «должно», как будто это на самом деле требование.
-
Диагноз вместо описания симптомов То ли из-за самоуверенности, то ли из-за совершенно неуместного стремления быть полезным, тестировщик описывает то, что, по его мнению, является причиной ошибки, вместо простого описания наблюдаемого поведения. Например, тестировщик исследует лог-файл и исходя из названия исключения в трассировке стека вызовов приходит к выводу, что приложению не хватает памяти. Окрылённый этим прозрением, он опускает все остальные части сообщения об ошибке, думая, что он уже обеспечил разработчиков всей необходимой информацией.
-
Завышение приоритета дефекта Некоторые тестировщики демонстрируют тенденцию к завышению приоритета сообщений об ошибках, найденных на более поздних стадиях проекта. По мере продвижения тестирования идентификация новых ошибок становится всё труднее и труднее, поэтому кажется, что дополнительные усилия, потраченные на их нахождение, должны быть скомпенсированы более высоким приоритетом Разработчики обнаруживают, что дефекты, которые в начале проекта расценивались бы как низкоприоритетные, внезапно становятся главными проблемами. Этот эффект может также иметь быть связан с увеличивающимся напряжением или приближающимся крайним срокам.
-
Оправдание плохого покрытия плохими предположениями Вместо исчерпывающего тестирования всех возможных комбинаций входных данных и состояний тестировщики выбирают для тестирования ограниченное подмножество, рассуждая, что выбранное подмножество окажется достаточным для полного покрытия кода. В действительности, они делают предположения о покрытии кода, исходя из логики управления пользовательским интерфейсом. Иногда предположения такого рода могут и даже должны быть сделаны, например, при недостатке времени для проведения исчерпывающего тестирования. Но в этом случае не тестировщики, а разработчики должны выбрать представительное подмножество операций, которые необходимо протестировать.
-
Работа тестировщика с репозиторием дефектов
Регистрация дефектов, обнаруженных в раунде тестирования Контроль реализации запросов на изменения и исправления дефектов, включая дублирующие дефекты Обработка отклоненных дефектов по запросу тест-менеджера
-
Защита дефекта
Экспертиза силами коллег После того, как дефекты обнаружены и описаны, можно (если нет уверенности в описании или ошибочности работы программы) произвести экспертизу силами равных или старших по должности, чтобы удостовериться в том, что они написаны понятным языком и носят объективный характер. Полезно показать отчет коллегам, которые могут указать на недостатки, ускользнувшие из поля зрения автора.
-
148 Отстаивание собственной позиции При спорах о дефектах тестировщик должен уметь отстаивать свое мнение. При этом всегда необходимо быть уверенным в том, что описанная ситуация на самом деле является ошибкой. Если уверенности нет, то лучше перепроверить и/или проконсультироваться с коллегами, руководителем или аналитиком. Если уверенность есть, то необходимо быть настойчивым и аргументировано отстаивать свои дефекты. Если же ситуация не является дефектом, то необходимо уметь признавать собственные ошибки.
-
Валидация дефектов
Проверка исправления ошибки При повторном тестировании приложения всегда тестируются ошибки, отмеченные разработчиками как исправленные в текущем билде. При тестировании исправленных ошибок всегда нужно помнить, что ошибка может вызывать сбои не только в месте ее обнаружения, но также и вокруг. Например за одной большой ошибкой может скрываться множество мелких.
-
150 Изменение статуса проверенной ошибки Если исправлена – закрыть Если не исправлена (при воспроизведении ошибка снова появляется) – открыть заново Проверка функциональности, связанной с ошибкой («посмотреть вокруг») Проверка функциональности, в которой была ошибка с другими входными данными Проверка возможной связанной функциональности
-
Требования к протоколу тестирования
Список сценариев тестирования в соответствии с заданием на тестирование Отметки о результатах выполнения каждого шага сценария (Passed, Failed, N/A) Указания на дефекты, обнаруженные в рамках шага или рядом с ним (ID, важность, new or known) Информация о конфигурации клиентской машины и сервера
-
152 Информация о тестировании вне плана (при его отсутствии или отклонении в сторону) Чек-лист по тестируемым областям или функциональным элементам Список дефектов для валидации и результаты их валидации (Closed or Opened) Список обнаруженных дефектов с указанием ID & важности. Информация о дате тестирования, версии приложения, версии плана тестирования Информация о суммарном времени, затраченном на тестирование
-
Регрессионное тестирование
Регрессионное тестирование — собирательное название для всех видов тестирования программного обеспечения, направленных на обнаружение ошибок в уже протестированных участках исходного кода. Такие ошибки, когда программа уже работала, а затем перестала работать или стала вести себя не так ,как планировалось, называют регрессионными ошибками. Обычно используемые методы регрессионного тестирования включают повторные прогоны предыдущих тестов, а также проверки, не попали ли регрессионные ошибки в очередную версию в результате слияния кода.
-
Типы регрессионноготестирования
-
Классы эквивалентности(Equivalence Class Testing\ Equivalence Portioning)
Класс эквивалентности — это класс, в рамках которого все тесты являются эквивалентными. Эквивалентные тесты — это тесты, которые приводят к одному и тому же результату. Если мы выполним два любых теста из одного класса эквивалентности — то получим один и тот же результат. Предполагается не результат «pass», а то, что мы идем по тем же самым шагам, используя другие данные и получаем аналогичный результат (с поправкой результата на эти самые другие данные, конечно). Классы эквивалентности обычно тестируют на границах и их девиациях (+-1, например), потому что вероятность поймать ошибку на таких значениях выше из-за возможных ошибок на операциях сравнения.
-
Правила выделения классов эквивалентности
Если входное условие описывает диапазон, то выделяют один правильный класс эквивалентности и два неправильных Если входное условие описывает множество значений, каждое из которых трактуется особо, то определяется правильный класс эквивалентности для каждого из значений и один неправильный класс значений Если входное условие трактуется как «должно быть», то делается один правильный класс эквивалентности и один неправильный Если есть подозрение, что различные элементы класса эквивалентности могут трактоваться программой по-разному, следует разбить класс на несколько подклассов
-
Правила составления тестов
Каждому классу эквивалентности назначается уникальный номер Проектирование новых тестов, каждый из которых покрывает как можно большее число непокрытых правильных классов эквивалентности до тех пор, пока не будут покрыты все правильные классы эквивалентности Проектирование тестов, каждый из которых покрывает один и только один из непокрытых неправильных классов эквивалентности пока все неправильные классы эквивалентности не будут покрыты тестами
-
Классы эквивалентности
Пример: Допустим, мытестируемИнтернет-магазин, продающийкарандаши. Взаказенеобходимоуказатьколичествокарандашей (максимудлязаказа – 500штук). В зависимостиотзаказанногоколичествакарандашейразличаетсястоимость: 1 – 100 – 10 грн. закарандаш; 101 – 200 – 9 грн. закарандаш; 201 - 300 – 8 грн. закарандаш и т.д. С каждойновойсотней, ценауменьшаетсянагривну.
-
Очевидно, чтонашивходныеданныемыможемразделитьнаследующиеклассыэквивалентности: Невалидноезначение: >500штук; Невалидноезначение:
-
Анализ граничных значений(Boundary Value Testing)
Задача: идентифицировать граничные значения для каждого входного значения (класса эквивалентности) на границе значение, меньшее граничного («у границы»\’below point’) значение, большее граничного(«за границей» \’above point’) Примеры: Область корректных значений: [-1.0, 1.0] -> тесты для -1.0, 1.0, -1.001, 1.001 Максимальная длина слова – 5 символов - > тесты для 4,5,6 Область выходных значений: минимум расхода 0.00, максимум 2000 -> подбираем входные данные для того, чтобы получить на выходе 0.00, 2000.00, 2000.01, -0.01
-
Правила составления тестов
Построить тесты для границ области и тесты с неправильными данными для случаев незначительного выхода за границы области, если входное значение описывает диапазон значений Построить тесты для минимального и максимального значения условий и тесты, большие и меньшие этих значений, если входное условие удовлетворяет дискретному ряду значений Использовать правило 1 для каждого выходного условия Использовать правило 2 для каждого выходного условия Если вход или выход программы есть упорядоченное множество, то сделать тесты на первый и последний элементы Попробовать найти другие граничные значения
-
Граничные значения
Граничные значения: «точка»: Z -> Z-1, Z, Z+1 Граничные значения: область корректных значений [x, y] -> x-1, x, y, y+1
-
Пример тестирования граничных значений
Поле ввода: возраст сотрудника. Допустимые значения: от 14 до 80.
-
Таблицы решений
Таблицы решений (Decision Table Testing) 1. Определить список возможных условий
-
Таблицы решений (Decision Table Testing) 2. Определить список всех возможных действий (ожидаемых результатов для условий).
-
Таблицы решений (Decision Table Testing) 3. Определить все значения для условий («да»\«нет» или более 2х значений) и их уникальные комбинации, которые приводят квыполнению ожидаемых результатов связанных с этим правилом
-
Таблицы решений (Decision Table Testing) 4. Создать тест кейс для каждого правила (столбца) – как минимум один, если условия бинарные и если условие – интервал значений, рассмотреть тесты как для нижней так и для верхней границы интервала
-
Функциональные диаграммы
Метод функциональных диаграмм(Cause-Effect Graphing) предлагает способ перевода спецификаций, написанных на естественном языке, на язык формальный Способствует проектированию высокорезультативных тестов, не страдающих избыточностью, и обнаруживающих случаи неполноты и неоднозначности во входных спецификациях
-
1. Разбить внешние спецификации на отдельные функции, которые будут тестироваться (декомпозиция фугкциональных требований) 2. Идентифицировать явные и неявные причины (условия на входе) и присвоить каждой из них уникальный номер 3. Идентифицировать явные и неявные эффекты (действия на выходе) и присвоить каждому из них уникальный номер 4. Перевести семантику спецификации в граф «причина-следствие» (Boolean cause-effect graphing) 5. Добавить информацию о невозможных комбинация причин\эффектов 6. Построить таблицу решений (бинарные значения) 7. Записать тест кейс для каждого столбца
-
Пример 1 -> Требования для расчета стоимости автомобильной страховки в США: Для женщин возрастом менее 65 лет, страховая премия равна $500 Для мужчин возрастом менее 25 лет, страховая премия равна $3000 Для мужчин возрастом от 25 до 64 лет, страховая премия равна $1000 Для всех водителей возрастом от 65 лет и старше, страховая премия равна $1500
-
Причины (Causes (input conditions)): 1. Пол: мужской 2. Пол: женский 3. Возраст: =25 and = 65
-
Следствия (Effects (output conditions)): 100. Премия = $1000 101. Премия = $3000 102. Премия = $1500 103. Премия = $500
-
Причина: 1. Пол: мужской and 4. Возраст: >=25 and
-
Причина: 1. Пол: мужской and 3. Возраст:
-
Причина: 1. Пол: мужской and 5. Возраст: >= 65 or 2. Пол: женский and 5. Возраст: >= 65 Следствие: 102: Премия = $1500 Рисунок # 3
-
Причина: 2. Пол: женский and 3. Возраст: =25 and
-
Рисунок # 3 Причина: 1. Пол: мужской and 5. Возраст: >= 65 or 2. Пол: женский and 5. Возраст: >= 65 Следствие: 102: Премия = $1500
-
Разработка тестов: функциональные диаграммы
-
Предположение об ошибке
Предположение об ошибке (Error Guessing) Этот метод в значительной степени является интуитивным. Тест инженер использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы "предугадать" при каких входных условиях система может выдать ошибку. Перечислить в некотором списке возможные ошибки или ситуации, в которых они могут появиться, а затем на основе этого списка написать тесты.
-
Ошибка адресации – ошибка, состоящая в неправильной адресации данных (например, выход за пределы участка памяти). Ошибка ввода-вывода – ошибка, возникающая в процессе обмена данными между устройствами памяти, внешними устройствами. Ошибка вычисления – ошибка, возникающая при выполнении арифметических операций (например, разнотипные данные, деление на ноль и др.). Ошибка интерфейса – программная ошибка, вызванная несовпадением характеристик фактических и формальных параметров (как правило, семантическая ошибка периода компиляции, но может быть и логической ошибкой периода выполнения). Ошибка обращения к данным – ошибка, возникающая при обращении программы к данным (например, выход индекса за пределы массива, не инициализированные значения переменных и др.). Ошибка описания данных – ошибка, допущенная в ходе описания данных.
-
Разработка тестов
Requirements-Driven Testing Проверяем каждое требование/запрос, которое описано или озвучено анализ требований: выявление неоднозначностей, неточностей, пропущенной информации и т.п. (можно использовать функциональные диаграмма) Отслеживаем все требования и их покрытие тестами список требований с идентификаторами и соответствующих тестов (Requirements Tracing Matrix) Для каждого требования должны быть разработаны тесты
-
Тестирование элементов интерфейса
-
20 заповедей дизайна пользовательского интерфейса
Обязанность интерфейса — обеспечение взаимодействия Интерфейсы служат для обеспечения взаимодействия между людьми и окружающим миром. Они помогают нам прояснять, освещать, реализовывать и наблюдать взаимосвязи; они могут объединять и разъединять нас, влиять на наши ожидания; а кроме того, они дают нам доступ к различным услугам. Не стоит принимать процесс разработки интерфейса за искусство в чистом виде, а сам интерфейс — за некий арт-объект. Интерфейсы призваны выполнять определенные функции, и эффективность их работы можно измерить. Но и к одним только утилитарным вопросам роль интерфейсов не сводится. Действительно хорошие интерфейсы способны вдохновлять, пробуждать, окутывать тайной и укреплять наши отношения с окружающим миром.
-
Ясность прежде всего Любой интерфейс в первую очередь должен быть понятным. Чтобы эффективно использовать разработанный вами интерфейс, люди должны понимать, что он из себя представляет, зачем им его использовать, какие задачи они смогут с его помощью выполнять, к чему приведет то или иное действие — и тогда они смогут успешно с ним взаимодействовать. Да, разобраться в интерфейсе с первого раза может быть непросто, но двусмысленностям в нем места нет. Понятному интерфейсу пользователи доверяют и поэтому, скорее всего, будут использовать его в дальнейшем. В общем, вместо того чтобы запихивать все на один экран и тем самым запутать пользователей, лучше сделайте сотню понятных экранов.
-
3. Внимание любой ценой Нас постоянно что-то отвлекает. Даже спокойно почитать уже невозможно без того, чтобы что-нибудь не отвлекло от дела. Внимание пользователей бесценно. Дайте ему сосредоточиться, не засоряйте приложения элементами, отвлекающими внимание от главного назначения того или иного созданного вами экрана. Если пользователям нужно что-то прочитать, то дайте им достаточно времени для этого, а уж потом показывайте рекламу, если это необходимо. Цените внимание ваших пользователей: от этого в выигрыше будут и они, и вы. Для обеспечения использования продукта внимание пользователей — жизненно важный фактор. Старайтесь удерживать его любой ценой.
-
Под контролем пользователей Людям нравится чувствовать контроль над ситуацией. Многие разработчики об этом не задумываются, и в результате пользователи вопреки своему желанию вынуждены совершать операции, которые они не собирались совершать, причем направление их движения оказывается весьма неясным, а результаты действий — неожиданными. Дайте пользователям почувствовать, что ситуация под их контролем, периодически отображая состояние системы, описывая причинно-следственные связи (если вы сделаете это, случится то-то) и помогая им ясно понять, чего можно ожидать от каждой конкретной операции. И не бойтесь быть Капитаном Очевидностью. Очевидные вещи далеко не всегда так уж очевидны.
-
Лучшее управление — прямое управление Лучший интерфейс — никакого интерфейса: например, с объектами реального мира мы взаимодействуем напрямую. Но постепенно появляется все больше объектов цифровой природы, которыми управлять напрямую невозможно, и тут нам на помощь приходят интерфейсы. Очень легко сбиться с верного пути и в итоге перегрузить интерфейс кнопками, финтифлюшками, графикой, параметрами, настройками, окнами, дополнительными вставками и прочим «мусором». В результате пользователи вынуждены вместо выполнения задач заниматься управлением элементами интерфейса. Чтобы этого избежать, возьмите за образец прямое управление: интерфейс должен быть максимально незаметным и способным распознавать естественные человеческие жесты. В идеале у пользователей должно появиться ощущение, будто они управляют объектом напрямую.
-
Один экран — одна основная задача Каждый экран приложения должен служить для выполнения какой-либо одной задачи, стоящей перед пользователями. Так пользователям приложения будет проще в нем разобраться и с ним работать, а разработчикам — расширять его функционал при необходимости. Экраны, поддерживающие выполнение нескольких основных задач, сбивают пользователей с толку. Очевидно, что, например, текст не может содержать две или три главные темы — главная тема может быть только одна. Так и дизайнерам следует закладывать в каждый экран возможность выполнения только одной ключевой задачи.
-
Второстепенная задача, знай свое место Кроме какой-то одной ключевой задачи экраны также могут служить для выполнения нескольких второстепенных задач. Но важно помнить, что главные и второстепенные задачи нельзя валить в одну кучу. Вы же, например, пишите статью не для того, чтобы пользователи делились ею в твитере, правильно? Ваша главная задача в этом случае — чтобы они ее прочитали и осознали прочитанное. Второстепенные задачи не должны выходить на первый план: к примеру, они могут быть оформлены менее заметным образом или отображаться только после того, как была выполнена ключевая задача.
-
Место для шага вперед Так как большинство операций пользователей не обрывают процесс взаимодействия, а последовательно переходят друг в друга, весьма благоразумно будет спроектировать для каждой операции какое-нибудь продолжение. Постарайтесь представить себе, каким будет следующий шаг пользователей в каждом конкретном случае, и выстраивайте интерфейс в соответствии с этим. Как и в обычно человеческом общении, здесь нужна отправная точка для дальнейшего взаимодействия. Если пользователи уже сделали все, что требовалось, не бросайте их: дайте им возможность естественным образом сделать следующий шаг на пути к достижению их целей.
-
Поведение определяет внешний вид (или «функция определяет форму») Люди предпочитают иметь дело с тем, что ведет себя предсказуемым образом: это равным образом относится к другим людям, животным, объектам — и в том числе к программному обеспечению. Когда чье-то поведение совпадает с нашими ожиданиями, мы чувствуем себя на правильной волне. Соответственно, элементы дизайна интерфейса должны выглядеть соответственно своему поведению. На практике это означает, что пользователи должны понимать, как поведет себя тот или иной элемент интерфейса, едва взглянув на него. Элемент, похожий на кнопку, и вести себя должен как кнопка. Не стоит заигрывать с основополагающими аспектами взаимодействий пользователей и интерфейса — приберегите свою творческую энергию для задач другого порядка.
-
Как важно быть последовательным Из предыдущего пункта следует, что если поведение экранных элементов различается, то и выглядеть они должны по-разному. Безусловно, элементы, схожие в поведении, и выглядеть должны схожим образом (последовательно). Но не менее важно, чтобы несхожие элементы были оформлены по-разному (т. е. непоследовательно). Дизайнеры-новички, стараясь сделать интерфейс логичным и последовательным, зачастую игнорируют существенные различия между элементами и используют для их оформления одни и те же приемы там, где следовало бы внести разнообразие.
-
Четкая иерархия — всему голова Четкая визуальная иерархия достигается, когда элементы на экране расположены в определенном порядке. То есть одни и те же элементы отображаются в одном и том же порядке каждый раз. Плохо проработанная визуальная иерархия не приносит никакой пользы и только сбивает пользователей с толку. В постоянно изменяющихся средах не так-то просто поддерживать четкую иерархию элементов, потому что визуальный вес становится относительной величиной: ведь если выделено все, то не выделено ничего. Если на экран нужно добавить заметный элемент, дизайнеру может понадобиться сделать все остальные элементы менее заметными, чтобы сохранить визуальную иерархию. Большинство пользователей не задумываются о визуальной иерархии при работе с интерфейсом, но при этом ее продуманное (или непродуманное) выстраивание — это один из самых легких способов улучшить (или ухудшить) дизайн.
-
Грамотная организация снижает когнитивную нагрузку Джон Маэда (John Maeda) в своей книге Simplicity пишет, что грамотная организация элементов интерфейса позволяет придать экрану менее загруженный вид. С помощью продуманной организации элементов вы сможете продемонстрировать связи между ними, и освоить такой интерфейс пользователям будет куда проще. Группируйте схожие элементы, располагайте их на экране таким образом, чтобы пользователям стало понятно, как они связаны между собой. Благодаря грамотной организации контента можно значительно снизить когнитивную нагрузку пользователей. Если в самом дизайне будут наглядно продемонстрированы связи между элементами, пользователям уже не придется мучительно в них разбираться! Не заставляйте пользователей лишний раз напрягаться — лучше просто покажите им все эти связи между элементами интерфейса с помощью вашего дизайна.
-
Подсказывай, а не указывай: роль цвета Цвет физических объектов меняется в зависимости от освещения. Одно и то же дерево, например, в полдень и на закате выглядит совершенно по-разному. В общем, в мире физических объектов цвет включает в себя множество оттенков и вообще довольно относителен, и в интерфейсах цвет также должен играть соответствующую роль. Цветом можно выделять объекты, привлекая к ним внимание пользователей, но при этом элементы нельзя разделять только по цвету. Если предполагается, что пользователи будут работать с каким-либо элементом продолжительное время, или же элемент содержит объемный текст, рекомендуется использовать для оформления бледные или приглушенные тона — а яркие оттенки приберегите для расстановки акцентов. Разумеется, можно использовать яркие цвета и для фоновой заливки, но только там, где это уместно.
-
Не все сразу На каждом экране должно отображаться только самое необходимое. Если пользователям требуется сделать выбор, предоставьте им ровно столько информации, сколько им для этого нужно. Подробностям можно посвятить последующие экраны. Не надо пытаться объяснить все от А до Я или выложить всю информацию разом. По возможности распределяйте рабочий процесс на несколько экранов, раскрывая информацию постепенно. Благодаря этому взаимодействие с интерфейсом остается ясным и понятным для пользователей.
-
Подсказывай с умом В идеальных интерфейсах подсказки не нужны вовсе, потому что такой интерфейс легко изучить и использовать. Но если спуститься с небес на землю, то в идеале подсказки должны быть контекстно-зависимыми и появляться только тогда и там, где они нужны, в остальное время оставаясь скрытыми. Заставляя людей открывать справку и искать ответы на возникшие у них вопросы, вы затрудняете их работу с интерфейсом, так как в этом случае им приходится формулировать, что именно они хотят найти. Лучше встраивать подсказки там, где они могут потребоваться. Только убедитесь, что они не будут лишний раз маячить перед носом тех пользователей, которые уже знакомы с интерфейсом.
-
Момент истины: нулевое состояние Дизайнеры часто упускают из вида такой важный момент, как первое знакомство с интерфейсом. Чтобы помочь пользователям как можно быстрее освоиться, дизайнер должен работать с прицелом на нулевое состояние — тот момент, когда еще ничего не произошло. Первый экран, который видят пользователи, не должен быть пустым, аки чистый лист, — на нем должны содержаться указания и подсказки для быстрого начала работы. Большинство затруднений при работе с интерфейсом возникает на почве непродуманного нулевого состояния. Но стоит пользователям понять правила игры, как их задача сразу значительно упрощается.
-
Текущие проблемы — главные проблемы Пользователям нужно решать задачи, актуальные на данный момент, а не гипотетические вопросы, которые могут возникнуть в будущем. Таким образом, интерфейс, ориентированный на решение потенциальных проблем, никому не будет нужен: изучайте текущую ситуацию и разрабатывайте интерфейс в соответствии с актуальными проблемами. Витать в облаках и строить гипотезы, конечно, гораздо увлекательнее, но зато результаты вашего труда окажутся востребованы благодарными пользователями, а не отправлены на свалку бесполезных интерфейсов.
-
Лучший дизайн — невидимый дизайн Интересный факт: действительно хорошие дизайны обычно никак не отмечаются пользователями, работавшими с ними. Причина заключается в том, что удачный дизайн позволяет пользователям сконцентрироваться на их задачах, а не на работе интерфейса. Пользователи, успешно выполнившие свои задачи, не станут задумываться над тем, как это так у них все хорошо получилось. Получается, что пользователи обращают внимание на дизайн только в том случае, если у них возникают какие-либо трудности. Да, дизайнеры не в восторге от того, что за удачные решения их никто не хвалит, притом что за косяки им достается по полной. Но действительно хорошим специалистам вполне достаточно того, что их дизайном активно пользуются. Они понимают, что довольный пользователь — это молчаливый пользователь.
-
Расширяем кругозор Визуальный и графический дизайн, полиграфия, копирайтинг, информационная архитектура и визуализация — все это входит в дизайн интерфейсов. С этими дисциплинами можно ознакамливаться вскользь, а можно углубиться в их изучение. Главное, не стоит смотреть на них свысока или вести язвительные дебаты о важности той или иной дисциплины. Черпайте в них полезные знания — и вперед. Не брезгуйте и на первый взгляд абсолютно не связанными с дизайном интерфейсов сферами. Подумайте, чему полезному можно научиться у издателя, автора программного кода, переплетчика книг, скейтбордиста, пожарного, каратиста?
-
Неиспользуемый интерфейс — плохой интерфейс Как и в других областях дизайна, в дизайне интерфейсов успешным считается тот результат дизайнерских трудов, который оказывается востребован пользователями. Люди не сядут даже в самое красивое кресло, если оно окажется неудобным, и этот предмет мебели не выполнит свою функцию, как и дизайн, который пользователи обходят вниманием. Таким образом, в дизайне интерфейсов важную роль играет создание не только самого объекта, но и некоей среды его использования. Дизайнер создает интерфейс не для услады собственных очей, а для того чтобы им пользовались!
-
GUI тестирование окон и экранов
Проверка точки входа. В каких случаях появляется данное окно? Панель навигации Выпадающий список меню Через меню по правому клику мышки Ярлычки 203
-
Общее состояние окна Проверить все элементы в окне на их присутствие: все необходимые элементы должны находиться на своих местах (это могут быть поля, подписи, списки, чек-боксы, радио-батоны, группы элементов, кнопки, заголовки окон, менюшки и т.п.). Проверить окно: желательно, чтобы оно имело дружелюбный интерфейс и было удобным для пользователей Проверить грамматику: должны быть проверены все тексты, надписи и сообщения Проверить состояние элементов в окне по умолчанию и их значения (они могут быть активны или неактивны, могут стоять галочки, что-то может быть выбрано и что-то может иметь какие-то значения и т.п.) 204
-
.Навигация Проверить куда можно перейти со страницы Особое внимание уделить кнопке “Назад” (Back) (если есть такая) Проверить положение курсора по-умолчанию (если это необходимо) Проверить навигацию при помощи клавиатуры Tab, Up, Down и т.п.: она должна быть логична и удобна 205
-
Горячие клавиши Проверить горячие клавиши доступные для приложения Стандартные сочетания клавиш (Ctrl+C, Alt+F4 и т.п.) 206
-
Стандартная функциональность элементов окна Например: Списки - скроллинг, сортировки Текстовые поля - должны быть редактируемыми Чек-боксы - выбрать, не выбрать Радио-батоны - выбрать, не выбрать Поля только для чтения Поля паролей ... 207
-
Проверка данных Пусто Минимальное значение Максимальное значение Меньше максимального Больше минимального Корректный тип данных (char, numeric и пр.) Некорректный тип данных Все необходимые значения ... 208
-
Проверка необходимых вводимых параметров Все необходимые параметры определены Необходимые параметры не определены (или все кроме одного) Проверить состояние элементов окна в зависимости от состояний элементов и данных 209
-
Изменение размеров окна. Проверить, как ведут себя элементы в окне: При изменении размеров окна Сжатии и растяжении Свертывании и развертывании При изменении разрешения экрана 210
-
Локализация Проверить окно и его элементы для поддерживаемых приложением локализаций Проверить на разных локализациях окружения (операционных систем и пр.) 211
-
Наиболее ценные качества тестировщика
Умение письменно и устно излагать проблему Способность предугадать, где находятся ошибки Способность одновременного выполнения нескольких задач Навыки работы по расписанию Умение работать в условиях давления Наблюдательность, внимание к деталям Способность представить себя на месте другого Склонность к экспериментам в большей степени, чем к теоретическим рассуждениям Умение сделать все немного не так, как другие, креативность, инициативность и азарт Обладание тактом и дипломатичностью
-
Вопросы для самопроверки
Что такое тестирование? Какова цель тестирования Каково место тестирования в системе качества? Приведите примеры различных способов классификации методов тестирования В чем различие стратегий тестирования белого и черного ящика? Какие существуют уровни тестирования?
-
Каковы основные модели разработки ПО Какими преимуществами обладает V-модель по сравнению с каскадной моделью? Какие виды тестирования соответствуют каждой из фаз разработки в V-модели? Какими преимуществами обладает итеративная модель по сравнению с V-моделью?
-
Дополнительныематериалы
http://software-testing.ru/ http://www.stickyminds.com/ http://seir.sei.cmu.edu/ http://www.kaner.com/ http://www.intuit.ru/department/se/testing/ http://www.rspa.com/reflib/Index.html http://s-test.narod.ru/index.htm С. Канер Lessons learned in software testing http://www.amazon.com/gp/reader/0471081124/ref=sib_rdr_fc/002-9775652-9384046?%5Fencoding=UTF8&p=S001 Введение в тестированиепрограммногообеспеченияЛуизаТамре Тестированиепрограммногообеспечения. Фундаментальныеконцепциименеджментабизнес-приложенийСэмКанер, ДжекФолк, ЕнгКекНгуен
Нет комментариев для данной презентации
Помогите другим пользователям — будьте первым, кто поделится своим мнением об этой презентации.