bug testing web-applications

Мы можем предположить, что во время тестирования программного обеспечения, что пользователь не'т проанализировать такие глупые действия на программное обеспечение?

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

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

Так какая польза от включения всех тех тестов, которые может/не может привести к ошибкам, когда вероятность появления подобных проблем в производстве намного меньше?

Примечание: приведенный выше пример-это только пример; такие вопросы могут возникнуть в любой функции/модуля.

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

70
9
9 ответов

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

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

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

Никогда Ничего Не Предполагай

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

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

Что касается тестирования, это полезно для защиты от случайных входов, однако полностью выбрав тест входов в случайном порядке (т. е. без особого внимания к любом случае использовать или крайние случаи) близка к бесполезной. Целью тестирования является проверка решения на соответствие требованиям и ожиданиям работодателя/клиентов/пользователей; это означает, что вы должны нацелены на все пограничные случаи и граничные условия, а также любые 'дегенерат' дела, которые Дон't установите в с пользователя'ы ожидается рабочего процесса.

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

Кроме того, вы можете быть написание на заказ программное обеспечение, которое имеет крайне ограниченный аудиторией 'эксперт' пользователей где там's никакой коммерческой выгоды, чтобы тратить время на исправление ошибок, так как эти пользователи способны делать свою работу с неисправного программного обеспечения (например, диагностический инструмент, используемый внутренней его команда вовсе'т предоставления каких-либо доходов, поэтому если она падает иногда тогда вряд ли кто-то хочет платить за время, необходимое, чтобы это исправить - они'Лл просто сказать его команда жить, а не с ошибками).

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

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

Есть несколько факторов, чтобы принять во внимание. Чтобы проиллюстрировать эти моменты, я'будете использовать пример поля, где пользователь должен ввести процент в рамках квот, определенных для конкретной задачи с точки зрения того, сколько дискового пространства задачи может использовать. 0% означает, что задача не'т быть в состоянии, чтобы написать что-нибудь на диск; 100% означает, что задача может заполнить все дисковое пространство. Значения между ними означает, что они означают. Как разработчик, вы'повторно, вероятно, считая, что допустимые значения [0, 1, 2, 3, ⋯ 99, 100], а все остальное-это глупо. Позвольте's см. Почему пользователи по-прежнему могли попасть те “глупые” ценности.

Опечатки

%^ Пользователь ввел значение 56, но по ошибке нажал <и>сдвиг</роз> при введении их (например, потому что на французской клавиатуре, нужно нажать <и>сдвиг</роз> для ввода цифр, и пользователь постоянно переключаясь между французской клавиатурой и QWERTY). Таким же образом, вы можете получить номер, что-то после или до него, или между: 56q Здесь пользователь был, наверное, войти в цифры, затем Tab для перемещения к следующему полю. Вместо нажатия <и>&ампер;усилитель; nbsp; ⇆ &усилителя;и nbsp;</роз> пользователь нажал клавишу соседа.

Недоразумений и неверных толкований

Пустой ввод-это, наверное, самый обычный. Пользователь представлял себе, что поле было необязательным, или ничего'т знаю, что сказать в этой области. 56.5 Пользователь считает, что значения с плавающей точкой приемлемо. Либо пользователь является неправильным, и приложения должны вежливо объяснить, почему принимаются только целые значения, или первоначальные требования были не правы, и имеет смысл, чтобы позволить пользователям вводить значения с плавающей точкой. "нет" Непонятое пользователя, когда его спросили, для пространства задача может занять, приложения ожидается число. Это может указывать на плохой пользовательский интерфейс. Например, у пользователя“, сколько дискового пространства задача взять?” приглашает к такого рода входной сигнал, в то время как поле со знаком процента следующим будет получать меньше, что-то вроде входа, потому что “нет %” не'т имеет особого смысла. 150 Пользователь недопонимает, что доля средств в этом случае. Может пользователь хотел сказать, что задача может иметь 150% от текущего используемого пространства, так что если на диске 2 ТБ, используется 100 ГБ, эта задача может использовать 150 ГБ. Опять же, лучший пользовательский интерфейс может помочь. Например, вместо того, голое поле ввода со знаком процента, которые добавляются к нему, можно было бы этого:

