|
|
|
Тестирование сборки (релиза) перед переносом в продуктив
|
|||
|---|---|---|---|
|
#18+
Очень часто при разработке нового функционала несколько доработок ведутся параллельно и их не получается поставить одновременно (единовременно) с использованием консолидированного тестирования. Приходится после основного тестирования, делать сборку для каждой подзадачи и переносить отдельно. В сборку могут входить не только код, но и скрипты для создания данных в справочниках и т.д. Созданную сборку необходимо проверять, так как при сборке могут что-то забыть туда включить, даже если в тесте все работает. Сейчас по сути накатываем сборку еще раз в копии тестовой базы , чтобы получить тот же результат. Тест не совсем надежный но зато требует меньше времени. Вопрос может есть более лучшие Best practices с точки зрения временных затрат на проверку? Понятно что в идеале нужно полное тестирование сборки но это время. Платформа 1С если это имеет значение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2015, 13:58 |
|
||
|
|

start [/forum/topic.php?fid=36&fpage=4&tid=1554634]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
63ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
32ms |
get tp. blocked users: |
1ms |
| others: | 12ms |
| total: | 151ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...