title: Конспект урока "Лесные опасности"

extracted_text:
Конспект урока по окружающему миру "Лесные опасности"
Задачи:
закрепить понятия «съедобные» и «несъедобные» грибы и ягоды;
изучить правила безопасности, которые нужно соблюдать в лесу;
воспитывать любовь к природе.

Ход урока
Организация начала урока.
Долгожданный дан звонок – начинается урок.
- Урок ознакомления с окружающим миром. Я думаю, что на уроке вы все будете очень активными и дружными. Желаю вам успеха.
Проверка домашнего задания
-  С какой  темой мы познакомились на прошлом уроке (Домашние опасности).
- Давайте вспомним, какие опасности подстерегают нас дома, и какие правила безопасности нужно соблюдать, чтобы нам было удобно, уютно и безопасно жить  в своей квартире.
- Расскажите, чем могут быть опасны эти предметы и как с ними нужно обращаться?

- Что обозначают эти знаки?

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

- Чем является лес для человека? А зачем вы ходите в лес? (ответы детей)
- Вот вы стоите у края леса, сейчас вы оглядываетесь и выбираете направление, куда идти.
- Будьте очень внимательны, иначе и до беды недалеко.
- Итак, закройте глаза, представьте, вы заходите в лес, идете по узенькой тропинке, оглядываетесь по сторонам…
- А вот и грибная опушка. Смотрите, какие разные грибы здесь растут. На доске грибы.
- Ой, ребята, на полянке мы не одни. На доске появляется ведьма и Красная Шапочка.
- Кто это?

Ведьма суп варить решила:
Змей сушеных покрошила,
Развела большой костер
И поставила котел.
Между сосен и полянок
Собрала ведро поганок,
Поскакала за бугор –
Отыскала мухомор,
Для приправы – бузины,
Для отравы – белены,
Волчьих ягод полкорзины
И отличной свежей тины…
Супчик вышел – то, что надо:
Целых 20 литров яда!

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

- Какие правила надо помнить, собирая грибы?
- Что нужно сделать, если вы сомневаетесь – съедобный гриб или нет? (спросить у взрослых или не брать совсем).
Обратить внимание детей на то, что нельзя собирать грибы вблизи дорог. Опыт с грязной водой Оборудование: тарелка, грязная вода, губка в форме шляпки гриба.

- Шляпка гриба  похожа на губку. Когда мы на неё нажимаем, из неё выделяется жидкость. Возьмём теперь губку и представим, что это шляпка гриба. Опускаем губку в грязную воду, сжимаем в воде и разжимаем. Что произошло? Губка впитала в себя всю грязную воду и сама стала грязной. Вот так и грибы впитывают в себя грязный загазованный воздух и пыль. Даже съедобные грибы, растущие у дороги, могут быть опасными и ядовитыми.
- Как думаете, можно ли употреблять в пищу такие грибы (нет).
Грибы нельзя собирать у дороги ближе, чем на 200м. и губкой.

 - Сделаем вывод: НЕ ВСЯКИЙ ГРИБ В ЛУКОШКО КЛАДУТ! Появляется на доске.

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

Рассказ подготовленного  ученика.

Волчье лыко. Это красивое, но очень опасное растение. Сок волчьего лыка содержит яд. Если он попадёт на кожу, вызывает сильное раздражение. Особенно опасно, если сок волчьего лыка попадёт в глаза. Может быть, поэтому люди, считая волка олицетворением всего злого, страшного и опасного, назвали это растение волчьим. Опасны и ягоды, они могут вызвать очень сильное отравление.

Рассказ подготовленного ученика.

Вороний глаз. Если раздвинуть траву, можно увидеть четыре широких длинных листочка, а между ними – круглую чёрную ягоду. Она напоминает глаз, а за чёрный цвет назвали вороньим. Ягода эта красивая, но не бери её в рот – она ядовита.

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

- Сделаем вывод: НЕ ВСЯ ЯГОДА, ЧТО КРАСИВА, СЪЕДОБНА. Вывод на доске.

- Среди цветов можно увидеть много насекомых. Давайте их рассмотрим.
Пчела, шершень, оса, шмель. Слайд.
- Чем они похожи?
- Про этих насекомых мы прочитаем в учебнике (С.33)

- Как же надо себя вести, если рядом летают жалящие насекомые?
- Что предпринимать, если вас все-таки ужалили?

- Сделаем вывод, как нужно себя вести, чтобы избежать укуса жалящих насекомых?
НЕ ТРЕВОЖЬ ЖАЛЯЩИХ НАСЕКОМЫХ.

Закрепление нового материала

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

Игра “Найди лишнее”. Ученики убирают лишнее и обосновывают почему.
 – Мухомор, сыроежка, груздь, масленок.
 – Смородина, малина, вороний глаз, черника.
 – Пчела, муха, шмель, оса.
У детей карточки. + слайд.

Рефлексия
- Наша прогулка закончилась.
- Давайте посмотрим, какие правила безопасности в лесу у нас получились.

- Молодцы! Вы хорошо усвоили правила поведения в лесу. Спасибо за урок.

Физкультминутка
  Мы входим   с вами в лес (маршируют на месте)
  Сколько здесь вокруг чудес! (Удивились, развели руками).
  Посмотрели вправо, влево (наклоны вправо, влево),
  Наклонились и присели (наклон вниз, приседание),
  Заниматься тихо сели (садятся за парты)


title: Конспект НОД "Пересказ текста рассказа по Л.Н. Толстому «Пришла весна»"

extracted_text:
Конспект НОД логопеда в соответствии с требованиями ФГОС в старшей группе  для детей с ОНР комбинированной направленности.
Пересказ текста рассказа по Л.Н.Толстому «Пришла весна».
Цель: составление пересказа по опорному плану из рисунков-пиктограмм.
Задачи : - учить детей составлять пересказ по опорному плану из рисунков-
               пиктограмм; (ОО «Коммуникативное развитие»)
                - стимулировать мыслительную и речевую активность детей;
                  (ОО  «Коммуникативное развитие»)
                - развивать произвольное внимание, зрительную и словесно-логическую
                   память, логическое мышление;
                - продолжать с детьми усваивать упражения биоэнергопластики;
                  (ОО «Коммуникативое развитие»)
                - систематизировать знания детей о весне и весенних явлениях;
                  (ОО «Познавательное развитие»)
                 - воспитывать интерес к сезонным изменениям , бережное отношение и
                   любовь к природе; (ОО «Социально-коммуникативное развитие»)
                  - познакомить детей с текстом рассказа по Л.Н.Толстому «Пришла весна»
                    с установкой на пересказ (ОО «Познавательное развитие»).
Оборудование:
                  текст рассказа Л.Н.Толстого «Пришла весна»; опорный план из рисунков-
                  пиктограмм; веточки черёмухи, берёзы и тополя в вазе с водой; мягкий
                  мяч среднего размера; магнитно-маркерная доска.
Предварительная работа:
                  Примерно за неделю до занятия поставить в вазу с водой веточки
                  черёмухи, берёзы и тополя; перед началом занятия логопед маркерами
                  рисует по образцу рисунки -пиктограммы на доске.
Ход НОД:
Упражения биоэнергопластики (логопед повторяет с детьми по десять пар упражнений биоэнергопластики для мышц нижней челюсти, губ и языка и для кистей обеих рук, следит за правильным и синхронным выполнением каждым ребёнком. Упражнения каждой пары выполняются одновременно, повторяются 5-7 раз без перерыва).
Речевая разминка (игра с мячом «Лови и отвечай». Дети стоят полукругом перед логопедом. Логопед по очереди задаёт вопросы каждому ребёнку и бросает мяч. Ребёнок должен поймать мяч, дать полный ответ на вопрос и вернуть мяч логопеду. Темп игры постепенно увеличивается. Примерные вопросы: какое время года наступило? Какие изменения происходят в природе).
Основная часть НОД:

Логопед: посмотрите на веточки, которые стоят в нашей вазе. Это веточки черёмухи, берёзы и тополя. Что вы можете сказать о почках на них? (почки смолистые, они набухли и проклюнулись первые листочки). Понюхайте, как по-разному пахнут почки разных деревьев. Это запах бывает только весной, когда природа просыпается от зимнего сна.

Логопед: сегодня на занятии мы будем составлять  пересказ текста рассказа Л.Н.Толстого «Пришла весна». В этом рассказе мы почувствуем много запахов долгожданной весны и услышим много звуков природы.

Знакомство с текстом рассказа.

Логопед: послушайте рассказ «Пришла весна». Логопед выразительно читает детям рассказ. По ходу чтения объясняет значение слов и словосочетаний «торопливые ручьи», «шоколадные чешуйки почек», «песня малиновки», «переливаться на все лады», «молодо и на небе и на земле, и в сердце человека». Затем логопед задаёт вопросы и следит, чтобы ответы детей были полными.

Логопед: А теперь ответьте на мои вопросы.
О каком времени года говорится в рассказе?
Что можно увидеть на мокрых улицах?
Почему всё вокруг стало ярче?
Как солнышко греет весной?
Что происходит весной с ветвями деревьев?
Что происходит с чешуйками почек на деревьях?
Чем пахнут весной и лес, и сад?
О чём напоминает запах черёмуховой почки?
А какой аромат у почек берёзы?
Что можно сказать о запахах в лесу?
Как дышится в весеннем лесу?
Какая песня у малиновки?
Что можно сказать о молодом зеленеющем лесе?
Почему автор говорит о том, что становится молодо на небе?
А на земле? В сердце человека?
Вам понравился рассказ? Почему?
Физкультминутка. Игра на внимание «Примета весны или нет».
Логопед вразнобой называет приметы времён года. Если названа примета весны, дети хлопают в ладоши. Если названа примета другого времени года- топают правой ногой.
Составление пересказа текста по опорным рисункам-пиктограммам.
Логопед: сегодня мы составим пересказ текста по плану из опорных рисунков-пиктограмм. Рассмотрите цепочки рисунков-пиктограмм и подумайте, о чём нужно рассказать по каждой из них.

Логопед показывает детям пиктограммы, нарисованные маркером на доске (ручьи; очки – всё стало ярче; солнышко; ноты – ветви деревьев…тихо поют свою песню; почки на ветке; лес и сад; нос- разные запахи; почки и соцветия черёмухи; почки берёзы; малиновка с нотой- песня малиновки; небо, земля и сердце человека).
          Логопед: ещё раз послушайте рассказ Л.Н.Толстого «Пришла весна» и
          приготовьтесь составить его пересказ. Логопед повторно читает рассказ.
          После этого дети поочерёдно составляют предложения по цепочке рисунков-
          Пиктограмм. Логопед помогает им в случае затруднений.
Подведение итогов НОД. Логопед благодарит всех детей за старание.

