Cross-system project testing

A system is often the most prone to problems where interfaces are connected. If there are multiple project interfaces and interactions across multiple systems, poor connections or errors in one place may lead to serious bugs or even re-design of the system. I have recently worked on two cross-system projects. Here I will talk about several issues that need attention in cross-system projects and some suggestions on how to make them.

　Demand stageTestWhat will be done?

Projects that span multiple systems must be familiar with each other's systems at the demand stage. If it is a transformation project, you need to be skilled by yourself.OthersSystem: ask people who are familiar with it. In addition, do not focus only on the requirements of your system for brand-new requirements, but also on the requirements of other systems, especially cross-cutting. If you have any questions, don't leave them behind in the design phase, so you may not be able to raise them. Let's list all the questions, no one can solve the problem as long as the problem can be raised. This is what we call "know yourself and know yourself. However, in many cases, most of them are only familiar with their own systems and other systems. In this case, you need to spend more time in the demand phase to find out the problems in the demand, calm down and think about the problems that may occur in the interface interaction part of the requirement. How should we design it to avoid those problems.

　　What should I pay attention to when planning projects across multiple systems?

For projects that have multiple interactions across multiple systems, it is often planned to develop joint debugging within two days. The actual situation usually takes about two more days to achieve joint debugging, therefore, it may take about two days for the scheduling to be conducted. In addition, there is still room for testing multiple interfaces. In many cases, we think that since the joint debugging is passed and the streaming is passed, testing should be fast and there should be no problems, however, it is often a matter of violation. Do not pin your hopes on development self-testing. Do not trust the self-testing degree of development too much. Of course, it is still possible to exclude self-testing. Therefore, it takes about two more days for the joint debugging test that involves multiple interfaces. In addition, when there are more systems and more interfaces, environmental factors will waste a lot of time. If an application is unavailable, the test may fail. Therefore, environmental factors and coordination time must also be taken into account.

What will the design phase test do?

Generally, in the development scheme design and UC design, testing usually takes less time. In this case, no problem is raised. We recommend that you also draw a flowchart during the UC design, think about some exceptions, especially how to call interactions. The most important thing is that you will constantly discover and solve problems when writing UC. You can find some problems during review and get familiar with the system, also strengthened the significance of the review. Write test design should be as detailed as possible. It is best to write back and modify the states of interaction and so on, so as to facilitate the design of use cases. If you have any questions, you need to communicate with each other. If you have different opinions, you need to communicate your opinions with those of developers and weigh how to do well. In addition, when writing test cases, we recommend that you have a lot of interactions. When you consider more scenario tests, you should consider abnormal stream situations. Such use cases do not need to be detailed, basically, it is in the form of a signature. You can use scenario cases to verify whether the development design is reasonable. If the design can meet the normal process, it can also meet some abnormal scenarios, which indicates that the design is basically no problem. In addition, we need to communicate with each other in development, testing, and design and test each other to check whether there are any omissions in the intersection.

　What will be done in the data preparation phase?

For cross-system projects, I think the data preparation stage is the time to be most familiar with the other party's system. After a series of operations, such as data creation, process, and so on, generally, you can understand the other system. If you have doubts about the system at this time, you may not consider the design. Of course, there will be a lot of trouble when creating this data, and there will be a lot of things that you don't know. It doesn't matter. Find someone to ask how to do it, after the questions are asked, we will precipitate these operation procedures so that we can create data on our own. In addition, you need to prepare more data. Some data is often used once or for different purposes. Plan the type of data to be prepared before creating the data, and prepare the data prepared before the test as far as possible.

　What should I do in the test execution phase?

As mentioned above, during the testing phase, we often think that the joint debugging is good, and there should be no problems in smoke, and it should be very fast, but what we often give us is still scattered, either this system cannot go down or the block cannot go down. Don't be impatient and calm down at this time. We can work with the development of joint debugging, and sometimes testing together to participate in joint debugging is much faster, and the process is also easier to use. It would be better if we could actively participate in their joint debugging before the smoke. In addition, pages are often inaccessible during the smoke phase. You need to know which tables are modified and how to create data for testing. Peer SystemDatabaseTables also need to be understood (in the test preparation stage ). Cross-system projects often encounter problems in the environment, either the system environment problem or the system environment problem. If the test execution fails, it is time to calm down, first, tell the relevant people to solve the problem, and think about whether there are any omissions that have not been taken into account, whether to add use cases, whether to create some data, and wait for the environment to be ready before testing.