Как зафиксировать ошибку

Программирование  •  01 декабря  2022  •  5 мин чтения

Тот ещё жук: как начинающему тестировщику составить хороший баг‑репорт

Баг-репорт — это документ о дефекте. Одни команды не тратят на него много времени, другие — фиксируют каждый баг. Рассказываем, как тестировщику правильно оформить баг-репорт.

  • Что такое баг
  • Виды багов
  • Приоритеты и жизненный цикл бага
  • Как выглядит жизненный цикл бага в теории и на примере дефекта в интернет-магазине
  • Что такое баг-репорт
  • Шаблон баг-репорта
  • Как правильно оформить баг-репорт
  • Совет эксперта

Что такое баг

Багом (от англ. bug) или дефектом часто называют ошибку в программном коде. Это не совсем ошибка, а скорее несоответствие фактического результата ожидаемому. То, как должна работать программа, описывают в требованиях к разработке. В идеальном мире она будет работать именно так, как её задумали заказчики. Но в реальности можно увидеть не то, что ожидалось.

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

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

Иногда баг все же оказывается в продукте после того, как его выпустили на рынок. Тогда он становится проблемой пользователей и службы технической поддержки. Такие дефекты часто бывают некритичными: опечатка в описании, вёрстка поехала. Для пользователя это неудобно, но в целом не приводит к серьёзным последствиям. Но иногда баги относятся к архитектуре системы или требованиям. Их обнаруживают не сразу, и они могут привести к убыткам для бизнеса. Например, для продукта заложили архитектуру, при которой невозможно писать юнит-тесты. Из-за этого с ростом продукта на тестирование тратят всё больше времени, а разработка становится всё дороже.

Как таблица решений помогает провести все тест-кейсы и ничего не забыть

Виды багов

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

Визуальный, относится к интерфейсу приложения. Кнопка «Купить» уехала за пределы экрана.

Функциональный. Не сохраняются данные: пользователь нажимает кнопку «Купить», но ничего не происходит, или может применить одноразовый купон на скидку два раза.

Дефект UX, влияет на удобство. Чтобы подтвердить мобильный телефон, пользователю приходится несколько раз покидать и возвращаться в мобильное приложение.

Баг нагрузки. Интернет-магазин должен выдерживать большой наплыв посетителей, например в Чёрную пятницу, поэтому там часто проводят нагрузочное тестирование. Например, искусственно создают ситуацию, когда в один раздел одновременно зашло несколько тысяч пользователей. Если приложение не загружается или зависает — это баг нагрузки.

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

Баг требований, или логический баг. До начала разработки приложения или отдельной «фичи» в требованиях что-то не учли. Например, забыли добавить всплывающее оповещение, что при включённом VPN приложение может работать с ошибками. Программист запрограммировал так, как было в требованиях (или как он их понял). В итоге, приложение работает, как описано в требованиях, но не так, как нужно бизнесу.

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

Начните карьеру в IT с профессии тестировщика

Спустя 4 месяца обучения в вашем портфолио будет 6 протестированных приложений. Пройдите бесплатную вводную часть курса, чтобы попробовать себя в роли тестировщика.

Приоритеты и жизненный цикл бага

Чем отличается приоритет от серьёзности и как их используют

У бага есть два важных атрибута — приоритет и серьёзность.

Серьёзность показывает, насколько баг влияет на возможность работать в программе. Обычно выделяют 5 уровней серьёзности бага. Самый опасный — блокирующий баг. Например, мобильное приложение перестало загружаться, и пользователь видит пустой экран. Самый безвредный — тривиальный баг. Он не влияет на работу приложения, а многие пользователи его даже не заметят. Это может быть, например, опечатка в разделе меню, куда редко заходят.

Приоритет — это критерий, который показывает, насколько быстро нужно исправить дефект. С точки зрения функционала баг может быть несерьёзный и некритичный, но при этом важный для бизнеса. Обычно выделяют три приоритета:

● высокий — исправить в первую очередь;
● средний — исправить, когда разобрались с первой категорией багов;
● низкий — исправить, когда разобрались с багами других приоритетов.

На проектах редко используют оба атрибута — в основном объединяют приоритет и серьёзность, или выбирают что-то одно. Чаще всего это приоритет — с точки зрения планирования важно понимать, что исправлять в первую очередь, а что может подождать.

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

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

Тестировщику, который давно на проекте, важно понимать, что приоритетно для конкретного продукта. Для начинающего тестировщика главное — правильно обнаружить и локализовать баг, а с приоритетом поможет более опытный коллега-ментор. Он перепроверяет баги, смотрит, какие тесты провел джун, поддерживает его и постепенно отправляет в свободное плавание.

Как выглядит жизненный цикл бага в теории и на примере дефекта в интернет-магазине

У бага есть нулевая стадия, когда он, как кот Шрёдингера, может быть багом, а может — просто непониманием со стороны пользователя. Тестировщик сталкивается с чем-то непонятным в работе системы и начинает разбираться, что произошло. Это называется локализацией. Её цель — убедиться, что обнаружили именно дефект. Для этого тестировщик смотрит проектную документацию, ставит эксперименты и узнаёт, в каких ситуациях воспроизводится дефект и можно ли его как-то обойти.

В результате локализации может быть два вывода:

Это не баг, или проблема не на стороне разработчиков. Например, внутренний пользователь чего-то не знает по системе и его нужно обучить. Или у пользователя приложения застряли деньги, а проблема на стороне банка.

Это баг программы, и его нужно завести в баг-трекинговой системе.

Так выглядит упрощенный жизненный цикл бага

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

Баг, как и другие задачи проекта, фиксируют в трекинговой системе. В ней на каждом жизненном этапе дефект получает статус. Самая популярная баг-трекинговая система — Jira. В Яндексе используют её аналог — Яндекс Трекер.

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

● Тестировщик описал, в чём проблема, и присвоил задаче статус — новый баг.

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

● Аналитик добавил уточнения по задаче и передал разработчику. Новый статус — в разработке.

● Разработчик отдаёт задачу аналитику, если хочет что-то уточнить, а если нет, то передает тестировщику.

● Тестировщик проводит ретест — проверяет, исправили баг или нет. Если проблему решили, он закрывает задачу, если нет — возвращает задачу разработчику. Она снова получит статус «В разработке».

● Отработанную задачу тестировщик передаёт во внедрение. После этого приложение либо обновят сразу, либо подождут до релиза: тогда обновленную функциональность добавят в приложение вместе с другими отработанными задачами.

● Готово. Теперь пользователь видит только актуальные товары.

Если дефект повторится, то баг реинкарнирует: его заводят как новую задачу, и он проходит тот же жизненный цикл.

Пример жизненного цикла бага на реальном проекте

Пример жизненного цикла бага на реальном проекте

Что такое баг‑репорт

В тестировании баг-репорт — это отчёт об ошибке, который заводится в баг-трекинговой системе.

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

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

Примеры метрик:

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

Опытные тестировщики советуют искать золотую середину:

● Фиксировать все баги с прода — если они мешают пользователям, то могут быть критичными и для бизнеса.

● Оформлять регрессионные баги — их находят во время подготовки продукта к релизу, и они не относятся к какой-то конкретной задаче. Если такие дефекты не исправить, их могут найти уже пользователи.

● Если в Jira уже есть задача, внутри которой нашли баг — не оформлять его отдельно, а написать в комментарии к этой задаче. Допустим, в приложение интернет-магазина решили добавить новую функцию к Чёрной пятнице — купон на скидку. Когда пользователь его применит, все товары в корзине подешевеют на 20%. Купон должен работать только когда в корзине больше одного товара. Программисты закончили разработку и передали в тестирование. Тестировщик нашёл баг: если удалить из корзины все товары, кроме одного, скидка так и останется — 20%. Такой баг оформляют в виде комментария.

Шаблон баг‑репорта

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

Как правильно оформить баг‑репорт

Хороший баг-репорт приходит с опытом. Вот на что нужно обратить внимание джуну:

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

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

Вложения. Если баг визуальный или UX (поехала вёрстка, не работает кнопка), то без скриншота или скринкаста не разобраться — важно показать, что видит пользователь.

Шаги воспроизведения. Бывает, что джун начинает издалека: «Включить компьютер». Или пишет слишком абстрактно: «Заходишь на страницу, товар не отображается». Важно искать золотую середину: описывать те шаги, которые относятся к багу, и так, чтобы другим коллегам было понятно. Например: нажать кнопку «Начать», сканировать любой товар из задачи.

Взгляд на проблему. Тестировщику важно хотя бы пытаться смотреть на проблему с точки зрения бизнеса. Например, текст не помещается в поле, а как этот баг влияет на бизнес? Ответ на вопрос поможет в будущем определять серьёзность и приоритет бага.

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

Как не стоит писать баг-репорты

Как не стоит писать баг-репорты. Опытный тестировщик в ответ на такой документ скажет, что баг-репорт описан непонятно: что значит «нельзя сканировать»? В результатах нужно описывать, что происходит, а не то, чего не происходит. Не хватает информации о том, какие материалы нужно приложить к такому багу, скриншоты или скринкасты

Вот как могли бы оформить этот баг более опытные джуны и продвинутые тестировщики.

Баг-репорт от опытного джуна или ленивого мидла

Заголовок: [Инвентаризация] В начатой задаче при попытке сканирования товаров визуально ничего не происходит

Предусловия: Приложение Инвентаризация запущено и активно, открыта невыполненная задача для инвентаризации

Шаги:

1. Нажать кнопку «Начать».

2. Сканировать товар, присутствующий в задаче и еще не отсканированный.

Фактический результат: при попытке сканирования товара визуально ничего не происходит. В логах ошибка <Error…> (приложен лог с ошибкой).

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

Окружение: Apple iPod touch 32 Gb.

Приоритет: критичный.

Баг-репорт от мидла или сеньора

Заголовок: [Инвентаризация] В начатой задаче сканирование товара не записывается в задачу, в логах ошибка <Error…>.

Предусловия: Приложение Инвентаризация запущено и активно, открыта невыполненная задача для инвентаризации.

Шаги:

1. Нажать кнопку «Начать».

2. Сканировать любой товар из задачи.

Фактический результат: при попытке сканирования товара сканер пищит (как и должен), но в задачу сканирование не записывается. В системных логах приложения ошибка <Error…> (приложен кусок лога с ошибкой). В серверных логах ошибка <Error…> (приложен кусок лога с ошибкой).

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

Доп.информация: если отправить запрос о сканировании не с устройства, а через эмулятор, то ошибок не возникает, возвращается корректный ответ (приложены запрос и ответ и логи с эмулятора).
Окружение: Apple iPod touch 32 Gb, версия приложения 1.2.21.3, тестовый стенд INTG.

Приоритет: критичный.

В примерах нет ошибок, но видно, как можно подойти к задаче в зависимости от опыта.

Совет эксперта

Ольга Ермолаева

Самый полезный для тестировщика вопрос — «Что если?». На нём завязана вся локализация. Выдвигайте больше гипотез и проверяйте их с разных сторон.

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

Руководитель направления QA

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

Кто такой инженер по тестированию и как им стать, чтобы начать IT-карьеру

First, if you use require, it’s always going to kill your app if the file cannot be included. There’s no control over the outcome, you cannot do anything afterwards. If you want to have control over the success of file inclusions, use include and test its return value.

$success = include "foo.php";
if (!$success) {
    // the file could not be included, oh noes!
}

You can have syntactical differences on that like:

if (!(include "foo.php")) ...

This will trigger an E_NOTICE if the file cannot be included, which you cannot catch. But that’s OK, since it’ll help you debug the issue and the display of errors will be turned off in production anyway (right, right?).

