Тестирование программного обеспечения. Базовый курс. 3-е издание
жүктеу/скачать 5,03 Mb. Pdf көрінісі
|
Software Testing - Base Course (Svyatoslav Kulikov) - 3rd edition - RU
- Бұл бет үшін навигация:
- Последовательность и структурированность.
- Полнота и неизбыточность
- Задание 2.4.a
|
Стр: 116/301 Для того чтобы чек-лист был действительно полезным инструментом, он дол- жен обладать рядом важных свойств. Логичность. Чек-лист пишется не «просто так», а на основе целей и для того, чтобы помочь в достижении этих целей. К сожалению, одной из самых частых и опасных ошибок при составлении чек-листа является превращение его в свалку мыслей, которые никак не связаны друг с другом. Последовательность и структурированность. Со структурированностью всё достаточно просто — она достигается за счёт оформления чек-листа в виде многоуровневого списка. Что до последовательности, то даже в том случае, когда пункты чек-листа не описывают цепочку действий, человеку всё равно удобнее вос- принимать информацию в виде неких небольших групп идей, переход между кото- рыми является понятным и очевидным (например, сначала можно прописать идеи простых позитивных тест-кейсов {82} , потом идеи простых негативных тест-кейсов, потом постепенно повышать сложность тест-кейсов, но не стоит писать эти идеи вперемешку). Полнота и неизбыточность . Чек-лист должен представлять собой аккурат- ную «сухую выжимку» идей, в которых нет дублирования (часто появляется из-за разных формулировок одной и той же идеи), и в то же время ничто важное не упу- щено. Правильно создавать и оформлять чек-листы также помогает восприятие их не только как хранилища наборов идей, но и как «требования для составления тест- кейсов». Эта мысль приводит к пересмотру и переосмыслению свойств качествен- ных требований (см. главу «Свойства качественных требований» {44} ) в применении к чек-листам. Задание 2.4.a: перечитайте главу «Свойства качественных требова- ний» {44} и подумайте, какие свойства качественных требований можно также считать и свойствами качественных чек-листов. Итак, рассмотрим процесс создания чек-листа. В главе «Пример анализа и тестирования требований» {54} приведён пример итоговой версии требований {60} , ко- торый мы и будем использовать. Поскольку мы не можем сразу «протестировать всё приложение» (это слиш- ком большая задача, чтобы решить её одним махом), нам уже сейчас нужно вы- брать некую логику построения чек-листов — да, их будет несколько (в итоге их можно будет структурированно объединить в один, но это не обязательно). Типичными вариантами такой логики является создание отдельных чек-ли- стов для: • типичных пользовательских сценариев {146} ; • различных уровней функционального тестирования {79} ; • отдельных частей (модулей и подмодулей {125} ) приложения; • отдельных требований, групп требований, уровней и типов требований {39} ; • частей или функций приложения, наиболее подверженных рискам. Этот список можно расширять и дополнять, можно комбинировать его пункты, получая, например, чек-листы для проверки наиболее типичных сценариев, затрагивающих некую часть приложения. Чтобы проиллюстрировать принципы построения чек-листов, мы воспользу- емся логикой разбиения функций приложения по степени их важности на три кате- гории (см. классификацию по убыванию степени важности функций приложения {79} ): Чек-лист Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2023 Стр: 117/301 • Базовые функции, без которых существование приложения теряет смысл (т.е. самые важные — то, ради чего приложение вообще создавалось), или нарушение работы которых создаёт объективные серьёзные проблемы для среды исполнения. (См. «Дымовое тестирование» {79} ). • Функции, востребованные большинством пользователей в их повседневной работе. (См. «Тестирование критического пути» {80} ). • Остальные функции (разнообразные «мелочи», проблемы с которыми не сильно повлияют на ценность приложения для конечного пользователя). (См. «Расширенное тестирование» {81} ). жүктеу/скачать 5,03 Mb. Достарыңызбен бөлісу:
|