[____] % of disk space (2 TB)
Когда пользователь начинает печатать, он хотел изменить текст на лету, чтобы стать такой:
[5___] % of disk space (102.4 GB of 2 TB)

Представления

Больших чисел или чисел с плавающей запятой может быть представлено по-разному. Например, число 1234.56 может быть записано так: 1,234.56. В зависимости от культуры, текстовое представление такое же количество будет отличаться. По-французски, то же самое число будет записано так: 1 234,56. Видите, запятая, когда вы не'т ждать, и пространство. Всегда ожидал конкретный формат, используя конкретный язык до добра не доведет рано или поздно, так как пользователи из разных стран могут иметь разные привычки написания чисел, дат и времени и т. д.

Люди против компьютеров

Двадцать четыре Обычные люди Дон'т думают так же, как компьютеры. “Двадцать четыре” является фактическое количество, независимо от того, что ПК скажет вам. Хотя (1) Большинство систем не'Т-образная рукоятка на все это типа входного сигнала и (2) почти каждый пользователь не'т представьте себе, входя в число, записанное в полном буквами, это не'т имею в виду, что такой вклад-это глупо. В о Face 3, Алан Купер приходит к выводу, что не обрабатывает такие данные свидетельствует о неспособности компьютеры адаптироваться к людям, а в идеале, интерфейс должен уметь правильно обрабатывать эти данные. Единственное, что я должен добавить в Алан Купер's Книга заключается в том, что во многих случаях цифры пишутся в цифрах по ошибке. Тот факт, что компьютеры ожидают, что их пользователи делают ошибки (и выиграл'т терпеть пользователь, который правильно пишет) - это раздражает.

Юникод

5𝟨 Unicode резервирует свои сюрпризы: герои которой мог выглядеть так же, не то же самое. Не убедил? Копипаст в "5𝟨 и" === "от 56 и" в инструменты разработчика в браузере, и нажмите <и>введите</роз>. Потому, что эти строки не равны, что символ Unicode𝟨не совпадает с символом6`. Это позволит создать ситуацию, когда недовольный клиент будет звонить, говорите, что ваше приложение не работает, предоставив скриншот вход, который выглядит нормально, и ваше приложение, утверждая, что вход является недействительным. Зачем кому-то вводить символ Unicode, который выглядит как цифра, спросите вы? А я бы'т ожидать, что пользователь, введя один ненамеренно, копипаст из другого источника может привести это, и у меня был случай, когда пользователь на самом деле сделал такое копировать-вставить в строку, которая содержит символы Unicode, которые не'т появляются на экране.

Заключение

Те случаи вы получаете на начальное поле ввода номера. Я позволю себе представить, что вы можете иметь для обработки для более сложных форм, например, дату или адрес. Мой ответ ориентирован на то, что вы назвали “глупым” вход. Тестирование-это не проверка счастливого пути; его's также о проверке, что вы приложение не'т сломать, когда злоумышленник намеренно вводя странные вещи, пытаясь разорвать его. Это означает, что, когда вы'повторно просить за процент, вы также должны проверить, что происходит, когда пользователь реагирует со строкой, содержащей 1 000 000 символов или отрицательное число, или Бобби стол.

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

Существует два вида испытаний, которые должны проводиться по каждой заявке вы пишите, и все они имеют разные цели. Тестирование вы делаете на свой собственный приложение положительного тестирования; ее цель-подтвердить, что программа работает. Тестирование как тестеры, кроме того, по вашему заявлению составляет негативное тестирование; ее цель-подтвердить, что ваша программа не работает. Зачем вам это надо? Потому что вы'вновь не лучшим человеком, чтобы проверить свое собственное программное обеспечение. Ведь ты писал, что, очевидно, уже работает, так?

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

Также обратите внимание, что конечный пользователь-это не только обеспечение ввода в программу. Каждый класс, который вы пишете имеет свой API и свои собственные ограничения на то, что считается допустимым значением, поэтому надежная проверка (т. е. "по договорам код-то") - это важно для ваших классов. Идея в том, чтобы укрепить свое программное обеспечение, так что неожиданное поведение является редким или несуществующим в максимально возможной степени.

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

Обычно это 'случайных' ценности не являются случайными. Вы пытаетесь захватить пограничные случаи, в "неизвестный неизвестный и".

Скажем, например, символ # приведет к краху приложения. Вы Don'т знать этого заранее, и было бы невозможно написать тестовые случаи для всех возможных входных данных. Но мы можем написать тест на в `"¬!" по£$%^&*()_+-=[]{};'#:@~,./<>?|\&и" и увидеть, если она сломается

