Tables are the basic unit of data storage in an Oracle database. Database tables hold all user-accessible data. Each table has columns and rows. Oracle stores each row of a database table containing data for less than 256 columns as one or more row pieces.
Views
Views are customized presentations of data in one or more tables or other views. A view can also be considered a stored query. Views do not actually contain data. Rather, they derive their data from the tables on which they are based, referred to as the base tables of the views.
Like tables, views can be queried, updated, inserted into, and deleted from, with some restrictions. All operations performed on a view actually affect the base tables of the view.
Views provide an additional level of table security by restricting access to a predetermined set of rows and columns of a table. They also hide data complexity and store complex queries.
Indexes
Indexes are optional structures associated with tables. Indexes can be created to increase the performance of data retrieval. Just as the index in this manual helps you quickly locate specific information, an Oracle index provides an access path to table data.
When processing a request, Oracle can use some or all of the available indexes to locate the requested rows efficiently. Indexes are useful when applications frequently query a table for a range of rows (for example, all employees with a salary greater than 1000 dollars) or a specific row.
Indexes are created on one or more columns of a table. After it is created, an index is automatically maintained and used by Oracle. Changes to table data (such as adding new rows, updating rows, or deleting rows) are automatically incorporated into all relevant indexes with complete transparency to the users.
You can partition indexes.
Data Definition Language (DDL) Statements
These statements create, alter, maintain, and drop schema objects. DDL statements also include statements that permit a user to grant other users the privileges to access the database and specific objects within the database.
Data Manipulation Language (DML) Statements
These statements manipulate data. For example, querying, inserting, updating, and deleting rows of a table are all DML operations. The most common SQL statement is the SELECT statement, which retrieves data from the database. Locking a table or view and examining the execution plan of an SQL statement are also DML operations
An integrity constraint is a declarative way to define a business rule for a column of a table. An integrity constraint is a statement about a table's data that is always true and that follows these rules:
• If an integrity constraint is created for a table and some existing table data does not satisfy the constraint, then the constraint cannot be enforced.
• After a constraint is defined, if any of the results of a DML statement violate the integrity constraint, then the statement is rolled back, and an error is returned.
Integrity constraints are defined with a table and are stored as part of the table's definition in the data dictionary, so that all database applications adhere to the same set of rules. When a rule changes, it only needs be changed once at the database level and not many times for each application.
The following integrity constraints are supported by Oracle:
• NOT NULL: Disallows nulls (empty entries) in a table's column.
• UNIQUE KEY: Disallows duplicate values in a column or set of columns.
• PRIMARY KEY: Disallows duplicate values and nulls in a column or set of columns.
• FOREIGN KEY: Requires each value in a column or set of columns to match a value in a related table's UNIQUE or PRIMARY KEY. FOREIGN KEY integrity constraints also define referential integrity actions that dictate what Oracle should do with dependent data if the data it references is altered.
• CHECK: Disallows values that do not satisfy the logical expression of the constraint.
• Primary key: The column or set of columns included in the definition of a table's PRIMARY KEY constraint. A primary key's values uniquely identify the rows in a table. Only one primary key can be defined for each table.
• Unique key: The column or set of columns included in the definition of a UNIQUE constraint.
• Foreign key: The column or set of columns included in the definition of a referential integrity constraint.
• Referenced key: The unique key or primary key of the same or a different table referenced by a foreign key.
RUP
13. What is RUP?
Rational Unified Process (RUP).It is a software engineering process which provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high quality software that meets the needs of its end users within a predictable schedule and budget
All it says is
1. Develop software iteratively
2. Manage requirements
3. Use component based architecture
4. Visually model the software
5. Continuously verify software quality
6. Control changes to software
They came up with the Rational Unified Process (RUP), which is a general framework that can be used to describe specific development processes.
According to the Unified Software Development Process
Every 'software life cycle' is 'a cycle over four phases in the following order: Inception, Elaboration, Construction and Transition
5. Rational Unified Process: (RUP)
It’s a software engineering process which provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high quality software that meets the needs of its end users within a predictable schedule and budget
All it says is
7. Develop software iteratively
8. Manage requirements
9. Use component based architecture
10. Visually model the software
11. Continuously verify software quality
12. Control changes to software
18.What tools are available for support of testing during software development life
cycle?
RUP(Rational Unified Process) for designiing, Microsoft Word, Excel, Visio 2000,
Test Plan Details
• Title
• Identification of software including version/release numbers
• Revision history of document including authors, dates, approvals
• Table of Contents
• Purpose of document, intended audience
• Objective of testing effort
• Software product overview
• Relevant related document list, such as requirements, design documents, other test plans
• Relevant standards or legal requirements
• Traceability requirements
• Relevant naming conventions and identifier conventions
• Overall software project organization and personnel/contact-info/responsibilties
• Test organization and personnel/contact-info/responsibilities
• Assumptions and dependencies
• Project risk analysis
• Testing priorities and focus
• Scope and limitations of testing
• Test outline - a decomposition of the test approach by test type, feature, functionality, process, system, module, etc. as applicable
• Outline of data input equivalence classes, boundary value analysis, error classes
• Test environment - hardware, operating systems, other required software, data configurations, interfaces to other systems
• Test environment validity analysis - differences between the test and production systems and their impact on test validity.
• Test environment setup and configuration issues
• Software migration processes
• Software CM processes
• Test data setup requirements
• Database setup requirements
• Outline of system-logging/error-logging/other capabilities, and tools such as screen capture software, that will be used to help describe and report bugs
• Discussion of any specialized software or hardware tools that will be used by testers to help track the cause or source of bugs
• Test automation - justification and overview
• Test tools to be used, including versions, patches, etc.
• Test script/test code maintenance processes and version control
• Problem tracking and resolution - tools and processes
• Project test metrics to be used
• Reporting requirements and testing deliverables
• Software entrance and exit criteria
• Initial sanity testing period and criteria
• Test suspension and restart criteria
• Personnel allocation
• Personnel pre-training needs
• Test site/location
• Outside test organizations to be utilized and their purpose, responsibilities, deliverables, contact persons, and coordination issues
• Relevant proprietary, classified, security and licensing issues.
• Open issues
• Appendix - glossary, acronyms, etc.
What is Test Plan?
Test Plan is a high level living document that defines the objective, scope, approach and focus of the software testing. It includes items like test objective, requirements, roles and responsibilities, software and hardware issues, limitations, test environments, risk factors etc.
Test Scripts and Test procedures
The Test Procedure is a detailed document which defines and guides the testing, and is
written by the QA analyst. Individual scripts and scenarios make up the bulk of this document.
Test Plan: A document describing the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning. Ref IEEE Std 829.
Test Procedure: A document providing detailed instructions for the execution of one or more test cases.
1. Writing the test plan and test cases: Template and the tool is decided to write the test plan, test cases and test procedures. Expected results are organized in the test plan according to the feature categories specified in the requirement document. For each feature positive and negative test cases are written. Writing test plan requires the complete understanding of the product and its interfaces with other systems. After test plan is completed, a walkthrough is conducted with the developers and design team members to baseline the test plan document.
What is master test plan? What it contains? Who is responsible for writing it?
OR
What is a test plan? Who is responsible for writing it? What it contains.
OR
What's a 'test plan'? What did you include in a test plan?
A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the 'why' and 'how' of product validation. It should be thorough enough to be useful but not so thorough that no one outside the test group will read it. The following are some of the items that might be included in a test plan, depending on the particular project:
• Title
• Identification of software including version/release numbers
• Revision history of document including authors, dates, approvals
• Table of Contents
• Purpose of document, intended audience
• Objective of testing effort
• Software product overview
• Relevant related document list, such as requirements, design documents, other test plans, etc.
• Relevant standards or legal requirements
• Trace ability requirements
• Relevant naming conventions and identifier conventions
• Overall software project organization and personnel/contact-info/responsibilties
• Test organization and personnel/contact-info/responsibilities
• Assumptions and dependencies
• Project risk analysis
• Testing priorities and focus
• Scope and limitations of testing
• Test outline - a decomposition of the test approach by test type, feature, functionality, process, system, module, etc. as applicable
• Outline of data input equivalence classes, boundary value analysis, error classes
• Test environment - hardware, operating systems, other required software, data configurations, interfaces to other systems
• Test environment validity analysis - differences between the test and production systems and their impact on test validity.
• Test environment setup and configuration issues
• Software migration processes
• Software CM processes
• Test data setup requirements
• Database setup requirements
• Outline of system-logging/error-logging/other capabilities, and tools such as screen capture software, that will be used to help describe and report bugs
• Discussion of any specialized software or hardware tools that will be used by testers to help track the cause or source of bugs
• Test automation - justification and overview
• Test tools to be used, including versions, patches, etc.
• Test script/test code maintenance processes and version control
• Problem tracking and resolution - tools and processes
• Project test metrics to be used
• Reporting requirements and testing deliverables
• Software entrance and exit criteria
• Initial sanity testing period and criteria
• Test suspension and restart criteria
• Personnel allocation
• Personnel pre-training needs
• Test site/location
• Outside test organizations to be utilized and their purpose, responsibilties, deliverables, contact persons, and coordination issues
• Relevant proprietary, classified, security, and licensing issues.
• Open issues
• Appendix - glossary, acronyms, etc.
The team-lead or a Sr. QA Analyst is responsible to write this document.
Test Framework
A set of utilities, stylesheets and documentation that describe and facilitate development, documentation and use of the tests.
.
Views
Views are customized presentations of data in one or more tables or other views. A view can also be considered a stored query. Views do not actually contain data. Rather, they derive their data from the tables on which they are based, referred to as the base tables of the views.
Like tables, views can be queried, updated, inserted into, and deleted from, with some restrictions. All operations performed on a view actually affect the base tables of the view.
Views provide an additional level of table security by restricting access to a predetermined set of rows and columns of a table. They also hide data complexity and store complex queries.
Indexes
Indexes are optional structures associated with tables. Indexes can be created to increase the performance of data retrieval. Just as the index in this manual helps you quickly locate specific information, an Oracle index provides an access path to table data.
When processing a request, Oracle can use some or all of the available indexes to locate the requested rows efficiently. Indexes are useful when applications frequently query a table for a range of rows (for example, all employees with a salary greater than 1000 dollars) or a specific row.
Indexes are created on one or more columns of a table. After it is created, an index is automatically maintained and used by Oracle. Changes to table data (such as adding new rows, updating rows, or deleting rows) are automatically incorporated into all relevant indexes with complete transparency to the users.
You can partition indexes.
Data Definition Language (DDL) Statements
These statements create, alter, maintain, and drop schema objects. DDL statements also include statements that permit a user to grant other users the privileges to access the database and specific objects within the database.
Data Manipulation Language (DML) Statements
These statements manipulate data. For example, querying, inserting, updating, and deleting rows of a table are all DML operations. The most common SQL statement is the SELECT statement, which retrieves data from the database. Locking a table or view and examining the execution plan of an SQL statement are also DML operations
An integrity constraint is a declarative way to define a business rule for a column of a table. An integrity constraint is a statement about a table's data that is always true and that follows these rules:
• If an integrity constraint is created for a table and some existing table data does not satisfy the constraint, then the constraint cannot be enforced.
• After a constraint is defined, if any of the results of a DML statement violate the integrity constraint, then the statement is rolled back, and an error is returned.
Integrity constraints are defined with a table and are stored as part of the table's definition in the data dictionary, so that all database applications adhere to the same set of rules. When a rule changes, it only needs be changed once at the database level and not many times for each application.
The following integrity constraints are supported by Oracle:
• NOT NULL: Disallows nulls (empty entries) in a table's column.
• UNIQUE KEY: Disallows duplicate values in a column or set of columns.
• PRIMARY KEY: Disallows duplicate values and nulls in a column or set of columns.
• FOREIGN KEY: Requires each value in a column or set of columns to match a value in a related table's UNIQUE or PRIMARY KEY. FOREIGN KEY integrity constraints also define referential integrity actions that dictate what Oracle should do with dependent data if the data it references is altered.
• CHECK: Disallows values that do not satisfy the logical expression of the constraint.
• Primary key: The column or set of columns included in the definition of a table's PRIMARY KEY constraint. A primary key's values uniquely identify the rows in a table. Only one primary key can be defined for each table.
• Unique key: The column or set of columns included in the definition of a UNIQUE constraint.
• Foreign key: The column or set of columns included in the definition of a referential integrity constraint.
• Referenced key: The unique key or primary key of the same or a different table referenced by a foreign key.
RUP
13. What is RUP?
Rational Unified Process (RUP).It is a software engineering process which provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high quality software that meets the needs of its end users within a predictable schedule and budget
All it says is
13. Develop software iteratively
14. Manage requirements
15. Use component based architecture
16. Visually model the software
17. Continuously verify software quality
18. Control changes to software
They came up with the Rational Unified Process (RUP), which is a general framework that can be used to describe specific development processes.
According to the Unified Software Development Process
Every 'software life cycle' is 'a cycle over four phases in the following order: Inception, Elaboration, Construction and Transition
5. Rational Unified Process: (RUP)
It’s a software engineering process which provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high quality software that meets the needs of its end users within a predictable schedule and budget
All it says is
19. Develop software iteratively
20. Manage requirements
21. Use component based architecture
22. Visually model the software
23. Continuously verify software quality
24. Control changes to software
18.What tools are available for support of testing during software development life
cycle?
RUP(Rational Unified Process) for designiing, Microsoft Word, Excel, Visio 2000,
Test Plan Details
• Title
• Identification of software including version/release numbers
• Revision history of document including authors, dates, approvals
• Table of Contents
• Purpose of document, intended audience
• Objective of testing effort
• Software product overview
• Relevant related document list, such as requirements, design documents, other test plans
• Relevant standards or legal requirements
• Traceability requirements
• Relevant naming conventions and identifier conventions
• Overall software project organization and personnel/contact-info/responsibilties
• Test organization and personnel/contact-info/responsibilities
• Assumptions and dependencies
• Project risk analysis
• Testing priorities and focus
• Scope and limitations of testing
• Test outline - a decomposition of the test approach by test type, feature, functionality, process, system, module, etc. as applicable
• Outline of data input equivalence classes, boundary value analysis, error classes
• Test environment - hardware, operating systems, other required software, data configurations, interfaces to other systems
• Test environment validity analysis - differences between the test and production systems and their impact on test validity.
• Test environment setup and configuration issues
• Software migration processes
• Software CM processes
• Test data setup requirements
• Database setup requirements
• Outline of system-logging/error-logging/other capabilities, and tools such as screen capture software, that will be used to help describe and report bugs
• Discussion of any specialized software or hardware tools that will be used by testers to help track the cause or source of bugs
• Test automation - justification and overview
• Test tools to be used, including versions, patches, etc.
• Test script/test code maintenance processes and version control
• Problem tracking and resolution - tools and processes
• Project test metrics to be used
• Reporting requirements and testing deliverables
• Software entrance and exit criteria
• Initial sanity testing period and criteria
• Test suspension and restart criteria
• Personnel allocation
• Personnel pre-training needs
• Test site/location
• Outside test organizations to be utilized and their purpose, responsibilities, deliverables, contact persons, and coordination issues
• Relevant proprietary, classified, security and licensing issues.
• Open issues
• Appendix - glossary, acronyms, etc.
What is Test Plan?
Test Plan is a high level living document that defines the objective, scope, approach and focus of the software testing. It includes items like test objective, requirements, roles and responsibilities, software and hardware issues, limitations, test environments, risk factors etc.
Test Scripts and Test procedures
The Test Procedure is a detailed document which defines and guides the testing, and is
written by the QA analyst. Individual scripts and scenarios make up the bulk of this document.
Test Plan: A document describing the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning. Ref IEEE Std 829.
Test Procedure: A document providing detailed instructions for the execution of one or more test cases.
2. Writing the test plan and test cases: Template and the tool is decided to write the test plan, test cases and test procedures. Expected results are organized in the test plan according to the feature categories specified in the requirement document. For each feature positive and negative test cases are written. Writing test plan requires the complete understanding of the product and its interfaces with other systems. After test plan is completed, a walkthrough is conducted with the developers and design team members to baseline the test plan document.
What is master test plan? What it contains? Who is responsible for writing it?
OR
What is a test plan? Who is responsible for writing it? What it contains.
OR
What's a 'test plan'? What did you include in a test plan?
A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the 'why' and 'how' of product validation. It should be thorough enough to be useful but not so thorough that no one outside the test group will read it. The following are some of the items that might be included in a test plan, depending on the particular project:
• Title
• Identification of software including version/release numbers
• Revision history of document including authors, dates, approvals
• Table of Contents
• Purpose of document, intended audience
• Objective of testing effort
• Software product overview
• Relevant related document list, such as requirements, design documents, other test plans, etc.
• Relevant standards or legal requirements
• Trace ability requirements
• Relevant naming conventions and identifier conventions
• Overall software project organization and personnel/contact-info/responsibilties
• Test organization and personnel/contact-info/responsibilities
• Assumptions and dependencies
• Project risk analysis
• Testing priorities and focus
• Scope and limitations of testing
• Test outline - a decomposition of the test approach by test type, feature, functionality, process, system, module, etc. as applicable
• Outline of data input equivalence classes, boundary value analysis, error classes
• Test environment - hardware, operating systems, other required software, data configurations, interfaces to other systems
• Test environment validity analysis - differences between the test and production systems and their impact on test validity.
• Test environment setup and configuration issues
• Software migration processes
• Software CM processes
• Test data setup requirements
• Database setup requirements
• Outline of system-logging/error-logging/other capabilities, and tools such as screen capture software, that will be used to help describe and report bugs
• Discussion of any specialized software or hardware tools that will be used by testers to help track the cause or source of bugs
• Test automation - justification and overview
• Test tools to be used, including versions, patches, etc.
• Test script/test code maintenance processes and version control
• Problem tracking and resolution - tools and processes
• Project test metrics to be used
• Reporting requirements and testing deliverables
• Software entrance and exit criteria
• Initial sanity testing period and criteria
• Test suspension and restart criteria
• Personnel allocation
• Personnel pre-training needs
• Test site/location
• Outside test organizations to be utilized and their purpose, responsibilties, deliverables, contact persons, and coordination issues
• Relevant proprietary, classified, security, and licensing issues.
• Open issues
• Appendix - glossary, acronyms, etc.
The team-lead or a Sr. QA Analyst is responsible to write this document.
What different type of test cases you wrote in the test plan?
Test cases for interface, functionality, security, load and performance testing.
1. To track the test cases and defects use test director as tool..
A test case is a document that describes the input, action, or event and the expected response, to determine if a particular feature of an application is working correctly.
A test case should contain particulars such as:
• test case identifier
• test case name
• objective
• test conditions/setup
• input data requirements
• steps
• expected results
What is a Test case?
For each function to be tested we develop various test conditions and test scenarios. We include preconditions, post conditions and acceptance criterion in order to verify the functionality of the application.
• Test Case is a commonly used term for a specific test. This is usually the smallest unit of testing. A Test Case will consist of information such as requirements testing, test steps, verification steps, prerequisites, outputs, test environment, etc.
• A set of inputs, execution preconditions, and expected outcomes developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.
What are CMM and CMMI? What is the difference?
The Capability Maturity Model for Software (CMM or SW-CMM) is a model for judging the maturity of the software processes of an organization and for identifying the key practices that are required to increase the maturity of these processes.
The Capability Maturity Model Integration (CMMI) provides the guidance for improving your organization's processes and your ability to manage the development, acquisition, and maintenance of products and services. CMM Integration places proven practices into a structure that helps your organization assess its organizational maturity and process area capability, establish priorities for improvement, and guide the implementation of these improvements.
The new integrated model (CMMI) uses Process Areas (known as PAs) which are different to the previous model, and covers as well systems as software processes, rather than only software processes as in the SW-CMM.
shell script is a script written for the shell, or command interpreter, of an operating system.
Hypertext Markup Language is the authoring software language used on the Internet's World Wide Web. HTML is used for creating World Wide Web pages.
JavaServer Pages (JSP) is a Java technology that allows software developers to dynamically generate HTML, XML or other types of documents in response to a Web client request. The technology allows Java code and certain pre-defined actions to be embedded into static content.
The JSP syntax adds additional XML tags, called JSP actions, to be used to invoke built-in functionality. Additionally, the technology allows for the creation of JSP tag libraries that act as extensions to the standard HTML or XML tags. Tag libraries provide a platform independent way of extending the capabilities of a Web server.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment