Recently, a friend left a message saying,"I want to know the key points of smoke, SIT, UAT, and regression testing in core system construction, how to design test cases, or relevant information recommendations, etc."
This topic is very general. In addition to business testing, testing also includes performance testing, security testing, etc.; and different roles have different requirements for cases. For example, bank business personnel like to write cases that run the entire transaction from beginning to end, while testing company personnel like to write very detailed cases.
In this regard, because I have not received formal training in testing methods, I mainly want to talk about my personal understanding or feelings. By the way, I summarized some of the most critical basic knowledge and friends 'practical experiences and shared them with everyone so that more people can find their direction.
- This article is suitable for the crowd:
Bank employees, business personnel, testers.
- This article solves the problem:
For testers who are new to banking business, learning testing knowledge related to the banking system will help them systematically understand, which will be helpful to their future work.
This article is divided into four parts:
The main tasks of bank testing
Classification and basis for bank testing
Case design for bank testing
Bank test execution requirements and guidelines
1 Main tasks of bank testing
As everyone's financial advisers, banks are very sensitive to money. Frequent or even occasional software failures will damage customers 'confidence. If a hacker attacks, personal property will be threatened and the bank will inevitably suffer losses. Therefore, banks have very high requirements for the quality of the system, pursuing stable functions, reliable performance, high security, and ultimately achieving customer trust and ensuring the completeness of bank and individual property.
The prerequisite for ensuring high quality of the system is testing. Testing is a very important stage in the entire core project, so the role of testers is very important. Let's start with the main tasks of the testing phase.
(1) Preparation of test rules
Testing rules are obtained by analyzing requirements. It is the first step of testing by analyzing the original requirements to find the key points that need to be tested. Generally, middle and senior testers write test rules. The more detailed and accurate they are written, the more they understand the business being tested, the easier they will find system problems and business problems, and the better they can grasp the quality and progress of the test.
If the test requirements analysis is not clear, then the key points of the test rules will be unclear, and the writing of test cases will be groundless. This may result in waste of time or resources, inaccurate assessment of test workload, and delay of the project. So, how to improve needs analysis capabilities?
First, read the requirements document to understand the implementation background of the requirements, understand the purpose of the requirements and the user's use scenarios. If you encounter doubts in the process, write them down first, communicate with the business more to familiarize yourself with the business knowledge as soon as possible; secondly, analyze the rationality of the requirements, analyze, understand, and think from the perspective of the user or business, and give some design suggestions to the requirements or developers to avoid being bound by inertia thinking; Finally, make full use of learning resources around you or on the Internet, such as good blogs or public accounts, to learn from the experiences of your predecessors and apply them to practical work.
Let's go back to the subtitle. Regarding the writing of test rules, for junior testers, the front is imitation, and they follow the cases written by experienced people. With more learning, more thinking, more summarizing and sharing, the requirements analysis ability will be greatly improved, and the test rules will be gradually written smoothly.
The test documents don't need to be too complex. They can be compiled directly in excel. Let's take the easy submission of regular department of the core system deposit module as an example. Please see the following figure:
(2) Preparation of test cases
As early as when developers are designing and coding, testers are constantly refining and adjusting test plans and completing the writing of test cases. The writing of test cases is actually to refine specific test cases based on the above test rules, including test goals, test environment, input data, test steps, expected results, etc.
However, the degree to which test points are refined is a matter of degree. We must grasp the degree to which test points are refined. Test points that are too thick have no guiding significance, and test points that are too thin can easily be corrected by us. If we ignore the overall test, we will not have a guiding effect, so we must grasp the degree to which test points are refined. So what problems do you encounter as a novice getting started?
For example, there are a lot of people who don't know how to start writing test cases, but are afraid to start writing test cases, and are worried that the overall test plan will be affected due to their delays. Regarding the mentality of being afraid of wolves before and after tigers after, the suggestion is not to worry about whether your own case is good or not, and write it down first; or refer to previously written public test cases, or even directly quote it, so that some unnecessary time can be avoided. Waste, but reference does not mean copying. While quoting, you must also think about your own unique test points for this requirement.
Secondly, test cases will participate in case review, and senior testers and business personnel will check them. Problems in the test cases will be discovered, and the reviewers will give everyone modification opinions. So, settle down and write the test cases you think of, so that you can help identify problems and better solve them.
In addition, everyone's test cases cannot be said to be perfect and comprehensive. They are all tried to be as comprehensive as possible and have a higher coverage rate during the continuous review process. However, old employees have more experience and experience than Xiaobai, so there must be a suitable method in the process of writing test cases. Next, let's take mobile banking as an example to open regular lump-sum deposits and withdrawals to share dry goods so that all the "clever women" tested have rice to cook.
(3) Test case review
After the test case is written, the test manager will organize a test case review, which means checking the test case. Generally, before developers send transactions or functions for testing, the main stakeholders in the business or technology must participate in the review and review cases one by one to reconfirm whether everyone has a consistent understanding of the requirements. Test case review is an extremely critical part of the testing process. Why is case review so important?
First of all, the review of test cases can not only eliminate deviations in the understanding of requirements documents among product, development, and testing parties, but also ensure that test internal personnel, namely test executors and test case designers, maintain consistency in test quality assurance;
Secondly, through test case review, product and development can evaluate the rationality and comprehensiveness of the case and point out unreasonable or omissions in the case design, so as to better improve the test case and improve the quality of the test case.
Moreover, if the development cannot hold a technical review meeting due to various restrictions, then the case review can also communicate with the development to confirm the implementation method and pay attention to the test points of different implementation methods to achieve comprehensive testing;
Finally, as the saying goes, testers are the headlights of the project and a role in exploring the road. As the saying goes, good doctors treat the disease before it is sick, testers should dig more potential pits in the early stage of the project, remind developers to pay attention to prevent them from falling out, and at the same time It also reduces the probability of bugs appearing and reduces development and testing costs.
Therefore, because many requirements 'details cannot be fully considered during the requirements stage, repeated communication will be used to continuously refine them with relevant personnel. Generally speaking, this review will be repeated about three times in order to improve the case. Later, cases will be reviewed selectively and quickly because the project schedule is too tight or the demand changes are too frequent.
(4) Smoke test
The test case review passed, and after the development submitted the test, the testers quickly completed a round of "smoke testing". The purpose of smoke testing is to confirm whether the basic functions are normal, and subsequent formal testing can be carried out to minimize the risk of unknown formal testing and prevent bug blockages that cause test progress to be blocked. However, there are also projects where smoke testing will start halfway through the review, and smoke will be smoked while reviewing.
From the perspective of the core development team, generally before notifying testers of smoke testing, the development team will conduct some transaction verification in advance. Especially during the migration smoke testing stage, leaders from all parties pay special attention to it, because migration smoke problems directly affect the start time of UAT or whether it can be put into production as scheduled. Therefore, basically if there are problems, they will require immediate resolution, immediate verification, or resolution within the same day, and project assistants will continue to follow up, confirm one by one, collect feedback, etc.
In addition, there are two suggestions for the construction of smoking test cases: one is to communicate with the development manager to confirm the new function points; the other is to determine which of the original cases are still valid on the new project and delete test cases that are no longer applicable, thereby creating a new set of test cases.
(5) Functional review
At the same time that testers begin to execute test cases, business personnel will organize a "functional review meeting" or "demonstration meeting" to use the test environment to show the available functions to relevant stakeholders as soon as possible, further ensuring that what is done is what everyone wants.
(6) Testing
Next, the tester will do multiple rounds of testing, which is a cyclic process of "discovering bugs, developing fixes, retesting, and discovering new bugs." Starting from the second round, it can be called "regression testing". After multiple rounds of testing, the project will require each user representative in the bank to do more detailed UAT.
Generally speaking, at the end of SIT or in the early stages of UAT, it is the time when there are the most defects and the most difficult time period for developers (personally, I don't know what testers experience at this stage).
During this period, you will encounter various problems, such as inconsistent parameters, inconsistent functions after repeated modifications, incorrect printout fields, failed re-test in cases where the test was successful due to poor version management, solving a bug resulting in the emergence of new bugs, overdue resolution time, and various errors reported in batches at night, whether someone is urging progress, etc., which makes people overwhelmed and confused.
In fact, the more times like this come, the more we can't be anxious and calm. The biggest bugs have to be dealt with one by one. Adjust your personal status and your way of doing things, survive this period, and you will be much better in the future. After multiple rounds of UAT testing and all the bugs are properly dealt with, it will enter into UAT closing, program version sealing, parameter verification and sealing, drills and production preparation.
At this time, commercial preparations have already begun. Business personnel may have to prepare user-oriented functions, documents introducing point-of-purchase points, and announcements of product updates; train service personnel and sales personnel; operations personnel may have been planning promotion plans; sales personnel may be updating sales statements...······
★ Noun explanation
Smoke Test: It can be understood that the test takes a short time and is enough to use only one bag of cigarettes. Others have the task of visually comparing the basic functions of the new circuit board. After any new circuit board is welded, power on first for inspection. If there are design defects, the circuit board may be shorted and the board will smoke.
UAT (User Acceptance Test): User Acceptance Test. Of course, it is better to let users test directly.
Acceptance Test: In addition to briefly testing all functions and performance of the system, it is also necessary to check whether project deliverables, such as project phase documents, user manuals, etc., are complete and comply with specifications.
Regression Test: After the modified code is deployed, it retests the previous bugs and verifies the correctness of the version. Often, when a system is launched, it has to go through multiple returns. Some companies adopt multiple rounds. The first round, second round, third round, etc. are all forms of regression testing, but the test focus of each round (regression) is different.
Bug: refers to defects or faults. The difference is that those discovered before the project is launched are called defects, and those discovered after the project is launched are called faults. Generally, faults will cause harm to users. The team has also formulated a grading system for faults and formulated corresponding penalties for those responsible.
2 Classification and basis for bank testing
In the computer industry, developers will have their own main areas involved in actual development work, cobol, java, python, php, C, etc. The same goes for testers, so there are many categories of bank tests. According to the content of the test, they can be divided into: functional testing, performance testing, security testing and other natures.
(1) Functional test
Functional testing can be divided into module functional testing, business functional testing, scenario functional testing and message functional testing. Let's continue to take the lump-sum deposit and withdrawal function of mobile banking as an example:
Module function testing, such as additions, deletions and changes, selection of drop-down boxes, entry of value ranges, and reaction after clicking a button; business function testing, such as regular conversion function testing; scenario function testing, such as fixed deposit process, early account cancellation, early partial withdrawal, concatenation of business functions; message function testing, such as interactive message testing with the payment system or core system.
(2) Performance test
Functional testing can be divided into large-capacity scenario testing, end-to-end concurrent testing, baffle testing, and business stress testing.
(3) Safety testing
Security testing can be divided into message encryption testing, password security testing, penetration testing (firewall), and channel transmission security testing.
(4) Other nature
Other properties are divided into system testing, hardware testing (POS machines, smart counters), and peripheral testing (ATM).
Then let's talk about the basis for the test.
The basis for the test can be divided into six points:
- Banking business rules, such as "Relevant Provisions on Chinese Capitals in Bank Cheques";
- Business scenario requirements, such as transfer business scenarios;
- Accounting bookkeeping rules, such as debit and credit bookkeeping;
- Various documents issued by the Central Bank, such as the People's Bank of China's "On Implementing the Classification Management System for Personal Accounts";
- Input each requirement document, such as fixed deposit function book;
- Others, such as system prototypes.
3 Case design for bank testing
(1) Case design classification
(2) Requirements and guidelines
(3) Precautions
4 Bank test execution requirements and criteria
(1) Test execution requirements and criteria
Execution should be carried out strictly in accordance with business scenarios and business processes.
The test data used must be reliable and complete.
Test execution result data must be stored correctly and calculated correctly.
Pay special attention to the verification and retention of evidence after implementation.
During the test execution process, the actual operation scenarios of different users must be considered, and the control conditions of authority control such as different institutions, positions, and passwords must be involved during execution.
(2) Implementation precautions
Strictly follow the case to ensure the consistency of test and case content.
Test data is reliable and effective data produced in accordance with business processes, and is not random data added manually.
The focus of batch transactions is on the status changes, calculation changes, and migration correctness of the batch data being processed.
Pay special attention to issues that are inconsistent with the expected results in the case.
Arrange cross-testing whenever possible.
concluding remarks
Earlier, some friends proposed to transfer from testing to development or requirements positions. I think the main thing depends on what you are good at or like. For example, if you are good at communication or coordination, it will be better to meet the needs; if you like technology in the blink of an eye, you can better use your skills when you transfer to a development position; if you are good at reverse thinking and are good at discovering abnormalities and branches outside the main body, then you will do testing. Very good. Let's stop talking about testing first. Interested friends can pay attention and expand when they have the opportunity.
References and Notes:
"Test Case Design Summary"
"Summary and Reflection on Functional Testing by Test Boss"
"ATTesting Sharing Conference-Banking Industry Test"
Author Dai Tangming
Transferred from the public account: Xiaodai Toba Too
Original link: https://www.example.com