Как представить свою работу другим

Katia_i45
26 мая 2016

Добрый день, коллеги.

Выбираем программу, чтобы вести тестовую документацию.

Ранее работала с программой testlink, хотела зайти на оф. сайт, вспомнить эту прогу, но сайт более не поддерживается.

Также наслышана про tarantul, у них проблемы с демо доступом аж с 2012 года.

Кто знает «живые» бесплатные проги?

Также рассматриваем и платные!

Какие у вас требования к учету тестовой документации?
Какая вообще у вас есть/будет тестовая документация?

возможность привязки чек-листов/тест-кейсов к определенной функциональности

прогон кейсов/чек-листов и назначения им статусов по прогону

взаимодействие с багтрекингом (у нас используется redmine)

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

хотелось бы видеть отчеты (с видами еще не определилась, но основной это по провальным кейсам)

из платных нашла TestRail, удобный, но дорогой, т. фиксирован период использования + кол-во пользователей, дорогая штука получается:

Freiman
26 мая 2016

Не совсем понял этот пункт. К чему именно должны быть привязаны тест-кейсы — требованиям? Или просто сгруппированы в что-то?

Можно пользоваться и тестлинком, вроде у него это все есть.

BadMF
26 мая 2016

Ну в тестлинке нет чек листов, чек лист это простите пара строчек в блокнотике. Использовать для этого тестлинк не совсем правильно. Хотя конечно можно использовать сущность тест кейса, а шаги как строки в чеклисте, но для каждой отдельной строки статус прохождения вы не поставите тогда.

Из бесплатных, тестлинк лучший выбор.

Если вы в нём и требования будете хранить, тогда и пункт 3 вполне реализуем. Но пока не ясна ваша инфраструктура, что-то конкретное сказать по этому пункту сложно.

Ну в тестлинке нет чек листов, чек лист это простите пара строчек в блокнотике. Использовать для этого тестлинк не совсем правильно. Хотя конечно можно использовать сущность тест кейса, а шаги как строки в чеклисте, но для каждой отдельной строки статус прохождения вы не поставите тогда. Из бесплатных, тестлинк лучший выбор. Если вы в нём и требования будете хранить, тогда и пункт 3 вполне реализуем. Но пока не ясна ваша инфраструктура, что-то конкретное сказать по этому пункту сложно.

Вы сталкивались с ней?

Нет. Учитывая, что она не обновлялась 2 года и, похоже, заброшена — не советую связываться.

у них на сайте чего-то не нашла какие есть различия между бесплатной Cominity edition и платной версией Enterprise

в демо доступе лежит лицензированная мобильная версия, а что будет в бесплатной. вопрос???

бывает у меня и такое!!

спасибо Вам большущее

BadMF
27 мая 2016

Вроде не плохая система.

Даже кастомные отчёты можно запилить при знании джавы. По функционалу сопоставима с тестлинком, не понятен только уровень интеграции с Джирой, у Тестлинка он самый простенький.

Freiman
27 мая 2016

Даже у супердорогого SilkCentral интеграция с Джирой недалеко ушла от TestLink 🙂

Требования

Речь здесь идет о тестировании требований всех уровней и видов: бизнес-требования, пользовательские требования, системные требования, функциональные требования, нефункциональные требования, требований производительности, требования удобства использования и т.

Мало того, что их надо тестировать. Тестировать требования необходимо на самых ранних этапах и/или стадиях процесса разработки (думаю, что Америки я не открыл). Начинать тестировать требования надо сразу, как только у вас появилась уникальная возможность получить к ним доступ, несмотря на то, где и в каком виде они находятся — в электронном виде, размещенные на общедоступном ресурсе, высланные вам по электронной почте или только что сформировавшиеся в голове консультанта/аналитика и еще не получившие формального отражения.

Если вы действительно радеете за результат, то обязательно постарайтесь привлечь к тестированию требований и ваших разработчиков, если самостоятельно они этого не делают, ошибочно полагая, что всем связанным с тестирование должны заниматься вы (т. тестировщики), а всем, связанным с требованиями, — консультанты и аналитики. Проанализировав требования с точки зрения внутренний архитектуры системы (программы) и кода, разработчики могут дать множество ценных советов и замечаний относительно того, что в требованиях написано не так или чего там не хватает.

Последствиями либо отсутствия тестирования требований вообще, либо откладывания тестирования требований до лучших времен или тезиса «все их недостатки выявятся в процессе разработки и тестирования» являются:

• выявление серьезных ошибок проектирования непосредственно перед выпуском релиза, что приводит к необходимости серьезных доработок, как требований, так и кода (я уже не говорю о доработке тест-кейсов, тестовых данных и повторном тестировании). Естественно, все это приводит к срыву сроков, авральной работе (по ночам и/или выходным) и прочим негативным вещам, которых можно было бы избежать своевременным тестированием требований;
• перекладывание всей ответственности и вины за случившееся на создателей требований, что по меньшей мере, не оздоровляет отношения между участниками разработки. Наверное, многие сталкивались с позицией программистов, аналогичной этим: «Не было написано, поэтому и не сделал», «Как написано, так и сделал», «Писать надо лучше» и т.п.

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

В заключении заметки о тестировании требований еще раз осмелюсь повторить критерии качества требований к программному обеспечению:

• Корректность
• Недвусмысленность (однозначность)
• Полнота
• Непротиворечивость (совместимость)
• Упорядоченность (ранжированность по важности и стабильности)
• Проверяемость (тестируемость или тестопригодность)
• Модифицируемость
• Трассируемость (прослеживаемость)
• Понятность

Тест- кейсы

Для лучшего понимания раздела, посвященного тест-кейсам, приведу здесь определение этих самых тест-кейсов, которое предлагает энциклопедия Wikipedia (прошу прощения за мой вольный перевод).

Тест-кейс (тестовый случай, test case) — это набор условий и/или переменных, с помощью которых тестировщик будет определять насколько полно тестируемое приложение удовлетворяет предъявляемому к нему требованию. Для того, чтобы убедиться, что требование полностью удовлетворяется, может понадобиться несколько тест-кейсов. Для полного тестирования всех требований, предъявляемых к приложению, должен быть создан/выполнен по меньшей мере один тест-кейс для каждого требования. Если требование имеет дочерние требования, то для каждого такого дочернего требования должен быть создан/выполнен также по крайней мере один тест-кейс. Некоторые методологии (например, RUP) рекомендуют создавать по меньшей мере два тест-кейса для каждого требования. Один из них должен выполнять позитивное тестирование, другой — негативное.

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

Что формально характеризует написанный тест-кейс? Наличие известного ввода (входные данные) и ожидаемого результата, который достигается после выполнения теста. Входные данные называются предусловиями теста, а ожидаемый результат — постусловиями теста.

Написанные тест-кейсы часто объединяются в тестовые наборы (test suite).

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

Тест-кейсы необходимо писать по требованиям

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

Одним из определений качественного продукта (не обязательного программного) является то, на сколько данный продукт удовлетворяет предъявляемым к нему требованиям. Исходя из такого подхода к качественному продукту, можно дать следующее определение тестированию. Тестирование — это процесс проверки соответствия продукта предъявляемым к нему требованиям. в процессе тестирования программного продукта мы определяем соответствует ли то, что написали программисты, тому, что написали консультанты и аналитики (формализовав требования и пожелания Заказчика).

Данное определение ни в коем случае не претендует на полноту и описывает процесс тестирования только с одной стороны. С той стороны, которая повернута к требованиям. Именно поэтому не стоит расценивать все, что будет написано дальше, как исчерпывающую инструкцию по написанию тест-кейсов.

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

Что же делают наиболее изобретательные тестировщики? При написании тест-кейсов они пытаются заручиться поддержкой программистов, а если еще точнее, то они пытаются как можно быстрей получить готовую реализацию продукта и писать все тест-кейсы, опираясь на реализованный продукт, т. это по их мнению объективно проще и понятней. Это крайне неправильно!

В этом случае получается, что в процессе тестирования проверяется соответствие разработанного продукта разработанному продукту (вот такой каламбурчик). Сами можете представить себе, что из этого получается.

Поэтому, резюмирую все описанное выше — базисом для подготовки тест-кейсов должны быть требования (в том или ином виде), а ни в коем случае не готовый продукт.

Тест-кейсы должны не повторять требования, а проверять их

Лень. Она является как источником великих прорывов и открытий, так и причиной, которая делает бессмысленной проделанную работу, проведенного впустую времени. Осмысленность любому начинанию, любой работе придает результат (желательно, конечно, положительный), ради которого эта работа задумывалась и выполнялась.

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

