180 simple test Cases for B/S and C/s architecture

This is a test checklist for web applications and desktop applications. Note: This article articleA bit long, my goal is to be able to share one of the comprehensive test lists that have been started but not yet completed. I will continue to update the list with many scenarios.　　If you don't have time to read now, feel free to share it with your friends and bookmark them for later reading. Test clearance Test CasesAn integral part of the writing process. With this checklist, you can easily create hundreds of test cases to test your Web or desktop applications. These are commonly used test cases and are basically applicable to all applications.　　As you reference this checklist when writing test cases for your project, I believe that you can overwrite most test types in addition to the specific business rules in the software Requirements Specification documentation.　　Although this is an ordinary list, I recommend using the following test cases to prepare a standard test list based on your specific needs and specific tests.　　The importance of applying test manifests during testing:-Maintaining a standard test case library for your application will ensure faster capture of the most common defects.　　-Reusing test cases can help save resource costs for writing repetitive use cases.　　-important test cases that are often overwritten cannot easily be forgotten.　　-The test checklist can be provided to developers to ensure that some common problems are avoided during the development phase.　　Note: 1) perform these test scenarios with different user roles, such as: Manage Users, guest users, etc.　　2) for Web applications, these scenarios should be tested on various versions of the client-approved browsers, such as Ie,firefox,chrome,safari.　　3) test with different screen resolutions, such as: 1024x768,1280x1024, etc. 4) Applications should be tested on a variety of displays, such as: LCD,CRT, notebooks, tablets, smart Mobile Phonesuch as 5) test the application on different system platforms, such as: WindowsMac Linuxand other systems. Comprehensive test Checklist for Web and desktop applicationsAssume that your application supports the following features:-Forms with multiple fields-child windows-with DatabaseInteraction-      Multiple query filtering rules and results display-      image upload-      Email-      Data guide Out of the general test scenario 1.   All required fields should be calibrated and marked with an asterisk "*" 2.   Verify that the error message should be properly displayed in the correct location 3.   All error messages apply the same CSS style display (e.g. red) 4.   General confirmation information should be displayed in an unexpected CSS style (for example: green) in error message 5.   Tip information should be meaningful 6. The first entry in the   drop-down field should be blank or text 7 like "Please select".   Delete any record information on the page should be required to confirm 8.   If the page supports the Add/Remove/update feature of the record, then the page should provide a selection of "Select All" and "none" for all records 9. The   quantity value should display the correct currency symbol 10. The default page ordering should be provided 11. The reset button feature should set all page fields to the default value of 12. All values should be correctly formatted with 13. The input field should check the Maximum field value and enter a value that exceeds the specified maximum value that is not accepted or stored in database 14. Check all input fields for special characters in case 15. Use standard field labels, such as: A field label that accepts a user's name can be defined as "name" 16. Check the sorting function of information records in page after Add/edit/delete operation 17. Check the timeout function, the value of the timeout should be configurable, and check if the application behaves reasonably 18 after the operation times out. Check the use of cookies in the application 19. Check to see if the downloadable file points to the correct file path 20. All resource keys should be configured in the configuration file or database instead of writing dead 21. The naming of resource keys should always follow standard practice 22. Validate all Web page markup (validating syntax errors for HTML and CSS) to ensure that it complies with standard 23. The application crashes or the pages that are not available should be redirected to error page 24. Check spelling and grammar errors for text in all pages 25. If you check the input characters in the numeric input field, you should prompt for the appropriate checksum information 26. If the field allows you to enter a numeric value, you should check the case of negative input 27. Check the Quantity field value with a decimal condition 28. Check the function of all the buttons on the page 29. When the user clicks the submit button continuously, they cannotRepeat submit page Information 30. The case of dividing by 0 should be handled in any calculation 31. Spaces before and after the input data should be handled correctly GUI and usability test scenarios1. All fields on the page (such as text boxes, radio options, drop-down lists) should be aligned appropriately 2.  Except for special designations, the values are aligned to the right by 3.  There is enough space between the field labels, columns, rows, and error messages to 4.  Scroll bar 5 is enabled only if necessary.  The title's font size, style and color, description text, label, field built-in data, and tabular information should all be specified in the software Requirements specification as standard 6.  The Description text box should be a multiline text box 7.  The disabled fields should be grayed out and users cannot set keyboard attention to these fields 8.  Mouse clicks on any field of the input text, the mouse arrow strain is cursor 9. Users cannot enter information in the drop-down selection list 10. When there is an error in the submitted page, the information that the user fills in should remain unchanged, and the user should be able to submit 11 again after correcting the error message. Check that the field label mentioned in the error message is correct 12. The drop-down field values should be in the defined order of 13. tab and SHIFT + TAB keys function normally 14. The default radio option is 15 pre-selected when the page is loaded. The Special field and page level help information should be available in 16. Check that the corresponding field 17 is highlighted correctly when an error occurs. Checks whether the options in the drop-down list are readable and does not display 18 because of field length truncation. All the buttons on the page can be operated by shortcut keys, and the user can do all the operation 19 through the keyboard. Check that all pictures cannot be displayed on page 20. Check all links fail page 21. All pages should have heading 22. A confirmation message 23 should be displayed before any update or delete operation is performed. Hourglass Timer 24 should be displayed when the application is busy. The page text should be left-justified 25. The user should be able to select a single option or any combination of multiple selections Filter Condition test Scenario1. The user should be able to filter the results by using all the parameters in the page 2.  The exact search function should load search Page 3 based on all search parameters selected by the user.  When you need at least one filter in the page to perform a search operation, you must ensure that the user does not set any filter criteria to display the appropriate error message 4 when submitting a query.  When at least one filter in the page is non-mandatory, the user submits the query after those non-mandatory filters use the default search criteria to query the results 5. The appropriate checksum information should be displayed when the filter condition is set to an invalid value Results Table test Scenario1. When the result page loads longer than the default length, you should see a message like "page loading" 2.  Check whether the data obtained in the results table satisfies all of the search criteria 3.  The total number of results should be shown in the results table 4.  The search criteria that you use should display 5 in the results table.  The values in the results table should be sorted by default column 6.  The sorting sequence should show the sorted icon 7.  The results in the results table are correct and contain all the specified Column 8.  For columns that support sorting, you should be able to sort operations in ascending and descending order 9. The row and column spacing in the result table is reasonable 10. Page 11 should be correctly paged when the result is more than the number of results displayed by default per page. Check Previous, Next, first, and last page pagination features 12. There are no duplicate records in the results table 13. Check that all columns are visible and enable horizontal scroll bar 14 if necessary. Check the Data dynamic column (column values are computed by other columns) 15. For the report results table, you should check the value of row totals and column totals 16. For a report results table, you should check the total value of 17 when the user switches paging when the page is paged. Check that the display column uses the correct symbol, such as:% (percent sign) should be displayed in the percentage calculation result of 18. Check whether the data in the results table has date ranges enabled window Test Cases1. Check that the default window is the correct size 2.  Check that the child window is the correct size 3.  Checks whether the default focus is placed on a field in the page (typically, the focus is on the first field in the page that can be entered) 4.  Checks if the child window 5 is closed when the parent window or open window is closed.  When the child window is open, the user cannot use or update the field value 6 of the window after the parent window or child window.  Check the window minimize, maximize, and close function 7.  Checks whether the window can reset size 8.  Check the parent window and the child window of the scroll bar function 9. Check the function of the Cancel button in the child window Software Testing 180 Comprehensive cases 3 Database test Scenarios1. Check that the data is correctly stored in the database when the page is submitted successfully 2. Check for column values that do not accept null values 3. Data should be stored in a single or multiple tables according to the table Design 4. The index name should follow the criteria such as Ind_ < table name > _ < Column name > 5. Table should have primary key 6. Table The columns in the column give the corresponding descriptive information (in addition to audit columns such as creation time, creator, etc.) 7. You should add log 8 for each database Add/update operation. You should create an index for the required table 9. Check that the data is submitted to the database only after the operation has been completely successful 10 The database name should be named after the application type, i.e. test, UAT, sandbox, on-site (although this is not a standard, but very helpful for database maintenance) 12. The database logical name should be named according to the database name (this is not a standard but facilitates database maintenance) 13. Stored procedures should not be prefixed with "sp_" Name 14. Check the Table audit column values (such as creation date, creator, update date, update, deleted, deleted date, deleted by, and so on) are populated correctly 15. Check that the input data is not truncated when it is saved, that the field length displayed on the page and the field length of the database should be the same 16. Check for minimum,　　Maximum and floating-point numeric fields 17. Check that numeric fields contain negative values (both accept and reject) 18. Check radio buttons and drop-down lists are correctly saved in the database 19. Check that the data type and data length of the database field design are correct 20. Check that all table constraints, such as primary key, foreign key, etc. are implemented correctly 21. Test sample input data for stored procedures and triggers 22. The first and last spaces of the input data should be automatically hidden before the data is saved to the database 23. The primary key column does not allow null values test scenario for image upload function(also applicable to other file uploads)　　1. Check the image upload path 2. Check image upload and modify function 3. Check the upload of various extended image files (e.g. JPEG, PNG, BMP, etc.).　　4. Check upload of a picture with a space or other available special characters in the file name 5. Check duplicate name picture upload 6. The image size is larger than the maximum allowable value, and the appropriate error message should be displayed when uploading. 7. Check for other files (such as TXT, doc, pdf, EXE, and so on) outside of the uploaded image file type, and you should display the appropriate error message 8. Check if the uploaded picture satisfies the specified height and width (if any), it can be uploaded successfully, otherwise it cannot upload 9. Upload a large image should display the upload progress bar 10. Check that the Cancel button in the upload process is valid 11. Check whether the file list in the File Selection dialog box displays only the supporting file type 12. Check the ability to upload multiple images 13. Check image quality after uploading, image quality should not change 14. Check that users are able to use/view uploaded images test scenario for sending e-mail(Test cases do not include compose or validate e-mail)　　(Be sure to use a fake email address before performing a mail-related test) 1. All email templates should use CSS Standard 2. To verify the email address before sending an email 3. Special characters should be handled properly in the message body Template 4. Language-specific characters (for example, Russian, Chinese, or German) should be handled properly in the e-mail body template 5. E-mail subject cannot be empty 6. Placeholder fields that use e-mail templates should be replaced with actual values such as {last name} {name} should be replaced by all recipients with the correct first and last names 7. If the report has dynamic values contained in the body of the e-mail message, the report data should be calculated correctly 8. The name of the e-mail sender cannot be empty 9. e-mail should be checked in different email clients (e.g. Outlook,gmail,hotmail,yahoo mail, etc.) 10. Check the Send e-mail feature using the To, Cc, and Bcc fields 11. Check for plain text messages 12. Check e-mail 13 in HTML format. View message headers and footers corresponding company logos, privacy policy and other links 14. Check email with attachments 15. Check Send e-mail to one, multiple, or contact groups 16. Check that the reply e-mail address is correct 17. Check to send a large number of emails Excel export feature test scenario1. File output should have the appropriate file extension 2. The filename of the exported Excel file should be in accordance with the standard, for example: If the file name is named using time, it should be converted to the actual time 3 when the files are exported. When an Excel file contains a date column, you need to check the exported date format 4. Check numeric or currency values in numeric format and the format should be the same as the page display 5. The exported file should have the appropriate column name 6. The default page sort should be reflected in the export file that the 7.Excel file data should be formatted correctly including header and footer text, date, page number, and all page values 8.　　Check that the files displayed on the page are the same as the exported Excel file 9. Check the export function when paging is used 10. Check that the Export button icon is displayed correctly based on the exported file type, such as: an. xls file is exported, and the icon for the Excel file is displayed 11. Check the export function of large files 12. Check the export feature of the page that contains special characters, check whether these special characters are exported to Excel file correctly Software Testing 180 Comprehensive cases 4 test scenarios for performance testing1. Check that the page load time is within the acceptable Range 2. Check page load slow links 3. Check the response time of all operations in mild, normal, moderate, and heavy load environments 4. Check the performance of database stored procedures and triggers 5. Check database query execution time 6. Check the application's Load test 7. Check Application Stress Test 8. Check CPU and memory usage under peak load conditions Security test test Scenario1. Check for SQL injection attacks 2. The Security page should use HTTPS protocol 3. The crash page should not leak application or server information, only the error page displays these 4. Enter 5 for escaping special characters. Error messages should not disclose any sensitive information 6. All credentials should be passed through an encrypted transport Channel 7. Test password security and password enforcement policies 8. Check the logoff function of the application 9. Check for brute force attacks 10.Cookie information can only be stored in an encrypted format 11. Check the session cookie duration and sessions time-out or logon session termination condition 12. The session token should pass through the secure channel 13.　　Passwords should not be stored in cookies 14. Testing for blocking service attacks 15. Detecting a memory leak 16. Access unauthorized applications by manually changing the variable values in the browser address bar 17. Verify how the file name extension is handled so that the. exe file cannot be uploaded to the server or executed on the server 18. Automatic completion should not be enabled for sensitive areas such as passwords and credit card information 19. File upload feature should use file type restrictions and anti-virus scanning of files uploaded by 20. Check that the directory is available 21. You should be disguised when you enter passwords and other sensitive fields 22. Check if the forgotten password is password protected , such as: The temporary password expires after a specified period of time, change the password or get a new password have security questions and so on 23. Check the CAPTCHA function 24. Check that important events are logged in the log file 25. Check that the test cases for access rights penetration testing are correctly implemented--　　On this page I have listed 41 test cases for penetration testing I sincerely thank Devanshu Lavaniya (Sr. Quality Engineer working at I-link Infosoft) to help me prepare a comprehensive test checklist. I tried to cover all the standard Web and desktop application features of the test scenario, but I know that this is not a complete list.　　Testers prepare their own test lists based on their experience in different projects.　　Add more test scenarios or negative test cases to the following notes to make them a relatively complete list. I would appreciate it if you would share this with your friends.

180 simple test Cases for B/S and C/s architecture (RPM)