Основы тестирования доработок

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

Во вложении находится документ Word, в нем приведен краткий курс к тестированию принимаемой доработки.

 

Тестирование доработок

15 августа

2012

Описание приемов тестирования частых ошибок

    

     

 


 

Оглавление

1. Факторы, определяющие сценарий тестирования

 2. Совокупности ошибок и их признаки

 3. Подготовка к тестированию 

 4. Разбиение доработки на блоки проверки

 5. Сценарии тестирования доработок

 5.1 Проверка алгоритмов расчета

 5.2 Проверка соответствию приложениям технического задания

 5.3 Проверка объектов метаданных, использованных разработчиком

 5.3.1 Справочник

 5.3.2 Независимый регистр сведений

 5.3.3 Документ

 5.3.4 Отчет

 5.3.5 Обработка

 6. Проверка быстродействия

  

Факторы, определяющие сценарий тестирования

Сценарий тестирования доработки определяется следующей совокупностью факторов:

  1. Алгоритмами расчета
  2. Соответствием приложениям технического задания
  3. Набором объектов метаданных, использованных разработчиком
  4. Быстродействием и отсутствием избыточных блокировок

Совокупности ошибок и их признаки

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

 

Подготовка к тестированию

Что входит в подготовку тестирования доработки

  1. Обязательно клиент-серверная база данных для тестирования доработок
  2. Подтверждение от разработчика о реализации последней версии доработки в базе данных
  3. Список объектов метаданных, использованных в доработке разработчиком
  4. Распечатанный экземпляр технического задания
  5. Тестирование под фокус-пользователем

Разбиение доработки на блоки проверки

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

Сценарии тестирования доработок

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

Проверка алгоритмов расчета

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

Выглядят такие таблицы примерно так:

Шаг / Переменная

Комментарий к шагу

Параметр1

Параметр2

ПараметрN

Начальные даннные

Инициализация параметров

 

 

 

 

Шаг 1

Расчет параметра X1

 

 

 

 

….

 

 

 

 

 

Шаг i

Расчет параметра Xi

 

 

 

 

…..

 

 

 

 

 

Шаг m:

Расчет параметра Xm

 

 

 

 

Итоговые данные

Выводимые в форму данные

 

 

 

 

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

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

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

 

Частые ошибки:

Ошибка

Комментарий по проверке

1

Деление на ноль

Ввести в систему нулевые данные, являющиеся делителем в формулах

2

Погрешность вычислений

Ввести минимальные, средние и максимальные значения вычислений. Таким образом, чтобы они давали небольшой результат вычислений или слишком большой результат вычислений. Проверяется в этом случае общий итог по табличной части, и верное отображение в строке данных в числовых колонках. Например в колонке «Сумма» в 1С не будет отображаться значение 0,004. В колонке количество не будет отображаться значение 0,0004.

3

Неверная формула

Ввести таблицу трассировки и проверить расчеты

4

Использование недопустимых значений

Если значение переменных формулы должны быть только положительные или только отрицательные, или входить в интервал от А до Б и т.п.. То нужно проверить на значения не входящие в область определения. Например, если 0 < Коэффициент

 

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

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

Частые ошибки:

Ошибка

Комментарий по проверке

1

Не соблюдены шрифты

Если это критично, то выводиться печатная форма. Выделяется ячейка и по кнопке свойства проверяются шрифты.

2

Не соблюден состав и названия колонок

 

3

Не соблюден состав блоков печатной формы

 

 

Проверка объектов метаданных, использованных разработчиком

                Опишем каждый объект и этапы его проверки

Справочник

Действие по проверке

Комментарий по проверке

1

Открытие в интерфейсе с набором ролей фокус-пользователя

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

2

Проверить наличие всех необходимых колонок в форме списка

 

3

Проверить наличие всех необходимых реквизитов в форме элемента

Проверить Владелец, Родитель, Код, Наименование

4

Соблюдена похожесть форм на типовые справочники 1С

Код, наименование, владелец, родитель сверху, все остальные реквизиты ниже

5

Пометить на удаление, Снять пометку на удалений, Скопировать. Не должно быть доступно интерактивное удаление.

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

6

Должна быть доступна кнопка «Перейти» к связанным объектам.

Должна быть в формах верхних командных панелях форм

7

Наличие справки

 

 

Независимый регистр сведений

Действие по проверке

Комментарий по проверке

1

Открытие в интерфейсе с набором ролей фокус-пользователя

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

3

Периодичность регистра (год, месяц, день)

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

4

Состав измерений

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

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

2) Проверить, что можно ввести, например 2 записи с одинаоквой Организацией, Подразделением, но разными номенклатурами.

5

Состав ресурсов

Вычисляемые поля

6

Состав реквизитов

Дополнительные реквизиты

7

Наличие всех необходимых полей в форме списка

 

