Всем привет, мы снова встретились, я ваш друг Цюаньчжаньцзюнь.

Программные дефекты:

1) Программное обеспечение не реализует функции, требуемые руководством по эксплуатации.

2) В программном обеспечении есть ошибки, которые, как указано в руководстве по продукту, не должны возникать.

3) Программное обеспечение реализует функции, не упомянутые в руководстве по продукту.

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

5) Программное обеспечение сложно понять.、Не прост в использовании、бежать медленно или оттестС точки зрения сотрудника, конечные пользователи подумают, что это нехорошо.。

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

Цель тестирования программного обеспечения:

1. Проверьте, полностью ли реализованы требования и функции программного обеспечения. 2. Убедитесь, что программное обеспечение может быть выпущено. 3. Найдите как можно больше ошибок в программном обеспечении. 4. Обнаруживайте ошибки в программном обеспечении как можно раньше. 5. Сделайте разумную оценку качества программного обеспечения. 6. Предотвратите возможные проблемы в следующей версии. 7. Предотвратите проблемы, которые могут возникнуть при их использовании пользователями. 8. Выявляйте проблемы и риски в процессе разработки.

Принципы тестирования программного обеспечения:

1. Все стандарты тестирования основаны на потребностях пользователей. 2. Разумно контролировать глубину и широту тестирования. Полное тестирование невозможно, а входные и выходные данные тестирования должны быть сбалансированы. 3. Принцип 80-20: 80% ошибок в программном обеспечении можно обнаружить и исправить на этапах анализа, проектирования и проверки, 16% дефектов обнаруживаются в ходе систематического тестирования программного обеспечения, а оставшиеся 4% вызваны длительным использованием. пользователи могут быть раскрыты в процессе. 4. Проведите тестирование как можно раньше. Чем раньше будут обнаружены ошибки, тем менее затратными будут модификации. 5. Если обнаружен участок программы с большим количеством ошибок, следует провести более углубленное тестирование. 6. Тестирование программного обеспечения начинается сразу же после запуска программного проекта, вместо того, чтобы ждать написания программы перед началом тестирования. 7. Разработчикам программного обеспечения, то есть программистам, следует избегать тестирования собственных программ. 8. Строго выполнять план тестирования и исключать случайность в тестировании, чтобы избежать упущений или дублирования неэффективной работы.

Процесс тестирования программного обеспечения

Разница между веб-тестированием и тестированием приложений

С уровня функционального тестирования нет никакой разницы между процессным и функциональным тестированием. Так в чем же разница? Поскольку оператор связи другой, тестирование системы и некоторые детали могут отличаться. Тогда мы должны сначала понять разницу между Интернетом и приложением.

Веб-проекты обычно имеют архитектуру B/S и основаны на браузере, тогда как приложения являются C/S и должны иметь клиент. Тогда и будет разница при тестировании системы.

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

Далее, с точки зрения производительности, веб-страница может фокусироваться только на времени отклика, в то время как приложению также необходимо заботиться о трафике, энергопотреблении, процессоре, графическом процессоре, памяти и т. д. Что касается производительности сервера, то тут разницы нет, поэтому обсуждать ее здесь не буду.

По сравнению с веб-тестированием в приложении есть несколько специальных тестов:

Тест на надежность:

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

Тест слабой сети — это тест, который необходимо выполнить во время тестирования приложения. Включает тесты слабой сети и коммутации сети. Необходимо протестировать взаимодействие с пользователем, вызванное слабой сетью, и ключевым моментом является рассмотрение того, приведет ли откат и обновление к вторичной отправке. Необходимо протестировать механизм обработки потери и задержки пакетов. Избегайте потери пользователей. Они обсуждались в предыдущей статье о тестировании слабой сети и не будут обсуждаться здесь снова. Установить, удалить, обновить: Веб-тестирование проводится в браузере, поэтому вам не о чем беспокоиться. Поскольку приложение является клиентским, его необходимо протестировать на предмет установки, обновления и удаления. Помимо обычной установки, обновления и удаления необходимо также учитывать нештатные сценарии. Включая перебои во время установки, слабую сеть, удаление установочных файлов после установки, обязательные и необязательные обновления, дополнительные обновления пакетов, возобновление точки останова, слабую сеть, удаление файлов, связанных с приложением, после удаления и т. д. С точки зрения автоматизации, большинство веб-сайтов используют селен и веб-драйвер, а приложения — Appium. Инструмент, используемый для веб-производительности, — LR, а приложение больше использует Jmeter.

Как отправлять качественные отчеты о дефектах

1. Краткое описание дефекта должно быть ясным и точным, чтобы соответствующий персонал, занимающийся разработкой, мог четко понять, в чем заключается проблема. 2. Полный отчет о дефекте должен включать необходимую информацию об его элементах, такую ​​как: краткое описание, средство обнаружения дефекта, тестовую среду, браузер, этапы воспроизведения дефекта, уровень серьезности, правопреемник, функциональный модуль, к которому он принадлежит и т. д., необходимая информация об элементе должна быть полностью и ясно описаны. 3. Шаги по воспроизведению дефекта должны быть четко описаны, чтобы соответствующий менеджер по разработке мог точно воспроизвести заявленный дефект в соответствии с этапами воспроизведения и определить причину дефекта. 4. Данные испытаний. Данные испытаний являются важным элементом информации для воспроизведения дефектов. Информация, используемая во время испытаний, должна быть описана четко и точно. Позвольте разработчикам точно воспроизводить дефекты на основе тестовых данных, предоставленных тестом. 5. Прикрепите информацию о снимке экрана. Информация о вложении или снимке экрана позволяет разработчикам сразу понять проблему.

Как комплексно протестировать веб-системы?