Конспект составила учитель-логопед ГБОУ СОШ №16 СПДС «Красная Шапочка» Момогид Нажия Арслановна.


title: Характеристика на трудного ученика 8 класса

extracted_text:
Характеристика
 ученика ____класса МБОУ _СОШ                            ...                                   ,
___________года рождения
Ученик обучается в данной школе с _______класса, с ______ года.
Воспитывается в неполной многодетной семье. Кроме ученика в семье есть___________.  Мать работает сутками. Дети могут оставаться предоставленными сами себе.        Родительские собрания мать ученика не посещает, часто по уважительной причине (рабочая смена). В школу приходит  по вызову классного руководителя и учителей-предметников. С поведением ребенка не справляется.
    Ученик закончил первое полугодие 2014-2015 учебного года  удовлетворительно. За первую четверть имел неудовлетворительную оценку по алгебре.    За время учебы ученик показывает слабые способности по многим дисциплинам школьной программы в силу того, что у него совершенно отсутствует желание учиться.  Ученик  не готовит домашние задания, на уроках работает только при неоднократном напоминании учителя. Может нагрубить учителям.  Школьные принадлежности  не носит, объясняя это забывчивостью. Дневник  на выставление оценок учителям-предметникам не подает.
С классом складывались ровные, дружелюбные отношения. Участвовал в  классных  мероприятиях,  соревнованиях.
Посещал секцию по хоккею в ФОКе, участвовал в районных, областных соревнованиях. В данный момент секцию не посещает.
Ученик физически здоров. Курит.
Начал пропускать учебные занятия с ___________года. С января 2015 года посетил только 4 урока.
На данный момент не посещает уроки, но все учебное время находится в здании школы. Грубит учителям, техническому персоналу, используя нецензурные выражения. Срывает уроки, проходящие во вторую смену (забегает в классы, стучит в двери), безобразничает в коридорах и столовой. Не реагирует ни на чьи замечания. У ребенка появилось чувство вседозволенности.
   С учеником неоднократно проводили беседы классный руководитель, заместитель директора по воспитательной работе, заместители директора по учебной работе, социальный педагог.
Но учащийся к своим проступкам остается равнодушен, ни в чем не сознается, не осознает свои ошибки.


Презентация "Орфоэпия как раздел лингвистики. Произношение гласных звуков"


title: Технологическая карта урока "Огород на окне. «Что посеешь - то и пожнёшь»"

extracted_text:
Ортаңғы тобының ұйымдастырылған оқу іс - әрекетінің  технологиялық   картасы Технологическая карта организованной учебной деятельности                                                                                в  средней  группе.
Білім беру саласы\образовательная область: Познание.                                                 Бөлімі\раздел: Естествознание.                                                                                Тақырыбы\тема: «Огород на окне. «Что посеешь-то и пожнёшь» (практическая деятельность: посадка лука, посев овса)                                                                                Мақсаты\цель: обобщать знания детей об условиях необходимых для роста растений (тепло, свет, вода, уход). Формировать элементарные представления о труде по уходу за растениями. Воспитывать желание принимать участие в посильном труде.
Билингвалдық компоненті\Билингвальный компонент: пияз - лук

Күтілетін нәтиже\ожидаемый результат:
Ұғынады/воспроизводят: информацию о том, что из семян при посадке и уходе вырастают новые растения;  знания об условиях необходимых для роста растений (тепло, свет, вода, уход).
Түсінеді/понимает:  как ухаживать за растениями.
 Қолдалады/применяет: умение правильно осуществлять посадку семян и лука.


title: Презентация "Введение в тестирование ПО"

extracted_text:
Введение втестирование ПО

Содержание
Основы тестирования
Модели жизненного цикла разработки
Команда тестирования
Типы и уровни тестирования
Дефекты
Портрет тестировщика ПО
Основы тестирования
Что такое тестирование?
Для начала мы ...

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

Что такое тестирование? 1/2
Это процесс исполнения программы с целью обнаружения ошибок (“Искусство тестирования программ”, Г. Майерс, 1979)
Процесс наблюдения за выполнением программы в специальных условиях и вынесения на этой основе оценки каких-либо ее аспектов ([ANSI/IEEE standard 610.12-1990: Glossary of SE Terminology. NY:IEEE, 1987])
Техническое исследование программы для получения информации о ее качестве с точки зрения определенного круга заинтересованных лиц [С. Kaner, 1999]
Проверка соответствия между реальным поведением программы и ее ожидаемым поведением на конечном наборе тестов, выбранном определенным образом [IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004]

1980
1987
1999
2004

Что такое тестирование?  2/2
Процесс, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этим результатов работ с целью определить, что они соответствуют описанным требованиям, показать, что они подходят для достижения заявленных целей, а также для нахождения дефектов.
Определение тестирования «по частям» 1/5
Во-первых, тестирование – это процесс, а не единичное действие

Определение тестирования «по частям» 2/5
Процесс тестирования включен во все активности жизненного цикла

Определение тестирования «по частям» 3/5
Тестирование ПО может быть статическим и динамическим
Статическое тестирование: Тестирование компонента или системы на уровне спецификации или реализации без исполнения кода программного продукта, например рецензирование или статический анализ кода.
Динамическое тестирование: Тестирование, проводимое во время выполнения программного обеспечения, компонента или системы.

Определение тестирования «по частям» 4/5
Планирование
Подготовка
Оценка

Определение тестирования «по частям» 5/5
Тестированию подлежит программный продукт и связанные с ним рабочие продукты
Цели тестирования
Предоставление информации для принятия решений
Повышение уверенности в уровне качества
Обнаружение дефектов
Предотвращение дефектов

Тестирование помогает уменьшить общий уровень риска в системе после обнаружения и устранения дефектов и порождает уверенность в качестве ПО
Определение тестирования: сравнение как ключевое понятие
Тестирование всегда предполагает сравнение.

Что с чем сравнивается?
 Объект тестирования (что сравнивается)
Базис тестирования (с чем сравнивается)

Терминология
Объект тестирования: Компонент или система, которые должны быть протестированы.
Базис тестирования: Документ, на основании которого определяются требования к компоненту или системе. Документация, на которой базируются тестовые сценарии.
Если правка данного документа может быть осуществлена только в процессе формальной процедуры внесения изменения, то такой базис тестирования называется замороженным базисом тестирования.
Рабочие продукты 1/2
Рабочие продукты, поставляемые команде тестировщиков в качестве объектов тестирования, могут быть разными:
 отдельный модуль
 компонент (несколько модулей)
 подсистема
 система

Рабочие продукты 2/2
документация с требованиями (маркетинговая, пользовательская, техническая)
требования (функциональные , проектные, базы данных)
модели, диаграммы, макеты
сценарии использования
код
тестовые планы и сценарии
проектная документация по автоматизации тестирования, код автоматизации тестирования
другие документы или код

Что такое дефект?
Дефект: Изъян в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию, например неверный оператор или определение данных. Дефект, обнаруженный во время выполнения, может привести к отказам компонента или системы.

Баг – синоним слова «дефект»
Как определить дефект перед нами или нет?
Программа не делает чего-то, что она должна делать согласно техническим требованиям.
Программа делает что-то, чего она не должна делать согласно техническим требованиям.
Программа делает что-то, о чем в требованиях не упоминалось (?).
Программа не делает чего-то, о чем не говорится в требованиях, однако подразумевается, что она должна делать это.
Программа трудна для понимания, неудобна в использовании.

Связанные понятия: ошибка и отказ 1/2
Люди делают ошибки.
Если кто-то допустит ошибку в архитектуре или коде программы, то эта программа будет содержать дефект.
При исполнении программы любой дефект может привести к отказу.
Ошибка (Error)
Дефект
(Defect)
Отказ
(Failure)

Связанные понятия: ошибка и отказ 2/2
Ошибка: Действие человека, которое приводит к неправильному результату .

Отказ: Отклонение компонента или системы от ожидаемого выполнения, эксплуатации или результата.
Демонстрация дефекта - Требования
На примере программы TestKnight
Фрагмент требований:
Диалоговое окно Опций
Lines Number – размер шахматной доски (3…10)
Cell Side – размер стороны клетки в пикселях
Delay Between Moves, ms – пауза между движениями в процессе вычислений (0…5000). Используется для понимания принципов работы программы. Данную опцию следует использовать вместе с опцией
Show …
…..
Демонстрация дефекта - Программа

Демонстрация дефекта – Ошибка кодирования
Нет проверки (забыли ;-) ) на диапазон обозначенный в требований 3-10
Демонстрация дефекта – Сбой
Вводим в параметрах значение 0
Нажимаем Ок

Источники дефектов 1/2
Дефекты появляются по разным причинам, но, как правило, их источником являются технические требования (спецификация).

Источники дефектов 2/2
Цена дефектов 1/2
Обнаружение и исправление дефекта программы после поставки обходится в 100 раз дороже, чем на стадии формирования требований и проектирования.

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

Цена дефектов 2/2
Чем раньше дефект обнаружен, тем дешевле обходится его исправление
Терминология: «верификация» vs. «валидация» 1/3
Верификация:   Доказанное  объективными  результатами  исследования  подтверждение того, что определенные требования были выполнены

Терминология: «верификация» vs. «валидация» 2/3
Валидация - определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователей

Терминология: «верификация» vs. «валидация» 3/3
«Вы создаете продукт правильно ?»

«Вы создаете правильный продукт?»

Тестирование и качество 1/9
Что такое качество?
«Качество – это ценность для индивидуума…»

                           Дж. Вайнберг (1992)

Тестирование и качество 2/9
Вопрос:
Отвечает ли тестировщик за качество?
Обсуждение – 3 мин.

Тестирование и качество 3/9
В IT-индустрии широко используется два понятия, которые напрямую связаны с тестированием программных продуктов:
обеспечение качества (QA)
контроль качества (QC)

Зачастую роль тестирования понимается неправильно.
Мы, как специалисты по тестированию, не обеспечиваем качество своей деятельностью.

Тестирование и качество 4/9

Тестирование и качество 5/9
В контроль качества входят:
 Тестирование
 Рецензирование кода
 Статический анализ кода
 Внешняя оценка и аудит
В обеспечение качества входят :
 Усовершенствование процессов
 Контроль качества
Управление изменениями

реактивные действия

реактивные и проактивные действия

Тестирование и качество 6/9

Тестирование выполняется для сбора информации.
Поэтому тестирование – это лишь один из информационных сервисов.

    рабочий продукт
информация

Тестирование и качество 7/9
Как тестировщик может повлиять на качество?
Тестирование  - это возможный способ оценки качества программного обеспечения в терминах найденных дефектов, исполненных тестов и протестированных систем. Это может быть сделано как для функциональных требований, так и для нефункциональных требований и характеристик программного обеспечения.
Когда во время тестирования находятся ошибки, качество систем программного обеспечения повышается, если эти дефекты исправлены.

