Разработка тестового сценария проекта практическая работа

Тема: Разработка тестового сценария проекта

С этим файлом связано 12 файл(ов). Среди них: Учет работы на ПК.docx, New Документ Microsoft Word.docx, 9 26.docx, 9 28.docx, vecnftd rbdfkbr gjdnjhtybt.docx, Практическое задание №16.docx, Вариант 1.docx, мустаев кивалик2.docx, Bank_Калашников_Кулешов.docx, rejting_shkol_moskvy_na_2019-2020_god.docx, Акт(Чика).docx, Акт(Чика).docx и ещё 2 файл(а).
Показать все связанные файлы

Подборка по базе: управление проектами 2 семестр син..pdf, русский язык 2 семестр практическое 3.docx, Технология развития бизнеса2 Практическое задание 3.docx, Задачи. Практическое занятие 2.docx, Физиология высшей нервной деятельности. Практическое задание №1,, КОНФЛИКТОЛОГИЯ практическое (1).docx, Курсовой проект Управление проектами .docx, Социология Практическое задание.pptx, Английский практическое 11 задание 5.docx, Технология организации проекта=44.pptx

Практическое занятие №6

Тема: Разработка тестового сценария проекта

Цель: Научиться разрабатывать простейшие тестовые сценарии (test case)

Задание:

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

ВАРИАНТЫ:

  1. Оплата мобильного телефона, через платежный терминал
  2. Снятие наличных денег в банкомате
  3. Проезд в автобусе с кондуктором
  4. Использование будильника мобильного телефона
  5. Ксерокопирование
  6. Проход в метро (по смарт-карте и/или с жетоном)
  7. Закрывание двери ключом
  8. Поездка в лифте
  9. Звонок в службу поддержки Интернет-провайдера/мобильного оператора

СОДЕРЖАНИЕ ОТЧЕТА:

  1. Титульный лист с название группы, номером и темой практического задания, вариантом, ФИО.
  2. Цель и задание, соответствующие полученному варианту.
  3. Результаты работы: тестовый сценарий в виде таблицы, включающий в себя номер шага, описание действия, необходимые на данном шаге тестовые данные и ожидаемый результат выполнения шага.
  4. Выводы: достигли ли цель работы.

ПРИМЕР:

Название IS-login-1
Дата создания 29.10.2021
Автор Ivan Ivanov
Дата последнего изменения 30.10.2021
Описание Проверка функционирования подсистемы «Вход в IS» некой информационной системы на соответствие требованиям при вводе корректных и некорректных значений.
Шаг № Описание Тестовые данные Ожидаемый результат
1 Введите имя пользователя. Нажмите кнопку «Войти» Имя пользователя = Test Основное окно программы не открывается. Должно быть выведено сообщение «Введите пароль»
2 Введите пароль. Нажмите кнопку «Войти» Пароль = Test Основное окно программы не открывается. Должно быть выведено сообщение «Введите имя пользователя»
3 Введите имя пользователя и пароль. Нажмите кнопку «Войти» Имя пользователя = Test

Пароль = ХХХ

 Основное окно программы не открывается. Должно быть выведено сообщение «Введите имя пользователя и/или пароль неверные. Пожалуйста введите правильные данные»
4 Введите имя пользователя и пароль. Нажмите кнопку «Войти» Имя пользователя = ХХХ

Пароль = Test

 Основное окно программы не открывается. Должно быть выведено сообщение «Введите имя пользователя и/или пароль неверные. Пожалуйста введите правильные данные»
5 Введите имя пользователя и пароль. Нажмите кнопку «Войти» Имя пользователя = ХХХ

Пароль = ХХХ

 Основное окно программы не открывается. Должно быть выведено сообщение «Введите имя пользователя и/или пароль неверные. Пожалуйста введите правильные данные»
6 Введите имя пользователя и пароль. Нажмите кнопку «Войти» Имя пользователя = « »

Пароль « »

 Основное окно программы не открывается. Должно быть выведено сообщение «Введите имя пользователя и/или пароль неверные. Пожалуйста введите правильные данные»