8

Наличие всех необходимых полей в форме элемента

 

9

Наличие справки

 

 

Частые ошибки и недочеты:

Ошибка

Комментарий

1

Не выведен в интерфейс

 

2

Не дано право фокус-пользователю на работу с объектом

Нет возможности создания и удаления записи регистра

3

Не соблюдается периодичность справочника

 

4

Неверно определен состав измерений

 

5

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

У измерения должен назначаться признак Ведущий

6

Справка от другого регистра сведений

 

 

Документ

Действие

Комментарий

1

Открытие в интерфейсе с набором ролей фокус-пользователя

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

2

Форма списка, Форма выбора

 

 

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

 

 

В списке пробуем действия создание документа, копирование, пометка на удаление, снятие пометки на удаление, проведение, отмена проведения, повторное проведение

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

 

В списке должно быть доступно по кнопке «Перейти» структура подчиненности и движения документа.

 

 

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

 

 

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

 

3

Форма документа

 

 

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

 

 

Форма должна иметь вид приближенный к типовым формам 1С документов. Т.е. сверху вниз: Командная панель действий формы, Номер и Дата документа, реквизиты шапки, панель с табличными частями, итоги, ответственный и комментарий, Основная панель формы с кнопками печати, записи, проведения и закрытия.

 

 

В командной панели действий формы должно быть доступно по кнопке «Перейти» структура

 

 

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

 

 

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

 

 

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

 

 

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

 

 

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

 

4

Печатные формы

 

 

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

Изменить существующий документ и попробовать распечатать

 

Печатная форма должна соответствовать приложению к тех заданию

Визуально сравнить с приложением тех задания

 

Должен быть выдержан шрифт и оформление согласно тех заданию

Сравнить свойства шрифта печатной формы  и приложения. Важно при печати этикеток или других специальных форм на принтеры не являющиеся А4.

 

Все нужные поля должны быть заполнены исходя из данных документа.

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

 

Сохранение параметров печати

Нажать кнопку Файл — Параметры печати, настроить параметры, сделать предварительный просмотр.

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

 

 

 

5

Проведение документа

 

 

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

Выводятся сообщения в окно служебных сообщений.

 

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

 

 

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

Попробовать изменить количество строк, состав полей. Сравнить

 

При нажатии кнопки «Записать» проведенного документа, должны переформировываться движения документа

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

6

Ввод на основании

 

 

Проверить создание документа на основании других документов

Могут быть синтаксические ошибки кода, вылетающие в конфигуратор- это недопустимо.

 

Проверить создание других документов на основании текущего

Могут быть синтаксические ошибки кода, вылетающие в конфигуратор- это недопустимо.

 

 

 

 

Отчет

Действия по тестированию:

Действие

Комментарий

1

Открытие в интерфейсе с набором ролей фокус-пользователя

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

2

Сохранение и восстановление настроек с возможностью, использования настроек с разных компьютеров

Есть два варианта сохранения настроек: 1) Доступные только на это м компьютере только под данным пользователем в данной базе 2) Доступные всем пользователям в данной базе на разных компьютерах

3

Наличие в форме отчета всех полей, описанных в тех задании

Тестирование на совпадение с приложениями.

4

Установка параметров

При открытии должна заполняться организация и период

5

Группировки

Все группировки учеты. Например от организации до документа движения.

6

Сортировка

Переформировать с другой сортировкой

7

Отборы

Переформировать с другими отборами

8

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

Это тестирование алгоритмов, см выше.

9

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

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

10

Проверить наличие и правильную работу расшифровки отчета

Правой клавишей на строке, сформировать расшифровку

11

Наличие справки

 

 

Частые ошибки и недочеты:

Ошибка

Комментарий

1

Не выведен в интерфейс

 

2

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

 

3

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

 

4

Не происходит установки параметров при первом открытии

 

5

Изменение параметров не влияет на результат отчета

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

6

Не выдержаны форматы оформления полей Округления

В полях могут быть числа с большим количеством знаков после запятой

7

Данным в поле не хватает места и они не видны

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

8

Отображаются неверные остатки на дату отчета, или не зависят от изменения данных отчета

 

9

Отсутствует справка к объекту

 

10

Отсутствует расшифровка или неверная или выдает ошибку

 

11

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

 

12

Отчет формируется очень долго

Неправильна я схема реализации запроса

13

Отсутствуют некоторые колонки отчета

 

14

Колонки называются не как в тех задании

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

15

Описание в справке от другого отчета

Копируют другие отчеты

16

Неправильное наименование отчета в форме

 

 

Обработка

Действия по тестированию:

Действие

Комментарий

1

Открытие в интерфейсе с набором ролей фокус-пользователя

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

2

Аналогично отчету должна иметь сохраняемые настройки

 

3

Справка

 

4

