Добрый день, мы с коллегой выложили сегодня на сайте новую статью по практическому применению некоторых техник тест дизайна. Думаю, что она будет полезна для новичков и вполне возможно для более опытных специалистов.
Мы постарались коротко, на небольшом примере, описать процесс разработки тест кейсов для небольшой формы приема заявок.
Ах, да, вот ссылка на статью: Практическое применение техник тест дизайна при разработке тест кейсов
Хотелось бы послушать Ваши комментарии и предложения по улучшению материала.
С уважением,
Алексей Булат
среда, 17 марта 2010 г.
Разработка тест кейсов или практическое применение тест дизайна
Подписаться на:
Комментарии к сообщению (Atom)
Сообщения
13 комментариев:
Навскидку:
1) Непонятно на что влияет "Тип обращения".
- Если при выборе разных значений будут использованы разные программные пути, то классы эквивалентности для него определены неверно.
- Если выбранные значения ни на что не влияют (выбранное значение просто сохраняется), то это один класс эквивалетности.
- В целом непонятно, почему выбраны именно первое и последнее значения.
2) Для всех текстовых полей, на мой взгляд, неверно подобраны данные.
Что даст проверка "йцукенгшщзйцукенгшщзйцуке"? А корректно ли обработаются пробелы? Латиница/киррилица? Умляуты? Допустимые символы, например, дефис?
3) На мой взгляд, не хватает тестов для номера телефона. Номера бывают более короткими (например, в провинциальных городах). Номера бывают "добавочными".
О вариантах неверного написания вообще можно говорить часами, люди такие затейники.
4) Как-то не очень много написано о применении методов комбинации. Вы хотите ее применить только для сокращения кол-ва тестов? Вы хотите применить ее для поиска double-mode дефектов? Вы выбираете алгоритм с закладом на необходимость повторяемости тестов?
Спасибо за статью и за ссылки.
Насчёт попытки показать, как работают техники тест дизайна - идея чудесная.
Но по поводу данного примера: прошу прощения, наверное, я чего-то не понимаю и хотела бы уточнить:
вот для формочки с пятью элементами мы получили в лучшем случае около 100 тесткейсов, в худшем - около 1000. Я так поняла, тут речь не идёт о генерировании данных для автоматических тестов. Речь идёт просто о тесткейсах для проверки функциональности формы.
И что - их рекомендуется все записать? А потом по написанному проверить? Или хотя бы просто все проверить? Вот все эти 100 или 1000 штук? (А в случае каких-то изменений в приложении - перепроверить, да не раз?)
Для формы из 5 элементов? И реально так можно работать?
А для более реального приложения, где элементов ну хотя бы штук 50 - получается, нужно написать даже боюсь представить сколько тесткейсов?
И это имеет смысл и считается целесообразным?
Очень хочу понять, как предполагается с этим работать в реальной жизни. Спасибо заранее.
Анонимный, спасибо за комментарий (Жалко, что Вы не представились). Честно говоря, ждал именно таких замечаний и вопросов. И по существу согласен с большинством из них.
Данные подобраны не полно, т.к. на это не было сделано основного акцента. Была попытка сделать акцент именно на методику разработки кейсов, т.е. хотели показать, как связаны тест дизайн и сами тест кейсы. Так что укажем явно, что взяты не все представляющие интерес варианты для сокращения объема статьи.
Теперь попробую ответить на вопросы из пункта 4.
> Как-то не очень много написано о применении методов комбинации. Вы хотите ее применить только для сокращения кол-ва тестов?
- вроде комбинаторика и применяется для сокращения количества тестов от максимально возможного числа вариантов. так что да, именно эта мысль была описана.
> Вы хотите применить ее для поиска double-mode дефектов?
- double-mode не очень широко используемый термин. Но да, для поиска double-mode дефектов в том числе.
> Вы выбираете алгоритм с закладом на необходимость повторяемости тестов?
- Это не автоматизация, это обычный тест-дизайн. Соответственно, будучи сегенерированы 1 раз, матрицы данных дожны быть записаны в тест кейсах. А повторять будет их запуск.
Lena, в реальной жизни даже pirwise тестирование можно встретить крайне редко, да и то, только с применением автоматизации. Однако, даже при дизайне ручных тестов полезно знать какие наборы данных могут вызывать ошибки и почему. Соответственно, основной упор идет на технику EG.
Насчет целесообразности: все зависит от величины рисков на проекте. если это заказ на доставку пиццы - риски не очень высокие, а если это фармацевтический софт, где цена ошибки в 0.0001 мг - это жизнь не одного человека? Там вам придется не только пройти все тысячи вариантов, но еще и расписаться за каждый результат...
Алексей, спасибо за ответ. И про риски - это понятно.
Однако:
статья анонсировалась, насколько я поняла, в первую очередь «для новичков».
И вот новичок понимает, как работают техники, генерит себе данные с использованием представленных методов, а потом комбинирует их и начинает писать тесткейсы. И вот после написания этих сотен тесткейсов, как ему следует дальше работать? Проверять их все подряд? По-моему, это утопия. А если не проверять их все подряд, то зачем их было писать? Просто чтоб были? Для чего?
Прошу прощения, что всё гну свою линию, а Вы ждали других комментариев. Но просто я считаю очень важным этот вопрос - вопрос целесообразного выбора тестов для проверки. В обычной жизни, со средними рисками.
И при этом меня очень смущает, что я встречаю такой подход к организации тестирования: при работе над проектом сажаются люди писать тесткейсы, на каждый чих. И пишется масса тесткейсов. Только я не понимаю, зачем они, если их все всё равно потом и проверять-то по написанному никто не будет в полном объёме. Просто чтобы тестеров работой занять?
(Если мои комментарии - всё-таки злостный оффтопик, то дайте знать :))
Анонимусом была я, прошу прощения, что не залогинилась сразу.
>Данные подобраны не полно, т.к. на это не было сделано основного акцента. Была попытка сделать акцент именно на >методику разработки кейсов, т.е. хотели показать, как связаны тест дизайн и сами тест кейсы. Так что укажем явно, что >взяты не все представляющие интерес варианты для сокращения объема статьи.
Я тут, наверное, пристрастна, т к последние пару месяцев увлеченно вожусь с domain тестированием (как совокупностью методик для выделения классов, выбора экземпляров из класса и их сочетания) и у меня тут вырос пунктик.
Я соглашусь, что можно отказаться от разработки большого количества негативных тесты. А вот на правильном определении классов эквивалентности (как в случае с "Типом обращения") и на подборе тестов для тестовых строк (как хорошем примере применения техники special values тестирования), наоборот, остановилась бы поподробнее.
> вроде комбинаторика и применяется для сокращения количества тестов от максимально возможного числа вариантов. так что > да, именно эта мысль была описана.
Простите, но я не соглашусь с вами. Любая техника сочетания параметров применяется в первую очередь для попыток обнаружения multi-mode дефектов. Сократить кол-во тестов можно, например, рассматривая каждый элемент и каждое его выбранное его значение по отдельности. Для вашего примера получилось бы около 40 тестов
> double-mode не очень широко используемый термин.
Кстати, если вы подскажете вменяемый синоним, буду крайне признательна.
> Это не автоматизация, это обычный тест-дизайн. Соответственно, будучи сегенерированы 1 раз, матрицы данных дожны быть > записаны в тест кейсах. А повторять будет их запуск.
Я имела в виду алгоритм, который применяется для составления тестового набора. Если мне не изменяет память, то разные методики "спаривания" параметров отличаются не только кол-вом сочетаний, но и, например, количеством повторения каждой пары значений (что иногда полезно при тестировании на устойчивость или когда мы не уверены, что верно определили класс эквивалентности).
Я, наверное, перефразирую свое замечание: из статьи не очень понятно, зачем вы решили применять технику сочетания данных и почему именно эту.
Lena, Ваш вопрос по-моему немного выходит за рамки темы дизайна тест кейсов и перекплывает в тему их использования, и их общей необходимости...
Вообше тема начиналась с того, что один мой знакомый НЕ ТЕСТЕР. Попросил меня помочь ему стать тестером. Он понял, что такое тест кейс, но не мог понять откуда берутся данные для тестирования. Тогда я вкрадце рассказал ему, что такое тест дизайн и про такие техники как EP, BVA, EG and etc. Он вроде понял и без труда научился составлять наборы данных, но вот у него появились вопросы:
- По какому принципу составлять тест кейсы с данными?
- Как скомбинировать данные?
Тут я решил написать, что-то на подобии гайдлайна по созданию тест кейсов. А помог мне в этом мой старый друг - Владимир Антонов.
На основании Ваших вопрос, скорее всего мы напишем еще статью посвященную именно работе с уже сгенерированными тестами, приоритезации их запуска и т.д. Но это будет только после того, как закончим эту...
Спасибо Вам еще раз за Ваши комментарии.
Всё-таки вставлю ещё свои пять копеек, за что снова прошу меня извинить.
Но осмелюсь предположить, что, вероятно, и Вашего знакомого интересовал вопрос, как на основании продуманных тестовых данных получить _разумное_ количество тесткейсов, потому что простые переборы - это то, что лежит на поверхности.
Я просто не вижу смысла генерировать эти безумные количества тесткейсов, если потом, на основании какого угодно подхода, реально использоваться будут, например, только 10% (да даже и 90% - всё равно это будет значить, что 10% были созданы зря). Зачем же было их генерировать и тратить на это ресурсы? Кстати, опасаюсь, что из таким образом сгенерированных тесткейсов потом будет крайне затруднительно выбрать более и менее приоритетные - проще будет заново написать то, что имеет высокий приоритет.
Так что всё-таки мой вопрос находится в рамках темы дизайна тесткейсов - как на основании наборов данных сгенерировать такие тесткейсы и в таком количестве, которое реально может и будет использовано?
2Лена: Все зависит от того какое количество тестов считать разумным. В жизни количество тестов часто продиктовано не анализами рисков, а банально - бюджетом проекта. В этом случае хорошо если у вас получится хотя бы по 5 тест кейсов форму, подобную описанной в статье. Наибольший приоритет, естественно, будет представлять позитивный тест, т.е. проверка формы с валидными данными и соответствующей реакции приложения. Затем будет идти проверка альтернативных потоков событий, если они есть (открытие дочерних форм и получение данных из них (пример: select file dialog), вызов вспомогательных функций (help), отмена текущего действия (cancel)). После этого - проверка срабатывания валидаторов (1 невалидный параметр) на формах, и только затем будут идти всякие изощрения типа парвайза, естественно, только в том случае если на это остались ресурсы.
Как уже писал Алексей - это вопрос приоритета. Менее приоритетными будут кейсы вероятность возникновения которых в реальных условиях помноженная на ущерб от их возникновения будет наименьшей.
С Уважением, Владимир.
Lena.
В дополнение к тому, что написал Владимир (zppln), хочу добавить еще несколько путей сокращения количества тест кейсов:
1. Вам нужно пригласить эксперта в предметной области, для обсуждения и выбора необходимых для проверки тет кейсов.
2. Есть такая техника Testing-by-contract, вытекающая из design-by-contract. Об этом хорошо написано в книге "A Practitioner's Guide to Software Test Design" by Lee Copeland в главе 3: Equivalence Class Testing. В двух словах Вам просто надо договориться с дизайнером, программистом и приложением :) о том, что вы будете тестировать, а что нет.
Техника же, где мы тестируем всё или почти всё называется defensive testing.
Надеюсь, что натолкнул вас на нужную мысль...
Алексей, спасибо за ссылку на книгу, обязательно почитаю.
Алексей, добралась-таки до упомянутой Вами книги и полюбопытствовала, что ж это за подходы такие.
И вышло, что этот самый Testing-by-contract - это по сути просто отсечение невалидных входных данных, т.е. негативных тестов («Testing-by-contract is based on the design-by-contract philosophy. Its approach is to create test cases only for the situations in which the pre-conditions are met.»).
А Deffensive testing - это тестирование, которые любые входные данные допускает, т.е. это как позитивные, так и негативные тесты («A different approach to design is defensive design. In this case the module is designed to accept any input. <…>Based on this approach we could define defensive testing: an approach that tests under both normal and abnormal pre-conditions.»)
Так что боюсь, что это всё-таки и не совсем то, что Вы имели в виду, отсылая меня к этому источнику, и не слишком то, что меня интересовало.
(Просто решила отчитаться :))
Обновили материал на странице:
http://www.protesting.ru/testing/testdesign_practice.html
Добавили комментарии по выбору данных. Думаю, что теперь у Вас будет меньше вопросов, что и откуда берется. :)
Заранее спасибо.
Отправить комментарий