Каковы различные методы обнаружения тестовых случаев

Question

All

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

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

Буду признателен за ваши взгляды на это.

Спасибо, Байт

Answer 1

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

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

Answer 2

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

Для примера, который вы привели, я бы сделал что-то вроде этого:

1. Для каждого поля я бы подумал о возможных значениях, которые вы можете ввести, как действительные, так и недействительные. Я бы искал граничные случаи; если поле числовое, что произойдет, если я введу значение на единицу меньше нижней границы? Что произойдет, если я введу нижнюю границу в качестве значения? И т.д.
2. Затем я бы использовал такой инструмент, как Инструмент попарного независимого комбинаторного тестирования (PICT) от Microsoft , чтобы сгенерировать как можно меньше тестовых сценариев во всех случаях для всех полей ввода.
3. Я бы также написал автоматизированный тест, чтобы вычислить форму, используя произвольный ввод, захватить результаты и посмотреть, имеют ли ответы смысл (виртуальные обезьяны за клавиатурой).

Answer 3

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

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

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

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

Answer 4

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

• Кто
• Чей
• Что
• Где
• Когда
• Почему
• Как
• Сколько

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

• Кто еще
• Чей еще
• и т.д ..

Затем задайте вопросы "не" - опровергните или опровергните свои предположения и оспаривайте их.

• Кому нет (например, Кому может не понадобиться доступ к этой безопасной функции и почему?)
• Что нет (какие данные пользователю не безразличны? Что пользователь не поместит в это текстовое поле? Вы уверены?)
• и т.д ...

Другие модификаторы предложений могут быть:

• W остальное
• W не
• W риски
• W отличается
• Объедините два вопросительных слова, например, Кто и когда.

Answer 5

Определите ваши предположения с разных точек зрения:

• Как пользователи могут неправильно это понять?
• Почему я думаю, что это действует или должно действовать таким образом?
• Какие у меня могут быть предубеждения относительно того, как это программное обеспечение должно работать?
• Откуда мне знать, что требования / дизайн / реализация - это то, что нужно?
• Какие другие перспективы (пользователи, администраторы, менеджеры, разработчики, юристы) могут существовать в отношении приоритета, важности, целей и т. Д. Этого программного обеспечения?
• Правильное ли программное обеспечение создается?
• Действительно ли я знаю, как выглядит действительное имя / номер телефона / идентификационный номер / адрес / и т. Д.?
• Чего мне не хватает?
• Как я могу ошибаться относительно (вставить существительное здесь) ?

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

• http://www.qualityperspectives.ca/resources_mnemonics.html

Answer 6

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

Answer 7

Храните тестовые каталоги с общими вопросами и типами задач для различных видов задач, таких как целочисленная проверка и шаги рабочего процесса и т. Д.

Answer 8

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

Answer 9

Обсуждение идей теста с другими. Когда вы объясняете свои идеи кому-то еще, вы склонны искать способы их усовершенствовать или расширить.

Answer 10

Групповые мозговые штурмы. (или неофициально в парах, когда это необходимо)

• см. Эти методы мозгового штурма