or throw new Exception doesn’t work because throw is a statement and cannot be used where an expression is expected.


If you want to catch syntax errors in the included file, use php_check_syntax/it’s successor php -l <file>.

#1

Фрося

  • ФИО:Радилова Елена Игоревна

Отправлено 04 декабря 2009 — 07:27

А как разумнее зафиксировать Ошибку (дефект, баг), в случае — если требуются изменения не только в коде ПО, но и в Спецификации ПО (Требованиях ПО) ?
Как пример. Сугубо — от пользователя.
Переоформляла карту в одном из банков.
При заполнении анкеты необходимо заполнить поле, вписав туда «любой год» (примерно такая формулировка). Поле — рассчитано на 4 цифры.
Вписываю: (пробел) 988 год.
Барышня-операционистка пытается ввести. Не вводится — «ошибка ввода». Зовет менеджера. Заменяют (пробел) на «0» — «ошибка ввода».
Менеджер задумывается и говорит:
«Ну… обычно год своего рождения вводят..»
«Не вопрос!» (мне уже интересно!)»Ставим год -1900. Да! Мне больше 100 лет! Но я прекрасно выгляжу!!! И хочу карту!»
Не вводится… «ошибка ввода»
В общем… ввели что-то…..
Менеджер пошла записывать в журнал — что надо позвонить «нашему сисадмину, чтоб что-то сделал…»

Ситуация вполне жизненная.
Итак.
КАК зафиксировать ошибку подобного типа? Так, чтобы были ИСПРАВЛЕНЫ все документы? Вплоть до анкеты клиента банка?

У меня область применений ПО совсем-совсем другая… но увы… схожие ситуации тоже бывают..

  • 0

Почему-то по пятницам особо остро хочется быть блондинкой….

  • Наверх


#2

Alfa

Отправлено 04 декабря 2009 — 07:44

КАК зафиксировать ошибку подобного типа? Так, чтобы были ИСПРАВЛЕНЫ все документы? Вплоть до анкеты клиента банка?

А чем плох обычный метод, через баг трекер?

  • 0

Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.

  • Наверх


#3

Фрося

Фрося

  • ФИО:Радилова Елена Игоревна

Отправлено 04 декабря 2009 — 08:17

КАК зафиксировать ошибку подобного типа? Так, чтобы были ИСПРАВЛЕНЫ все документы? Вплоть до анкеты клиента банка?

А чем плох обычный метод, через баг трекер?

Хорош!
Проигрываем ситуацию.
Менеджер «звонит сисадмину» — ну.. вот такой способ у менеджера разбираться с проблемами…
Дальше что?
Сисадмин имеет доступ к баг трекеру?
Ну ладно… предположим — что имеет…
Повторил у себя ситуацию, подумал, записал…
А что? Записал-то?
И как потом из баг трекера, какими путями добраться до изменения Анкеты клиента (однозначно придется — «любой год» и есть «любой год»…клиент догадываться не должен — что имелось в виду)?
И кто определяет — менять Спецификацию или нет?
Вот что для меня неочевидно..

  • 0

Почему-то по пятницам особо остро хочется быть блондинкой….

  • Наверх


#4

Alfa

Отправлено 04 декабря 2009 — 09:01

А что? Записал-то?
И как потом из баг трекера, какими путями добраться до изменения Анкеты клиента (однозначно придется — «любой год» и есть «любой год»…клиент догадываться не должен — что имелось в виду)?

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

Правда я пока не до конца понял фраза «добраться до изменения Анкеты» означает «как догадаться, что надо менять анкету» или «как процедурно организовать изменение анкеты и кто это делает»? Мой ответ про второй вариант.

И кто определяет — менять Спецификацию или нет?
Вот что для меня неочевидно..

Если это ошибка, то какие могут быть сомнения? Кто-то же отвечает за спецификацию у него и спросите или как там у Вас устроено.

Извините что я все время вопросами отвечаю.

  • 0

Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.

  • Наверх


#5

Boltick

Boltick

  • ФИО:Алексей
  • Город:планета Земля

Отправлено 04 декабря 2009 — 09:08

Хорош!
Проигрываем ситуацию.
Менеджер «звонит сисадмину» — ну.. вот такой способ у менеджера разбираться с проблемами…
Дальше что?
Сисадмин имеет доступ к баг трекеру?
Ну ладно… предположим — что имеет…
Повторил у себя ситуацию, подумал, записал…
А что? Записал-то?
И как потом из баг трекера, какими путями добраться до изменения Анкеты клиента (однозначно придется — «любой год» и есть «любой год»…клиент догадываться не должен — что имелось в виду)?
И кто определяет — менять Спецификацию или нет?
Вот что для меня неочевидно..

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

Вот.

  • 0

  • Наверх


#6

Фрося

Фрося

  • ФИО:Радилова Елена Игоревна

Отправлено 04 декабря 2009 — 09:53

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

Вот.

Вообще кто я ?
Видимо… дамочка за все.. От написания Требований… до…(здесь уже писала… )

(В случае с банком и багами в банковском ПО — вообще КЛИЕНТ!!!! Такой — въедливо-любопытный.)
Разница у меня с Вами — принципиальная.
Вы, судя по посту — работае в фирме где процессы организованы…и роли расписаны…
А я — в фирме, где все это еще в стадии организации….И в этой организационной стадии принимать участие и мне… С учетом специфики фирмы..

Потому Вы передали аналитику — и все…Вопрос закрыт. Для Вас. У меня — другая ситуация…
Так что -вопросы еще буду задавать.
Меня полный цикл интересует… как от баги, выявленной у пользователя добраться до изменения Спецификации ПО и документации пользователя?

Хорошо. Пусть бага отправлена аналитику. Какой документ он оформляет, чтоб исправить Спецификацию?
Какой документ оформляется, чтоб исправить анкету Клиента?

Уф… если ссылочка на ресурс интернетовский будет — благодарность моя безгранична…

  • 0

