Displaying progress bar in VBA using a form

Courtesy: Microsoft.com

1.Open a new workbook in Excel.


2.In Microsoft Office Excel 2003 and in earlier versions of Excel, click Tools, point to Macro, and then click Visual Basic Editor.

In Microsoft Office Excel 2007, click Visual Basic in the Code group on the Developer tab.

Note To display the Developer tab in the Ribbon, follow these steps:

a.Start Excel 2007, click the Microsoft Office Button, and then click Excel Options.

b.In the Excel Options dialog box, click Popular, and then click to select the Show Developer tab in the Ribbon check box.

3.On the Insert menu, click UserForm.

4.Draw a Label control on the user form.

5.Change the following properties of the Label control to the following values:

Property Value

--------------------------------------------

Caption Now updating. Please wait...

Note If the Properties window is not visible, click Properties Window on the View menu.

6.Draw a Frame control on the user form.

7.Change the following properties of the Frame control to the following values:

Property Value
-----------------------------

Name FrameProgress

8.Draw a Label control on the Frame control.

9.Change the following properties of the Label control to the following values:

Property Value

-------------------------------------

Name LabelProgress

BackColor &H000000FF&

SpecialEffect fmSpecialEffectRaised

Type the Macro Code

1.Double-click the user form to open the Code window for the user form.

2.In the module, type the following code for the UserForm_Activate event:

Private Sub UserForm_Activate()

' Set the width of the progress bar to 0.

UserForm1.LabelProgress.Width = 0

' Call the main subroutine.

Call Main

End Sub

3.On the Insert menu, click Module.

4.In the Code window for the module, type the following code:

Sub ShowUserForm()

UserForm1.Show

End Sub

Sub Main()

Dim Counter As Integer

Dim RowMax As Integer, ColMax As Integer

Dim r As Integer, c As Integer

Dim PctDone As Single



Application.ScreenUpdating = False

' Initialize variables.

Counter = 1

RowMax = 100

ColMax = 25



' Loop through cells.

For r = 1 To RowMax

For c = 1 To ColMax

'Put a random number in a cell

Cells(r, c) = Int(Rnd * 1000)   /////remove/comment this if you don't want to insert cols/rows....

Counter = Counter + 1

Next c



' Update the percentage completed.

PctDone = Counter / (RowMax * ColMax)



' Call subroutine that updates the progress bar.

UpdateProgressBar PctDone

Next r

' The task is finished, so unload the UserForm.

Unload UserForm1

End Sub



Sub UpdateProgressBar(PctDone As Single)

With UserForm1



' Update the Caption property of the Frame control.

.FrameProgress.Caption = Format(PctDone, "0%")



' Widen the Label control.

.LabelProgress.Width = PctDone * _

(.FrameProgress.Width - 10)

End With



' The DoEvents allows the UserForm to update.

DoEvents

End Sub

5.Return to Excel.

6.In Excel 2003 and in earlier versions of Excel, point to Macro on the Tools menu, and then click Macros.



In Excel 2007, click Macros in the Code group on the Developer tab.

7.In the Macro dialog box, click to select ShowUserForm, and then click Run.

Rack-mount and Blade Servers

Source - Wikipedia and Techtarget.com

A blade server is a stripped-down server computer with a modular design optimized to minimize the use of physical space and energy. Whereas a standard rack-mount server can function with (at least) a power cord and network cable, blade servers have many components removed to save space, minimize power consumption and other considerations, while still having all the functional components to be considered a computer.

A rack server, also called a rack-mounted server, is a computer dedicated to use as a server and designed to be installed in a framework called a rack. The rack contains multiple mounting slots called bays, each designed to hold a hardware unit secured in place with screws. A rack server has a low-profile enclosure, in contrast to a tower server, which is built into an upright, standalone cabinet.

What are the various kinds of Servers (Web Servers, Application Servers, etc.)? [Source jguru.com, author Paul Danckaert] / Difference between a Web Server and Application Server.

The servers involved in handling and processing a user's request break down into a few basic types, each of which may have one or more tasks it solves. This flexibility gives developers a great deal of power over how applications will be created and deployed, but also leads to confusion over what server is able to, or should, perform a specific task.

Starting at the basic level, a user is typically submitting a request to a system through a web browser. (We are conveniently ignoring all other types of clients (RMI, CORBA, COM/DCOM, Custom, etc..) for the time being for purposes of clarity.) The web request must be received by a Web Server (otherwise known as an HTTP Server) of some sort. This web server must handle standard HTTP requests and responses, typically returning HTML to the calling user. Code that executes within the server environment may be CGI driven, Servlets, ASP, or some other server-side programming language, but the end result is that the web server will pass back HTML to the user.

The web server may need to execute an application in response to the users request. It may be generating a list of news items, or handling a form submission to a guest book. If the server application is written as a Java Servlet, it will need a place to execute, and this place is typically called a Servlet Engine. Depending on the web server, this engine may be internal, external, or a completely different product. This engine is continually running, unlike a traditional CGI environment where a CGI script is started upon each request to the server. This persistance gives a servlet connection and thread pooling, as well as an easy way to maintain state between each HTTP request. JSP pages are usually tied in with the servlet engine, and would execute within the same space/application as the servlets.