7 Введите имя пользователя и пароль. Нажмите кнопку «Войти» Имя пользователя = Test

Пароль = Test

 Должно открыться основное окно приложения.
8 Введите имя пользователя и пароль. Нажмите кнопку «Войти» USER = ADMIN

Пароль = ADMIN

 Должно открыться окно приложения с административными настройками.
Источник

Санкт-Петербургский
Государственный Университет Информационных
Технологий, Механики и Оптики

Кафедра Информационных
Технологий и Программирования

Лабораторная
работа №2.
Вар 1.

Тема:
Создание тестового сценария (test
case).

Выполнили студенты:

Шевченко Алексей

Тихонов Дмитрий

Группа: 5511

Преподаватель:

Санкт-Петербург

2008 год

Цель:
Научиться создавать простейшие тестовые
сценарии (test case).

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

Название

Оплата
телефона

Дата
создания

20.10.2008

Автор

Алексей
Шевченко

Дата
последнего изменения

25.10.2008

Описание

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

Шаг
№

Описание

Тестовые
данные

Ожидаемый
результат

1

Введите
номер телефона, на экранной клавиатуре

1234567

В
окне появиться номер 1234567

Кнопка
Ок подсветиться.

2

Нажмите
кнопку Ок

Появится
окно с номером телефона в углу, пустым
счетчиком купюр, и надписью Жду денег,
100, 500, 1000р, неактивная кнопка оплатить
и кнопка изменить номер

3

Сунем
рваную десяти рублевую бумажку, в щель
приема денег

10
рублей

На
экране ничего не происходит, автомат
«выплевывает» бумажку обратно

4

Сунем
100 рублей

100
рублей

Купюра
исчезла, в окне счетчика появилась
цифра 100 кнопка оплатить стала активной

5

Сунем
еще 100 рублей

100
рублей

Купюра
исчезла, в окне счетчика появилась
цифра 200

6

Нажмем
на кнопку изменить номер

Появляется
меню для выбора номера телефона,
экранная клавиатура

7

Введем
номер 7654321, так же как в пункте один

7654321

Появилось
Появится окно с номером телефона в
углу, в окне счетчика написано 200 и
надписью Жду денег, 100, 500, 1000р, активная
кнопка оплатить и кнопка изменить
номер

8

Нажимаем
кнопку оплатить

Появляется
надпись 200р успешно зачислено на счет,
и чек.

9

Повторяем
шаги 1.2.

Сунем
1000 рублей

1000
рублей

Купюра
исчезла, в окне счетчика появилась
цифра 1000

10

Вспоминаем,
что уже оплатили телефон

Пытаемся
вернуть деньги

11

Нажимаем
на кнопку помощь

На
экране появляется инструкция по
использованию автомата, Пункт 1 КАК
Вернуть Деньги Засунутые в Автомат

12

Нажимаем
на 1 пункт меню пальцем

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

13

Злимся.
Пинаем автомат ногой и разбиваем экран

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

4. Система прошла тестирование успешно,
за исключением антивандальной защиты
(необходимо сделать корпус прочнее). Мы
освоили написание тестовых сценариев,
а

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

  • #
  • #
  • #
  • #
  • #

    09.05.201437.89 Кб745511-5-s14&s17.xls

Источник

ЛАБОРАТОРНАЯ РАБОТА № 15. РАЗРАБОТКА ТЕСТОВОГО СЦЕНАРИЯ ПРОЕКТА

Цель: получить навыки разработки тестовых сценариев.

Теоретические вопросы

Оценка стоимости и причины ошибок в программном обеспечении. Виды и методы тестирования.

Понятие теста.

Требования к разработке тестовых сценариев. Правила разработки тестовых сценариев.

Задание № 1. Написать программу решения квадратного уравнения ах2 + bх + с = 0.

Задание № 2. Найти минимальный набор тестов для программы нахождения веще-ственных корней квадратного уравнения ах2 + bх + с = 0. Решение представлено в таблице.

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