Что я имею в виду, когда пишу, что тесты должны не повторять требования, а проверять их?

Поясню на простых (естественно, выдуманных, чтобы читатели не краснели, при виде своих собственных творений) примерах.

Есть одно из функциональных требований к системе, для которого необходимо написать тест-кейсы: Значение в поле «Сумма» должно рассчитываться как сумма значений из полей «A» и «B».

Тест-кейс, написанный ленивым тестировщиком:

Ввести значения в поля «A» и «B».

Значение в поле «Сумма» должно рассчитываться как сумма значений из полей «А» и «B». (Иногда еще также в графе с ожидаемым результатом встречаются такие «шедевры» как: См. в ТЗ, в соответствии с ТЗ, наблюдаем ожидаемые значения и т.

Тест-кейс, написанный неленивым тестировщиком:

Нажать на кнопку «Рассчитать»

Чем второй тест-кейс лучше первого?

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

Далее, если речь идет о приемочных тест-кейсах, которые должны обязательно выполнить разработчики перед тем, чтобы передать версию на тестирование, то здесь в случае с первым тест-кейсом вообще все плохо. реакция разработчика на такой тест-кейс такова (сужу по своему собственному опыту): «Я же и так все делал по требованиям, поэтому должно все работать, как я и сделал. Тем более я когда-то проверял, что 2 + 2 = 4». И разработчик со спокойной совестью ставит Pass и переходит к следующему тест-кейсу (который наверняка будет таким же неоднозначным :)).

Приведенный пример с суммированием, конечно же, очень примитивен для простоты понимания, но на практике часто приходится сталкиваться с тем, что менее очевидные вещи, чем A + B, описываются в тест-кейсах аналогичным образом и не приносят ожидаемого результата, т. проверки какого — либо требования. И в силу этого, после выкладки тестовой версии кажущиеся на первый взгляд очевидными (позитивные) тесты проваливаются.

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

Написание приемочных тест-кейсов (по определенным правилам)

В предыдущих заметках я уже упоминал о приемочных тестах, которые подготавливают тестировщики для принятия на тестирование очередной тестовой версии приложения.

Проясню немного ситуацию. На проекте сложилась классическая ситуация, описанная еще когда-то господином Канером, когда с появлением выделенного тестирования разработчики расслабляются и абсолютно перестают тестировать свои бесценные творения. Доходит даже до того, что написав что-то (или исправив очередную ошибку в коде) они даже не удосуживаются посмотреть, что же в результате их писательства получилось, а с легкой руки передают на тестирование. Спасибо, что хоть привычка компилировать еще сохранилась!

Для пресечения такой ситуации было перепробовано множество различных способов и методов, начиная с дружеского разъяснения, проведения обучающих семинаров, написания чек-листов и памяток для разработчиков и заканчивая различными степенями наказания (насколько позволяет корпоративная культура), но ничего не помогало. Поэтому было решено подготавливать некоторые наборы приемочных тест-кейсов для разработчиков, которые они в обязательном порядке должны прогонять на системе для разработке перед выкладкой тестовой версии. Обязательным условием выкладки тестовой версии является 100% Pass приемочных тест-кейсов. После выкладки тестовой версии тестировщики начинают свою работу с повторного прогона того же самого приемочного набора для проверки того, что разработчики действительно выполнили все тест-кейсы (а не просто проставили отметки). Я здесь не вдаюсь в технические детали всей этой процедуры. По результатам такой проверки тестировщиками происходит разбор полетов, после которого кто-то получает прянички, а кто-то кнуты.

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

Парочку таких правил я уже написал в предыдущем пункте: тест-кейсы (в том числе и приемочные) должны проверять требования, а не повторять их и тест-кейсы должны быть однозначными, т. максимально одинаково пониматься как тестировщиками, так и разработчиками. Здесь о другом.

Первое и, на мой взгляд, самое главное — при написании тест-кейсов (а особенно приемочных) тестировщик должен осознать, что данные тест-кейсы предназначены не для него самого, а для другого человека. И писать их, соответственно, необходимо максимально подробно и максимально понятно даже не для посвященного в бизнес-логику приложения человека.

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

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

Сокращенно звучит он так — один тест-кейс — одна проверка.

Как реагировать на следующий тест-кейс?

