tag:blogger.com,1999:blog-2877410536371661916.post4955558629912957827..comments2023-10-23T17:22:38.832+02:00Comments on Про Тестинг: Разработка тест кейсов или практическое применение тест дизайнаАлексей Булатhttp://www.blogger.com/profile/03409061843239194158noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-2877410536371661916.post-16165163250890818282010-03-26T10:32:51.750+01:002010-03-26T10:32:51.750+01:00Обновили материал на странице:
http://www.protest...Обновили материал на странице: <br />http://www.protesting.ru/testing/testdesign_practice.html<br /><br />Добавили комментарии по выбору данных. Думаю, что теперь у Вас будет меньше вопросов, что и откуда берется. :)<br /><br />Заранее спасибо.А.Б.https://www.blogger.com/profile/15946082367048034861noreply@blogger.comtag:blogger.com,1999:blog-2877410536371661916.post-30853546166320294952010-03-23T11:18:04.003+01:002010-03-23T11:18:04.003+01:00Алексей, добралась-таки до упомянутой Вами книги и...Алексей, добралась-таки до упомянутой Вами книги и полюбопытствовала, что ж это за подходы такие.<br /><br />И вышло, что этот самый 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.»).<br /><br />А 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.»)<br /><br />Так что боюсь, что это всё-таки и не совсем то, что Вы имели в виду, отсылая меня к этому источнику, и не слишком то, что меня интересовало.<br /><br />(Просто решила отчитаться :))Lenahttps://www.blogger.com/profile/10407254034423531224noreply@blogger.comtag:blogger.com,1999:blog-2877410536371661916.post-12958276365699923822010-03-18T15:23:57.968+01:002010-03-18T15:23:57.968+01:00Алексей, спасибо за ссылку на книгу, обязательно п...Алексей, спасибо за ссылку на книгу, обязательно почитаю.Lenahttps://www.blogger.com/profile/10407254034423531224noreply@blogger.comtag:blogger.com,1999:blog-2877410536371661916.post-54527493210356048602010-03-18T13:52:12.214+01:002010-03-18T13:52:12.214+01:00Lena.
В дополнение к тому, что написал Владимир (...Lena. <br />В дополнение к тому, что написал Владимир (zppln), хочу добавить еще несколько путей сокращения количества тест кейсов:<br /><br />1. Вам нужно пригласить эксперта в предметной области, для обсуждения и выбора необходимых для проверки тет кейсов. <br /><br />2. Есть такая техника Testing-by-contract, вытекающая из design-by-contract. Об этом хорошо написано в книге "A Practitioner's Guide to Software Test Design" by Lee Copeland в главе 3: Equivalence Class Testing. В двух словах Вам просто надо договориться с дизайнером, программистом и приложением :) о том, что вы будете тестировать, а что нет. <br />Техника же, где мы тестируем всё или почти всё называется defensive testing. <br /><br />Надеюсь, что натолкнул вас на нужную мысль...А.Б.https://www.blogger.com/profile/15946082367048034861noreply@blogger.comtag:blogger.com,1999:blog-2877410536371661916.post-24361845358810108352010-03-18T13:02:24.085+01:002010-03-18T13:02:24.085+01:002Лена: Все зависит от того какое количество тестов...2Лена: Все зависит от того какое количество тестов считать разумным. В жизни количество тестов часто продиктовано не анализами рисков, а банально - бюджетом проекта. В этом случае хорошо если у вас получится хотя бы по 5 тест кейсов форму, подобную описанной в статье. Наибольший приоритет, естественно, будет представлять позитивный тест, т.е. проверка формы с валидными данными и соответствующей реакции приложения. Затем будет идти проверка альтернативных потоков событий, если они есть (открытие дочерних форм и получение данных из них (пример: select file dialog), вызов вспомогательных функций (help), отмена текущего действия (cancel)). После этого - проверка срабатывания валидаторов (1 невалидный параметр) на формах, и только затем будут идти всякие изощрения типа парвайза, естественно, только в том случае если на это остались ресурсы.<br />Как уже писал Алексей - это вопрос приоритета. Менее приоритетными будут кейсы вероятность возникновения которых в реальных условиях помноженная на ущерб от их возникновения будет наименьшей.<br />С Уважением, Владимир.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2877410536371661916.post-12765777508289186812010-03-18T11:07:55.682+01:002010-03-18T11:07:55.682+01:00Всё-таки вставлю ещё свои пять копеек, за что снов...Всё-таки вставлю ещё свои пять копеек, за что снова прошу меня извинить.<br />Но осмелюсь предположить, что, вероятно, и Вашего знакомого интересовал вопрос, как на основании продуманных тестовых данных получить _разумное_ количество тесткейсов, потому что простые переборы - это то, что лежит на поверхности.<br /><br />Я просто не вижу смысла генерировать эти безумные количества тесткейсов, если потом, на основании какого угодно подхода, реально использоваться будут, например, только 10% (да даже и 90% - всё равно это будет значить, что 10% были созданы зря). Зачем же было их генерировать и тратить на это ресурсы? Кстати, опасаюсь, что из таким образом сгенерированных тесткейсов потом будет крайне затруднительно выбрать более и менее приоритетные - проще будет заново написать то, что имеет высокий приоритет.<br /><br />Так что всё-таки мой вопрос находится в рамках темы дизайна тесткейсов - как на основании наборов данных сгенерировать такие тесткейсы и в таком количестве, которое реально может и будет использовано?Lenahttps://www.blogger.com/profile/10407254034423531224noreply@blogger.comtag:blogger.com,1999:blog-2877410536371661916.post-23753122901743353932010-03-17T20:40:47.774+01:002010-03-17T20:40:47.774+01:00Lena, Ваш вопрос по-моему немного выходит за рамки...Lena, Ваш вопрос по-моему немного выходит за рамки темы дизайна тест кейсов и перекплывает в тему их использования, и их общей необходимости... <br /><br />Вообше тема начиналась с того, что один мой знакомый НЕ ТЕСТЕР. Попросил меня помочь ему стать тестером. Он понял, что такое тест кейс, но не мог понять откуда берутся данные для тестирования. Тогда я вкрадце рассказал ему, что такое тест дизайн и про такие техники как EP, BVA, EG and etc. Он вроде понял и без труда научился составлять наборы данных, но вот у него появились вопросы: <br />- По какому принципу составлять тест кейсы с данными? <br />- Как скомбинировать данные? <br /><br />Тут я решил написать, что-то на подобии гайдлайна по созданию тест кейсов. А помог мне в этом мой старый друг - Владимир Антонов.<br /><br />На основании Ваших вопрос, скорее всего мы напишем еще статью посвященную именно работе с уже сгенерированными тестами, приоритезации их запуска и т.д. Но это будет только после того, как закончим эту...<br /><br />Спасибо Вам еще раз за Ваши комментарии.А.Б.https://www.blogger.com/profile/15946082367048034861noreply@blogger.comtag:blogger.com,1999:blog-2877410536371661916.post-18060271593881543882010-03-17T18:24:02.595+01:002010-03-17T18:24:02.595+01:00Анонимусом была я, прошу прощения, что не залогини...Анонимусом была я, прошу прощения, что не залогинилась сразу. <br /><br />>Данные подобраны не полно, т.к. на это не было сделано основного акцента. Была попытка сделать акцент именно на >методику разработки кейсов, т.е. хотели показать, как связаны тест дизайн и сами тест кейсы. Так что укажем явно, что >взяты не все представляющие интерес варианты для сокращения объема статьи.<br /><br />Я тут, наверное, пристрастна, т к последние пару месяцев увлеченно вожусь с domain тестированием (как совокупностью методик для выделения классов, выбора экземпляров из класса и их сочетания) и у меня тут вырос пунктик. <br /><br />Я соглашусь, что можно отказаться от разработки большого количества негативных тесты. А вот на правильном определении классов эквивалентности (как в случае с "Типом обращения") и на подборе тестов для тестовых строк (как хорошем примере применения техники special values тестирования), наоборот, остановилась бы поподробнее. <br /><br /><br />> вроде комбинаторика и применяется для сокращения количества тестов от максимально возможного числа вариантов. так что > да, именно эта мысль была описана.<br />Простите, но я не соглашусь с вами. Любая техника сочетания параметров применяется в первую очередь для попыток обнаружения multi-mode дефектов. Сократить кол-во тестов можно, например, рассматривая каждый элемент и каждое его выбранное его значение по отдельности. Для вашего примера получилось бы около 40 тестов <br /><br />> double-mode не очень широко используемый термин. <br />Кстати, если вы подскажете вменяемый синоним, буду крайне признательна. <br /><br />> Это не автоматизация, это обычный тест-дизайн. Соответственно, будучи сегенерированы 1 раз, матрицы данных дожны быть > записаны в тест кейсах. А повторять будет их запуск.<br />Я имела в виду алгоритм, который применяется для составления тестового набора. Если мне не изменяет память, то разные методики "спаривания" параметров отличаются не только кол-вом сочетаний, но и, например, количеством повторения каждой пары значений (что иногда полезно при тестировании на устойчивость или когда мы не уверены, что верно определили класс эквивалентности). <br /><br />Я, наверное, перефразирую свое замечание: из статьи не очень понятно, зачем вы решили применять технику сочетания данных и почему именно эту.pancakyeshttps://www.blogger.com/profile/09139624969691386232noreply@blogger.comtag:blogger.com,1999:blog-2877410536371661916.post-80926266088165321542010-03-17T17:26:59.470+01:002010-03-17T17:26:59.470+01:00Алексей, спасибо за ответ. И про риски - это понят...Алексей, спасибо за ответ. И про риски - это понятно. <br /><br />Однако:<br />статья анонсировалась, насколько я поняла, в первую очередь «для новичков».<br /><br />И вот новичок понимает, как работают техники, генерит себе данные с использованием представленных методов, а потом комбинирует их и начинает писать тесткейсы. И вот после написания этих сотен тесткейсов, как ему следует дальше работать? Проверять их все подряд? По-моему, это утопия. А если не проверять их все подряд, то зачем их было писать? Просто чтоб были? Для чего?<br /><br />Прошу прощения, что всё гну свою линию, а Вы ждали других комментариев. Но просто я считаю очень важным этот вопрос - вопрос целесообразного выбора тестов для проверки. В обычной жизни, со средними рисками.<br /><br />И при этом меня очень смущает, что я встречаю такой подход к организации тестирования: при работе над проектом сажаются люди писать тесткейсы, на каждый чих. И пишется масса тесткейсов. Только я не понимаю, зачем они, если их все всё равно потом и проверять-то по написанному никто не будет в полном объёме. Просто чтобы тестеров работой занять?<br /><br />(Если мои комментарии - всё-таки злостный оффтопик, то дайте знать :))Lenahttps://www.blogger.com/profile/10407254034423531224noreply@blogger.comtag:blogger.com,1999:blog-2877410536371661916.post-52365850684787824112010-03-17T17:08:56.540+01:002010-03-17T17:08:56.540+01:00Lena, в реальной жизни даже pirwise тестирование м...Lena, в реальной жизни даже pirwise тестирование можно встретить крайне редко, да и то, только с применением автоматизации. Однако, даже при дизайне ручных тестов полезно знать какие наборы данных могут вызывать ошибки и почему. Соответственно, основной упор идет на технику EG.<br /><br />Насчет целесообразности: все зависит от величины рисков на проекте. если это заказ на доставку пиццы - риски не очень высокие, а если это фармацевтический софт, где цена ошибки в 0.0001 мг - это жизнь не одного человека? Там вам придется не только пройти все тысячи вариантов, но еще и расписаться за каждый результат...А.Б.https://www.blogger.com/profile/15946082367048034861noreply@blogger.comtag:blogger.com,1999:blog-2877410536371661916.post-79644483166670707322010-03-17T17:04:43.609+01:002010-03-17T17:04:43.609+01:00Анонимный, спасибо за комментарий (Жалко, что Вы н...Анонимный, спасибо за комментарий (Жалко, что Вы не представились). Честно говоря, ждал именно таких замечаний и вопросов. И по существу согласен с большинством из них. <br /><br />Данные подобраны не полно, т.к. на это не было сделано основного акцента. Была попытка сделать акцент именно на методику разработки кейсов, т.е. хотели показать, как связаны тест дизайн и сами тест кейсы. Так что укажем явно, что взяты не все представляющие интерес варианты для сокращения объема статьи.<br /><br /><br />Теперь попробую ответить на вопросы из пункта 4.<br />> Как-то не очень много написано о применении методов комбинации. Вы хотите ее применить только для сокращения кол-ва тестов?<br />- вроде комбинаторика и применяется для сокращения количества тестов от максимально возможного числа вариантов. так что да, именно эта мысль была описана.<br /><br /><br />> Вы хотите применить ее для поиска double-mode дефектов? <br />- double-mode не очень широко используемый термин. Но да, для поиска double-mode дефектов в том числе. <br /><br />> Вы выбираете алгоритм с закладом на необходимость повторяемости тестов?<br />- Это не автоматизация, это обычный тест-дизайн. Соответственно, будучи сегенерированы 1 раз, матрицы данных дожны быть записаны в тест кейсах. А повторять будет их запуск.А.Б.https://www.blogger.com/profile/15946082367048034861noreply@blogger.comtag:blogger.com,1999:blog-2877410536371661916.post-7794788568305062912010-03-17T16:33:59.447+01:002010-03-17T16:33:59.447+01:00Насчёт попытки показать, как работают техники тест...Насчёт попытки показать, как работают техники тест дизайна - идея чудесная.<br /><br />Но по поводу данного примера: прошу прощения, наверное, я чего-то не понимаю и хотела бы уточнить:<br /><br />вот для формочки с пятью элементами мы получили в лучшем случае около 100 тесткейсов, в худшем - около 1000. Я так поняла, тут речь не идёт о генерировании данных для автоматических тестов. Речь идёт просто о тесткейсах для проверки функциональности формы.<br />И что - их рекомендуется все записать? А потом по написанному проверить? Или хотя бы просто все проверить? Вот все эти 100 или 1000 штук? (А в случае каких-то изменений в приложении - перепроверить, да не раз?)<br />Для формы из 5 элементов? И реально так можно работать?<br />А для более реального приложения, где элементов ну хотя бы штук 50 - получается, нужно написать даже боюсь представить сколько тесткейсов?<br />И это имеет смысл и считается целесообразным?<br /><br />Очень хочу понять, как предполагается с этим работать в реальной жизни. Спасибо заранее.Lenahttps://www.blogger.com/profile/10407254034423531224noreply@blogger.comtag:blogger.com,1999:blog-2877410536371661916.post-74049691278832056302010-03-17T15:40:34.495+01:002010-03-17T15:40:34.495+01:00Навскидку:
1) Непонятно на что влияет "Тип об...Навскидку:<br />1) Непонятно на что влияет "Тип обращения". <br />- Если при выборе разных значений будут использованы разные программные пути, то классы эквивалентности для него определены неверно. <br />- Если выбранные значения ни на что не влияют (выбранное значение просто сохраняется), то это один класс эквивалетности.<br />- В целом непонятно, почему выбраны именно первое и последнее значения. <br /><br />2) Для всех текстовых полей, на мой взгляд, неверно подобраны данные.<br />Что даст проверка "йцукенгшщзйцукенгшщзйцуке"? А корректно ли обработаются пробелы? Латиница/киррилица? Умляуты? Допустимые символы, например, дефис?<br /><br />3) На мой взгляд, не хватает тестов для номера телефона. Номера бывают более короткими (например, в провинциальных городах). Номера бывают "добавочными". <br /><br />О вариантах неверного написания вообще можно говорить часами, люди такие затейники.<br /><br />4) Как-то не очень много написано о применении методов комбинации. Вы хотите ее применить только для сокращения кол-ва тестов? Вы хотите применить ее для поиска double-mode дефектов? Вы выбираете алгоритм с закладом на необходимость повторяемости тестов?<br /><br />Спасибо за статью и за ссылки.Anonymousnoreply@blogger.com