Юзабилити оформление

Удобное управление пользователем без лишних действий и переходов в другие окна.

5

Изменять данные системы корректно, повторно, не вываливаться в конфигуратор

 

6

Пользователю даны права доступа на сам объект и объекты используемые обработкой

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

 

 

 

 

Проверка быстродействия и отсутствия избыточных блокировок

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

            Например, если заказчику требуется каждый день формировать отчет, а отчет в программе формируется более 24 часов — то данный отчет Заказчику не подойдет.

            Или например, пользователь-оператор должен за рабочий день 8 часов, оформить 80 документов. Т.е. по 10 документов в час, т.е. по 1 документу в 6 минут. Если это по каким, то причинам не удается (долго заполнять документ или долгое проведение документа), то данный документ коммерчески не обоснован — Заказчику не подойдет.

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

 

 

 

16 Comments

  1. pumbaE

    А где-же обработка? Дайте обработку, которая будет проделывать эти рутинные операции с прописанными правилам…

    p.s.: эти слова не воспринимайте всерьез, это просто плач Ярославны.

    Reply
  2. sapervodichka

    (1) pumbaE, Попробуй Автоматическое тестирование конфигураций 1С ) может доума доведешь. Она под 8.1 платформу на сайте, но конвертируется под 8.2. В принципе может потянуть большую часть проверок. Плюс еще есть обработка от 1С открытия всех форм, я её допилил для автоформирования всех отчетов и создания и проведения копий документов и вывода всех печтаных форм…. так и проверяю. Не плач!

    Reply
  3. Belomor

    (1)Вот посмотри, у Артура есть и более свежая версия http://infostart.ru/public/15492/

    Reply
  4. pumbaE

    (3) Belomor, Артур все никак не может/хочет провести webinar по TDD . Надо будет его по доставать по этому поводу. Про его обработку я знаю, но думал, а вдруг что-нибудь новенькое сделали, пока я тут со снегопатом развлекаюсь.

    Reply
  5. Belomor
  6. Totoro

    Идея хорошая, но некоторые требования должны быть описаны в ТЗ, иначе нет смысла их проверять и требовать работоспособности

    Reply
  7. musatov1c.ru

    Смотрится важным. Оставляю себе памятку 🙂

    Reply
  8. strenuus

    Полезно как памятка неопытному разработчику. Чтобы не давать ему потом подзатыльников за «детские» ошибки и недоработки. Распечатаю подопечным. Спасибо.

    Reply
  9. AlexO

    Т.к. это чей-то курсовой, то поставил плюс за труды.

    Также подойдет франчайзи как шаблон для отчета по сделанному ТЗ (и для отчета заказчику).

    Ну, и последний абзац зело хорош…

    Только вот про него тру-1сники как-то забывают с появлением денег…

    Reply
  10. sapervodichka

    (10) AlexO, Это не курсовой :-)))) Мой курсовой был, например: использование нейронных сетей в прогнозировании производства или движение фигур в реперном пространстве — а это скорее как выше заметили — памятка новичкам для проверки доработок.

    Reply
  11. awk

    Замечания к статье:

    1.

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

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

    2. На втором месте ошибки прав. То есть когда под админом все работает, а под пользователем нет(или перестает работать). Так что проверять надо под всеми затронутыми ролями. Благо это хорошо автоматизируется.

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

    Reply
  12. sapervodichka

    Яркий ответ «разработчика»! С нуля пробегать по тест кейсам = Платить консультанту. Тестировать под всеми «затронутыми» ролями = наверное ближе к ОПЭ (проще на живых людях допроверять). А то что не указано в т.з. тестированию не подлежит = Гуд! Остается пустяк сдать клиенту и выбить бабло, а если проект крупняк не опозориться и не получить от руководства.

    Reply
  13. awk

    (13)

    Платить консультанту

    Скорее держать на штате тестировщика.

    проще на живых людях допроверять

    Скорее проще договориться об отдельном проекте/задаче по разграничению прав.

    Гуд!

    Не сложно оговорить в ТЗ, что формы должны открываться не более 3-5 секунд, отчеты с оперативной информацией (глубиной 1-2 месяца) не более 1 минуты на среднеофисном компе и т.д. (за эталон можно взять любой современный комп за 6 — 9 т.р.).

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

    Это зависит не от качества реализации, а от качества втирания.

    Reply
  14. sapervodichka

    (14) awk, согласен ) спасибо за комменты

    Reply
  15. kot30688

    Отчет, который формируется 24 часа — это пять! Вообще заметил в табличке требований к документам, по форме списка при удалении не должно появляться никаких диалогов и предупреждений. Получается, должно молча ставить пометку удаления? Или я что-то не так понял?

    Reply
  16. sapervodichka

    Проверить доработки быстро можно так https://infostart.ru/public/1056811/

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *