Тестовые данные для excel - Word и Excel - помощь в работе с программами

Excel-тестирования и задания

Примеры заданий для проверки уровня владения MS Excel

Здесь Вы можете бесплатно скачать файлы и выполнить задания. Отличная тренировка и возможность проверить свои навыки.

New! 1. Пример Excel-заданий для прохождения собеседования (Sales Analyst)

РЕШЕНИЕ ЗАДАНИЙ. Скачайте файл с решениями и посмотрите видеоразбор ниже.

2. Пример Excel-заданий в зарубежную компанию (аналитик)

2. РЕШЕНИЕ ЗАДАНИЙ. Скачайте файл с решениями и посмотрите видеоразбор ниже.

3. Пример Excel-заданий в FMCG-компанию

3. РЕШЕНИЕ ЗАДАНИЙ. Скачайте файл с решениями и проверьте себя.

На эту страницу будут добавляться новые файлы и задания.
Разборы заданий я буду публиковать в моем блоге @valeriarti и на YouTube — канале Artis Academy.

Источник

Генерация автоматических тестов: Excel, XML, XSLT, далее — везде

Есть определенная функциональная область приложения: некая экспертная система, анализирующая состояние данных, и выдающая результат — множество рекомендаций на базе набора правил. Компоненты системы покрыты определенным набором юнит-тестов, но основная «магия» заключается в выполнении правил. Набор правил определен заказчиком на стадии проекта, конфигурация выполнена.
Более того, поскольку после первоначальной приемки (это было долго и сложно — потому, что “вручную») в правила экспертной системы регулярно вносятся изменения по требованию заказчика. При этом, очевидно, неплохо — бы проводить регрессионное тестирование системы, чтобы убедиться, что остальные правила все еще работают корректно и никаких побочных эффектов последние изменения не внесли.

Основная сложность заключается даже не в подготовке сценариев — они есть, а в их выполнении. При выполнении сценариев “вручную», примерно 99% времени и усилий уходит на подготовку тестовых данных в приложении. Время исполнения правил экспертной системой и последующего анализа выдаваемого результата — незначительно по сравнению с подготовительной частью. Сложность выполнения тестов, как известно, серьезный негативный фактор, порождающий недоверие со стороны заказчика, и влияющий на развитие системы («Изменишь что-то, а потом тестировать еще прийдется… Ну его. »).

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

Под катом будет рассказано об одном подходе, реализующим данную идею — с использованием MS Excel, XML и XSLT преобразований.

Тест — это прежде всего данные

А где проще всего готовить данные, особенно неподготовленному пользователю? В таблицах. Значит, прежде всего — в MS Excel.

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

Итак, постановка задачи

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

Решение

Пара дополнительных вводных:

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

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

Итак, архитектура решения:

Преобразовать данные из Excel в XML определённого формата
Преобразовать XML с помощью XSLT в финальный код тестового скрипта на произвольном языке программирования

Этап 1. Ведение данных в Excel

Здесь, честно говоря, я ограничился ведением данных в виде табличных блоков. Фрагмент файла — на картинке.

Блок начинается со строки, содержащей название блока (ячейка “A5″). Оно будет использовано в качестве имени xml-элемента, так что содержание должно соответствовать требованиям. В той же строе может присутствовать необязательный “тип” (ячейка “B5″) — он будет использовано в качестве значения атрибута, так что тоже имеет ограничения.
Каждая колонка таблицы содержит помимо “официального” названия, представляющего бизнес-термины (строка 8), еще два поля для “типа” (строка 6) и “технического названия” (строка 7). В процессе подготовки данных технические поля можно скрывать, но во время генерации кода использоваться будут именно они.
Колонок в таблице может быть сколько угодно. Скрипт завершает обработку колонок как только встретит колонку с пустым значением “тип” (колонка D).
Колонки со “типом”, начинающимся с нижнего подчеркивания — пропускаются.
Таблица обрабатывается до тех пор, пока не встретиться строка с пустым значением в первой колонке (ячейка “A11”)
Скрипт останавливается после 3 пустых строк.

Этап 2. Excel -> XML

Преобразование данных с листов Excel в XML — несложная задача. Преобразование производится с помощью кода на VBA. Тут могут быть варианты, но мне так показалось проще и быстрее всего.

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

Код представлен в виде Excel add-in (.xlam) — для упрощения поддержки кода, когда количество файлов с тестовыми данными более 1 и эти файлы создаются/поддерживаются более чем одним человеком. Кроме того — это соответствует подходу разделения кода и данных;

Этап 3. XML -> Code

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

Начальная итерация начинается по элементам, представляющим листы (различные тестовые сценарии). Здесь можно размещать блоки setup / teardown, утилит;

Финальный комментарий

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

Заключение

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

В нашем проекте удалось довольно быстро создать набор тестовых сценариев для интеграционного тестирования сложной функциональной области — всего на данный момент около 60 файлов, генерируемых примерно в 180 тестовых классов tSQLt (фреймворк для тестирования логики на стороне MS SQL Server). В планах — использовать подход для расширения тестирования этой и других функциональных областей проекта.

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

Код VBA для преобразования Excel файлов в XML и запуска преобразования (вместе с примером Excel и XML) можно взять на GitHub github.com/serhit/TestDataGenerator.

Преобразование XSLT не включено в репозиторий, поскольку оно генерит код для конкретной задачи — у вас все равно будет свой. Буду рад комментариям и pull request’ам.

Проектирование тестов в среде MS Excel и VBA

Если ваши ученики освоили в Excel представление и обработку данных, то можно переходить на качественно новый уровень работы с Excel – автоматизировать свою работу. Язык VBA (Visual Basic for Application) – язык программирования, который подходит для всех приложений Microsoft Office, это один из самых простых в изучении и применении языков, он является версией языка Visual Basic.

Предлагаю задания для создания проектов в виде тестов в среде MS Excel и VBA.

Откройте Excel.
Переименуйте Лист1 в Вопросник и составьте таблицу.

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

Пользовательские формы могут иметь вид:

UserForm1

UserForm2

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

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

Темы проектов:

1. Подобрать тест, обработать его, результаты показать через пользовательскую форму.

2. Вопросник по любому предмету, результаты которого обработать в Excel и выдать через пользовательскую форму оценку:

Данная работа является контрольно-обучающим пособием по теме «Практическое применение табличного электронного редактора EXCEL », а именно создание интерактивных тестов.

Работу можно использовать на уроках информатики в 9-11 классах технического профиля, а также для пользователей начинающего уровня.

Microsoft Excel — программа для работы с электронными таблицами, созданная корпорацией Microsoft для Microsoft Windows, Windows NT и Mac OS. Она предоставляет возможности экономико — статистических расчетов, графические инструменты и, за исключением Excel 2008 под Mac OS X, язык макропрограммирования VBA (Visual Basic для приложений). Microsoft Excel входит в состав Microsoft Office и на сегодняшний день Excel является одним из наиболее популярных приложений в мире.

Также в Microsoft Excel можно создавать интерактивные тесты с помощью стандартных функций или макросов.

Создание интерактивных тестов в программе MS Excel.

(инструкция для изучения возможностей и применения MS Excel по созданию интерактивных тестов для учащихся старших классов)

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

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

Для создания таких тестов не требуется специального программного обеспечения. Пакет MS Office (Excel в частности) имеется на каждом персональном компьютере. Этим объясняется доступность предлагаемой информации.

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

Основные сведения по MS Excel

Для создания теста необходимо знать несколько особенностей программы MS Excel, на которые имеются ссылки в данной разработке.

Перечень команд, которые управляют работой Excel, находится в основном меню (рис.1,1) Здесь Вы найдете команду Вставка, Данные, Сервис.

Пункты основного меню содержат раскрывающийся список команд, открыть который можно щелкнув левой кнопкой мыши на пункте меню. Так Вы найдете команды Проверка (пункта меню Данные), Лист (пункта меню Вставка), Макрос (пункта меню Сервис).

Каждая ячейка Excel имеет уникальный адрес, состоящий из названия столбца и строки (рис.1,2).

Столбцы таблицы Excel обозначаются латинскими буквами (рис.1,3), строки цифрами (рис.1,4). Обратите внимание, если будете вводить формулы с клавиатуры.

Формулы вводим в строку формул (рис.1,5), начиная со знака = (равенства).

Для создания фигуры к тесту воспользуемся панелью инструментов Рисование (находится в нижней части окна Excel), либо пунктом меню Вставка-Рисунок-Автофигуры

Источник

Smartsheet Contributor

Kate Eby

January 25, 2019

In this article, you’ll find the most useful free, downloadable test case templates in Microsoft Excel and PDF formats. Learn how to use these templates to review and verify certain features and functions of an application, software, a trial, or a test and update those features and functions based on test results.

In this article

Test Case Planning and Execution Template
Test Case Point Estimate Template
Manual Testing Test Case Template
Automation Testing Test Case Template
User Acceptance Testing Test Case Template
SQL Server Integration Services Testing Test Case Template
What Is a Test Case Document?
What Is the Purpose of a Test Case?
What Are the Components of a Test Case?
What Is the Difference between a Test Case and a Test Scenario?
Tips to Write, Implement, and Track Test Cases
Test Case Use Cases
Improve Your Test Cases with Free Test Case Templates in Smartsheet

Test Case Planning and Execution Template

Download Test Case Planning and Execution Template

Excel | Word | PDF | Smartsheet

With this complete test case planning and execution template, you can map out test plans for individual components of a project or trial, seamlessly execute tests, and analyze the data that comes from a test. You can also track tests by test ID and name, identify each step of a test, add priority levels and notes, and compare actual versus expected results. This complete testing template is compatible for all tests, from clinical trials to software updates.

Test Case Point Estimate Template

Download Test Case Point Estimate Template

Excel | Smartsheet

Assess the approach needed to test software, determine testing checkpoints and preconditions, and analyze all test results with this comprehensive test case point estimate template. Use this template to rate priorities and complexities based on a high-to-low measure, allocate testing time for each specific step, and determine the amount of work associated with each test.

Manual Testing Test Case Template

Download Manual Testing Test Case Template

Excel | Word | PDF

With this manual testing test case template, you can record testing steps and data, analyze expected results versus actual results, and determine whether or not you can consider a test to be a success. With space to record each individual step of the testing process, the test ID and name, and additional notes to consider during analysis, this template allows you to run through every possible result in a trial and determine if it passed or failed inspection.

Automation Testing Test Case Template

Download Automation Testing Test Case Template

Excel | PDF

Use this automation testing test case template to review the success or failure of an automated software, application, or feature. Document the test name and ID, the test duration, each separate step and component, and any notes about the test, including the parts of the test that are automated. Simply download and fill out this form to fit the needs of whatever automated application you are testing.

User Acceptance Testing Test Case Template

Download User Acceptance Testing Test Case Template

Excel | PDF

With this user acceptance testing (UAT) test case template, test newly designed software to ensure that it matches the designated specifications and meets all user-provided requirements. Track individual applications, the steps to execute them, and both the expected and actual results with this comprehensive testing template.

SQL Server Integration Services Testing Test Case Template

Download SQL Server Integration Services Testing Test Case Template

Excel | PDF

Manage, test, and track all SQL server integration services with this detailed test case template. You can use this SQL test case template to ensure that all programming and data management systems are working correctly and test any updates or quick fixes.

What Is a Test Case Document?

A test case document is a set of steps that a team can execute to test certain scenarios based on the needs of the function, from clinical trials to software updates and even project management changes. Each test case includes a set of preconditions as well as test data, expected results, actual results, and post-conditions that help determine the success or failure of a test.

All steps of a test case are meant to check the functionality and applicability of each test, based on the preconditions and expected results. A test case is considered the smallest unit of a testing plan and contributes to the overall test script or user story.

To begin a test case, one must first describe the actions and parameters they mean to achieve, verify, or challenge regarding any expected behavior of a test. There are sets of conditions and variables that the tester uses to determine the quality and success of a system, trial, feature, or software, and the end results can confirm these facts.

What Is the Purpose of a Test Case?

A test case can help you easily identify any problems, unplanned issues, or missed details in a project, update, or trial. Additionally, test cases provide the following benefits for the individuals or teams who carry them out:

Minimize ad-hoc testing
Make manual test case management easier and more streamlined
Save valuable time when testing and analyzing results
Enable testers to develop individual test cases for specific scenarios
Verify the success of updates or changes
Make it easier to share results with stakeholders and gain buy-in from all involved parties
Lessen the effort and error rate involved in testing
Define and flesh out all positive and negative test results or behavior
Divide tests into positive and negative segments
Eliminate the number of bugs or errors in an end product
Communicate all specific conditions from the start in order to eliminate confusion
Keep management updated on the quality status of a test
Help testers generate detailed summaries and reports on test status, defects, bugs, etc.
Track productivity and trace all problems back to the source
Help testers write and report on more comprehensive test case results

What Are the Components of a Test Case?

A test case is comprised of many different components: It assesses what is being tested, the expected results of a test, and the process involved in testing each specified element of a case.

In general, test cases should include the following:

Test Process: This includes the test review and approval, the test execution plan, the test report process, use cases (if applicable), and performance risks.
Positive and Negative Tests: Positive tests should help check whether the functionality is performing correctly, while negative tests should check every reverse situation where an error or issue could occur.
Test Case ID: This helps you correctly and uniformly document each test case and its corresponding results; it also helps you avoid retesting the same things.
Test Scenario: This includes all the information about a test in the form of specific, detailed objectives that will help a tester perform a test accurately. It will not, however, include specific steps or sequences.
Test Steps: The steps should tell a tester, in detail, exactly what they should do during each step, including specific objectives.
Test Data: This section includes all the information and data that a test collects throughout the duration of the process.
Expected Results: This includes any detailed and precise information or data that a tester should expect to see and gather from a test.
Actual Results: This includes all positive and negative results that you receive from a test and that help you confirm or reject the expected results and detect any issues or bugs.
Confirmation: This is the part of the process during which testers discuss and review whether or not a test was a success or a failure, based on the results.

What Is the Difference between a Test Case and a Test Scenario?

Although they may seem quite similar, test cases and test scenarios are two very different aspects involved in testing the functionality of a new software, update, or process. Test cases are specific conditions under which a new functionality is tested, whereas a test scenario is the overall end-to-end functionality of an application when it is working correctly.

Test cases are usually lower-level actions that can be created or derived from test scenarios. They give information about preconditions, what is being tested, how the test will be carried out, and the expected results.

Test cases require detailed documentation in order to assess how a test is proceeding, and a test case verifies the output of a function.

On the other hand, test scenarios are made up of test procedures, which encompass many test cases. Test scenarios are generally considered to be higher level and include groups of test cases, depending on the following factors: the functionality being tested, the type of test being performed, and the duration of the test.

Overall, test scenarios help reduce the complexity and confusion involved in creating a new product or updating a new function.

Tips to Write, Implement, and Track Test Cases

In order to gain the most from the tests you are running, you must create comprehensive, detailed, and test-specific test cases that describe exactly what is being tested, why it is being tested, and what the expected results should be.

To run the most effective test cases and gain powerful, actionable insights, follow these simple tips:

Make the test steps as clear as possible, avoiding vague objectives and directions.
Ensure that the test has no more than 15 steps to avoid confusion. If there are more than 15 steps, break the test into separate tests.
In the test directions, include any additional documents or references that might be relevant to the test itself.
Include a detailed description of the requirement being tested, and explain in detail how the test should be carried out for each requirement.
Provide details on all the expected results, so the tester can compare the actual results against them. Of course, this step is unnecessary if the expected results are obvious.
Use active case language when writing the steps, and make sure they are as simple and clear as possible.
Avoid repeating any of the same steps, as this could add confusion to an already complicated process.
Include the test name and ID in the testing instructions.
Keep the end user in mind as you develop the test and its variables.
Reread and peer review the test case instructions before finalizing them.
Remember that the test case should be repeatable, traceable, and accurate.

Test Case Use Cases

You can leverage test cases for a variety of purposes: to gain insight into how processes are performing; to determine how software updates are being used; and to figure out how business trials or tests are progressing.

Some of the most common use cases for test cases include the following:

Confirming login functionality on a username and password combination
Checking to see how the login function reacts to a valid or invalid username or password
Seeing what happens when someone inputs an empty response for either the username or password component

Numerous companies, such as HP Quality Center and Jira, use test cases to track and update their processes.

Improve Your Test Cases with Free Test Case Templates in Smartsheet

Empower your people to go above and beyond with a flexible platform designed to match the needs of your team — and adapt as those needs change.

The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed.

When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time. Try Smartsheet for free, today.

Источник

Полная «режиссерская» версия доклада, сделанного SQA Days 2008

Автор: Сергей Талалаев

Оригинальная публикация

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

1. Предыстория

1.1 Автоматизация: от эйфории до созерцания

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

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

В нашем случае ситуация оказалась настолько запущенной, что было принято решении отказаться от существующих скриптов такого вида и написании их с нуля в строгом соответствии с оговоренными правилами которые впоследствии оформились в документ под названием “Test scriprting guideline”.

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

1.2 Проблема больших чисел

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

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

Количество скриптов : Время затрачиваемое на их поддержку

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

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

Унификация структуры скриптов (с последующим документированием этой структуры)
Вынос общих бизнес-функций в библиотеки/классы
Использование внешних источников данных

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

1.3 Идентификация проблемы.

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

Основным требованием предъявляемым со стороны тестовой команды (а здесь мы имеем ввиду именно функциональных тестировщиков) является простота создания и поддержки тестовых данных и отсутствие необходимости изучения каких-либо узкоспециализированных инструментов и сложных техник.

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

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

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

2. Стандартные решения – достоинства и недостатки

2.1 Реализация внутренних хранилищ в семействах продуктов IBM Rational

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

Из положительных сторон можно отметить:

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

Из минусов:

неудобство редактирования данных
отсутствие возможности группировки данных

2.2 Реализация внутренних хранилищ в семействах продуктов HP Mercury

В качестве встроенного хранилища данных в семействе продуктов HP Mercury используются стандартные Excel файлы.

Из положительных сторон можно отметить:

удобство редактирования
родная поддержка на уровне скрипта

Из минусов:

при редактировании через встроенный редактор из файла удалятся всё форматирование
отсутствие возможности группировки данных

2.3 Другие варианты хранения данных

CVS файлы

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

XML файлы

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

3. Поиск компромисса

3.1 Почему Excel?

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

3.2 Хитрости и трюки

Для того чтобы получить видимые для ODBC таблицы в Excel- файле вы должны определенным образом разметить интересующие вас подмножества ячеек. Для этой цели служит функциональность называемая Names (именованные диапазоны). Создать именованный диапазон можно через “Define name” диалог (Insert > Name > Define) или через Formulas > Define Name в 2007-ом офисе.

После такого выделения ваши имена становятся доступны как таблицы для ODBC драйвера. Для проверки того что диапазон задан верно необходимо выделить помеченные ячейки и в Navigation bar должно отбразиться заданное имя.

3.3 «Ложка дегтя»: ограничения использования

Конечно все это было бы слишком хорошо если бы не было каких-либо ограничивающих факторов и они к сожалению есть:

мы не сможем использовать наши тестовые данные для нагрузочных тестов как например в случае использования “родных” хранилищ Rational;
у нас не будет возможности запускать наши тесты в многоплатформенной среде даже если сама тестовая платформа это позволяет.

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

4. Из личного опыта: «Датадривен – это просто»

4.1 Задача: разработать автоматические тесты с возможностью кастомизации без изменения кода.

Кастомизация предполагалась следующая:

скрипты должны были выполнятся как в рамках Smoke тестов так и в рамках основного цикла тестирования
существовала необходимость использовать скрипты в том числе для загрузки некоторых специфичных начальных тестовых данных с UI (общесистемные данные грузились напрямую в БД на этапе сборки билда)

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

4.2 Вариант решения

Использование property файлов для группы скриптов, в которых для каждого скрипта задаются его тестовые данные (в нашем случае имя Excel файла)
На уровне самого скрипта задался набор данных по умолчанию, который позволял запускать скрипты без параметров
На уровне property файлов также была возможность отключить отработку точек проверки

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

4.3 Анализ полученного результата

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

Из минусов можно отметить следующий момент. Так как фреймворк реализовывался на обычном процедуральном языке (расширение VB) то все сервисные механизмы по работе с property файлами должны были присутствовать на уровне скриптов. И хотя реального кода там было не более 10 строк тем не менее это захламляло скрипт.
Дальнейшая реализация такого же подхода в рамках OO-языка (Functional Tester + Java) показала насколько эффективно сервисный код может быть скрыт на верхнем уровне иерархии.

5.1 Возможность использования Excel в качестве источника XML-данных

Начиная с 2003-ей версии офиса в Excel появилась возможность интеграции с XML, причем как в сторону загрузки данных в Excel таблицы так и в сторону экспорта табличных данных в XML файл. Эта функциональность (называемая в офисе 2003 Lists а в 2007 – Tables) добавила еще больше гибкости в процедуру подготовки тестовых данных. Теперь появилась возможность оперировать с текстовыми данными практически любого вида. Единственно, что требуется дополнительно реализовать — это XSLT преобразование из полученного в процесе экспорта XML файла к требуемому для приложения виду.

5.2 Варианты применения

Лежащий на поверхности путь преобразования – это подготовка прямых SQL операторов для прямой заливки данных в базу. Кроме того могут понадобиться какие-либо специфичные форматы данных в основе которых лежат табличные данные (например, данные для Web- сервисов).

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

6. Из личного опыта: «Пойди туда, не знаю куда – найди то, не знаю что»

6.1 Задача: протестировать процедуру миграции БД

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

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

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

6.2 Вариант решения

Вот тут как нельзя кстати пригодилась новая функциональность Excel позволяющая выгружать данные в XML.

Мы сначала подготовили данные для понятных нам тестовых случаев и согласно предполагаемой структуре сделали прослойку для генерации скриптов (то есть приготовили набор XSL файлов необходимый для конвертации выгружаемых XML в требуемый нам формат).

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

6.3 Анализ полученного результата

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

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

7. Из личного опыта: «Хотели бы помочь, но по-своему»

7.1 Задача: получить тестовые данные для проведения UAT от заказчика

В ходе работ по ”оживлению” старого демо-приложения выяснилось, что мы не можем убедиться в корректности работы функциональности отчетов в восстановленном функционале из-за полного отсутствия документации на эту часть приложения. Заказчик воспринял ситуацию адекватно и предложил свою помощь в разрешении проблемы, а именно предложил нам взять на себя подготовкку тестовых данных для этой части функционала. Наша радость к сожалению была очень недолгой, когда мы увидели в каком виде к нам начали приходить эти данные. Ни о какой организованной струтуре речи ни шло. Данные для полей с ограниченным набором списковых значений например могли отличаться от набора к набору ( как пример в одном наборе период назывался “semi-annual”, а в другом – “Semi annual”). Мы пришли к выводу, что на вычистку таких данных уйдет больше времени, если они не будут жестко следовать предопределенному формату.

7.2 Вариант решения

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

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

В дальнейшем предполагалось использовать механизм выгрузки подготовленных данных в XML формат и конвертацию полученных XML файлов в последовательность SQL-операторов для загрузки данных напрямую в БД.

7.3 Анализ полученного результата

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

Обсудить в форуме

Источник

Содержание

Test Case Template – Download Excel & Word Sample Format
What is Test Case Template?
Test Case Template for Excel and Word
Образец шаблона теста
Шаблон тестового примера
Free Test Case Templates
Test Case Planning and Execution Template
Test Case Point Estimate Template
Manual Testing Test Case Template
Automation Testing Test Case Template
User Acceptance Testing Test Case Template
SQL Server Integration Services Testing Test Case Template
What Is a Test Case Document?
What Is the Purpose of a Test Case?
What Are the Components of a Test Case?
What Is the Difference between a Test Case and a Test Scenario?
Tips to Write, Implement, and Track Test Cases
Test Case Use Cases
Improve Your Test Cases with Free Test Case Templates in Smartsheet

Test Case Template – Download Excel & Word Sample Format

Updated March 4, 2023

What is Test Case Template?

