Документооборот КОРП, ПРОФ и ДГУ
31.08.2016
Каждый релиз конфигурации "1С:Документооборот" проходит тщательное тестирование. Вносимые изменения проходят несколько этапов проверки:
Каждый этап важен и помогает найти ошибки разного характера:
Чтобы доработки не имели негативного влияния на конфигурацию, их необходимо тестировать. Не рекомендуется пренебрегать качеством тестирования - проверяйте работоспособность как внесенных изменений (убедитесь, что они не противоречат уже реализованному функционалу), так и основных механизмов, задействованных во время разработки.
Как правило, на тестирование уходит примерно десять процентов времени, затраченного на разработку. Например, если десять программистов занимаются разработкой нового функционала на протяжении пяти рабочих дней, то для покрытия тестами внесенных изменений одному тестировщику потребуется пять рабочих дней. Команде из пяти тестировщиков потребуется один день на тестирование нового функционала и выявления ошибок старых механизмов, вероятно привнесенных во время разработки.
Функциональное тестирование подразумевает проверку ключевых сценариев, которые в свою очередь делятся на позитивные и негативные.
Рассмотрим на примере тестирования анкеты с обязательным текстовым полем Фамилия. Для тестирования необходимо отправить анкету со следующими данными:
Представлены два позитивных и три негативных сценария: 1 – корректные данные, 2,4 - некорректные данные, 3 – пустые данные, 5 - неочевидный сценарий.
Первый сценарий проверяет, что отправка анкеты в принципе работает. Со второго по четвертый проверяется работа с некорректными входными данными, при вводе которых анкета не должна быть отправлена. Пятым пунктом выявляется некий неочевидный сценарий, который мог быть не учтен разработчиком. Он является наименее критичным, поэтому такого рода сценарии нужно проходить в последнюю очередь. Первые четыре разновидности входных данных обязательно должны быть протестировании. Неочевидные сценарии выполняются после проведения основных тестов при наличии времени. Количество неочевидных сценариев ничем не ограничено, но все же необходимо оценивать их адекватность - некоторые сценарии лучше согласовать с разработчиком или, если есть возможность, с конечным пользователем.
Тесты должны выполняться от имени пользователей с ограниченным уровнем доступа (не Администратор, не Выполняющий потоковое сканирование).
Оформление тестов не менее важная часть тестирования. Каждый тест должен содержать подробное и четкое описание действий. Это позволяет исключить возможность неправильной трактовки теста и, как следствие, неверного его проведения. Неточное описание может привести к пропуску критической ошибки! А поиск низкоприоритетных ошибок бесполезен, если из-за критичных ошибок пользователь не сможет выполнить стандартных операций.
В ручном режиме проводится тестирование всех внесенных изменений и проверка работоспособности основных механизмов, затронутых во время разработки. Тестирование проводится по описанной выше технологии.
При наличии времени и ресурсов, рекомендуется проводить Регрессионное тестирование. Это выборочное тестирование, позволяющее убедиться, что изменения не вызвали нежелательных побочных эффектов и программа работоспособна. Для проведения регрессионного тестирования необходимо составить тестовую модель. Это набор тестов или чек-листов, покрывающих всю функциональность реализованную в программе.
Если времени и ресурсов на проведение полноценного регрессионного тестирования нет, можно обойтись проверкой только основных механизмов и тех, что были затронуты в ходе разработки. Для этого рекомендуется использовать Регламентные тесты. Регламентный тест включает проверку основных механизмов, без которых работа программы невозможна. Например, в "1С:Документообороте" это создание пользователей, работа с документами, работа с файлами, первоначальное заполнение базы, работа с настройками, работа почты, процессов и т.д. Рассмотрим пример плана регламентного тестирования одной из версий "1С:Документооборота".
Набор тестов можно разделить на несколько блоков: блок обновления типовой конфигурации, блок обновления клиентских баз, блок функциональных тестов. Такой тест рекомендуется собирать перед каждым выпуском новой версии программы. Удобно составить эталонный регламентный тест и включить в него максимальный набор регламентных тестов. При выпуске новой версии программы достаточно скопировать эталонный тест, удалить "лишние" тесты и добавить новые, обязательные для прохождения в рамках текущей версии.
Обязательными для прохождения перед каждым выпуском версии программы являются тесты обновления, причем проверку необходимо проводить как с последней версии, так и со всех поддерживаемых.
Уделите внимание проверке прав доступа после обновления.
Все действия тестов должны быть записаны. Написанию тестов нужно уделять достаточно внимания. Качественно составленный тест экономит время. Рассмотрим фрагмент регламентного теста "Приемочный тест почты", где максимально коротко и точно описан каждый шаг:
«Предусловия:
Установлена последняя версия "1С:Предприятия".
Установлена конфигурация "1С:Документооборот" тестируемой версии.
Включены регламентные задания для клиент-серверной версии.
Выполнен вход в систему документооборота пользователем "Фролова".
Тест проводится для клиент-серверной и файловой версии конфигурации. Редакция КОРП.
Шаги:
1. Очистить папки входящих\исходящих писем перед тестом.
2. Удалить лишние папки. Остаться должны только входящие, исходящие, отправленные, корзина, черновик для каждого ящика.
3. В пустой области писем любого из настроенных ящиков нажать правую кнопку мыши, прощелкать все кнопки. Система выдает сообщение не выбрано письмо.
4. Нажать "Написать новое письмо" - открылась форма заполнения нового письма. Закрыть, письмо не сохранять.
5. Нажать Ctrl+N - открылась форма заполнения нового письма, курсор находится в строке "Кому".
6. Заполнить тему и текст. Нажать "х". На вопрос системы "Сохранить изменения?" - нажать "Да".
7. Открыть "Черновик". В списке присутствует письмо с темой, указанной на предыдущем шаге. Выделить письмо, нажать F2. Закрыть письмо. Открыть письмо двойным кликом.
8. В области указания адресата нажать правую кнопку мыши - добавить адресата, указать "Тест почты".
9. Нажать правую кнопку мыши- добавить адресата. В строке нажать "...", Открылась адресная книга. Найти и выбрать пользователя "Почты тест" (email: maxgavtest@yandex.ru). Нажать "Готово". Пользователь добавлен в список адресатов.
10. Открыть адресную книгу. Найти группу пользователей, выделить ее, нажать кнопку "стрелка вправо" в окне адресной книги. Нажать "Готово". Все пользователи этой группы добавлены.
11. Удалить лишних пользователей (оставить "Тест почты" и "Почты тест").
12. Нажать кнопку "Адресная книга" (картинка записной книжки в верхней панели). Раскрыть группу "Личный адресат", выделить несколько адресатов, нажать кнопку "Стрелка вправо" в окне адресной книги. Нажать "Готово". Адресаты добавились с пометкой "Копия" (при наличии записи вида "Кому").
13. Нажать кнопку "Адресная книга", Выбрать группу адресатов нажать кнопку "Стрелка вправо" в окне адресной книги. Нажать "Готово". Адресаты добавлены.
14. Удалить лишних пользователей (оставить "Тест почты" и "Почты тест").
15. Отредактировать тему и текст: ё1234567890-=Ё!"№;%:?*()_+йцукенгшщзхъфывапролджэ\ячсмитьбю.яЙЦУКЕНГШЩЗХЪФЫВАПРОЛДЖЭ//ЯЧСМИТЬБЮ,`1234567890-=~!@#$%^&*()_+QWERTYUIOP{}ASDFGHJKL:"|ZXCVBNM<>?|qwertyuiop[]asdfghjkl;'\\zxcvbnm,.
16. Нажать "Отправить".
17. Открыть папки "Входящие" ящиков test2@1c.ru и test@yandex.ru. В списках присутствуют письма, созданные на предыдущем шаге.
18. Открыть письмо двойным кликом, закрыть. Открыть кнопкой F2.
19. Создать новое письмо с адресатами "Сотрудник предприятия 2" (vad2006@yandex.ru) и внешним е-мейлом.
20. В окне нового письма нажать "Все реквизиты". Убедиться что вид маршрутизации = доставка через почтовый сервер, Адресация = Это внешнее письмо.
21. Отправить письмо. Письмо отправлено без ошибок. Убедиться, что письмо дошло до адресатов…»
Идеальный тест не оставляет вопросов к автору или разработчику. Задача теста – помимо выявления ошибок, не позволяющих использовать функционал программы, не создавать препятствий работе тестировщика. Тест должен давать ответы и точные руководства к действиям, а не оставлять вопросы из-за неточных формулировок. Поверхностный и неточный тест - это не "возможность проверить большее количество механизмов", а почти наверняка пропуск ошибок и потеря времени на разъяснения и консультации с коллегами. В итоге получается дорого и некачественно. Точный тест дает гарантии работоспособности и не требует вмешательства других сотрудников.
Первичное тестирование - еще один тест, который рекомендуется выполнять при каждом обновлении версии программы. Первичное тестирование - это прохождение максимального количества экранных форм, создание простейших объектов. Тест не требует погружения в логику работы программы, поэтому не занимает много времени и дает возможность выявить ошибки открытия форм, которые могут привести к недоступности части функционала.
Первичное тестирование проводится от имени пользователей с ограниченными правами: один пользователь с минимальным набором прав (учетная запись самого младшего специалиста), другой - с максимальным (руководитель подразделения/предприятия).
ВАЖНО!
Регламентные тесты проводятся только после того, как все изменения в программу уже внесены, иначе он будет неэффективным. Во время проведения регламентного теста допустимо исправление только критичных ошибок. Остальные ошибки фиксируются для исправления в следующих версиях.