Заповеди по отладки программного средства, предложенные Г. Майерсом.

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

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

Заповедь 3. Готовьте тесты как для правильных, так и для неправильных данных.

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

Заповедь 6. Пропускайте заново все тесты, связанные с проверкой работы какой-либо программы ПС или ее взаимодействия с другими программами, если в нее были внесены изменения (например, в результате устранения ошибки).

Задание № 6. Разработайте набор тестовых сценариев (как позитивных, так и негативных) для следующей программы:

Имеется консольное приложение (разработайте самостоятельно). Ему на вход подается 2

строки. На выходе приложение выдает число вхождений второй строки в первую. Например:

Набор тестовых сценариев запишите в виде таблицы, приведенной выше.

Задание № 3. Оформите отчет.

Достарыңызбен бөлісу:

Источник

Разработка тестового сценария

Автор:   •  Февраль 19, 2021  •  Практическая работа  •  500 Слов (2 Страниц)  •  328 Просмотры

Страница 1 из 2

Как правило, для автоматизированного тестирования строят отдельные программные модули, которые в последующем не включаются в комплект поставки программного продукта и являются внутренним инструментом для компании – разработчика. Разберем на практическом примере разработку автоматизированных тестов в среде Visual Studio.

Тем самым модулем или инструментом, о котором говорилось выше, в Visual Studio является проект модульного тестирования – UnitTestProject (см. Рис. 1).

Рисунок 1 Создание проекта модульного тестирования

Предположим, что стоит задача протестировать реализацию методов класса «Треугольник» (ClassTreug), определяющего прямоугольный треугольник, заданный своими катетами:

— Gipotenusa – вычисление гипотенузы треугольника;

— Plotsthad – вычисление площади треугольника; — Radius – вычисление радиуса описанной окружности.

Создадим папку -TestVB.

Запустим Visual Studio 2019, в стартовом окне выберем Создание проекта и выбираем проект –

Visual Basic – Windows – Библиотека -Библиотека классов (.Net Framework)

Нажимаем Далее и в настройках нового проект а указываем:

— имя проекта – ClassLibraryTreug;

— расположение — …….TestVB и нажимаем кнопку Создать.

В окне кода Visual Studio, закладка Class1.vb, переименуем наш Class1 в ClassTreug, и введем код реализующий методы класса с помощью пользовательских функций (Function) и процедур (Sub), видимости Public:

Добавим в наше решение проект модульного теста:

— в Обозревателе решений, выбираем решение – ClassLibraryTreug;

— правой кнопкой мыши открываем контекстное меню решения и выбираем: Добавить -> Создать проект, после чего в окне добавления проекта устанавливаем: Visual Basic – Windows – Тестирование – Проект модульного теста (.Net Framework):

Нажимаем кнопку Далее, и в качестве

…

Доступно только на Essays.club

Источник

Сессия 3

  • Разработка библиотеки классов
    • Общие требования
    • Класс аналитики (реализация)
    • Разработка модульных тестов
    • Разработка тестовых сценариев

Разработка библиотеки классов

Инструкция с картинками ниже

Общие требования

В связи со стремительным развитием нашей системы было решено вынести некоторый важный функционал за рамки основного проекта и сделать библиотеку классов, которую мы сможем подключать
к любому нашему проекту в случае расширения. Данная библиотека будет подключаться к основному проекту и должна быть представлена в виде .dll/.jar файла или папки с файлом .py.

Чтобы система правильно интегрировалась вам необходимо обязательно следовать правилам именования библиотек, классов и методов в них. В случае ошибок в рамках именования ваша работа не
может быть проверена и ваш результат не будет зачтен. Классы и методы должны содержать модификатор public (если это реализуемо в рамках платформы), чтобы внешние приложения могли
получить к ним доступ.

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

Класс аналитики

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

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

Например, вам поступили следующие данные: 2019-12-12 14:43, 2019-12-01 15:05, 2019-11-04 09:01, а, значит, самый популярный месяц — декабрь. Вам необходимо вернуть следующие данные: 2019-12-01 00:00, 2019-11-01 00:00. В случае совпадения характеристик популярности сперва нужно вывести более
ранние месяцы.

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

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

Разработка модульных тестов (Unit-tests)

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

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

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

Необходимо разработать модульные тесты, которые на основании исходных данных можно условно разделить на 2 группы следующим образом: 10 методов низкой сложности и 5 методов высокой
сложности.

Разработка тестовых сценариев (Test-cases)

Для выполнения процедуры тестирования удаления товаров Вам нужно описать пять сценариев.

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

Необходимо, чтобы варианты тестирования демонстрировали различные исходы работы алгоритма. Для описания тестовых сценариев в ресурсах предоставлен шаблон testing-template.docx.

Разработка библиотеки классов (реализация)

Я в ходе предварительной подготовки показывал как делать тесты для проекта, они в принципе одинаковые для любого типа проектов. Но все (и МРМТ тоже) впали в ступор от слов «библиотека классов». Заполним этот пробел.

Библиотека это отдельный проект. Для C# этот проект должен генерировать файл *.dll

Замечания по репозиторию

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

Однако в «Требованиях и рекомендациях» указано, что каждая сессия должна быть загружена в отдельную ветку с названием «Сессия Х»… Но к этому вроде не придирались (посмотрю еще в критериях оценки).

Т.е. у вас в итоге должно получиться 3 репозитория:

  • session1 (с диаграммами, не помню чтобы там были требования к названию репозитория, если вдруг увидите, то называйте как положено)
  • my_cool_program (пока не смотрел как надо именовать приложение во второй сессии, но скорее всего созвучно названию компании)
  • CompanyCoreLib (третья сессия — тут явно указано какое имя должно быть у репозитория)

Создание проекта

