Понимание того, как работает тестирование программного обеспечения и что тестировать

Ответ 1

Начнем с очевидного:

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

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

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

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

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

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

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

Что вы получаете при тестировании? На мой взгляд, есть много вещей

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

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

Ответ 2

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

Для всех современных сред разработки существуют unit test фреймворки. Там Nunit для .net, а также MS unit test framework в Visual Studio, CPPUnit для С++, JUnit и т.д. Все это означает одно: подключиться к частям вашей программы, запустить ваши предварительно определенные скрипты и сообщить об ошибке.

CPPUnit, например, основан на макросах, таких как CPPUNIT_ASSERT_EQUAL, предназначенных для использования как что-то вроде этого: CPPUNIT_ASSERT_EQUAL (sum (arr), 17). И он сказал бы, если он не будет равным, и в этом случае тест будет считаться неудачным.

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

Модульные тесты необходимы для каждой разработки программного обеспечения moden, потому что опыт показывает, что они улучшают скорость разработки. Также предлагается, чтобы unit test код мог служить своего рода "документацией" для библиотеки.

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

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

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

Ответ 3

Я нашел книгу "JUnit Pocket Guide" Кент Бек как отличное (и дешевое и компактное!) введение в Unit Testing: книга разделена примерно на разделы по существу тестового программирования и общих методов тестирования и затем переходит в спецификацию структуры JUnit (которую он создал совместно).

http://www.amazon.co.uk/JUnit-Pocket-Guide-Kent-Beck/dp/0596007434/ref=sr_1_7?ie=UTF8&s=books&qid=1276811600&sr=8-7

Что касается вашего запроса на некоторые иллюстративные примеры модульного тестирования; этот JUnit Primer неплох:

http://www.clarkware.com/articles/JUnitPrimer.html#testcase

Ответ 4

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

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

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

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

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

Я делаю, вы должны, Microsoft не делает этого. (поймать шутку;))

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

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

Я слышал об модульном тестировании. Могу ли я кратко пояснить это?

http://en.wikipedia.org/wiki/Unit_testing

Что такое среда тестирования?

http://en.wikipedia.org/wiki/Test_automation_framework

Ответ 5

Что тестировать

Есть несколько действительно полезных понятий, которые помогли мне разобраться в этом:

• http://en.wikipedia.org/wiki/Equivalence_partitioning
• http://en.wikipedia.org/wiki/Boundary-value_analysis

Обозначение эквивалентности говорит: "Выполнение теста в этом контексте с этими событиями эквивалентно этому другому тесту здесь, поэтому мне не нужно делать то и другое".

Граничный анализ говорит: "Здесь точка, в которой изменение контекста или другого события приводит к другому результату, поэтому мне понадобятся тесты по обе стороны от этой границы".

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

Когда тестировать

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

Автоматическое тестирование

Автоматическое тестирование означает либо скриптирование, либо запись теста, так что вам не нужно делать это вручную - ваш script или код сделает это за вас. Существует два вида средств автоматизации: BDD- или читаемые на английском языке приемочные испытания, которые позволяют писать сценарии и автоматические обертки, которые позволяют вам автоматизировать более легко. Например, вы можете использовать GivWenZen или Fitnesse в качестве вашего устройства, а Selenium - как инструмент для веб-автоматизации.

Если у вас есть Visual Studio 2008+, вы можете скачать исходный код здесь и попробовать сценарий, чтобы увидеть его запуск:

http://code.google.com/p/wipflash/

Тестирование устройств

В самом строгом смысле, Unit Testing означает тестирование элемента кода в изоляции от всех других элементов кода. Мы используем mocks вместо реальных фрагментов кода, которые требуются для нашего кода. В действительности мы часто прагматичны в отношении природы "единиц" - например, я не издеваюсь над предметами домена.

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

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

Структуры тестирования

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

Удачи!

Ответ 6

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

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

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

Я слышал о модульном тестировании. Могу ли я получить краткое объяснение по этому поводу? Что такое тестирование? , Зависит от вашего выбора языка программирования, потому что в python предусмотрен юнит-тест, а у java есть другая структура модульного теста

В целом необходимо пройти через концепции автоматизации тестирования и приложения.