В данной инструкции изложены основные функции сайта, и как ими пользоваться
Здравствуйте,
Вы находитесь на странице инструкции сайта Тестсмарт.
Прочитав инструкцию, Вы узнаете функции каждой кнопки.
Мы начнем сверху, продвигаясь вниз, слева направо.
Обращаем Ваше внимание, что в мобильной версии все кнопки располагаются, исключительно сверху вниз.
Итак, первый значок, находящийся в самом верхнем левом углу, логотип сайта. Нажимая на него, не зависимо от страницы, попадете на главную страницу.
«Главная» - отправит вас на первую страницу.
«Разделы сайта» - выпадет список разделов, нажав на один из них, попадете в раздел интересующий Вас.
На странице билетов добавляется кнопка "Билеты", нажимая - разворачивается список билетов, где выбираете интересующий вас билет.
«Полезные ссылки» - нажав, выйдет список наших сайтов, на которых Вы можете получить дополнительную информацию.
В правом углу, в той же оранжевой полосе, находятся белые кнопки с символическими значками.
- Первая кнопка выводит форму входа в систему для зарегистрированных пользователей.
- Вторая кнопка выводит форму обратной связи через нее, Вы можете написать об ошибке или просто связаться с администрацией сайта.
- Третья кнопка выводит инструкцию, которую Вы читаете. :)
- Последняя кнопка с изображением книги (доступна только на билетах) выводит список литературы необходимой для подготовки.
Опускаемся ниже, в серой полосе расположились кнопки социальных сетей, если Вам понравился наш сайт нажимайте, чтобы другие могли так же подготовиться к экзаменам.
Следующая функция «Поиск по сайту» - для поиска нужной информации, билетов, вопросов. Используя ее, сайт выдаст вам все известные варианты.
Последняя кнопка расположенная справа, это селектор нажав на который вы выбираете, сколько вопросов на странице вам нужно, либо по одному вопросу на странице, или все вопросы билета выходят на одну страницу.
Предлагаемый тест предназначен для семиклассников и позволяет проверить базовые знания учащихся по алгебре и геометрии. Для успешного решения теста не требуется знаний, выходящих за рамки школьной программы по математике для 7 класса. Большинство заданий стандартны, хотя встречаются и относительно сложные (например, задания 14 и 20). Предполагается, что тестируемые знакомы со всем материалом по алгебре и геометрии, изучаемым в 7 классе.
В тесте будет предложено 20 вопросов различной сложности. Каждый правильный ответ приносит 1 балл. Максимальная оценка за выполнение теста равна 20. За неверные ответы баллы не снимаются.
На решение предложенного варианта отводится 120 минут. Не используйте в процессе работы микрокалькулятор, учебники, школьные тетради и т. д. Не пользуйтесь помощью родителей.
Ответом к заданию в большинстве случаев является целое число или конечная десятичная дробь. Не пишите в ответе размерности величин, не забывайте переводить обыкновенные дроби в десятичные!
Если ваш результат превысит 16 баллов, смело ставьте себе оценку "отлично". Если вы наберете 12-16 баллов, это можно считать хорошим итогом.
А вот в случае, если ваша оценка будет ниже 7 баллов, ситуация критическая! Вы плохо знакомы со школьным курсом математики, причем речь идет не только о программе 7 класса, но и о существенных пробелах за 5-6 классы. Не забывайте: через два года вам предстоит сдавать ГИА по математике. Подготовку к этому экзамену надо начинать уже сейчас. Чем быстрее вы восстановите все пробелы, тем легче будет учиться в 8 - 9 классе, тем лучше вы сдадите ГИА.
«7 plagues of Software Testing» - это цикл из семи заметок Джеймса Виттекера, в мае 2009 года присоединившегося к команде Google в качестве Test Director. Этот цикл родился из его первого выступления (tech talk) в Google, где его выводы, по признанию самого Джеймса, были признаны ребятами из Google достаточно провокационными.
Оригиналы всех семи заметок опубликованы в блоге http://googletesting.blogspot.com/ . Переводы заметок можно найти по тегу whittaker в блоге Юли Нечаевой: http://jnechaeva.blogspot.com/search/label/whittaker
Порок бесцельности
Мудрость. Это больше, чем просто крутое словцо. Оно рисует в воображении колдовской образ древних магических книг и ученых мудрецов с их тайными, с таким риском добытыми знаниями.
И это именно то, чего нам не хватает в тестировании. Мудрость тестирования? Вы шутите? Где она? Кто же её зажал? Не подскажете?
Индустрия тестирования больна пороком бесцельности. Нам не хватает Мудрости, нам не хватает корня того знания, которое передается от мастера к подмастерьям и записано в магических книгах для прилежного изучения. Наши ученики без наставников. Мы должны заново изобретать колесо в уединении своих офисов, тем самым позволяя другим тестировщикам заново изобретать колесо в своих офисах по всему миру.
Предлагаю остановить эту бессмыслицу. Тестирование стало слишком бесцельным. Мы тестируем потому, что наши менеджеры говорит нам это делать. Мы автоматизируем потому, что мы можем, или потому, что мы знаем как, а не потому, что это часть осознанной и выстраданной стратегии, и уж точно не потому, что нам это подсказывает наша Мудрость. Существует ли где-то план или другое задокументированное знание, которое направляет наше тестирование, или мы просто барабаним по клавиатуре, надеясь, что что-то сломается? Где же наши тестировщицкие книги заклинаний? Действительно ли с трудом добытое знание наших предшественников в тестировании – это то, что нам всегда доступно в наше время быстродоступной информации?
Когда охотники убивают, они запоминают и территорию, и обстоятельства. Они передают это знание своим преемникам. Со временем они начинают понимать повадки добычи, и коллективное знание множества охотников значительно облегчает труд будущих охотников. Когда вы видите такую территорию, вы ожидаете игры по определенным правилам. Можем ли мы сказать то же самое о тестировании? Как хорошо мы учимся друг у друга? Разве наши моменты озарений систематизированы таким образом, чтобы избавить будущих тестировщиков от страданий в бесцельности борьбы с тем, над чем страдали мы? Можем ли мы сказать, что когда мы видим такую функциональность, мы знаем лучший способ её протестировать?
Порок бесцельности, увы, широко распространен. И нужда в Мудрости очень остра. Nike говорит нам: ‘just do it’, но что применимо к упражнениям, не подходит к тестированию ПО. В следующий раз, поймав себя на ‘just doing’ тестирование, остановитесь на мгновение и спросите себя: «Какова моя цель?» и «Каково назначение этого теста?». И если ответ не приходит к вам моментально, вы в плену бесцельности, «just doing it», положившись на удачу и грубую силу в усилиях по поимке вашей добычи.
Удаче не место в волшебстве охоты и ей нет места в тестировании. Удача – это хорошая случайность, но она не может быть нашим планом А. Следите за пороком бесцельности. Препарируйте свои успехи, исследуйте свои неудачи и будьте уверены, что вы фиксируете то, чему научились в ходе самонаблюдения, для ваших коллег.
Станьте для них Мастером. Создавайте тестировщицкую книгу заклинаний и делитесь ей с другими в своей команде. И со временем вы избавитесь от порока бесцельности.
Порок повторяемости
Если бесцельность – это результат «простоделания», то повторяемость – это результат «простоделания несколько раз». Раз за разом, билд за билдом, спринт за спринтом, версия за версией мы тестируем наш продукт. Разработчики проводят инспекции, создают юнит-тесты и запускают статические анализаторы. Но у нас есть лишь маленькие догадки по поводу всей этой работы, и мы не можем доверять им. Разработчики тестируют, но затем перетестируем мы. Мы не можем поручиться за то, что они делают, и поэтому мы подвергаем повторному тестированию всё. Наряду с ростом нашего продукта в фичах и по мере фиксов дефектов мы продолжаем наше тестирование. Новые тесты теряют свою новизну очень быстро, и все они, в конце концов, становятся устаревшими.
Существует Бейзеровский парадокс пестицида. Пестициды убивают жуков, но опрыскайте одно и то же поле одним и тем же ядом достаточное количество раз, и у оставшихся жуков выработается иммунитет. «Прополоскать и повторить» - это алгоритм для мытья волос, а не для тестирования ПО. Последнее, чего мы хотим добиться, -- это билд, полный супер-багов, устойчивых к нашему «тестициду». Дальше – хуже: всё, что называется «успешным тестированием» будет давать нам фальшивое видение тщательности и делать наши метрики завершенности кучей опасного вранья.
Когда вы не находите баги, это не потому, что их нет, а потому, что повторение повлекло за собой парадокс пестицида.
Память – это та штука, которая с возрастом слабеет первой, но в общей картине инженерии разработку ПО можно назвать старой с очень большой натяжкой.
Действительно, мы откровенно молоды в сравнении с гражданскими, механическими, электротехническими и другими инженерными дисциплинами. Мы не можем использовать возраст как оправдание амнезии.
Тестировщики подвержены двум типам порока амнезии. У нас есть командная амнезия, которая заставляет нас забывать наши прежние проекты, наши прежние баги, тесты, сбои и так далее. Требуется время для построения коллективной памяти, которая помогла бы нам остановить повторение наших ошибок. Каждый проект – это не старт с нулевой точки, это всего лишь новая цель для уже более опытной команды. Звездный корабль Enterprise сохраняет бортовой журнал. Это дневник, в котором описаны все приключения его экипажа и к которому можно обратиться за деталями, которые возможно помогут людям выбраться из текущего очередного переплета. Я не пропагандирую ведение дневников для команд тестирования, но я действительно хочу иметь механизм для сохранения знаний. Идея в том, что мы как команда основываемся на наших коллективных знаниях и успехах. Чем длиннее память экипажа Enterprise, тем лучше её можно использовать.
А ну-ка, назовите мне быстренько последний крупный сбой продукта, над которым работает ваша команда. Есть ли у вашей команды коллективная память общих багов? Делитесь ли вы хорошими тестами? Если один специалист пишет тесты для проверки какой-то функциональности, знают ли об этом остальные и тратят ли они свое время на тестирование где-то в другом месте? Документируются ли проблемы, которые ломают автоматизацию, с тем, чтобы усилия на анализ этих проблем и их решение не повторялись снова? Знает ли команда, что делает каждый, с тем, чтобы их области тестирования перекрывались как можно меньше? Достигается ли это с помощью дашбордов и постоянного общения? Или мы синхронизируем наши действия лишь митингами, крадущими наше время и прерывающими нашу работу? Ответьте честно. Первый шаг к исправлению – признание существования проблемы.
Второй тип проблем с памятью – амнезия индустрии. Когда я упоминал Бориса Бейзера и его парадокс пестицида в моем предыдущем посте, скольким из вас пришлось искать, что это такое? А те из вас, кто знал, - как у вас со знаниями AJAX? Будьте честными: да, есть ребята, которые в курсе как исторического ракурса, так и современных технологий, но они так редки, так редки... Наше знание, кажется, не коллективное. Оно ситуативное. Те, кто помнит идеи Бориса Бейзера, работали в мире, где AJAX не было. Тем, кто без проблем говорит на языке web, не хватает фундаментального мышления и мудрости. Запоминание – вот что у нас есть, но это не настоящая память.
Амнезия индустрии – это настоящая беда. Подумайте об этом в таком ключе: проблема тестирования, которая встала перед вами прямо сейчас (вставьте сюда проблему, над которой вы работаете), уже была когда-то решена. Вы тестируете операционную систему? Кто-то уже сделал это, и не только он. Веб-приложение? Да, и это уже сделано. AJAX? Клиент-сервер? Да, да и ещё раз да. Скорее всего все, что вы сейчас делаете, уже было сделано до вас. Да, есть какие-то новые проблемы тестирования, но более чем вероятно, что ваша нынешняя проблема не одна из них. Очень плохо, что с коллективной памятью в индустрии все так запущено, иначе было бы просто дотянуться до помощи.
Позвольте мне завершить эту колонку, показав пальцем внутрь: Как же мы [Гугл] будем тестировать недавно анонсированную ОС Chrome? Сколько коллективной памяти мы сохранили после Chrome и Android? Сколько из того, чему мы научились, тестируя Android, поможет? А сколько из этого будет переиспользоваться? Как легко тестовые команды Chrome и Android адаптируются к этому новому испытанию? И, конечно же, многие наши проблемы тестирования – это те, с которыми мы уже сталкивались.
Запомним ли мы?
Порок скучности
"Тестирование скучно". И не говорите мне, что вы никогда не слыхали о разработчике, дизайнере или другом не-тестировщике, выражающем такое мнение. Найдите время поискать истину в вашей собственной душе. Даже самый фанатичный тестировщик должен бы признать появление порока скучности в некоторые моменты. Изо-дня-в-дневное выполнение тестов и заполнение баг-репортов просто не удерживает интерес наиболее продвинутых технарей, которых работа с компьютером притягивает своей креативностью и многообещающей репутацией. Даже если вы находите себя невосприимчивым к скуке, вы все равно должны признать, что многие аспекты тестирования монотонны и далеки от творчества.
Хотя начинается все не так. На заре тестерской карьеры возбуждение от охоты на баги может удерживать тестировщика в течение многих месяцев. Это происходит как опьянение от прохождения видеоигры и попыток найти ускользающий приз. И большая часть успехов в перерасчете на навыки как раз приобретается в эти ранние годы тестировщиками, которые быстро превращаются из новобранцев в достаточно хороших специалистов. Кто же будет противиться карьере, предлагающей изучение, развитие и интеллектуально интересные задачи?
Но как только кривая достижений сглаживается, задачи тестирования могут становиться повторяемыми, что очень быстро превращается в монотонность. Я думаю, развитие уходит в сторону, вот почему многие тестировщики переходят в разработчики после нескольких лет. Интересные задачи и творчество блекнут от монотонности.
Я считаю, что скучающие тестировщики что-то упускают. Я утверждаю, что лишь тактические аспекты тестирования становятся со временем скучными, и многие ударяются в автоматизацию дабы сгладить это. Автоматизация как зелье от скуки выполнения тест-кейсов и заполнения баг-репортов – это одно дело, но автоматизация – не замена стратегическим аспектам процесса тестирования и именно в стратегии мы находим избавление от порока скучности. Процесс тест-дизайна, принятие решения о том, что должно быть и что не должно быть протестировано, и в каком соотношении, - во всем этом автоматизация вам не поможет, и это остается интересной и побуждающей думать задачей. И ни одно из этого ещё не является стратегической задачей мониторинга тестов и определения, когда остановиться. Это и есть те тяжелые, но интересные стратегические проблемы, которые изгоняют порок скучности. Тестировщики могут поддаться пороку скучности, либо же они могут сместить свой фокус с лишь тактических задач на изящный микс из тактической работы и стратегических размышлений.
Убедитесь, что в вашей суете по выполнению мелких тактических задач тестирования вы не упускаете стратегические аспекты вашей работы, потому что именно здесь есть интересные технические задачи и высокоуровневые размышления, которые удержат ваш интерес и припрут этот порок к стене.
Порок бездомности
Есть 2 категории людей, которые регулярно находят баги: тестировщики, которым за это платят, и пользователи, которые сталкиваются с багами случайно. Вообще-то, пользователи не делают это специально, просто в процессе нормального использования ПО в ходе работы (или развлечения, или социализации, или ещё чего-то) случаются сбои. Частенько, именно магическая комбинация взаимодействия приложения с реальными данными пользователя на реальном компьютерном окружении пользователя приводит к сбою ПО. Не кажется ли вам очевидным, что тестер должен стремиться воссоздать такие данные и условия окружения в своей тестовой лаборатории, чтобы найти эти баги до выпуска продукта?
На самом деле, тестировщики усердно пытались добиться именно этого в течение десятилетий. Я называю это «привнесением пользователя в тестовую лабораторию», неважно как, телом или духом. Моя докторская диссертация была на тему статистического тестирования использования, и я был далеко не первым человеком, кто думал об этой идее, как свидетельствует моя многостраничная библиография. Но здесь есть естественное ограничение на успех такого рода работы. Тестировщики просто не могут стать пользователями или имитировать их действия достаточно натурально, чтобы найти все важные баги. Вы будете пропускать важные дефекты, если только вы действительно не живете в этом продукте.
Это как домовладение. Не имеет значения, хорошо ли построен дом. Не имеет значения, насколько старательными были строители и подрядчики во время строительства. Дом может быть тщательно проинспектирован на каждой фазе строительства подрядчиком, домовладельцем и государственным строительным инспектором. Все равно есть проблемы, которые могут быть обнаружены только спустя некоторое время после заселения дома. Дом должны использовать, в нем должны обедать, спать, принимать душ, готовить, устраивать вечеринки, отдыхать и все остальное, что домовладельцы делают в своих домах. Нельзя обнаружить дефект в системе сточных вод, пока подросток не постоит под душем в течение часа. Нельзя обнаружить оставленный кусок арматуры в бетонной плите гаража, пока не начнут парковать машину ночью. Строитель не будет (да он и не сможет) смоделировать такое.
И время тоже имеет значение. Нужны месяцы перегорания лампочек по одной в неделю, чтобы выяснить брак в проводке. Должен пройти год, чтобы шляпки гвоздей начали торчать из стены. Все это проблемы домовладельца, а не строителя. Это эквиваленты софтовых утечек памяти и искажений данных, время – необходимый элемент для обнаружения подобных сбоев.
Есть некоторое количество дефектов, которые просто не могут быть найдены до тех пор, пока дом не будет обжит, и ПО здесь ничем не отличается. Оно должно побыть в руках реальных пользователей, выполняющих реальную работу с реальными данными в реальном окружении. Такие баги недоступны тестировщикам, как шляпки гвоздей и прут арматуры строителям.
Тестировщики бездомны. Мы можем делать лишь то, что можем, и ничего более. Нужно понимать наши ограничения и быть готовыми к спискам жалоб от наших пользователей. Претендовать на то, что как только приложение выпущено, проект завершен, - как минимум, глупо. Есть ещё гарантийный период, в который мы присматриваем за приложение, и этот период - все ещё часть фазы тестирования.
Порок слепоты
Представьте себе прохождение видеоигры с завязанными глазами, или даже с выключенным heads up дисплеем. Вы не можете следить за здоровьем своего персонажа, ваша система планирования исчезла. Нет впередсмотрящего радара, и вообще нет никаких предостережений. В игре невозможность доступа к информации о мире кампании подрывает силы и является верным путем к смерти вашего персонажа.
И есть множество аспектов тестирования программного обеспечения, которые скрываются в этом невидимом диапазоне. Программное обеспечение невидимо само по себе. Мы видим его только сквозь UI, а многое из того, что происходит, скрыто под покровом и находится вне области обзора. Это совершенно не похоже на производство автомобиля, где вы можете четко увидеть недостающие детали, и где множество инженеров могут смотреть на автомобиль и видеть одно и то же. Не возникнет спора о том, установлен ли бампер на машину, ведь это очевидно для любого, кто смотрит на неё. С программным обеспечением, которое существует как магнитные колебания на носителе данных, всё иначе. И это не способствует наглядности.
Тестирование во многом, как и прохождение видеоигры с завязанными глазами. Мы не можем видеть баги, мы не можем видеть покрытие, мы не можем видеть изменения в коде. Эта информация, такая ценная для нас, тестировщиков, скрыта в бесполезных статистических отчетах. И если кто-то повяжет нам на глаза настоящую повязку, мы можем даже не заметить этого.
Слепота касательно нашего продукта и его поведения создает весьма ощутимые проблемы для тестировщиков. Какие части приложения более всего были подвержены юнит-тестированию? Какие части были изменены со сменой одного билда на другой? Какую часть программы покрывает этот конкретный тест-кейс? Какие части были протестированы тщательно, а каким вообще не было уделено внимания?
Нашим народным средством от порока слепоты всегда было измерение покрытия кода, API-метод покрытия или UI покрытие. Мы берем вещи, которые видим лучше всего и измеряем их. Но действительно ли они что-нибудь нам говорят? Мы делаем так годами не потому, что это приоткрывает завесу, а потому, что это все, что позволит нам сделать наша слепота. Мы очень много взаимодействуем с нашим приложением посредством тестов, но мы должны полагаться на другие, менее конкретные чувства для любого фидбека о нашей работе.
Тестировщики могли бы многому научиться в мире компьютерных игр. Включите свои heads up дисплеи - и вы увидите информацию, к которой были слепы. Сила в знании.
Порок энтропии
Математически, энтропия – это мера неопределенности. Скажем, если есть 5 событий, то энтропия будет максимальной, если все они равновероятны, и энтропия будет минимальной, если лишь одно из событий определено, а остальные 4 – невозможны.
Чем более неопределенные события вам приходится рассматривать, тем выше карабкается мера энтропии. Люди часто думают об энтропии как о мере случайности: чем более неопределенные события рассматриваются, тем более случаен их результат.
Тестировщики привносят энтропию в разработку добавлением ряда вещей, которые следует сделать разработчику. Когда разработчики пишут код, энтропия мала. Когда мы заводим баги, мы увеличиваем энтропию. Баги отводят внимание разработчиков от кодирования. Теперь они должны работать параллельно и над созданием, и над починкой фич. Чем больше багов, тем больше параллельных задач, и это повышает энтропию. Энтропия – одна из причин, почему баги вызывают ещё больше багов: принцип энтропии обеспечивает это. Энтропия порождает энтропию! В конце концов, математика показывает нам то, что и так интуитивно понятно: предотвращение круче лечения.
Как бы там ни было, мы ничего не можем сделать, чтобы полностью предотвратить порок энтропии, кроме как создать разработчиков, которые никогда не ошибаются. А раз это маловероятно, мы должны определять, как и когда мы сталкиваемся с энтропией, и делать все, что в наших силах, чтобы ею управлять. Чем больше мы сможем сделать во время разработки, тем лучше. Помогать в code review, вводить наших разработчиков в курс тест-планов, пользовательских сценариев и окружений, чтобы они могли кодировать с меньшим количеством багов, которые нам пришлось бы рапортовать. Выкуривать баги как можно раньше, заводить их пачками и быть уверенными, что мы создаём только высококачественные баг-репорты, причесывая их самостоятельно, концентрируя тем самым мысли программистов на разработке. Написание хороших баг-репортов и быстрая проверка исправлений удержат внимание разработчиков там, где ему положено быть. Фактически это максимизирует определенность «разработчицких событий» и минимизирует количество и влияние багов. Энтропия, таким образом, сходит на минимум.
Мы не можем отогнать этот порок, но мы можем определить привнесение энтропии в разработку и согласиться с неминуемым влиянием на качество кода; мы можем держать её под контролем.
- Tutorial
Недавно был на собеседовании на Middle QA на проект, который явно превышает мои возможности. Уделил много времени тому, чего не знал вообще и мало времени повторению простой теории, а зря.
Ниже основы основ для повторения перед собеседованием для Trainee and Junior: определение тестирования, качество , верификация / валидация , цели, этапы, тест план, пункты тест плана, тест дизайн, техники тест дизайна, traceability matrix , test case, чек-лист, дефект, error/deffect/failure , баг репорт, severity vs priority, уровни тестирования, виды / типы, подходы к интеграционному тестированию , принципы тестирования, статическое и динамическое тестирование, исследовательское / ad-hoc тестирование, требования, жизненный цикл бага, стадии разработки ПО, decision table, qa/qc/test engineer, диаграмма связей.
Все замечания, корректировки и дополнения очень приветствуются.
Тестирование программного обеспечения - проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. В более широком смысле, тестирование - это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).
Качество программного обеспечения (Software Quality) - это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности.
Верификация (verification)
- это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы.
Валидация (validation)
- это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе .
Также можно встретить иную интерпритацию:
Процесс оценки соответствия продукта явным требованиям (спецификациям) и есть верификация (verification), в то же время оценка соответствия продукта ожиданиям и требованиям пользователей - есть валидация (validation). Также часто можно встретить следующее определение этих понятий:
Validation - ’is this the right specification?’.
Verification - ’is the system correct to specification?’.
Цели тестирования
Повысить вероятность того, что приложение, предназначенное для тестирования, будет работать правильно при любых обстоятельствах.
Повысить вероятность того, что приложение, предназначенное для тестирования, будет соответствовать всем описанным требованиям.
Предоставление актуальной информации о состоянии продукта на данный момент.
Этапы тестирования:
1. Анализ продукта
2. Работа с требованиями
3. Разработка стратегии тестирования
и планирование процедур контроля качества
4. Создание тестовой документации
5. Тестирование прототипа
6. Основное тестирование
7. Стабилизация
8. Эксплуатация
Тест план (Test Plan)
- это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
Отвечает на вопросы:
Что надо тестировать?
Что будете тестировать?
Как будете тестировать?
Когда будете тестировать?
Критерии начала тестирования.
Критерии окончания тестирования.
Основные пункты тест плана
В стандарте IEEE 829 перечислены пункты, из которых должен (пусть - может) состоять тест-план:
a) Test plan identifier;
b) Introduction;
c) Test items;
d) Features to be tested;
e) Features not to be tested;
f) Approach;
g) Item pass/fail criteria;
h) Suspension criteria and resumption requirements;
i) Test deliverables;
j) Testing tasks;
k) Environmental needs;
l) Responsibilities;
m) Staffing and training needs;
n) Schedule;
o) Risks and contingencies;
p) Approvals.
Тест дизайн
– это этап процесса тестирования ПО, на котором проектируются и создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.
Роли, ответственные за тест дизайн:
Тест аналитик - определяет «ЧТО тестировать?»
Тест дизайнер - определяет «КАК тестировать?»
Техники тест дизайна
Эквивалентное Разделение (Equivalence Partitioning - EP) . Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала - 0.
Анализ Граничных Значений (Boundary Value Analysis - BVA). Если взять пример выше, в качестве значений для позитивного тестирования выберем минимальную и максимальную границы (1 и 10), и значения больше и меньше границ (0 и 11). Анализ Граничный значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.
Причина / Следствие (Cause/Effect - CE). Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие). Например, вы проверяете возможность добавлять клиента, используя определенную экранную форму. Для этого вам необходимо будет ввести несколько полей, таких как «Имя», «Адрес», «Номер Телефона» а затем, нажать кнопку «Добавить» - это «Причина». После нажатия кнопки «Добавить», система добавляет клиента в базу данных и показывает его номер на экране - это «Следствие».
Предугадывание ошибки (Error Guessing - EG). Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку. Например, спецификация говорит: «пользователь должен ввести код». Тестировщик будет думать: «Что, если я не введу код?», «Что, если я введу неправильный код? », и так далее. Это и есть предугадывание ошибки.
Исчерпывающее тестирование (Exhaustive Testing - ET) - это крайний случай. В пределах этой техники вы должны проверить все возможные комбинации входных значений, и в принципе, это должно найти все проблемы. На практике применение этого метода не представляется возможным, из-за огромного количества входных значений.
Попарное тестирование (Pairwise Testing) - это техника формирования наборов тестовых данных. Сформулировать суть можно, например, вот так: формирование таких наборов данных, в которых каждое тестируемое значение каждого из проверяемых параметров хотя бы единожды сочетается с каждым тестируемым значением всех остальных проверяемых параметров.
Допустим, какое-то значений (налог) для человека рассчитывается на основании его пола, возраста и наличия детей - получаем три входных параметра, для каждого из которых для тестов выбираем каким-то образом значения. Например: пол - мужской или женский; возраст - до 25, от 25 до 60, более 60; наличие детей - да или нет. Для проверки правильности расчётов можно, конечно, перебрать все комбинации значений всех параметров:
| № | пол | возраст | дети |
|---|---|---|---|
| 1 | мужчина | до 25 | детей нет |
| 2 | женщина | до 25 | детей нет |
| 3 | мужчина | 25-60 | детей нет |
| 4 | женщина | 25-60 | детей нет |
| 5 | мужчина | старше 60 | детей нет |
| 6 | женщина | старше 60 | детей нет |
| 7 | мужчина | до 25 | дети есть |
| 8 | женщина | до 25 | дети есть |
| 9 | мужчина | 25-60 | дети есть |
| 10 | женщина | 25-60 | дети есть |
| 11 | мужчина | старше 60 | дети есть |
| 12 | женщина | старше 60 | дети есть |
А можно решить, что нам не нужны сочетания значений всех параметров со всеми, а мы хотим только убедиться, что мы проверим все уникальные пары значений параметров. Т.е., например, с точки зрения параметров пола и возраста мы хотим убедиться, что мы точно проверим мужчину до 25, мужчину между 25 и 60, мужчину после 60, а также женщину до 25, женщину между 25 и 60, ну и женщину после 60. И точно так же для всех остальных пар параметров. И таким образом, мы можем получить гораздо меньше наборов значений (в них есть все пары значений, правда некоторые дважды):
| № | пол | возраст | дети |
|---|---|---|---|
| 1 | мужчина | до 25 | детей нет |
| 2 | женщина | до 25 | дети есть |
| 3 | мужчина | 25-60 | дети есть |
| 4 | женщина | 25-60 | детей нет |
| 5 | мужчина | старше 60 | детей нет |
| 6 | женщина | старше 60 | дети есть |
Такой подход примерно и составляет суть техники pairwise testing - мы не проверяем все сочетания всех значений, но проверяем все пары значений.
Traceability matrix - Матрица соответствия требований
- это двумерная таблица, содержащая соответсвие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк - тестовые сценарии. На пересечении - отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки.
Матрица соответсвия требований используется QA-инженерами для валидации покрытия продукта тестами. МСТ является неотъемлемой частью тест-плана.
Тестовый сценарий (Test Case)
- это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Пример:
Action Expected Result Test Result
(passed/failed/blocked)
Open page «login» Login page is opened Passed
Каждый тест кейс должен иметь 3 части:
PreConditions Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
Test Case Description Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям
PostConditions Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста - initial state)
Виды Тестовых Сценариев:
Тест кейсы разделяются по ожидаемому результату на позитивные и негативные:
Позитивный тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.
Негативный тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций (срабатывание валидаторов), а также проверяет, что вызываемая приложением функция не выполняется при срабатывании валидатора.
Чек-лист (check list)
- это документ, описывающий что должно быть протестировано. При этом чек-лист может быть абсолютно разного уровня детализации. На сколько детальным будет чек-лист зависит от требований к отчетности, уровня знания продукта сотрудниками и сложности продукта.
Как правило, чек-лист содержит только действия (шаги), без ожидаемого результата. Чек-лист менее формализован чем тестовый сценарий. Его уместно использовать тогда, когда тестовые сценарии будут избыточны. Также чек-лист ассоциируются с гибкими подходами в тестировании.
Дефект (он же баг) – это несоответствие фактического результата выполнения программы ожидаемому результату. Дефекты обнаруживаются на этапе тестирования программного обеспечения (ПО), когда тестировщик проводит сравнение полученных результатов работы программы (компонента или дизайна) с ожидаемым результатом, описанным в спецификации требований.
Error
- ошибка пользователя, то есть он пытается использовать программу иным способом.
Пример - вводит буквы в поля, где требуется вводить цифры (возраст, количество товара и т.п.).
В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message), с красным крестиком которые.
Bug (defect)
- ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так как планировалось и программа выходит из-под контроля. Например, когда никак не контроллируется ввод пользователя, в результате неверные данные вызывают краши или иные «радости» в работе программы. Либо внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.
Failure
- сбой (причём не обязательно аппаратный) в работе компонента, всей программы или системы. То есть, существуют такие дефекты, которые приводят к сбоям (A defect caused the failure) и существуют такие, которые не приводят. UI-дефекты например. Но аппаратный сбой, никак не связанный с software, тоже является failure.
Баг Репорт (Bug Report)
- это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
Шапка
Короткое описание (Summary) Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации.
Проект (Project) Название тестируемого проекта
Компонент приложения (Component) Название части или функции тестируемого продукта
Номер версии (Version) Версия на которой была найдена ошибка
Серьезность (Severity) Наиболее распространена пятиуровневая система градации серьезности дефекта:
S1 Блокирующий (Blocker)
S2 Критический (Critical)
S3 Значительный (Major)
S4 Незначительный (Minor)
S5 Тривиальный (Trivial)
Приоритет (Priority) Приоритет дефекта:
P1 Высокий (High)
P2 Средний (Medium)
P3 Низкий (Low)
Статус (Status) Статус бага. Зависит от используемой процедуры и жизненного цикла бага (bug workflow and life cycle)
Автор (Author) Создатель баг репорта
Назначен на (Assigned To) Имя сотрудника, назначенного на решение проблемы
Окружение
ОС / Сервис Пак и т.д. / Браузера + версия /… Информация об окружении, на котором был найден баг: операционная система, сервис пак, для WEB тестирования - имя и версия браузера и т.д.
…
Описание
Шаги воспроизведения (Steps to Reproduce) Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке.
Фактический Результат (Result) Результат, полученный после прохождения шагов к воспроизведению
Ожидаемый результат (Expected Result) Ожидаемый правильный результат
Дополнения
Прикрепленный файл (Attachment) Файл с логами, скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы
Severity vs Priority
Серьезность (Severity) - это атрибут, характеризующий влияние дефекта на работоспособность приложения.
Приоритет (Priority) - это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Можно сказать, что это инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект.
Severity выставляется тестировщиком
Priority – менеджером, тимлидом или заказчиком
Градация Серьезности дефекта (Severity)
S1 Блокирующая (Blocker)
Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна. Решение проблемы необходимо для дальнейшего функционирования системы.
S2 Критическая (Critical)
Критическая ошибка, неправильно работающая ключевая бизнес логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, без возможности решения проблемы, используя другие входные точки. Решение проблемы необходимо для дальнейшей работы с ключевыми функциями тестируемой системой.
S3 Значительная (Major)
Значительная ошибка, часть основной бизнес логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.
S4 Незначительная (Minor)
Незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.
S5 Тривиальная (Trivial)
Тривиальная ошибка, не касающаяся бизнес логики приложения, плохо воспроизводимая проблема, малозаметная посредствам пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.
Градация Приоритета дефекта (Priority)
P1 Высокий (High)
Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.
P2 Средний (Medium)
Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.
P3 Низкий (Low)
Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.
Уровни Тестирования
1. Модульное тестирование (Unit Testing)
Компонентное (модульное) тестирование проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).
2. Интеграционное тестирование (Integration Testing)
Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.
3. Системное тестирование (System Testing)
Основной задачей системного тестирования является проверка как функциональных, так и не функциональных требований в системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования, отсутствующая или неверная функциональность, неудобство использования и т.д.
4. Операционное тестирование (Release Testing).
Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации, как это было определено в бизнес моделе системы. Следует учесть, что и бизнес модель может содержать ошибки. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях; недостаточная производительность системы в среде эксплуатации и др. Очевидно, что нахождение подобных вещей на стадии внедрения - критичная и дорогостоящая проблема. Поэтому так важно проведение не только верификации, но и валидации, с самых ранних этапов разработки ПО.
5. Приемочное тестирование (Acceptance Testing)
Формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью:
определения удовлетворяет ли система приемочным критериям;
вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет.
Виды / типы тестирования
Функциональные виды тестирования
Функциональное тестирование (Functional testing)
Тестирование пользовательского интерфейса (GUI Testing)
Тестирование безопасности (Security and Access Control Testing)
Тестирование взаимодействия (Interoperability Testing)
Нефункциональные виды тестирования
Все виды тестирования производительности:
o нагрузочное тестирование (Performance and Load Testing)
o стрессовое тестирование (Stress Testing)
o тестирование стабильности или надежности (Stability / Reliability Testing)
o объемное тестирование (Volume Testing)
Тестирование установки (Installation testing)
Тестирование удобства пользования (Usability Testing)
Тестирование на отказ и восстановление (Failover and Recovery Testing)
Конфигурационное тестирование (Configuration Testing)
Связанные с изменениями виды тестирования
Дымовое тестирование (Smoke Testing)Регрессионное тестирование (Regression Testing)
Повторное тестирование (Re-testing)
Тестирование сборки (Build Verification Test)
Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)
Функциональное тестирование рассматривает заранее указанное поведение и основывается на анализе спецификаций функциональности компонента или системы в целом.
Тестирование пользовательского интерфейса (GUI Testing) - функциональная проверка интерфейса на соответствие требованиям - размер, шрифт, цвет, consistent behavior.
Тестирование безопасности - это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
Тестирование взаимодействия (Interoperability Testing) – это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование
Нагрузочное тестирование - это автоматизированное тестирование, имитирующее работу определенного количества бизнес пользователей на каком-либо общем (разделяемом ими) ресурсе.
Стрессовое тестирование (Stress Testing) позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса. Стрессом в данном контексте может быть повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера. Также одной из задач при стрессовом тестировании может быть оценка деградации производительности, таким образом цели стрессового тестирования могут пересекаться с целями тестирования производительности.
Объемное тестирование (Volume Testing). Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения
Тестирование стабильности или надежности (Stability / Reliability Testing). Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.
Тестирование установки направленно на проверку успешной инсталляции и настройки, а также обновления или удаления программного обеспечения.
Тестирование удобства пользования
- это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Сюда также входит:
User eXperience (UX) - ощущение, испытываемое пользователем во время использования цифрового продукта, в то время как User interface - это инструмент, позволяющий осуществлять интеракцию «пользователь - веб-ресурс».
Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети). Целью данного вида тестирования является проверка систем восстановления (или дублирующих основной функционал систем), которые, в случае возникновения сбоев, обеспечат сохранность и целостность данных тестируемого продукта.
Конфигурационное тестирование (Configuration Testing) - специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.)
Дымовое (Smoke) тестирование рассматривается как короткий цикл тестов, выполняемый для подтверждения того, что после сборки кода (нового или исправленного) устанавливаемое приложение, стартует и выполняет основные функции.
Регрессионное тестирование - это вид тестирования направленный на проверку изменений, сделанных в приложении или окружающей среде (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб сервер или сервер приложения), для подтверждения того факта, что существующая ранее функциональность работает как и прежде. Регрессионными могут быть как функциональные, так и нефункциональные тесты.
Повторное тестирование
- тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.
В чем разница между regression testing и re-testing?
Re-testing - проверяется исправление багов
Regression testing - проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвало новых багов.
Тестирование сборки или Build Verification Test - тестирование направленное на определение соответствия, выпущенной версии, критериям качества для начала тестирования. По своим целям является аналогом Дымового Тестирования, направленного на приемку новой версии в дальнейшее тестирование или эксплуатацию. Вглубь оно может проникать дальше, в зависимости от требований к качеству выпущенной версии.
Санитарное тестирование - это узконаправленное тестирование достаточное для доказательства того, что конкретная функция работает согласно заявленным в спецификации требованиям. Является подмножеством регрессионного тестирования. Используется для определения работоспособности определенной части приложения после изменений произведенных в ней или окружающей среде. Обычно выполняется вручную.
Подходы к интеграционному тестированию:
Снизу вверх (Bottom Up Integration)
Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения.
Сверху вниз (Top Down Integration)
Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами. Таким образом мы проводим тестирование сверху вниз.
Большой взрыв («Big Bang» Integration)
Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования.
Принципы тестирования
Принцип 1
– Тестирование демонстрирует наличие дефектов (Testing shows presence of defects)
Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет. Тестирование снижает вероятность наличия дефектов, находящихся в программном обеспечении, но, даже если дефекты не были обнаружены, это не доказывает его корректности.
Принцип 2
– Исчерпывающее тестирование недостижимо (Exhaustive testing is impossible)
Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо, за исключением тривиальных случаев. Вместо исчерпывающего тестирования должны использоваться анализ рисков и расстановка приоритетов, чтобы более точно сфокусировать усилия по тестированию.
Принцип 3
– Раннее тестирование (Early testing)
Чтобы найти дефекты как можно раньше, активности по тестированию должны быть начаты как можно раньше в жизненном цикле разработки программного обеспечения или системы, и должны быть сфокусированы на определенных целях.
Принцип 4
– Скопление дефектов (Defects clustering)
Усилия тестирования должны быть сосредоточены пропорционально ожидаемой, а позже реальной плотности дефектов по модулям. Как правило, большая часть дефектов, обнаруженных при тестировании или повлекших за собой основное количество сбоев системы, содержится в небольшом количестве модулей.
Принцип 5
– Парадокс пестицида (Pesticide paradox)
Если одни и те же тесты будут прогоняться много раз, в конечном счете этот набор тестовых сценариев больше не будет находить новых дефектов. Чтобы преодолеть этот “парадокс пестицида”, тестовые сценарии должны регулярно рецензироваться и корректироваться, новые тесты должны быть разносторонними, чтобы охватить все компоненты программного обеспечения,
или системы, и найти как можно больше дефектов.
Принцип 6
– Тестирование зависит от контекста (Testing is concept depending)
Тестирование выполняется по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем сайт электронной коммерции.
Принцип 7
– Заблуждение об отсутствии ошибок (Absence-of-errors fallacy)
Обнаружение и исправление дефектов не помогут, если созданная система не подходит пользователю и не удовлетворяет его ожиданиям и потребностям.
Cтатическое и динамическое тестирование
Статическое тестирование отличается от динамического тем, что производится без запуска программного кода продукта. Тестирование осуществляется путем анализа программного кода (code review) или скомпилированного кода. Анализ может производиться как вручную, так и с помощью специальных инструментальных средств. Целью анализа является раннее выявление ошибок и потенциальных проблем в продукте. Также к статическому тестированию относится тестирования спецификации и прочей документации.
Исследовательское / ad-hoc тестирование
Простейшее определение исследовательского тестирования - это разработка и выполнения тестов в одно и то же время. Что является противоположностью сценарного подхода (с его предопределенными процедурами тестирования, неважно ручными или автоматизированными). Исследовательские тесты, в отличие от сценарных тестов, не определены заранее и не выполняются в точном соответствии с планом.
Разница между ad hoc и exploratory testing в том, что теоретически, ad hoc может провести кто угодно, а для проведения exploratory необходимо мастерство и владение определенными техниками. Обратите внимание, что определенные техники это не только техники тестирования.
Требования
– это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения. Что, а не как.
Требования к требованиям:
Корректность
Недвусмысленность
Полнота набора требований
Непротиворечивость набора требований
Проверяемость (тестопригодность)
Трассируемость
Понимаемость
Жизненный цикл бага
Стадии разработки ПО - это этапы, которые проходят команды разработчиков ПО, прежде чем программа станет доступной для широко круга пользователей. Разработка ПО начинается с первоначального этапа разработки (стадия «пре-альфа») и продолжается стадиями, на которых продукт дорабатывается и модернизируется. Финальным этапом этого процесса становится выпуск на рынок окончательной версии программного обеспечения («общедоступного релиза»).
Программный продукт проходит следующие стадии:
анализ требований к проекту;
проектирование;
реализация;
тестирование продукта;
внедрение и поддержка.
Каждой стадии разработки ПО присваивается определенный порядковый номер. Также каждый этап имеет свое собственное название, которое характеризует готовность продукта на этой стадии.
Жизненный цикл разработки ПО:
Пре-альфа
Альфа
Бета
Релиз-кандидат
Релиз
Пост-релиз
Таблица принятия решений (decision table) – великолепный инструмент для упорядочения сложных бизнес требований, которые должны быть реализованы в продукте. В таблицах решений представлен набор условий, одновременное выполнение которых должно привести к определенному действию.
Пояснительная записка к итоговому тесту по математике за курс 7 класса
Данный тест содержит темы курса алгебры и геометрии за 7 класс. Содержание экзаменационной работы находится в рамках Обязательного минимума содержания образования по математике в основной школе.
Общее время работы – 40 минут.
Всего в работе 9 заданий, из которых 7 заданий базового уровня (часть I) и 2 задания повышенного уровня (часть II).
Работа состоит из двух модулей: «Алгебра», «Геометрия».
Модуль «Алгебра» содержит 5 заданий: в части I – 3 задания с выбором ответа А1 – А3 и 1 задание с кратким ответом – В1; в части II – 1 задание с полным решением С1.
Модуль «Геометрия» содержит 4 задания: в части I – 1 задание с кратким ответом В2, 1 задание с выбором ответа – В3 и 1 задание на соотношение – В4; в части II – 1 задание с полным решением С2.
Тест составлен по принципу проведения ОГЭ, что позволяет учащимся 7 класса психологически готовиться к экзаменам. Для составления теста использовалась следующая литература:
Алгебра: сб. заданий для подготовки к итоговой аттестации в 9 кл./ [Л.В. Кузнецова, С.Б. Суворова, Е.А. Бунимович и др.].– М.: Просвещение, 2010. – 192с.: ил. – (Итоговая аттестация).
Алгебра. ГИА. Экспресс-диагностика 9 класс.240 диагностических вариантов/ В.В. Мирошин.- М. «Национальное образование»,2012-256с.
ГИА-2013.Математика: типовые экзаменационные варианты: 30 вариантов/ под ред. А.Л. Семенова, И.В. Ященко.- М. «Национальное образование»,2012-192с.
Критерии оценивания
| Менее 7 заданий | 7 заданий | 8 заданий | 9 заданий |
|
Таблица ответов
Тест по математике за курс 7 класса
1 вариант
Часть 1
Модуль «Алгебра»
А1. Перечислите в ответе номера верных равенств.
А2. Решите уравнение: (5x–3)+(7x–4)=8–(15–11x).