Каждому номеру действия необходимо сопоставлять соответствующий номер ожидаемого результата? Или же после выполнения полностью всех действий мы получим результат, состоящий из четырех пунктов? А может быть как — то еще?

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

И это не голая теория, а реальные вопросы, которые мне задают разработчики, которые выполняют таким образом составленные тест-кейсы.

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

Своевременность отметок о прохождении/сбое тест-кейсов

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

В нашем случае цель проста — в любой момент времени отслеживать текущую ситуацию по процессу выполнения тест-кейсов:

• процент выполнения от общего запланированного количества;
• количество успешно пройденных тест-кейсов;
• количество проваленных тест-кейсов;
• и другие производные от них метрики.

Чтобы получать объективную информацию, необходимо, чтобы в каждый момент времени данные о выполнении тест-кейсов были актуальными. Для этого необходимо, чтобы сразу же после прогона тест-кейса тестировщик проставлял соответствующую отметку.

Чаще всего тестировщики не проставляют отметки сразу же, откладывая на потом, когда полностью закончат тестирование. Какие я вижу минусы в этом подходе:

Нет оперативной информации о том, на каком этапе в данный момент находится тестирование и, следовательно, совершенно не понятно укладывается тестирование в отведенные сроки или необходимы корректирующие действия.

Выполнив 125 тест-кейсов тестировщик вряд ли точно вспомнит, какие тест-кейсы прошли успешно, а какие нет.

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

Поэтому давайте делать все в свое время! Как говорится: «Дорога ложка к обеду».

Стандартные атрибуты тест-кейса

• Номер —  уникальный идентификатор тест-кейса. Его удобно использовать для одинакового понимания, о какой проверке идет речь (например, дать ссылку в баге).
• Шаги — описание действий, необходимых для проверки (например, создание элемента).
• Ожидаемый результат (ОР) — сама проверка: что мы ожидаем получить после выполнения шагов («Элемент создан»).

Преимущества и недостатки тест-кейсов

Преимущества: тест-кейсы можно доверить выполнять новичку или призванному на помощь коллеге из другого отдела, который ничегошеньки о проекте не знает. Дополнительных вопросов с его стороны будет по минимуму — все и так (должно быть  ) понятно!

Недостатки (вытекают один из другого):

• Очень много копипасты много копипасты копипасты. В примере выше заполняется поле «ФИО». Тест-кейсы «ввести в поле только символы, только числа, строку нулевой длины и т. д.» будут очень похожи друг на друга, первые шаги одинаковые и, положа руку на сердце, будут копипаститься. Попробуйте написать хотя бы три тест-кейса на один функционал и сразу увидите эту проблему.
• Сложно поддерживать. Представьте, что вкладку «Жильцы» переименовали в «Заказчики». Чтобы актуализировать тест-кейсы, надо внести изменения в сотни сценариев, что утомительно даже в режиме «Ctrl + C, Ctrl + V».
• Неактуальное состояние. Тест-кейсы копипастятся друг от друга, и часто в них остаются неактуальные части из исходного кейса, которые забыли изменить.

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

Чтобы тест-кейсы честно выполняли свою роль, их надо поддерживать, периодически проверять на правильность и дорабатывать. Это отнимает очень много времени и сил.

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

Стандартные ошибки при оформлении тест-кейсов

Читать теорию — одно, делать на практике — другое. Обычно в теории все понятно, а на практике получаем примерно такой кейс (все совпадения случайны, тест-кейс написан как агрегация различных ошибок):

Тест-кейс № 01. Создание жильца.

• Зайди на сайт www.test.ru.
• Перейди на вкладку «Жильцы».
• Нажми на кнопку «Создать карточку жильца».
• Введи корректные ФИО, например, «Иванов Иван Иванович» и сохрани карточку.

Ожидаемый результат — карточка создана.

Попробуйте, не смотря ответ, сами найти проблемные зоны в этом тест-кейсе. А потом проверите себя

Абстрактное названиеНа первый взгляд название хорошее, короткое и понятное — мы ведь правда создаем жильца. Но! Если мы теперь создадим еще пяток тест-кейсов на ввод некорректных ФИО, то у них будет точно такое же название. В итоге новый тестировщик, получив задание проверить кейс «Создание жильца», обнаружит в системе два десятка проверок с таким названием и впадет в ступор, какой выбирать?Всегда помните про «кратко, но емко». По названию тест-кейса тестировщик, знающий проект, должен понять, что надо делать, не заглядывая в шаги. Так что дополняем название — Создание жильца без отчества, Создание жильца, цифры в поле «Имя» и т.

