Тестирование программного обеспечения. Базовый курс. 3-е издание
жүктеу/скачать 5,03 Mb. Pdf көрінісі
|
Software Testing - Base Course (Svyatoslav Kulikov) - 3rd edition - RU
| Недвусмысленность
(unambiguousness 90 , 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» и т.д.). Эта проблема перекликается с нарушением корректности. 90 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–2023 Стр: 47/301 Способы обнаружения проблем Способы устранения проблем Увидеть в требованиях двусмыслен- ность хорошо помогают перечислен- ные выше слова-индикаторы. Столь же эффективным является проду- мывание проверок: очень тяжело придумать объективную проверку для требования, допускающего раз- ночтение. Самый страшный враг двусмыслен- ности – числа и формулы: если что- то можно выразить в формульном или числовом виде (вместо словес- ного описания), обязательно стоит это сделать. Если это невозможно, стоит хотя бы использовать макси- мально точные технические тер- мины, отсылки к стандартам и т.п. жүктеу/скачать 5,03 Mb. Достарыңызбен бөлісу:
|