Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
Функциональные требования (functional requirements 78 ) описывают поведе- ние системы, т.е. её действия (вычисления, преобразования, проверки, обработку и т.д.). В контексте проектирования функциональные требования в основном вли- яют на дизайн системы. Стоит помнить, что к поведению системы относится не только то, что система должна делать, но и то, что она не должна делать (например: «приложение не должно выгружать из оперативной памяти фоновые документы в течение 30 минут с момента выполнения с ними последней операции»). Несколько простых, изолированных от контекста и друг от друга примеров функциональных требований: • В процессе инсталляции приложение должно проверять остаток свобод- ного места на целевом носителе. • Система должна автоматически выполнять резервное копирование дан- ных ежедневно в указанный момент времени. • Электронный адрес пользователя, вводимый при регистрации, должен быть проверен на соответствие требованиям RFC822. Нефункциональные требования (non-functional requirements 79 ) описывают свойства системы (удобство использования, безопасность, надёжность, расширяе- мость и т.д.), которыми она должна обладать при реализации своего поведения. Здесь приводится более техническое и детальное описание атрибутов качества. В контексте проектирования нефункциональные требования в основном влияют на архитектуру системы. Несколько простых, изолированных от контекста и друг от друга примеров нефункциональных требований: • При одновременной непрерывной работе с системой 1000 пользователей, минимальное время между возникновением сбоев должно быть более или равно 100 часов. • Ни при каких условиях общий объём используемой приложением памяти не может превышать 2 ГБ. • Размер шрифта для любой надписи на экране должен поддерживать настройку в диапазоне от 5 до 15 пунктов. Следующие требования в общем случае могут быть отнесены к нефункцио- нальным, однако их часто выделяют в отдельные подгруппы (здесь для простоты рассмотрены лишь три таких подгруппы, но их может быть и гораздо больше; как правило, они проистекают из атрибутов качества, но высокая степень детализации позволяет отнести их к уровню требований к продукту). 78 Functional requirement. A requirement that specifies a function that a component or system must perform. [ISTQB Glossary] Functional requirements describe the observable behaviors the system will exhibit under certain conditions and the actions the system will let users take. [ «Software Requirements (3 rd edition) », Karl Wiegers and Joy Beatty] 79 Non-functional requirement. A requirement that does not relate to functionality, but to attributes such as reliability, efficiency, usability, maintainability and portability. [ISTQB Glossary] Уровни и типы требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 39/298 Ограничения (limitations, constraints 80 ) представляют собой факторы, ограни- чивающие выбор способов и средств (в том числе инструментов) реализации про- дукта. Несколько простых, изолированных от контекста и друг от друга примеров ограничений: • Все элементы интерфейса должны отображаться без прокрутки при раз- решениях экрана от 800x600 до 1920x1080. • Не допускается использование Flash при реализации клиентской части приложения. • Приложение должно сохранять способность реализовывать функции с уровнем важности «критический» при отсутствии у клиента поддержки JavaScript. Требования к интерфейсам (external interfaces requirements 81 ) описывают особенности взаимодействия разрабатываемой системы с другими системами и операционной средой. Несколько простых, изолированных от контекста и друг от друга примеров требований к интерфейсам: • Обмен данными между клиентской и серверной частями приложения при осуществлении фоновых AJAX-запросов должен быть реализован в фор- мате JSON. • Протоколирование событий должно вестись в журнале событий операци- онной системы. • Соединение с почтовым сервером должно выполняться согласно RFC3207 ( «SMTP over TLS»). Требования к данным (data requirements 82 ) описывают структуры данных (и сами данные), являющиеся неотъемлемой частью разрабатываемой системы. Ча- сто сюда относят описание базы данных и особенностей её использования. Несколько простых, изолированных от контекста и друг от друга примеров требований к данным: • Все данные системы, за исключением пользовательских документов, должны храниться в БД под управлением СУБД MySQL, пользовательские документы должны храниться в БД под управлением СУБД MongoDB. • Информация о кассовых транзакциях за текущий месяц должна храниться в операционной таблице, а по завершении месяца переноситься в архив- ную. • Для ускорения операций поиска по тексту статей и обзоров должны быть предусмотрены полнотекстовые индексы на соответствующих полях таблиц. 80 Limitation, constraint. Design and implementation constraints legitimately restrict the options available to the developer. [ «Soft- ware Requirements (3rd edition) », Karl Wiegers and Joy Beatty] 81 External interface requirements. Requirements in this category describe the connections between the system and the rest of the universe. They include interfaces to users, hardware, and other software systems. [ «Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] 82 Data requirements. Data requirement describe the format, data type, allowed values, or default value for a data element; the composition of a complex business data structure; or a report to be generated. [ «Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] Уровни и типы требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 40/298 Спецификация требований (software requirements specification, SRS 83 ) объ- единяет в себе описание всех требований уровня продукта и может представлять собой весьма объёмный документ (сотни и тысячи страниц). Поскольку требований может быть очень много, а их приходится не только единожды написать и согласовать между собой, но и постоянно обновлять, работу проектной команды по управлению требованиями значительно облегчают соответ- ствующие инструментальные средства (requirements management tools 84 , 85 ). Для более глубокого понимания принципов создания, организации и ис- пользования набора требований рекомендуется ознакомиться с фунда- ментальной работой Карла Вигерса «Разработка требований к программ- ному обеспечению» («Software Requirements (3rd Edition) (Developer Best Practices) », Karl Wiegers, Joy Beatty). В этой же книге (в приложениях) при- ведены крайне наглядные учебные примеры документов, описывающих требования различного уровня. 83 Software requirements specification, SRS. SRS describes as fully as necessary the expected behavior of the software system. The SRS is used in development, testing, quality assurance, project management, and related project functions. People call this deliverable by many different names, including business requirements document, functional spec, requirements document, and others. [ «Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] 84 Requirements management tool. A tool that supports the recording of requirements, requirements attributes (e.g. priority, knowledge responsible) and annotation, and facilitates traceability through layers of requirements and requirements change management. Some requirements management tools also provide facilities for static analysis, such as consistency checking and violations to predefined requirements rules. [ISTQB Glossary] 85 Обширный список инструментальных средств управления требованиями можно найти здесь: http://makingofsoftware.com/resources/list-of-rm-tools Свойства качественных требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 41/298 2.2.5. Свойства качественных требований В процессе тестирования требований проверяется их соответствие опреде- лённому набору свойств (рисунок 2.2.f). Рисунок 2.2.f — Свойства качественного требования Завершённость (completeness 86 ). Требование является полным и закончен- ным с точки зрения представления в нём всей необходимой информации, ничто не пропущено по соображениям «это и так всем понятно». Типичные проблемы с завершённостью: • Отсутствуют нефункциональные составляющие требования или ссылки на соответствующие нефункциональные требования (например: «пароли должны храниться в зашифрованном виде» — каков алгоритм шифрова- ния?). • Указана лишь часть некоторого перечисления (например: «экспорт осу- ществляется в форматы PDF, PNG и т.д.» — что мы должны понимать под «и т.д.»?). • Приведённые ссылки неоднозначны (например: «см. выше» вместо «см. раз- дел 123.45.b»). Способы обнаружения проблем Способы устранения проблем Применимы почти все техники тестиро- вания требований {48} , но лучше всего по- могает задавание вопросов и использо- вание графического представления раз- рабатываемой системы. Также очень по- могает глубокое знание предметной об- ласти, позволяющее замечать пропу- щенные фрагменты информации. Как только было выяснено, что чего-то не хватает, нужно полу- чить недостающую информа- цию и дописать её в требова- ния. Возможно, потребуется не- большая переработка требова- ний. 86 Each requirement must contain all the information necessary for the reader to understand it. In the case of functional requirements, this means providing the information the developer needs to be able to implement it correctly. No requirement or necessary information should be absent. [ «Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] Корректность и проверяемость Проранжированность Важность Стабильность Срочность Модифицируемость Прослеживаемость Обязательность Актуальность Выполнимость Недвусмысленность Непротиворечивость Атомарность Завершённость Свойства качественных требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 42/298 Атомарность, единичность (atomicity 87 ). Требование является атомарным, если его нельзя разбить на отдельные требования без потери завершённости и оно описывает одну и только одну ситуацию. Типичные проблемы с атомарностью: • В одном требовании, фактически, содержится несколько независимых (например: «кнопка “Restart” не должна отображаться при остановленном сервисе, окно “Log” должно вмещать не менее 20-ти записей о последних действиях пользователя» — здесь зачем-то в одном предложении описаны совершенно разные элементы интерфейса в совершенно разных кон- текстах). • Требование допускает разночтение в силу грамматических особенностей языка (например: «если пользователь подтверждает заказ и редактирует заказ или откладывает заказ, должен выдаваться запрос на оплату» — здесь описаны три разных случая, и это требование стоит разбить на три от- дельных во избежание путаницы). Такое нарушение атомарности часто вле- чёт за собой возникновение противоречивости. • В одном требовании объединено описание нескольких независимых ситуа- ций (например: «когда пользователь входит в систему, ему должно отоб- ражаться приветствие; когда пользователь вошёл в систему, должно отображаться имя пользователя; когда пользователь выходит из си- стемы, должно отображаться прощание» — все эти три ситуации заслужи- вают того, чтобы быть описанными отдельными и куда более детальными требованиями). Способы обнаружения проблем Способы устранения проблем Обдумывание, обсуждение с колле- гами и здравый смысл: если мы счи- таем, что некий раздел требований перегружен и требует декомпози- ции, скорее всего, так и есть. Переработка и структурирование требований: разбиение их на раз- делы, подразделы, пункты, под- пункты и т.д. Непротиворечивость, последовательность (consistency 88 ). Требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам. Типичные проблемы с непротиворечивостью: • Противоречия внутри одного требования (например: «после успешного входа в систему пользователя, не имеющего права входить в систему…» — тогда как он успешно вошёл в систему, если не имел такого права?) • Противоречия между двумя и более требованиями, между таблицей и тек- стом, рисунком и текстом, требованием и прототипом и т.д. (например: «712.a Кнопка “Close” всегда должна быть красной» и «36452.x Кнопка “Close” все- гда должна быть синей» — так всё же красной или синей?) • Использование неверной терминологии или использование разных терминов для обозначения одного и того же объекта или явления (например: «в случае, если разрешение окна составляет менее 800x600…» — разрешение есть у экрана, у окна есть размер). 87 Each requirement you write represents a single market need that you either satisfy or fail to satisfy. A well written requirement is independently deliverable and represents an incremental increase in the value of your software. [ «Writing Good Requirements — The Big Ten Rules», Tyner Blain: http://tynerblain.com/blog/2006/05/25/writing-good-requirements-the-big-ten-rules/ ] 88 Consistent requirements don’t conflict with other requirements of the same type or with higher-level business, user, or system requirements. [ «Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] Свойства качественных требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 43/298 Способы обнаружения проблем Способы устранения проблем Лучше всего обнаружить противоречи- вость помогает хорошая память ☺, но даже при её наличии незаменимым ин- струментом является графическое пред- ставление разрабатываемой системы, позволяющее представить всю ключевую информацию в виде единой согласован- ной схемы (на которой противоречия очень заметны). После обнаружения противо- речия нужно прояснить ситуа- цию с заказчиком и внести не- обходимые правки в требова- ния. Недвусмысленность (unambiguousness 89 , clearness ). Требование должно быть описано без использования жаргона, неочевидных аббревиатур и расплывча- тых формулировок, должно допускать только однозначное объективное понимание и быть атомарным в плане невозможности различной трактовки сочетания отдель- ных фраз. Типичные проблемы с недвусмысленностью: • Использование терминов или фраз, допускающих субъективное толкование (например: «приложение должно поддерживать передачу больших объёмов данных» — насколько «больших»?) Вот лишь небольшой перечень слов и выражений, которые можно считать верными признаками двусмысленности: адекватно (adequate), быть способным (be able to), легко (easy), обеспечи- вать (provide for), как минимум (as a minimum), быть способным (be capable of ), эффективно (effectively), своевременно (timely), применимо (as applica- ble), если возможно (if possible), будет определено позже (to be determined, TBD ), по мере необходимости (as appropriate), если это целесообразно (if practical ), но не ограничиваясь (but not limited to), быть способно (capability of), иметь возможность (capability to), нормально (normal), минимизировать (minimize ), максимизировать (maximize), оптимизировать (optimize), быстро (rapid), удобно (user-friendly), просто (simple), часто (often), обычно (usual), большой (large), гибкий (flexible), устойчивый (robust), по последнему слову техники (state-of-the-art), улучшенный (improved), результативно (efficient). Вот утрированный пример требования, звучащего очень красиво, но совер- шенно нереализуемого и непонятного: «В случае необходимости оптимиза- ции передачи больших файлов система должна эффективно использовать минимум оперативной памяти, если это возможно». • Использование неочевидных или двусмысленных аббревиатур без расшиф- ровки (например: «доступ к ФС осуществляется посредством системы прозрачного шифрования» и «ФС предоставляет возможность фиксиро- вать сообщения в их текущем состоянии с хранением истории всех изме- нений» — ФС здесь обозначает файловую систему? Точно? А не какой-ни- будь «Фиксатор Сообщений»?) • Формулировка требований из соображений, что нечто должно быть всем оче- видно (например: «Система конвертирует входной файл из формата PDF в выходной файл формата PNG» — и при этом автор считает совершенно очевидным, что имена файлов система получает из командной строки, а мно- гостраничный PDF конвертируется в несколько PNG-файлов, к именам кото- рых добавляется «page-1», «page-2» и т.д.). Эта проблема перекликается с нарушением корректности. 89 Natural language is prone to two types of ambiguity. One type I can spot myself, when I can think of more than one way to interpret a given requirement. The other type of ambiguity is harder to catch. That’s when different people read the requirement and come up with different interpretations of it. [ «Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] Свойства качественных требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 44/298 Способы обнаружения проблем Способы устранения проблем Увидеть в требованиях двусмыслен- ность хорошо помогают перечислен- ные выше слова-индикаторы. Столь же эффективным является проду- мывание проверок: очень тяжело придумать объективную проверку для требования, допускающего раз- ночтение. Самый страшный враг двусмыслен- ности – числа и формулы: если что- то можно выразить в формульном или числовом виде (вместо словес- ного описания), обязательно стоит это сделать. Если это невозможно, стоит хотя бы использовать макси- мально точные технические тер- мины, отсылки к стандартам и т.п. |