Исходный адрес：http://www.51testing.com/html/04/n-3727304.html один, Функциональное тестирование 　　1. Проверка связи 　　Ссылки являются основной функцией систем веб-приложений. Они являются основным средством переключения между страницами и направления пользователей на страницы с неизвестными адресами. Тестирование ссылок можно разделить на три аспекта. Во-первых, проверьте, действительно ли все ссылки ведут на связанную страницу, как указано; во-вторых, проверьте, существует ли связанная страница, наконец, убедитесь, что в системе веб-приложения нет потерянных страниц. ссылки, указывающие на страницу, доступ к которой возможен только в том случае, если вы знаете правильный URL-адрес. Тестирование ссылок можно автоматизировать, и для этого существует множество инструментов. Тестирование ссылок должно быть завершено на этапе интеграционного тестирования, то есть тестирование ссылок выполняется после разработки всех страниц всей системы веб-приложений. 　　2. Тестирование формы 　　Когда пользователи отправляют информацию системному администратору веб-приложения, им необходимо использовать операции формы, такие как регистрация пользователя, вход в систему, отправка информации и т. д. В этом случае мы должны проверить целостность операции отправки, чтобы проверить правильность информации, отправленной на сервер. Например: подходят ли заполненные пользователем дата рождения и род занятий, совпадают ли заполненные провинция и город и т. д. Если используются значения по умолчанию, проверьте правильность значений по умолчанию. Если форма может принимать только определенные указанные значения, проверьте и это. Например: могут быть приняты только определенные символы. Вы можете пропустить эти символы во время тестирования, чтобы увидеть, сообщит ли система об ошибке. 　　3. Проверка файлов cookie 　　Файлы cookie обычно используются для хранения информации о пользователе и пользовательских операциях в системе приложений. Когда пользователь использует файлы cookie для доступа к системе приложений, веб-сервер отправляет информацию о пользователе и сохраняет информацию на клиентском компьютере в форме файлов cookie. Это можно использовать для создания динамических и настраиваемых страниц или хранения логина и другой информации. Если система веб-приложений использует файлы cookie, вы должны проверить, могут ли файлы cookie работать правильно. Содержание теста может включать в себя информацию о том, работают ли файлы cookie, сохраняются ли они в соответствии с запланированным временем, какое влияние обновление оказывает на файлы cookie и т. д. 　　4. Тесты по языку дизайна 　　Различия в версиях языка веб-дизайна могут вызвать серьезные проблемы на стороне клиента или сервера, например, какую версию HTML использовать и т. д. Этот вопрос особенно важен при разработке в распределенной среде, где разработчики не работают все вместе. Помимо проблемы с версией HTML, различные языки сценариев, такие как Java, JavaScript, ActiveX, VBScript или Perl и т. д. также необходимо проверить. 　　5. Тестирование базы данных 　　В технологии веб-приложений база данных играет важную роль. База данных обеспечивает пространство для управления, работы, запроса и реализации запросов пользователей на хранение данных системы веб-приложений. В веб-приложениях наиболее часто используемым типом базы данных является реляционная база данных, которая может использовать SQL для обработки информации. В системе веб-приложений, использующей базу данных, обычно могут возникать два типа ошибок, а именно ошибки согласованности данных и ошибки вывода. Ошибки согласованности данных в основном вызваны неправильной информацией в форме, отправленной пользователями, тогда как ошибки вывода в основном вызваны проблемами скорости сети или конструкции программы. В этих двух ситуациях тесты можно проводить отдельно. два, Тестирование производительности 　　1. Проверка скорости соединения 　　Скорость, с которой пользователи подключаются к веб-приложениям, зависит от того, как они получают доступ к Интернету: дозваниваются ли они по телефону или используют широкополосную связь. Пользователи могут ждать более длительный период времени при загрузке программы, но не при простом посещении страницы. Если время ответа веб-системы слишком велико (например, более 5 секунд), пользователи уйдут, потому что им не терпится ждать. Кроме того, на некоторых страницах установлены ограничения по времени ожидания. Если скорость ответа слишком низкая, пользователям может потребоваться повторно войти в систему, прежде чем они смогут просматривать контент. Более того, если скорость соединения слишком низкая, это также может привести к потере данных и помешать пользователям получить реальную страницу. 　　2. Нагрузочный тест 　　Нагрузочное тестирование предназначено для измерения производительности веб-системы на определенном уровне нагрузки, чтобы гарантировать, что веб-система может нормально работать в соответствии с требованиями. Уровень нагрузки может представлять собой количество пользователей, одновременно обращающихся к веб-системе в определенное время, или объем онлайн-обработки данных. Например: скольким пользователям система веб-приложений может разрешить одновременное подключение к сети? Что произойдет, если это число будет превышено? Может ли система веб-приложений обрабатывать большое количество запросов пользователей на одну и ту же страницу? 　　3. Стресс-тест 　　Нагрузочное тестирование следует планировать после выпуска веб-системы и ее тестирования в реальной сетевой среде. Поскольку внутренние сотрудники предприятия, особенно члены проектной группы, всегда ограничены, а количество запросов, которые веб-система может обрабатывать одновременно, намного превышает этот предел, поэтому результаты будут правильными только в том случае, если они будут размещены в Интернете. и принял нагрузочное тестирование. Проведение стресс-тестирования означает фактическое уничтожение системы веб-приложений и тестирование реакции системы. Стресс-тестирование предназначено для проверки ограничений системы и возможностей восстановления после сбоев, то есть для проверки того, произойдет ли сбой системы веб-приложений и при каких обстоятельствах она выйдет из строя. Хакеры часто предоставляют ложные полезные данные до тех пор, пока система веб-приложений не выйдет из строя, а затем получают доступ при перезапуске системы. Области стресс-тестирования включают формы, страницы входа и другой информации. три, юзабилити-тестирование 　　1. Тест навигации 　　Навигация описывает, как пользователи работают на странице между различными элементами управления пользовательского интерфейса, такими как кнопки, диалоговые окна, списки и окна, или между различными подключенными страницами. Вы можете определить, легко ли ориентироваться в веб-приложении, рассмотрев следующие вопросы: Интуитивна ли навигация? Доступны ли основные части веб-системы с домашней страницы? Требуется ли для веб-системы карта сайта, поисковая система или другая навигация? СПИД? Размещение слишком большого количества информации на странице часто приводит к противоположному эффекту. Пользователи систем веб-приложений, как правило, руководствуются определенной целью и быстро просматривают систему веб-приложений, чтобы увидеть, есть ли там информация, отвечающая их потребностям. Если нет, они быстро уйдут. Лишь немногие пользователи готовы потратить время на ознакомление со структурой системы веб-приложений. Поэтому помощь в навигации по системе веб-приложений должна быть максимально точной. Другим важным аспектом навигации является согласованность структуры страницы, навигации, меню и стилей подключения системы веб-приложений. Убедитесь, что пользователи интуитивно знают, есть ли контент в системе веб-приложений и где он находится. После того, как уровень системы веб-приложений определен, необходимо начать тестирование функции пользовательской навигации. Позвольте конечным пользователям принять участие в этом тесте, и эффект будет более очевидным. 　　2. Тест графики 　　 В системах веб-приложений соответствующие изображения и анимация могут не только играть роль рекламы, но и украшать страницу. Графика системы веб-приложений может включать изображения, анимацию, границы, цвета, шрифты, фон, кнопки и т. д. 　　В состав графического теста входит: 　　(1) Убедитесь, что графика имеет четкую цель, и не группируйте изображения или анимацию в случайном порядке, чтобы не тратить время на передачу. Размер изображения системы веб-приложений должен быть как можно меньшим, и оно должно иметь возможность четко что-то объяснять, обычно ссылаясь на конкретную страницу. 　　(2) Убедитесь, что стиль шрифта на всех страницах одинаков. 　　(3) Цвет фона должен совпадать с цветом шрифта и цветом переднего плана. 　　(4) Размер и качество изображения также являются очень важным фактором, обычно используется сжатие JPG или GIF. 　　3. Тестирование контента 　　Тестирование контента используется для проверки правильности, точности и актуальности информации, предоставляемой системой веб-приложения. Точность информации означает, является ли информация надежной или дезинформированной. Например, в прайс-листе продуктов неправильные цены могут вызвать финансовые проблемы или даже привести к юридическим спорам. Точность информации зависит от наличия грамматических или орфографических ошибок; Этот тест обычно выполняется с использованием какого-либо программного обеспечения для обработки текста, например Microsoft. Функция проверки пиньинь и грамматики Word; актуальность информации означает, можно ли найти список информации или запись, связанную с текущей информацией о просмотре, на текущей странице, которая представляет собой так называемый список связанных статей на обычных веб-сайтах. 　　4. Общий тест интерфейса 　　Общий интерфейс относится к структуре страниц всей системы веб-приложений, что дает пользователям ощущение целостности. Например: чувствуют ли пользователи себя комфортно при просмотре системы веб-приложений и интуитивно ли они знают, где находится информация, которую они ищут? Последовательен ли стиль дизайна всей системы веб-приложений? Процесс тестирования всего интерфейса на самом деле представляет собой процесс исследования конечных пользователей. Обычно системы веб-приложений принимают форму анкеты на домашней странице для получения отзывов от конечных пользователей. Для любого юзабилити-тестирования необходимо участие внешнего персонала (людей, которые не имеют или мало связаны с разработкой систем веб-приложений), предпочтительно участие конечных пользователей. Четыре, Тестирование совместимости клиента 　　1. Тестирование платформы 　　На рынке существует множество различных типов операционных систем, наиболее распространенными являются Windows, Unix, Macintosh, Linux и т. д. Какую операционную систему использует конечный пользователь системы веб-приложений, зависит от конфигурации пользовательской системы. Таким образом, могут возникнуть проблемы совместимости. Одно и то же приложение может нормально работать в некоторых операционных системах, но может не работать в других операционных системах. Поэтому перед выпуском веб-системы ее необходимо протестировать на совместимость с различными операционными системами. 　　2. Тестирование браузера 　　Браузер является основным компонентом веб-клиента. Браузеры разных производителей поддерживают Java, JavaScript, ActiveX、 Плагины или разные спецификации HTML имеют разную поддержку. Например, ActiveX является продуктом Microsoft и предназначен для Интернета. Он предназначен для Explorer, JavaScript — продукт Netscape, Java — продукт Sun и т. д. Кроме того, стили фреймов и иерархии в разных браузерах отображаются по-разному или не отображаются вообще. В разных браузерах разные настройки безопасности и Java. Один из способов проверить совместимость браузера — создать матрицу совместимости. В этой матрице проверяется адаптивность браузеров разных производителей и разных версий к определенным компонентам и настройкам. пять, Тестирование безопасности 　　Система веб-приложений Тестирование Основными областями безопасности являются: 　　(1) Современные системы веб-приложений в основном используют метод сначала регистрации, а затем входа в систему. Поэтому необходимо проверять действительные и недействительные имена пользователей и пароли, обращать внимание на то, чувствительны ли они к регистру, ограничивать количество попыток, можно ли просматривать страницу напрямую без входа в систему и т. д. 　　(2) Имеет ли система веб-приложений ограничения по времени ожидания, то есть, если пользователь не нажимает ни на одну страницу в течение определенного периода времени (например, 15 минут) после входа в систему, нужно ли ему снова войти в систему, чтобы использовать это нормально. 　　(3) Для обеспечения безопасности системы веб-приложений файлы журналов имеют решающее значение. Необходимо проверить, записывается ли соответствующая информация в файл журнала и можно ли ее отследить. 　　(4) При использовании защищенного сокета проверьте правильность шифрования и целостность информации. 　　(5) Серверные сценарии часто представляют собой лазейки в безопасности, и эти лазейки часто используются хакерами. Поэтому нам также необходимо протестировать проблему, заключающуюся в том, что скрипты нельзя размещать и редактировать на стороне сервера без авторизации.

тест Классический дизайн варианта использованияВопросы для интервью——лифт,чашка,Ручка,стол,стиральная машина

Исходный адрес：https://blog.csdn.net/slforeverlove/article/details/47080279

Качества, которыми должен обладать хороший тестировщик:

1) Навыки общения и самовыражения 2) Любопытство и скептицизм 3) Чувство ответственности и способность противостоять давлению. 4) Будьте уверены в себе и придерживайтесь своего мнения. 5) Терпение и внимательность. 6) Способность мыслить наоборот. 7) Хорошо учится и подводит итоги. 8) Командный дух 9) Умение писать документы

Навыки, которыми должен обладать хороший тестировщик:

1) Знание бизнеса. 2) Иметь навыки программирования, такие как C, C++, JAVA и т. д. 3) Небольшие инструменты тестирования могут быть написаны на языке сценариев. 4) Основные приложения операционных систем и знания сетей, возможность создать тестовую среду. 5) Знание различных баз данных. 6) Знание теорий и методов тестирования программного обеспечения. 7) Освоить использование общих инструментов тестирования и разработки. 8) Отличные навыки написания документов.

Классификация тестирования программного обеспечения:

1) Разделяется в зависимости от того, выполняется ли тестируемое программное обеспечение:

Статическое тестирование: означает отсутствие запуска программного обеспечения. Тестирование включает проверку кода, анализ статической структуры, измерение качества кода и т. д. В основном оно проверяет и анализирует спецификацию требований к программному обеспечению, спецификацию проекта и исходный код программного обеспечения.

Динамическое тестирование: относится к запуску тестируемой программы, проверке разницы между результатами работы и ожидаемыми результатами, анализу причин различий и анализу эффективности работы, надежности и других характеристик программного обеспечения. Динамическое тестирование в настоящее время является основным методом тестирования компании.

2) По технологии тестирования оно делится на тестирование «черного ящика» и тестирование «белого ящика»:

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

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

3) По методу тестирования его можно разделить на ручное тестирование и автоматическое тестирование.

4) В зависимости от этапа процесса его можно разделить на модульное тестирование, интеграционное тестирование, системное тестирование и приемочное тестирование.

Модульное тестирование: посредством тестирования модуля (класса/метода/функции) код соответствует требованиям проектирования. Основная цель — выявить различные ошибки, которые могут возникнуть в процессе кодирования, например ошибки в граничных значениях во время проверки пользовательского ввода.

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

Системное тестирование: это тест, который объединяет подтвержденное программное обеспечение, компьютерное оборудование, периферийные устройства, сети и другие элементы. Системное тестирование — это проверка всей системы продукта, цель которой — проверить, соответствует ли система определению технических требований, выявить несоответствия или противоречия техническим требованиям и внести исправления.

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

Процесс разработки программного обеспечения (жизненный цикл программного обеспечения):

Планирование-"Анализ требований-"Проектирование-"Программирование-"Тестирование-"Эксплуатация/Техническое обслуживание"

Процесс тестирования программного обеспечения:

План тестирования-"Анализ требований-"Тестовые примеры-"Выполнение тестового набора-"Отправить ошибку-"Регрессионное тестирование

Модель разработки программного обеспечения:

Модель тестирования программного обеспечения:

Модель V: отражает взаимно однозначное соответствие между этапами тестирования и разработки. Тестирование происходит после разработки, и объем регрессионного тестирования после ошибок велик.

Модель W: Тестирование сопровождает весь цикл разработки, причем тестирование и разработка проводятся одновременно, что способствует раннему обнаружению проблем.

Модель H: деятельность по тестированию программного обеспечения полностью независима и параллельна другим процессам.

Метод тестирования белого ящика

Метод тестирования белого ящикаиметь Покрытие операторов, покрытие решений, покрытие условий, покрытие решений/условий, покрытие комбинаций условий и покрытие путей.

1. Покрытие операторов. Каждый оператор выполняется хотя бы один раз.

2. Каждая ветка, охватывающая каждое решение, должна быть выполнена хотя бы один раз.

3. Каждое условие, охватывающее каждое суждение, должно принимать различные возможные значения.

4. Покрытие решения/условия одновременно удовлетворяет покрытию условия покрытия решения.

5. Комбинация условий охватывает каждую комбинацию условий в каждом решении и появляется хотя бы один раз.

6. Охват путей позволяет выполнить каждый возможный путь в программе хотя бы один раз.

Каковы методы и основы для разработки вариантов использования?

делится на тест белого ящика и тест черного ящика,При ответе,Будьте осторожны, произнося их отдельно. В сценарии использования теста «белого ящика» предусмотрены следующие методы: операторов, покрытие решений, покрытие условий, покрытие решений/условий, покрытие комбинаций условий и покрытие пути. Основой является структура кода.

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

Какими качествами и навыками должен обладать инженер-испытатель?