Повелительное наклонениеЧтобы коллегам было приятнее работать с тест-кейсами, лучше делать их описание обезличенным — «Выполнить, загрузить».

PRODВ данном примере идет ссылка на PROD. Никогда нельзя проводить тестирование на PROD-е! Исключение составляет дымовой тест, проводящийся после обновления PROD-системы. Тестовый набор для этого создается отдельно и тщательно выверяется. ВСЕ остальное тестирование проводится ТОЛЬКО на тестовом стенде. В описании тест-кейсов и багов должны быть ссылки только на тестовый сервер. Иначе попросим коллегу с другого проекта помочь нам с тестированием, а он пойдет на PROD и. или сломает что-то, или испортит реальные данные.

Нет ссылки на сайтНаписан URL, но не кликабельный. Нужно выделить, скопировать, открыть новую страницу, вставить. Гораздо лучше было бы просто нажать на него!

Нет описания проверки»Карточка создана» — кратко, но не емко. Не имея знаний о проекте, тестировщик может только предполагать, что включает в себя этот пункт. Достаточно ли того, что карточка закрылась без ошибок? Или она должна теперь отображаться в списке карточек? А сколько в системе таких списков? Должна ли система отображать введенные данные, если открыть карточку на просмотр? Что конкретно нужно проверять?Поправим тест-кейс по всем замечаниям. Вот что получилось:

Тест-кейс № 02. Создание жильца с корректными ФИО.

• Зайти на сайт .
• Перейти на вкладку «Жильцы»
• Нажать на кнопку «Создать карточку жильца».
• Ввести корректные ФИО, например, «Иванов Иван Иванович».
• Нажать на кнопку «Сохранить».

Ожидаемый результат1. Окно с информацией о жильце закрывается и отображается общий список, в котором присутствует новая карточка. Эту карточку можно открыть. В открытой карточке отображаются введенные данные, то есть в поле ФИО указано «Иванов Иван Иванович».

Уже хорошо, но можно ли еще улучшить этот тест-кейс?

Сейчас снова попробуйте, не смотря ответ, найти проблемные зоны в этом тест-кейсе. А потом проверите себя

Итак, ошибки кейса 02:

Абстрактное название. Слова «корректный», «правильный» ит. в названии тест-кейса такой же маркер, как «ошибка» в названии бага. Таких слов надо избегать. Позитивных проверок можно придумать хоть сто. Но чем-то они будут различаться. «Создание жильца, у которого нет отчества», — это тоже кейс с корректным ФИО. Только из такого названия сразу ясно, про что кейс. Поэтому забудьте про слова «корректный», «некорректный» и т. , пытайтесь писать понятнее. И всегда помните принцип «кратко, но емко». А разделение кейсов на смысловые группы (негативные тесты, позитивные тесты, тесты на особые случаи) сделайте в системе управления тест-кейсами через флаги или отдельные наборы тестов.

Тест-кейс № 03. Создание жильца с полным ФИО.

• Перейти на вкладку «Жильцы»
• Нажать на кнопку «Создать карточку жильца».
• Ввести корректные ФИО, например, «Иванов Иван Иванович».
• Нажать на кнопку «Сохранить».

Определения из книг по тестированию

Ron Patton. Software Testing.

Тест-кейсы перечисляют конкретные вещи, которые будут протестированы, и описывают детальные шаги, которые необходимо выполнить для проверки программного обеспечения.

Lee Copeland. A Practitioner’s Guide to Software Test Design.

• Test case specification identifier — A unique identifier so that this document can be distinguished from all other documents.
• Test items — Identifies the items and features to be tested by this test case.
• Input specifications — Specifies each input required by this test case.
• Output specifications — Specifies each output expected after executing this test case.
• Environmental needs — Any special hardware, software, facilities, etc. required for the execution of this test case that were not listed in its associated test design specification.
• Special procedural requirements — Defines any special setup, execution, or cleanup procedures unique to this test case.
• Intercase dependencies — Lists any test cases that must be executed prior to this test case.

Цель спецификации тест-кейсов — описать в деталях каждый тест-кейс. Она состоит из следующих секций:

• Идентификатор тест-кейса — уникальный идентификатор, благодаря которому данный документ может быть отличен от остальных.
• Элементы теста — идентифицирует элементы и фичи, которые необходимо протестировать по этому кейсу.
• Входные данные — описывает каждое входное значение, необходимое для выполнения тест-кейса.
• Выходные данные — описывает каждый результат, ожидаемый после выполнения тест-кейса.
• Окружение — любое специальное аппаратное, программное обеспечение, аппаратура и т.д., необходимое для выполнения тест-кейса и не перечисленное в документации по тест-дизайну (верхнеуровневая документация).
• Особые процедурные требования — описывает любые специальные действия по подготовке к тесту, его выполнению или очистке системы после выполнения кейса.
• Зависимости — список любых тест-кейсов, которые должны быть выполнены перед данным кейсом.

Гленфорд Майерс, Искусство тестирования программ

Любой тест должен включать две составляющие:

• описание входных данных программы;
• точное описание корректных выходных данных для каждого набора входных данных.

На этом, пожалуй, все

Игра не запускается

Игра вылетает на рабочий стол без ошибок. О: Скорее всего проблема в поврежденных файлах игры. В подобном случае рекомендуется переустановить игру, предварительно скопировав все сохранения. В случае если игра загружалась из официального магазина за сохранность прогресса можно не переживать.

CASE: Animatronics не работает на консоли. О: Обновите ПО до актуальной версии, а так же проверьте стабильность подключения к интернету. Если полное обновление прошивки консоли и самой игры не решило проблему, то стоит заново загрузить игру, предварительно удалив с диска.

Ошибка 0xc000007b.

О: Есть два пути решения. Первый — полная переустановка игры. В ряде случаев это устраняет проблему. Второй состоит из двух этапов:

Ошибка 0xc0000142.

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

Ошибка 0xc0000906.

О: Данная ошибка связана с блокировкой одного или нескольких файлов игры антивирусом или “Защитником Windows”. Для её устранения необходимо добавить всю папку игры в исключени. Для каждого антивируса эта процедура индивидуально и следует обратиться к его справочной системе. Стоит отметить, что вы делаете это на свой страх и риск. Все мы любим репаки, но если вас часто мучает данная ошибка — стоит задуматься о покупке игр. Пусть даже и по скидкам, о которых можно узнать из новостей на нашем сайте.

Отсутствует msvcp 140. dll/msvcp 120. dll/msvcp 110. dll/msvcp 100. dll

О: Ошибка возникает в случае отсутствия на компьютере корректной версии пакета Microsoft Visual C++, в который и входит msvcp 140. dll (и подобные ему). Решением будет установка нужной версии пакета.

После загрузки и установки нового пакета ошибка должна пропасть. Если сообщение об отсутствии msvcp 140. dll (120, 110, 100) сохраняется необходимо сделать следующее:

Ошибка 0xc0000009a/0xc0000009b/0xc0000009f и другие О: Все ошибки начинающиеся с индекса 0xc0000009 (например 0xc0000009a, где на месте “а” может находиться любая буква или цифра) можно отнести к одному семейству. Подобные ошибки являются следствием проблем с оперативной памятью или файлом подкачки.

Размер файла подкачки должен быть кратен 1024. Объём зависит от свободного места на выбранном локальном диске. Рекомендуем установить его равным объему ОЗУ. Если ошибка 0xc0000009а сохранилась, необходимо проверить вашу оперативную память. Для этого нужно воспользоваться функциями таких программ как MemTest86, Acronis, Everest.

Игра тормозит и лагает

Скорее всего данная проблема носит аппаратный характер. Проверьте системные требования игры и установите корректные настройки качества графики. Подробнее об оптимизации игры можно почитать на форуме. Также загляните в раздел файлов, где найдутся программы для оптимизации CASE: Animatronics для работы на слабых ПК. Ниже рассмотрены исключительные случаи.

Появились тормоза в игре. О: Проверьте компьютер на вирусы, отключите лишние фоновые процессы и неиспользуемые программы в диспетчере задач. Также стоит проверить состояние жесткого диска с помощью специализированных программ по типу Hard Drive Inspector. Проверьте температуру процессора и видеокарты —возможно пришла пора обслужить ваш компьютер.

Долгие загрузки в игре. О: Проверьте состояние своего жесткого диска. Рекомендуется удалить лишние моды — они могут сильно влиять на продолжительность загрузок. Проверьте настройки антивируса и обязательно установите в нём “игровой режим” или его аналог.

CASE: Animatronics лагает. О: Причинами периодических тормозов (фризов или лагов) в CASE: Animatronics могут быть запущенные в фоновом режиме приложения. Особое внимание следует уделить программам вроде Discord и Skype. Если лаги есть и в других играх, то рекомендуем проверить состояние жесткого диска — скорее всего пришла пора заменить его.

Ошибки загрузки/обновления

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

Если магазин или лончер CASE: Animatronics не завершает обновления или выдает ошибки, то переустановите саму программу. При этом все скачанные вами игры сохранятся.

Запустите проверку целостности данных игры.

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

Проверьте настройки антивируса и “Защитника Windows”, а также разрешения в брандмауэре. Вполне возможно они ограничивают подключение к интернету для ряда приложений. Данную проблему можно решить и полной переустановкой магазина или лончера т. большинство из них попросит предоставить доступ к интернету в процессе инсталляции.

О специфических ошибках связанных с последними обновлениями можно узнать на форуме игры.

Системные требования CASE

Второе, что стоит сделать при возникновении каких-либо проблем с CASE: Animatronics, это свериться с системными требованиями. По-хорошему делать это нужно еще до покупки, чтобы не пожалеть о потраченных деньгах.

Минимальные системные требования CASE: Animatronics:

Windows 7, Процессор: Intel Core2 Quad Q8400, 512 MB ОЗУ, 1 GB HDD, NVIDIA GeForce GTX 560 Видеопамять: 1GB, DirectX 10, Клавиатура, мышь

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

Файлы, драйверы и библиотеки

Практически каждое устройство в компьютере требует набор специального программного обеспечения. Это драйверы, библиотеки и прочие файлы, которые обеспечивают правильную работу компьютера.

Начать стоит с драйверов для видеокарты. Современные графические карты производятся только двумя крупными компаниями — Nvidia и AMD. Выяснив, продукт какой из них крутит кулерами в системном блоке, отправляемся на официальный сайт и загружаем пакет свежих драйверов:

Фоновые процессы всегда влияют на производительность. Вы можете существенно увеличить FPS, очистив ваш ПК от мусорных файлов и включив специальный игровой режим с помощью программы Advanced System Optimizer

CASE 2: Animatronics Survival не работает на консоли. О: Обновите ПО до актуальной версии, а так же проверьте стабильность подключения к интернету. Если полное обновление прошивки консоли и самой игры не решило проблему, то стоит заново загрузить игру, предварительно удалив с диска.

Скорее всего данная проблема носит аппаратный характер. Проверьте системные требования игры и установите корректные настройки качества графики. Подробнее об оптимизации игры можно почитать на форуме. Также загляните в раздел файлов, где найдутся программы для оптимизации CASE 2: Animatronics Survival для работы на слабых ПК. Ниже рассмотрены исключительные случаи.

CASE 2: Animatronics Survival лагает. О: Причинами периодических тормозов (фризов или лагов) в CASE 2: Animatronics Survival могут быть запущенные в фоновом режиме приложения. Особое внимание следует уделить программам вроде Discord и Skype. Если лаги есть и в других играх, то рекомендуем проверить состояние жесткого диска — скорее всего пришла пора заменить его.

Если магазин или лончер CASE 2: Animatronics Survival не завершает обновления или выдает ошибки, то переустановите саму программу. При этом все скачанные вами игры сохранятся.

Ошибки входа в игру

Проверьте соединение с интернетом, а также убедитесь в том, что у вас установлены последние обновления. Проверьте настройки вашего антивируса — вполне возможно что в данный момент он ограничивает доступ к интернету для ряда приложений. Может быть игра готовится к выходу большого обновления? Или ошибка не только у вас? Обязательно проверьте последние новости по игре, а так же загляните на форум, чтобы обсудить проблему с другими игроками.

Черный экран и вылет при попытке зайти в игру. О: Если вы используете VPN, то с большей долей вероятности проблема именно в нём. Попробуйте изменить его настройки или временно отключить. Рекомендуется сменить регион в самой игре (если такая возможность предусмотрена). Спустя какое-то время можно будет вернуться к привычным настройкам.

