How to use design test cases to test online bank transfers?

Table of contents

foreword

  1. How to test online bank transfer, design a test case.

  Answer ideas:

  2. The process of testing work? What are the defect states? How many ways are there to design test cases?

  After modification, there are two processing situations:

  3. What is the classic BUG found in the project?

  4. How to measure the automatic transfer of fixed deposits upon maturity?

  How to test saving money, what test method to use?

  5. How to design test cases for the login function?

  Function Test (Function Test)

  UI Test (UITest)

  Performance Test (PerformanceTest)

  Security Test (SecurityTest)

  Usability Test (UsabilityTest)

  Compatibility Test (CompatibilityTest)

  6. What is the core business of the e-commerce platform? How is the shopping cart tested?


foreword

Software testing is the process of executing a program in order to find bugs in it.

In layman's terms, software testing needs to find software errors as much as possible before releasing the software, try to avoid giving users a bad experience after release, and meet the needs of users.

  1. How to test online bank transfer, design a test case.

  Answer ideas:

  Macroscopically, it can be considered from the quality model (universal formula), and the key point is to test the function, performance and security of the transfer. The design of test cases can use the scenario method as the main method, and first list the basic flow and alternative flow of the transfer. Then design the scene, and finally design the data according to the scene. Specific examples are required during the actual interview.

  · Check the interface first

  ·Retest function:

  Verify peer transfers and inter-bank transfers.

  Verify the transfer limit.

  Verify transfers from illegal accounts (reported lost, frozen, locked accounts).

  Then test performance.

  2. The process of testing work? What are the defect states? How many ways are there to design test cases?

  The actual workflow of the test engineer (take the P2P medium-sized version as an example, one version per month):

  The product manager or SR sends the requirement book to development and testing.

  Take a look at the test first and conduct a demand analysis. The test team leader writes the test plan and assigns test tasks to testers (2 days) (at this time, the development is also conducting demand analysis)

  After 2 days, the product manager called the testing and development together again to explain the requirements (or review the requirements). If you have any questions, you can ask them directly. If you find any problems with the requirements, you can also raise them, and the SR will revise them when you go back. (Required explanation time 0.5 days)

  After talking about the requirements, the test colleagues have to sort out the test scenarios and write the cases (xmind and Excel will be used), a total of 5 working days. (Development is writing code at this time)

  Afterwards, the case review will be conducted. During the review, there are SRs, testing colleagues, and development colleagues. During the review, generally SRs, test team leaders, and development colleagues of the corresponding modules will give some comments. After the review, go back to modify and supplement the case. (0.5 days for case review).

  After modification, there are two processing situations:

  A second case review is sometimes required for large projects.

  For small projects, when the time is tight, the second trial is generally not carried out, but the revised or newly added case should be sent by email for the leader to see, and a copy should be sent to other colleagues. (0.5 days for case review, 0.5 days for case modification, and 0.5 days for case second trial)

  After the case review, the test will start. Generally, the test environment has been developed and set up (if you say you can build it yourself, the build process will be summarized by the teacher):

  The test of the medium-sized version is generally divided into 2 rounds: the first round: 5 days; the second round: 3 days; the regression test 2 days; (a total of 10 working days).

  After the regression test is completed and the online standard is met, it will go online as scheduled, usually at 12 o'clock in the evening on the same day.

  3. What is the classic BUG found in the project?

  Compatibility issues, in the IE browser, the submit order button can be clicked, but in Google, Firefox cannot.

  Query the order page, the results filtered according to the conditions are not the desired results, and the values ​​of some fields are not displayed, or are displayed incorrectly. (Because the value obtained from the library table during development is wrong)

  After the payment is successful, the order status has not been turned over to a successful transaction. (Because the code does not correctly obtain the status code of the successful payment record in the library table)

  Change the payment password, the new password is consistent with the original password, and it has passed, the system has not verified the old and new passwords.

  The mobile phone verification code at the time of payment can be used all the time, and the validity period control is not successful.

  After the mobile app is disconnected from the network, click again, there is no friendly error page indicating that the network has been disconnected, only undefined is returned.

  4. How to measure the automatic transfer of fixed deposits upon maturity?

  Answer idea: there will definitely be a boundary when it expires, so the boundary value method can be considered in the design. Automatic dump. (First of all, we must figure out what is automatic dump)

  How to test saving money, what test method to use?

  Preparation ideas: Saving money should be classified into: current demand, zero deposit and lump sum withdrawal, etc. (under Baidu for specific rules), and then choose the appropriate use case design method according to the business rules of each category. For example, how much is the minimum deposit at one time? The maximum amount that can be deposited at one time, etc.

  5. How to design test cases for the login function?

  Function Test (Function Test)

  1. Enter the correct account number and password, click the submit button, and verify whether you can log in correctly. (normal input)

  2. If you enter a wrong account number or password, the verification login will fail, and a corresponding error message will be prompted. (error checking)

  3. Can you jump to the correct page after successful login? (Low)

  4. If the account number and password are too short or too long, what should be done? (Security, whether there is a prompt when the password is too short)

  5. There are special characters (such as spaces) in the account number and password, and other non-English situations. (filtered or not)

  6. The function of remembering the account number.

  7. After the login fails, the password cannot be recorded.

  8. There are spaces before and after the account number and password.

  9. Whether the password is encrypted and displayed. (asterisks, dots, etc.)

  10. If the verification code is involved, it is also necessary to consider whether the text is too distorted to make it difficult to identify, consider the color (for color blind users), and whether the refresh or change button is easy to use.

  11. Are the links on the login page such as registration, forgot password, logout and login with another account correct?

  12. When entering the password, there will be a prompt message when the uppercase keyboard is turned on.

  13. Do not enter anything, click the submit button, and see the prompt information. (not null check)

  UI Test (UITest)

  1. Whether the layout is reasonable, whether the two Testboxes and a button are aligned.

  2. Whether the length and height of the Testbox and the button are combined.

  3. Whether the design style of the interface is consistent with the design style of the UI.

  4. The text in the interface is concise and easy to understand, without typos.

  Performance Test (PerformanceTest)

  1. It takes a few seconds to open the login page.

  2. After entering the correct account number and password, the login will jump to a new page after successful login, within 5 seconds.

  Security Test (SecurityTest)

  1. Whether the cookie generated after successful login has HttpOnly. (Reduce the risk of script theft)

  2. Whether the account number and password are sent to the web server in an encrypted manner.

  3. The verification of the account number and password should be verified by the server side, not just by javaScript on the client side.

  4. The input box for account number and password should shield SQL injection attacks.

  5. In the input box of account number and password, the input script should be prohibited. (to prevent XSS attacks)

  6. Limit the number of wrong logins. (to prevent brute force cracking)

  7. Consider whether to support multiple users logging in on the same machine.

  8. Consider a user logging in on multiple machines.

  Usability Test (UsabilityTest)

  1. Whether it is possible to use the keyboard for all operations, and whether there are shortcut keys.

  2. Enter the account number and password and press Enter to check whether you can log in.

  3. Whether the input box can be switched with the Tab key.

  Compatibility Test (CompatibilityTest)

  1. Whether it can be displayed normally under mainstream browsers has already functioned normally. (IE6~11, FireFox, Chrome, Safari, etc.)

  2. Whether different platforms can work normally, such as Windows, Mac.

  3. Whether it works normally on mobile devices, such as iPhone, Android.

  4. Different resolutions.

  6. What is the core business of the e-commerce platform? How is the shopping cart tested?

  The e-commerce platform is mainly a product sales platform, so product search, adding to the shopping cart, settlement and payment are the core business of the e-commerce platform, that is, the entire product purchase process.

  The test of the shopping cart mainly considers the following aspects (just master the idea):

  1. Interface test, whether the product information in the shopping cart is displayed normally, and whether the price of the product added to the shopping cart is displayed normally.

  2. Functional test, whether the product can be added to the shopping cart from the product details page.

  3. When the shopping cart page is opened, products are added on other pages. After the shopping cart is refreshed, can the new products be displayed.

  4. If you are not logged in, click to add to the shopping cart, whether you can add it to the shopping cart (cache method) or you will be prompted to log in directly.

  5. When the product is not selected, the checkout button is gray and cannot be clicked.

  6. After selecting the product, the checkout button will be clickable.

  7. After the item is selected, the total price of the item is automatically calculated to check whether the price is correct.

  8. After selecting the product, click the checkout button to enter the confirmation list page

  9. In the shopping cart, you can modify the quantity of the product.

  10. In the shopping cart, you can remove the added products from the shopping cart.

  11. In the shopping cart, you can move the product into the favorites. After being moved into the favorites, the products will not be displayed in the shopping cart.

  12. Whether the products in the shopping cart display discount or promotion information.

  13. Add items to the shopping cart in batches.

  14. Remove items in batches from the shopping cart.

  15. Performance testing.

  16. How long does it take to open the shopping cart page.

  17. How many items can be added to the shopping cart at most.

  18. What is the speed of adding and removing items in batches?

  19. Compatibility testing.

  20. If it is a web mall, test whether the function is normal on different browsers.

  21. If it is an app, test whether the functions are normal under different mobile phone brands, different operating system versions and different resolutions.

 As someone who has been here, I also hope that you will avoid some detours. Here I will share with you some necessities on the way forward for automated testing, hoping to help you. (WEB automated testing, app automated testing, interface automated testing, continuous integration, automated test development, big factory interview questions, resume templates, etc.), I believe it can make you better progress!

Just leave [Automated Test] [Automated Test Communication]: 574737577 (remark ccc) icon-default.png?t=N4P3http://qm.qq.com/cgi-bin/qm/qr?_wv=1027&k=1MDs4T0SvhL4arRoq3njIVb9HGXrRoj6&authKey=sx1h5dj77OV5obrcx6nE7Dn3sqEVuE4XrG qzqneReBJy3ojOL3oHMSH48XPKPWhW&noverify=0&group_code=574737577

 

 

Guess you like

Origin blog.csdn.net/Free355/article/details/131088214