Qtp Automated Testing

I did some development for a short time before, and later I was mainly engaged in testing. I had a wealth of testing experience (but only limited to Black Box) and led the team for half a year. During this period, I learned 6-sigma (black belt) with my boss ), I have also made several patents, so I have a great deal of process, improvement, and sense on the customer's demand side, and I feel very innovative. Now I am dedicated to qtp automated development, and a project is just over, so I will share my thoughts and discuss them together.

Review the operations of the entire project and summarize the following:

1. demand confirmation stage

In this case, we need strong support from manual testers and establish good communication to improve the business efficiency we are familiar with. The communication includes:

1) requirement proposal: confirm the automated implementation strategy with the manual testing contact.

Take the ideas of the boss and the customer as the main direction, combine the actual needs of manual testing, and take into account the current situation of automation implementation, jointly develop the scope of the project.

The requirement cannot be the "wishful thinking" of the automation team ". Of course, in reality, there are sometimes more ideas proposed by the automation party, but the fundamental principle is to obtain manual approval and confirmation. Otherwise, when something is done, when they say this is not what I want, our automation team will all faint ......

2) requirements confirmation and familiarity: the automated Team further analyzes the requirements and develops an automated auto-test case.

The premise of analysis is that you are familiar with the business, that is, you can understand the test case and perform the test. In principle, automation personnel should be very familiar with their businesses and should have at least manual testing experience. But in fact, we cannot be familiar with all the projects, so it is important to quickly master the business operation process. At this time, the most convenient way is to communicate with the manual tester. The better the communication effect, the less time it takes.

PS: In our previous project, we finished reading all the manual test cases in the requirement validation phase, classified them into what we needed, and confirmed with them. To be honest, a little delayed.

2. Development Stage

If I have previous experience in the demand validation stage, the development stage is brand new to me. In our previous automated projects, code changes were rare in the development phase. The focus was on how to concatenate parallel operations on multiple devices or PCs. However, different projects here require strong programming capabilities and familiarity with qtp, which is also a weak point for me. This is why I learned the most at this stage.

First, a good frame framework brings great convenience to our coding and maintenance.

Second, for coding, for common functions, you can write them only after reading the help specification. Now you are very familiar with it and can directly encode it quickly. I learned many new coding techniques, such:

1) The dictionary object is used. I have never heard of it before. Khan ~~

2) the actual application of descriptive programming has only previously seen related concepts

3) the application of time functions, such as the Sync method, waitproperty attribute, or self-editing a for loop, dynamic wait time.

Thirdly, cocoding ensures code synchronization.

The disadvantage of managing our code through SVN is that many people can edit the same file at the same time. This development mode seems to be common in various development projects, but I have little pure development experience and management tool changes (previously using VSS ), at the beginning, I couldn't even connect to check in or check out. It's not difficult to learn such operations. What's hard is how to establish such a collaborative operation mode in my mind and how to share resources, it will not cause inconvenience to others because of a person's modification. Our team reached a consensus. Before submitting code, we should first check whether there are changes on the server, and then submit after update. If this is not the case, we can only compare the differences between files. However, in the management of the Object Library, because the stored data is special and cannot be compared, you need to explain it to the founder of the document before modification, and then update it.

3. Overall project management

I think that in this project, we did not integrate the so-called project management. Because there are still few people and some experience, we fully follow up on the project progress with our consciousness and experience, this is very dangerous. In the next step, if we expand our team and add inexperienced people to the Code, the project risk will be very high, so we need to enable a project supervision mechanism.

1) resource adjustment

In the future, we can try to arrange a person to study in the manual test group, but of course, he must have an automatic concept. "undercover" will go there to learn about testing and understand the needs, this is an inter-group adjustment.

In the automated testing group, we can share our information through regular experience sharing, and actively ask others when there is a problem, so we can calculate an account, if I encounter a problem, If I solve it myself or check the information online, it may take about half an hour, but if I ask people around me, it may take only five minutes, the two were delayed for five minutes, that is, they used ten minutes to complete the work for half an hour. Why not? You may also say that for me, I spent five minutes completing the work for half an hour, but what about the Q & A personnel ?? He wasted five minutes. No one is willing to do this ...... However, it may be the other way around, that is, it takes me five minutes to solve the problem that took me half an hour. At this time, we are a win-win situation. In this cycle, can we be less efficient ?? We are now in the era of unity and collaboration, not an era that tests the Independent Learning of individuals. Therefore, we should not share such resources as a manifestation of our ability to solve problems independently. When talking about requirements with manual tests, we should also make full use of such support, instead of testing case at home.

2) Transaction priority

Focusing on the embarrassing status quo of automated development in various companies, it is more important to distinguish between primary and secondary development. This is reflected in filtering test cases. We follow the 20-80 rule, and we need to be brave enough to remove the 80% test cases that took 20% of the time to complete, unless the manual test has special requirements, which is not contrary to the nature of automatic testing. The purpose of automated testing is not to automate all cases of manual testing, but to automate cases with relatively low change, simple process logic, and high testing frequency, we cannot add unnecessary cases to the pursuit of automated proportions.

3) Transaction Supervision

The question is discussed in the form of a question and answer:

A. Q: How can I customize a reasonable project schedule? Isn't it easy for team members to work, and they don't have to work overtime every day?

A: This requires us to understand the configuration of all resources, master the average time of each operation link, and understand the time range (confidence interval) that may be used for 80% of this link as an auxiliary decision.

B. Q: How can I master the project progress? That is, how does the project owner ensure that the project is on schedule? How do project managers or higher supervisors know the project progress?

A: regular meeting. Ask the team members to report their work progress and discuss the problems encountered.

Take the weekly report as an example. The content of the meeting is as follows: The team members will introduce the specific work of this week (a bit like timesheet). Compared with the expected content of last week, the meeting should be completed on time or delayed, what is the cause of the delay ?? The project owner will arrange work for the next week.

After several times of Planning-> Implementation-> correction plan, you will have a better understanding of the weekly work progress, which is conducive to the estimation of the project progress.

C. Q: How can I accept the project results?

A: each person has a different understanding of the concept of "complete". Some people think that complete is the right thing. Some people think that good is the right thing, and some people want perfect. To ensure consistency after the project is completed, you can create a completed checklist to quantify the concept of "finished", such as the completion of Acceptance Test Case script, we can customize the following checklist for acceptance.

No	Function Name	Check Point	Review history	Code Review	Time Optimization	Data create	Doc sync	Remark	Date	Reviewer
V360_tc0001	Tc_capbasicsearch								10/16/2008	Lynn
......	......								......	......

4) Review

That is, after the project is completed, summarize and adjust the project. After the review and analysis, Zhuge Liang found out the improvement scheme, which is very helpful for the progress of the next project.

After two rounds of development, the Code maintenance phase has been reached. In the past, we thought that maintenance is the easiest step in "requirement-> development-> maintenance", but now we are scratching our heads.

After the results of these run operations, the first sentence for all people to meet was: "Well, it's a pass on my computer. How can this happen now ?"

Calm down and check the Code. There are always some problems that we can ignore, but there are still many stubborn problems, in particular, the problem that the interface is not refreshed in a timely manner or is inexplicable is really annoying. Development is a creative thing, and testing is a destructive thing. Both of them have a sense of accomplishment, but maintaining or wiping your ass makes us all upset. Summarize our requirements, development, and operation experience, as well as problems encountered during recent maintenance:

1. In the demand analysis stage, when writing an Autotest case, the steps are slightly detailed and should not be too simple or complex, multi-purpose project terminology (people who read this document are familiar with the Project). This helps maintenance personnel or manual testers understand the test content of case later.

2. When developing code:

1) the comments in the script are clearly written.

2) make the object library and object naming as meaningful as possible

3) The intermediate steps (such as page Jump, some important buttons or links) should be clearly written. It is best to write them into the report.

4) The checkpoint judgment should be intuitive and clear about the input and output values and expected output. For example, if the query function fails, specify the input conditions to make the query fail, otherwise, QA may input another set of data for query and the result is successful.

5) after writing the entire case, you need to check whether the overall report is easy to understand. The entire report needs to be consistent in context like a story.

6) at the end of the development process, you need to arrange time for Mutual Review code, as per 1 )~ 5) Review other people's code. This will also find some problems. In addition, mutual inspection of Code helps us discover the strengths of others and some things we have not noticed.

7) after the code is complete, you should never hide it. Instead, you must run the code several times and run it on different computers. You can run the code on each other at night.

I think, 6) and 7) in the development stage, we always say that the development time is tight and the two steps are shortened or omitted, which leads to hundreds of errors during the official operation.

3. Maintenance Phase

Summary of Common Errors:

1) environment problems (such as interface refreshing and suspension of exceptions)

We can only identify these problems, but we always feel that we can optimize them again, that is, we have not yet come up with a good solution. Will continue to explore

2) qtp conflicts with IE

Some operations of qtp may cause IE to be aborted abnormally, or the qtp cannot be reflected due to IE settings. The frequency of such problems is not high, but it may lead to a series of errors.

3) object exception

There are the following situations:

The first is the object change or logic change caused by the upgrade of the site itself. You need to modify the code at this time;

In the second case, the object cannot be identified due to an interface jump exception, which can be seen in the captured image.

There is also a situation where, in our framework, object duplication occurs when loading object libraries, leading to the inability to recognize objects. In this case, you need to process repeated objects to ensure their uniqueness.

The most common issue is that objects are not unique and cannot be identified. When they are found in webelement, we often determine whether a webelement is successful based on its value, however, sometimes there are many hidden webelements in the interface. If the identification attribute of webelement happens to use descriptive programming or regular expressions, it is easy to recognize it. You need to add the index attribute for identification.

4) Existence of dirty data

For example, if a case is "add"> "query"> "delete", an error is aborted if the operation is not executed for the first time. During the second operation, the code added previously exists, which affects addition or query. We can design case: delete-> Add-> query-> Delete

Another example is that the prerequisite for the operation requires the B operation settings, but the setting of B will affect other operations of the phase. We set case: B config1-> A operate-> B config2, however, if the case is aborted before B config2, config1 of B will be brought into the next case. For such a case, you can put the case in the last execution to reduce the impact on other code.

Our final test report will be confirmed by the manual QA personnel, check whether the bug is a system bug, and count the ratio of bug discovery,

1) Check bugs detected by missing rate automation/bugs detected by QA

Check whether the bug detected by QA is in the case of automated testing. If so, it is our problem. If not, we need to add it to the case, this shows the importance of requirements and QA validation. Otherwise, we will be very depressed if people do not recognize your checkpoint or your case is missing.

2) Bug detected by QA and all bugs detected by Automation

This is a great deal of pressure. If ten bugs are detected automatically, nine of them are script or environment problems, and only one is a real bug, we can imagine the efficiency of automation.