“Недействительная сессия” и аналогичные. О: Перезапустите лончер и дождитесь его повторного подключения к серверам. Если это не помогло — потребуется перезапуск компьютера и роутера. Если и в этом случае проблема не исчезла стоит обратиться на форум — скорее всего ошибка носит массовый характер.

CASE 2: Animatronics Survival не подключается к серверу. О: Скорее всего, сервер игры перегружен или конкретное лобби не доступно в данный момент. Попробуйте обновить список доступных серверов или просто перезапустить игру.

Обязательно обновите драйвера видеокарты и другое ПО

Важно помнить, что следует загружать только окончательные версии видеокарт – старайтесь не использовать бета-версии, так как в них может быть большое количество не найденных и не исправленных ошибок.

Animatronics Survival не запускается

Многие проблемы с запуском игр случаются по причине некорректной установки. Проверьте, не было ли ошибок во время установки, попробуйте удалить игру и запустить установщик снова, предварительно отключив антивирус – часто нужные для работы игры файлы по ошибке удаляются. Также важно помнить, что в пути до папки с установленной игрой не должно быть знаков кириллицы – используйте для названий каталогов только буквы латиницы и цифры.

Еще не помешает проверить, хватает ли места на HDD для установки. Можно попытаться запустить игру от имени Администратора в режиме совместимости с разными версиями Windows.

Animatronics Survival тормозит. Низкий FPS. Лаги. Фризы. Зависает

Первое – установите свежие драйвера на видеокарту, от этого FPS в игре может значительно подняться. Также проверьте загруженность компьютера в диспетчере задач (открывается нажатием CTRL+SHIFT+ESCAPE). Если перед запуском игры вы видите, что какой-то процесс потребляет слишком много ресурсов – выключите его программу или просто завершите этот процесс из диспетчера задач.

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

Animatronics Survival вылетает на рабочий стол

Если CASE 2: Animatronics Survival у вас часто вылетает на рабочий слот, попробуйте начать решение проблемы со снижения качества графики. Вполне возможно, что вашему компьютеру просто не хватает производительности и игра не может работать корректно. Также стоит проверить обновления – большинство современных игр имеют систему автоматической установки новых патчей. Проверьте, не отключена ли эта опция в настройках.

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

Если с железом все нормально, и оно удовлетворяет минимальным требованиям – попробуйте переключиться на другое окно (ALT+TAB), а потом вернуться к окну игры.

Animatronics Survival не устанавливается. Зависла установка

Прежде всего проверьте, хватает ли у вас места на HDD для установки. Помните, что для корректной работы программы установки требуется заявленный объем места, плюс 1-2 гигабайта свободного пространства на системном диске. Вообще, запомните правило – на системном диске всегда должно быть хотя бы 2 гигабайта свободного места для временных файлов. Иначе как игры, так и программы, могут работать не корректно или вообще откажутся запуститься.

Проблемы с установкой также могут произойти из-за отсутствия подключения к интернету или его нестабильной работы. Также не забудьте приостановить работу антивируса на время установки игры – иногда он мешает корректному копированию файлов или удаляет их по ошибке, считая вирусами.

Animatronics Survival не работает управление

Иногда управление в игре не работает из-за одновременного подключения нескольких устройств ввода. Попробуйте отключить геймпад или, если по какой-то причине у вас подключено две клавиатуры или мыши, оставьте только одну пару устройств. Если у вас не работает геймпад, то помните – официально игры поддерживают только контроллеры, определяющиеся как джойстики Xbox. Если ваш контроллер определяется иначе – попробуйте воспользоваться программами, эмулирующими джойстики Xbox (например, x360ce).

Не работает звук в CASE 2

Проверьте, работает ли звук в других программах. После этого проверьте, не отключен ли звук в настройках самой игры и выбрано ли там устройство воспроизведения звука, к которому подключены ваши колонки или гарнитура. Далее следует во время работы игры открыть микшер и проверить, не отключен ли звук там.

Если используете внешнюю звуковую карту – проверьте наличие новых драйверов на сайте производителя.

Глючит или не запускается CASE: Animatronics? Решение есть! Постоянные лаги и зависания — не проблема! После установки мода CASE: Animatronics начала глючить или НПС не реагируют на завершение задания? И на этот вопрос найдется ответ! На этой странице вы сможете найти решение для любых известных проблем с игрой и обсудить их на форуме.