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

71

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

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

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

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

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

Нагарани Дуббака
источник
4
Возможно, уместно: тестирование на обезьянах , с плюсами и минусами
Кристоф

Ответы:

190

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

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

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

Барт ван Инген Шенау
источник
16
И затем есть вещи, которые не люди, которые делают это. 👽
Кодзиро
110
Или они могут пытаться ввести свое действительное юридическое имя, такое как «О'Мэлли», «姓名» или «Роберт»); DROP TABLE Студенты; - » .
10
90
Или , может быть подлинным название компаний, ; DROP TABLE "КОМПАНИИ"; - ООО .
Бен
25
Я думаю, что последний абзац может быть усилен, если подчеркнуть, что если программа аварийно завершает работу со случайными нажатиями кошки, идущей по клавиатуре, она почти наверняка завершится сбоем (и того хуже) со злонамеренным вводом.
Phihag
11
Кроме того, многие люди вводят случайные данные, потому что они не хотят предоставлять реальные данные (например, свое имя, день рождения и т. Д.). Некоторые также предполагают, что компьютер такой же умный, как и оператор, и могут напечатать что-то вроде «в прошлом году» вместо «2016» и ожидают, что ваше приложение справится с ним, как это сделал бы человек.
Луаан
102

Никогда не принимай ничего

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

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

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

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

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

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

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

Бен Коттрелл
источник
12
Хотя полностью случайное тестирование бесполезно, и вам, безусловно, следует явно протестировать столько граничных случаев, сколько вы можете себе представить, определенное количество случайных размытостей может иногда оказаться полезным для проверки проблем, которые вы, возможно, не предвидели.
Шон Бертон
10
У нас есть поговорка: «Так сложно написать защищенное от идиота программное обеспечение, потому что идиоты такие умные люди». Итак, сделайте тест на «бессмысленные» входы!
Ральф Клеберхофф
For example, a user may enter a malicious input which wipes the entire database - if you haven't explicitly protected against and tested for this scenario, then there's no way you can be sure whether or not this can happen.Как маленькие Бобби Таблицы из этого комикса XKCD? ;)
nick012000
12
«Никогда не предполагай ничего». Я полагаю, это хороший совет.
candied_orange
Спасибо, что указали, что не все "ошибки" являются "исправлениями". Существует большая разница в том, чтобы знать о крайнем случае и тратить время и деньги на исправление крайнего случая. Было бы неплохо разрешить любой возможный ввод данных в веб-форму и иметь заданный ответ для всех случаев, но, возможно, это не относится к вашему конкретному программному обеспечению. Может быть, ваш ввод допускает только цифры на передней части, поэтому невозможно получить не числа на задней части. «Исправление» потенциальной ошибки, связанной с отсутствием номеров в форме «только цифры», - пустая трата времени и денег.
EvSunWoodard
60

Есть несколько факторов, которые необходимо учитывать. Чтобы проиллюстрировать эти моменты, я буду использовать пример поля, в котором пользователь должен вводить процент в контексте квоты, определенной для конкретной задачи, с точки зрения того, сколько дискового пространства может использовать эта задача. 0% означает, что задача не сможет записать что-либо на диск; 100% означает, что задача может заполнить все дисковое пространство. Значения между ними означают, что они значат.

Как разработчик, вы, вероятно, считаете, что допустимые значения [0, 1, 2, 3, 99, 100], а все остальное глупо. Давайте посмотрим, почему пользователи все еще могут вводить эти «глупые» значения.

Опечатки

%^

Пользователь вводил значение 56, но ошибочно нажимал Shiftпри их вводе (например, потому что на французской клавиатуре приходится нажимать Shiftдля ввода цифр, а пользователь постоянно переключался между французской клавиатурой и QWERTY).

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

56q

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

Непонимание и неправильное толкование

Пустой ввод, вероятно, самый обычный. Пользователь вообразил, что поле является необязательным, или не знал, что поместить в это поле.

56.5

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

none

Пользователь неправильно понял, что при запросе места, которое может занять задание, приложение ожидало число. Это может указывать на плохой пользовательский интерфейс. Например, запрос пользователя «Сколько места на диске должно занимать задание?» Приглашает к такому типу ввода, в то время как поле с последующим знаком процента получит меньше такого рода ввода, потому что «none%» не делает много смысла.

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. Видите, запятая, где вы не ожидаете, и пробел.

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

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

Twenty-four

Обычные люди не думают так же, как компьютеры. «Двадцать четыре» - это фактическое число, независимо от того, что ПК скажет вам.

Хотя (1) большинство систем вообще не обрабатывают этот тип ввода и (2) почти каждый пользователь не представляет ввода целыми буквами, это не означает, что такой ввод глупый. В « О лице 3» Алан Купер подчеркивает, что отсутствие обработки таких входных данных указывает на неспособность компьютеров адаптироваться к людям, и в идеале интерфейс должен иметь возможность правильно обрабатывать эти входные данные.

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

Unicode

5𝟨

Unicode оставляет за собой свои сюрпризы: символы, которые могут выглядеть одинаково, не одинаковы. Не убежден? Скопируйте и вставьте "5𝟨" === "56"в инструменты разработчика своего браузера и нажмите Enter.

Причина того, что эти строки не равны, заключается в том, что символ Unicode отличается 𝟨от символа 6. Это создаст ситуацию, когда разъяренный клиент позвонит, сообщив, что ваше приложение не работает, предоставив снимок экрана с вводом, который выглядит правдоподобно, и ваше приложение заявит, что ввод недействителен.

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

Заключение

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