Тестирование и качество 8/9
Можно думать о себе, как о гаранте качества, но вы не создаете качество и не можете лишить продукт его.
Качество должно закладываться создателями продукта и зачастую для них это становиться неподъемной ношей.
Тестировщик призван помочь им решать эту задачу более эффективно.

Тестирование и качество 9/9
Любой проект похож на езду по дороге.  Проекты бывают легкие и типовые, но большинство напоминают заснеженную горную трассу. В этих проектах не обойтись без света фар.
Как тестировщик, вы освещаете дорогу.
7 принципов тестирования
Принцип 1 – Тестирование демонстрирует наличие дефектов

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

7 принципов тестирования
Принцип 2 – Исчерпывающее тестирование недостижимо
Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо, за исключением тривиальных случаев. Вместо исчерпывающего тестирования должны использоваться анализ рисков и расстановка приоритетов, чтобы более точно сфокусировать усилия по тестированию.
7 принципов тестирования
Принцип 3 – Раннее тестирование
Чтобы найти дефекты как можно раньше, активности по тестированию должны быть начаты как можно раньше в жизненном цикле разработки программного обеспечения или системы, и должны быть сфокусированы на определенных целях.
7 принципов тестирования
Принцип 4 – Скопление дефектов

Большая часть дефектов, обнаруженных при тестировании или повлекших за собой основное количество сбоев системы, содержится в небольшом количестве модулей.
7 принципов тестирования
Принцип 5 – Парадокс пестицида
Если одни и  те же тесты будут прогоняться много раз, в конечном счете этот набор тестовых сценариев больше не будет находить новых дефектов. Чтобы преодолеть этот “парадокс
пестицида”, тестовые сценарии должны регулярно пересматриваться и корректироваться, новые тесты должны быть разносторонними, чтобы охватить все компоненты программного обеспечения, или системы, и найти как можно больше дефектов.

7 принципов тестирования
Принцип 6 – Тестирование зависит от контекста

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

Вот такие ошибки …
F-16 вверх ногами
Испытания американского истребителя F-16 проводились, понятное дело, в северном полушарии. На заключительном этапе самолет решили проверить где-то в Латинской Америке, но уже с другой стороны экватора. При переводе самолета в режим автопилота он автоматически развернулся «вверх ногами».
Правильно выбирайте типы данных
Причиной взрыва 4 июня 1996 г. ракеты Ариан-5, была программная ошибка. В системе управления ракеты использовалось модифицированное программное обеспечение ранее успешно работавшее на Ариан-4, но Ариан-5 ускорялась быстрее предыдущей модификации, в результате когда на 40 секунде полета одна из вспомогательных подпрограмм попыталась преобразовать длинное целое значение в короткое без проверки величины значения, то вышло за границы типа, произошло отключение системы управления ракеты, и она была взорвана по команде на самоликвидацию. Прямой (вместе с ракетой-носителем был потерян коммуникационный спутник) и косвенный ущерб от этого программного сбоя был оценен в полмиллиарда долларов.

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

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

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

Тестирование – не обособленная процедура. Оно занимает свое место в жизненном цикле, который во многом определяет организацию тестирования.

Модель жизненного цикла разработки
Под моделью обычно понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного цикла.
Этапы:
анализ осуществимости; стратегическое планирование; анализ требований;
проектирование (предварительное и детальное);
кодирование (программирование);
отладка и тестирование; интеграция;
внедрение; эксплуатация и сопровождение.
Результат работ на каждом этапе
Ключевые события (точки принятия решений)

ЖЦ ПО: ключевые характеристики 1/2
Эффективность
Затраты/бюджет
Сроки
Приемлемое качество продукта

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

ЖЦ ПО: ключевые характеристики 2/2
Предсказуемость
Реальные трудозатраты и сроки находятся в запланированных (сметных) пределах
Управляемость
Возможность внесения корректив по ходу проекта (изменяющиеся требования и др.)
Сдерживание рисков
Устойчивость к влиянию внешних факторов

Модели жизненного цикла разработки
Каскадная модель
Итеративная или инкрементальная модель
Спиральная модель
Процесс разработки ПО зависит от выбранной модели разработки.
Каскадная модель
Наиболее популярный пример – водопадная модель.
Водопадная модель стала одной из первых разработанных моделей. Она предполагает строгое последовательное (во времени) выполнение всех фаз.
Проекты, в которых за основу взята данная модель, развиваются путем последовательного перехода от фазы к фазе, от первоначального замысла к конечному продукту.
Каскадная (водопадная) модель
Каскадная (водопадная) модель
Ключевые характеристики
Данная модель требует наличия четко-определенных требований, которые остаются неизменными на протяжении всего проекта.
Четкое планирование: каждый этап и его составные части планируется и включается в график до начала работ.
Продукт можно считать завершенным только после окончания последнего этапа.

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

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

Трудности тестирования в каскадной модели 1/3
#1 Поиск компромисса между качеством и сроками поставки
Поскольку тестирование начинается только в конце проекта, оно, как правило, выполняется в условиях нехватки времени. В таких ситуациях приходится выбирать между качеством и сроками поставки. Распространенная ситуация: тестировщики под давлением дают добро продукту, многие дефекты которого проявятся во время эксплуатации.
В таких ситуациях тестировщиков могут обвинить в том, что они тормозят процесс.

Трудности тестирования в каскадной модели 2/3
 #2  Разработчиков также поджимают  сроки, в результате чего они передают тестировщикам нестабильные и часто не поддающиеся тестированию системы. Это приводит к тому, что львиная часть графика тестирования уходит на то, что по своей сути, является вынужденным, повторным модульным тестированием.

Трудности тестирования в каскадной модели 3/3
#3 Позднее включение тестировщиков в проект
Когда тестировщики подключаются к работе на стадии формирования требований, тестирование выполняет превентивную функцию, анализируя требования и предотвращая попадание дефектов в код.
При подключении тестировщиков на более поздних стадиях тестирование выполняется в лучшем случае в рамках реактивной стратегии, в худшем – экспромтом. При этом нет ни предупреждения дефектов, ни четких границ, ни ограниченного объема тестирования.
Итеративная или инкрементальная модель
Итеративные или инкрементальные модели – это модели, в которых система реализуется и тестируется итерационно, блоками

Формирование требований, проектирование, сборка, и тестирование системы делиться на большое количество итераций. Примеры: Rapid Application Development (RAD), Rational Unified Process (RUP) и гибкие методологии разработки (Agile).
Итеративная или инкрементальная модель
Цикл «планирование-действие-проверка-корректировка»
Итеративная или инкрементальная модель
Ключевые характеристики
Система разрабатывается повторяющимися циклами (итеративная модель). Одновременно разрабатываются лишь небольшие части системы (инкрементальная модель)
В результате каждой итерации появляется рабочий продукт, являющийся частью конечного разрабатываемого продукта
Итеративная или инкрементальная модель
Преимущества
Гибкость в принятии новых требований или изменений
Возможность адаптации процесса на основе уроков, извлеченных из предыдущих итераций
Более короткие сроки вывода продукта на рынок: возможность получить отзывы от заказчиков/пользователей путем демонстрации рабочих частей системы
Недостатки
Стоимость продукта неизвестна
Могут возникнуть проблемы с архитектурой системы, поскольку требования для всего жизненного цикла программы не собираются заранее

Трудности тестирования в итеративной или инкрементальной модели
#1 Большие объемы регрессионного тестирования
Каждое расширение системы требует регрессионного тестирования всех функций и возможностей, представленных в предыдущих итерациях.
Поскольку наиболее важные функции и возможности, как правило, выполняются на более ранних итерациях, очень важно проследить, чтобы они не были повреждены.
Трудности тестирования в итеративной или инкрементальной модели
#2 Отсутствие четкого плана для обнаружения и устранения дефектов
Проявляется это в том, что программисты уделяют все рабочее время последующим расширениям в то время, как тестировщики тестируют текущую итерацию.
Как только тестировщики сообщают об обнаруженных дефектах, бизнес-аналитики, проектировщики и программисты, которые должны решать эти проблемы, начинают работать в режиме полной загрузки.
Трудности тестирования в итеративной или инкрементальной модели
#3 Отсутствие должного внимания и уважения к тестированию
Эта проблема не имеет всеобщего охвата, однако, в сообществе гибкой разработки есть, в некотором смысле пренебрежительное отношение к тестированию и связанными с ним активностями.
Спиральная модель
Система разрабатывается на основе ранних прототипов. Разработка движется от прототипа к прототипу, каждый из которых тестируется, затем перепроектируется и повторно прототипируется, после чего снова тестируется. И так до тех пор, пока все рискованные конструктивные решения не пройдут тестирование (или не пройдут и будут отвергнуты) .
Спиральная модель
Спиральная модель
Ключевые характеристики
Спиральная модель сочетает в себе концепцию итеративной разработки с систематикой и контролем водопадной модели:
Данная модель включает в себя большую часть этапов водопадной модели, и в том же порядке. Однако этапы отделены друг от друга планированием, оценкой рисков, прототипированием и имитацией.
На каждой итерации по всему циклу продукт является расширением более раннего продукта (как в итеративной модели)
Расширение модели осуществляется только после анализа рисков: во время каждого цикла проводиться поиск крупных рисков и делаются попытки по их устранению
Спиральная модель предназначена для крупных, дорогостоящих и сложных проектов (с высокими проектными рисками)

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

Трудности тестирования в спиральной модели
В силу особенностей самой модели, конструкция системы будет неизменно меняться.
Гибкость имеет первостепенное значение для решений, касающихся тестовых сценариев, тестовых данных, инструментов тестирования и тестового окружения на ранних этапах проекта. К примеру, если руководитель тестирования зациклен на каком-то одном способе генерации тестовых данных, а структура системного хранилища данных радикально меняется, скажем, от реляционной базы данных к XML файлам, потребуется значительная переработка тестовых артефактов, инструментов и подходов.
Трудности тестирования в спиральной модели
Специфичная, экспериментальная манера тестирования на ранних этапах проекта.
Тестирование ранних прототипов сводится к поиску неизвестного и тщательному тестированию сомнительных конструкций с целью обнаружить что-то, что не работает.
Повышение уверенности в качестве продукта не является целью, как правило. Такое раннее тестирование, которое переходит к выполнению более типичных функций на финальных этапах, требует от руководителя тестирования менять планы и стратегии по мере развития проекта. Опять же, гибкость здесь – ключевой фактор.
Трудности тестирования в спиральной модели

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

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