Почему-то по пятницам особо остро хочется быть блондинкой….

  • Наверх


#7

Фрося

Фрося

  • ФИО:Радилова Елена Игоревна

Отправлено 04 декабря 2009 — 10:06

Напишите ему задачу поменять то-то и то-то. И привяжите ее к багу или просто упомяните там, чтоб при провереке не забыть.
Правда я пока не до конца понял фраза «добраться до изменения Анкеты» означает «как догадаться, что надо менять анкету» или «как процедурно организовать изменение анкеты и кто это делает»? Мой ответ про второй вариант.

И кто определяет — менять Спецификацию или нет?
Вот что для меня неочевидно..

Если это ошибка, то какие могут быть сомнения? Кто-то же отвечает за спецификацию у него и спросите или как там у Вас устроено.

Извините что я все время вопросами отвечаю.

Спасибо -что отвечаете. А что вопросами — так это вполне нормально.

В БАНКЕ Я КЛИЕНТ! ДАМОЧКА С УЛИЦЫ! ЭТО — реальный случай из моей жизни.

Именно — как процедурно организовать изменение во всех (ну… если по — умному) — объектах конфигурационного управления?

РС.
У нас пока устроено…. ну…. (смайлики…смайлики…) — неформально-курилочно-записочно!

  • 0

Почему-то по пятницам особо остро хочется быть блондинкой….

  • Наверх


#8

Clauster

Clauster

  • ФИО:Худобородов Валерий
  • Город:Espoo

Отправлено 04 декабря 2009 — 10:57

Чего непонятного-то? Приходит фидбэк от клиента, саппорт обрабатывает, если не могут сами исправить (спеку, форму, базу) и для этого нужн выпустить новую версию, передают дальше. Вроде очевидно все. Будет это багтрекер, емейл, звонок по телефону или общение в курилке — абсолютно не важно, главное решить проблему быстро и эффективно. Если это действительно проблема.

  • 0

  • Наверх


#9

Фрося

Фрося

  • ФИО:Радилова Елена Игоревна

Отправлено 04 декабря 2009 — 11:26

Чего непонятного-то? Приходит фидбэк от клиента, саппорт обрабатывает, если не могут сами исправить (спеку, форму, базу) и для этого нужн выпустить новую версию, передают дальше. Вроде очевидно все. Будет это багтрекер, емейл, звонок по телефону или общение в курилке — абсолютно не важно, главное решить проблему быстро и эффективно. Если это действительно проблема.

И как это? Поговорили по телефону/в курилке….
Побежали Спецификацию ПО исправлять?
А кому-то в коридоре сказали — «Тань! исправь там анкету клиента….»
Ну и как все это вписать в управление конфигурациями?

Т.е. тестер баг фиксирует, сообщение об ошибке оформляет. Это понятно.
А что оформлять (какой документ) — для изменения не кода программы, а других объектов УК?
Для изменения Спецификации ПО? Для изменения пользовательской документации?
Как решить проблему быстро, эффективно, и при этом — внести изменения во все объекты конфигурации ПО?

Как цепочку-то выстроить (минималистическую!) в случае «Приходит фидбэк от клиента»?

Опять же — повторюсь — процесс пока абсолютно не формализован. Соответственно — ситуации при которых по результатам «разговора в курилке» программа меняется, а вот другие объекты (от Спецификации до пользовательской документации…) …
И …. не получается качественное ПО…. а так..что-то..

  • 0

Почему-то по пятницам особо остро хочется быть блондинкой….

  • Наверх


#10

greyver

greyver

  • ФИО:Вербенко Сергей Анатольевич
  • Город:Москва, Зеленоград

Отправлено 04 декабря 2009 — 12:47

Т.е. тестер баг фиксирует, сообщение об ошибке оформляет. Это понятно.
А что оформлять (какой документ) — для изменения не кода программы, а других объектов УК?
Для изменения Спецификации ПО? Для изменения пользовательской документации?

выпишите сообщение, на изменение других объектов (спецификации, документации)

Как цепочку-то выстроить (минималистическую!) в случае «Приходит фидбэк от клиента»?

Аналогично тому, как и находит тестер проблему в … (коде, спецификации, документации)

  • 0

  • Наверх


#11

astenix

Отправлено 04 декабря 2009 — 15:58

И как это? Поговорили по телефону/в курилке….
Побежали Спецификацию ПО исправлять?
А кому-то в коридоре сказали — «Тань! исправь там анкету клиента….»
Ну и как все это вписать в управление конфигурациями?

Фрося, распечатайте на бумаге с гербом следующий текст:

СООБЩЕНИЕ ОБ ОШИБКЕ!

Под этим текстом помельче:

«Там вот что-то не работает. Барышня-операционистка пытается ввести. Не вводится. Зовет менеджера. Заменяют (пробел) на «0» — «ошибка ввода». Менеджер задумывается и говорит: «Ставим год -1900. Да! Мне больше 100 лет! Но я прекрасно выгляжу!!! И хочу карту!» Не вводится… «ошибка ввода». В общем… ввели что-то….. Ситуация вполне жизненная.«

Ниже:

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

Имя, подпись (кровью).

И эту бумагу кладете на подпись сисадмину. Ну, он же с компами возится…

А если не подпишет — сразу докладную начальнику совета директоров и президентов банка. И в докладной пишете проблему очень, очень подробно:

«Там вот что-то не работает. Барышня-операционистка пытается ввести. И менеджер пытается ввести. И менеджер задумывается. Да! Мне больше 100 лет! Но я прекрасно выгляжу!!! И хочу карту! Не вводится… «ошибка ввода». В общем… ввели что-то….. Ситуация вполне жизненная.«

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

Как цепочку-то выстроить (минималистическую!) в случае «Приходит фидбэк от клиента»?

  • Определить, в чьей компетенции находится проблема, которая получена от клиента.
  • Направить ему сообщение на исполнение.
  • Получить исправление .
  • Проверить исправление.
  • Направить к тому, в чьей компетенции находится ведение процессов запрос на рассмотрение необходимости внесения изменения в такой-то документ.
  • Получить исправление .
  • Проследить за внедрением исправления.

«разговора в курилке» программа меняется, а вот другие объекты (от Спецификации до пользовательской документации…) …
И …. не получается качественное ПО…. а так..что-то..

Даже если у вас Документация в ПОЛНОМ порядке, это не значит, что все будет в ПОЛНОМ порядке в софте. Для вас что важнее?

  • 0

  • Наверх


#12

Clauster

Clauster

  • ФИО:Худобородов Валерий
  • Город:Espoo

Отправлено 04 декабря 2009 — 16:50

Чего непонятного-то? Приходит фидбэк от клиента, саппорт обрабатывает, если не могут сами исправить (спеку, форму, базу) и для этого нужн выпустить новую версию, передают дальше. Вроде очевидно все. Будет это багтрекер, емейл, звонок по телефону или общение в курилке — абсолютно не важно, главное решить проблему быстро и эффективно. Если это действительно проблема.

И как это? Поговорили по телефону/в курилке….
Побежали Спецификацию ПО исправлять?
А кому-то в коридоре сказали — «Тань! исправь там анкету клиента….»
Ну и как все это вписать в управление конфигурациями?

Т.е. тестер баг фиксирует, сообщение об ошибке оформляет. Это понятно.
А что оформлять (какой документ) — для изменения не кода программы, а других объектов УК?
Для изменения Спецификации ПО? Для изменения пользовательской документации?
Как решить проблему быстро, эффективно, и при этом — внести изменения во все объекты конфигурации ПО?

Как цепочку-то выстроить (минималистическую!) в случае «Приходит фидбэк от клиента»?

Опять же — повторюсь — процесс пока абсолютно не формализован. Соответственно — ситуации при которых по результатам «разговора в курилке» программа меняется, а вот другие объекты (от Спецификации до пользовательской документации…) …
И …. не получается качественное ПО…. а так..что-то..

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

  • 0

  • Наверх


#13

Фрося

Фрося

  • ФИО:Радилова Елена Игоревна

Отправлено 05 декабря 2009 — 09:22

Даже если у вас Документация в ПОЛНОМ порядке, это не значит, что все будет в ПОЛНОМ порядке в софте. Для вас что важнее?

Для меня как клиента банка? Что важнее?
Чтоб мне, клиенту удобней было. Клиент софт и документацию(ту же анкету) не разделяет. Ему — качественный конечный продукт нужен.
Вы вкус гамбургера(софт), поданного Вам в куске рваной, грязной газеты(документация пользователя) оценивать будете? Я — нет. Я такой гамбургер в руки не возьму (исключение — жуткий голод).
А уж какие там процессы на кухне, или насколько модерновый холодильник, или сколько сертификатов у персонала — клиента вообще не интересует.

За цепочку — спасибо. Она вполне понятна.

  • 0

Почему-то по пятницам особо остро хочется быть блондинкой….

  • Наверх


#14

Clauster

Clauster

  • ФИО:Худобородов Валерий
  • Город:Espoo

Отправлено 05 декабря 2009 — 10:41

Для меня как клиента банка? Что важнее?
Чтоб мне, клиенту удобней было. Клиент софт и документацию(ту же анкету) не разделяет. Ему — качественный конечный продукт нужен.

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

  • 0

  • Наверх


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

Один из примеров ― баг-репорт (от англ. bug report ― отчёт об ошибке), который содержит описание всех найденных дефектов в работе приложения. Не имеет значения, тестируете ли вы компьютерную игру, приложение для банка или сайт онлайн-магазина ― составление правильного отчёта является залогом продуктивного QA-процесса.

Баг-репорт содержит ответы на следующие вопросы:

  • что идёт не так;
  • где проявляется дефект;
  • когда ошибка воспроизводится.

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

Разберёмся, как добиться этого сочетания.

Как выявляют баги?

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

  1. во время проведения тестирования ПО;
  2. при обращении заказчика с описанием ошибки;
  3. из сообщений пользователей, которые столкнулись с проблемами во время использования программного продукта.

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

Какой инструмент используют для документирования дефектов?

Самой распространённой системой для отслеживания дефектов является JIRA. Данный ресурс позволяет фиксировать ошибки и следить за их жизненным циклом. Но эта программа не такая простая, особенно для новичков в ИТ. Поэтому важно ознакомиться с её функционалом.

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

Некоторые компании отдают предпочтение и менее известным инструментам, например, Redmine или Mantis.

Каких правил придерживаться при написании баг-репорта?

Правило №1: следуйте принципу «1 дефект = 1 баг-репорт». Это позволит сохранить прозрачность процессов на проекте и детально следить за исправлением недочётов.

Правило №2: пишите баг-репорт простым и лаконичным языком, ведь от того, насколько быстро разработчик поймёт суть проблемы зависит скорость внесения правок в код.

Правило №3: описывайте дефект кратко, но с сохранением максимума полезной информации.

Правило №4: удостоверьтесь в воспроизводимости ошибки до заведения баг-репорта, повторите свой алгоритм действий и по возможности сократите число шагов.

Правило №5: проверьте, нет ли идентичного дефекта, который уже был зафиксирован.

Если всё в порядке, можно переходить к описанию.

Из каких элементов состоит баг-репорт?

Форма заполнения баг-репорта включает несколько полей (атрибутов). Туда тестировщик вносит характеристики дефекта. Число атрибутов может варьироваться в зависимости от баг-трекинговой системы и особенностей проекта, но с некоторыми тестировщики работают постоянно. Рассмотрим их:

Summary (заголовок)

Первый элемент баг-репорта — это краткое описание сути проблемы. В этом поле мы должны коротко и ясно описать выявленный дефект. Уже на этом этапе вы можете придерживаться правила «Где? Что? Когда или в каких условиях?». Не лишним будет добавить и данные о тестовом окружении, под которым выявлен дефект. Формулируйте этот атрибут в виде связного предложения, так будет проще вникнуть в суть проблемы.

Давайте рассмотрим конкретный пример. Представьте, что вы тестируете площадку объявлений menyaemsya.com. Согласно требованиям, поле с описанием товара должно содержать максимум 350 символов. Но вы видите, что система пропускает описание, которое превышает данный лимит. Для этого дефекта вам нужно составить баг-репорт. Воспользуемся подсказкой «Что? Где? Когда?», чтобы составить заголовок. Получается:

«Ограничение на ввод символов в поле с описанием товара отсутствует на всех страницах».

При тестировании мобильных приложений важно внести и название платформы, iOS или Android.

Заголовок готов. Можем двигаться дальше.

Description (описание)

Содержание этого поля отличается в зависимости от баг-трекинговой системы. Например, JIRA или Redmine предполагают описание шагов воспроизведения ошибки. Пользователи Mantis тут могут более подробно описать суть проблемы, а для описания пути воспользоваться атрибутом «Steps to reproduce» (в пер. с англ. «действия по воспроизведению»). Выглядеть это описание может следующим образом:

  1. переход на сайт menyaemsya.com;
  2. вход или регистрация;
  3. нажатие кнопки «Добавить объявление»;
  4. ввод символов в поле «Описание».

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

«Пользователь авторизован на сайте menyaemsya.com и перешёл в корзину».

Actual/expected result (фактический/ожидаемый результат)

Нам предстоит ещё раз указать на суть дефекта и добавить информацию о том, как элемент ПО должен работать корректно.

Пример заполнения данного раздела:

«При внесении информации в поле “Описание” количество вводимых пользователем знаков не лимитируется. Ожидается, что после внесения 350 символов система не будет выводить на экран знаки и предложит пользователю сократить текст».

Attachments (вложения)

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

Priority (приоритет)

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

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

  • P1 High (высокий приоритет);
  • P2 Medium (средний приоритет);
  • P3 Low (низкий приоритет);

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

Severity (серьёзность)

Ошибки имеют и другую характеристику ― степень серьёзности влияния на систему.

  • Blocker — это статус для проблем, которые прерывают работу приложения.
  • Critical — такой баг значительно влияет на работоспособность, но не приводит к блокировке.
  • Major — ошибка, которая не способствует фундаментальным изменениям, но может привести к незначительным искажениям отображения информации или выполнения некоторых функций.
  • Minor — не влияет на работу системы. К этой категории можно отнести ошибки в текстовых блоках или визуальных решениях.
Status (статус)

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

  • New – новый баг;
  • Feedback – требуется обратная связь;
  • Acknowledged – с содержанием документа ознакомились;
  • Accepted – ошибка воспроизвелась и была подтверждена;
  • Assigned – исправление ошибки назначено;
  • Resolved – изменения были внесены;
  • Closed – дефект больше не воспроизводится.

Такими являются основные элементы баг-репорта, с которыми приходится встречаться чаще всего. Но в отчёте могут содержаться и дополнительные поля:

  • Environment/platform – среда, платформа или операционная система;
  • Fix version – этап разработки ПО на момент выявления бага;
  • Assignee – пользователь, которому предстоит утвердить или исправить дефект;
  • Lable – категория ошибки (текст, визуальные элементы и прочее).

Резюмируем

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

  • убедиться в воспроизводимости ошибки;
  • оценить поведение системы на разных платформах (при необходимости);
  • проверить дефект на уникальность в баг-трекинговой системе.

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

Умение составлять подобные репорты является важным для тестировщика навыком, который вы можете развить, ежедневно тренируясь. А освоить азы вам помогут наши замечательные преподаватели, сотрудники международной ИТ-компании, на курсе «Основы тестирования ПО». Присоединяйтесь!

#php #error-handling

#php #обработка ошибок

Вопрос:

У меня есть IPN-файл PayPal, который, похоже, не работает. Это очень долго, поэтому, прежде чем я попытаюсь отладить построчно, я хотел бы знать, есть ли в PHP способ фиксировать любую ошибку, которая мешает правильному выполнению страницы. Затем я мог бы взять это и отправить себе по электронной почте. Это сэкономило бы мне много времени.

Я уже попробовал несколько вещей и знаю, что транзакция обрабатывается PayPal должным образом, и IPN отправляется на мою страницу IPN. Итак, я уверен, что в моем коде что-то перепуталось, но отладить это локально практически невозможно.

Итак, мой вопрос: есть ли способ зафиксировать ошибку, которая препятствует выполнению файла?

Спасибо!

Ответ №1:

RTFPHPM?

(F для «дружественного», конечно;-)

Ответ №2:

Включите ведение журнала ошибок в php.ini — вы можете записать его в файл, в системный журнал, вывести на экран и т. Д.

�����: ���������������� �� ����� ������

8.5. �������� ������

���� �� ���������� �� ����� ���������� ��������� � ����������, ��� ��� �������� �������, �� ��� ��������� ������������� ������ � ��������� ��������� �����. �����������, ��� ���� ��������� ����� �������� �������, ����� ��� ������ ����� ��� �������� � ����� �� �����. ����� �������� ��� �����, ��� �������� ������������ ��������� �������������� ������. ����� ������� ��� �����������:

� ���� ������-������� ��������� ������������ ��������, � ����� ��������� � ������ � ��� �� ����� ������, ��� � ������. ����� ����, ���������� ����������� ������� ��� �����, � ������� ���������������� ����������� ���������. �������� � ������ �������, ����� ������ ��������� ��� ��������� ������� ��������� ���� ������ � ����������� �����, � ������� ����� ������������ ���. ����� �� ���������� ���� ������� ���������, �������� �� �������, ��������� ���������, ���������� ������ ����� � ���������������� ���������� ��������� ���� ������. ���������� ���� ��, ��� �� ���� ������, �� � ����������� � ����� ��� ���������� ����������� ������, ��� ���������� ���� ��������� �������� reconsult ��� ���� ������, ����� �������� ������ ����������� ���������� �������� ������.

� ���� ���� ������-������� �� ��������� ��������� � �������� ��������� ����� ������������� ��������� � ��������� ����� ����������� ������, �� ��� �������� ��������� ������ � ��������� �������� consult �� ���� ����� ����������� ������, ����������� �� ������� ������.

���� ������� ����� ���������, ���� ������� ��������� ����, ��������� �� ������ ��� �������, �������������� ��������� �������� consult �� ���� ������ ����� ���������. ����� ��� ����, ����� ������� � ������ ��� ���������, ���������� ���������� ������� ��������� consult � ����� ���������� �����. ��������, ���� �� ���������� ������� ��������� consult � �����, �����������:

?- [filel,file2,file3].

?- [file4,file5,file�].

�� � ���������� ����� ������� � ������ ��� ����� file1, file2, file3, file4, file5, file6.

������ ��������� � ��������� ������� ����� ���������������, ��� �� ����� ������ � ��������� � ������� ���������� consult(user) ��� reconsult(user). ������ �� ������� ������������ ���� �������� ������� �����. �� ���������������� ����� ����� ������ �����-���� ������ ���������, ������� ��������� ����� ��������, � ��� ���������� ��������� ����� ����������� � ���� �� ��������, ������� ����������� ��� ������� ������� ���������. ����� ����, ��������� � �������� ����� �� �������� ������ ����������� � ���� ����������� �����, �� ������������� ��������� �� ������ ���� � ���������. ����, �� ������������ ��������� ������� ����������� ����� � ��������� � ������� �������� ��������� ��������� ��������.

���� ���������� ��������� ������ ����, ��� ����� ������������ ��������� consultreconsult, ����� ������ ��������� � ��������� � ���������. ���� ����� ������ ����������, ����� � ���� ������ ������������ ��� �� ������ �����������.

?- ������������([�,b,�,d],[�],�).

���

?- consult (user).

������������([�|�],�,[�|D]):- ������������(�,�,D).

������������([],�,�).

���([],[]).

���([�|�],�):- o6p(B,D), ������������(D,[�],�).

/* ���� ������ � ������� ����� ����� */

��

?- ���([a,b,c,d,e],X).

���

?- ������������([�,b,�,d,�], [f],�).

���

?- ������������([],[�,b,-],�).

X = [�,b,�]

��

?- reconsult(user)

������������([�|�],�,[�|D]):- ������������(�,�,D).

/* ���� ������ � ������� ����� ����� */

��

?- o�p([a,b,c,d],X).

���

?- consult (user).

������������([],�,�).

/* ���� ������ � ������� ����� ����� */

��

?- o�p([a,b,c,d,e],X). X = [e,d,c,b,a].

��

� ����������� ������ ������ ��� ��������� ����������� �������� � ����� ����� �������� ����������� ��� ���������� ������������ ���. �������, �� ��� �� ������� ������ �� � ����, � ����� ���������� ������� ��������� � ����� ����� �������� consult. �������, ��� ������ ���������� ������� �����, ����� ����, � �� ������ ������. � ���������, � ������ ����������� ��� ������������ �������� ������ � � ���� ������ , ���� �� ���� ����� ������ ���� . ��� ������ ��������������, ����� ������� �� ����� �������� �� �������, ���������� ������������ ���. �����-�� ������� ����������� ������������, ��� ��� ����������� ������������ ������� (� �������� ������ ��� �����, ��������, ������������� �� ������������ �������� �������). ��� ��� �����, �� ������ �������� ��������� ����������� �����, ��������� ��� ����� �������� reconsult. � ���������, � ����� ����� ����������� �� �������� ������ ��������� ������� (������ []). ������� ��������� ��-�������� �� ��������. � ����� ������� �������� ����������� ��� ������������, ��������� �� ���� �����������, �������� ����� ������������ �� ������ �����������, ������� ��������� ��������. ��� ����������� ��������, ��� �� �������� ������ � ��� �������� ����� ���������, ������ ������� � ��� ���������� ����������� ���� �����������. ��� �������� ����� � ������� ��������� consult. �� ���� ��� ��������� ����������.

� ���������� ����� ��� ���� �����: ��� �������� ��������� � ��������� �������� �� �� �� ����������� �������, �� ������� �� �������� ��� ��������� �������������� ������ ���������. ���������, ��� ���� ���������� ����������� � ����� ������� �������� � ���, ����� ���������� ������ ���� ����������������, ����� � ����� ��������� ������������ � ��� ����� �����. �������, ����������� ��������� ��� ��� �� ��������� � ����� � � ��� ����� ���� � �����-���� ������ ������.

Мне нужно зафиксировать последнюю ошибку в функции «включить» PHP.

Я тестирую функции «Исключения», но, к сожалению, я написал над функцией «include».

Если я напишу после того, как функция «include» не отображает исключение.

Пример 1:

try{
        throw new exception();
        require_once( $this->controller['path'] );
    }
    catch( exception $e )
    {
        print_r( error_get_last() );
    }

Это возвращение:… (Пустота)…

Пример 2:

try{

        require_once( $this->controller['path'] ) OR throw new exception();;
    }
    catch( exception $e )
    {
        print_r( error_get_last() );
    }

Это возвращение: Ошибка анализа: синтаксическая ошибка, неожиданный T_THROW в…

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

Кто-нибудь знает, как это получить?

Ребята! Мне нужно уловить синтаксические ошибки. Привет!

22 дек. 2011, в 06:09

Поделиться

Источник

4 ответа

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

$success = include "foo.php";
if (!$success) {
    // the file could not be included, oh noes!
}

У вас могут быть синтаксические различия, например:

if (!(include "foo.php")) ...

Это приведет к срабатыванию E_NOTICE, если файл не может быть включен, который вы не можете поймать. Но это нормально, так как это поможет вам отладить проблему, и отображение ошибок будет в любом случае отключено в процессе (правильно, правильно?).

or throw new Exception не работает, потому что throw является оператором и не может использоваться там, где ожидается выражение.


Если вы хотите уловить ошибки синтаксиса во включенном файле, используйте php_check_syntax/it successor php -l <file>.

deceze
22 дек. 2011, в 06:33

Поделиться

require_once — это языковая конструкция, а не функция, и вы не можете делать короткое замыкание с ней.

Чтобы проверить, существует ли файл перед его включением, вы можете использовать is_file(). Если вы хотите проверить, читается ли файл, вы можете использовать is_readable().

Вы также можете использовать include, который выдает E_WARNING, если файл не найден, а не E_COMPILE_ERROR.

alex
22 дек. 2011, в 06:28

Поделиться

i согласен с alex, попробуйте cath error с проверкой file_exists(), затем используйте Exception

if(file_exists($this->controller['path'])){
    try{
       require_once( $this->controller['path'] );
    }catch(Exception $e){
          // throw error
    }
}

или используйте is_readable()

if(is_readable($this->controller['path'])){
    try{
       require_once( $this->controller['path'] );
    }catch(Exception $e){
          // throw error
    }
} 

Khairu Aqsara
22 дек. 2011, в 06:25

Поделиться

Большинство встроенных функций PHP вызывают ошибки, а не бросают исключения. Чтобы преобразовать ошибки PHP в исключения, вы можете настроить собственный обработчик ошибок:

function exceptions_error_handler($severity, $message, $filename, $lineno) { 
    throw new ErrorException($message, 0, $severity, $filename, $lineno); 
}
set_error_handler('exceptions_error_handler');

С помощью этого кода вы сможете уловить все нефатальные ошибки в качестве исключений. Обратите внимание, что функции require_* вызывают фатальную ошибку, поэтому вам придется использовать include.

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

Your Common Sense
22 дек. 2011, в 07:06

Поделиться

Ещё вопросы

  • 1Поиск данных Firebase без одного дочернего узла
  • 0LightOpenID использует только первый возвращенный AuthURL, несмотря на запуск отдельных сессий PHP
  • 0Откройте div и закройте других
  • 1Как отключить завершение кода в отладочной консоли в pycharm?
  • 1gTTS Python Script в фоновом режиме получает tcgetattr (): неподходящий ioctl для устройства
  • 0Переменная, выделенная из стека C ++, не уничтожена (/ уничтожена?)
  • 0Нарисуйте 2 куба в OpenGL, используя GLM
  • 1Несоответствие типов шаблонов при обновлении данных плитки
  • 0Как настроить все модули отключить только модуль викторины включен в Moodle?
  • 0Лучший способ превратить PHP-массив в Javascript
  • 0FullText InnoDB Поиск без ответа
  • 1Не удалось получить политику конфигурации приложений из Microsoft Intune в приложении для Android
  • 1Java, сравните маленький 2D массив с каждой возможной итерацией в большем 2D массиве
  • 0Как выбрать первую из этих кнопок?
  • 1Обработка событий для переключения видимости родственного элемента SVG?
  • 1Ссылка «реакции-роутер-дом» не работает?
  • 0Обновить таблицу A с информацией о B со значением в качестве имени столбца
  • 1Получить значение из web.config в файл XSLT
  • 1Как получить размер итератора без зацикливания?
  • 0setTimout при загрузке анимации после нажатия кнопки отправить
  • 1Почему начальное значение «я» всегда 49
  • 0Rightsidebar начинается с нижней части содержимого в div содержимого
  • 0Вызовите функцию jquery, используя атрибут onclick, который передаст функции this
  • 0Сова Карусель не работает в angularjs частичный вид
  • 1Уведомления не получаются на устройство, но получают успех на FCM, в чем проблема?
  • 0Пример работы с редактором текстового редактора tinymce не запущен
  • 0Изменить текст в модальном окне в зависимости от нажатия кнопки
  • 1Как вы компилируете приложение фляги с Cython?
  • 0Как передать значение из DropDownListFor в угловую функцию?
  • 0невозможно загрузить динамическую библиотеку
  • 0Получить все результаты из первой таблицы в соединении MySQL
  • 1Сброс порядковых номеров акцептора в качестве инициатора без возможности использования onLogon
  • 0Rails Active Record Query Total отправляется в будний день
  • 0Можете ли вы создать ссылку, которая использует текущий URL-адрес динамически, используя Javascript?
  • 1Android не воспроизводит звуковой эффект, когда включен режим «Не беспокоить»
  • 1Первая сборка приложения Node.JS в TFS 2015 Update2
  • 1Как исправить эту лямбда-функцию AWS для Google reCaptcha?
  • 1Как отобразить массив в массиве на Highcharts? [JS]
  • 0Методы цепочки с задержками в JavaScript
  • 1Метеор выполняет функции синхронно
  • 0Присоединиться по user_id в Symfony
  • 0Как передать экземпляры класса / структуры в качестве аргументов для обратных вызовов, используя boost :: bind?
  • 0Передача пользовательских функций в объекты jquery
  • 0Что означает max_user_connections?
  • 0Как показать динамический контент на Ionic Custom POPUP
  • 0Как получить экземпляр выбранного в данный момент li с помощью JQuery
  • 1Чтение значения файлов cookie в веб-клиенте с поддержкой файлов cookie
  • 1В фляге, как я могу изменить HTML с кодом в Python?
  • 1Строка заменяет логику
  • 1Интернет перед WCF Security лучший вариант

Сообщество Overcoder

Понравилась статья? Поделить с друзьями:
  • Как заставить кадастрового инженера исправить свою ошибку
  • Как заставить ворд исправлять ошибки
  • Как изменить страницу ошибки 404
  • Как изменить ошибку 404 на сайте
  • Как изменить карточку товара на озон при ошибке