Выделение времени устранения ошибки [закрывается]
Тот факт, что тест пройден, означает, что тест не зависит от того, какое изображение найдено. Неработающая ссылка на изображение, как правило, не приводит к сбою теста, и на самом деле часто авторы тестов даже не удосуживаются предоставить имитированные изображения, потому что это (воспринимается как) слишком много работы и не имеет отношения к тестируемой вещи. .
Смотрите, ребята, вот почему мы просим привести пример . Теперь, когда ОП опубликовал пример , мы можем видеть, что его проблема заключается в кэшировании в браузере, и будет решена заменой
product.images.attach io: File.open(path), filename: 'image.png'
на
product.images.attach io: File.open(path), filename: "image-#{Time.now.strftime("%s%L")}.png"
в помощнике, который делает приложение. Я бы не решил это без примера.
Пояснение
ActiveStorage обрабатывает сохранение и обслуживание файлов. OP сохранял и обслуживал изображения с этим, что определенно предназначалось для этого. Чтобы разные службы могли обслуживать файлы по-разному, ActiveStorage отделяет опубликованный URL-адрес от фактического URL-адреса, обслуживающего изображения.
Опубликованный URL является почти постоянной ссылкой: это закодированная версия ключа базы данных для вложения. ActiveStorage обрабатывает запрос URL-адреса путем поиска места хранения файла и отправки временного перенаправления 302 на URL-адрес, который можно использовать для доступа к файлу, который называется «служебный URL-адрес». При использовании AWS S3 для хранения файлов служебный URL-адрес может быть подписанным URL-адресом, срок действия которого быстро истекает, но, тем не менее, он подключает браузер напрямую к S3, а не через веб-сервер в качестве посредника.
По умолчанию URL-адрес службы действителен в течение 5 минут, и ActiveRecord явно устанавливает
Cache-Control: max-age=300, private
при перенаправлении 302. Браузер кэширует этот ответ на перенаправление, и в течение следующих 5 минут браузер даже не будет пытаться использовать или проверить опубликованный URL-адрес, он немедленно заменит общедоступный URL-адрес на кэшированный URL-адрес службы.
К сожалению, хотя общедоступный URL-адрес предсказуемо воссоздается, URL-адрес службы генерируется случайным образом, поэтому, когда браузер выполняет автоматическое перенаправление, ранее действительный URL-адрес службы больше не работает. Решение (или обходной путь, в зависимости от вашей точки зрения) состоит в том, чтобы различать общедоступные URL-адреса путем добавления метки времени в имени файла, чтобы тесты не использовали повторно общедоступные URL-адреса.
Sidenote
Кстати, вам не следует использовать url_for с image_tag. Измените ваш ERB с
= image_tag url_for(product.image.variant(resize: "120x120"))
на
= image_tag(product.image.variant(resize: "120x120"))
Rails достаточно умен, чтобы справиться с любым случаем, но последний способ является рекомендуемым.
8 ответов
Единственный ответ, который я могу дать, должен быть чрезвычайно консервативным. Угадайте, сколько времени это возьмет, и несколько Ваше предположение четыре. Используйте это в качестве своей оценки. Как Вы сказали, очень трудно выяснить, сколько времени вещи возьмут для фиксации, и лучше сказать, что это займет больше времени, чем это на самом деле делает, чем быть пойманным, "повреждая крайний срок", потому что Вы не были достаточно консервативны.
Компания, на которую я работаю часто, получает неблагоразумные запросы от наших клиентов. Ключевая вещь помнить состоит в том, что клиенты хотят быть хорошо информированными. Мы нашли лучший способ сделать, это с точки зрения отчетов о состоянии.
Так, мы сначала делаем довольно хорошее задание разъяснения нашей позиции. В Вашем примере это было бы чем-то вроде этого:
У нас есть расписание набора для того, чтобы исправить ошибки в нашем проекте, который у нас есть исторически хороший послужной список оставания в графике. Однако процесс детализации, сколько времени каждая ошибка возьмет для фиксации, довольно подвержен ошибкам. Мы были бы рады предоставить Вам еженедельные обновления (или два раза в неделю или ежедневный в зависимости от клиента) на ошибках, которые были исправлены и меры, которые были протестированы.
Однако я действительно полагаю, что хорошо попытаться оценить, сколько времени каждая ошибка возьмет для фиксации. Причина этого - Вы, должен понять то, что общее время исправить все ошибки возьмет. Вы не сможете получить точную оценку, если у Вас не будет оценки, как долго отдельные части возьмут для фиксации. Они могут быть грубыми оценками, конечно (оцененный не более, чем расходы час, исследуя проблему) - Вы не хотите тратить впустую слишком много времени, оценивая. Затем я обычно фактор в дополнительных 20%. Поэтому скажите, что оценки для ошибок составляют 3 дня, 5 дней и 2 дня. Затем я сообщил бы клиенту, что мы должны смочь исправить ошибки через 12 дней. Затем, конечно, Вы, возможно, должны добавить больше времени для тестирования и переупаковки Вашего продукта, прежде чем можно будет дать им поставляемый компонент.
Это должно совпасть с оценкой любой другой задачи, которую Вы имеете. Разделите его на самые маленькие возможные задачи и оцените их так точно, как Вы можете с дополнением для неожиданного. Затем дайте им диапазон, таким образом, Вы не придавлены на определенную дату на задачах, которые не четко определены. Нет никакого различия между оценкой, что время исправляет ошибку и оценку, что время реализует опцию с туманными требованиями.
Не думайте об этом с точки зрения оценки, сколько времени ошибки берут для фиксации, потому что Вы не можете возможно оценить это правильно.
Думайте об этом с точки зрения руководящего клиентского гнева. Если Вы скажете им, что ошибки займут время вообще для фиксации, и они заканчивают тем, что заняли 3 месяца, то клиент будет доволен Вами теперь и разъярен Вами в будущем.
Если Вы скажете им, что ошибки займут 3 месяца для фиксации, и они на самом деле занимают 3 месяца для фиксации (который они будут), то клиент будет разъярен теперь и доволен Вами в будущем.
Я обычно говорю, что ошибки займут время вообще (2-3 дня, кажется, хорошее число умиротворения).
Вы правы, оценки обычно неточны.
Возможно, Вы хотите спросить их, какого количества каждая ошибка стоит им, если она идет открепленная. Затем можно выполнить соответствующее вычисление для выяснения, если они должны когда-либо фиксироваться, и сколько времени (или реалистично, они) можно позволить себе посвятить каждой ошибке.
Почему не только выбирают несколько полос для серьезности ошибки, например, 1 час, 1/2 день, 1 день, 1 неделя и присваиваются против них. Обычно у Вас будет чувство для ошибки - для которых Вы понятия не имеете, помещаете худшее число случая в него!
Я не думал бы, что Вы будете требоваться для оценки на любом более прекрасном уровне, чем это по причинам, которые Вы заключили в кавычки (занимающий слишком много времени заниматься расследованиями, и т.д.)
Я не думаю, что это - пустая трата времени. Ваш клиент хочет знать больше, чем количество ошибок и их приоритета - они хотят чувство для того, сколько работы остается.
Ни при каких обстоятельствах не должен этот результат в Вас генерирующий больше ошибок. Вы не должны спешить на время фиксировать их. Если Вы оценили 1 день, и он оснащает 10 часов, это в порядке. Если Вы оценили 1 неделю, и потребовалось 2 часа, хороший результат!
Это - просто упражнение в оценке!
Обычно мы будем соглашаться, какие ошибки должны быть исправлены для конкретного выпуска и затем определить период времени для того, чтобы исправить все ошибки. Для каждой отдельной ошибки существует большая неуверенность/изменчивость в том, сколько времени она могла взять для фиксации, но это имеет тенденцию составлять в среднем с большим числом ошибок. Для определенных ошибок, которые Вы знаете, займет больше времени, может быть возможно дать некоторые оценки, например, если необходимо записать средство моделирования или среду тестирования для него.
Если это ошибки, которые нашли и сообщили, то необходимо смочь разработать оценку на времени для фиксации его (и время для перетестирования). Уверенность оценки, вероятно, будет пропорциональна времени, которое Вы проводите на оценке, возможно, объясняете эту стоимость для клиента.
Если существует много связанных маленьких отчетов об ошибках, возможно, Вы могли бы свернуть их в один всеобъемлющий отчет. Это могло бы избежать клиента, пытающегося привередничать который ошибки зафиксировать базирующийся просто на отдельных оценках.