3 какие результаты должно обеспечивать тестирование

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

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

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

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

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

4. Любой человек, за исключением случаев, оговоренных законом, имеет право знать результаты своего тестирования. Итоговые данные в доступной для понимания форме предоставляет испытуемым тот, кто проводил обследование. Ознакомление с результатами тестирования должно исключать их неправильное толкование или появление у испытуемых каких-либо опасений. При этом тестирующий обязан подчеркнуть, что выводы по тестированию носят вероятностный характер и являются относительно достоверными только при условии правильного проведения теста и полной откровенности испытуемых. Эта вероятность зависит от конкретной тестовой методики и при правильной организации процедуры тестирования колеблется в пределах от 60 до 80%.

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

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

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

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

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

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

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


Источник:

  1. Пугачев В. П. Тесты, деловые игры, тренинги в управлении персоналом: учеб. для студентов вузов. — М. : Аспект Пресс, 2003. — 285с. (с. 25-27)

Независимо от формы проведения тестирования (с использованием ПЭВМ или без), при его организации и проведении следует придерживаться следующих принципов:

— испытуемые должны быть заранее осведомлены о месте и времени проведения тестирования, количестве заданий в тестах и примерном их содержании, правилах выполнения тестовых заданий и правилах их оценивания при проверке, количестве времени, отводимом на сдачу теста, минимальной сумме баллов, необходимой для получения положительной оценки*[12]. Для этого следует организовать для испытуемых предварительные консультации либо снабдить их соответствующими пособиями (инструкциями);

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

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

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

— продолжительность тестирования, одинаковая для всех без исключения испытуемых, устанавливается (и корректируется) на практике, в зависимости от цели тестирования (см. также табл. 1), объема и сложности тестов, уровня подготовленности испытуемых. В общем случае продолжительность тестирования должна быть такой, чтобы наиболее подготовленные успели выполнить не менее 90 % заданий теста*[13];

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

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

— способ обработки результатов тестирования должен обеспечивать небольшое время обработки, отсутствие ошибок, минимальное влияние каких-либо субъективных факторов (здесь очевидны преимущества тестирования с использованием ПЭВМ).

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

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

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

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

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

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

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

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

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

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

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

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

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

Читайте также:

©2015-2022 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-02-12
Нарушение авторских прав и Нарушение персональных данных



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


Мы поможем в написании ваших работ!

Ресурсы


4 абсолютных принципа качества:

  1. Качество определяется как соответствие требованиям.
  2. Способ обеспечения качества — предотвращение, а не оценка.
  3. Мера качества — цена несоответствия, а не индексы.
  4. Стандартом работы должно быть отсутствие дефектов.

Книги

  • (PDF) Тестирование программного обеспечения (Святослав Куликов, 2018). Курс хоть и позиционируется как «базовый», но предметная область расписана глубоко, наглядно, со множеством примеров.
  • (PDF) Как тестируют в Google (Джеймс Уиттакер, 2012; русский перевод 2014 — изд. «Питер»), не только об их опыте реформации процессов тестирования, но и о методах разработки и менеджмента; описанное релевантно больше для крупных продуктовых компаний. Насколько мне известно, на текущий момент Google уже отказался от ряда описанных нововведений.

Тестирование в условиях микросервисной архитектуры и Service mesh

  • Testing Strategies in a Microservice Architecture (Martin Fowler, 2014), статья Мартина Фаулера о тестировании в микросервисной архитектуре. Листать слайды стрелочками вверху.
  • История service mesh в компании (Александр Лукьянченко, Авито, 2019). Об изначальных проблемах, о подходе к Service Mesh, о проблемах с эксплуатацией Istio, о создании собственного решения в виде sidecar-сервиса Netramesh (Golang + K8s / bare metal), о внедрении OpenTracing с инструментом Jaeger (что позволяет получать карты взаимодействия сервисов), о тестах и выделении критичных путей, о своего рода канареечных тестах с подменой роутинга для тестов.
  • Реализация Consumer-Driven Contract подхода для тестирования микросервисов (Фрол Крючков, Авито, 2018)