There are many products that handle the web serving and the servlet engine in different manners. Netscape/iPlanet Enterprise Server builds the servlet engine directly into the web server and runs within the same process space. Apache requires that a servlet engine run in an external process, and will communicate to the engine via TCP/IP sockets. Other servers, such as MS IIS don't officially support servlets, and require add-on products to add that capability.

When you move on to Enterprise JavaBeans (and other J2EE components like JMS and CORBA) you move into the application server space. An Application Server is any server that supplies additional functionality related to enterprise computing -- for instance, load balancing, database access classes, transaction processing, messaging, and so on.

EJB Application Servers provide an EJB container, which is the environment that beans will execute in, and this container will manage transactions, thread pools, and other issues as necessary. These application servers are usually stand-alone products, and developers would tie their servlets/JSP pages to the EJB components via remote object access APIs. Depending on the application server, programmers may use CORBA or RMI to talk to their beans, but the baseline standard is to use JNDI to locate and create EJB references as necessary.

Now, one thing that confuses the issue is that many application server providers include some or all of these components in their product. If you look at WebLogic (http://www.beasys.com/) you will find that WebLogic contains a web server, servlet engine, JSP processor, JMS facility, as well as an EJB container. Theoretically a product like this could be used to handle all aspects of site development. In practice, you would most likely use this type of product to manage/serve EJB instances, while dedicated web servers handle the specific HTTP requests.

Types of tests to be included in a System Test (source Wikipedia)

1. Graphical user interface testing
2. Usability testing
3. Software performance testing
4. Compatibility testing
5. Exception handling
6. Load testing
7. Volume testing
8. Stress testing
9. Security testing
10. Scalability testing
11. Sanity testing
12. Smoke testing
13. Exploratory testing
14. Ad hoc testing
15. Regression testing
16. Installation testing
17. Maintenance testing
18. Recovery testing and failover testing.
19. Accessibility testing, including compliance with certain compliance needed for the disabled.

Six major components of test automation framework (Softwaregenius.com)

A test automation infrastructure, or framework, consists of test tools, equipment, test scripts, procedures, and people needed to make test automation efficient and effective. The creation and maintenance of a test automation framework are key to the success of any test automation project within an organization.

The implementation of an automation framework generally requires an automation test group. The responsibility of this group is to develop test automation infrastructure, test libraries, and tests tools.


The idea behind an automation infrastructure is to ensure the following:a) Different test tools and equipment are coordinated to work together.
b) The library of the existing test case scripts can be reused for different test projects, thus minimizing the duplication of development effort.
c) Nobody creates test scripts in their own ways.
d) Consistency is maintained across test scripts.
e) The test suite automation process is coordinated such that it is available just in time for regression testing.
f) People understand their responsibilities in automated testing.


Components of a typical test automation framework are as described in the following figure.


1) System to Be Tested: This is the first component of an automation infrastructure. The subsystems of the system to be tested must be stable; otherwise test automation will not be cost effective. All the subsystems must be stable and work together as a whole before the start of an automation test project.


2) Testing Platform: The testing platform and facilities, that is, the network setup on which the system will be tested, must be in place to carry out the test automation project. For example, a procedure to download the image of the SUT, configuration management utilities, servers, clients, routers, switches, and hubs are necessary to set up the automation environment to execute the test scripts.


3) Test Case Library: It is useful to compile libraries of reusable test steps of basic utilities to be used as the building blocks of automated test scripts. Each utility typically performs a distinct task to assist the automation of test cases. Examples of such utilities are ssh (secure shell) from client to server, exit from client to server, response capture, information extraction, rules for verdicts, verdict logging, error logging, cleanup, and setup.


4) Automated Testing Practices: The procedures describing how to automate test cases using test tools and test case libraries must be documented. A template of an automated test case is useful in order to have consistency across all the automated test cases developed by different engineers. A list of all the utilities and guidelines for using them will enable us to have better efficiency in test automation. In addition, the maintenance procedure for the library must be documented.


5) Testing Tools: Different types of tools are required for the development of test scripts. Examples of such tools are test automation tool, traffic generation tool, traffic monitoring tool, and support tool. The support tools include test factory, requirement analysis, defect tracking, and configuration management tools. Integration of test automation and support tools, such as defect tracking, is crucial for the automatic reporting of defects for failed test cases. Similarly, the test factory tool can generate automated test execution trends and result patterns.


6) Test Administrator: The automation framework administrator does the following

a) Manages test case libraries, test platforms, and test tools;
b) Maintains the inventory of templates;
c) Provides tutorials; and
d) Helps test engineers in writing test scripts using the test case libraries.
e) Provides tutorial assistance to the users of test tools and maintains a liaison with the tool vendors and the users.


Source: http://www.softwaretestinggenius.com/articalDetails.php?qry=957