Создаем новый проект, установив нужные фильтры (C#, Windows, Библиотека) и выбрав проект для соответствующей платформы. Мы всё делаем для .NET Framework.

создание проекта

Не забываем указать название проекта. Как вы тут напишете, так dll и будет называться.

ввод названия

В итоге студия создаст нам «рыбу» с одним файлом:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace CompanyCoreLib
{
    public class Class1
    {
    }
}

Создание класса аналитики

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

  1. Контекстное меню проекта -> Добавить -> Создать элемент. Далее в списке находим «Класс» и не забываем задать ему название (Analytics в нашем случае). Получится аналогичная «рыба» с нужным названием класса:

    using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace CompanyCoreLib
{
    class Analytics
    {
    }
}

  2. Контекстное меню Class1 -> Удалить

Реализация класса аналитики

В спецификации метода (был и такой файл в материалах сессии 3) указано название метода и его параметры, добавляем в наш класс:

public class Analytics
{
    public List<DateTime> PopularMonths(List<DateTime> dates) {
        return dates;
    }
}

Во-первых, обращаем внимание на ключевое слово «public» перед названием КЛАССА. Студия его автоматом не пишет, а для экспорта оно нужно. На эти грабли мы уже наступали при тестировании, напоминаю еще раз.

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

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

Полная реализация

namespace CompanyCoreLib
{
    // вспомогательный класс, который поможет отсортировать даты по частоте использования
    class DateTimeWithCounter
    {
        public DateTime DateTimeProp;
        public int Counter = 0;

        // конструктор
        public DateTimeWithCounter(DateTime date) {
            DateTimeProp = date;
            Counter = 1;
        }
    }

    public class Analytics
    {
        public List<DateTime> PopularMonths(List<DateTime> dates)
        {
            // объавляем временный массив объектов "ДатаСоСчетчиком"
            var DateTimeWithCounterList = new List<DateTimeWithCounter>();

            // тут сразу можно сделать проверку на длину исходного массива

            // перебираем исходный массив
            foreach (DateTime date in dates) {
                // вычисляем начало месяца для текущей даты
                var DateMonthStart = new DateTime(date.Year, date.Month, 1, 0, 0, 0);

                // ищем эту дату во вспомогательном массиве    
                var index = DateTimeWithCounterList.
                    FindIndex(item => item.DateTimeProp == DateMonthStart);

                if (index == -1)
                {
                    // такой даты нет - добавляю
                    DateTimeWithCounterList.
                        Add(new DateTimeWithCounter(DateMonthStart));
                }
                else {
                    // дата есть - увеличиваем счетчик
                    DateTimeWithCounterList[index].Counter++;
                }
            }

            // вспомогательный массив сортируем по убыванию по счетчику (самые популярные попадают в начало списка) 
            // ЗАТЕМ сортируем ПО дате по возрастанию
            // выбираем из объекта только дату, счетчик нам уже не нужен
            return DateTimeWithCounterList
                .OrderByDescending(item => item.Counter)
                // при первом прочтении это условие не разглядел
                .ThenBy(item => item.DateTimeProp)
                .Select(item => item.DateTimeProp)
                .ToList();

        }
    }
}

Разработка модульных тестов

Собственно это мы уже проходили, но повторим на этом примере еще раз.

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

В контекстном меню РЕШЕНИЯ выбираете Добавить -> Создать проект

При создании проекта можете воспользоваться фильтрами «языки», «платформа» и «типы проектов». В итоге надо выбрать «Проект модульного теста (.NET Framework)»

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

Связь с основным проектом

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

В тестовом проекте находим пункт «ссылки» (раньше назывался «зависимости») и в контекстном меню «добавить ссылку»

Выбрать основной проект (их может быть несколько), у нас он называется CompanyCoreLib.

Проверить, добавлен ли проект в зависимости, можно раскрыв «ссылки»

Написание тестов

Реализация теста, проверяющего результат работы метода PopularMonths:

namespace CompanyCoreLib.Tests
{
    [TestClass]
    public class AnalyticsTest
    {
        static Analytics AnalyticsClass = null;

        [ClassInitialize]
        static public void Init(TestContext tc)
        {
            AnalyticsClass = new Analytics();
        }


        [TestMethod]
        public void PopularMonths_Await3ItemsWithSortByDate()
        {
            List<DateTime> dates = new List<DateTime>() {
                new DateTime(2020, 12, 17),
                new DateTime(2020, 12, 15),
                new DateTime(2020, 11, 17),
                new DateTime(2020, 10, 1) };

            dates = AnalyticsClass.PopularMonths(dates);

            // должно вернуть 3 записи
            Assert.AreEqual(dates.Count, 3);

            // первой должен быть декабрь
            Assert.AreEqual(dates[0], new DateTime(2020, 12, 1));
        }
    }
}

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

Assert.IsTrue(Enumerable.SequenceEqual(expected, actual));

где expected и actual соответсвенно ожидаемые и реальные данные (списки дат)

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

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

Разработка тестовых сценариев

Шаблон для тестовых сценариев есть в файле testing-template.docx. Вам надо его только заполнить. Рассмотрим на основе одного кейса:

Аннотация теста

    Мои комментарии
Название проекта DoeduSam
Рабочая версия 1.0 Эту версию не плохо бы вписать в свойства проекта
Имя тестирующего DEMO_xx
Дата(ы) теста 21.12.2020 текущая

Тестовый пример #1:

    Мои комментарии
Тестовый пример # TC_DP_1 расшифровывается: TestCase_DeleteProduct_x
Приоритет тестирования средний бизнес-правило
Заголовок/название теста Удаление товара без продаж и дополнительных товаров
Краткое изложение теста Товар должен без ошибок удалиться из таблицы товаров
Этапы теста 1. Очистить таблицы продаж, дополнительных товаров, дополнительных картинок и товаров. 2. Добавить тестовый товар в таблицу Products
3. Вызвать метод удаления товара
4. Проверить наличие удаленной записи в таблице
Тестовые данные Название: Моторное масло Motor Oil KE900-90042-R
Изображение: Товары автосервиса8FE07916.jpg
Производитель: Nissan
Активен: да
Цена: 2060		 Тут нужно вставить содержимое любой записи из products_a_import
Ожидаемый результат Запись должна быть удалена из таблицы без ошибок и исключений
Фактический результат Запись удалена
Статус зачет
Предварительное условие В базу должны быть загружен тестовый продукт
Постусловие Таблица товаров должна быть пустой
Примечания/комментарии Т.к. мы добавили только товар без продаж и дополнительных товаров, то ошибок в принципе быть не может ни по вине кода ни по ограничениям базы

Что еще можно проверить

  • №2 — удаление товара с дополнительными товарами. Если ограничения настроены правильно (каскадное удаление), то тоже долно удаляться нормально.

  • №3 — удаление товара с дополнительными картинками. Аналогично №2.

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

  • №5 — удаление товара с продажами. Вариант с предварительной проверкой — в коде нужно проверить есть ли у товара продажи и при наличии продаж вывести сообщение, что удалять товар нельзя.

Источник

Практическая работа №1,2

Тестирование «Белым ящиком»

Цель работы: изучить метод тестирования «Белым ящиком»

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

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

Таким образом, тестирование ушло внутрь компаний, и появилась профессия тестировщика.

Рассмотрим определение, которое записано в SWEBOK.

Тестирование ПО – это проверка соответствия между реальным поведением программы и ее ожидаемым поведением на конечном наборе тестов, выбранном определенным образом. [IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004].

Все виды тестирования можно условно разделить на две большие группы:

Статическое тестирование (static testing).

Динамическое тестирование (dynamic testing).

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

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

Статический анализ кода (static code analysis) – это анализ исходного кода, производимый без его исполнения.

Динамическое тестирование – это тестовая деятельность, предусматривающая эксплуатацию (запуск) программного продукта.

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

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

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

По знанию системы выделяют:

  • тестирование «черного ящика» (black box testing);

  • тестирование «белого ящика» (white box testing);

  • тестирование «серого ящика» (grey box testing).

Метод белого ящика (white box testing, open box testing, clear box testing, glass box testing) – у тестировщика есть доступ к внутренней структуре и коду приложения, а также есть достаточно знаний для понимания увиденного.

Разработка тестов методом белого ящика (white-box test design technique): Процедура разработки или выбора тестовых сценариев на основании анализа внутренней структуры компонента или системы.

Техники, основанные на структуре, или методе белого ящика

  • тестирование операторов;

  • тестирование альтернатив.

Альтернатива (decision): Точка программы, в которой управление имеет два или более альтернативных путей. Узел с двумя или более связями для разделения ветвей.

Тестирование условий альтернатив (decision condition testing): Разработка тестов методом белого ящика, при котором тестовые сценарии проектируются для исходов условий и результатов альтернатив.

Покрытие (coverage): Уровень, выражаемый в процентах, на который определенный элемент покрытия был проверен набором тестов.

Покрытие альтернатив (decision coverage): Процент результатов альтернативы, который был проверен набором тестов. Стопроцентное покрытие решений подразумевает стопроцентное покрытие ветвей и стопроцентное покрытие операторов.

Покрытие кода (code coverage): Метод анализа, определяющий, какие части программного обеспечения были проверены (покрыты) набором тестов, а какие нет, например, покрытие операторов, покрытие альтернатив или покрытие условий. Еще выделяют серый ящик.

ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ И

ФОРМА ОТЧЕТНОСТИ:

Задание 1. Разработать программу на Python.

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

  1. Разнасторонний треугольник

  2. Равнобедренный треугольник

  3. Равносторонний треугольник

Ограничения:

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

Задание 2. Подготовить набор тестовых вариантов для обнаружения ошибок в программе.

Результат оформить в следующем виде:

А

В

С

Ожидаемый результат

Объект проверки

Значение

Значение

Значение

Что должно получится

Значения вводимых данных, либо ожидаемый результат

…

…

…

…

…

Задание 3. Разработать программу на Python.

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

  1. Остроугольный треугольник

  2. Тупоугольный треугольник

  3. Прямоугольный треугольник

Ограничения:

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

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

Задание 4. На основании проведенных тестов составьте рекомендации по исправлению ошибок, выявленных в ходе тестирования в виде отчета.

Пример:

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

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

Источник

Что такое тестовый сценарий?

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

Что такое тестирование сценария?

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

Давайте изучим это с помощью видео ниже —

Зачем создавать тестовые сценарии?

Тестовые сценарии создаются по следующим причинам:

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

Когда не создать тестовый сценарий?

Тестовые сценарии не могут быть созданы, когда

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

Как написать тестовые сценарии

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

  • Шаг 1 : Прочтите документы с требованиями, такие как BRS, SRS, FRS, тестируемой системы (SUT). Вы также можете сослаться на примеры использования, книги, руководства и т. Д. Приложения, подлежащего тестированию.
  • Шаг 2 : Для каждого требования определите возможные действия и цели пользователей. Определить технические аспекты требования. Определите возможные сценарии злоупотребления системой и оцените пользователей с менталитетом хакера.
  • Шаг 3: После прочтения Документа с требованиями и проведения надлежащего анализа перечислите различные сценарии тестирования, которые проверяют каждую функцию программного обеспечения.
  • Шаг 4: После того, как вы перечислили все возможные сценарии тестирования, создается матрица отслеживания, чтобы убедиться, что каждому требованию соответствует соответствующий сценарий тестирования.
  • Шаг 5: Созданные сценарии проверяются вашим руководителем. Позже они также рассматриваются другими заинтересованными сторонами в проекте.

Советы по созданию тестовых сценариев

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

Пример 1. Сценарий тестирования для приложения электронной коммерции

Для приложения электронной коммерции несколько тестовых сценариев

Тестовый сценарий 1: проверка функциональности входа

тестовый сценарий

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

  1. Проверьте поведение системы при вводе действительного адреса электронной почты и пароля.
  2. Проверьте поведение системы при вводе неверного идентификатора электронной почты и действительного пароля.
  3. Проверьте поведение системы при вводе действительного адреса электронной почты и неверного пароля.
  4. Проверьте поведение системы при вводе неверного идентификатора электронной почты и неверного пароля.
  5. Проверьте поведение системы, если адрес электронной почты и пароль оставлены пустыми и введен вход.
  6. Проверить Забыли пароль работает как положено
  7. Проверьте поведение системы при вводе действительного / недействительного номера телефона и пароля.
  8. Проверять поведение системы, когда установлен флажок «Держать меня в подписи»

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

Тестовый сценарий 2. Проверка функциональности поиска

тестовый сценарий

Тестовый сценарий 3: проверьте страницу описания продукта

тестовый сценарий

Сценарий тестирования 4: Проверьте функциональность платежей

тестовый сценарий

Тестовый сценарий 5: проверка истории заказов

тестовый сценарий

Помимо этих 5 сценариев, здесь приведен список всех других сценариев.

  • Проверьте поведение домашней страницы для постоянных клиентов
  • Проверьте категорию / страницы продукта
  • Проверьте службу поддержки / контактные страницы
  • Проверьте страницы ежедневных предложений

Пример 2: Тестовые сценарии для банковского сайта

Тестовый сценарий 1 : Проверьте функциональность входа и аутентификации

Тестовый сценарий 2 : Проверить перевод денег можно

Тестовый сценарий 3. Проверьте выписку со счета.

Тестовый сценарий 4 : Проверка фиксированного депозита / периодического депозита может быть создана

И так далее…

Шаблон сценария тестирования

Скачать шаблон тестового сценария Excel (.xlsx)

Источник

Понравилась статья? Поделить с друзьями:
  • Разработка тестового сценария проекта лабораторная работа
  • Разработка тестового сценария пример
  • Разработка тестового сценария оценка необходимого количества тестов
  • Разработка тест кейсов сценариев тестирования
  • Разработка сценарного плана праздника

    • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии