Читать «Вычислительное мышление: Метод решения сложных задач» онлайн - страница 117

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

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

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