Оценочные характеристики качества:

Оценочные характеристики качества:

•Для оценки различных свойств процесса создания программного продукта, а также и самого продукта, применяются количественные характеристики, называемые мерами

•Путем непосредственного измерения определяются опорные свойства.

•Остальные свойства оцениваются путем вычисления функций от опорных значений. Такие функции называются метриками.

21. Критерии сложности, корректности и другие показатели качества программ для основных этапов их жизненного цикла.

Статическая сложность моделей: граф-модель (узлы – точки перехода, рёбра – линейные участки).

Иерархия сложности: линейный код, код с простым ветвлением (условия), с циклами.

Цикломатическое число – «густота рёбер» в графе; (Cyclomatic number, circuit rank) — для неориентированного графа число , равное мощности множества фундаментальных циклов или, что то же, числу хорд относительно каркаса графа ; для орграфа цикломатическое число неориентированного графа, получающегося заменой дуг ребрами.

Ц. число = (кол-во рёбер) – (кол-во узлов) + (кол-во связных подграфов).

Теория Холстеда

Уровень языка

Сложность комплексов программ

Сложность эксплуатации

NP-полные задачи – сводимость за биномиальное время.

(!) Сложность = (кол-во шагов) / (объём данных); ни в коем случае не время!

22. Принципы и инструменты тестирования программных продуктов.

Принципы тестирования

Хорош тот тест, для которого высока вероятность обнару­жить ошибку. Эта аксиома является фундаментальным принципом тестирования. Поскольку невозможно показать, что программа не имеет ошибок и, значит, все такие попытки бесплодны, процесс тестирования должен представлять собой попытки обнаружить в программе прежде не найденные ошибки.

Одна из самых сложных проблем при тестировании — решить, когда нужно его закончить. Как уже говорилось, исчерпывающее тестирование (т. е. испытание всех входных значений) невозможно. Таким образом, при тестировании мы сталкиваемся с экономической проблемой: как выбрать конечное число тестов, которое дает максимальную отдачу (вероятность обнаружения ошибок) для данных затрат. Известно слишком много случаев, когда написанные тесты имели крайне малую вероятность обнаружения новых ошибок, в то время как довольно очевидные хорошие тесты оставались незамеченными.

Не нужно тестировать свою собственную программу. Ни один программист не должен пытаться тестировать свою собственную программу. Это относится ко всем формам тестирования — как к тестированию системы, так и к тестированию внешних функций и даже отдельных модулей. Тестирование должно быть в высшей степени разрушительным процессом, но имеются глубокие психологические причины, по которым программист не может относиться к своей собственной программе как разрушитель. Дополнительное давление (например, жесткий график) на отдельного программиста или весь коллектив разработчиков проекта часто мешает программисту или всему коллективу выполнить адекватное тестирование. Если модуль содержит дефекты вследствие каких-то ошибок перевода, довольно высока вероятность того, что программист допустит ту же ошибку перевода (например, неправильно интерпретирует спецификации) и при подготовке тестов. Все ошибки в его понимании других модулей и их сопряжении также отразятся на тестах.

Тестирование всегда должна выполнять внешняя группа, которая в некотором смысле стоит особняком от программиста и проекта. Вместо того чтобы выполнять автономное тестирова­ние модулей самостоятельно, программист должен иметь набор тестов, подготовленных разработчиком одного из модулей, вы­зывающих тестируемый модуль (а может быть, даже выполнен­ных на машине и проверенных этим разработчиком). Комплекс­ное тестирование всегда должно выполняться независимой груп­пой, например специальным отделом обеспечения качества, или группой пользователей-добровольцев.

Отсюда вовсе не следует, что программист не может тестировать свою программу. Многие программисты с этим вполне успешно справляются. Здесь лишь делается вывод о том, что тестирование является более эффективным, если оно выполняется кем-либо другим. Заметим, что все наши рассуждения не относятся к отладке, т. е. к исправлению уже известных ошибок. Эта работа эффективнее выполняется самим автором программы.

Необходимая часть всякого теста — описание ожидаемых выходных данных или результатов. Одна из самых распространенных ошибок при тестировании состоит в том, что результаты каждого теста не прогнозируются до его выполнения. Ожидаемые результаты нужно определять заранее, чтобы не возникла ситуация, когда «глаз видит то, что хочет увидеть». Чтобы совсем исключить такую возможность, лучше разрабатывать самопроверяющиеся тесты либо пользоваться инструментами тестирования, способными автоматически сверять ожидаемые и фактические результаты.

Хотя эта аксиома чрезвычайно важна, иногда, например, при тестировании математического программного обеспечения приходится допускать исключения. Математическое программное обеспечение обладает тем свойством, что выходные данные являются только приближением правильного результата. Это происходит из-за использования конечных вычислительных процессов вместо бесконечных математических процессов, из-за ошибок округления, связанных с конечной точностью машинной арифметики и неточностью представления чисел, а также ошибок из-за конечной точности представления входных данных и констант. Поэтому во многих случаях оказывается важной не абсолютная точность, а корреляция ошибок. Например, когда математическая программа возвращает массив чисел, может оказаться важным, чтобы вычисленное решение было точным решением для набора входных данных, аппроксимирующего реальные выходные данные. Поэтому при тестировании математического программного обеспечения прогнозирование точных выходных данных затруднительно.

Избегайте невоспроизводимых тестов, не тестируйте «слету». Использование диалоговых систем иногда мешает хорошему тестированию. Для того чтобы тестировать программу в пакетной системе, программист обычно должен оформить тест в виде спе­циальной ведущей программы или в виде файла тестовых данных. В условиях диалога программист слишком часто выполняет тестирование «с лету», т. е. сидя за терминалом, задает конкретные значения и выполняет программу, чтобы «посмотреть, что получится». Это неряшливая и по многим причинам нежелательная форма тестирования. Основной ее недостаток в том, что та­кие тесты мимолетны; они исчезают по окончании их выполнения. Всякий раз, когда программу понадобится тестировать повторно (например, после исправления ошибок или после модификации), придется придумывать тесты заново.

Тестирование обходится слишком дорого и без этих дополнительных расходов. Никогда не используйте тестов, которые тут же выбрасываются. Тесты следует документировать и хранить в такой форме, чтобы каждый мог использовать их повторно.

Готовьте тесты как для правильных, так и для неправильных входных данных. Многие программисты ориентируются в своих тестах на «разумные» условия на входе, забывая о последствиях появления непредусмотренных или ошибочных входных данных. Однако многие ошибки, которые потом неожиданно обнаруживаются в работающих программах, проявляются вследствие ни­как не предусмотренных действий пользователя программы. Тес­ты, представляющие неожиданные или неправильные входные данные, часто лучше обнаруживают ошибки, чем правильные тесты.

Детально изучите результаты каждого теста. По всей вероятности, это наиболее очевидный принцип, но и ему часто не уделяется должного внимания. Самые изощренные тесты ничего не стоят, если их результаты удостаиваются лишь беглого взгляда. Тестирование программы означает большее, нежели выполнение достаточного количества тестов; оно также предполагает изучение результатов каждого теста. «Да, я уже проверял такую ситуацию, но такого как-то не заметил в выдаче», — довольно распространенная реакция программиста на обнаруженную новую ошибку.

По мере того как число ошибок, обнаруженных в некотором компоненте программного обеспечения, увеличивается, растет относительная вероятность существования в нем необнаружен­ных ошибок. Этот противоречащий интуиции феномен, означает, что ошибки образуют кластеры, т. е. встречаются группами. С ростом числа ошибок, обнаруженных в компоненте программы (например, в модуле, подсистеме, функции пользователя), увеличивается также вероятность существования в этом компоненте еще не обнаруженных ошибок. Если при тестировании двух модулей в них обнаружены одна и восемь ошибок соответственно, кривая показывает, что для модуля с восьмью ошибками вероятность того, что в нем еще есть ошибки, выше.

Поручайте тестирование самым способным программистам. Тестирование и в особенности проектирование тестов — этап в разработке программного обеспечения, особенно требующий творческого подхода. К сожалению, во многих организациях на тестирование смотрят совсем не так. Его часто считают рутинной, не­творческой работой, вследствие чего коллективы, занимающиеся тестированием, укомплектованы в основном неопытными или молодыми программистами. Однако практика показывает, что более правильным было бы сделать наоборот. Проектирование тестов требует даже больше творчества, чем разработка архитектуры и проектирование программного обеспечения.

Считайте тестируемость ключевой задачей вашей разработки.

Проект системы должен быть таким, чтобы каждый модуль подключался к системе только один раз. Множество проблем во многих больших программных системах возникает из-за нарушения этой аксиомы. Ситуация, когда во время цикла тестирования большой системы некоторые модули приходится подключать больше десяти раз, — не редкость. Каждая версия такого модуля содержит еще одну маленькую дополнительную функцию, необходимую для текущего уровня системы. Если следовать правилам и проектировать небольшие модули, каждый из которых выполняет отдельную функцию, бороться с этой проблемой станет легче.

Никогда не изменяйте программу, чтобы облегчить ее тестирование. Часто возникает соблазн изменить программу, чтобы было легче ее тестировать. Например, программист, тестируя модуль, содержащий цикл, который должен повторяться 100 раз, меняет его так, чтобы цикл повторялся только 10 раз. Может быть, этот программист и занимается тестированием, но только другой программы.

Тестирование, как почти всякая другая деятельность, должно начинаться с постановки целей. Как уже говорилось, цикл тести­рования подобен полному циклу разработки программного обес­печения. Тесты должны быть спроектированы, реализованы, про­верены и, наконец, выполнены. Поэтому задачи тестирования должны быть сформулированы на каждом его этапе, например, для каждого конкретного типа тестирования должны быть опре­делены ориентиры (число пройденных путей, проверенных услов­ных переходов и т. п.) и доля ошибок, которые должны быть обнаружены на этом этапе.

Приведем еще раз три наиболее важных принципа тестирования:

1. Тестирование — это процесс выполнения программ с целью обнаружения ошибок.

2. Хорошим считается тест, который имеет высокую вероятность обнаружения еще не выявленной ошибки.

3. Удачным считается тест, который обнаруживает еще не выявленную ошибку.