A Test Case Template is a well-designed document for developing and better understanding of the test case data for a particular test case scenario. A good Test Case template maintains test artifact consistency for the test team and makes it easy for all stakeholders to understand the test cases. Writing test case in a standard format lessen the test effort and the error rate. Test cases format are more desirable in case if you are reviewing test case from experts.

The template chosen for your project depends on your test policy. Many organizations create test cases in Microsoft Excel while some in Microsoft Word. Some even use test management tools like HP ALM to document their test cases.

Click Below to download Test Case XLS

Irrespective of the test case documentation method chosen, any good test case template must have the following fields

Test Case Field	Description
Test case ID:	Each test case should be represented by a unique ID. To indicate test types follow some convention like “TC_UI_1” indicating “User Interface Test Case#1.”
Test Priority:	It is useful while executing the test.

Low
Medium
High

Name of the Module: Determine the name of the main module or sub-module being tested Test Designed by: Tester’s Name Date of test designed: Date when test was designed Test Executed by: Who executed the test- tester Date of the Test Execution: Date when test needs to be executed Name or Test Title: Title of the test case Description/Summary of Test: Determine the summary or test purpose in brief Pre-condition: Any requirement that needs to be done before execution of this test case. To execute this test case list all pre-conditions Dependencies: Determine any dependencies on test requirements or other test cases Test Steps: Mention all the test steps in detail and write in the order in which it requires to be executed. While writing test steps ensure that you provide as much detail as you can Test Data: Use of test data as an input for the test case. Deliver different data sets with precise values to be used as an input Expected Results: Mention the expected result including error or message that should appear on screen Post-Condition: What would be the state of the system after running the test case? Actual Result: After test execution, actual test result should be filled Status (Fail/Pass): Mark this field as failed, if actual result is not as per the estimated result Notes: If there are some special condition which is left in above field

Link / Defect ID: Include the link for Defect or determine the defect number if test status is fail
Keywords / Test Type: To determine tests based on test types this field can be used. Eg: Usability, functional, business rules, etc.
Requirements: Requirements for which this test case is being written
References / Attachments: It is useful for complicated test scenarios, give the actual path of the document or diagram
Automation ( Yes/No): To track automation status when test cases are automated

Test Case Template for Excel and Word

Click below to download Test Case Excel File

Click below to download Test Case Word File

Источник

Образец шаблона теста

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

Шаблон, выбранный для вашего проекта, зависит от вашей политики тестирования. Многие организации создают контрольные примеры в Microsoft Excel, а некоторые — в Microsoft Word. Некоторые даже используют инструменты управления тестированием, такие как HP ALM, для документирования своих тестовых случаев.

Нажмите ниже, чтобы загрузить Test Case XLS

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

Поле теста	Описание
Идентификатор тестового примера:	Каждый тестовый пример должен быть представлен уникальным идентификатором. Для обозначения типов тестов следуйте некоторому соглашению, например «TC_UI_1», обозначающему «Тестовый пример интерфейса пользователя № 1».
Приоритет теста:	Низкий средний Высокая
Наименование модуля :	Определите имя тестируемого основного модуля или субмодуля.
Тест разработан :	Имя тестера
Дата разработки теста :	Дата, когда был разработан тест
Тест выполнен :	Кто выполнил тест-тестер
Дата проведения теста :	Дата, когда необходимо выполнить тест
Имя или название теста :	Название теста
Описание / Краткое содержание теста :	Определите краткую информацию или цель теста вкратце
Предварительное условие :	Любое требование, которое необходимо выполнить перед выполнением этого контрольного примера. Чтобы выполнить этот контрольный пример, перечислите все предварительные условия
Зависимости :	Определите любые зависимости от требований теста или других тестовых случаев
Тестовые шаги :	Упомяните все этапы тестирования подробно и напишите в том порядке, в котором они должны быть выполнены. При написании тестовых шагов убедитесь, что вы предоставили как можно больше деталей
Тестовые данные :	Использование тестовых данных в качестве входных данных для тестового примера. Предоставить различные наборы данных с точными значениями, которые будут использоваться в качестве входных данных
Ожидаемые результаты :	Укажите ожидаемый результат, включая ошибку или сообщение, которое должно появиться на экране
Постусловие :	Каково будет состояние системы после выполнения контрольного примера?
Фактический результат :	После выполнения теста фактический результат теста должен быть заполнен
Статус (Fail / Pass):	Пометить это поле как несостоявшееся, если фактический результат не соответствует ожидаемому результату
Примечания :	Если есть какие-то особые условия, оставленные в поле выше

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

Ссылка / Дефект ID : Включите ссылку на дефект или определить число дефектов , если статус тестов отказобезо-
Ключевые слова / тип теста : для определения тестов на основе типов тестов можно использовать это поле. Например: юзабилити, функциональность, бизнес-правила и т. Д.
Требования : требования, для которых написан этот контрольный пример
Ссылки / Приложения : Полезно для сложных тестовых сценариев, указывать фактический путь к документу или диаграмме.
Автоматизация (Да / Нет) : для отслеживания состояния автоматизации, когда тесты автоматизированы

Шаблон тестового примера

Нажмите ниже, чтобы скачать тестовый файл Excel

Нажмите ниже, чтобы загрузить тестовый файл Word.

Источник

Free Test Case Templates

January 25, 2019

Test Case Planning and Execution Template

Download Test Case Planning and Execution Template

Test Case Point Estimate Template

Download Test Case Point Estimate Template

Manual Testing Test Case Template

Download Manual Testing Test Case Template

Automation Testing Test Case Template

Download Automation Testing Test Case Template

User Acceptance Testing Test Case Template

Download User Acceptance Testing Test Case Template

SQL Server Integration Services Testing Test Case Template

Download SQL Server Integration Services Testing Test Case Template

What Is a Test Case Document?

What Is the Purpose of a Test Case?

Minimize ad-hoc testing
Make manual test case management easier and more streamlined
Save valuable time when testing and analyzing results
Enable testers to develop individual test cases for specific scenarios
Verify the success of updates or changes
Make it easier to share results with stakeholders and gain buy-in from all involved parties
Lessen the effort and error rate involved in testing
Define and flesh out all positive and negative test results or behavior
Divide tests into positive and negative segments
Eliminate the number of bugs or errors in an end product
Communicate all specific conditions from the start in order to eliminate confusion
Keep management updated on the quality status of a test
Help testers generate detailed summaries and reports on test status, defects, bugs, etc.
Track productivity and trace all problems back to the source
Help testers write and report on more comprehensive test case results

What Are the Components of a Test Case?

A test case is comprised of many different components: It assesses what is being tested, the expected results of a test, and the process involved in testing each specified element of a case.

In general, test cases should include the following:

Test Process: This includes the test review and approval, the test execution plan, the test report process, use cases (if applicable), and performance risks.
Positive and Negative Tests: Positive tests should help check whether the functionality is performing correctly, while negative tests should check every reverse situation where an error or issue could occur.
Test Case ID: This helps you correctly and uniformly document each test case and its corresponding results; it also helps you avoid retesting the same things.
Test Scenario: This includes all the information about a test in the form of specific, detailed objectives that will help a tester perform a test accurately. It will not, however, include specific steps or sequences.
Test Steps: The steps should tell a tester, in detail, exactly what they should do during each step, including specific objectives.
Test Data: This section includes all the information and data that a test collects throughout the duration of the process.
Expected Results: This includes any detailed and precise information or data that a tester should expect to see and gather from a test.
Actual Results: This includes all positive and negative results that you receive from a test and that help you confirm or reject the expected results and detect any issues or bugs.
Confirmation: This is the part of the process during which testers discuss and review whether or not a test was a success or a failure, based on the results.

What Is the Difference between a Test Case and a Test Scenario?

Test cases require detailed documentation in order to assess how a test is proceeding, and a test case verifies the output of a function.

Overall, test scenarios help reduce the complexity and confusion involved in creating a new product or updating a new function.

Tips to Write, Implement, and Track Test Cases

To run the most effective test cases and gain powerful, actionable insights, follow these simple tips:

Make the test steps as clear as possible, avoiding vague objectives and directions.
Ensure that the test has no more than 15 steps to avoid confusion. If there are more than 15 steps, break the test into separate tests.
In the test directions, include any additional documents or references that might be relevant to the test itself.
Include a detailed description of the requirement being tested, and explain in detail how the test should be carried out for each requirement.
Provide details on all the expected results, so the tester can compare the actual results against them. Of course, this step is unnecessary if the expected results are obvious.
Use active case language when writing the steps, and make sure they are as simple and clear as possible.
Avoid repeating any of the same steps, as this could add confusion to an already complicated process.
Include the test name and ID in the testing instructions.
Keep the end user in mind as you develop the test and its variables.
Reread and peer review the test case instructions before finalizing them.
Remember that the test case should be repeatable, traceable, and accurate.

Test Case Use Cases

Some of the most common use cases for test cases include the following:

Confirming login functionality on a username and password combination
Checking to see how the login function reacts to a valid or invalid username or password
Seeing what happens when someone inputs an empty response for either the username or password component

Numerous companies, such as HP Quality Center and Jira, use test cases to track and update their processes.

Improve Your Test Cases with Free Test Case Templates in Smartsheet

Empower your people to go above and beyond with a flexible platform designed to match the needs of your team — and adapt as those needs change.

When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time. Try Smartsheet for free, today.

Источник

Создание
интерактивного теста в Excel

1 этап

1.
Запустите программу MS Excel.

2.
Выполните команду Сервис – Макрос – Безопасность. В
открывшемся диалоговом окне Безопасность во вкладке Уровень
безопасности установите Средняя.

3.
В ячейку D3 введите запись ФИО, а в ячейку D4 – Класс.

2 этап

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

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

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

1)
Выбирается меню Данные.

2)
В ниспадающем меню выбирается команда Проверка.

Рисунок 1

3) В диалоговом окне выбирается тип данных — Список

Рисунок 2

4) В окне Источник

перечисляются варианты ответов
через точку с запятой.

Рисунок 3

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

Рисунок 4

4. Закрепим полученные знания из
п.1. Введите в ячейку E4 списки классов, которые будут проходить тестирование.

Рисунок 5

5. Оформим название теста: Тест по
музыке на тему «Музыкальные термины». В строке 6 оформите заголовки столбцов
теста. В ячейки В7:В16 введите вопросы, а в ячейки С7:С16 введите ответы в
виде списка с выборочными четырьмя ответами, среди которых один правильный.
Лист 1 переименуйте Тест.

Рисунок 6

Создадим макрос,
который очищает поля для возможности тестирования многократно и назначим макрос
кнопке с названием Очистка.

4.
Выполните команду Сервис – Макрос – Начать запись. Дайте
имя макросу Очистка. Выделите все поля с ответами и нажмите клавишу delete.
Также удалите фамилию ученика и класс.

5.
Выполните команду Сервис – Макрос – Остановить запись.

Теперь нарисуем кнопку и назначим ей макрос Очистка.

8.
Выполните команду Вид – Панели инструментов – Формы.

9.
Найдите инструмент Кнопка, активизируйте его (щелкните на
нем) и нарисуйте кнопку на листе, правее ответов (см. Рис.6).

10.
Назначьте ей макрос Очистка.

11.
Сохраните тест.

3 этап

Для подведения итогов
тестирования можно предусмотреть специальный лист, переименовав его в
Результат, на котором будут подведены итоги ответов.

Создадим на листе ответов 5 макросов:

•
Ваш ответ – ученик может увидеть свои ответы

•
Результат – ученик может увидеть, на какие вопросы он ответил
неверно.

•
Верный ответ – ученик может увидеть правильные ответы.

•
Оценка – ученик может увидеть свою оценку.

•
Очистка – для возможности многократного тестирования.

12.
В строки А2 и А3 введите записи ФИО и Класс соответственно.

13.
Скопируйте с первого листа номера вопросов и сами вопросы в
столбцы А6:А15 и В6:В15.

14.
Введите остальные заголовки таблицы, согласно рисунку (Ваш ответ,
Результат, Верный ответ).

Рисунок 7 Создадим
первый макрос – Ваш ответ.

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

15.
Выполните команду Сервис – Макрос – Начать запись. Дайте
имя макросу Ваш_ответ.

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

16.
Установите курсор в ячейку В2, нажмите знак «=», перейдите на
лист вопросов и щелкните мышью в ячейку Е4 (Петров Вася) и нажмите клавишу
«Enter». Аналогично введите класс.

17.
Таким же образом в листе ответов введите в ячейку С6 ответ с
листа вопросов.

18.
Скопируйте остальные варианты ответов: установите курсор в ячейку
С6 и подведите его в правый нижний угол этой ячейки. Когда курсор примет вид
«+», протяните вниз до ячейки С16.

19.
Остановите макрос. Нарисуйте кнопку и назначьте ей макрос Ваш
ответ.

Далее оформляем столбец Результат. Для этого
используем логическую функцию «если».

20.
Создайте второй макрос – Результат. На листе ответов
установите курсор в ячейку D6.

21.
Выполните команду Вставка – Функция (или кнопка fx рядом со строкой формул).

Выберите в категории Логические функцию Если.

22.
Заполните поля согласно Рис 7. Текстовые ответы необходимо
заключать в кавычки.

23.
Аналогичным образом заполните ячейки D7:D10.

24.
Остановите макрос. Нарисуйте кнопку и назначьте ей макрос Результат.

Рисунок 8 Далее оформляем столбец Верный ответ.

25.
Создайте третий макрос – назовите его Ответ1. Установите
курсор в ячейку Е6.

Введите в ячейки E6:E15 верные ответы к вопросам.

26.
Остановите макрос. Нарисуйте кнопку и назначьте ей макрос Верный
ответ.

Далее оформляем столбец
Оценка. Для этого используем логическую функцию «если» и статистическую
функцию «счетесли».

27.
В строки В17 и В18 введите соответственно записи Количество
верных ответов, Количество неверных ответов (см. Рис. 7).

28.
Создайте четвертый макрос – назовите его Оценка.

29.
Установите курсор в ячейку С17. Выполните команду Вставка – Функция
( или кнопка fx рядом со строкой формул). Выберите в
категории Статистические функцию Счетесли.

30.
Выделите на листе ответов диапазон D6:D15.

31.
В строке критерий введите запись «верно» и нажмите кнопку ОК.

Рисунок 9

32.
Аналогичным образом введите количество неверных ответов. Только в
строке критерий введите запись «неверно».

Для выставления оценки используем
функцию «если». Критерии оценивания:

Кол-во верных ответов	Оценка
9-10	5
7-8	4
5-6	3
>4	2

Для Excel эта запись будет выглядеть следующим образом:

ЕСЛИ(C17>8;5;ЕСЛИ(C17>6;4;ЕСЛИ(C17>4;3;2)))

33.
Установите курсор в ячейку С21. Выполните команду Вставка –
Функция (или кнопка fx рядом со строкой формул). Выберите в
категории Логические функцию Если.

34.
После открытия окна Аргументы функции щелкните мышью в
ячейку С17. Ее адрес появится в строке Лог_выражение. Далее введите
записи согласно Рис. 10.

35.
Установите курсор в строку Значение_если_ложь и нажмите на
кнопку ЕСЛИ (рядом со строкой формул) для создания следующего вложения функции
Если.

Рисунок 10

При
каждом последующем открытии окна Аргументы функций нужно вводить записи

Лог_выражение	С17>6	C17>4
Значение_если_истина	4	3
Значение_если_ложь	(здесь нажимаем кнопку ЕСЛИ)	2

36. Остановите макрос.
Нарисуйте кнопку и назначьте ей макрос Оценка.

Источник

Представьт себе ситуацию: вам поручили провести тестирование учеников. Учеников в классе более 20, вопросов в тесте — 10. Времени на подведение итогов у вас совсем немного. И тут вы применяете свои знания в Excel 2010 и составляете таблицу, в которой ученик вводит ответы на вопросы теста, а созданная вами программа в виде таблицы выдает ему оценку в зависимости от количества ошибок. А теперь опишем процесс создания такой таблицы.

Готовим таблицу (рис. 10.5). В первой строке — номера 10 вопросов. Тексты вопросов могут быть даны ниже, сделаны примечаниями и т. д. Как вам удобнее.

Рис. 10.5. Подготовка таблицы

Во вторую строку, которая называется «Опрос по теме № 1», ученики будут вводить свои варианты ответов. В третьей строке введены формулы, которые содержат правильные ответы теста. Допустим, в нашем тесте ученики выбирают из трех вариантов ответов. Не волнуйтесь, эту строку мы потом скроем и она не будет видна. Обратите внимание на формулу в ячейке B3 на рис. 10.5. Я использовала здесь логическую функцию из библиотеки Excel. В общем виде она выглядит так: ЕСЛИ(лог_выражение; значение_если_истина; значение_если_ложь). Функция ЕСЛИ возвращает одно значение, если указанное условие дает в результате значение ИСТИНА, и другое значение, если условие дает в результате значение ЛОЖЬ.

Простыми словами: первый аргумент функции (лог_выражение) — логическое выражение, которое функция проверяет. Если выражение верно, то функция на выходе выдает второй аргумент (значение_если_ истина), если выражение неверно, то на выходе функции — третий аргумент (значение_если_ложь). Аргумент лог_выражение — обязательный. Например, В2=1 — логическое выражение; если значение в ячейке В2 равно 1, это выражение принимает значение ИСТИНА, в противном случае — значение ЛОЖЬ. В этом аргументе может использоваться любой оператор сравнения.

Операторы сравнения в Excel:

= — равно;
> — больше;
< — меньше;
>= — больше или равно;
< = — меньше или равно;
<> — не равно.

Аргумент значение_если_истина. Это значение, которое возвращается, если аргумент лог_выражение соответствует значению ИСТИНА.
Аргумент значение_если_ложь. Это значение, которое возвращается, если аргумент лог_выражение соответствует значению ЛОЖЬ.

На рис. 10.6 приведен пример использования этой функции.

Рис. 10.6. Пример использования функции ЕСЛИ

Во втором столбце — числа. Функция ЕСЛИ проверяет логическое выражение В1>3 (для последующих строчек берутся соответствующие значения ячеек в столбце В) и выдает значение «значение больше трех» в том случае, если число во втором столбце больше 3, и «значение не больше трех», если число во втором столбце меньше или равно 3. В качестве второго и третьего аргументов использован текст. Обратите внимание: текст обязательно берется в кавычки.

Но вернемся к нашей формуле на рис. 10.5. Смысл ее в том, что если ученик отвечает правильно, то значение ячейки третьей строки приобретает значение 1, если неправильно, то 0. Если В2 = 1 (то есть правильный ответ на вопрос под номером 1), то ячейка В3 = 1, если ответ неправильный, то В3 = 0. На рис. 10.5 ученик дал 5 правильных ответов. В третьей строке 5 единиц, остальное — нули. В ячейке L3 — сумма диапазона B3:К3. Теперь нужно скрыть третью строку, чтобы отвечающий на вопросы теста не видел правильных ответов, которые заложены в формулу.

Выделите третью строку, перейдите на вкладку Главная, в группе Ячейки нажмите кнопку Формат и в появившемся меню выполните команду Скрыть или отобразить → Скрыть строки. Посмотрите, на рис. 10.7 третьей строки как не бывало. (Захотите отобразить строку обратно, используйте команду Отобразить строки.)

Рис. 10.7. Результаты

Зато на рисунке уже виден результат, который выдается тестируемому. Как я это сделала?

Ячейка B4 выводит результат по десятибалльной системе (значение в ячейке В4 равно значению в ячейке L3, которое мы скрыли от тестируемого). На рис. 10.7 результат равен 8, значит, из 10 вопросов ученик дал 8 правильных ответов. Ячейка В5 выдает результат по пятибалльной системе, и тут все сложнее. Подход такой:

если правильных ответов 9 или 10, то оценка 5;
если правильных ответов 8 или 7, то оценка 4;
если правильных ответов от 6 до 4, то оценка 3;
если правильных ответов от 3, то оценка 2;
если правильных ответов 2 или 1, то оценка 1.

Я привожу этот пример, чтобы рассказать, что в качестве аргумента функции ЕСЛИ может быть любая логическая функция. И таких вложенных функций может быть не больше 64. Но я себе слабо представляю, как можно соорудить логическую конструкцию из 64 вложенных функций и не запутаться… Давайте хотя бы с тремя попробуем разобраться.

Смотрите на формулу на рис. 10.7. Разбор таких «матрешек» всегда нужно начинать с самой маленькой, то есть с самой внутренней функции, в нашем случае она выглядит так: =ЕСЛИ(L3>2;2;1). Эта функция проверяет количество правильных ответов (строка 3 у нас скрыта, ее можно увидеть на рис. 10.5). Если правильных ответов больше 2, то на выходе оценка 2, если не больше 2 (а не больше 2, значит, меньше или равно 2),
то 1.

Следующая «матрешка»: =ЕСЛИ(L3>3;3;ЕСЛИ(L3>2;2;1)). Если количество правильных ответов больше 3, то оценка 3, если не больше 3 (то есть меньше или равно 3), то проверяется первое условие и в зависимости от результата выставляется 2 или 1.

Третий уровень: =ЕСЛИ(L3>6;4;ЕСЛИ(L3>3;3;ЕСЛИ(L3>2;2;1))). Если количество правильных ответов больше 6, то оценка 4. Если меньше, то проверяются последовательно второе и первое условие и ставятся оценки 3, 2 или 1.

И последний уровень. =ЕСЛИ(L3>8;5;ЕСЛИ(L3>6;4;ЕСЛИ(L3>3;3;ЕСЛИ(L3>2;2;1)))) Для отличников — тех, кто даст больше 8 правильных ответов. Им — оценка 5. Если правильных ответов меньше 8, то программа проверяет последовательно все ЕСЛИ и выставляет 4, 3, 2 или 1.

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

И(логическое_значение1;логическое_значение2;…) — возвращает значение ИСТИНА, если в результате вычисления всех аргументов получается значение ИСТИНА; возвращает значение ЛОЖЬ, если в результате вычисления хотя бы одного из аргументов получается значение ЛОЖЬ. Аргумент логическое_значение1 — обязательный. Это первое проверяемое условие, вычисление которого дает значение ИСТИНА или ЛОЖЬ. Аргументы логическое_значение2 и далее — необязательные. Этих условий может быть не более 255.

Функция И проверяет все логические значения, которые записаны у нее в аргументах. Если все они верны, то функция на выходе выдает значение ИСТИНА, если хотя бы одно выражение неверно, то на выходе ЛОЖЬ. Посмотрите пример на рис. 10.8.

Рис. 10.8. Пример использования функции И

Функцию И можно использовать как аргумент к функции ЕСЛИ. Например: =ЕСЛИ(И(1<A1; A1<100); A1;"Значение вне интервала"). Помните принцип «матрешки»? Разбираться начинаем с самой внутренней
функции.

И(1<A1; A1<100) — эта функция проверит два логических выражения. Если значение в ячейке А1 будет больше 1 и меньше 100, примет значение ИСТИНА, в противном случае — ЛОЖЬ. Если первый аргумент функции ЕСЛИ принимает значение ИСТИНА (в нашем случае это значит, что значение ИСТИНА принимает функция И, то есть значение в ячейке А1 больше 1 и меньше 100), то на выходе функции ЕСЛИ — второй аргумент. В данном случае число, которое находится в ячейке А1.

Если ЛОЖЬ (значение в ячейке А1 не попадает в интервал от 1 до 100), то на выходе — текст «Значение вне интервала». Посмотрите на рис. 10.9. Здесь в столбце A — исходные значения, а в столбце В — результат выполнения описанной функции.

Рис. 10.9. Вложенные функции

ИЛИ(логическое_значение1;логическое_значение2;…) — возвращает значение ИСТИНА, если хотя бы один из аргументов имеет значение ИСТИНА. Возвращает значение ЛОЖЬ, если все аргументы имеют значение ЛОЖЬ. Аргумент логическое_значение1 — обязательный. Аргумент логическое значение2 и далее — необязательные. Функция работает так же, как и И, только значение ИСТИНА она принимает гораздо чаще. Ей для этого достаточно, чтобы хотя бы одно из поставленных условий соблюдалось.

Источник