Мои Конспекты
Главная | Обратная связь

...

Автомобили
Астрономия
Биология
География
Дом и сад
Другие языки
Другое
Информатика
История
Культура
Литература
Логика
Математика
Медицина
Металлургия
Механика
Образование
Охрана труда
Педагогика
Политика
Право
Психология
Религия
Риторика
Социология
Спорт
Строительство
Технология
Туризм
Физика
Философия
Финансы
Химия
Черчение
Экология
Экономика
Электроника

Еще правила, которых нужно придерживаться





Помощь в ✍️ написании работы
Поможем с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой

§ необходимо в каждом тесте уделять внимание процедуре приведения объекта тестирования в некую исходную позицию до прохождения теста и, если это рационально, его возврата в эту же позицию после прохождения теста — это дает возможность запускать тесты независимо, в любом нужном порядке, не заботясь о том, в каком состоянии объект остался после предыдущего теста;

§ при этом следует определить оптимальные стартовые позиции/состояния объекта тестирования для всех тестов, чем их получится меньше, тем лучше (меньше усилий и времени для подготовки объекта к новому тесту и больше удобства при группирования тестов);

§ количество шагов нужно оптимизировать, иногда в одном шаге можно объединить несколько, если нам важен промежуточный результат только последнего из них, однако, если уверенности нет, лучше описать лишнее, чем пропустить ключевой шаг;

§ упорядочивать тесты в тест-плане желательно последовательно по отношению к функциональности объекта тестирования, двигаясь от тестов первых действий или экранов объекта (например, запуска самой программы) до последних (например, ее закрытия);

§ тестер не должен придумывать спецификации и термины, которые нигде пока не описаны и не применяются в требованиях, не должен использовать условности из своей жизни (например, «phone receives the call» не обязательно соответствует фразе «телефон звонит», а «open the door» не всегда означает, что дверь открывается именно поворотом ручки), такое придумывание может привести к написанию неверных тестов;

§ раздел тест-плана «Open Issues» (открытые вопросы, нюансы) используется для того, чтобы собрать в одном месте отсутствующие в требованиях данные, запросы на уточнения, без которых нельзя написать некоторые тест-кейсы;

§ главное в конструировании тестов — руководствоваться здравым смыслом и интуицией, если есть ощущение, что в каком-то случае имеет смысл нарушить правила, нужно их нарушить.

 

Общие разделы

Тест-план как и другая документация должен содержать помимо полезной информации (описания тестов) некую второстепенную, придающую ему официальный и формальный статус. Как правило, такой информацией общего характера является набор следующих разделов:

§ описание документа (document description), зачем и для кого он нужен, к чему имеет отношение —
в нашем случае там описывается следующее: вкратце об объекте тестирования (object of testing); список родственных документов (related documents), в нем как минимум ссылка на Требования и Тест-отчеты; глоссарий (glossary) — расшифровка терминов и обозначений; указание границ, глубины документа (scope) — что документ описывает хорошо, что лишь упоминает, а что не описывает вообще (например, он может не описывать подробно все параметры функций и не содержать историю версий продукта, в этом случае будет уместна ссылка на документ, который описывает упущенное лучше); открытые вопросы (open issues), которые нужно обсудить и определить до такого-то этапа тестирования;

§ условия тестирования (test conditions) — обычно это программная (software) и аппаратная (hardware) конфигурация, при которой данный тест-план считается верным и годным к применению, и ограничения (restrictions), сужающие область ответственности для данной версии тест-плана (например, следующие версии продукта не могут быть протестированы некоторой частью тестов);

§ другие особенности тестирования (other issues), здесь уместно упоминание об используемой системе регистрации и ведении истории найденных в процессе тестирования ошибок (bug tracking system) и еще каких-то относительно важных моментов;

§ список функциональности, которая не будет протестирована вообще (not to be tested) и почему (чаще всего это идентификаторы Требований, которые не поддаются покрытию тестами или поддаются слишком трудно, что делает нерациональным их покрытие);

§ возможны другие разделы, например, отказ от ответственности (disclaimer), копирайт (авторские права) и прочее.

Описание тестов, разделение их на группы (тест-сьюты)

Это самая важная часть документа, а точнее, он сам и есть. Здесь после возможного вступления, разъяснения принятого стиля описания тестов и находится весь набор тестов, разделенный на тест-кейсы (test cases) и тест-сьюты (test suites).

Последнее понятие применяется в случае, если набор всех тест-кейсов планируется разделить на отдельные группы (сьюты), а не проходить каждый раз все тесты подряд. Например, имеет смысл создать тест-сьют для быстрого тестирования самой важной функциональности (sanity testing suite) с целью быстро оценить стабильность новой сборки, для стрессового тестирования (abusive или stress testing suite) и другие сьюты, подходящие для конкретной ситуации с конкретным объектом тестирования.

В некоторых случаях тест-сьюты могут содержать так называемые случаи применения (use cases) — это как правило комплексные тест-кейсы высокого уровня, то есть, реальные случаи применения продукта пользователем, описание целой процедуры работы с отдельной функцией продукта тестирования, а не проверка отдельного элемента этой функции. Например, если объект тестирования — телефонный терминал, то совершить звонок (дозвониться, побыть в состоянии соединения, закончить звонок) — это случай применения (use case), а убедиться, что при «поднятии» трубки слышен гудок или включается подсветка клавиатуры, — это тестовый случай (test case), то есть, тестирование системы на низком уровне, а не на пользовательском.

Необязательно тест-сьюты должны содержать уникальный набор тестов, иногда какие-то тест-кейсы, если они в чем-то универсальны, могут входить в состав нескольких тест-сьютов. А бывает даже, что тест-сьюты вмещают в себя другие тест-сьюты.

Главное, чтобы организация тестов подчинялась здравому смыслу, была понятна и максимально удобна для тестировщика, который будет с ней работать. Поэтому нужно оценить ее с точки зрения выполнения тестирования.

Доверь свою работу ✍️ кандидату наук!
Поможем с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой



Поиск по сайту:







©2015-2020 mykonspekts.ru Все права принадлежат авторам размещенных материалов.