Однажды я написал программу, которой я живу-протестированы в лаборатории с 60 студентами. Я стоял за 60 компьютерных экранов и увидели их использовать. Количество нелепых вещах, что они делали, волосы дыбом. Я был весь в поту, наблюдая их на "творчество" и. Они сделали гораздо больше, чем любой один человек может фантазировать в течение всей жизни. Конечно, один из них нарушил его.

После этого я следую подход: если ты такой "очень специфическая польза случае" не делать, то показать ошибку

Если у меня есть несколько вариантов использования, я строго их определить и цепь выше.

То, что вы'вновь описывал Fuzzing или пуха тестирование: бросить случайный и неверный вход в систему и посмотреть, что происходит. Вы Don'т сделать это, потому что вас ожидает пользователя, чтобы сделать это. Вы это делаете, чтобы разоблачить ваши собственные предположения и предубеждения для того, чтобы подчеркнуть края системы, чтобы увидеть, что происходит.

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

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

Фаззинг нет таких предубеждений по поводу ввода. Это будет жестоко упражнение вашей системе с любой возможной комбинации "не действует" и вход. Юникод, ASCII, большие, маленькие, и много, очень много ошибок. Ваша система должна корректно реагировать на все из них. Он никогда не должен разбиться. Пользователь всегда должен получать какие-то разумные сообщения о том, что пошло не так и как это исправить. Это's не мусор / мусор, это'ы мусора в / ошибка.

В то время как кто-то может уволить в результате взрывов, потому что "не реальный пользователь будет делать, что", что не попадает в смысл учений. Фаззинг-это дешевый способ устранить ваши предубеждения о возможных входов. Это'ы дешево бросить все странные вещи, пользователи будут стараться делать по вашей системе. Как инженер, ваша задача обеспечить вашей системе не корректно.


Кроме того, метод Монте-Карло "на вход" и это'Т просто о пользователях. Это может представлять в следствии запрос API, чтобы 3-я сторона, что если начинает посылать перепутались результаты? Как ваша интернет-система с этим? Правильная система должна оповещать администратора о том, что компонент пропал. Ненадлежащее система будет спокойно отказаться от плохой запрос, или, что еще хуже, примите это как хорошие данные.

Наконец, некоторые пользователи являются вредоносными. Если вы Don'т тест пушком вашей системы, кто-то другой. Они будут зондировать краев вашей системы на типичные ошибки и постараться их использовать дыры в безопасности. Тестирование может сымитировать этот, в определенной степени, и вы можете справиться с любой возможной бреши в системе безопасности обнаружены, прежде чем они становятся проблемой.

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

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

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

Будь моя воля, я'd имеют вернул программного обеспечения и сочли непригодным. Разница между слабым и сильным программным продуктом является уровень тестирования он был подвергнут.

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

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

так что толку от включения всех тех тестов, которые может/не может привести к ошибкам, когда вероятность появления подобных проблем в производстве меньше?

Когда вы стресс тестирование программного обеспечения вы'вновь пытается узнать границы того, что программное обеспечение's не ограничения.

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

Вы можете иметь все ваши функциональные тесты, но до сих пор не стресс тестирование.

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

Да, это стандартная практика.

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

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

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

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