Команда тестирования
Команда тестирования
Независимость тестирования
Тип мышления, требуемый для тестирования и рецензирования, отличается от типа мышления, требуемого для разработки. С правильной установкой разработчики сами могут тестировать собственный код, однако ответственность за это передается тестировщику, как правило, для того чтобы сфокусироваться именно на тестировании и получить ряд дополнительных преимуществ, таких как независимый взгляд обученных и профессиональных тестировщиков. Независимое тестирование может быть выполнено на любом уровне тестирования.
Независимость тестирования
Независимость тестирования: Разделение  ответственностей,  которое позволяет выполнять объективное тестирование.
Уровни независимости
Ниже описываются несколько уровней независимости, в порядке от низкого к высокому:
 Разработчики тестируют собственный код (низкий уровень независимости)
 Независимые тестировщики (например, из команды разработчиков)
 Независимая команда или группа тестирования из другой организационной группы или независимые тестировщики (например, специалисты по тестиро- ванию удобства использования и производительности)
Независимые тестировщики, привлеченные на аутсорсинг или сторонние по отношению к организации.
Важность независимости тестирования 1/2
Причина 1 – Редактировать и править собственный код – не самая лучшая идея. Свежий взгляд необходим, т.к. проверяя свою работу, вы руководствуетесь теми же предположениями, что и при написании, а, значит, серьезные дефекты останутся незамеченными.
Например, программа может содержать ошибки, обусловленные  непониманием программиста поставленной задачи или технического задания. В этом случае, непонимание программиста, скорее всего, отразится и в самой программе.

Важность независимости тестирования 2/2
Причина 2 – Никому не нравится находить ошибки в своей работе. Это распространяется и на разработчиков программных продуктов.

Причина 3 – Смена фокусировки в проектной активности так же представляет собой проблему. После конструктивной работы по проектированию и написанию кода программисту чрезвычайно сложно переключиться, и вести в отношении собственной же программы деструктивную деятельность.
Команда тестирования
Команда
Взаимодействие в проектной команде
Роль тестировщика 1/6
Тестирование выполняет сервисную функцию. Как тестировщик, вы оказываете услуги по тестированию различным «заказчикам»:
Руководитель проекта (PM):
Руководитель проекта обязан быть в курсе деятельности тестировщика и влиять на нее. Тестировщик должен, в свою очередь, по запросу извещать PM’а о статусе тестирования, об обнаруженных серьезных проблемах, и не быть «бутылочным горлышком» для проекта.
Роль тестировщика 2/6
Программист:
Тестировщик облегчает работу программиста, сообщая ему о дефектах в его работе, причем, делая это быстро.
О тестировщика требуется понимание своего ремесла и знание продукта, чтобы не тратить время программиста ошибочными или поверхностными отчетами.
Роль тестировщика 3/6
Технический писатель:
Специалисты, пишущие руководства, получают неполную информацию о продукте. Тестировщик может лучше объяснить им, как работает программа и предостеречь от тех или иных ошибок в документации.
Писатели так же могут помочь группам тестирования. Изучая сам продукт и то, как он эксплуатируется, они могут предупредить тестировщиков о новых областях использования продукта, недочетах в тестовом плане и о дефектах, с которыми сталкиваются пользователи.
Роль тестировщика 4/6
Техническая поддержка
Тестировщики ставят группы поддержки в известность о тех аспектах продукта, которые могут доставить неудобства пользователям.
Специалисты из службы поддержи так же помогают тестировщикам, поскольку могут обосновать необходимость исправления дефекта.
Роль тестировщика 5/6
Отдел маркетинга:
Отдел маркетинга должен знать есть ли в продукте что-либо несоответствующее его ключевым характеристикам, которые должны быть поставлены заказчику. Дефект, который кажется незначительным разработчикам, может оказаться критически важным для маркетинга.
Также тестировщик может помочь отделу маркетинга в составлении точного отчета о возможностях продукта.
Роль тестировщика 6/6
Пользователь:
В сущности, тестировщик работает на пользователей продукта. Их удовлетворение является приоритетной задачей проекта и, конечно же, тестировщика
Типы и уровни тестирования
Уровень тестирования
Уровень тестирования: группа  задач по тестирования которые управляются совместно. Уровень тестирования связан с областями ответственности в проекте.
Примерами уровней  тестирования  могут  служить
компонентное  тестирование,
интеграционное тестирование,
системное тестирование
приёмочное тестирование.

Уровень тестирования
Для каждого уровня тестирования может быть определено:
Цель
Объекты тестирования
Прослеживание связи с базисом тестирования (при наличии)
Критерии входа и выхода
Артефакты процесса тестирования, которые будет поставлять отдел тестирования -  тестовые сценарии, протоколы тестирования, отчетность о результатах и другие
Тестовые методики
Измерения и метрики
Инструментарий

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

Так же известно, как модульное тестирование

Компонентное тестирование: общий обзор
Выполняется самим разработчиком (иногда модульное тестирование доверяется другому разработчику, не автору кода, для повышения уровня независимости)
Тестирование функциональных и нефункциональных характеристик программы
Могут быть использованы эмуляторы (заглушки и драйвера)

Компонентное тестирование
Пример кода
Компонентное тестирование
Модульный тест
Далее эту программу запускаем, таким образом автоматически тестирую код.
Компонентное тестирование
 Цель
Изолировать отдельные части программы и показать, что по отдельности все части работают.
 Объекты тестирования
Компоненты
Программы
Модули БД
Базис тестирования
Требования к компонентам
Детальный дизайн
Код

Компонентное тестирование
 Критерии входа
Бизнес- и функциональные требования выработаны и утверждены.
Разработка компонентов закончена.
Среда разработки стабильна.
Документация по тестовым сценариям модульных тестов составлена.
 Критерии выхода
Все тестовые сценарии модульных тестов исполнены. Тестовые результаты доступны.
Обнаруженные дефекты исправлены и закрыты.
Проверка кода завершена.
Все обнаруженные серьезные дефекты закрыты.

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

Компонентное тестирование
Инструментарий
Инструмент отладки
Интегрированная среда модульного тестирования
Junit
Nunit
Другие

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

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

Тестирование интеграции компонентов
Тестирование интеграции компонентов: Тестирование, выполняемое для  выявления  дефектов  в  интерфейсах  и  взаимодействии  между  интегрированными компонентами.

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

Тестирование интеграции компонентов
Цель
Удостовериться, что взаимодействие двух или более компонентов дает результат, отвечающий функциональным требованиям
Обнаружить проблемы интерфейса
Объекты тестирования
Подсистемы
Инфраструктура
Интерфейсы

Тестирование интеграции компонентов
Базис тестирования
Проект программы и системы
Архитектура
Технологический процесс (workflow)
Сценарии использования
Критерии входа
Модули для интеграционного тестирования закончены
Компонентное тестирование закончено
Проблемы, обнаруженные в компонентном тестировании, исправлены и закрыты
Сценарии интеграционного тестирования закончены
Среда интеграционного тестирования готова

Тестирование интеграции компонентов
Критерии выхода
Дефекты, обнаруженные во время интеграционного тестирования, исправлены и закрыты
Все тестовые сценарии исполнены; для каждого сценария есть результаты тестирования
Методы интеграционного тестирования
 «Большой взрыв» (“Big Bang)”
 «Сверху вниз» (“Top down”)
 «Снизу вверх»   (“Bottom up”)
Методы подробно разбираются в тренинге «SQA-028 Основы тест-дизайна»

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

Системное тестирование
Системное тестирование: Процесс тестирования системы в целом с целью проверки того, что она соответствует установленным требованиям

Системное тестирование: общий обзор
Выполняется тестировщиками
Тестирование функциональных и нефункциональных характеристик программы
Системное тестирование является разновидностью тестирования методом черного ящика, а, следовательно, не требует знания внутренней структуры кода или логики
Включает тестирование взаимодействия с операционной системой и системными ресурсами

Системное тестирование
Цель
Протестировать законченную, интегрированную систему, чтобы оценить ее соответствие указанным требованиям (функциональным/нефункциональным)
Объекты тестирования
 Система в целом
Базис тестирования
 Функциональная спецификация (FRS)
Спецификация системных требований к ПО (SRS)
Сценарии использования
Отчеты об анализе степени риска

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

Системное тестирование
Техники тест-дизайна
Эквивалентное разбиение
Анализ граничных значений
Тестирование таблицы решений
Тестирование всех пар (pairwise)
Тестирование состояний и переходов
Тестирование по сценариям использования
Измерения и метрики
Покрытие требований
Покрытие классов эквивалентности
Покрытие граничных значений

Системное тестирование
Отчетность
Данные по обнаруженным дефектам, как правило, заносятся в отчет и в систему управления дефектами
Инструментарий
Тестовые компараторы
Инструменты захвата/воспроизведения
Инструменты тестирования защищенности
Инструменты тестирования производительности
…

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

Приемочное тестирование: общий обзор
Выполняется заказчиком или пользователем системы
Поиск дефектов не является главной целью
Пользовательское приемочное тестирование проверяет готовность системы для использования;  Эксплуатационное тестирование проверяет насколько система пригода для эксплуатации в конкретном операционном окружении
Альфа тестирования выполняется в стенах компании, которая разрабатывает программный продукт. Бета тестирования выполняется заказчиком/пользователем на его оборудовании
Классификация тестирования
С исполнением и без исполнения кода:
	статическое / динамическое
Различные знания о структуре кода:
	черный ящик / серый ящик / белый ящик
По свойствам тестируемого объекта: функциональность, производительность, совместимость, надежность, удобство…
По изменениям:
    регрессионное тестирование, подтверждающее тестирование
По типу прогона тестов:
	ручное и автоматическое

С исполнением и без исполнения кода…
Статическое тестирование: Тестирование  компонента  или  системы  на  уровне спецификации  или  реализации  без  исполнения  кода  программного  продукта,  например, рецензирование или статический анализ.
Динамическое тестирование: Тестирование,  проводимое  во  время  выполнения программного обеспечения, компонента или системы.

Статическое тестирование
При статическом тестировании код исследуется вручную (рецензирование) или с помощью автоматизированных средств анализа (статистический анализ) без исполнения кода.
Объекты тестирования:
 Код
 Документация с требованиями
 Сценарии использования
 Руководства
.. и прочая проектная документация
Статическое тестирование
Преимущества рецензирования:
 раннее обнаружение и исправление дефектов
 улучшение продуктивности разработки
 уменьшение времени разработки
 уменьшение времени и стоимости тестирования
 сокращение стоимости жизненного цикла
 уменьшение числа дефектов и улучшение коммуникаций
могут быть найдены упущения в требованиях
Динамическое тестирование
Цель статического тестирования – поиск дефектов в продукте, в то время как цель динамического тестирования, обнаружение отказов системы. Только динамическое тестирование дает представление о поведении программы и позволяет выявить различия между ожидаемым и фактическим поведением.
Объекты тестирования:
Модуль
Интерфейс
Система
Различные знания о структуре кода…
Тестирование методом черного ящика
Тестирование методом черного ящика: Тестирование,  функциональное  или нефункциональное, без знания внутренней структуры компонента или системы.

Тестирование методом серого ящика
Тестирование методом серого ящика: Сочетает в себе тестирование методом черного и белого ящика.
Например, продукт тестируется методом черного ящика, но тестовые сценарии разрабатываются с разрабатываются с учетом знаний о внутренней структуре продукта.
Тестирование методом белого ящика
Тестирование методом белого ящика: Тестирование,  основанное  на  анализе внутренней структуры компонента или системы.

Синонимы:
тестирование на основе структуры
структурное тестирование
тестирование прозрачного ящика
тестирование методом прозрачного ящика –

По свойствам тестируемого объекта…
Функциональное тестирование
 Тестирование установки (инсталляции)
 Тестирование графического пользовательского интерфейса
  Нефункциональное тестирование
Тестирование производительности, нагрузочное тестирование, стрессовое тестирование
Тестирование обеспеченности технической поддержкой
Тестирование локализуемости
Тестирование практичности
Тестирование защищенности
…

Функциональное тестирование
Функциональное тестирование: Тестирование,  основанное  на  анализе спецификации функциональности компонента или системы.
Функциональное тестирование включает в себя:
Тестирование настройки и лицензирования
 Тестирование графического пользовательского интерфейса
…
Тестирование установки и лицензирования
Тестирование установки: Вид тестирования, ориентированный на то, что требуется пользователям для успешной установки, настройки и регистрации программного продукта. Процесс тестирования может включать полный и частичный процесс установки/удаления, а так же обновления программы
Тестирование целостности данных
Тестирование целостности данных: Вид тестирования, главной целью которого является проверка целостности данных после различных транзакций (ввод/выбор/обновление). Как правило, целостность данных проверяется в тестированиях методом белого и черного ящика
Тестирование защищенности
Тестирование защищенности: Тестирование  с  целью  оценить  защищенность программного продукта
Объекты тестирования:
пароли
шифрование
аппаратные устройства доступа
уровни доступа к информации
авторизация
скрытые каналы
безопасность на физическом уровне

Тестирование графического пользовательского интерфейса
Тестирование графического пользовательского интерфейса: Тестирование графического пользовательского интерфейса продукта с целью удостовериться в том, что он отвечает спецификациям

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

Тестирование производительности: в инженерии программного обеспечения тестирование, которое проводится с целью определения, как быстро работает система или её часть под определённой нагрузкой. Также может служить для проверки и подтверждения других атрибутов качества системы, таких как масштабируемость, надёжность и потребление ресурсов. http://ru.wikipedia.org/

Тренинг "SQA-033 Основы тестирования производительности"

Нагрузочное тестирование
Нагрузочное тестирование: Тип  тестирования  производительности,  проводимый  с  целью  оценки поведения  компонента  или  системы  при  возрастающей  нагрузке,  например  количестве параллельных  пользователей  и/или  операций,  а  также  определения  какую  нагрузку  может выдержать  компонент  или  система.
Стрессовое тестирование
Стрессовое тестирование: Вид  тестирования  производительности,  оценивающий систему или компонент на граничных значениях рабочих нагрузок или за их пределами, или же в  состоянии  ограниченных  ресурсов,  таких  как  память  или  доступ  к  серверу
Тестирование удобства использования
Тестирование удобства использования: Тестирование  с  целью  определения  степени понятности, легкости в изучении и использовании, привлекательности программного продукта для пользователя при условии использования в заданных условиях эксплуатации.
Тестирование по изменениям…
Подтверждающее тестирование: Тестирование,  во  время  которого  исполняются  тестовые сценарии,  выявившие  ошибки  во  время  последнего  запуска,  для  подтверждения  успешности исправления этих ошибок.
Регрессионное тестирование: Тестирование  уже  протестированной  программы, проводящееся после модификации для уверенности в том, что процесс модификации не внес или не активизировал ошибки в областях, не подвергавшихся изменениям. Проводится после изменений в коде программного продукта или его окружении
По типу прогона тестов..
Ручное тестирование: Процесс ручного тестирования продукта. Тестировщик играет роль конечного пользователя, используя максимальное количество функций программы, чтобы удостовериться в их корректной работе.
Автоматизированное тестирование: Использование  программного обеспечения  (помимо тестируемого ПО)  для  контроля  выполнения  тестов, сравнения  полученных  результатов  с  эталонными,  установки  предусловий  тестов  и  других функций контроля тестирования и организации отчетов.
Дефекты
Дефекты – основная продукция тестировщиков
Отчет о дефекте – основной продукт работы большинства тестировщиков.
Хорошими отчетами тестировщик зарабатывает себе хорошую репутацию. Плохие отчеты, написанные в критикующей манере и недостаточно обоснованные, создают дополнительную работу для программистов, тратят их время и формируют негативное впечатление от работы тестировщика.
Отчет о дефекте
Отчет о дефекте: Документ, содержащий отчет о любом недостатке в компоненте или системе,  который  может  привести  компонент  или  систему  к  невозможности  выполнить требуемую функцию.
Инструмент управления дефектами
Система  управления дефектами: Инструмент,  обеспечивающий фиксирование дефектов и изменений, а также поддержку их состояний. Часто имеет процессно-ориентированные  возможности  для  поддержки  и  контроля  распределения,  исправления  и повторной  проверки  дефектов,  а  также  возможности  отчетности

Тренинг "SQA-024 Основы управление  дефектами"
Жизненный цикл отчета об ошибке
Термин «ЖЦ отчета об ошибке» относится к различным стадиям, которые дефект проходит в инструменте управления дефектами за время своего жизненного цикла.

В большинстве проектных команд установлены правила о том, кто может менять статус дефекта или назначать его кому-либо. Например, только руководитель проекта может принять решение отсрочить исправление дефекта или же только тестировщик имеет разрешение на закрытие дефекта.
Пример ЖЦ дефекта 1/3

Пример ЖЦ дефекта 2/3
После сообщения о дефекте, отчет изучается коллегой тестировщика, сообщившего о нем, или руководителем тестирования.
Если при рецензировании дефект подтвердиться, открывается отчет о дефекте, и проектная команда должна принять решение, исправлять дефект или нет. В случае, если дефект подлежит исправлению, назначается программист для решения задачи.
Как только программист исправит дефект, отчет о нем возвращается тестировщику на подтверждающее тестирование. Если исправления не будут подтверждены результатами тестирования дефект будет переоткрыт и переназначен.

Пример ЖЦ дефекта 3/3
После подтверждения тестировщика об устранении дефекта, отчет о нем закрывается. Работы по нему заканчиваются.
Любой статус помимо «отклонен», «отложен» или «закрыт» требует работ по устранению дефекта до окончания проекта.  У отчета о дефекте в таком статусе есть владелец, ответственный за переход инцидента в следующий статус.
Стрелками на схеме показаны допустимые направления таких переходов.
Идентификатор. Уникальный ID, присваиваемый отчету о дефекте, который может быть использован при его поиске и упоминании о нем.
Краткое описание. Краткое описание дефекта.
Подробное описание. Детальное описание дефекта.
Влияние. Критичность и серьйозность  дефекта.

IEEE 829 Standard for Software Test Documentation

Отчет о дефекте 1/6

Отчет о дефекте 2/6
Краткое описание – очень важное поле, на которое будут обращать внимание руководитель проекта и прочие руководители, и исполнители, изучая список дефектов, которые не были или не будут устранены. Должно включать в себя:
краткое, но конкретное описание, которое даст читателю представление о характере проблемы
краткое описание границ и зависимостей дефекта (насколько узки или широки обстоятельства, обуславливающие данный дефект?)
краткое описание влияния или последствий данного дефекта

Отчет о дефекте 3/6
Описание инцидента может содержать следующую информацию:
Время и дата
Имя тестировщика
Аппаратные и программные конфигурации
Входные данные
Шаги процедуры
Ожидаемые результаты
Фактические результаты
Попытки воспроизвести дефект, описание испытанных средств
Прочие наблюдения и информация, которые могут помочь программисту обнаружить дефект

Отчет о дефекте 4/6
Влияние касается приоритета и критичности дефекта

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

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

Отчет о дефекте 6/6
Приоритеты:
Требует немедленного устранения, делает невозможным дальнейшее тестирование, явный дефект
Должен быть устранен до релиза
Устранить, когда будет время
Желательно устранить, но не препятствует релизу продукта
По мере развития проекта приоритеты могут  меняться

Классификация дефектов 1/6
Комментарии: Несоответствующие/некорректные/дезориентирующие или пропущенные комментарии в исходном коде
Ошибка в вычислениях: Неправильный расчет по формуле/ неправильная бизнес валидация в коде
Ошибка данных: Некорректная совокупность данных/обновление БД
Ошибка базы данных: Ошибка в схеме/структуре БД
Упущения при проектировании: Проектные данные/методы проектирования упущены/не отражены в документации и не отвечают требованиям

Классификация дефектов 2/6
Некорректное или условно-оптимальное проектирование: Проектные данные/методы проектирования требуют корректировки для того, чтобы считаться полными. Описанные конструктивные особенности не являются оптимальными для требуемого решения
Неправильное проектирование: Неправильное или неточное проектирование
Нечеткое проектирование: Проектные данные/методы проектирования не ясны для рецензента. Слова допускают двоякое толкование, проектные данные нечетки
Граничные условия не учтены: Граничные условия некорректны/не учтены

Классификация дефектов 3/6
Ошибка интерфейса: Внутренние или внешние по отношению к приложению ошибки интерфейса, некорректная обработка переданных параметров, неправильное расположение полей и объектов, неудобное положение окна/ экрана
Логическая ошибка: Отсутствующая, недостаточная, неактуальная или неоднозначная функциональность в исходном коде
Ошибки в сообщениях: Несоответствующие/некорректные/ошибочные или отсутствующие сообщения об ошибках в исходном коде
Ошибка навигации между объектами: Навигация неправильно воплощена в исходном коде

Классификация дефектов 4/6
Ошибка производительности: Ошибка, связанная с производительностью/ оптимальностью кода
Пропущенные требования: Неявные/явные требования были пропущены/не отражены в документах на стадии сбора требований
Неполноценные требования: Требования нуждаются в расширении для того, чтобы быть полными
Некорректные требования: Ошибочные или неточные требования

Классификация требований 5/6
Нечеткие требования: Требования не ясны рецензенту. Используются слова, допускающие двоякое толкование (например, вроде, возможно, может быть и т.д.)
Ошибка настроек времени/очередности: Ошибка, вызванная неверными/отсутствующими расчетами времени ожидания и очередности
Стандарты: Не соблюдаются стандарты, например, стандарты по проектированию/сбору требований/кодированию, имеющие отношение к проекту

Классификация требований 6/6
Системная ошибка: Аппаратные ошибки и ошибки ОС, потеря доступа к памяти, системный сбой
Ошибка тестового плана/сценария: Неполноценные/неверные/нечеткие/дублирующие или пропущенные тестовые планы/сценарии, неполная/неверная конфигурация тестов
Типографическая ошибка: Орфографические/грамматические ошибки в документации/исходном коде
Ошибка объявления переменных: Неверная декларация / использование переменных, ошибка несоответствия типов в исходном коде
Далеко не все дефекты устраняются…
В реальности далеко не все найденные дефекты устраняются. Некоторые не устраняются вовсе, исправление же некоторых откладывается до следующего релиза.

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

Далеко не все дефекты устраняются…
Причина 2 – Дефект вовсе не дефект. Может, вам доводилось слышать фразу: «Это не дефект, а такое свойство!». Это часто приводит к непониманиям, ошибкам в тестах или изменениям в спецификации, поскольку потенциальные дефекты рассматриваются как свойства системы.
Причина 3 – Устранять неисправность слишком рискованно. К сожалению, это случается очень часто. ПО – хрупкая и взаимосвязанная система. Устранение одной неисправности может привести к появлению других. Менять что-либо в программе незадолго до выпуска релиза может быть очень рискованной затеей. Лучше оставить в программе известный дефект, чтобы избежать риска появления новых, неизвестных.

Далеко не все дефекты устраняются…
Причина 4 – Это того не стоит. Дефекты, которые будут проявляться очень редко или в малоиспользуемых функциях, могут быть оставлены без изменений. Дефекты, которые можно обойти или предотвратить, так же часто не устраняются. Все сводится к оценке рисков.
Причина 5 – Неэффективный отчет о дефектах. Тестировщик недостаточно обосновал необходимость устранения определенного дефекта. В результате, дефект не был воспринят как таковой, был воспринят как не препятствующий выпуску продукта,  как слишком рискованный для устранения или просто как не стоящий усилий по устранению.

Упражнение
Представьте, что вы тестируете калькулятор Windows, который выдает: 1+1=2, 2+2=5, 3+3=6, 4+4=9, 5+5=10 и 6+6=13. Напишите отчет о дефекте, который бы эффективно описывал проблему.

5 мин на размышления
10 мин на разбор
Портрет тестировщика ПО
Личные навыки
Навыки тестирования ПО приобретаются через опыт или обучение в различных направлениях деятельности. Все нижеперечисленное может внести свой вклад в базу знаний тестировщика:
Использование программных систем
Знание предметной области или бизнеса
Участие в различных этапах разработки ПО, включая анализ, разработку и техническую поддержку
Участие в тестировании ПО

Использование программных систем
Пользователи программных систем хорошо знакомы с системой и точно знают, как она работает, какие именно неисправности имеют существенное влияние, и какова должна быть ожидаемая реакция системы .
Знание проблемной области или бизнеса
Пользователи с экспертизой в проблемной области знают области наибольшей важности для бизнеса и как они влияют на способность бизнеса решать проблемы. Эти знания могут быть использованы для приоритизации тестовых активностей, создании реалистичных тестовых данных и сценариев, и верификации или поставки сценариев использования.
Участие в различных этапах разработки ПО
Знание процесса разработки ПО (анализ требований, проектирование и программирование) дает понимание того, как появляются ошибки, где они могут быть обнаружены и как предотвратить их появление. Опыт технической поддержки дает знания о пользовательском опыте, ожиданиях и требованиях к практичности. Опыт в разработке ПО необходим для работы с профессиональными инструментами автоматизации тестирования, которые требуют опыта в программировании и проектировании.
Участие в тестировании ПО
К специфичным навыкам тестирования ПО относится умение анализировать спецификации, участвовать в анализе рисков, разрабатывать тестовые сценарии, а так же внимательно прогонять тесты и записывать результаты.
Навыки межличностного общения
Навыки межличностного общения такие, как умение критиковать и воспринимать критику, оказывать влияние на других и умение вести переговоры так же важны для тестировщика. Технически грамотный тестировщик, скорее всего, не справиться со своей задачей, если не овладеет и не будет использовать необходимые навыки межличностного общения.
Успешного специалиста в области тестирования так же отличает организованность, внимание к деталям и сильные навыки письменной и устной коммуникации.
Литература
Дополнительная литература
“Lessons Learned in Software Testing” by Cem Kaner, James Bach and Bret Pettichord
“Foundations of Software Testing” by Dorothy Graham, Erik van Veenendaal, Isabel Evans, Rex Black
“Software testing” by Ron Patton
“Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах” Роман Савин
“How to Break Software: A Practical Guide to Testing” James A. Whittaker


Презентация "Человек и его здоровье"


title: Презентация "Простые и сложные предложения" 4 класс

extracted_text:
Урок русского языка 4класс
                     Учитель
        Кашникова Наталья
               Владимировна
Мы должны знать русский язык, потому что он является языком межнационального общения.Итак, начинаем!
первая буква в названии части речи ,обозначающей предмет
(С)
с этой буквы пишем название падежа, который отвечает на вопрос "кто»
(И)
с этой буквы пишем название неизменяемой части речи, обозначающей признак действия или признак признака
 (Н)
первая буква в названии падежа ,отвечающего на вопрос "кем?»
(Т)
 третья буква в названии части речи, обозначающей действие
(А)
 буква, стоящая последней в названии изучаемого нами предмета
(К)
 первая буква в названии части слова, стоящей между корнем и окончанием
(С)
 эта буква - самый распространённый союз
(И)
звук, который мы слышим на конце слова "груз»
 (С)

Синтаксис – наука, изучающая строение и значение словосочетаний и предложений.
Тема: Простое и сложное предложение.
 Учимся отличать простое предложение  от сложного.

 Учимся расставлять знаки препинания в сложных  предложениях.

Правила работы в группе:

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

Я внимательно выслушал объяснение и пошёл вперёд.
[ ____            и                ].
Тронул лисёнок мышку,
 она убежала.
[            _____ ], [ _____            ].

  План действий

1. Выделить основу предложения.
2. Проверить к разным словам, и эти слова являются о, есть ли  однородные члены предложения. (Поставить вопросы к словам, если от одного слова задали один и тот же вопрос одним и тем же членом предложения – это однородные)
3. Начертить схему предложения.
4. Сделать вывод.
5. Расставить запятые.

Работа с учебником.

Вывод:

   Если части сложного предложения соединяет союз и, запятая ставится перед союзом.
   Если союз и соединяет два однородных члена, то запятая не ставится.
Продолжи предложения
1. Я научился…
2. Я понял…
3. Теперь я могу…
4. Было трудно…
5. Было интересно…
6. Сегодня я узнал…
Учите русский – годы кряду,
С душой, с усердием, с умом!
Вас ждёт великая награда,
И та награда в нём самом!

Спасибо за урок!


title: Презентация "Tипы и виды тестирования"

extracted_text:
Вопросы:
Изобразите (как сможете) ЖЦ дефекта.
Какие бывают резолюции дефектов?
Какие Вы знаете статусы дефектов?
1
ЛЕКЦИЯ 4«Tипы и виды тестирования»
Smoke
MAT

AT
Серый ящик
Белый ящик
Чёрный ящик
Автоматизированное
Ручное
Интуитивное
Исследовательское
По документации
Приемочное тестирование
Бета- тестирование
Альфа- тестирование
Модульное
Интеграционное
Системное
Регрессионное
Smoke
Валидация дефектов
Тестирование новых функций
Функциональное
Тестирование пользовательского интерфейса
Юзабилити
Доступности
Локализации
Интернационализации
кроссбраузерное
кроссплатформенное
нагрузочное
стрессовое
объемное
Безопасности
Защищенности
Тестирование требований
Тестирование прототипа
Тестирование инсталляции и лицензирование
4
Уровни тестирования
Тестовое покрытие –

это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода
5
Уровни тестирования
Тестовое покрытие определяется:

Глубиной тестирования
Шириной тестирования
Целями тестирования
Профессиональным уровнем тестирощика
6
Уровни тестирования
Ширина
Глубина
7
Уровни тестирования
Ширина тестирования
отражает количество модулей/функций приложения, которые были протестированы.
Глубина тестирования
отражает вид проверок, которые производились для модуля/функции (например, позитивность/негативность сценариев, тестирование в рамках/вне рамок тест сценариев и др.).
По уровню покрытия
Smoke – пригодность сборки для дальнейших тестов
Уровень качества: Acceptable / Unacceptable

MAT (Minimal Acceptance Test, Positive test) – тест на положительных сценариях
Уровень качества: High / Medium / Low

AT (Acceptance Test) – полный тест на положительных и негативных сценариях)
Уровень качества: High / Medium / Low
По цели тестирования
New Feature Test (NFT, AT of NF) – определить качество поставленной на тестирование функциональности

Обычно тестируется полным тестом (AT)
По цели тестирования
Regression testing – удостовериться, что добавление новой функциональности не повлияло на работу старой

Регрессионное тестирование может быть проведено на уровне Smoke, MAT или AT.
По цели тестирования
Defect Validation – проверка результата исправления дефектов

Может включать элементы регрессионного тестирования.

По цели тестирования
User Acceptance Test (UAT, ПиМИ): формальная проверка приложения (зачастую заказчиком), сопровождаемая протоколированием результатов

Тестовые активности:
Smoke
Регрессионное
Валидация дефектов
Тестирование новых функций
Автоматизированное
Ручное
По степени
автоматизации
15

Черный ящик: не заглядываем внутрь системы

По знанию кода
16

Черный ящик: не заглядываем внутрь системы

Белый ящик: смотрим код

По знанию кода
17

Черный ящик: не заглядываем внутрь системы

Белый ящик: смотрим код

Серый ящик: частично заглядываем в систему

По знанию кода
18
Модульное (Unit/component) – отдельные части (модули) системы

Интеграционное (Integration) –взаимодействие между отдельными модулями

Системное (System) – работоспособность системы в целом

По уровням
Интуитивное (Ad Hoc)
Исследовательское (Exploratory)
По документации
По подготовленности
Альфа- тестирование
Бета- тестирование
По времени и месту
проведения
По объекту
Функциональное
Тестирование пользовательского интерфейса
Юзабилити
Доступности
Локализации
Интернационализации
Совместимости (кроссбраузерное, кроссплатформенное)
Производительности (нагрузочное, стрессовое, объемное)
Безопасности
Защищенности
Тестирование требований
Тестирование прототипа
Тестирование инсталляции и лицензирование
22
Функциональное тестирование
Функциональное тестирование (Functional testing) – это тестирование функций приложения на соответствие требованиям.

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

