Действие > Ожидаемый результат > Test результат
Вопросы по тестированию.
· Что такое – тестирование?
Тестирование программного обеспечения (Software Testing) - проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. [IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004]
В более широком смысле, тестирование - это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов
· Каковы цели тестирования?
Основной задачей тестирования ПО является получение информации о статусе готовности заявленной функциональности системы или приложения.
Задача получения статуса готовности обычно реализуется как проверка сценариев использования системы в валидных и невалидных условиях использования, которые формируются наборами входных данных и состояний, операций или пеолучаемых тестируемым функционалом данных и набором выходных данных и состояний системы.
Выявленные ошибки это побочный результат отработки задачи тестирования ПО, так как напрямую не являются нужной и полезной Заказчику тестирования информацией.
Количество найденных в процессе тестирования ошибок никак не характеризует уровень качества конечного продукта, а может выступать метрикой качества или зрелости самого процесса разработки ПО.
Количество найденных в процессе тестирования ошибок никак не характеризует целесообраз-ность затрат ресурсов на проведение тестирования, так как напрямую зависит в основном от состояния продукта на момент начала тестирования и в меньшей степени от степени подготовленности/спланированности тестирования.
· Что входит в тестовую документацию?
План тестирования (Test Plan)
Набор тест кейсов и тестов (Test Case & Test suite)
Дефект / Баг Репорты (Bug Reports / Defects)
· Что такое тест-план?
это документ описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
Хороший тест план должен как минимум отвечать на следующие вопросы:
1. что надо тестировать (объект тестирования: система, приложение, оборудование)
2. что будете тестировать (список функций и компонент тестируемой системы)
3. как будете тестировать (стратегия тестирования – виды тестирования и их применение по отношению к тестируемому объекту)
4. когда будете тестировать (последовательность проведения работ: подготовка, тестирование, анализ результатов, в разрезе запланированных фаз разработки проекта)
5. критерии начала и окончания тестирования
· Что такое чек-лист?
Это описание того, что должно быть проверено, без предварительного составления тест-кейсов. Используется как заместитель тест-плана в условиях дефицита времени тестировщика.
· Чем отличается чек-лист от тест-плана?
Отсутствием предварительно разработанных тест кейсов, что экономит время тестировщика и повышает гибкость процесса проверки одной и той же функциональности за счет оперативного изменения точки зрения на предмет тестирования в условиях регрессионного тестирования.
· Плюсы и минусы чек-листов
Какие преимущества чек-листов по сравнению с тест-кейсами:
· нивелирование эффекта пестицида в регрессионном тестировании
- расширение тестового покрытия за счёт отличий при разном прохождении
- сокращение затрат на содержание и поддержку тестов: не надо писать много буковок!
- отсутствие рутины, которую так не любят квалифицированные тестировщики
- возможность проходить и комбинировать тесты по-разному, в зависимости от предпочтений сотрудников
При этом, чек-листы сохраняют множество плюсов, свойственных детальным тест-кейсам:
· статистика: кто, когда, что проходил (с детализацией по сборке продукта и окружению, на котором проводилось тестирование)
- памятка, которая помогает не забыть важные тесты
· возможность оценить состояние продукта, его готовность к выпуску
минусы чек-листов:
· начинающие тестировщики не всегда эффективно проводят тесты без подробной документации
- чек-листы невозможно использовать для обучения начинающих сотрудников, так как в них недостаточно подробной информации
· заказчику или руководству может быть недостаточно того уровня детализации, который предлагают чек-листы
Итого, выбор очевиден: если у вас высокая текучка, низкоквалифицированные сотрудники или этого требует руководство, выбора нет, и придётся создавать и поддерживать подробные, детальные тест-кейсы. Но если в вашей команде квалифицированные сотрудники, то чек-листы значительно удобнее и помогут вам получить максимум пользы от тестовой документации, не тратя время на бюрократию!
· Наведите характеристики хорошего тест-плана
Хороший тест план должен как минимум описывать следующее:
1. Что надо тестировать?
o описание объекта тестирования: системы, приложения, оборудования
- Что будете тестировать?
- список функций и описание тестируемой системы и её компонент в отдельности
3. Как будете тестировать?
- стратегия тестирования, а именно: виды тестирования и их применение по отношению к объекту тестирования
4. Когда будете тестировать?
- последовательность проведения работ: подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки
5. Критерии начала тестирования:
- готовность тестовой платформы (тестового стенда)
- законченность разработки требуемого функционала
- наличие всей необходимой документации
- ...
- Критерии окончания тестирования:
- результаты тестирования удовлетворяют критериям качества продукта:
§ требования к количеству открытых багов выполнены
§ выдержка определенного периода без изменения исходного кода приложения Code Freeze (CF)
§ выдержка определенного периода без открытия новых багов Zero Bug Bounce (ZBB)
- ...
· Перечислите виды тестовых планов
Чаще всего на практике приходится сталкиваться со следующими видами тест планов:
1. Мастер Тест План (Master Plan or Master Test Plan)
2. Тест План (Test Plan), назовем его детальный тест план)
3. План Приемочных Испытаний (Product Acceptance Plan) - документ, описывающий набор действий, связанных с приемочным тестированием (стратегия, дата проведения, ответственные работники и т.д.)
4. Явное отличие Мастер Тест Плана от просто Тест Плана в том, что мастер тест план является более статичным в силу того, что содержит в себе высокоуровневую (High Level) информацию, которая не подвержена частому изменению в процессе тестирования и пересмотра требований.
Сам же детальный тест план, который содержит более конкретную информацию по стратегии, видам тестировании, расписанию выполнения работ, является "живым" документом, который постоянно претерпевает изменения, отражающие реальное положение дел на проекте.
В повседневной жизни на проекте может быть один Мастер Тест План и несколько детальных тест планов, описывающих отдельные модули одного приложения.
· Как можно повысить уровень доверия к тест-плану?
Для увеличения ценности вашего тест плана рекомендуется проводить его периодическое рецен-зирование со стороны участников проектной группы. Это можно сделать просто договорившись между собой или же реализовать в виде "процедуры утверждения".
Как пример, приведем список участников проектной группы, утверждение которых мы считаем необходимым:
- Ведущий тестировщик
- Тест менеджер (менеджер по качеству)
- Руководитель разработки
- Менеджер Проекта
Каждый из перечисленных участников проекта, перед утверждением, проведет рецензию и внесет свои комментарии и предложения, которые помогут сделать Ваш тест план более полным и качественным.
· Что такое тест-кейс?
Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части на предмет ее соответствия установленным требованиям.
Под тест кейсом понимается структура вида:
Действие > Ожидаемый результат > Test результат
Пример:
| Действие | Ожидаемый результат | Test результат (passed/failed/blocked) |
| Открыть "login" | Страница Login открылась | Passed |
· Какие виды тестовых случаев?
Тест кейсы разделяются по ожидаемому результату на позитивные и негативные:
- Позитивный тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.
- Негативный тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций (срабатывание валидаторов), а также проверяет, что вызываемая приложением функция не выполняется при срабатывании валидатора.
· Какова структура тестовых случаев
Каждый тест кейс должен иметь 3 части:
| PreConditions | Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния. |
| Test Case Description | Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям |
| PostConditions | Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста - initial state) |
· Обязателен ли в Test Case структурный элемент PostConditions
Примечание: Post Conditions не является обязательной частью. Это скорее всего - правило хорошего тона: "намусорил - убери за собой". Это особенно актуально при автоматизированном тестировании, когда за один прогон можно наполнить базу данных сотней или даже тысячей некорректных документов.
Пример тест кейса:
do A1, verify B1
do A2, verify B2
do A3, verify B3
В приведенном примере конечная проверка - В3. Это значит, что именно она является ключевой. Значит, A1 и А2 - это действия приводящие систему в тестопригодное состояние. А В1 и В2 - условия того, что система находится в состоянии пригодном для тестирования. Таким образом имеем:
| Action | Expected Result | Test Result (passed/failed/blocked) |
| PreConditions | ||
| do A1 | verify B1 | |
| do A2 | verify B2 | |
| Test Case Description | ||
| do A3 | verify B3 | |
| PostConditions |
PostConditions в данном примере не были описаны, но по логике вещей надо выполнить шаги, которые бы вернули систему в первоначальное состояние. (например, удалили созданную запись, или отменили бы изменения сделанные в документе)
· Чем вызвана трехуровневая структура тест-кейса?
Обеспечением чистоты проведения тестирования. В предыдущем примере конечная проверка безусловно единственная и в случае, если тест будет провален (test failed) будет сразу ясно почему. Если провальными окажутся проверки В1 и/или В2, то тест кейс будет заблокирован (test blocked), из-за того, что функцию невозможно привести в тестопригодное состояние (состояние пригодное для проведения тестирования), но это не значит, что тестируемая функция не работает.
| Action | Expected Result | Test Result (passed/failed/blocked) |
| PreConditions | ||
| do A1 | verify B1 | passed |
| do A2 | verify B2 | failed |
| Test Case Description: | ||
| do A3 | verify B3 | blocked |
| PostConditions |
· Что такое Test Case Specification
Это детализация описания тест-кейса. Бытует много разных мнений об уровне детализации при написании тест кейсов, а также количестве проверок в одном тест кейсе. Все они по своему правильные. Мое мнение, что уровень детализации тест кейсов должен быть таков, чтобы обеспечивать разумное соотношение времени прохождения к тестовому покрытию. Т.е. до тех пор пока покрытие тестами определенного функционала не меняется, можно уменьшать детализацию тест кейсов.
Пример тест кейса 1:
| Проверка отображения страницы | ||
| Действие | Ожидаемый результат | Результат теста |
| Открыть страницу "Вход в систему" | - Окно "Вход в систему" открыто - Название окна - Вход в систему - Логотип компании отображается в правом верхнем углу - На форме 2 поля - Имя и Пароль - Кнопка Вход доступна - Ссылка "забыл пароль" - доступна | ... |
Пример тест кейса 2:
Название: Проверка отображения страницы
Действие: Открыть страницу "Вход в систему"
Проверка: Проверьте, что отображаемая страница соответствует странице на картинке (и прилагаем изображение страницы "Вход в систему")
В примере 1 и 2 покрытие будет одинаковым, но вот время, которое потребуется для прохождения, будет разным. Мне кажется, что второй пример будет даже нагляднее.
Ниже приведем, с целью иллюстрации, пример детального оформления тестового случая
| Название: | Тест отправки комментария | ||
| Функция: | Контакт-Вопросы | ||
| Действие | Ожидаемый результат | Результат теста: · пройден · провален · заблокирован | |
| Предусловие: | |||
| Откройте сайт Про Тестинг: http://www.protesting.ru | Сайт Про тестинг открыт и доступен | ||
| Перейдите по ссылке "Задать вопрос" внизу страницы | Страница "Вопросы, пожелания и заявки" открыта и доступна | ||
| Шаги теста: | |||
| Заполните форму отправки комментария: "Тип Обращения": Комментарий "Контактное лицо": Ольга "E-mail": test@test.com "Сообщение": Добрый день, уважаемый коллектив "ПроТестинг"! Я еще ни разу не видела кач. примера баг-репорта, тест-кейса и прочей необходимой док-ии. Не подскажите, где я могу с ними ознакомиться? С уважением. | Данные успешно введены | ||
| Нажмите кнопку "Отправить" | Страница "Ваш запрос успешно отправлен!" открыта | ||
| Постусловие: | |||
| Кликните по ссылке "Перейти Назад на форму отправления заявок" | Страниц "Вопросы, пожелания и заявки" открыта | ||
Решение о виде тест кейса и детализации его описания принимает человек, ответственный за его создание - Тест Дизайнер или Тест Аналитик, обладающий необходимым опытом, и который знает тест дизайн не по наслышке и имеет опыт практического применения техник тест дизайна.
· Что снижает уровень затрат на подготовку документации?
Единый шаблон или подход к их написанию. Что предлагаем мы в части написания тест-кейсов- это структура PreConditions, Test Case Description, PostConditions, и уже ваше личное дело - пользоваться ею или придумать свой "велосипед".
Общие шаблоны предоставляют всем членам команды важную основу для сотрудничества. Когда каждый человек выполняет задачу своим способом, о сотрудничестве можно забыть.
Часто разработчик боится попросить помощи другого человека, потому что он может не согласиться с его подходом. А когда сотрудничества нет, такие различия в подходах могут препятствовать общему пониманию и накоплению знаний и опыта.
Виды деятельности по Контролю Качества (анализ, рецензии и тестирование) принесут больше пользы и будут более продуктивны, если продукт был сделан, используя общую модель.
Без их использования рецензенты и специалисты по тестированию просто будут пытаться отловить проблемы везде, где касалась рука разработчика. Такой бессистемный подход к Контролю Качества требует больше усилий и приводит к плохому покрытию и слабому обнаружению дефектов.
Общие шаблоны способствуют улучшению технической работы. Разработчик, выполняющий задачи своим собственным способом, может с легкостью пропустить важные детали или информацию. Когда работа стандартизирована, не возникает вопросов, что проделанная работа должна в себя включать.
Стандарты должны применяться при написании тест планов, спецификаций, пользовательских интерфейсов, документации, тренинговых материалов и других продуктов, т.к. общее видение того, как проект должен быть сделан, может помочь обеспечить его качество.
Но наряду со стандартами, необходимо определить ситуации их использования и разработать руководство по адаптации стандартов под нужды организации, если это необходимо. Любой стандарт, который вы принимаете, должен помочь вам выполнять свою работу как можно лучше и не должен связывать вам руки.
· Что такое Traceability Matrix?
Traceability matrix (полное название Requirement Traceability Matrix - RTM) - это матрица покрытия функциональных требований тест-кейсами.
Зачем нужна эта матрица? Например, для того чтобы:
- при разработке тестов четко ориентироваться какие из требований уже покрыты тестами, а какие еще нет;
- при выполнении тестирования ориентироваться какие из требований прошли все написанные для них тесты успешно, а какие - еще нет.
В системах для управления тестами (например, TestLink) имеется возможность перечислить требования, тест-кейсы, указать связи между ними и при выполнении тестов отслеживать в соответствующем репорте насколько полно реализованы требования в продукте.
· Что такое тест дизайн?
Тест дизайн – это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.
План работы над тест дизайном
· анализ имеющихся проектных артефактов: документация (спецификации, требования, планы), модели, исполняемый код и т.д.
· написание спецификации по тест дизайну (Test Design Specification)
· проектирование и создание тестовых случаев (Test Cases)
Ответственные за тест дизайн
- Тест аналитик - определяет "ЧТО тестировать?"
- Тест дизайнер - определяет "КАК тестировать?"
· Назовите основные техники тест дизайна
Разбивка на классы эквивалентности (Equivalence Partitioning - EP). Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала - 0.
Анализ Граничных Значений (Boundary Value Analysis - BVA). Если взять пример выше, в качестве значений для позитивного тестирования выберем минимальную и максимальную границы (1 и 10), и значения больше и меньше границ (0 и 11). Анализ Граничный значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.
Выделение причины / Следствия (Cause/Effect - CE). Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие). Например, вы проверяете возможность добавлять клиента, используя определенную экранную форму. Для этого вам необходимо будет ввести несколько полей, таких как "Имя", "Адрес", "Номер Телефона" а затем, нажать кнопку "Добавить" - эта "Причина". После нажатия кнопки "Добавить", система добавляет клиента в базу данных и показывает его номер на экране - это "Следствие".
Предугадывание ошибки (Error Guessing - EG). Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы "предугадать" при каких входных условиях система может выдать ошибку. Например, спецификация говорит: "пользователь должен ввести код". Тест аналитик, будет думать: "Что, если я не введу код?", "Что, если я введу неправильный код? ", и так далее. Это и есть предугадывание ошибки.
Исчерпывающее тестирование (Exhaustive Testing - ET) - это крайний случай. В пределах этой техники вы должны проверить все возможные комбинации входных значений, и в принципе, это должно найти все проблемы. На практике применение этого метода не представляется возможным, из-за огромного количества входных значений.
· Что такое тестовое покрытие?
Это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода (отношение количества контролируемых путей выполнения программного кода ко всем путям).
Чем выше требуемый уровень тестового покрытия, тем больше тестов будет выбрано, для проверки тестируемых требований или исполняемого кода.
Сложность современного программного обеспечения и инфраструктуры сделало невыполнимой задачу проведения тестирования со 100% тестовым покрытием и породило проблему дизайна тестового покрытия.
· Каковы техники формирования тестового покрытия?
Для разработки набора тестов, обеспечивающего более менее высокий уровень покрытия можно использовать специальные инструменты либо техники тест дизайна. Существует 2 широко применяемых подхода к оценке и измерению тестового покрытия:
· Покрытие требований (Requirements Coverage) - оценка покрытия тестами функциональных и нефункциональных требований к продукту путем построения матриц трассировки (traceability matrix).
· Покрытие кода (Code Coverage) - оценка покрытия исполняемого кода тестами, путем отслеживания непроверенных в процессе тестирования частей программного обеспечения.
Различия:
Метод покрытия требований сосредоточен на проверке соответствия набора проводимых тестов требованиям к продукту, в то время как анализ покрытия кода - на полноте проверки тестами, разработанной части продукта (исходного кода).
Ограничения:
Метод оценки покрытия кода не выявит нереализованные требования, так как работает не с конечным продуктом, а с существующим исходным кодом.
Метод покрытия требований может оставить непроверенными некоторые участки кода, потому что не учитывает конечную реализацию.
· Методы определения тестового покрытия?
Покрытие требований (Requirements Coverage)
Расчет тестового покрытия относительно требований проводится по формуле:
Tcov = (Lcov/Ltotal) * 100%
где:
Tcov - тестовое покрытие
Lcov - количество требований, проверяемых тест кейсами
Ltotal - общее количество требований
Для измерения покрытия требований, необходимо проанализировать требования к продукту и разбить их на пункты. Опционально каждый пункт связывается с тест кейсами, проверяющими его. Совокупность этих связей - и является матрицей трассировки. Проследив связи, можно понять какие именно требования проверяет тестовый случай.
Тесты не связанные с требованиями не имеют смысла. Требования, не связанные с тестами - это "белые пятна", т.е. выполнив все созданные тест кейсы, нельзя дать ответ реализовано данное требование в продукте или нет.
Покрытие кода (Code Coverage)
Расчет тестового покрытия относительно исполняемого кода программного обеспечения проводится по формуле:
Tcov = (Ltc/Lcode) * 100%
где:
Tcov - тестовое покрытие
Ltc - кол-ва строк кода, покрытых тестами
Lcode - общее кол-во строк кода.
В настоящее время существует инструментарий (например: Clover), позволяющий проанализировать в какие строки были вхождения во время проведения тестирования, благодаря чему можно значительно увеличить покрытие, добавив новые тесты для конкретных случаев, а также избавиться от дублирующих тестов.
Проведение такого анализа кода и последующая оптимизация покрытия достаточно легко реализуется в рамках тестирования белого ящика (white-box testing), при модульном, интеграционном и системном тестировании.
При тестировании же черного ящика (black-box testing) задача становится довольно дорогостоящей, так как требует много времени и ресурсов на установку, конфигурацию и анализ результатов работы, как со стороны тестировщиков, так и разработчиков.
· Способы оптимизации тестового покрытия
Для оптимизации тестового покрытия при тестировании на основании требований, наилучшим способом будет использование стандартных техник тест дизайна.
Приведем шаги оптимальной разработки тестовых случаев по имеющимся требованиям с использованием техники тест дизайна:
- Эквивалентное Разделение (Equivalence Partitioning), далее в тексте - EP
- Анализ Граничных Значений (Boundary Value Analysis), далее в тексте - BVA
- Предугадывание ошибки (Error Guessing), далее в тексте - EG
- Причина / Следствие (Cause/Effect), далее в тексте – CE
· План разработки тест кейсов
1. Анализ требований.
- Определение набора тестовых данных на основании EP, BVA, EG.
- Разработка шаблона теста на основании CE.
- Написание тест кейсов на основании первоначальных требований, тестовых данных и шагов теста.
· Пример разработки тест кейсов
Протестировать функциональность формы приема заявок, требования к которой предоставлены в следующей таблице:
| Элемент | Тип элемента | Требования |
| Тип обращения | combobox | Набор данных:
|
| Контактное лицо | editbox | 1. Обязательное для заполнения 2. Максимально 25 символов 3. Использование цифр и спец символов не допускается |
| Контактный телефон | editbox |
|
| Сообщение | text area | 1. Обязательное для заполнения 2. Максимальная длина 1024 символа |
| Отправить | button | Состояние: 1. По умолчанию - не активна (Disabled) 2. После заполнения обязательных полей становится активна (Enabled) Действия после нажатия 1. Если введенные данные корректны - отправка сообщения 2. Если введенные данные НЕ корректны - валидационное сообщение |
Вариант использования (иногда его может и не быть):
Анализ требований
Читаем, анализируем требования и выделяем для себя следующие нюансы: