4 формирование условий завершения процесса тестирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тест-стратегия включает в себя список тестовых случаев (Test Cases). В средах Microsoft Visual Studio 2010 Ultimate и Microsoft Test Manager 2010 тестовый случай – это рабочий элемент, состоящий из совокупности шагов, условий, а также параметров, необходимых для проверки корректности работы тестируемой функции.

После проведения тестирования формируется отчетная документация (отчет по тестированию программного продукта).

2. Тест-план

Тест-план составляется менеджером проекта. Тест-план должен включать в себя ответы на следующие вопросы:

§ Что представляет собой система (сведения о продукте, его назначение)?

§ Какие части продукта будут протестированы?

§ Потенциальные риски продукта (какие слабые места могут быть у продукта).

§ В какие сроки пройдет тестирование? (Указывается, какие виды тестирования (см. описание тест-стратегии) будут проходить на той или иной стадии (итерации) разработки продукта).

§ Кто будет тестировать?

Как правило, ответственным за проведение тестирования по тестовым случаям (конфигурационное и интеграционное), Usability- и Exploratory-тестирование назначается тестировщик.

Как правило, ответственным за проведение Unit-тестирования назначается разработчик тестируемой части программы, а тестирования производительности – один из разработчиков продукта.

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

§ Критерии окончания тестирования.

Составим тест-план для тестирования программы, разработанной в процессе выполнения лабораторной работы № 13.

Пример тест-плана для программы «Алгоритм Rijndael»:

1. Что представляет из себя система (сведения о продукте, его назначение)?

Программа «Алгоритм Rijndael» представляет собой WinForms-приложение, предназначенное для шифрования данных. Данное приложение может использоваться двумя типами пользователей – это человек, который зашифровывает данные (Шифровщик), и человек, который расшифровывает данные (Дешифровщик). Шифровщик может с помощью программы зашифровать данные. Дешифровщик может с помощью программы расшифровать уже зашифрованные с помощью алгоритма Rijndael данные.

2. Какие части продукта будут протестированы?

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

3. Потенциальные риски продукта (какие слабые места могут быть у продукта).

Основным риском тестируемой системы является риск некорректной зашифровки и расшифровки данных.

4. В какие сроки пройдет тестирование?

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

5. Кто будет тестировать?

Ответственным за проведение тестирования назначается тестировщик.

6. Критерии окончания тестирования.

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

МегаПредмет



Обратная связь

ПОЗНАВАТЕЛЬНОЕ

Сила воли ведет к действию, а позитивные действия формируют позитивное отношение


Как определить диапазон голоса — ваш вокал


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


Целительная привычка


Как самому избавиться от обидчивости


Противоречивые взгляды на качества, присущие мужчинам


Тренинг уверенности в себе


Вкуснейший «Салат из свеклы с чесноком»


Натюрморт и его изобразительные возможности


Применение, как принимать мумие? Мумие для волос, лица, при переломах, при кровотечении и т.д.


Как научиться брать на себя ответственность


Зачем нужны границы в отношениях с детьми?


Световозвращающие элементы на детской одежде


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


Как слышать голос Бога


Классификация ожирения по ИМТ (ВОЗ)


Глава 3. Завет мужчины с женщиной


Оси и плоскости тела человека

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


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


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

Помощь в ✍️ написании работы

Курсовая работа по дисциплине «Тестирование ПО»

Задание.

1.Написать приложение, которое будет тестироваться, в соответствии с вариантом задания. Номер варианта совпадает с порядковым номером в списке группы. В интерфейсе пользователя необходимо отразить сортировку с помощью визуальных объектов (например, в виде диаграммы). Архитектура MVC.

№ варианта задание
Тип сортировки Интерфейс пользователя Метод хранения данных
Быстрая сортировка Сортировка слиянием Пирамидальная сортировка Корневая сортировка Сортировка Шелла Пузырьковая сортировка Сортировка вставками графический веб файл txt файл xml
+             +   +  
  +             +   +
    +         +   +  
      +         +   +
        +     +   +  
          +     +   +
            + +   +  
+               +   +
  +           +   +  
    +           +   +
      +       +   +  
        +       +   +
          +   +   +  
            +   +   +
+             +   +  

2.Задание по тестированию. Результаты работы над курсовым проектом необходимо оформить в виде документа, содержание которого соответствует приведенному ниже. Для создания документации можете попробовать использовать https://github.com/allure-framework. Вся тестовая документация должна быть оформлена в соответствии со стандартом IEEE-829-1998 (при желании можно взять стандарт 2008 года). В случае исключения какого-либо пункта требуется обосновать свое решение во введении. Работы, с одинаковыми выводами и тестами не принимаются! Библиотечные функции сортировки не использовать!

1.Титульник

2.Задание

3.Введение (каковы цели, задачи тестирования, зачем оно нужно, контроль качества ПО…)

4.Схема проекта (отразить все классы, их методы и поля, а также связи между классами). Можно нарисовать в DPAToolkit.

5.Тест-план (строго в соответствии со стандартом IEEE-829-1998 или 2008).

6.Тест-кейсы (должны быть оформлены в соответствии с примерами).

7.Выводы (копии с работ одногруппников не принимаются).

8.Литература.

Теоретические сведения

1.Все чаще используются итеративные процессы разработки ПО, в частности, технология RUP — Rational Unified Process . На рисунке можно увидеть жизненный цикл продукта по RUP. При использовании такого подхода тестирование перестает быть процессом «на отшибе», который запускается после того, как программисты написали весь необходимый код. Работа над тестами начинается с самого начального этапа выявления требований к будущему продукту и тесно интегрируется с текущими задачами. И это предъявляет новые требования к тестировщикам. Их роль не сводится просто к выявлению ошибок как можно полнее и как можно раньше. Они должны участвовать в общем процессе выявления и устранения наиболее существенных рисков проекта. Для этого на каждую итерацию определяется цель тестирования и методы ее достижения. А в конце каждой итерации определяется, насколько эта цель достигнута, нужны ли дополнительные испытания, и не нужно ли изменить принципы и инструменты проведения тестов. В свою очередь, каждый обнаруженный дефект должен пройти через свой собственный жизненный цикл.

Жизненный цикл продукта по RUP.

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

В соответствие с соотношением различных задач в итерации они группируются в фазы. В первой фазе — Начало — основное внимание уделяется задачам анализа. В итерациях второй фазы — Разработка — основное внимание уделяется проектированию и опробованию ключевых проектных решений. В третьей фазе — Построение — наиболее велика доля задач разработки и тестирования. А в последней фазе — Передача — решаются в наибольшей мере задачи тестирования и передачи системы Заказчику.

Рисунок. Итерации жизненного цикла программного продукта.

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

2. Методология тестирования. В терминологии тестирования фразы «тестирование белого ящика» и «тестирование чёрного ящика» относятся к тому, имеет ли разработчик тестов доступ к исходному коду тестируемого программного обеспечения, или же тестирование выполняется через пользовательский интерфейс либо прикладной программный интерфейс, предоставленный тестируемым модулем.

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

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

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

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

Модульное тестирование (Unit-testing) — уровень тестирования, на котором тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. На этом уровне применяются методы «белого ящика».

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

Системное тестирование (System testing) — это тестирование программного обеспечения, выполняемое на полной, интегрированной системе, с целью проверки соответствия системы исходным требованиям. Системное тестирование относится к методам тестирования «чёрного ящика», и, тем самым, не требует знаний о внутреннем устройстве системы. Системное тестирование выполняется через внешние интерфейсы программного обеспечения и тесно связано с тестированием пользовательского интерфейса (или через пользовательский интерфейс), проводимым при помощи имитации действий пользователей над элементами этого интерфейса. Частными случаями этого вида тестирования являются тестирование графического пользовательского интерфейса (Graphical User Interface, GUI) и пользовательского интерфейса Web-приложений (WebUI).

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

Рисунок. Уровни тестирования.

Статическое тестирование (Static testing)– тестирование, в ходе которого тестируемая программа (код) не выполняется (запускается). Анализ программы происходит на основе исходного кода, который вычитывается вручную, либо анализируется специальными инструментами. Примеры статического тестирования:

– обзоры (Reviews);

– инспекции (Inspections);

– сквозные просмотры (Walkthroughs);

– аудиты (Audits).

Динамическое тестирование (Dynamic testing) – тестирование, в ходе которого тестируемая программа (код) выполняется (запускается).

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

Регрессионное тестирование (Regression testing) – тестирование функциональности, которая была уже протестирована до внесения какого-либо изменения. После внесения изменений в очередную версию программы, регрессионные тесты подтверждают, что сделанные изменения не повлияли на работоспособность остальной функциональности приложения. Регрессионное тестирование может выполняться как вручную, так и средствами автоматизации тестирования.

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

Функциональное тестирование (Functional testing) — цель данного тестирования состоит в том, чтобы убедиться в надлежащем функционировании объекта тестирования:

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

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

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

– продемонстрировать, что система удовлетворяет критериям производительности при заданных условиях;

– измерить, какая часть системы является причиной «плохой» производительности системы;

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

Стрессовое тестирование (Stress testing) — обычно используется для понимания пределов пропускной способности приложения. Этот тип тестирования проводится для определения надёжности системы во время экстремальных нагрузок и отвечает на вопросы о достаточной производительности системы в случае, если текущая нагрузка сильно превысит ожидаемый максимум.

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

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

Тестирование удобства использования (Usability testing) — исследование, выполняемое с целью определения, удобен ли некоторый искусственный объект (такой как вебстраница, пользовательский интерфейс или устройство) для его предполагаемого применения. Таким образом, проверка эргономичности измеряет эргономичность объекта или системы. Проверка эргономичности сосредоточена на определённом объекте или небольшом наборе объектов, в то время как исследования взаимодействие человек-компьютер в целом — формулируют универсальные принципы. Это метод оценки удобства продукта в использовании, основанный на привлечении пользователей в качестве тестировщиков, испытателей и суммировании полученных от них выводов. При испытании многих продуктов пользователю предлагают в «лабораторных» условиях решить основные задачи, для выполнения которых этот продукт разрабатывался, и просят высказывать во время выполнения этих тестов свои замечания. Процесс тестирования фиксируется в протоколе (логе) и/или на аудио- и видеоустройства — с целью последующего более детального анализа. Если юзабилити-тестирование выявляет какие-либо трудности (например, сложности в понимании инструкций, выполнении действий или интерпретации ответов системы), то разработчики должны доработать продукт и повторить тестирование.

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

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

5.Процесс тестирования.

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

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

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

Рисунок. Схема процесса тестирования.

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

Принципы организации тестирования.

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

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

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

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

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

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

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

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

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

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

Планирование тестирования

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

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

Однако вне зависимости от модели разработки при планировании тестирования необходимо ответить на пять вопросов, определяющих этот процесс:

кто будет тестировать и на каких этапах? Разработчики продукта, независимая группа тестировщиков или совместно;

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

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

– как надо тестировать? Будет ли тестирование сосредоточено только на проверке того, что данный продукт должен выполнять, или также на том, как это реализовано;

– в каком объеме тестировать? Как определить, в достаточном ли объеме выполнено тестирование, или как распределить ограниченные ресурсы, выделенные под тестирование.

Все ответы на поставленные вопросы и многое другое фиксируется в документе – Тест-план.

b)Тест план (Test Plan) – это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.

Тест-план содержит:

1) перечень тестовых ресурсов;

2) перечень функций и подсистем, подлежащих тестированию;

3) тестовую стратегию:

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

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

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

4) график (расписание) тестовых циклов;

5) указание конкретных параметров аппаратуры и программного окружения;

6) определение тестовых метрик, которые необходимо собирать и анализировать, таких как покрытие набора требований, покрытие кода, количество и уровень серьезности дефектов, объем тестового кода и т.п.

Тест план должен как минимум отвечать на следующие вопросы:

1) что надо тестировать? Описание объекта тестирования: системы, приложения, оборудование;

2) что будете тестировать?Список функций и описание тестируемой системы и её компонент в отдельности;

3) как будете тестировать? Сстратегия тестирования, а именно: методологии, виды тестирования и их применение по отношению к тестируемому объекту, приоритеты, автоматизация и пр.;

4) когда будете тестировать? Последовательность проведения работ: фазы, циклы тестирования, процедура тестирования — подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки;

5) где будете тестировать?

– окружение тестируемой системы – описание;

– необходимое для тестирования оборудование и программные средства.

6) кто будет тестировать?

– роли и обязанности;

– имена и фамилии.

7) критерии начала тестирования:

– готовность окружения;

– готовность тест кейсов;

– законченность разработки требуемого функционала;

– выполнение юнит-тестов;

– билд построен и удовлетворяет определенным критериям.

8) критерии окончания тестирования:

– результаты тестирования удовлетворяют определенным критериям;

– требования к количеству открытых багов выполнены (определяются заранее).

9) критерии передачи системы для приемочного тестирования:

– приемочные тесты – где хранятся и когда выполняются;

– процедура приемки.

10) какие риски существую и как мы ими будет управлять? Риски и их разрешение

11) метрики и отчеты:

– продуктовые метрики – кто собирает, с какой периодичностью;

– отчеты — кто создает, кому отправляет, и т.п.

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

– окружение тестируемой системы (описание программно-аппаратных средств);

– необходимое для тестирования оборудование и программные средства (тестовый стенд и его конфигурация, программы для автоматизированного тестирования и т.д.);

– риски и пути их разрешения.

c)Виды тест-планов. Чаще всего на практике приходится сталкиваться со следующими видами тест планов:

1)мастер тест-план (Master Plan or Master Test Plan);

2)тест-план (Test Plan);

3)план приемочных испытаний (Product Acceptance Plan) — документ, описывающий набор действий, связанных с приемочным тестированием: стратегия, дата проведения, ответственные и т.д.;

4) план автоматизации (Test Automation Plan) — документ, описывающий набор действий, связанных с автоматизацией тестированием: стратегия, правила, ответственные и т.д.

Явное отличие Master Test Plan от просто Test Plan в том, что мастер тест-план является более статичным в силу того, что содержит в себе высокоуровневую информацию, которая не подвержена частому изменению в процессе тестирования и пересмотра требований. Сам же детальный тест план, который содержит более конкретную информацию по стратегии, видам тестировании, расписанию выполнения работ, является «живым» документом, который постоянно претерпевает изменения, отражающие реальное положение вещей на проекте. В повседневной жизни на проекте может быть один Мастер Тест План и несколько детальных тест планов, описывающих отдельные модули одного приложения.


©2015-2022 megapredmet.ru Все права принадлежат авторам размещенных материалов. Обратная связь…

Поможем в ✍️ написании учебной работы


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

Рис. 7. Разработка и тестирование изменения

Действия по разработке и тестированию изменения

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

· SMF-функция «Предварительное планирование»

· SMF-функция «Планирование проекта»

· SMF-функция «Создание»

· SMF-функция «Стабилизация»  

· SMF-функция «Развертывание»

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

· Стандартные изменения. Используйте существующие процедуры для стандартных изменений.

· Незначительные изменения. Используйте процессы для незначительных изменений, описанные в настоящем документе. Дополнительные сведения см. в описании SMF-функций этапа «Внедрение».

· Важные и значительные изменения. См. описание SMF-функций этапа «Внедрение».

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

В следующей таблице перечислены действия, которые входят в эту процедуру:  

· Проектирование изменения

· Выявление зависимостей конфигурации

· Создание и тестирование изменения

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

· Обновление запроса на изменение

Таблица 8. Действия и основные аспекты процесса разработки и тестирования изменения

Действия Аспекты
Проектирование изменения Основные вопросы
· Учтены ли в проекте бизнес-требования и определены ли функции, которые необходимы пользователям для выполнения работы?
· Разработаны ли надлежащие сценарии использования?
· Учтены ли в проекте требования к эксплуатации?
· Учтены ли в проекте требования к системе?
Входные данные
· Требования пользователей и бизнес-подразделений
· Сценарии использования
· Требования к эксплуатации и к системе
Конечный результат
· Проектные документы
Рекомендации
· Поддерживайте связь между требованиями и функцииями решения. Это позволяет проверять правильность проек­та и его соответствие целям и требованиям решения.
Выявление зависимостей конфигурации Основные вопросы
· Существуют ли другие конфигурационные элементы, которые зависят от предлагаемого изменения или могут быть затронуты им?
· Зависит ли предлагаемое изменение от других изменений? Другими словами, нужно ли для внесения предлагаемого изменения сначала выполнить другие изменения?
· Сохранены ли в системе управления конфигурациями сведения обо всех изменениях (как о предварительных требованиях, так и о конечном изменении)?
Входные данные
· Сведения о других предлагаемых изменениях в системе управления конфигурациями
Конечный результат
· Запись в системе управления конфигурациями, показывающая зависимости конфигурационных элементов, на которые может влиять предлагаемое изменение или которые могут влиять на него
Рекомендации
· Данные в CMS должны обновляться при каждом утвер­ждении RFC. Это поможет отслеживать изменения, запланированные для конфигурационного элемента или группы конфигурационных элементов. После успешного завершения изменения данные в CMS также необходимо обновить.
Разработка и тестирование изменения Основные вопросы
· Соответствует ли готовое изменение спецификациям заказчика?
· Подготовила ли группа разработчиков среду разработки?
· Подготовила ли группа разработчиков процесс отслеживания ошибок? Каким образом информация об этих ошибках будет передана группе эксплуатации для использования в базе знаний?
· Проводили ли группы разработки и тестирования совместную работу по подготовке тестовых заданий?
· Подготовила ли группа несколько версий-кандидатов и протестировала ли каждую из них, чтобы проверить, можно ли выпускать соответствующую версию для пилотной группы?
· Завершила ли группа приемочное тестирование пользователями?
· Выполнила ли группа пилотное развертывание решения и получила ли отзывы?
Входные данные
· Документ с описанием концепции и области действия проекта
· Функциональная спецификация
· Требования заказчиков
· Код.
· Техническое задание на проведение тестирования
· План тестирования
· Лабораторная среда
· База данных, политики и процедуры отслеживания ошибок
Конечный результат
· Версии-кандидаты
· Версия-кандидат, готовая к пилотному тестированию
Рекомендации
· Разрешайте все известные проблемы (разрешение может заключаться в исправлении или отсрочке).
· Создайте стандарты для определения приоритета и серьезности ошибок и проинформируйте о них всех участников группы, включая роли разработки, тестирования и взаимодействия с пользователем.
· Предоставьте специалистам по обучению и поддержке доступ к базе данных для отслеживания ошибок, чтобы они могли получить представление об истории создания решения и о проблемах, возникавших во время разработки.
· Для анализа ошибок и выработки стратегий их разре­шения проводите регулярные собрания с участием разработчиков и тестировщиков.
Анализ готовности изменения к выпуску Основные вопросы
· Существует ли выравнивание бизнеса и ИТ и понятны ли приоритеты?
· Определены ли ответственные за все операции и действий?
· Подписаны ли все планы надлежащими руководителями?
· Проинформированы ли надлежащим образом все группы, которых затрагивает изменение? 
· Знают ли пользователи и владельцы зависимых услуг о влиянии, которое окажет на них это изменение, и о том, что оно запланировано? 
· Готовы ли пользователи к использованию новых процессов и одобряют ли их?
· Завершено ли тестирование?
· Готовы ли к выпуску группы эксплуатации и поддержки?
Входные данные
· Отчеты о состоянии для руководителя процесса управления релизами
Конечный результат
· Решение о готовности/неготовности релиза
Рекомендации                             
· Убедитесь, что руководителю процесса управления релизами предоставлены надлежащие отчеты о состоянии. 
· Предоставьте отзывы и подтверждения тем, кто должен поддерживать релиз, и напомните организации об ожидаемых выгодах.
Обновление RFC Основные вопросы
· Внесены ли обновления, отражающие намеченную дату выпуска, планы и причины возврата (если таковой необходим), требования к поддержке, план развер­тывания, результаты тестирования, выявленные проблемы и дату анализа после внедрения (PIR)? Дополнительные сведения о PIR см. в разделе «Процесс 7. Проверка и анализ изменения».
· Ведется ли в ходе процесса мониторинг и обновление состояния?
· Может ли инициатор изменения просматривать RFC и определять его состояние в ходе процесса?
· Осуществлялось ли при выпуске информирование инициатора изменения?
Входные данные
· Обновления для изменения
Конечный результат
· Обновленный запрос на изменение
Рекомендации
· Чтобы убедиться, что информация обновлена, руководитель процесса управления релизами должен осуществлять мониторинг выполняемых изменений, которые задерживают выпуск. Чтобы установить ожидае­мые результаты, можно использовать соглашение об уровне операционного обслуживания.

Процесс 6. Выпуск изменения


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

Рис. 8. Выпуск изменения



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

Глава 1. Общие положения

1. Настоящие Правила, программы и организация тестирования административных государственных служащих, кандидатов на занятие административных государственных должностей (далее – Правила) разработаны в соответствии с подпунктом 5) пункта 2 статьи 5 и пунктами 3 и 4 статьи 28 Закона Республики Казахстан от 23 ноября 2015 года «О государственной службе Республики Казахстан» (далее – Закон), Указом Президента Республики Казахстан от 29 декабря 2015 года № 151 «О некоторых вопросах поступления граждан на административную государственную службу корпуса «А» и определяют порядок, программы, организацию тестирования административных государственных служащих, кандидатов на занятие административных государственных должностей, а также порядок обжалования результатов тестирования.

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

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

4. Техническое обеспечение процедур тестирования, формирования базы данных тестовых заданий и их обновление осуществляется акционерным обществом «Национальный центр по управлению персоналом государственной службы» (далее – Центр).

Глава 2. Тестирование кандидатов на зачисление в кадровый резерв административной государственной службы корпуса «А»

5. Тестирование кандидатов на зачисление в кадровый резерв административной государственной службы корпуса «А» (далее – кандидаты в резерв корпуса «А») состоит из следующих этапов:

1) тестирование на знание законодательства Республики Казахстан;

2) логический тест;

3) тестирование на определение уровня компетенций;

4) тестирование на знание государственного языка.

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

7. Кандидат в резерв корпуса «А» проходит тестирование на знание законодательства Республики Казахстан по программе тестирования согласно приложению 1 к настоящим Правилам по той категории административной государственной должности корпуса «А», которая указана в его заявлении об участии в отборе в кадровый резерв корпуса «А».

8. Кандидаты в резерв корпуса «А», получившие результаты тестирования на знание законодательства Республики Казахстан ниже значений, указанных в приложении 1 к настоящим Правилам, не допускаются к следующему этапу тестирования.

9. Тестирование на знание государственного языка кандидатов в резерв корпуса «А» проводится в соответствии со стандартами системы оценки уровня владения казахским языком – КАЗТЕСТ.

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

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

Глава 3. Тестирование кандидатов на занятие административных государственных должностей корпуса «Б» на знание государственного языка и законодательства Республики Казахстан

12. Уполномоченный орган и его территориальные подразделения проводят тестирование кандидатов на занятие административных государственных должностей корпуса «Б» (далее – кандидат/кандидаты на должность корпуса «Б») на знание государственного языка и законодательства Республики Казахстан по мере обращения граждан.

13. Для участия в тестировании кандидат на должность корпуса «Б» не позднее одного календарного дня до дня тестирования подает заявление по форме, согласно приложению 2 к настоящим Правилам (далее – заявление) через веб-портал «электронного правительства» или посредством обращения в Государственную корпорацию «Правительство для граждан» (далее – Государственная корпорация).

При обращении в Государственную корпорацию кандидат на должность корпуса «Б» предъявляет документ, удостоверяющий его личность.

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

14. Кандидат на должность корпуса «Б» выбирает день и время тестирования исходя из наличия свободных мест для проведения тестирования.

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

15. Кандидаты на должность корпуса «Б» проходят тестирование на знание государственного языка и законодательства Республики Казахстан по тем программам тестирования кандидатов на занятие административных государственных должностей корпуса «Б» на знание государственного языка и законодательства Республики Казахстан согласно приложению 4 к настоящим Правилам (далее – программы тестирования), которые указаны в их заявлениях.

16. Значение для прохождения тестирования на знание государственного языка Республики Казахстан не устанавливается.

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

Сертификат, выданный по первой программе тестирования, действителен для категорий должностей административной государственной службы корпуса «Б», относящихся ко второй и третьей программе тестирования.

Сертификат, выданный по второй программе тестирования, действителен для категорий должностей административной государственной службы корпуса «Б», относящихся к третьей программе тестирования.

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

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

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

20. В случае утери или порчи сертификата, в течение срока его действия, кандидаты на должность корпуса «Б» могут получить дубликат сертификата по форме, согласно приложению 7 к настоящим Правилам через веб-портал «электронного правительства» или посредством обращения в Государственную корпорацию при наличии электронной цифровой подписи.

Глава 4. Порядок проведения оценки личных качеств кандидатов на должность корпуса «Б»

21. Оценка личных качеств кандидатов на должность корпуса «Б» проводится в форме тестирования.

22. Тестирование на оценку личных качеств кандидатов на должность корпуса «Б» проводится после завершения ими тестирования на знание законодательства Республики Казахстан согласно графику тестирования.

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

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

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

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

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

Глава 5. Порядок организации тестирования

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

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

27. До начала тестирования администратор знакомит тестируемых лиц с инструкцией по тестированию и отвечает на возникшие у них вопросы по процедуре тестирования.

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

29. График тестирования формируется автоматически.

30. Зал тестирования оснащается подавителем сотовой связи, в целях идентификации кандидата на должность корпуса «Б» – карт-ридером.

31. Каждая рабочая станция оснащается веб-камерой для снятия фотографии кандидата и ведения видеозаписи процесса тестирования.

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

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

33. В случае нарушения тестируемым лицом требований пункта 32 настоящих Правил, администратор останавливает процесс тестирования такого лица и удаляет его из помещения для тестирования.

При этом администратор составляет акт о нарушении настоящих Правил по форме, согласно приложению 10 к настоящим Правилам (далее – акт о нарушении) в течение одного рабочего дня.

Лица, в отношении которых был составлен акт о нарушении, проходят повторное тестирование не ранее чем через шесть месяцев со дня нарушения. Результаты тестирования лиц, нарушивших требования пункта 32 настоящих Правил, аннулируются.

34. При невозможности продолжения тестирования вследствие непреодолимой силы (стихийные явления, военные действия), а также по причине технических неполадок тестирование приостанавливается и оформляется акт о приостановлении процедуры тестирования по форме, согласно приложению 11 к настоящим Правилам.

В этом случае, кандидат на должность корпуса «Б» вправе пройти тестирование, записавшись на тестирование в порядке определенном пунктами 13 и 14 настоящих Правил.

35. По истечении времени, отведенного на выполнение тестов, тестирование автоматически завершается.

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

37. Не позднее двадцати минут после завершения тестирования лицам выдаются их результаты с подписями администратора и оператора тестирования, заверенные печатью.

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

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



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


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