Важным условием является ввод корректных и некорректных тестовых данных.
23
Тестирование графического интерфейса пользователя
Тестирование графического интерфейса пользователя (GUI) предполагает проверку соответствия приложения требованиям к графическому интерфейсу, профессионально ли оно выглядит, выполнено ли оно в едином стиле.
Как правило, через пользовательский интерфейс и реализуется большая часть функциональности ПО.
24
Тестирование графического интерфейса пользователя
Что нужно проверять?
Горячие клавиши (hot keys)
Порядок табуляции
Окна сообщений
Изменение размеров окон приложения
Поддержка скроллинга
25
Тестирование графического интерфейса пользователя
Пример
26
Тестирование программ установки и лицензирования
тестирование
В ходе тестирования установки (Installation testing) проверяется правильность процесса установки приложения и эффект, оказываемый установкой приложения на операционную систему конечного пользователя.

Тестирование механизма лицензирования помогает определить эффективность системы защиты приложения
27
Тестирование требований
Единичность
Завершённость
Последовательность
Атомарность
Актуальность
Выполнимость
Обязательность
Проверяемость
Характеристики требований
28
Совместимость с различными браузерами и операционными системами
Кроссбраузерность (Crossbrowser testing):
Цель данного типа тестирования – удостовериться, что приложение будет эффективно работать не только с Internet Explorer, но также и с альтернативными браузерами (Safari, Opera, FireFox, Google Chome и др.)

Кроссплатформенность (Crossplatform testing):
Цель кроссплатформенного тестирования – удостовериться, что приложение работает одинаково корректно и эффективно на любых типах и версиях операционных систем (ОС - Windows, Mac OS и Linux/Unix).
29
Тестирование интеграций
Тестирование интеграций (Integration testing) – проверка того, как одно приложение взаимодействует с другим.

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

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

В общем случае включает внедрение скриптов, операторов SQL, манипуляции с адресной строкой и исходным кодом программы
32
Тестирование удобства пользовательского интерфейса
Удобство пользования (Usability) – это степень эффективности, продуктивности и удовлетворенности, с которой продукт может использоваться определенными пользователями для достижения своих целей в определенном контексте (ISO 9241)
33
Тестирование удобства пользовательского интерфейса
Тестирование удобства пользования (Usability testing) определяет, насколько комфортна работа пользователей с приложением или сайтом в контексте понимания процесса работы, простоту навигации и структуры, понятность и последовательность сообщений. Этот вид тестирования в огромной степени определяет будущий успех или провал проекта.
34
Тестирование удобства пользовательского интерфейса
Критерии тестирования удобства пользования:

Функциональность
Визуальное оформление
Эффективность
Производительность
Обучаемость
Навигация
Логичность
Обратная связь
35
Тестирование доступности
Тестирование доступности (accessibility testing) необходимо, чтобы проверить соответствие программного обеспечения общепризнанным стандартам доступности. Практически все современные приложения, рассчитанные на широкую целевую аудиторию, должны быть доступны для использования людьми с ограниченными возможностями (зрительными, слуховыми, речевыми, когнитивными, невралгическими и др.), с учетом возраста, технических предпочтений и физических способностей.

36
Тестирование доступности
Критерии тестирования доступности:

Все изображения на сайте должны иметь альтернативный текст

Аудио содержимое должно иметь текстовый эквивалент

Страница должна быть читабельна при увеличенном размере шрифтов

Страница должна читаться на монохромном экране и др.

37
Тестирование локализации
Целью тестирования локализации (Localization testing, L10n) является проверка соответствия приложения региональным стандартам пользовательского интерфейса, языковым стандартам и др.
38
Тестирование локализации
В ходе тестирования локализации и интернационализации проверяются следующие аспекты:

Соответствие приложения стандартам оформления пользовательского интерфейса
Отсутствие непереведенных сообщений
Соответствие способа подачи данных региональным стандартам
Сортировка данных в алфавитном порядке
Совместимость приложения со стандартами различных регионов
Правильность оформления документации и вспомогательных файлов
39
Тестирование локализации
Примеры дефектов
40
Тестирование интернационализации
Тестирование интернационализации (Internationalization testing, i18n) – проверка того, каким образом происходит адаптация продукта.
Интернационализа́ция (англ. internationalization) — технологические приёмы разработки, упрощающие адаптацию продукта (такого как программное или аппаратное обеспечение) к языковым и культурным особенностям региона (регионов), отличного от того, в котором разрабатывался продукт.
41
Тестирование производительности
Тестирование производительности (Performance testing) — тестирование, которое проводится с целью определения, как быстро работает вычислительная система или её часть под определённой нагрузкой.
В тестировании производительности различают следующие направления:
нагрузочное (load)
стресс (stress)
объемное (volume)

Вам предоставляется на тестирование веб-проект – интернет магазин по продаже деталей для автомобилей.
Из планов разработки известно, что на тестирование будут поставлены 3 сборки:
#1 включает в себя 50% функциональности
#2 включает в себя оставшиеся 50% функциональности
#3 является финальной (release candidate) и будет отдана заказчику

Вопрос:
Какие тесты Вы проведете на каждой сборке?
Задача 1
43
Спасибо за внимание! Жду Ваших вопросов


title: Презентация "Об основах социального обслуживания граждан в Российской Федерации"

extracted_text:
Федеральный закон от 28 декабря 2013 года N 442-ФЗ «ОБ ОСНОВАХСОЦИАЛЬНОГО ОБСЛУЖИВАНИЯ ГРАЖДАН В РОССИЙСКОЙ ФЕДЕРАЦИИ»

 Настоящий Федеральный закон устанавливает
основы социального обслуживания
полномочия органов государственной власти
права и обязанности
правовые
организационные
экономические
федеральных
региональных
Получателей социальных услуг
Поставщиков социальных услуг
Социальное обслуживание граждан регулируется
настоящим Федеральным законом,
другими федеральными законами и иными нормативно-правовыми актами Российской Федерации и её субъектов.
Понятия
«социальная услуга» - действие или действия в сфере социального обслуживания по оказанию постоянной, периодической разовой помощи, в том числе срочной помощи, гражданину в целях улучшения условий его жизнедеятельности и расширения возможностей самостоятельно обеспечивать свои жизненные потребности
«социальное обслуживание»- деятельность по предоставлению социальных услуг гражданам
«стандарт социальной услуги»- основные требования к объёму, периодичности и качеству предоставления  социальной услуги получателю социальной услуги, установленные по видам социальных услуг
«профилактика обстоятельств, обусловливающих нуждаемость в социальном обслуживании»- система мер, направленных на выявление и устранение причин, повлиявших на ухудшение условий жизнедеятельности граждан
«получатель социальных услуг»- гражданин, который признан нуждающимся в социальном обслуживании и которому предоставляется социальная услуга
«поставщик социальных услуг»- юридическое лицо независимо от его организационно-правовой формы и индивидуальный предприниматель, осуществляющие социальное обслуживание
Принципы социального обеспечения
 гуманность, уважение достоинства личности и соблюдение прав человека
 равный, свободный доступ граждан к социальному обслуживанию
 адресность предоставления социальных услуг
 добровольность
 конфиденциальность
 приближенность поставщиков социальных услуг к месту жительства получателей социальных услуг
 достаточность количества поставщиков, а также их финансовых, материально-технических, кадровых и информационных ресурсов
 сохранение пребывания гражданина в привычной благоприятной среде

Из чего состоит система социального обслуживания?
Когда допускается разглашение персональной информации?
С письменного согласия получателя социальных услуг
или
органов, наделенных полномочиями по осуществлению государственного контроля (надзора) в сфере социального обслуживания
при обработке персональных данных в рамках межведомственного информационного взаимодействия
в иных установленных законодательством РФ случаях
органов дознания и следствия, суда

По запросу органов
Полномочия:
федеральных органов государственной власти

Полномочия:
уполномоченного федерального органа

Полномочия:
органов государственной власти субъектов РФ

Полномочия:
органов государственной власти субъектов РФ
(продолжение)

Действующие лица в законе
ПОСТАВЩИК
ПОЛУЧАТЕЛЬ
Обязанности сторон
ПОСТАВЩИК
предоставлять услуги получателям в соответствии с индивидуальными программами и условиями договоров
обязан
предоставлять бесплатно в доступной форме получателям информацию
защищать персональные данные Получателей
В общем, осуществлять свои услуги в соответствии с законодательством и договором, и всячески способствовать
Обязанности сторон
ПОСТАВЩИК
Вся основная информация о поставщике,
в соответствии со статьей 13, должна быть
обязан
открытой
и
   доступной
Обязанности сторон
ПОЛУЧАТЕЛЬ
обязан
Предоставлять необходимые документы
Информировать поставщиков о принципиальных изменениях
Соблюдать условия договора
Права сторон
ПОСТАВЩИК
запрашивать у органов необходимую информацию
имеет право
отказать в предоставлении услуг при нарушении договора
быть включенными в реестр поставщиков
А также, предоставлять дополнительные услуги за отдельную плату
Права сторон
ПОЛУЧАТЕЛЬ
имеет право
выбрать поставщиков социальных услуг
получить информацию о правах и обязанностях, соц. услугах и поставщиках
отказаться от услуг
на защиту своих прав и интересов
на соц. сопровождение
участвовать в составлении индивидуальных программ
на обеспечение соответствующих нормам условий пребывания в организациях соц. обслуживания
Кто имеет право на соц. обслуживание?
Обстоятельства
1. Утрата способности к само-обслуживанию
2. Инвалидность
3. Дети с трудностью в социальной адаптации
4. Отсутствие возможности ухода за детьми
5. Наличие внутрисемейного конфликта
6. Отсутствие определенного места жительства
7. Отсутствие работы и средств к существованию
8. наличие иных обстоятельств, которые нормативными правовыми актами субъекта РФ признаны ухудшающими или способными ухудшить условия жизнедеятельности граждан

Как стать получателем соц. услуг?
1) Принадлежать к одной из вышеупомянутых категорий
2) Подать заявление
3) Ожидать решение в течение 5 суток
признание гражданина нуждающимся в социальном обслуживании
отказ
2 экземпляра
Индивидуальная программа
составляется в течении 10 дней с момента подачи заявления
форма социального обслуживания + виды + объем + периодичность + условия + сроки предоставления + перечень рекомендуемых поставщиков + мероприятия по социальному сопровождению
ЧТО СОДЕРЖИТ?
Договор
в течении 1 суток с даты предоставления индивидуальной программы
ЗАКЛЮЧАЕТСЯ МЕЖДУ
Регистр получателей социальных услуг
содержит информацию о получателе социальных услуг:
формируется на основании данных поставщиков социальных услуг
  регистрационный номер учетной записи
  ФИО, пол, дата рождения
  контактные данные
  страховой номер индивидуального лицевого счета
  данные паспорта
  дата обращения
  дата оформления и номер индивидуальной программы
  наименование поставщика социальных услуг, реализующего индивидуальную программу
  перечень предоставления, стоимости, результатов социальных услуг
Порядок предоставления социальных услуг
обязателен для всех поставщиков
зависит от видов и форм социального обслуживания
включает
Межведомственное взаимодействие при организации социального обслуживания в субъекте РФ осуществляется на основе регламента, который определяет:
Перечень органов государственной власти субъекта Российской Федерации
Порядок, формы, виды деятельности, оценки результатов и осуществление контроля межведомственного взаимодействия
Требования к содержанию, формам и условиям обмена информацией
Механизм реализации мероприятий по социальному сопровождению
Профилактика обстоятельств, обусловливающих нуждаемость гражданина в социальном обслуживании
может проводиться в рамках региональных программ
осуществляется 2 путями
1. Обследование условий жизнедеятельности гражданина, определение причин, влияющих на ухудшение этих условий
2. Анализ данных государственной статистической отчетности, проведение выборочных социологических опросов
Социальное обслуживание осуществляется

на дому
в полустационарной форме
в стационарной форме

- по месту проживания
- в учреждении в определенное время суток
- в учреждении круглосуточно
       Независимая оценка качества оказания услуг организациями социального обслуживания –
это форма общественного контроля
ЦЕЛЬ: предоставить информацию о качестве оказания услуг организациями социального обслуживания, повысить качество их деятельности
В основе независимой оценки услуг лежат критерии
Особенности проведения независимой оценки качества оказания услуг

Состоит из не менее 5 человек
Формируются общественные советы по проведению оценки
Советы проводят независимую оценку качества оказания услуг

Информация, полученная в ходе независимой оценки

Не чаще
1 раза в год
Не реже
1 раза
в 3 года

  Рассматривается государственными органами в течении месяца

  Учитывается при выработке мер по совершенствованию социального обслуживания

 Размещается в Интернете
Для осуществления
Мониторинга
в сфере социального обслуживания
в субъекте Российской Федерации формируются
информационные системы в сфере социального обслуживания
реестр поставщиков
социальных услуг
регистр получателей
 социальных услуг
Государственного контроля
 (надзора)
Реестр поставщиков социальных услуг
размещается на официальном сайте уполномоченного органа субъекта РФ в интернете
содержит информацию о поставщике социальных услуг:
  наименование
  дата регистрации
  организационно-правовая форма
  контактные данные
   данные о руководителе
  информация о лицензиях
  сведения о формах социального обслуживания
  перечень социальных услуг, их тарифы и условия предоставления
  количество мест для предоставления социальных услуг
  результаты проверок
 опыт работы за последние 5 лет
Щербинин Максим, Ямбых ЮлияЛощилова Татьяна
Презентацию подготовили:
Спасибо за внимание!


title: Открытый урок "Короли, президенты и граждане" 4 класс

extracted_text:
Открытый урок по окружающему миру в 4г классе.
Подготовила учитель начальных классов  Нежельская О.П.

РАЗДЕЛ I. ЧЕЛОВЕЧЕСТВО
ГЛАВА IV. Многоликое человечество

Тема: КОРОЛИ, ПРЕЗИДЕНТЫ И ГРАЖДАНЕ
Цели:
создать образ эпохи Новейшего времени, учиться отличать современные явления, открытия, достижения от того, что было создано в другие эпохи;
ознакомить детей с различными формами правления государств, введение понятий монархия, республика, демократия.
нравственное воспитание, воспитание чувства патриотизма.

Урок построен в технологии критического мышления.

Оборудование: проектор, компьютер, экран, слайдовая презентация, распечатанные рассказы "Великобритания", "Соединенные Штаты Америки".


Презентация "Сообщения о планетах Солнечной системы" 3 класс


title: Конспект занятия "Пересказ рассказа К.Д. Ушинского «Петушок с семьёй»"

extracted_text:
         Пересказ рассказа   К.Д.Ушинского   « Петушок  с  семьёй».

Цели:

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

Образовательные задачи:

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

Воспитательные задачи:

Вызвать интерес к  домашним   птицам  и  животным, воспитывать бережное
отношение к   ним.

Словарная работа:

Учить сравнивать курицу и цыпленка на картинках; подбирать антонимы:
маленькие - большие; согласовывать существительные и прилагательные в роде
и падеже; обогащать словарь детей: наседка, хохлатка,   квохчет,
раскудахтались, вихор, долотцом.

Материал:

 предметные картинки с изображением курицы и цыплят,   петушка.

                                Ход занятия:

- Ребята, садитесь, пожалуйста, за столы. Я загадаю вам загадки:

- у   матери  двадцать   деток.

Все   детки  -   однолетки.

- Про кого эта загадка?  (про курочку).

-  А  это  загадка  про  кого?

Хвост  с  узорами   сапоги  со  шпорами.   (   Про     петушка).

 Посмотрите, какая    семья  пришла к нам в гости! (   картинка   с
изображением   петушка   с   семьёй).Рассмотрим  на  картинке  какого
цвета  у  петушка  пёрышки? (белые, пестрые, разноцветные).

Гребешок  красный,  бородка   красная,  на  ногах   шпоры,  на  хвосте
узоры.

-  Как   петушок   разговаривает?   (   ку – кА – ре – ку).

Рассмотрим  на  картинке  курочку,  какого  цвета  у  ней пёрышка  ?  (
пёстренькие  -  рябенькие).

- Как курочка разговаривает? (квох – квох – квох  или ко-ко-ко)

- А это кто? (цыплята). Расскажите, какие   цыплята? (маленькие,
пушистенькие,  похожие   на комочки ). Какого они  цвета?  ( одни   желтые,
золотистые;   другие   чёрненькие).  Чем похожи  мама   курочка,   папа
петушок   и  цыплята? (есть голова, крылышки, клювики).   А чем они не
похожи? ( курочка  и  петушок   большие ,  а цыплята   маленькие ). Какие
 цыплята?   (маленькие  и  беззащитные).      А    мама  курочка ?   (
заботливая, внимательная),   петушок   справедливый,   беспорядка  не
любит. Вспомним,  как в русских сказках курочку называют? (Курочка – ряба,
наседка, пеструшка, хохлатка),  а  петушка  «   петушок   золотой
гребешок,   голосистое   горлышко).

- Сейчас я вам прочитаю рассказ    К.Д.Ушинского    «  Петушок   с
семьёй». Догадались о чем будет рассказ? (   О   петушке, о курочке  и
цыплятах)). А чем отличается рассказ от сказки? (тем, что это было на самом
деле)

 Чтение рассказа.

                               Вопросы детям:

- Понравился вам рассказ писателя   К.Д.чарушина?

- Про кого этот рассказ? (про   петушка, курочку  и   цыплят )

- Где жила  семья   петушка? (на дворе)

- Что случилось? (  нашёл  петушок   зёрнышко)

-Что   он  сделал? (  позвал   :    «собирайтесь   с  цыплятками,  с
малыми   ребятками  я  вам   зёрнышко  припас!»)

- как  называет  петушок   курочек?  ( хлопотуньи  -  хозяюшки!)

- Что сделали  курочки  с  цыплятками? (  собрались,   раскудахтались,
зёрнышком   не   поделились,  -  передрались )

- Расскажите,   что  сделал   петушок? (  сейчас  семью   помирил:  ту   за
 хохолок,  того  за  вихор,  сам  зёрнышко  съел .)

 - А   что  сделал  потом?   (На   плетень  взлетел,  крыльями  замахал,
во  всё  горло   заорал   ку – кА – ре – ку!)

- правильно   ли  он  поступил?   (  ответы  детей)

- Сейчас я вам прочитаю рассказ еще раз (чтение  рассказа).

- А  теперь  нам     Дима   расскажет, как   петушок   гулял   по  двору
 и нашёл      зёрнышко, как он    с  ним  поступил ?

- Мирослава    расскажет,  почему  петушок  съел   сам  зёрнышко?

Пересказ 2-3 детей.

Всем детям дается положительная оценка.

                               Физкультминутка

Вышла курочка гулять

Махать прямыми ручками, как крылышками
И горошка поклевать.

Пальчики собрать в щепотку и «поклевать»
-Ко-ко-ко! Ко-ко-ко!

Махать ручками, посмотреть друг на друга
Зернышки клевать легко!

Пальчики собрать в щепотку и «поклевать»
- Ребята, про кого мы сегодня читали рассказ? (про   петушка  с  семьёй). А
фамилию автора запомнили? ( Ушинский  – он написал много рассказов о
ждивотных).  Правильно! Молодцы!

Приложение:

                             Петушок  с  семьёй.
                                (К.Д.Ушинский)
  Ходит   по   двору   петушок:   на  голове   красный   гребешок,  под
  носом   красная  бородка.  Нос   у  Пети  долотцом,    хвост   у  Пети
  колесцом;  на  хвосте   узоры,  на   ногах   шпоры.   Лапами   Петя
  кучу   разгребает,   курочек  с  цыплятами   созывает:
  «  кучки  -  хохлатушки!  хлопотуньи -  хозяюшки! Пёстренькие –
  рябенькие!  Чёрненькие  -  беленькие!  Собирайтесь  с  цыплятками,  с
  малыми   ребятками:   я  вам  зёрнышко   припас!»
    Курочки    с  цыплятками   собрались,  раскудахтались;    зёрнышком  не
   поделились,  -  передрались.
  Петя – петушок  беспорядков  не  любит  -  сейчас   семью   помирил:  ту
  за  хохолок,  того  за  вихор,  сам  зёрнышко  съел,  на  плетень
  взлетел,   крыльями  замахал,  во  всё   горло   заорал:  ку – кА – ре –
  ку!

1.После    занятия    включить  детям   видио – фильм   о   домашних
животных  авторы   составители   этого   замечательного   фильма,   которые
    показали  и   рассказали    рождение,   повадки   и  жизнь   домашних
животных  и  птиц   Я.И.Кубышкин,   С.Ю.Ромашина.

2. Во  второй   половине  дня   провести    вечер   загадок  и  отгадок  на
  тему:  «  Домашние   животные  и  птицы».

3.   Домашнее   задание:               Нарисовать    домашних   птиц
воспитанникам   привлекая   к  творчеству  и  родителей.

Конспект  занятия   по  развитию   речи    в   средней   группе.

                     Пересказ   рассказа   К.Д.Ушинский

                                    [pic]

                                    [pic]

                        Воспитатель: Гришкевич   О.В.