Мой ответ сфокусирован на том, что вы назвали «глупым» вкладом. Тестирование не о проверке счастливых путей; это также проверка того, что ваше приложение не ломается, когда злонамеренный пользователь намеренно вводит странные вещи, пытаясь их сломать. Это означает, что, когда вы запрашиваете процент, вам также необходимо проверить, что происходит, когда пользователь отвечает строкой, содержащей 1 000 000 символов, или отрицательным числом, или таблицей бобби .

Арсений Мурзенко
источник
9
Ах, U + 1D7E8: МАТЕМАТИЧЕСКИЙ ЦИФРОВОЙ SANS-SERIF SIX.
Андреас Рейбранд
23
В отношении другого символа Юникода: на японских клавиатурах очень распространено переключение с обычных цифр на цифры полной ширины, где цифра равна ширине кандзи. Таким образом, японский пользователь мог иметь японский ввод (а не английский) и случайно вводить цифры полной ширины.
Jan
3
Перед тем, как увидеть ваш раздел 5𝟨, касающийся той же проблемы с гомоглифом, я фактически ожидал 1 234,56строку (используя U + 00A0 NO-BREAK SPACE вместо U + 0020 SPACE), что является правильным способом кодификации этих числовых маркеров (или с помощью U + 202F). NARROW NO-BREAK SPACE, peroahps). Копирование значения из любого приложения, которое форматирует числа в соответствии с языковым стандартом, перед тем, как представить его пользователю, очень легко это произведет.
Анхель
4
Копирование - намного большая проблема. Обычным является копирование вставки пробелов, разрывов строк, невидимых символов ...
Sulthan
7
@ Арсений Мурзенко Тебе повезло. Копирование, например, из PDF и вставка, может вставлять всевозможные символы, которые могут быть нежелательны в зависимости от окружностей, например, лигатуры (для fi и т. Д.), Умные кавычки, en или em, где ASCII был минус и т. Д.
Rosie F
12

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

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

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

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

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

Роберт Харви
источник
Типичным примером приложения, которое ожидает определенный порядок, является функция «разрыва», которая выпускает дескрипторы, которые никогда не были зарезервированы.
wizzwizz4
2
К сожалению, стандартная практика состоит в том, чтобы отвергать все, что не имеет смысла, и оставлять пользователя в замешательстве и разочаровании. Правильная практика состоит в том, чтобы точно объяснить (например, с помощью сообщений об ошибках / обратной связи), почему ввод был отклонен, чтобы пользователь знал, как исправить свой ввод и принять его. Простое «получить целое число от 1 до 100» требует минимум 4 различных сообщения об ошибке (пустая строка, неподдерживаемый символ, слишком большой, слишком маленький); плюс тестирование для обеспечения правильной обратной связи в каждом конкретном случае.
Брендан
2
@Brendan: требуется только одно сообщение: «Это должно быть число от 1 до 100». Пользователь не знает (и не должен знать), что такое строка или что означают «неподдерживаемые символы». Это влияние программиста, а не помощь пользователя.
Роберт Харви
@RobertHarvey Я бы, наверное, добавил к этому утверждению что-то вроде «состоящего из цифр». Поскольку вход «Семьдесят девять» - это число от 1 до 100, но он не является входом, с которым может работать большинство программ.
Delioth
1
@Delioth: ты не можешь исправить глупость.
Роберт Харви
11

Обычно «случайные» значения не являются случайными. Вы пытаетесь захватить крайние случаи, «неизвестное неизвестное».

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

Ewan
источник
2
+1 Удивительно, как часто эти случайные символы обнаруживают ошибку. Данные из пользовательского ввода могут много путешествовать через множество компонентов / услуг. Только один компонент в цепочке не обрабатывает его должным образом, чтобы система имела ошибку.
Лан
4
особенно теперь, когда все мобильные клавиатуры имеют смайлики
Ewan
Для разработчиков .Net инструмент IntelliTest (ранее называвшийся Pex) - это действительно хороший способ использовать пути кода для нахождения крайних случаев, он особенно полезен при проверке входных данных и для получения хорошего покрытия кода.
Джеймс Снелл
7

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

После этого я придерживаюсь подхода: if "a very specific use case" do, else show error

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

Артур Тарасов
источник
1
Тем не менее, эти конкретные случаи использования могут быть слишком конкретными. Мы всегда недооцениваем пространство допустимых входных данных. (О'Хара, локально отформатированные десятичные дроби и т. Д.). Сколько финансовых процедур было подготовлено для обработки отрицательных процентных ставок?
Гуран
6

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

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

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

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

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


Более того, нечеткий «ввод» касается не только пользователей. Это может быть результат запроса API к стороннему сервису, что если он начнет отправлять испорченные результаты? Как ваша система справляется с этим? Надлежащая система должна предупредить администратора, что компонент вышел из строя. Неправильная система тихо отклонит плохой запрос или, что еще хуже, примет его как хорошие данные.

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

Schwern
источник
И есть инструменты тестирования Quick Check, которые делают подобные вещи
icc97
4

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

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

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

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

Arkanon
источник
2
test every possible type of input that a user will be physically able to submit.- Эта проблемная область по существу бесконечна, и вы тратите свое время, пытаясь все это проверить. Проверка на отрицательные входы - это единичная бифуркация; это не только разумно, но и ожидается от компетентных разработчиков. Вам не нужно проверять каждое отрицательное число, чтобы доказать, что такая проверка работает.
Роберт Харви
13
Вот почему я сказал каждый тип ввода, а не каждый возможный ввод. И я повторю свою мысль: если вы не протестируете каждый тип ввода, пользователи в конечном итоге это сделают.
Арканон
1

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

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

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

Когда вы тестируете программное обеспечение для стресс- тестирования, вы пытаетесь определить границы ограничений программного обеспечения.

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

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

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

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

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

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

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

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

Reactgular
источник