Глава 1. Основы начала работы с тестированием программного обеспечения Основные моменты этой главы 1. Понимание опыта тестирования программного обеспечения и планирования карьеры. 2. Освоить вводные базовые знания по тестированию программного обеспечения. 3. Понять взаимосвязь между тестированием программного обеспечения и разработкой программного обеспечения. 4. Понять дефекты и элементы тестирования программного обеспечения. 1. Опыт тестирования программного обеспечения и планирование карьеры фон 1. К дефектам программного обеспечения относятся не только функциональные дефекты, но также дефекты страниц и дефекты производительности. 2. С 1960-х годов проводятся испытания, чтобы доказать правильность программы. В последние годы отечественная индустрия тестирования постепенно стандартизируется, разделение труда становится все более детальным, а индустрия тестирования развивается. будет становиться все лучше и лучше. планирование карьеры 1. Инженер по тестированию – Старший инженер по тестированию – Менеджер по тестированию Описание работы: (1) Участвовать в анализе спроса на программные продукты, писать планы тестирования, разрабатывать тестовые данные и тестовые примеры; (2) Заранее оценить риски программных продуктов и предложить эффективные планы их предотвращения. (3) Полное тестирование интеграции продукта, функционирование продукта, тестирование производительности, стресс-тестирование и т. д.; (4) Отслеживайте результаты тестирования и проверьте измененную версию программного обеспечения. (5) Проанализировать данные на основе представленного отчета об испытаниях и сделать предварительные выводы. 2. Технические потребности тестировщиков Основы программирования; инструменты автоматического тестирования; операционные системы; инструменты управления конфигурациями; 2. Базовые знания для начала работы Определение тестирования программного обеспечения Процесс использования ручных и автоматизированных средств для запуска или тестирования тестируемого объекта с целью проверки соответствия тестируемого объекта требованиям, заданным пользователем, или для выяснения разницы между ожидаемыми и фактическими результатами. Объекты тестирования программного обеспечения: включают в себя множество аспектов, включая не только тестирование программного обеспечения, но также программы, данные, документы, файлы конфигурации и т. д. Документы, полученные на каждом этапе анализа требований, эскизного проекта, детального проектирования и кодирования программы, включая спецификации требований, спецификации эскизного проекта, спецификации детального проектирования и исходные программы, должны стать объектами тестирования программного обеспечения.
Цель тестирования программного обеспечения
Целью тестирования программного обеспечения является обнаружение как можно большего количества ошибок в программном обеспечении до его ввода в эксплуатацию. Содержит следующие перспективы:
(1) Целью тестирования является обнаружение ошибок, но оно не может доказать корректность программы;
(2) Проверьте, соответствует ли система требованиям;
(3) Хорошие тестовые примеры — это те, которые обнаруживают необнаруженные ошибки, а успешные тесты — те, которые обнаруживают ошибки.
3. Принципы тестирования программного обеспечения
(1) Тестирование программного обеспечения должно быть привлечено к проекту как можно раньше и продолжать проводить тестирование программного обеспечения.
(2) Тестовые сценарии программного обеспечения разрабатываются и состоят из входных тестовых данных и соответствующих ожидаемых выходных результатов.
(3) При разработке тестовых примеров следует включать разумные и необоснованные входные условия.
(4) По каждому результату испытания должна проводиться комплексная проверка.
(5) Уделяйте пристальное внимание явлению кластеризации во время тестирования и проводите более углубленное тестирование программ/модулей, в которых обнаружено больше ошибок.
(6) Строго соблюдайте план тестирования и старайтесь избегать случайного тестирования.
3. Тестирование и разработка программного обеспечения.
Диаграмма взаимосвязи между тестированием программного обеспечения и этапами разработки программного обеспечения
Диаграмма параллелизма для тестирования и разработки
4. Дефекты при тестировании программного обеспечения
Что такое программный дефект (ошибка)
Взгляд изнутри продукта: Дефекты программного обеспечения — это ошибки, сбои и другие проблемы, возникающие во время разработки или обслуживания программных продуктов;
Взгляд снаружи продукта: Дефекты программного обеспечения — это сбои или нарушения определенных функций, которые должна реализовать система.
Механизмы ошибок программного обеспечения можно описать как: ошибки программного обеспечения, дефекты программного обеспечения, сбои программного обеспечения и сбои программного обеспечения.
а) Ошибки программного обеспечения: относятся к неприемлемым человеческим ошибкам.
б) Дефекты программного обеспечения: это недопустимые отклонения, существующие в программном обеспечении (документах, данных, программах).
в) Сбой программного обеспечения: относится к неприемлемому внутреннему состоянию, возникающему во время работы программного обеспечения. В это время, если не будут приняты соответствующие меры (отказоустойчивость) для своевременной обработки, произойдет программный сбой.
г) Сбой программного обеспечения: относится к неприемлемым внешним поведенческим результатам во время работы программного обеспечения.
Причина неисправности
а) Технические проблемы: ошибки алгоритма, синтаксические ошибки, проблемы расчета и точности, несоответствие передачи параметров интерфейса.
б) Работа в команде: недоразумения и недостаточная коммуникация.
в) Само программное обеспечение: проблемы, вызванные ошибками в документации, сценариями использования или несоответствиями пользователей, самовосстановлением системы или резервным копированием данных за пределы площадки, катастрофическим восстановлением и т. д.
4), вопросы управления проектами
Классификация дефектов
А. Этапы разработки программного обеспечения делятся на 3 категории.
(1) Неправильные характеристики
Этот тип ошибок относится к ошибкам, вызванным несоответствием между спецификациями и определениями проблем.
(2) Ошибки проектирования
Это ошибка, допущенная на этапе проектирования, из-за которой проект системы не соответствует функциональности, указанной в техническом задании.
(3) Ошибка кодирования
Ошибки при кодировании
Б. Дефекты на этапе тестирования программного обеспечения делятся на 5 категорий.
(1) Функциональная ошибка
(2) Системная ошибка
(3) Ошибки обработки
(4) Ошибка данных
(5) Ошибка кодирования
упражняться:
1. Почему спецификации программного продукта содержат больше всего дефектов?
2. Все ли дефекты необходимо исправить?
3. Если вы обнаружили дефект ПО, но разработчик со всех сторон доказывает, что это не дефект, как с этим бороться?
5. Элементы дефектов тестирования программного обеспечения
Жизненный цикл дефекта программного обеспечения
Обнаружить — Открыть — Восстановить — Закрыть
Серьезность дефектов программного обеспечения (1) Фатальный: любая основная функция системы полностью потеряна, пользовательские данные уничтожены, система выходит из строя, зависает, выходит из строя или личная безопасность находится под угрозой. (2) Серьезно: основные функции системы частично потеряны, данные не могут быть сохранены, а функции или услуги, предоставляемые системой, явно затронуты. (3) Общие сведения: некоторые функции системы реализованы не полностью, но это не влияет на нормальное использование пользователем. Например, подсказка неточна или пользовательский интерфейс плохой, время работы длительное; и другие проблемы. (2) Маленький: это делает работу оператора неудобной или хлопотной, но не влияет на работу и выполнение функций, например, возникают некоторые незначительные проблемы, такие как отдельные опечатки и неравномерное расположение текста, которые не влияют на понимание продукта. Приоритет дефектов программного обеспечения (1) Немедленное решение: дефект приводит к тому, что система становится практически непригодной для использования или испытание невозможно продолжить, и его необходимо немедленно устранить. (2) Высокий приоритет. Дефект серьезный и влияет на тестирование, поэтому ему необходимо придать приоритет. (3) Обычная очередь: дефекты необходимо поставить в очередь и ожидать ремонта. (2) Низкий приоритет: дефекты можно исправить, когда у разработчиков будет время.