Проектирование комплексного теста

Комплексное тестирование — наиболее творческий из всех обсуждавшихся до сих пор видов тестирования. Разработка хороших комплексных тестов требует часто даже больше изобретательности, чем само проектирование системы. Здесь нет простых рекомендаций типа тестирования всех ветвей или построения функциональных диаграмм. Однако следующие 15 пунктов дают некоторое представление о том, какие виды тестов могут понадобиться.

1. Тестирование стрессов. Распространенный недостаток больших систем состоит в том, что они функционируют как будто бы нормально при слабой или умеренной нагрузке, но выходят из строя при большой нагрузке и в стрессовых ситуациях реальной среды. Тестирование стрессов представляет собой попытки подвергнуть систему крайнему «давлению», например, попытку одновременно подключить к системе разделения времени 100 терминалов, насытить банковскую систему мощным потоком входных сообщений или систему управления — процессами аварийных сигналов от всех ее процессов.

Одна из причин, по которой тестирование стрессов опускают состоит в том, что персонал, занимающийся тестированием, хотя и признает потенциальную пользу таких тестов, считает, что столь жесткие стрессовые ситуации никогда не возникнут в реальной среде. Это предположение редко оправдывается. Например, бывают случаи, когда все пользователи системы разделения времени пытаются подключиться в одно и то же время (например, когда произошел отказ системы на 1-2 минуты и система только что восстановлена). У банковских систем, обслуживающих терминалы покупателей, бывают пиковые нагрузки в первые часы работы магазинов и в час обеденного перерыва.

2. Тестирование объема. В то время как при тестировании стрессов делается попытка подвергнуть систему серьезным нагрузкам в короткий интервал времени, тестирование объема представляет собой попытку предъявить системе большие объемы данных в течение более длительного времени. На вход компилятора следует подать до нелепости громадную программу. Программа обработки текстов — огромный документ. Очередь зада­ний операционной системы следует заполнить до предела. Цель тестирования объема — показать, что система или программа не может обрабатывать данные в количествах, указанных в их спе­цификациях.

3. Тестирование конфигурации. Многие системы, например операционные системы или системы управления файлами, обеспечивают работу различных конфигураций аппаратуры и программного обеспечения. Число таких конфигураций часто слишком велико, чтобы можно было проверить все варианты. Однако следуеттестировать по крайней мере максимальную и минимальную конфигурации. Система должна быть проверена со всяким аппаратным устройством, которое она обслуживает, или со всякой программой, с которой она должна взаимодействовать. Если сама программная система допускает несколько конфигураций (.е. покупатель может выбрать только определенные части или варианты системы), должна быть тестирована каждая из них.

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

5. Тестирование защиты. Так как внимание к вопросам сохранения секретности в обществе возрастает, к большинству систем предъявляются определенные требования по обеспечению защиты от несанкционированного доступа. Например, операционная система должна устранить всякую возможность для программы пользователя увидеть данные или программу другого пользователя. Административная информационная система не должна позволять подчиненному получить сведения о зарплате тех, кто стоит выше его по служебной лестнице. Цель тестирования защиты — нарушить секретность в системе. Один из методов -нанять профессиональную группу «взломщиков», т. е. людей с опытом разрушения средств обеспечения защиты в системах. Для тестирования защиты важно построить такие тесты, которые нарушат программные средства защиты, например, механизм защиты памяти операционной системы или механизмы защиты данных системы управления базой данных. Одним из путей разработки подобных тестов является изучение известных проблем защиты в этих системах и генерация тестов, которые позволяют проверить, как решаются аналогичные проблемы в тестируемой системе.

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

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

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

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

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

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

12. Тестирование публикации. Проверка точности всей документации для пользователя является важной частью комплексного тестирования. Все комплексные тесты следует строить только на основе документации для пользователя. Ее проверяют при определении правильности представления предшествующих тестов системы. Пользовательская документация должна быть и предметом инспекции при проверке ее на точность и ясность. Любые примеры, приведенные в документации, следует оформить как тест и подать на вход программы.

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

14. Тестирование удобства установки. Процедуры установки (настройки) некоторых типов систем программного обеспечения весьма сложны. Тестирование подобных процедур является частью процесса тестирования системы.

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

Не все из перечисленных 15 пунктов применимы к тестированию всякой системы (например, когда тестируется отдельная прикладная программа), но тем не менее это перечень вопросов, которые разумно иметь в виду.

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

Комплексное тестирование системы — такая особая и такая важная работа, что в будущем возможно появление компаний, специализирующихся в основном на комплексном тестировании систем, разработанных другими.

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

По своей природе комплексные тесты никогда не сводятся к проверке отдельных функций системы. Они часто пишутся в форме сценариев, представляющих ряд последовательных действий пользователя. Например, один комплексный тест может представлять подключение терминала к системе, выдачу последовательно 10—20 команд и затем отключение от системы. Вследствие их особой сложности тесты системы состоят из нескольких компонентов: сценария, входных данных и ожидаемых выходных данных. В сценарии точно указываются действия, которые должны быть совершены во время выполнения теста.