Хороший инженер-испытатель должен не только иметь прочную основу, но и предъявлять очень высокие требования к своему характеру и чувству ответственности. Подробности заключаются в следующем: (1) Овладеть базовой теорией тестирования (2) Тестировать с установкой на выявление проблем в программном обеспечении, то есть быть объективным и не выглядеть критичным (3) Иметь опыт в читать спецификации требований и другие документы (4) ) Видеть проблемы с точки зрения пользователя (5) Иметь сильное чувство качества (6) Будьте осторожны и ответственны (7) Иметь хорошие и эффективные методы общения (с разработчиками и заказчиками) ( 8) Иметь предыдущий опыт тестирования. (9) Уметь своевременно и точно определять, где находятся зоны повышенного риска.

Каковы обычные стратегии интеграционного тестирования?

Грубо можно говорить о четырех пунктах, конечно, лучше было бы рассказать обо всех. Существует десять стратегий интеграционного тестирования: (1) Интеграция «большого взрыва» (2) Интеграция сверху вниз (3) Интеграция снизу вверх (4) Сэндвич-интеграция (5) Многоуровневая интеграция (6) Магистральная интеграция (7) Интеграция на основе функций Интеграция (8) Интеграция на основе сообщений (9) Интеграция на основе рисков (10) Интеграция на основе прогресса.

Что такое тестирование совместимости? На каких аспектах фокусируется тестирование совместимости?

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

Типы совместимости, если они разбиты, включают совместимость платформы, совместимость сети, совместимость баз данных и совместимость форматов данных.

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

У меня есть программа, и я обнаружил, что она работает очень медленно в Windows. Как определить, возникла ли проблема с программой или с программным или аппаратным обеспечением?

1. Проверьте, имеет ли система признаки отравления;

2. Проверьте, соответствует ли конфигурация программного обеспечения/оборудования рекомендуемым стандартам программного обеспечения;

3. Подтвердите, является ли текущая система независимой, то есть не предоставляет никаких внешних сервисов, потребляющих ресурсы ЦП;

4. Если это структурированное программное обеспечение C/S или B/S, вам необходимо проверить, нет ли проблем с подключением к серверу или проблемой доступа;

5. Когда нагрузка на систему отсутствует, проверьте монитор производительности, чтобы подтвердить доступ приложения к ЦП/памяти.

Каковы стратегии тестирования?

Черный ящик/белый ящик, статическое/динамическое, ручное/автоматическое, дымовое тестирование, регрессионное тестирование, публичное тестирование (стратегия бета-тестирования)

Каковы характеристики метода разработки тестовых примеров с использованием ортогональной таблицы?

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

Основные функции проверки и дефекты, вызванные вторичной интеграцией, обычно можно обнаружить, однако более глубокие и более сложные дефекты по-прежнему бессильны;

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

Опишите процесс управления отслеживанием дефектов программного обеспечения (BUG) с помощью инструмента управления дефектами bugzilla?

Посмотреть подробностиРуководство пользователя bugZilla

В Bugzilla статус отчета об ошибке разделен на следующие статусы:

Подлежит подтверждению      unconfirmed

Недавно отправленные      new

назначенный      assigned

проблема нерешенная reopened

Для повторного тестирования       resolved

быть в архиве       verified

В архиве       closed

Мнения об устранении ошибок (Решение)

Модифицированный      fixed

Не проблема       nvalid

Невозможно изменить       wontfix

Будет решено в более поздних версиях  later

 бронировать           remind

 повторить           duplicate

 не могу воспроизвести      workforme 

Как вы думаете, возникнут ли проблемы при использовании bugzilla?

Интерфейс работает нестабильно;

Настройка различных его частей по мере необходимости — утомительный процесс.

С точки зрения управления процессами безопасность трудно определить, и легко неправильно использовать ошибки других людей;

Без комплексных скоринговых показателей сложно определить приоритетность ремонта.

Опишите полный процесс разработки тест-кейса?

Анализ требований + работа по сопровождению изменений требований;

Определить требования к тестированию на основе требований;

Разрабатывать планы тестирования и проверять планы тестирования;

После прохождения проверки плана разрабатываются тестовые сценарии, а затем тестовые сценарии проверяются;

единица Каковы стратегии тестирования?

Распространенные ошибки в модулях обычно проявляются в следующих пяти аспектах, поэтому именно на этих пяти аспектах сосредоточено внимание модульного тестирования.

1. Интерфейс устройства.

2. Локальная структура данных.

3. Независимый путь.

4. Обработка ошибок.

5. Граничные условия

Во время модульного тестирования, поскольку модуль сам по себе не является независимой программой и не представляет собой полноценную работоспособную программную систему, необходимо настроить некоторые вспомогательные тестовые блоки. Существует два типа вспомогательных тестовых блоков: один является блоком драйвера, а другой. Это свая.

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

(1) Принять тестовые данные, включая входные данные тестового примера и ожидаемый результат;

(2) передать входные данные тестового примера на тестируемое устройство и запустить тестируемое устройство для тестирования;

(3) Сравните фактическую мощность тестируемого устройства с ожидаемой мощностью, чтобы получить результаты испытаний;

(4) Выведите результаты теста в указанное место.

2. Заглушка: используется для замены субблока, вызываемого в процессе работы тестируемого блока.

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

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

стратегия модульного тестирования

Существует три основные стратегии исполнения юнитов: изолированная стратегия. модульного тестирования（Isolation Unit Тестирование), нисходящая стратегия модульного тестирования（Top Down Unit Тестирование) и стратегия «снизу вверх». модульного тестирования（Bottom Up Unit Тестирование). Следует отметить, что в интеграционном тестировании также существуют стратегии тестирования «сверху вниз» и «снизу вверх», но объекты тестирования различаются.

1、изолированная стратегия модульного тестирования（Isolation Unit Testing）

Метод: Независимо от связи между каждым модулем и другими модулями, спроектируйте модуль-заглушку и модуль драйвера для каждого модуля и проведите независимое модульное тестирование для каждого модуля.

Преимущества: этот метод относительно прост, наиболее прост в использовании, обеспечивает высокий структурный охват и может выполняться параллельно. Этот метод представляет собой чисто модульное тестирование.

Недостатки: Функции-заглушки и функции драйвера имеют большую нагрузку и низкую эффективность.

2、сверху внизстратегия модульного тестирования（Top Down Unit Testing）

Метод: сначала протестируйте модуль верхнего уровня и превратите модуль, вызываемый верхним уровнем, в модуль-заглушку. Затем протестируйте второй уровень, используя модуль, протестированный выше, в качестве модуля драйвера, и так далее, пока все модули не будут выполнены. проверено.

Преимущества: позволяет сэкономить на разработке функций драйвера и имеет высокую эффективность.

Недостатки: поскольку тестируемые модули добавляются один за другим, процесс тестирования становится все более сложным, а стоимость разработки и обслуживания увеличивается.

3、вверх дномстратегия модульного тестирования（Bottom Up Unit Testing）

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

Преимущества: он позволяет сэкономить на разработке функций-заглушек и имеет высокую эффективность тестирования.

Недостатки: это не чистый модульный тест. Качество тестирования базовых функций будет иметь большое влияние на тестирование функций верхнего уровня.

Каковы три части LoadRunner?

генератор сценариев;

контроллер сцены;

Анализатор результатов.

Процесс тестирования LoadRunner?

1. Тестовый дизайн

2. Создайте сценарий виртуального пользователя.

3. Создайте сценарии работы

4. Сценарий операции

5. Сцена наблюдения

6. Анализ результатов испытаний

Лучше всего объединить вышеизложенное с кейсом и представить его на основе описанного выше процесса.

Что такое параллелизм? Как провести параллельное тестирование в lordrunner? Что произойдет, если точка встречи не удастся?

Одновременно поддерживается несколько различных операций.

LoadRunner обеспечивает маскировку IP, точки встречи, дизайн виртуальных пользователей и настройки на нескольких компьютерах, что позволяет лучше имитировать реальный параллелизм.

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

Какие функции имеет TestDirector и как он управляет процессом тестирования программного обеспечения?

Управление спросом

n Определить объем тестирования

n Определить дерево требований

n Описать функциональные точки дерева требований

план испытаний

n Определить цели тестирования и стратегии тестирования.

n Разобрать приложение и построить его испытаний Дерево。

n Определите метод тестирования для каждой функциональной точки.

n Соедините каждую функциональную точку с требованием, чтобы план испытания покрывают все потребности в испытаниях.

n Опишите шаги тестирования для ручного тестирования.

n Укажите функциональные точки, которые необходимо автоматически протестировать

выполнение теста

n Определите набор тестов.

n Разработать задачи тестирования и графики тестирования для каждого тестировщика.

n Запускайте автоматические тесты.

Отслеживание дефектов

n Регистрация дефектов

n Просмотрите новые дефекты и определите, какие из них необходимо исправить.

n Соответствующий технический персонал устраняет дефекты

n Регрессионное тестирование

n Анализировать статистические диаграммы дефектов и анализировать качество разработки приложений.

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

Тестирование совместимости, также известное как «тестирование конфигурации», проверяет, совместимо ли программное обеспечение с другими элементами системы, с которыми оно взаимодействует, такими как браузеры, операционные системы, оборудование и т. д. Проверить работу тест-объекта в различных конфигурациях программного и аппаратного обеспечения.

Functional testing (Функциональное обучения), также известный как поведенческий тестирование (тест поведения), тестирование функций и работоспособного поведения продукта для определения того, что они соответствуют требованиям к проектированию, на основе характеристик продукта, эксплуатационных описаний и пользовательских сценариев. Функциональное программное обеспечение для локализации тестирование, используемое для проверки правильности работы приложения или веб-сайта для предполагаемых пользователей. Используйте соответствующую платформу, браузер и тестовые сценарии, чтобы гарантировать, что взаимодействие с вашими целевыми пользователями будет таким же хорошим, как если бы приложение было разработано специально для этого рынка. Performance testing（Тестирование производительности）,Оцените, соответствует ли продукт или компонент требованиям к производительности. Включает в себя нагрузочный тест、тест интенсивности、Тест емкости базы данных、Бенчмарк-тест и другие виды.

Что содержит запись о дефекте (или ошибке) программного обеспечения? Как отправить высококачественные записи о дефектах программного обеспечения (ошибках)?

1. Версия программного обеспечения, соответствующая ОШИБКЕ. 2. Развитый интерфейс персонала и тестировщиков. 3.Приоритет ошибок 4. Серьезность ОШИБКИ 5. Модуль, к которому может принадлежать ОШИБКА 6. Название ОШИБКИ 7. Описание ОШИБКИ 8. Скриншоты ошибок 9. Статус ошибки 10. Типы ошибок BUG (данные, интерфейс...)

В чем разница между бета-тестированием и альфа-тестированием?

Бета-тестирование — это тест, проводимый несколькими пользователями программного обеспечения в реальной среде использования одним или несколькими пользователями. Разработчики обычно не присутствуют на месте тестирования. Альфа-тестирование — это тест, проводимый пользователем в среде разработки, или это может быть контролируемый тест, проводимый пользователями внутри компании в смоделированной реальной операционной среде.

Кто обычно участвует в обзорах программного обеспечения? Какова его цель?

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

Персонал: пользователи, клиенты или разработчики соответствующих отделов, тестировщики, аналитики требований — все приемлемы, в зависимости от стадии проверки.

В чем разница между этапным обзором и обзором проекта?

В обзоре фазы рассматривается каждый этап проекта: результаты этапа и работа.

Обзор проекта: Общий обзор проекта: работа и продукт.

Что такое фан-ин? Что такое разветвление?

Справочный ответ:

Разветвление: количество вызовов, разветвление: количество вызванных других модулей.

Что такое модуль-заглушка? Что такое модуль драйвера?

Модуль-заглушка: тестируемый модуль вызывает модуль

Модуль драйвера: вызов тестируемого модуля

Что, по вашему мнению, является ключом к хорошему планированию тестирования?

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

Сделай это хорошо испытания Ключ к работе: Цель,управлять,спецификация

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

2. Придерживайтесь правила «5W» и уточняйте содержание и процесс Правило «5W» относится к «Что (что делать)», «Почему (зачем это делать)», «Когда (когда это делать)», «Где (существовать Где)», «Как (как это сделать) )". Создайте программное обеспечение, используя план правила «5W». испытаний,Может помочь команде тестировщиков понять цель тестирования (почему),Уточнить объем и содержание теста (Что),Определите даты начала и окончания теста (когда),Укажите методы и инструменты для тестирования (Как),Указывает место (где), где хранится тестовая документация и программное обеспечение.

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

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

Кратко опишите жизненный цикл дефекта?

представлять на рассмотрение->подтверждать->распространять->ремонт->проверять->закрытие

По каким аспектам следует проверять безопасность программного обеспечения?

(1) Механизм аутентификации пользователя: например, сертификат данных, смарт-карта, двухфакторная аутентификация, безопасный протокол электронных транзакций.

(2) Механизм шифрования

(3) Стратегии защиты безопасности: такие как журналы безопасности, обнаружение вторжений, изоляционная защита и сканирование уязвимостей.

(4) Методы резервного копирования и восстановления данных: оборудование для хранения, оптимизация хранения, защита хранилища, управление хранилищем.

(5) Антивирусная система

Каков статус и понимание работы по управлению конфигурацией программного обеспечения?

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

Управление конфигурацией тестирования программного обеспечения включает в себя четыре основных действия:

Идентификатор элемента конфигурации

Управление элементами конфигурации

Отчет о состоянии элемента конфигурации

Настройка аудита

   Управлению конфигурацией программного обеспечения обычно помогают инструменты, в основном MS. SourceSafe、Rational ClearCase и т. д.

Как вы думаете, какими должны быть стандарты прохождения тестирования программного обеспечения?

Значение плотности дефектов соответствует требованиям заказчика.

Что значит внедрить управление тестированием?

Анализ рисков, контроль выполнения, распределение ролей, контроль качества

Из каких этапов должен состоять полный набор тестов?

Справочный ответ:план испытаний、Проектирование и разработка、реализация тестового теста、Обзор и тест Выводы

Каково основное содержание модульного тестирования?

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

Интеграционное тестирование еще называют сборочным тестированием или совместным тестированием. Кратко опишите основное содержание интеграционного тестирования.

(1) Будут ли потеряны данные, проходящие через интерфейс модуля, при подключении различных модулей?

(2) Будет ли функция одного модуля отрицательно влиять на функцию другого модуля;

(3) может ли комбинация каждой подфункции достичь ожидаемой родительской функции;

(4) Есть ли проблема с глобальной структурой данных;

(5) Будут ли ошибки отдельного модуля усиливаться при накоплении, достигая неприемлемого уровня.

Кратко опишите взаимосвязь между интеграционным тестированием и тестированием системы?

(1) Основной основой для интеграционного тестирования является эскизная спецификация проекта, а основной основой для тестирования системы является спецификация проектирования требований;

(2) Интеграционное тестирование — это тестирование системных модулей, а системное тестирование — это тестирование всей системы, включая тестирование соответствующих программных и аппаратных платформ, сетей и соответствующих периферийных устройств.

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

Руководство пользователя

Инструкции по установке и настройке

Онлайн-помощь

гид, гид

Образцы, примеры и шаблоны

Форма авторизации/регистрации

Лицензионное соглашение с конечным пользователем

На каких еще документах следует сосредоточить внимание при документировании тестирования, помимо пользовательской документации в программной системе?

Разработочная документация

Спецификация требований к программному обеспечению

　　　　Инструкции по проектированию базы данных

　　　　Спецификация эскизного проекта

　　　　Подробные инструкции по проектированию

　　　　отчет о технико-экономическом обосновании

Управление документами

　　　　план развития проекта

　　　　план испытаний

　　　　отчет об испытаниях

　　　　Ежемесячный отчет о ходе разработки

　　　　Сводный отчет о разработке

Кратко опишите ключевые моменты тестирования пользовательских документов в программных комплексах?

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

(2) Терминология. Термины, используемые в документе, должны быть пригодны для целевой аудитории, иметь единообразное использование и иметь стандартные определения, соответствующие отраслевым нормам.

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

(4) Честность. Проверьте интерфейс программного обеспечения, чтобы увидеть, есть ли какие-либо важные ветки, которые не описаны, или даже есть ли целые большие модули, которые не описаны.

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

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

(7) Диаграммы и скриншоты интерфейса. Убедитесь, что все схемы и скриншоты интерфейса соответствуют релизной версии.

(8) Образцы и примеры. Загрузите и используйте образцы как пользователь. Если это программа, введите данные и выполните ее. Создайте документы для каждого модуля и подтвердите их правильность.

(9) Язык. Не должно быть опечаток и двусмысленных утверждений. Особое внимание уделяйте тексту на скриншотах или нарисованной графике.

(10) Печать и упаковка. Проверьте качество печати; соответствует ли толщина и формат руководства; соответствует ли размер упаковочной коробки; нет ли мелких деталей, которые легко теряются и т. д.

Каково основное содержание модульного тестирования?

Большая часть модульного тестирования выполняется разработчиками. Тестировщики с хорошим техническим опытом или при разработке системного программного обеспечения могут привлечь тестировщиков для проведения модульного тестирования. Большинство выполняемых модульных тестов представляют собой процесс отладки программ разработчиками или совместной отладкой системы. Основная цель обсуждения данного вопроса – расширение кругозора читателей.

Модульное тестирование обычно включает в себя пять аспектов тестирования:

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

-Совпадает ли количество введенных фактических параметров с количеством формальных параметров;

-соответствие входных фактических параметров атрибутам формальных параметров;

-Соответствуют ли размеры входных фактических параметров формальным параметрам;

- совпадает ли количество фактических параметров, заданных при вызове других модулей, с количеством формальных параметров вызываемого модуля;

-Соответствуют ли свойства фактических параметров, заданных при вызове других модулей, свойствам формальных параметров вызываемого модуля;

-Соответствуют ли размеры фактических параметров, заданных при вызове других модулей, размерам формальных параметров вызываемого модуля;

-Правильны ли количество, атрибуты и порядок параметров, используемых при вызове предопределенной функции;

-Есть ли ссылка на параметр, не связанная с текущей точкой входа;

- Были ли изменены параметры, доступные только для чтения;

-Последовательны ли определения глобальных переменных в разных модулях;

— Передавать ли определенные ограничения в качестве параметров.

Если функция модуля включает внешний ввод и вывод, следует также учитывать следующие факторы:

-Правильны ли атрибуты файла;

-Правильна ли инструкция OPEN/CLOSE;

-Соответствует ли описание формата операторам ввода и вывода;

-Соответствует ли размер буфера длине записи;

- Был ли файл открыт перед использованием;

-Обрабатывается ли конец файла;

- Обрабатываются ли ошибки ввода/вывода;

-Есть ли текстовые ошибки в выводимой информации.

-Тестирование локальной структуры данных;

- проверка граничных условий;

-Все независимые тесты путей выполнения в модуле;

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

- Неподходящие или несовместимые описания типов;

-Переменная не имеет начального значения;

- Ошибка инициализации переменной или значения по умолчанию;

-Неправильное имя переменной (опечатка или неправильное усечение);

- Возникают исключения переполнения, потери адреса и исключения.

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

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

-Непонимание или использование неправильного приоритета операторов;

-Операции смешанного типа;

-Неверное начальное значение переменной;

-Недостаточная точность;

- Знак выражения неправильный.

Суждение сравнения и поток управления часто тесно связаны при тестировании со следующими ошибками:

-Сравнивать объекты разных типов данных;

-Неправильное использование логических операторов или приоритета;

- Ожидание, что две величины, которые теоретически равны, но на самом деле не равны, из-за ограничений компьютерного представления;

-Ошибка в операции сравнения или переменной;

-Условие завершения цикла может не возникнуть;

-Невозможно выйти, если итерация расходится;

- Переменные цикла были неправильно изменены.

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

-Сообщение об ошибке вывода трудно понять;

-Записанные ошибки не соответствуют реальным ошибкам;

- Система вмешалась до запуска настроенного раздела программы по обработке ошибок;

- Неправильная обработка исключений;

- В заявлении об ошибке не содержится достаточной информации для обнаружения ошибки.

Как понять силовое тестирование?

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

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

Тестовые показатели теста на прочность и стресс-теста схожи, и большинство из них являются индикаторами, связанными со временем, такими как параллелизм (пропускная способность), задержка (максимум\минимум\среднее) и индикаторы последовательности и т. д.

Испытание на прочность требует знания структуры системы и разработки методов испытаний на прочность на основе характеристик системы.

Как понимать стресс-тестирование, нагрузочное тестирование и тестирование производительности?

Тестирование производительность - это более широкий диапазон, на самом деле Тестирование производительностипроизводительность включена、сила、давление、Масса другого контента.

давлениетест Речь идет о стабильности и грузоподъемности сервера.тест,Это очень распространенный тест. Увеличение количества пользователей, обращающихся к системе, или несколько пользователей, выполняющих операции с большими объемами данных, вызывают стресс. Нагрузочный тест проводится с относительно большим давлением.,В основном существует тест-система или соответствующая способность в концентрированных экстремальных условиях.,Является важной частью Тестирования производительности. 100 пользователей, непрерывно получающих доступ к системе в течение получаса, можно расценивать как стресс-тест.,Тогда 8 часов непрерывного доступа можно считать нагрузочным тестом.,1000 пользователей, непрерывно обращающихся к системе в течение 1 часа, также можно рассматривать как нагрузку.

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

Что такое узкое место системы?

«Узкие места» в основном относятся к неспособности одного или нескольких аспектов всей программно-аппаратной системы удовлетворить конкретные бизнес-требования пользователей. «Специфический» означает, что узкие места появятся при определенных условиях, поскольку в конце концов большинство систем не могут удовлетворить конкретный бизнес. требования пользователей до их ввода в эксплуатацию.

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

Поэтому мы тестируем узкие места системы главным образом для достижения следующих двух целей:

-Обнаружение «поверхностных» узких мест. В основном для имитации действий пользователя,Выявление узких мест, когда пользователи используют систему на пределе своих возможностей,Затем устраните узкое место,Это Тестирование Основная цель производительности.

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

Что в основном включает в себя тестирование документов?

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

Целостность документа: в основном это относится к полноте и полноте содержания документа, а также к пониманию общего качества документа. Например, Руководство пользователя должно включать все функциональные модули программного обеспечения.

Согласованность описания и фактической ситуации с программным обеспечением: в основном степень соответствия между документацией на программное обеспечение и фактической ситуацией с программным обеспечением. Например Руководство После того, как пользователь в основном завершен, нам также нужно обратить внимание на Руководство. пользователя соответствует фактическому описанию функции. Потому что документация часто не успевает за скоростью обновления версий программного обеспечения.

Понятность: в первую очередь проверьте, есть ли в документе графические описания ключевых и важных операций, а также легко ли понять текст и диаграммы. Для ключевых и важных операций одних текстовых описаний явно недостаточно. Необходимо прикрепить схемы, чтобы описания были более интуитивными и понятными.

Примеры операций приведены в документации: Эта проверка в основном предназначена для Руководства. пользователь. Являются ли примеры приложений, предоставленные для основных функций и ключевых операций, богатыми, и являются ли описания предоставленных примеров подробными. Только простое изображение и текстовое описание без примеров. пользователя Выглядит как простая копия интерфейса программы,Для пользователей,Не очень полезно.

Качество печати и упаковки: в основном для проверки степени коммерциализации программных документов. какое-то Руководство user просто распечатывается и переплетается, но он слишком груб и его сложно сохранить. Отличная документация, такая как Руководство пользовательские и технические документы,Должна быть предоставлена ​​коммерческая упаковка.,И красиво напечатано.

В чем разница между тестированием конфигурации и тестированием совместимости?

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

Основное содержание тестирования конфигурации заключается в использовании различного оборудования для проверки работы программного обеспечения, которое обычно включает в себя:

(1) Как программное обеспечение работает на разных хостах, например Dell и Apple;

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

(3) Различные периферийные устройства;

(4) Различные интерфейсы;

(5) Различные опции, например, разные размеры памяти;

Основное содержание тестирования совместимости:

(1) Проверьте, совместимо ли программное обеспечение с различными платформами операционных систем;

(2) Проверьте, совместимо ли программное обеспечение с разными версиями одной и той же платформы операционной системы;

(3) Является ли само программное обеспечение прямой или обратной совместимостью;

(4) Совместимо ли тестовое программное обеспечение с другим сопутствующим программным обеспечением;

(5) Тестирование совместимости данных, в основном относится к возможности совместного использования данных;

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

Что в основном включает в себя тестирование документации программного обеспечения?

Поскольку системы документации программного обеспечения становятся все более большими, тестирование документов стало важной частью тестирования программного обеспечения. Основными объектами тестирования документов являются:

-Пакет текста и графики;

-Маркетинговые материалы, реклама и другие вставки;

-авторизация и регистрационная форма;

-Лицензионное соглашение с конечным пользователем；

-Мастер установки и настройки;

-Руководство пользователя；

-Онлайн-помощь；

-Образцы, демонстрационные примеры и шаблоны;

-……

Целью тестирования документации является повышение простоты использования и надежности, а также снижение затрат на поддержку, поскольку пользователи могут самостоятельно решать проблемы с помощью документации. Основное содержание проверки документов заключается в следующем:

-Цель читателя – главным образом, может ли содержание документа быть понято читателями этого уровня;

-Терминология – главным образом для проверки того, подходит ли терминология читателям;

-Содержимое и тема - проверьте, подходит ли тема, отсутствует ли она, стандартизирован ли формат и т.д.;

- Значки и снимки экрана – проверяйте графики на точность и точность;

- Образцы и примеры – соответствуют ли они функциональности программного обеспечения;

-Орфография и грамматика;

-Релевантность документа – соответствует ли он содержанию других сопутствующих документов, например, соответствует ли он рекламной информации;

Документирование – очень важная задача,Мы должны уделять пристальное внимание не только,Что еще более важно, мы должны завершить это серьезно.,Нравится делать Функциональное Сейчас обработаю документ тестом.

Можно ли провести тестирование методом «черного ящика» без документов технических условий и требований к продукции?

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

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

##3 В чем «странность пестицидов» при тестировании? Термин «странность пестицида» был предложен Борисом Бейзером во втором издании «Технологии тестирования программного обеспечения» под его редакцией. Используется для описания явления, заключающегося в том, что чем больше тестов тестировщик выполняет на одном и том же тестовом объекте, тем меньше дефектов обнаруживается. Точно так же, как если вы продолжите использовать пестициды, вредители станут невосприимчивы, и пестицид перестанет быть эффективным. Основная причина этого явления заключается в том, что тестировщики слишком хорошо знакомы с тестовым программным обеспечением и у них сформировалось фиксированное мышление.

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

Как при тестировании конфигурации определить, является ли обнаруженный дефект общей проблемой или конкретной проблемой конфигурации?

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

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

Можно ли полностью протестировать программу?

Новички в тестировании программного обеспечения могут подумать, что после получения программного обеспечения им необходимо провести полное тестирование, чтобы найти все дефекты программного обеспечения, чтобы программное обеспечение можно было выпустить с «нулевыми дефектами». На практике полное тестирование невозможно. В основном причина одна:

- Полное тестирование трудоемко и время не позволяет;

- Полное тестирование обычно означает больше инвестиций в ресурсы, что в действительности зачастую неосуществимо;

-Объем ввода слишком велик и не может быть проверен по одному;

-Выходных результатов слишком много, и их можно классифицировать только для проверки;

-Существует слишком много способов реализации программного обеспечения;

- Не существует объективного стандарта для спецификаций программного продукта. С разных точек зрения стандарты дефектов программного обеспечения различны;

Поэтому объем тестирования должен определяться исходя из реальной ситуации.

Каковы основные риски тестирования программного обеспечения?

Не тестируя программное обеспечение полностью, мы фактически выбираем риск, поскольку дефекты, скорее всего, будут существовать в тех частях, которые не были протестированы. Например, для удобства программистов при отладке программы всплывают некоторые окна с подсказками, и эти подсказки появляются только при определенных условиях. Бывает, что некоторые из этих кодов не были закомментированы до выпуска программы. Инженер-испытатель не проверял его во время испытания. Если клиент столкнется с этим дефектом, это будет дорогостоящим дефектом, поскольку он не будет обнаружен до момента доставки.

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

Означает ли большее количество обнаруженных дефектов, что в программном обеспечении больше дефектов?

Это относительно распространенное явление. Инженеры-испытатели ломают голову, прежде чем найти дефект, но, обнаружив один, они обнаруживают множество дефектов один за другим, что дает им чувство личного достижения. Основные причины заключаются в следующем:

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

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

«Дефекты один за другим» — это не объективная закономерность, а обычное явление. Если бы программное обеспечение было написано лучше, это явление было бы менее распространенным. Тестировщикам необходимо только серьезно следовать процедурам тестирования.

Можно ли исправить все дефекты программного обеспечения? Все ли дефекты программного обеспечения необходимо устранять?

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

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

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

-Дефекты, которые не являются дефектами. Мы часто сталкиваемся с определенными функциональными проблемами, которые рассматриваются как дефекты. Такие проблемы можно рассмотреть и решить позже, когда у нас будет время.

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

Являются ли тестировщики программного обеспечения контролем качества?

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

Тестирование программного обеспечения и качество дополняют друг друга, и оба работают на улучшение качества программного обеспечения.

Как сократить потери от смены работы тестировщиками?

Смена работы — распространенное явление в ИТ-индустрии, и смена работы принесет определенные потери как компании, так и отдельному человеку. Команда тестирования, несомненно, столкнется с угрозой смены работы. Будучи менеджером по тестированию, вы можете минимизировать потери, только начав свою повседневную работу. Рекомендуется начать со следующих двух аспектов:

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

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

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

1、 базовый Функциональное тестирование： Функция копирования и вставки файлов, прежде всего, ключевого слова «файл», файлы имеют разные категории (изображения, видео, аудио, документы и т. д.), и каждая категория имеет разные типы (тип документа: txt doc execl pdf и т. д.), каждый файл имеет разный размер и у файла много разрешений. Он скрыт? Может ли он выполняться только администратором? Выбирайте файлы разных типов и размеров в разных категориях в качестве тестовых ресурсов. Например: txt файлы по типу документа можно разделить на Текстовый файл размером 1 КБ, текстовый файл 1 МБ, текстовый файл 1 ГБ. . . . следующее ключевое слово скопировать и вставить Есть много способов копирования Щелкните правой кнопкой мыши, чтобы выбрать, Ctrl+C, Существуют различные способы перетаскивания, копирования и вставки. Потом скопировать откуда и вставить куда, например Он может иметь локальный жесткий диск, мобильный жесткий диск, USB-накопитель, карту памяти, дискету, компакт-диск, подключать хранилище мобильного телефона, копировать на сетевой адрес и т. д. скопировать и вставить Окончательный файл Нетдоступен,Права доступа к файлам Нетдаиметьизменять。копироватьпрошлые мощности Нетдостаточночто делать？копировать Послеиметь Файл с повторяющимся именемчто делать？копировать Отмена в процессе、Неисправность、тянутьUSB-накопительчто делать？копироватьэнергия процесса Нетисполняемый файл？

2. Каковы функциональные характеристики Тестирования производительности: скопировать и вставить? Приемлема ли скорость копирования файла? Можно ли обрабатывать несколько файлов одновременно? Процесс обработки файла занимает много ресурсов процессора и потребляет много энергии?

3. Тест на совместимость: поддерживают ли эту функцию Windows XP, Windows 7, Windows 8, Windows 8.1, Windows 10 и другие версии Windows?

4. Интерактивное тестирование; скопировать и вставить файл,Затрагиваются ли другие функции использования хранилища Windows? Например, имеет ли какое-либо влияние воспроизведение локальных аудио, видео и т. д. файлов? сторона копировать,Будет ли это иметь какое-либо влияние, если его наклеить с одной стороны?

Стабильность вставки: изменится ли размер после вставки, изменится ли формат контента, не удастся ли вставить, будет ли скопированный контент по-прежнему найден после ошибки и т. д.

Безопасность вставки: будет ли вставленный контент просочиться в другое место после вставки?

2.Тестирование производительности：（1）время：скопировать и Ответ на вставитьвремя? Время отображения страницы? (2) Загрузка: несколько раз просмотреть, выполнить скопировать и вставитьда否иметьаномальный？скопировать и вставить Можно ли допустить один или несколько файлов большого размера? (3) Прочность: При условии обеспечения достаточной мощности, соответственно скопировать и вставить50ГБ, 100ГБ, 500ГБ,... размер файлов, посмотреть, когда происходит сбой, производительность после сбоя, можно ли вернуться в норму скопировать и вставить50G? (4) Емкость: существует непрерывное копирование при различных условиях ресурсов ЦП. и вставить5 минут, до скопировать и вставить Какую емкость занимает файл?

5. Соответствует ли интерфейс отображения индикатора выполнения стилю дизайна системы? Есть ли текстовые ошибки в интерфейсе дисплея? Разумно ли расположение интерфейса дисплея? Доступны ли кнопки в интерфейсе (например, есть ли возможность прервать работу? Доступно ли свертывание?)

6. Тест локализации: отображение в разных языковых средах нормальное

7. Вспомогательный тест: может ли дисплей работать нормально при высокой контрастности?

Связь：https://www.nowcoder.com/questionTerminal/ad274cafadf64222bb8805df45828741?orderByHotValue=1&pos=3 Источник: Niuke.com

1 、скопировать и вставитьметод

Тест сочетания клавиш: проверьте Ctrl+C, чтобы убедиться, что копирование выполняется правильно, и Ctrl+v, чтобы проверить, поддерживает ли он функцию вставки.

Тест правой кнопкой мыши: проверьте, правильно ли выполняется функция скопировать и вставить;

существовать cmd Использование скопировать из командной строки и вставить Заказ；

2. Проверка размера файла

Исходный файл пустой, 0 байт;

Исходный файл имеет нормальный размер;

Исходный файл очень большой: **G/ и т. д.;

3. Формат файла

Нормально ли это в различных форматах файлов скопировать и вставить: Такие как: картинки, звуки, видео, сжатые файлы, офисные файлы: word\excel\ppt и т. д., двоичные файлы;

Проверка общих файлов и скрытых файлов

4. Скопируйте и вставьте путь к файлу.

существоватьсистема Нет По тому же пути к файлускопировать и вставить,

Относительный путь и абсолютный путь к файлу скопировать и вставить;

папку test и еще одну другую папку скопировать и вставить;

Тестирование между разными дисками C\D\E;

тестскопировать и вставитьTo: мобильный жесткий диск, U диски, кард-ридеры и другие внешние устройства хранения данных;

5. Аномальное тестирование

Проверка поврежденных файлов, неполных имен файлов, файлов, копирование и вставка которых запрещены, файлов, размер которых превышает указанный и т. д.;

Проверьте, следует ли запрашивать замену или перезапись файлов с тем же именем;

6. Совместимость

Тестируйте разные операционные системы и разные приложения (например, QQ);

7 、Тестирование производительности：

тестскопировать и вставить Максимальный поддерживаемый размер файла;скопировать и вставить соответствующую скорость работы、Выполнение завершеновремя；

Поддерживает одновременную работу с файлами разных форматов;

Поддержка большого количества файлов одновременно скопировать и вставить;

Дизайн тестового примера интерфейса входа в систему

один,интерфейстестточка：

1. Соответствует ли стиль дизайна интерфейса стилю дизайна пользовательского интерфейса;

2. Текст в интерфейсе лаконичный и понятный;

3. В интерфейсе нет опечаток;

два, имя пользователя и пароль существуют При входе учитывайте:

1. Правильное имя пользователя и правильный пароль;

2. Правильное имя пользователя и неправильный пароль;

3. Неверное имя пользователя и правильный пароль;

4. Неверное имя пользователя и неправильный пароль;

5. Пустое имя пользователя и пустой пароль;

6. Правильное имя пользователя и пустой пароль;

7. Пустое имя пользователя и правильный пароль;

8. До/в/после имени пользователя есть пробелы;

9. До/в/после пароля есть пробелы;

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

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

три,Тестирование безопасности：

1. Скрыт и отображается ли пароль;

3. Если вы не можете ввести его напрямую, просто скопируйте его, чтобы проверить, нет ли ошибки при проверке данных;

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

Четыре,совместимостьтест：

  1. Тестирование разных браузеров
  2. Тестирование различных версий браузера

пять,другойтестточка：

1. Проверьте, поддерживается ли клавиша табуляции между полями ввода;

2. Кнопка входа в систему должна учитывать, поддерживается ли клавиша Enter;

3. Позиция по умолчанию после отмены (обычно пустое поле ввода имени пользователя);

4. Правильна ли страница перехода после входа в систему (обычно домашняя страница);

5. Рассмотрим реакцию интерфейса на многократное нажатие кнопок входа и отмены;

6. Рассмотрите возможность существования нескольких пользователей, входящих в систему на одной машине;

7. Предположим, что один пользователь осуществляет вход на несколько компьютеров;

8. Правильно ли указаны регистрация и другие ссылки на странице входа?

Издатель: Лидер стека программистов полного стека, укажите источник для перепечатки: https://javaforall.cn/129071.html Исходная ссылка: https://javaforall.cn