Как интерпретировать, 'тестируют каждый сценарий, о котором можно думать' [закрытый]
Во-первых "размер объекта" не является четко определенным понятием в Java. Вы могли иметь в виду сам объект, только с его участниками, Объектом и всеми объектами, которые это отсылает к (ссылочный график). Вы могли иметь в виду размер в памяти или размер на диске. И JVM позволяют оптимизировать вещи как Строки.
, Таким образом, единственный корректный путь состоит в том, чтобы спросить JVM с хорошим профилировщиком (я использую YourKit), который, вероятно, не является тем, что Вы хотите.
Однако из описания выше его кажется, что каждая строка будет автономной, и не иметь большое дерево зависимостей, таким образом, метод сериализации, вероятно, будет хорошим приближением на большей части JVMs. Самый легкий способ сделать это следующие:
Serializable ser;
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObject(ser);
oos.close();
return baos.size();
Помнят, что, если у Вас есть объекты с общими ссылками, это не будет давать корректный результат, и размер сериализации будет не всегда соответствовать размеру в памяти, но это - хорошее приближение. Код будет немного более эффективным при инициализации размера ByteArrayOutputStream к разумному значению.
15 ответов
- Every browser in every language
- Every operating system in every language
- A variety of screen resolutions
- Javascript on/off
- Images on/off
- CSS on/off
- Cookies enabled/disabled
- Messing about with URLs
- All sorts of input variations, especially testing for XSS attacks, non-ASCII characters, invalid input
- Keyboard accessibility
- Server related issues - e.g. does the application work OK after a software/hardware restart?
- Opening the site in more than one tab/window is a good way of testing any strange session-related issues
для веб-сайтов, большинство распространенных перерывов, о которых вы можете подумать во время разработки некоторые из самых крупных: предотвращение внедрения mysql предотвращение несанкционированного доступа (попадание неучастника в членский раздел) if at any time you have form submission, consider what would happen if the user altered the get or even the post data
those are all i can think of at the moment, all of these you wouldn't really "try to break" the site, you just throw some catches into your code.
Существует так много типов тестов, которые можно выполнить с учетом часть программного обеспечения, список которой бесконечен и охватывается несколькими различными типами, однозначного ответа не существует.
Функциональное тестирование, интеграционное тестирование, тестирование производительности, Проверка на проницаемость, регрессионные тесты, тестирование совместимости с браузерами, стресс-тестирование - список можно продолжить.
И это до того, как вы углубитесь в каждую и начнете обсуждать такие особенности, как атаки css / xss и т. д.
In addition to Bobby Jack's list, I'd suggest protecting your website from most-stupid-user and hacker-user scenarios -- this would mean, among other things, protecting your URLs and QueryString properly.
для целей CYA - воспользуйтесь ответом Бобби Джека
- различные разрешения экрана
In addition to Bobby Jack's list, and NomeN, and pretty much everyone else ... I don't see this mentioned specifically; apologies if it is. You didn't mention what type of site this is, but depending on the problem domain, specifically malformed data can cause headaches. For example: in an e-commerce site, what if someone tries to order negative quantities? Lots of things can be broken by "backwards" (for lack of a better word) input.
Don't forget the "bonehead" tests.
Open a page, click the submit button. Did the form properly handle absolutely nothing being submitted?
Put the cursor in a textbox field. Pound on the keys a few time (blasted cat on my keyboard, blasted coffee spill shorting things out). Did the input validation work with "non-standard" data?
Submit a form/request. Hit the back button. Is the form resubmitting itself? Should it be? Is it displaying the proper data when coming back?
You'd be surprised how many times I got burned in the past by the "bonehead" situations.
Отчасти это зависит от контекста. Вот несколько менее очевидных:
Каков «поток» сайта? Есть ли порядок, в котором пользователь должен получать доступ к вещам?
- Попробуйте выйти из строя
- Попробуйте пропустить шаги
- Выход и возврат
Заданы ли формы?
- Попробуйте XSS
- Попробуйте SQL-инъекцию
Используются ли файлы cookie?
- Попробуйте получить доступ к сайту с http://domain.com , а не с http: // www. domain.com (да, www иногда вызывает проблемы, если программист неосторожен)
Я бы начал с дымового теста - широкого теста, который проверяет самые основные функции. Затем перечислите наиболее важные функции в порядке важности и создайте тесты для них в этом порядке. Если сайт вообще любого размера и регулярно обновляется, вы захотите автоматизировать эти тесты, используя что-то вроде селена.
Одно определение: тестировать каждую ветвь кода. [100% покрытие] Конечно, это имеет значение только для нестатических веб-сайтов.
- Try to think of corner cases, and do not forget the common case.
- Stress testing.
- Click every button, and twist every knob on the user interface, make sure the feedback is reasonable and appropriate.
- Try to look at the user interface from every prospective users perspective, are there parts that are confusing, prone to misinterpretation or even do not make sense.
- Take a good look at the metaphors that are used, are they appropriate and used consistently.
- Try gibberish as input.
- Попробуйте ввести код, например Javascript, убедитесь, что он хорошо защищен от хакерских атак.
И, конечно же, основы (скопировано из Бобби Джека и доктора, предоставлено в указанном порядке):
- Каждый браузер
- Каждая операционная система
- Включение / отключение Javascript
- Включение / выключение изображений
- CSS вкл. / Выкл.
- Изменить разрешение экрана
- Файлы cookie включены
- Забудьте все, что вы знаете о системе, попробуйте взглянуть на нее так, как если бы это был первый раз.
- Ставьте под вопрос все.
- Попробуйте разные браузеры, устройства и разрешения.
- Попробуйте распечатать без установленного принтера.
- Попробуйте использовать веб-сайт, не касаясь мыши.
- Попробуйте использовать веб-сайт, не касаясь клавиатуры.
- Сделайте снимки экрана графического интерфейса пользователя и измените шкалу серого. Вы все еще можете читать текст?
На самом деле, лучше начинать с очень общих случаев. Получите хороший набор типичных вариантов использования и убедитесь, что все они тщательно протестированы. Затем начните переходить к чуть менее распространенным случаям.
Тестирование - это всегда комбинаторная ситуация, поэтому вы не можете протестировать каждый сценарий. Рассмотрим 10 браузеров x 10 типов пользователей x 10 методов x 10 ОС x 10 форм = 100 000 тестовых сценариев.
Вероятно, существует квадриллион сценариев для любого приложения разумного размера.
Таким образом, вам нужно начать с наиболее распространенных сценариев, а затем продолжить свой путь оттуда. Также нужно подумать об ортогональности тестов. Грубая сила «проверить все сценарии» просто не работает.
Было бы непрактично «проверять каждый сценарий, который вы можете придумать». Почему это так? Используя здесь всего 14 предложений, в основном из превосходного ответа Бобби Джека, вы получите 2654208 возможных тестов. На самом деле, вы бы не стали или не смогли бы проверить каждое из них. Так что же вам делать?
Это отличный пример того, как попарные (или другие, более сложные методы комбинированного тестирования) были бы чрезвычайно полезны. Всего 38 тестов охватили бы не только каждое значение параметра хотя бы один раз, но и включили бы хотя бы один тестовый пример, охватывающий каждую пару значений параметров, взаимодействующих друг с другом. (например, Browser = "Opera" и CSS = "on" будут проверены, и имитировать разорванное соединение? = "Y", и файлы cookie включены = " (A) входные данные создают 2 654 208 возможных тестовых случаев / сценариев, и (B) всего 38 тестовых примеров будут проверять каждую возможную пару значений параметров хотя бы в одном тестовом примере. (например, Browser = "Opera" и CSS = "on" будут проверены, а Simulate Dropped Connectivity? = "Y" и Cookies Enabled = "N" будут проверены и т. д.)
Image 2 - http://pea.to/8B
Дополнительная информация о этот метод максимального охвата с минимальным количеством тестовых примеров можно найти на www.combinatorialtesting.com, в частности на http://www.combinatorialtesting.com/clear-introductions-1
- Justin
Justin Хантер - основатель и генеральный директор Hexawise - Больше информации. Меньше тестов. www.hexawise.com
Также не забудьте инструменты проверки. Консорциум World Wide Web, орган стандартизации для Интернета, предлагает множество инструментов, как и другие прекрасные организации. Вот несколько хороших онлайн-инструментов, чтобы:
- Проверить HTML (например, W3C HTML валидатор ).
- Проверить CSS (например, W3C CSS валидатор .
- ] Проверить ссылки (например, Средство проверки ссылок W3C ).
- Проверить доступность (например, Wave ).
- Проверить скорость загрузки страницы (например, Google's Page Speed ).
- Проверить, как выглядят страницы при печати (это редко проверяется, но иногда можно найти артефакты, которые портят профессиональный вид).
- Проверка всех браузеров была упомянута ранее, но о чем не упоминалось, так это о том, что существуют инструменты, позволяющие быстро предоставить вам несколько представлений в браузере, чтобы превратить непрактичное в сферу практического; рассмотрите эти Инструменты тестирования браузера .
- Проверьте удобство использования; В чем-то аморфная цель часто выходит за рамки обязанностей или бюджета технического тестировщика. Недавно я наткнулся на usertesting.com , который предлагает реальную обратную связь с пользователями, дешево и быстро.
- Корректура! Опечатки - это самый быстрый способ сказать, что ваш веб-сайт глупый.
Наконец, вот мнение одного человека о разумном контрольном списке , а вот сайт с грандиозным заявлением о онлайн-проверке всего .
В чем-то аморфная цель часто выходит за рамки обязанностей или бюджета технического тестировщика. Недавно я наткнулся на usertesting.com , который предлагает реальную обратную связь с пользователями, дешево и быстро.Наконец, вот мнение одного человека о разумном контрольном списке , а вот сайт с грандиозным заявлением о онлайн-проверке всего .
В чем-то аморфная цель часто выходит за рамки обязанностей или бюджета технического тестировщика. Недавно я наткнулся на usertesting.com , который предлагает реальную обратную связь с пользователями, дешево и быстро.Наконец, вот мнение одного человека о разумном контрольном списке , а вот сайт с грандиозным заявлением о онлайн-проверке всего .