Что такое корнер кейс
corner case
Смотреть что такое «corner case» в других словарях:
Corner case — A corner case (or pathological case) is a problem or situation that occurs only outside of normal operating parameters – specifically one that manifests itself when multiple environmental variables or conditions are simultaneously at extreme… … Wikipedia
Corner Gas — The Corner Gas logo Format Comedy Created by Brent Butt Starring Brent Butt … Wikipedia
Corner Boys — The Wire episode Episode no. Season 4 Episode 8 … Wikipedia
Case Vacanze Caputo — (Montelepre,Италия) Категория отеля: Адрес: Via Madonna Del Carmine 43, 90040 Montelepre … Каталог отелей
Corner solution — A corner solution is a special solution to an agent s maximization problem in which the quantity of one of the arguments in the maximized function is zero. The more usual solution will lie in the non zero interior at the point of tangency between … Wikipedia
Corner transfer matrix — In statistical mechanics, the corner transfer matrix describes the effect of adding a quadrant to a lattice. Introduced by Rodney Baxter in 1968 as an extension of the Kramers Wannier row to row transfer matrix, it provides a powerful method of… … Wikipedia
Corner detection — Feature detection Output of a typical corner detection algorithm … Wikipedia
Corner kick — A picture of the exact moment the blue white team s corner kick is taken. A corner kick is a method of restarting play in a game of association football. It was first devised in Sheffield under the Sheffield Rules 1867. It was adopted by the… … Wikipedia
Corner — For other uses, see Corner (disambiguation). A corner is the place where two lines meet at an angle, and a concave corner of intersecting walls is generally thought to be the least beneficial position to be in a life or death situation. From this … Wikipedia
Corner — Recorded in the spellings of Corner and Cornner, this interesting name is English Medieval but from two quite distinct French origins. The first is from the word cornier meaning an angle or corner, and as such was introduced into England after… … Surnames reference
Case’s Corner Historic District — Infobox nrhp | name =Case s Corner Historic District nrhp type = hd caption = location= Weston, Massachusetts lat degrees = 42 lat minutes = 21 lat seconds = 29 lat direction = N long degrees = 71 long minutes = 17 long seconds = 55 long… … Wikipedia
corner case
1 corner case
См. также в других словарях:
Corner case — A corner case (or pathological case) is a problem or situation that occurs only outside of normal operating parameters – specifically one that manifests itself when multiple environmental variables or conditions are simultaneously at extreme… … Wikipedia
Corner Gas — The Corner Gas logo Format Comedy Created by Brent Butt Starring Brent Butt … Wikipedia
Corner Boys — The Wire episode Episode no. Season 4 Episode 8 … Wikipedia
Case Vacanze Caputo — (Montelepre,Италия) Категория отеля: Адрес: Via Madonna Del Carmine 43, 90040 Montelepre … Каталог отелей
Corner solution — A corner solution is a special solution to an agent s maximization problem in which the quantity of one of the arguments in the maximized function is zero. The more usual solution will lie in the non zero interior at the point of tangency between … Wikipedia
Corner transfer matrix — In statistical mechanics, the corner transfer matrix describes the effect of adding a quadrant to a lattice. Introduced by Rodney Baxter in 1968 as an extension of the Kramers Wannier row to row transfer matrix, it provides a powerful method of… … Wikipedia
Corner detection — Feature detection Output of a typical corner detection algorithm … Wikipedia
Corner kick — A picture of the exact moment the blue white team s corner kick is taken. A corner kick is a method of restarting play in a game of association football. It was first devised in Sheffield under the Sheffield Rules 1867. It was adopted by the… … Wikipedia
Corner — For other uses, see Corner (disambiguation). A corner is the place where two lines meet at an angle, and a concave corner of intersecting walls is generally thought to be the least beneficial position to be in a life or death situation. From this … Wikipedia
Corner — Recorded in the spellings of Corner and Cornner, this interesting name is English Medieval but from two quite distinct French origins. The first is from the word cornier meaning an angle or corner, and as such was introduced into England after… … Surnames reference
Case’s Corner Historic District — Infobox nrhp | name =Case s Corner Historic District nrhp type = hd caption = location= Weston, Massachusetts lat degrees = 42 lat minutes = 21 lat seconds = 29 lat direction = N long degrees = 71 long minutes = 17 long seconds = 55 long… … Wikipedia
Добавить описание тестирования граничных случаев (corner cases) #51
Comments
daynin commented Feb 9, 2017
Но не сказано какие именно варианты нужно тестировать. А именно, для любого кода целесообразно протестировать как минимум следующие кейсы:
Плюс следует отметить, что если вы не видели, как тест падает, то такому тесту доверять нельзя, так как легко пойти по positive way и пропустить ошибку в коде
The text was updated successfully, but these errors were encountered:
dzhiriki commented Feb 9, 2017
Про то, что нужно проверять, что тест не проходит написано в секции про TDD. Но да, стоит на это больше внимания акцентировать.
А что ты тут подразумеваешь под ожидаемым некорректным поведением? Если поведение ожидаемо, то оно заведомо корректное. Или я как-то не так тебя понял?
daynin commented Feb 9, 2017
@dzhiriki да, возможно, я не совсем точно выразился
А что ты тут подразумеваешь под ожидаемым некорректным поведением?
Я имел в виду, что нужно тестировать не только positive way. Например, для sum это будет проверка
То есть мы должны проверить не только кейсы, которые мы как разработчики и так предполагаем увидеть, но и кейсы, которые заведомо неверны.
dzhiriki commented Feb 9, 2017
Понял. Да, стоит подобнее раскрыть этот момент. А то нюансов тут достаточно:
daynin commented Feb 9, 2017
Если мы тестируем, что 10 и 20 возвращает 30, то нет особого смысла делать тест на не равно 42.
Есть отличное видео, объясняющее, почему важно тестировать negative cases. Люди, к сожалению, склонны следовать только positive way и тесты могут быть false positive. Извини, что так много англицизмов, но я, если честно, не знаю, как это правильно и емко описать по-русски, чтобы это не звучало странно 🙂
dzhiriki commented Feb 9, 2017
Пункты, что я описал выше были адресованы не тебе, а просто для истории, чтобы потом не вспоминать \ придумывать, что хотели описать. Так-то я понял о чем речь 🙂
Оффтоп: Видео я видел. В «ГП и МРМ» была такая же игра, к слову 🙂
daynin commented Jan 18, 2018
В #65 значительно доработал раздел «Testing», этот issue уже не актуален
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Тестирование глазами разработчика: инструменты, мифы, ситуации
Евгений Сафронов, Senior Developer, DataArt
«Тестирование можно использовать для того, чтобы доказать наличие ошибок в программе, и никогда — для того чтобы доказать их отсутствие!»
Эдсгер Дейкстра
Тестирование — это прикладная, стандартизированная, инженерная практика, которая применима в большинстве отраслей человеческой жизни. Тестирование, как философия, метрика или практика, существует намного дольше, чем программирование. К примеру, мы выковали меч. Чтобы проверить достаточно ли острым он получился, его испытывают. В некоторые эпохи даже на живом человеке, скажем, рабе.
Тестирование — это проверка работоспособности программы, предмета или любой промышленной разработки. Как и в любом деле, здесь есть свои тонкости и своя философия. Она, наверное, ближе тестировщикам, которые на произведенные нами вещи смотрят деструктивно — они с самого начала думают о том, как сломать предложенный разработчиками продукт. Это не очень типично для пользователей, которые более предсказуемы и обычно находят ошибки, случайно пытаясь сделать с нашей программой что-то нетипичное. У разработчиков подход к программам в принципе другой, но мы должны помнить: тестировщики должны ломать то, что мы создали — это их хлеб.
Почему тестировать программы так важно?
Разработчики не мыслят через тестирование, мы мыслим созидательно — и это может быть источником проблем. Когда нас просят написать программу, мы прежде всего думаем над концептами, структурами данных, их описанием и взаимодействием. В результате мы представляем решение — готовое, пусть и переполненное багами. Обычно мы слабо представляем, что будет, если изменятся входные данные, если пользователь будет в большом количестве совершать нетипичные операции.
При этом практика показывает, самые дорогостоящие ошибки случаются в результате небольших изменений. Потому что, если вы плохо написали кусок кода, более опытный коллега попросит вас его переделать. Обладая опытом, вы сами будете замечать неудачные фрагменты практически сразу. Но когда ошибки минимальны — отдельный символ, точка, знак финансовой операции, ошибка округления — найти их очень сложно, причем на любом этапе.
Рис. 1. Форма авторизации и количество вариантов ее заполнения.
Давайте посмотрим, почему возникает такая сложность в тестировании. На рисунке мы видим простую форму из трех полей. В первых двух полях можно ввести от 1 до 255 букв, в третьем от 1 до 20 символов. Можно также оставить строки пустыми. Внизу мы видим число возможных комбинаций, заметно превышающее количество элементарных частиц во вселенной. Я думаю, это убедительное доказательство того, что проверить все возможные кейсы нереально. Да и пытаться это сделать, наверное, нецелесообразно.
Типы ошибок в проектах
Рис. 2. Схема распределения ошибок по типам, согласно данным книги Стива Макконнелла «Совершенный код».
Примерно 25% общего объема приходится на структурные ошибки. Они возникают еще на этапе проектирования, когда вы создаете структуры данных и пишете реализации манипуляций с ними, то есть создаете некий «клей», скрепляющий эти структуры. Это огромный пласт фундаментальных ошибок.
Далее идут ошибки данных, связанные с реализацией функциональности и т. д. Интересно, что архитектура находится на последнем месте. Это можно объяснить тем, что, создав неправильную архитектуру, очень сложно в принципе выпустить конечный продукт.
Рис. 3. Распределение ошибок по стадиям разработки. Схема Стива Макконнелла.
На этап конструирования и проектирования приходится основной пласт ошибок и дефектов. Здесь работает известное правило Парето: 80 % дефектов локализованы лишь в 20 % вашего кода. Как правило, это какие-то корнер-кейсы. Если вы пишете операции с математической, например, с финансовой логикой, очень много ошибок может заключаться в пределах пограничных значений, при округлении чисел и т. п. Большинство ваших кейсов будут работать, но основная часть дефектов будет локализована в небольшом участке кода.
Вне зависимости от того, применяете ли вы ручное или юнит-тестирование, нельзя утверждать, что покрыв тестами 50 % кода, вам удалось предотвратить 50 % возможных дефектов. Если вы написали 100 юнит-тестов нельзя сказать, что итоговое качество вашего продукта повысилось, например, вдвое. Потому что разработчик, который не мыслит через призму тестирования, проверяет самые легкие кейсы. Нужные формы заполняются стандартными именем, фамилией и логином — разработчик идет дальше. Он с большой долей вероятности не станет проверять случаи, когда одно из полей остается пустым, или когда в него действительно вбили имя длиной в 255 знаков. Не будет он экспериментировать с нестандартными символами, комбинациями строчных и заглавных букв.
Тестировать продукт могут все: разработчик, тестировщик, менеджер, заказчик. Иногда в небольших проектах роль тестировщика может выполнять менеджер или разработчик. Но все же все четыре роли здесь очень важны — каждый участник процессе смотрит на объект со своей точки зрения. Разработчик — через призму того, как работает код. У него с самого начала есть большая часть информации о том, как сломать интерфейс. Для тестировщика найти ошибки и сломать продукт — прямая задача. Заказчик смотрит на тесты совершенно иначе: ему интересно, как написать меньше тестов и заплатить меньше денег, все равно получив в итоге качественный продукт. Но самая интересная роль у менеджера, который обычно может опираться на случаи из собственной практики. Впрочем, как правило, он служит мостом между разработчиками, тестировщиками и заказчиком, а его основная задача сводится к презентации продукта. Но именно менеджер отвечает за качество продукта на выходе.
Тестирование черного и белого ящиков
Классификация тестирования в виде анализа белого, серого и черного ящиков, интересна нам тем, что разработчик смотрит на собственный код как на белый ящик. А тестировщик и заказчик рассматривают программу как черный ящик — они до конца не понимают, как именно работает программа, знают только, какие фичи важны и должны работать обязательно.
Баг на сайте интернет-магазина, из-за которого какой-то товар не попадает в корзину, для разработчика — минорная проблема. Достаточно что-то закоммитить и раскоммитить, поменять переменные в одном месте — и все отлично заработает. Для тестировщика и тем более заказчика такой баг оказывается критическим, поскольку не позволяет клиенту купить нужный товар.
Но самый интересный ящик — серый. С ним работают те, кого я называю умными тестировщиамки, которые глубоко вникают в код и то, как работает продукт. Их интересует, как происходит деплой и коммуникация с базами данных.
Какие тесты пишут разработчики?
Рис. 4. Пирамида модульного тестирования.
Основа пирамиды — юнит-тестирование — желательно, чтобы юнит-тестов в проекте было много. Далее следуют интеграционное тестирование наших модулей, Acceptance Tests и непосредственное UI-тестирование конкретных фич.
F.I.R.S.T
F.I.R.S.T. — методология описания требованиий, которым должны отвечать тесты. Прежде всего, модульные, но в принципе эти характеристики можно экстраполировать и на автоматические тесты. Ее создатель — известный дядюшка Боб — автор многих практик программирования.
Рис. 5. Схема TDD-процесса.
Две базовых методологии юнит-тестирования — похожие концепты TDD и BDD. BDD-подход основывается на TDD и призван устранить небольшие недостатки, которые присутствуют в TDD. Синтаксис BDD-тестов в большей степени ориентирован на бизнес и понятен заказчику и вообще технически менее подкованному человеку. TDD — о том, как делать вещи правильно. BDD — о том, как делать правильные вещи.
Как выглядит TDD-процесс?
Первым делом вы пишете тест для кода, который еще не написан. Соответственно, видите, что он не работает. Чтобы он заработал, код ещё нужно написать. Потом вы все-таки пишете код, запускаете тест и убеждаетесь в том, что тест работает. Далее вы модифицируете свой тест (уточняете требования, добавлете проверку граничных условий и т. п.). После этого ваш тест перестает работать, и вы снова приходите к необходимости модифицировать ваш код. Этот процесс зациклен до того момента, пока ваш тест не будет совершенно четко отвечать конечным критериям и соответствовать задачам, которые перед вами стоят. Предположим, если вы решаете квадратное уравнение, ваша задача — написать функцию, которая находит корни квадратного уравнения. Предположим, вы написали тест, и он хорошо работает на базе действительных чисел. Но если пользователь захочет найти комплексное решение, то ничего не получится, тест завалится и потребует модификации. Поэтому эта схема должна быть в крови у разработчиков: нужно действовать по ней, пока ваша фича не будет соответствовать всем требованиям.
Как выглядит TDD?
Пример написан на JavaScript, но думаю, в синтаксическом плане он будет примерно также выглядеть для PHP или Java. Все достаточно очевидно. Открыв тест, можно легко сказать, какие моменты протестированы не были. Можно легко и быстро что-то добавить. И таким образом проверить, корректно ли работает ли ваша функция.
BDD очень похож на TDD, но отличается тем, что формулировки в описании немного лучше адаптированы для людей, менее плотно связанных с разработкой: менеджеров или бизнес-аналитиков.
Особенности модульного тестирования
Рис. 6. Инструменты юнит-тестирования.
QUnit — библиотека от разработчиков jQuery, позволяющая писать юнит-тесты в TDD-стиле, с механизмом assert. Вы пишете qunit.test, название теста, и что вы хотите протестировать.Затем запускаете его в отдельном файле, который должен видеть ваш код, и можете убедиться в том, что код работает.
Mocha — фреймворк для тестирования, позволяющий писать тесты в TDD и BDD-формате. Как правило, он используется совместно с другими инструментами для того, чтобы полностью реализовать TDD-подход в работе. То есть он позволяет запускать и описывать тесты в нужном формате, а к примеру за обработку проверок утверждений (asserts) отвечает другая библиотека (чаще всего Chai).
Sinon— инструмент для создания Mocks, stubs и spies, который очень часто используется в современных успешных проектах. Он содержит набор функций и модулей, которые здорово помогают и решают большое количество типичных проблем, которые возникают у разработчика во время создания юнит-тестов.
Jasmine — популярный BDD-библиотека, которая фактически стала стандартом в экосистеме самого распространенного Javascript-фреймворка Angular.
Как научиться правильно ставить задачи разработчикам и ускорить процессы в 2 раза
Одна из основных проблем в ИТ проектах — взаимопонимание двух миров: бизнеса и разработки. Одни хотят быстро и красиво, другие хотят получить исчерпывающее описание хотелки. Переговоры занимают много времени, но еще больше — исправление ошибок. Как эффективно выстроить процесс, рассказывает зам технического директора музыкального сервиса «Звук» Кирилл Ларин.
Так как разработка (+тестирование) — самое дорогое звено в создании ИТ-решения, то необходимо экономить время разработчика любым способом.
Если задача поступает в разработку с неполным описанием, то есть в ней нет всех Use cases и Corner cases, то разработчик тратит массу времени на выяснение нюансов. Или не хочет вступать в полемику и делает все, опираясь на свою картину мира, по принципу “художник так видит”.
Если в компании ограничены ресурсы, нет системного аналитика, либо он не покрывает весь бэклог, то необходимо найти другой выход, который позволит эффективно решить проблему.
Одно из решений — выработка стандарта описания задач. Лучше больше продумывать их до реализации, чем додумывать в процессе исполнения. Здесь необходимо найти баланс между заказчиком и разработкой.
Основа баланса — смещение большей части работы на постановщика/представителя бизнеса. Чем лучше он проработает фичу, тем вернее будет результат на выходе.
Однако часто бизнес не знает, что требуется разработчику, чтобы сделать задачу верно и в срок. Как найти общий язык?
Сквозь слёзы и пот мы в Звуке сформировали стандарт, который позволяет получить 90% информации, необходимой для решения любой it-задачи.
Главная цель — реализовать именно то, что хотел заказчик. Так как любую информацию можно трактовать по-разному, то следует использовать утвержденный формат постановки задачи. Такой формат, который уменьшит вероятность разночтений.
Для этого заказчику необходимо описать следующие аспекты задачи:
Рассмотрим подробно каждый аспект.
Для точного определения, что требуется сделать в постановке задачи используется принцип SMART:
Какую проблему заказчик пытается решить?
Какие метрики будут оцениваться, какие показатели будут достигнуты в ходе решения задачи?
Какие технологические требования и ограничения предъявляет заказчик к функционалу?
Какая функциональность ожидается?
Несмотря на то, что US в огромной степени играют роль, ранее принадлежавшую спецификациям требований, сценариям использования и т.п., они все же ощутимо отличаются рядом тонких, но критических нюансов:
Текст самой US должен объяснять роль/действия пользователя в системе, его потребность и выгоду, которые пользователь получит после того как история случится.
US можно оценить по критериям INVEST:
Какой сценарий необходимо пройти, чтобы достичь цель?
Что UC включают в себя:
Что UC не включают в себя:
В зависимости от глубины и сложности того, что вы хотите или должны достичь, UC описывают комбинацию следующих элементов:
Для написания UC используются следующие шаги:
Чтобы описать CC нужно определить, какие факторы влияют на фичу и описать результат/сценарий при всевозможных комбинациях этих факторов.
Для этого целесообразно использовать таблицу, в которой на пересечении факторов будет описан результат/сценарий.
С теорией всё понятно, но как дело обстоит на практике? Разберем упрощенное описание задачи на примере сохранения настроек приложения.
Сохранять настройки приложения
В ходе опроса было выявлено, что пользователь ожидает, что приложение запоминает его последнее состояние (настройки). По аналогии с другими сервисами.
Использовать распространенный UX для реализации решения
Сохранять настройки приложения на серверной стороне в связке с данными пользователя
Как пользователь, я хочу, чтобы приложение запоминало мои настройки, чтобы мне не приходилось указывать их каждый раз при авторизации
— Пользователь открывает приложение.
— Пользователь входит в учетную запись в приложении.
— Пользователь устанавливает настройки приложения.
— Система сохраняет настройки.
— Пользователь выходит из учетной записи в приложении.
— Пользователь входит в учетную запись в приложении (+ на другом устройстве).
— Система передает сохраненные настройки в приложение.
— Приложение отображает сохраненные настройки пользователя.
Обеспечить обратную совместимость со старыми клиентами.
Первое. Объяснить команде боль. Как известно, если вы указываете причину внедрения, конверсия увеличивается.
Второе. Показать пример, поставить некоторое количество задач для начала по стандарту, показать заказчикам, как это надо делать, как оно работает.
Третье. При внедрении обязательно собрать обратную связь по стандарту. Ответить на все вопросы, внести корректировки. Тогда будет коллективный труд, порог вхождения ниже.
Четвертое. Воспринимать все нововведения, как эксперимент. Если он удался (были достигнуты цели), он приживется сам собой, так как мотивация у людей будет осознанной. Если не удался, можно вернуться к прежнему состоянию.
Пятое. Закрепить нововведения фактами в виде цифр — сравните с периодом до внедрения. Производительность увеличилась на столько-то, количество ошибок упало на столько-то.
Каждая система, находящаяся в покое, противиться изменению. При внедрении подобных стандартов/изменении процессов вы столкнетесь с сопротивлением. Но игра стоит свеч. Лучший аргумент — это метрики. Если они пошли вверх, значит, вы на верном пути.
В «Звуке» после внедрения стандарта скорость и качество работы увеличилось в 2 раза. Мы получили положительные отзывы от всех участников команды и решили основную проблему.