Chaos testing

  • Chaos Engineering: искусство умышленного разрушения. Часть 1
  • Chaos Engineering: искусство умышленного разрушения. Часть 2
  • Chaos Engineering: искусство умышленного разрушения. Часть 3

Тестирование: QC И QA

Тестирование ПО = процесс исследования/испытания ПО, имеющий своей целью проверку соответствия между реальным и ожидаемым поведением ПО на конечном наборе тестов, выбранных определённым образом (ISO/IEC TR 19759:2005).

Цель тестирования или цель разработки и выполнения тестов:

  • обеспечить очищение ПО от ошибок до приемлимого уровня (вы не можете предоставить 100% покрытие, но вы должны сделать все возможное, и гарантировать, что очевидные ошибки исправлены);
  • убедиться, что ПО отвечает оригинальным требованиям и спецификации;

QA and QA scheme

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

Здесь очень подходит термин Verification с вопросом «Are we building the product right?» — правильно ли мы делаем продукт, проверяется соответствие планам, спецификациям, дизайну, правилам составления кода, проход тест-кейсов. Проверяем CORRECTNESS.

QA (Quality Assurance, обеспечение качества) = часть менеджмента качества, ориентированная на создание и настройку процессов, целью которых является обеспечение гарантии того, что требования к качеству будут выполнены (продукт будет соответствовать ожиданиям качества заказчика).

Состоит из процессов/действий, направленных на обеспечение качества разработки продукта на каждом из его этапов. Эти действия, как правило, предшествуют развитию продукта и продолжаются, пока процесс пребывает в состоянии развития. На самом QA лежит ответственность за разработку и внедрение процессов и стандартов для улучшения жизненного цикла разработки ПО (SDLC), и обеспечение уверенности в том, что эти процессы выполняются. Фокусом QA является предотвращение дефектов на всех этапах его реализации и постоянное его совершенствование.

Занимается вопросами «а какие виды и методы тестирования мы будем использовать?», «как будем измерять качество?» и т.п.

Здесь очень подходит термин Validation с вопросом «Are we building the right product?» — правильный ли продукт мы делаем, удовлетворяет ли продукт нуждам пользователя. Проверяем COMPLETENESS.

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

  • значимы для Заказчиков/Пользователей
  • оказывают влияние на мнение пользователя о работе с системой
  • снижают потенциальные затратные риски

Цикл тестирования

Цикл тестирования (Testing Cycle) напоминает типичный производственный цикл, обычно проходя в несколько этапов:

  1. Тест-анализ — анализ требований (Requirement analysis) и (опционально) Тестирование требований.

    Результат: Матрица трассировки Требований и Тест-кейсов (Requirement Traceability Matrix, RTM), зарегистрированные дефекты документации и более качественная документация для разработчиков.
  2. Планирование (Test Management, Test Planning).

    Результат: тест-план (Test Plan) / стратегия тестирования, оценка трудозатрат (Effort Estimation)
  3. Проектирование тестов (Test Design, Test Development).

    Результат: набор тест-кейсов (test cases), которые необходимо пройти, тестовые данные (test data)
  4. Выполнение (Test Execution). Используются методы тестирования (methods of testing).

    Результат: отчёт о тестировании, багрепорты (bug report).
  5. Анализ результатов тестирования (Test Result Analysis). Используются метрики (QA metrics).

    Результат: выводы для исправления ошибок в планировании и контроле над процессом тестирования/разработки.

Уровни тестирования

V-диаграмма тестирования

скачать схему в формате diagrams.net (бывший draw.io)

Что же касается относительного объёма тестов для ИТ-Продукта(ов), с гордостью представляю «Чашу тестов»:

Чаша тестов

скачать схему в формате diagrams.net (бывший draw.io)

Unit testing — Модульное тестирование

Модульное тестирование (Unit testing) = тестирование одного модуля кода (обычно это одна функция или один класс в случае ООП-кода) в изолированном окружении. Это значит, что:

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

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

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

Integration testing — Интеграционное тестирование

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

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

System testing — Системное тестирование

Системное тестирование (System testing) = процесс тестирования системы в целом с целью проверки того, что она соответствует установленным Спецификациям к Требованиям к ПО (SRS).

Удостовериться, что Система умеет принять какие-то данные от поставщиков, обработать их, передать данные потребителям, всё это в правильной последовательности и формате. Дальнейшая судьба данных нас не волнует. Главное — наша система работает правильно в правильном окружении.

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

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

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

API testing — тестирование API

Тестирование API (API testing) = процесс тестирования API приложения с целью проверки того, что реализация внешних интерфейсов соответствует установленным требованиям.

Тестирование API можно отнести и к интеграционному тестированию и к системному, в зависимости от того что мы в рамках своей задачи считаем тестируемой системой (SUT, system under testing) — отдельный сервис или некую платформу как совокупность сервисов.

Может включать в себя тестирование:

  1. WADL/WSDL SOAP API (XML)
  2. HTTP REST API, сиречь HTTP-request вида:

    • POST host:9090/entity с body, содержащим text/json/xml
    • GET host:9090/entity/1
    • PUT host:9090/entity/1 с body, содержащим text/json/xml
  3. HTTP non-REST API, сиречь HTTP-request вида:

    • POST host:9090/CreateEntity с body, содержащим text/json/xml
    • GET host:9090/GetEntity?id=1
    • POST host:9090/UpdateEntity с body, содержащим text/json/xml
  4. RPC-взаимодействия с сервером, например, в виде java-call клиентской библиотеки, см. gRPC
  5. Тестирование CDC (consumer driven contract) для всех вышеуказанных разновидностей API в виде:

    • Тестов клиентов сервисов-поставщиков. Обычное используется заглушка, которая автоматически формируется из контракта. Это позволяет избежать развёртывания окружения в виде Сервисов-Поставщиков.
    • Тестов для API сервисов-поставщиков. Они также могут генерироваться из контракта.

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

Инструменты для тестирования web-API

Postman = GUI-инструмент для тестирования REST/SOAP. Поддерживает создание скриптов для автотестов (Javascript).

  • Postman — desktop-приложение
  • Postman — расширение для Google Chrome, инструмент для тестирования API.
  • Как работать с Postman

SoapUI = GUI-инструмент для тестирования REST/SOAP. Поддерживает создание test-suit’ов со скриптами для автоматизации тестирования (разные ЯП).

  • SoapUI
  • Как протестировать приложение при взаимодействии с API с помощью SoapUI

cURL = CLI-инструмент для для взаимодействия с серверами по протоколам с синтаксисом URL.

  • cURL
  • шпаргалка, curl common options
  • Что JavaScript-разработчику следует знать о Curl

Acceptance testing — Приёмочное тестирование

Приёмочное тестирование (Acceptance testing) или Приёмо-сдаточные испытания (ПСИ) — формальный процесс тестирования, который проверяет соответствие системы Бизнес/Пользовательским требованиям и проводится с целью: определения удовлетворяет ли система приёмочным критериям, вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет. Выполняется на основании набора типичных тестовых случаев и сценариев, разработанных на основании требований к данному приложению.

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

End-to-End testing — Сквозное тестирование

Сквозное тестирование (End-To-End, E2E или Chain testing) = проверять не только наше окружение, но и все взаимосвязанные системы, через которые проходят данные принимаемые или отправляемые нашей системой. А это, в свою очередь, означает, что мы должны будем совместить несколько таких «пирамид тестирования» между собой. E2E тестирование это не просто приёмка (пользовательское тестирование), которое будет выполнять заказчик, это выстраивание мостика, с учётом всех возможных ситуаций, по которому пойдёт заказчик и поведёт за собой в ногу пользователей.

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

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

Сквозное тестирование (End-To-End, E2E или Chain testing)

скачать схему в формате diagrams.net (бывший draw.io)

Мартин Фаулер предупреждает о том, что написание и поддержка E2E-тестов достаточно дороги, а значит:

  • их не должно быть много
  • время прохода E2E-тестов должно исчисляться минутами, а не часами
  • E2E-тесты должны кореллировать с CJM
  • если какой-нибудь внешний сервис очень часто является причиной задержек в выполнении E2E-сценария, рекомендуется его исключить, организовав заглушку вместо него
  • нужно стараться делать E2E-тесты независимыми от предподготовленных данных, отсутствие или плохое качество которых часто является причиной ошибок. Если есть сервисы (воззможно, среди тестируемвых), которые предоставляют API по созданию объектов сущностей, то следует использовать его. Если такого нет, то нужные данные следует импортировать на уровне БД.

Виды тестирования

Функциональные тесты базируются на функциях и особенностях, а также взаимодействии с другими системами, и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing) и приёмочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы.

Нефункциональное тестирование описывает тесты, необходимые для определения характеристик программного обеспечения, которые могут быть измерены различными величинами. В целом, это тестирование того, «Как» система работает.

Квадранты тестирования

скачать схему в формате diagrams.net (бывший draw.io)

Функциональное тестирование (functional testing)

Функциональное тестирование

рассматривает заранее указанное поведение и основывается на анализе спецификаций функциональности компонента или системы в целом.

Функциональные тесты основываются на функциях, выполняемых системой, и могут проводиться на всех уровнях тестирования (компонентном, интеграционном, системном, приёмочном). Как правило, эти функции описываются в требованиях, функциональных спецификациях или в виде вариантов использования системы (use cases).


Функциональное тестирование бывает:

  • «Позитивное» (positive testing) — это тестирование на данных или сценариях, которые соответствуют нормальному (штатному, ожидаемому) поведению системы.

    Основной целью «позитивного» тестирования является проверка того, что при помощи системы можно делать то, для чего она создавалась.
  • «Негативное» (negative testing) — это тестирование на данных или сценариях, которые соответствуют нештатному поведению тестируемой системы — различные сообщения об ошибках, исключительные ситуации, «запредельные» состояния и т.п.

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

Позитивное тестирование является гораздо более важным, но это не означает, что «негативными» тестами можно пренебречь.

Подробнее о позитивном/негативном тестировании: https://www.guru99.com/positive-vs-negative-testing.html

Тестирование безопасности (security and access control testing)

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

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

Сканирование безопасности (Security Scanning): Включается в себя идентификацию сетевых и системных недостатков (слабых мест), а затем предоставляет решения для сокращения таких рисков. Сканирование может выполняться как в ручном так и автоматическом режимах.

Тест на проникновение (Penetration testing): симулирует нападение злоумышленника. Это тестирование включает анализ конкретной системы с целью проверить потенциальную уязвимость к внешним попыткам взлома.

Оценка риска (Risk Assessment): включает в себя анализ рисков безопасности, наблюдаемых в организации. Риски классифицируются как слабые (low), средние (medium) и высокие (high). Этот вид тестирования рекомендует методы контроля и снижения рисков.

Тестирование ролевой модели (testing of role model)

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

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

Во многих системах существует ролевая модель, в самом банальном исполнении это администратор и простой пользователь. В какой-нибудь банковской системе это может быть администратор, клиент, оператор, андеррайтер, специалист отдела X, Y, Z и т.д. В какой-нибудь системе складского учёта это может быть администратор, начальник склада, заместитель начальника склада, кладовщик, грузчик.

Каждая роль наделена определённым уровнем прав доступа к тем или иным функциям в АС (автоматизированной системе, ПО), к чтению/изменению/удалению данных на формах GUI, настройкам самой системы и т.п.

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

  1. доступны такие-то функции, а такие-то НЕ доступны.
  2. (не)доступны для чтения/редактирования/удаления такие-то данные на таких-то формах GUI.
  3. достаточно тех или иных прав для выполнений своих задач согласно сценариям использования системы, в которых его роль задействована. Т.е. он способен выполнять задачи в рамках отведённого ему (участка) бизнес-процесса.

Тестирование производительности (performance testing) или нагрузочное тестирование (load testing)

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

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

Стрессовое тестирование (stress testing) = тестирование приложения под экстремальными нагрузками, определение способности обрабатывать высокий уровень траффика или обработки данных. Целью является определить переломную точку приложения.

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

Тестирование выносливости (endurance testing) = убеждение в том, что приложение может безопасно находиться под высокими нагрузками долгий период времени.

Объёмное тестирование (volume testing) = получение оценки производительности при увеличении объёмов данных в базе данных приложения.

Тестирование удобства использования (usability testing)

Тестирование удобства пользования

— это метод тестирования, направленный на установление степени удобства использования, «обучаемости», понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. [ISO 9126]

Удобство (User Friendliness):

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

Эффективность (Efficiency):

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

Правильность (Accuracy):

  • нет грамматических, синтаксических ошибок, не выводятся устаревшие или неверные данные;
  • нет битых ссылок;

Тестирование на отказ и восстановление (failover and recovery testing)

Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети). Целью данного вида тестирования является проверка систем восстановления (или дублирующих основные функции систем), которые, в случае возникновения сбоев, обеспечат сохранность и целостность данных тестируемого продукта.

Тестирование на отказ и восстановление очень важно для систем, работающих по принципу «24×7», например интернет-магазины, ERP-системы.

Объектом тестирования в большинстве случаев являются весьма вероятные эксплуатационные проблемы, такие как:

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

Тестирование графического пользовательского интерфейса (GUI testing)

  1. проверить для всех элементов GUI размеры, позицию и принятие букв и цифр. Например, во всех полях ввода возможно производить ввод
  2. удостовериться, что графический интерфейс позволяет полностью реализовать весь функции приложения
  3. проверить верность отображения предупреждающий сообщений и сообщений об ошибках
  4. проверить читабельность шрифтов, используемых приложением, их выравнивание, цвет
  5. проверить отображение и расположение изображений
  6. проверить расположение элементов интерфейса при различных разрешениях экрана

Тестирование совместимости (compatibility testing)

Аппаратное обеспечение: совместимость с различными аппаратными конфигурациями.

Операционные системы: совместимость с различными операционными системами: Windows, *nix, Mac OS и т.д.

Программное обеспечение: совместимость с различным программным обеспечением. Например, MS Word совместим с MS Outlook, MS Excel, VBA и т.д.

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

Браузер: проверка совместимости веб-сайта с основными по-популярности: Firefox, Google Chrome, Internet Explorer, Opera, Safari.

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

Мобильные устройства: совместимость с мобильными платформами, такими как Android, iOS и т.д.

Версии программного обеспечения: совместимость с различными версиями программного обеспечения. Например, совместимость Microsoft Word с Windows 10, Windows 8, Windows 7, Windows XP, Windows XP SP2 и т.д.

Дымовое тестирование (Smoke testing)

Дымовые тесты выполняются каждый раз, когда мы получаем новый билд (версию), проекта (системы) на тестирование, при этом считая её относительно нестабильной. Нам нужно убедиться что критически важные функции Приложения/Системы работают согласно ожиданиям. Идея данного вида тестирования заключается в том, чтобы выявить серьёзные проблемы как можно раньше, и отклонить этот билд (вернуть на доработку) на раннем этапе тестирования, чтобы не углубляться в долгие и сложные тесты, не затрачивая тем самым время на заведомо бракованное ПО.

Ре-тест (Re-test)

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

Санитарная проверка (Sanity check)

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

Регрессионное тестирование (regression testing)

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

РТ занимает львиную долю времени, и как раз для сокращения затрат и существует автоматизация тестирования.

Пример, разъясняющий разницу между тестами после изменений

У нас есть веб-сервис с пользовательским интерфейсом и RESTful API. Будучи тестировщиками, мы знаем:

  • Что у него есть 10 точек входа, для простоты, в нашем случае расположенных на одном IP
  • все они принимают GET-запрос на вход, возвращая какие-либо данные в формате json

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

  • Выполнив один простой GET-запрос к одной из этих точек входа. Если от сервиса пришёл ответ в формате JSON, т.е. не вернул ошибку 4хх или 5хх или что-то невнятное, то он не «задымился». На этом можно сказать что «дымный» тест пройден. Для проверки того, что работает так же и UI достаточно просто один раз открыть страницу в браузере.
  • Санитарное тестирование в данном случае будет состоять из выполнения запроса ко всем 10 точкам входа в API.
  • Ре-тест в данном примере это точечная проверка что, к примеру, сломавшаяся точка входа в API следующем билде отрабатывает как задумывалось.
  • Регрессионные тесты будут состоять из Smoke + Sanity + UI выполняемые вместе в одной куче:

    • Выполнения запроса ко всем 10 точкам входа в API, сверкой полученного JSON с ожидаемым, а так же наличием требуемых данных в нём
    • проверить что добавление 11-ой точки входа не поломало, к примеру, восстановление пароля.

Пример регрессионного тестирования для условного банка

Пример регрессионного тестирования для условного банка

скачать схему в формате diagrams.net (бывший draw.io)

Методы: ручное и авто

Ручное (manual testing) = выполнение тестировщиком тестовых сценариев и тестовых случаев вручную.

К автоматизации тестирования (automation testing) существуют следующие основные подходы:

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

    Например, у Яндекс.Карт есть API геокодера. Отправив к нему запрос с географическим адресом, ты можешь получить координаты точки (и наоборот), а у Центробанка есть API, которое возвращает официальный курс валют в заданный день.

    Если у твоего приложения есть API, то можно тестировать его, посылая заранее подготовленные запросы и сравнивая пришедший ответ с ожидаемым.
  • тестирование пользовательского интерфейса — (GUI-тестирование). Имитация действий пользователя с помощью специальных тестовых фреймворков.

Некоторые инструменты для автоматизации тестов

  • серия программных продуктов Selenium
  • PhantomJS
  • JUnit
  • PhpUnit

Полезные статьи

  • Автоматизированное Функциональное Тестирование
  • Как стать автоматизатором тестирования?
  • Manual Testing Tutorial for Beginners
  • AUTOMATION TESTING Tutorial: Process, Planning & Tools
  • https://gist.github.com/codedokode/a455bde7d0748c0a351a — Автоматизированное тестирование
  • Антипаттерны тестирования ПО (unit-тесты, интеграционные тесты) (2018)

Баг-репорт

Баг репорт (bug report) = документ, описывающий ситуацию или последовательность действий, приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.

Составлять следует стремиться так, чтобы по названию или краткому описанию бага (summary) разработчик понял в чём соль проблемы, а прочитав детальное описание бага (description) он примерно представлял в в каком компоненте или даже его части ему надо искать ошибку.

Значимость/серьёзность (severity) ошибок
0 остановка системы server down остановка работы системы
1 Потеря данных data loss Потеря пользовательских, операторских, системных данных
2 Потеря функциональности functional loss Блокирование основной функциональности. Могут включать в себя нефункциональные проблемы, например связанные с производительностью, которые вызывает неприемлимые задержки в использовании функций
3 Дыра в безопасности security loss
4 Потеря функциональности с наличием обходного пути functional loss but alternate path exists Блокирование основной функциональности, но для пользователя существует разумный обходной путь
5 Частичная потеря функциональности partial functionality loss Блокирование использования некоторой несущественной функциональности
6 Косметическая ошибка cosmetic error Значительные недостатки в пользовательском интерфейсе или в способности системы реагировать на запросы пользователя

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

Правила оформления названия (subject) баг-репорта

Структура понятного названия таска:

<Где (название страницы)> : <Какой элемент/функция страницы> — <суть ошибки/задания>

Catalog Editor: Copy — not all existing catalogs shown in «select catalog» combobox

или Catalog Library -> Duplicate Catalog — If ‘Use audience’ option is marked, ‘Shared with’ data must be copied to the new catalog>

это годные названия. Ради того чтобы понять насколько проблема велика и срочна — не нужно открывать этот issue.

«Organizer», «Catalog properties page» — за такие названия тасков всего 400 лет назад отправляли на костёр. Потому что из него не понятно в чём суть, «ну page, ну и что, в чём проблема-то??».

Шаблон «тела» баг-репорта

DO: («ДЕЙСТВИЯ», «ШАГИ ВОСПРОИЗВЕДЕНИЯ»)

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

RESULT: («РЕЗУЛЬТАТ:»)

Опишите последствия ваших действий, расскажите, что случилось, когда достигнута «точка невозвращения» и как баг проявляет себя

EXPECTED RESULT: («ОЖИДАЕМЫЙ РЕЗУЛЬТАТ:»)

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

ADDITIONAL INFO: («ДОПИНФО:»)

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

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

Пример баг-репорта

bug report example

JIRA & Adaptavist

Не забыть настроить

в проекте JIRA:

  1. добавить пользователей
  2. распределить их по группам
  3. настройка workflow для Тасков
  4. настройка состава полей для Тасков
  5. настройка канбан-досок
  6. создание components для того, чтобы отмечать к каким сервисам какой Таск-ТК трассируются
  7. настройка ролёвки для adaptavist по вышесозданным группам + включить трассировку Таск—ТК

в Test Adaptavist, связанном с этим проектом:

  1. кастомные поля для ТК (кто автоматизатор, какие компоненты/сервисы используются)
  2. components для заполнения кастомного поля в ТК
  3. настройка предоставлений списка ТК
  4. посоздавать папки, раскидать ТК

Способы уведомления о готовности тасков к автоматизации

  1. ассайном таска, связанного ссылкой с ТК;
  2. сменой статуса такого таска
  3. упоминанием в комменте таска
  4. голосом на дэйли
  5. письмом
  6. сменой статуса ТК в адаптависте

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

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

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

Для реализации метода тестов должны быть изготовлены или заранее известны эталонные результаты.

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

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

Какими должны быть тестовые данные?

Тестовые данные должны обеспечить проверку всех возможных условий возникновения ошибок:

· должна быть испытана каждая ветвь алгоритма;

· очередной тестовый прогон должен контролировать нечто такое, что еще не было проверено на предыдущих прогонах;

· первый тест должен быть максимально прост, чтобы проверить, работает ли программа вообще;

· арифметические операции в тестах должны предельно упрощаться для уменьшения объема вычислений;

· количества элементов последовательностей, точность для итерационных вычислений, количество проходов цикла в тестовых примерах должны задаваться из соображений сокращения объема вычислений;

· минимизация вычислений не должна снижать надежности контроля;

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

· усложнение тестовых данных должно происходить постепенно.

Пример. Система тестов для задачи нахождения корней квадратного уравнения ax2 + bx + c = 0 :

Номер теста Проверяемый случай Коэффициенты Результаты
a b c
d > 0 -2 x1 = 1, x2 = -2
d = 0 Корни равны: x1 = -1, x2 = -1
d < 0 Действительных корней нет
a = 0, b = 0, c = 0 Все коэффициенты равны нулю. x — любое число
a = 0, b = 0, c № 0 Неправильное уравнение
a = 0, b № 0 Линейное уравнение; один корень: x = -0.5
a № 0, b № 0, c = 0 x1 = 0, x2 = -0.5

Из каких этапов состоит процесс тестирования?

Процесс тестирования можно разделить на три этапа.

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

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

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

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

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

? Как будет вести себя программа, работающая с массивами, если количество их элементов певысит величину, указанную в объявлении массива?

? Что произойдет, если числа будут слишком малыми или слишком большими?

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

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

Каковы характерные ошибки программирования?

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


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

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

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

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

Примеры синтаксических ошибок:

· пропуск знака пунктуации;

· несогласованность скобок;

· неправильное формирование оператора;

· неверное образование имен переменных;

· неверное написание служебных слов;

· отсутствие условий окончания цикла;

· отсутствие описания массива и т.п.

Какие ошибки не обнаруживаются транслятором?

Существует множество ошибок, которые транслятор выявить не в состоянии, если используемые в программе операторы сформированы верно.

Примеры таких ошибок.

Логические ошибки:

· неверное указание ветви алгоритма после проверки некоторого условия;

· неполный учет возможных условий;

· пропуск в программе одного или более блоков алгоритма.

Ошибки в циклах:

· неправильное указание начала цикла;

· неправильное указание условий окончания цикла;

· неправильное указание числа повторений цикла;

· бесконечный цикл.

Ошибки ввода-вывода; ошибки при работе с данными:

· неправильное задание тип данных;

· организация считывания меньшего или большего объёма даных, чем требуется;

· неправильное редактирование данных.

Ошибки в использов нии переменных:

· использование переменных без указания их начальных значений;

· ошибочное указание одной переменной вместо другой.

Ошибки при работе с массивами:

· массивы предварительно не обнулены;

· массивы неправильно описаны;

· индексы следуют в неправильном порядке.

Ошибки арифметических операций:

· неверное указание типа переменной (например, целочисленного вместо вещественного);

· неверное определение порядка действий;

· деление на нуль;

· извлечение квадратного корня из отрицательного числа;

· потеря значащих разрядов числа.

Эти ошибки обнаруживаются с помощью тестирования.

В чем заключается сопровождение программы?

Сопровождение программ — это работы, связанные с обслуживанием программ в процессе их эксплуатации.

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

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

Вопросы для самоконтроля

8.1. Какие основные этапы включает в себя решение задач на компьютере?

8.2. Какие этапы компьютерного решения задач осуществляются без участия компьютера?

8.3. Что называют математической моделью объекта или явления?

8.4. Почему невозможно точное исследование поведения объектов или явлений?

8.5. Какие способы моделирования осуществляются с помощью компьютера?

8.6. Из каких последовательных действий состоит процесс разработки программы?

8.7. Доказывает ли получение правдоподобного результата правильность программы?

8.8. Какие ошибки могут остаться невыявленными, если не провести проверку (просмотр, прокрутку) программы?

8.9. Чем тестирование программы отличается от её отладки?

8.10. Каким образом программа-отладчик помогает исследовать поведение программы в процессе её выполнения?

8.11. Как следует планировать процесс отладки программы?

8.12. Можно ли с помощью тестирования доказать правильность программы?

8.13. На какой стадии работы над программой вычисляются эталонные результаты тестов?

8.14. Назовите основные этапы процесса тестирования.

8.15. В чём заключается отличие синта ксических ошибок от семантических?

8.16. О чём свидетельствует отсутствие сообщений машины о синтаксических ошибках?

8.17. Какие разновидности ошибок транслятор не в состоянии обнаружить?

8.18. Для чего программам требуется сопровождение?

Упражнения

Составьте системы тестов для решения следующих задач:

8.1. Найти наибольший общий делитель двух заданных целых чисел.

8.2. Найти наименьшее общее кратное двух заданных целых чисел.

8.3. Определить, является ли заданное число нечетным двузначным числом.

8.4. Заданы площади квадрата и круга. Определить, поместится ли квадрат в круге.

8.5. Решить биквадратное уравнение.

8.6. Найти среднее арифметическое положительных элементов заданного одномерного массива.

8.7. Элементы заданного одномерного массива разделить на его первый элемент.

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

8.9. Определить, имеют ли общие точки две плоские фигуры — треугольник с заданными координатами его вершин и круг заданного радиуса c центром в начале координат.

8.10. Задано целое А > 1. Найти наименьшее целое неотрицательное k, при котором 2k > А.

8.11. Дана последовательность целых чисел. Определить, со скольких чётных чисел она начинается.

8.12. В заданном двумерном массиве найти количество строк, не содержащих нули.

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

8.14. Преобразовать число, заданное в римской системе счисления, в число десятичной системы.