Тестирование программного обеспечения. Базовый курс. 3-е издание

Логика создания эффективных проверок
Тестирование программного обеспечения. Базовый курс. 
© EPAM Systems, 2015–2023
 
Стр: 153/301 
•
никогда в реальной жизни (как бы мы ни старались) мы не получим «совер-
шенного и идеального набора требований» — там всегда будет некоторое 
количество недоработок, и это тоже надо принимать во внимание. 
Однако существует достаточно простой алгоритм, позволяющий нам созда-
вать эффективные проверки даже в таких условиях. Приступая к продумыванию 
чек-листа, тест-кейса или набора тест-кейсов, задайте себе следующие вопросы и 
получите чёткие ответы: 
•
Что перед вами? Если вы не понимаете, что вам предстоит тестировать, вы 
не уйдёте дальше бездумных формальных проверок. 
•
Кому и зачем оно нужно (и насколько это важно)? Ответ на этот вопрос поз-
волит вам быстро придумать несколько характерных сценариев использова-
ния
{146}
 
того, что вы собираетесь тестировать. 
•
Как оно обычно используется? Это уже детализация сценариев и источник 
идей для позитивного тестирования
{82}
 
(их удобно оформить в виде чек-ли-
ста). 
•
Как оно может сломаться, т.е. начать работать неверно? Это также детали-
зация сценариев использования, но уже в контексте негативного тестирова-
ния
{82}
 
(их тоже удобно оформить в виде чек-листа). 
К этому алгоритму можно добавить ещё небольшой перечень универсальных 
рекомендаций, которые позволят вам проводить тестирование лучше: 
•
Начинайте как можно раньше — уже с момента появления первых требова-
ний можно заниматься их тестированием и улучшением, можно писать чек-
листы и тест-кейсы, можно уточнять план тестирования, готовить тестовое 
окружение и т.д. 
•
Если вам предстоит тестировать что-то большое и сложное, разбивайте его 
на модули и подмодули, функциональность подвергайте функциональной 
декомпозиции
307
— т.е. добейтесь такого уровня детализации, при котором 
вы можете без труда удержать в голове всю информацию об объекте тести-
рования. 
•
Обязательно пишите чек-листы. Если вам кажется, что вы сможете запом-
нить все идеи и потом легко их воспроизвести, вы ошибаетесь. Исключений 
не бывает. 
•
По мере создания чек-листов, тест-кейсов и т.д. прямо в текст вписывайте 
возникающие вопросы. Когда вопросов накопится достаточно, соберите их 
отдельно, уточните формулировки и обратитесь к тому, кто может дать от-
веты. 
•
Если используемое вами инструментальное средство позволяет использо-
вать косметическое оформление текста — используйте (так текст будет 
лучше читаться), но старайтесь следовать общепринятым традициям и не 
раскрашивать каждое второе слово в свой цвет, шрифт, размер и т.д. 
•
Используйте технику беглого просмотра
{51}
 
для получения отзыва от коллег и 
улучшения созданного вами документа. 
•
Планируйте время на улучшение тест-кейсов (исправление ошибок, дора-
ботку по факту изменения требований и т.д.). 
•
Начинайте проработку (и выполнение) тест-кейсов с простых позитивных 
проверок наиболее важной функциональности. Затем постепенно повы-
шайте сложность проверок, помня не только о позитивных
{82}
, но и о негатив-
ных
{82}
 
проверках. 
307
«Functional decomposition», Wikipedia [
http://en.wikipedia.org/wiki/Functional_decomposition
] 

Логика создания эффективных проверок
Тестирование программного обеспечения. Базовый курс. 
© EPAM Systems, 2015–2023
 
Стр: 154/301 
•
Помните, что в основе тестирования лежит цель. Если вы не можете быстро 
и просто сформулировать цель созданного вами тест-кейса, вы создали пло-
хой тест-кейс. 
•
Избегайте избыточных, дублирующих друг друга тест-кейсов. Минимизиро-
вать их количество вам помогут техники классов эквивалентности
{94}
, 
гранич-
ных условий
{95}
, 
доменного тестирования
{95}
. 
•
Если показательность
{140}
 
тест-кейса можно увеличить, при этом не сильно 
изменив его сложность и не отклонившись от исходной цели, сделайте это. 
•
Помните, что очень многие тест-кейсы требуют отдельной подготовки, кото-
рую нужно описать в соответствующем поле тест-кейса. 
•
Несколько позитивных тест-кейсов
{82}
 
можно безбоязненно объединять, но 
объединение негативных тест-кейсов
{82}
 
почти всегда запрещено. 
•
Подумайте, как можно оптимизировать созданный вами тест-кейс (набор 
тест-кейсов и т.д.) так, чтобы снизить трудозатраты на его выполнение. 
•
Перед тем как отправлять финальную версию созданного вами документа, 
ещё раз перечитайте написанное (в доброй половине случаев найдёте опе-
чатку или иную недоработку). 

жүктеу/скачать 5,03 Mb.

Достарыңызбен бөлісу: