Test must ask face to face by huazi~

1. Test Basics

Test definition: test operations are performed manually or with the tool "tested object"

Test purpose:

  • The starting point of positive thinking: make yourself sure that the product can work normally, evaluate the characteristics or capabilities of a program and system, and determine whether it achieves the desired results. Software testing is any behavior for this purpose.
  • Reverse thinking: testing is the process of executing a program or system to find errors. Testing is to prove that the program is wrong, not to prove that the program is error free. A good test case is that it can find previously undetected errors. A successful test is a test that finds previously undetected errors.

In short, the purpose of software testing is to find out the hidden defects in software products as early as possible and ensure that they can be repaired!

Test principle:

1. The test shall be based on customer requirements

All testing work should be based on meeting the needs of customers. From the perspective of customers, the most serious error is that the software can not meet the requirements.

2. The test shall be carried out as soon as possible

Software errors exist in all stages of the software life cycle, so we should carry out testing as soon as possible and run software testing through all stages of the software life cycle, so that testers can find and prevent errors as soon as possible and reduce the cost of error repair. Carrying out testing as soon as possible is helpful to help testers understand the needs and design of software products, so as to predict the difficulty and risk of testing, formulate perfect plans and schemes, and improve the efficiency of testing.

3. Exhaustive testing is impossible

Due to the limitation of time and resources, it is impossible to conduct complete (all combinations of various inputs and outputs) testing. Testers can determine the focus of testing according to the risk and priority of testing, so as to control the workload of testing and strike a balance between testing cost, risk and benefit.

4. Follow the GoodEnough principle

The GoodEnough principle means that the input and output of testing should be properly weighed to form a sufficient quality evaluation process, which is based on the cost of testing. Insufficient testing can not guarantee the quality of software products, but too much testing investment will cause a waste of resources. With the increase of test resource input, the test output also increases, but when the input reaches a certain proportion, the test effect will not be significantly enhanced. Therefore, the test input should be considered according to the actual requirements and product quality. It is best to make the test input and output reach a GoodEnough state.

5. Test defects shall comply with the "28" theorem

The "28" theorem of defects is also called Pareto principle and defect cluster effect. Generally, 80% of software defects will be concentrated in 20% modules, and the defects are not evenly distributed. Therefore, when testing, we should grasp the main contradiction. If we find that some modules have more defects than other modules, we should invest more manpower and energy to focus on testing these modules to improve the testing efficiency.

6. Avoid defective immunization

We all know the principle of insect resistance, that is, if a drug is used for a long time, the insect will develop drug resistance. In software testing, defects are immune. If the same test cases are used repeatedly, the ability to find defects will become worse and worse; The more familiar testers are with the software, the more they will ignore some seemingly small problems, and the worse their ability to find defects. This phenomenon is called the "pesticide" phenomenon of software testing. It is mainly because testers do not update test cases in time or are too familiar with test cases and test objects.

Test object:

  • Programs, data, documents.

Generally, the purpose of software testing mainly includes:

  • One is to find program errors and test them
  • Second, testing is used to prove that there are errors in the software program, not to prove that there are no errors in the program;
  • Third, good testing. Its function is to find some errors that have not been found before. Therefore, we must pay attention to the specific purpose of testing and follow the principle of economy when selecting test cases.

Key elements:

Basic concepts of software testing

Software testing is a part of software engineering, and now it becomes more and more important. The basic concepts of software testing are as follows:

1. Why software testing: (software testing has defects)

2. What is software testing: verification and validation, finding bug s

3. What are software defects: bug s, summarized from all aspects

4. Classification of software testing: it is divided into three angles (test method, test target and test object)

5. Scope of software testing work (process): set up a test team, analyze test needs, formulate test plans (including test environment design and construction), design test cases, execute test cases, analyze test results (find out problems and propose solutions), and improve reporting.

6. Software test methods: black and white box test, dynamic and static test, active and passive test, formal test, risk-based test, fuzzy test, ALAC and random test, etc.

7. Software test basis and specification (standard): test process model (v, w, TMap, etc.)

Software Testing Technology (specific operation of testing methods): select the corresponding testing tools or write their own code according to the testing type to complete the testing work. For example, for performance testing, select lr or jmeter to complete the test objectives.

2. Test automation pyhton automated test framework

Automation framework and tools

  1. summary

  • Automation is not recommended for functional testing
  • Interface test has the highest cost performance
  • Interface testing can be automated

The test automation mentioned later will also be introduced around interface automation.

Internet software testing and development based on Python

PyUnit test framework

If you use python as the automation programming language, you will naturally use pyunit as the automation testing framework.

The following parts are mainly from the official documents of pyunit. This paper only makes some translation and simple structural adjustments. This part belongs to the basic principles and concepts of the test framework. It is necessary to understand it before coding.

PyUnit, the unit testing framework of Python, can be regarded as the Python language implementation version of JUnit, the unit testing framework under the Java language. Even Kent Beck, one of its authors, is the author of JUnit.

unittest should achieve the following objectives:

  • Support automated testing
  • Let all test scripts share the setup and shutdown code
  • Test case scripts can be organized through collections
  • Separate all test scripts from the test report framework

In order to achieve the above objectives, unittest supports the following important concepts:

    • test fixture

      Do some preparatory work for one or more test cases, such as connecting to a database, creating a directory, or starting a process

    • test case

      Test case is the smallest unit of test behavior, which is tested and checked by comparing some input and output values

    • test suite

      A collection that aggregates test cases or test case collections. All test cases in a test suite can be executed in batches

    • Test executor

      Organize components that schedule test script execution activities. The test executor displays the test results of the test script through some graphical interfaces, text interfaces or returning some special values. It is mainly used to generate test reports

3 basic examples

The following example is also from the official document basic_demo.py:

# coding:utf-8
"""
Basic automated test scripts basic_demo.py
"""
__author__ = 'zheng'
 
import unittest
 
 
class TestStringMethods(unittest.TestCase):
 
    def setUp(self):
        print 'init by setUp...'
 
    def tearDown(self):
        print 'end by tearDown...'
 
    def test_upper(self):
        self.assertEqual('foo'.upper(), 'FOO')
 
    def test_isupper(self):
        self.assertTrue('FOO'.isupper())
        self.assertFalse('Foo'.isupper())
        self.assertTrue('Foo'.isupper())
 
    def test_split(self):
        s = 'hello world'
        self.assertEqual(s.split(), ['hello', 'world'])
        # check that s.split fails when the separator is not a string
        with self.assertRaises(TypeError):
            s.split(2)
 
 
if __name__ == '__main__':
    unittest.main()

Although the official document describes several ways to organize test case scripts:

  1. Independent test function
  2. Single case test class
  3. Multi use case test class

Different writing forms have different organization methods. For details, see the official documents. After studying the official documents, the author of this paper likes the third method, multi use case test class, which is the basic example above. This method has the following characteristics:

  • The test class inherits from unittest.TestCase
  • A test class can manage multiple test script functions
  • The test script function name needs to be preceded by test_ start
  • All test functions in a test class share the setUp and tearDown functions

Run this program in the console:

➜  src git:(master) ✗ python basic_demo.py
init by setUp...
Fend by tearDown...
init by setUp...
end by tearDown...
.init by setUp...
end by tearDown...
.
======================================================================
FAIL: test_isupper (__main__.TestStringMethods)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "basic_demo.py", line 24, in test_isupper
    self.assertTrue('Foo'.isupper())
AssertionError: False is not true
 
----------------------------------------------------------------------
Ran 3 tests in 0.001s
 
FAILED (failures=1)
➜  src git:(master) ✗

The main function of the previous basic example uses the simplest way to directly run all test cases and generate the default text report. In fact, we only need to make some simple modifications to the calling function. We can reasonably organize these test cases and obtain useful data information, so as to integrate with the information system and form a better expansion.

if __name__ == '__main__':
    # unittest.main()
    # Load test cases
    test_cases = unittest.TestLoader().loadTestsFromTestCase(TestStringMethods)
    # Use the test suite and package the test cases
    test_suit = unittest.TestSuite()
    test_suit.addTests(test_cases)
    # Run the test suite and return the test results
    test_result = unittest.TextTestRunner(verbosity=2).run(test_suit)
    #Generate test report
    print("testsRun:%s" % test_result.testsRun)
    print("failures:%s" % len(test_result.failures))
    print("errors:%s" % len(test_result.errors))
    print("skipped:%s" % len(test_result.skipped))

The output generated after running is:

➜  src git:(master) ✗ python basic_demo.py
test_isupper (__main__.TestStringMethods) ... init by setUp...
FAIL
end by tearDown...
test_split (__main__.TestStringMethods) ... init by setUp...
end by tearDown...
ok
test_upper (__main__.TestStringMethods) ... init by setUp...
end by tearDown...
ok
 
======================================================================
FAIL: test_isupper (__main__.TestStringMethods)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "basic_demo.py", line 23, in test_isupper
    self.assertTrue('Foo'.isupper())
AssertionError: False is not true
 
----------------------------------------------------------------------
Ran 3 tests in 0.001s
 
FAILED (failures=1)
testsRun:3
failures:1
errors:0
skipped:0

Obviously, the above input results have counted the test results. These data are important indicators in a test activity. These data can be stored and integrated with the test information management system. Later, the dashboard or statistical report will be generated to form a stable and product test circuit diagram. These are related to development and will not be described here.

Combined with the above specific examples, we can also find the specific implementation objects corresponding to the theoretical part of the previous section:

    • test fixture

      The setUp function initializes and tearDown destroys

    • test case

      Corresponding to TestCase class, or more detailed corresponding test script function

    • test suite

      Corresponding TestSuite class

    • Test executor

      Corresponding TextTestRunner class

4 IDE tools

Since you need to develop code productivity, you need to introduce an IDE tool -- pychar. It is undeniable that it is the ide of the most dedicated / professional Python language at present. There is also good support for pyunint.

The main support is as follows:

  • Visual programming development (this is the basic feature of IDE)

  • Visual display of test results

  • Export test reports that generate HTML

    • Visual control of use case execution (this is very convenient in the development and debugging stage, and can easily control the operation of specified code units)

      Let all users in a directory execute, let all use cases in a single file execute, and let a single user in a single file execute

4.1 operation and commissioning

Pychart provides flexible running and debugging support for test scripts.

With pycharm, developers can realize the following functions without writing the main function:

  • Run all test classes under a file
  • Run all test scripts for a test class
  • Run a test script of a test class

Among them, "run a test script of a test class" is more useful, which is suitable for rapid development, running and debugging of a single script in the development stage.

usage method:

  1. Move the cursor inside the test function
  2. Press the run shortcut ctrl+shift+F10 (Eclipse shortcut scheme)

If you want to Debug a breakpoint, use the Debug mode to run and Debug a single function.

Of course, you don't have to borrow the IDE, but you can also realize the above functions through the operation of testSuit, but the IDE provides a more flexible and direct choice. These are just some tips for using IDE, and I won't go into more details.

4.2 result visualization

For the example mentioned above, if you choose to run this program in the IDE, you will see the following effects:

You can see that all runs pass. If one of them is deliberately failed, the following results will be displayed:

4.3 generate test report

Pychart also provides the export function of test result report, which is displayed on a function button on the test result display box.

The export results are as follows:

Of course, if you don't consider the integration with the information system, the subsequent dashboard and test statistics, and just want to generate reports, this function is enough.

In general, for automated testing and development, the above skills can fully meet the requirements. The next thing to do is to use all kinds of basic computer knowledge to continuously increase test case scripts in the face of increasing business needs.

The principle of functional development projects is very simple, but with the increase of quantity, they will form a scale, and so will test and development projects.

5 project organization

Previously, the development of test cases and tools in debugging state were introduced. However, if you really want to integrate into the continuous integration automation system, you obviously can't rely on the IDE. Instead, it uses the organization and calling method of python language. For example, there should be a main function as the execution entry, and so on.

The detailed technical implementation details will be introduced in the corresponding articles later.

The project organization mode separated from IDE has the following advantages:

  • All scripts can be executed by event triggering (which can become a part of the continuous integration pipeline)
  • All the data can be put forward and customized processing and processing (integrated with the test information system to provide data source for the quality analysis system)

6 test platform

About how to automatically generate the test report, a test product, some platforms can provide interface call, report display and sharing functions. For details, please refer to:

http://www.jianshu.com/p/c5fa76cf87db

7 Summary

The content of this small part is mainly about some design ideas and basic use examples of pyunit, an automated testing framework based on python language. In fact, the use of tools is very simple, but how to make good use of these tools for software production requires other computer skills. In subsequent articles, we will deeply expand the application of this framework from the aspects of engineering and technology.

3. Basic theory and design method of white box test

Basic static analysis method of white box test

Black box test:

Black box test, also known as function test or data-driven test, is to test whether each function can be used normally when the function of the product is known. During the test, the program is regarded as a black pot that cannot be opened. Without considering the internal structure and internal characteristics of the program, the tester tests at the program interface, It only checks whether the program function is normally used according to the requirements specification, whether the program can properly receive the input data and generate the correct output information, and maintain the integrity of external information (such as database or file).

The "black box" method focuses on the external structure of the program, does not consider the internal logic structure, and tests the software interface and software function. The "black box" method is an exhaustive input test. Only when all possible inputs are used as test conditions, can all errors in the program be found out by this method. In fact, there are an infinite number of test cases, so we should not only test all legal inputs, but also test those illegal but possible inputs.

The common black box test methods are: equivalence class partition method; Boundary value analysis method; Cause and effect diagram method; Scene method; Orthogonal experimental design; Decision table driven analysis; False conjecture; Functional diagram analysis.

White box test:

White box test, also known as structure test or logic driven test, is a test of how the unit under test works. It designs test cases according to the control structure of the program, which is mainly used for software or program verification. The white box test method checks the internal logical structure of the program and tests all logical paths. It is an exhaustive path test method, but even if each path has been tested, there may still be errors. Because: the exhaustive path test cannot check whether the program itself violates the design specification, that is, whether the program is a wrong program; Exhaustive path testing cannot check that the program has errors due to missing paths; Exhaustive path testing does not find some data related errors.

The principles to be followed in white box testing are: 1. Ensure that all independent paths in a module are tested at least once; 2. All logical values need to be tested for true and false; Two cases; 3. Check the internal data structure of the program to ensure the effectiveness of its structure; 4. Run all cycles within the upper and lower boundaries and operational range.

Common white box test methods:

Static testing: testing without running programs, including code inspection, static structure analysis, code quality measurement, document testing, etc. it can be carried out manually to give full play to people's logical thinking advantages, or automatically with the help of software tools (Fxcop).

Dynamic test: you need to execute code and find problems by running programs, including function confirmation and interface test, coverage analysis, performance analysis, memory analysis, etc.

Logical coverage in white box testing includes statement coverage, decision coverage, condition coverage, decision / condition coverage, condition combination coverage and path coverage. The ability of six coverage standards to find errors changes from weak to strong:

1. Each statement shall be executed at least once.

2. The decision covers each branch of each decision at least once.

3. The condition covers each condition determined, and various possible values shall be taken for each condition.

4. The decision / condition coverage meets the decision coverage condition coverage at the same time.

5. The condition combination covers each combination of conditions in each decision at least once.

6. Path coverage enables each possible path in the program to be executed at least once.

4. Defect analysis and management

Defect analysis method, defect management, problem list level definition

1. The basic elements of software defect report include

Defect number, defect title, basic information of defect, software and hardware environment tested, software version tested, defect type, defect severity, defect processing priority, defect reproduction steps, actual result description of defect, expected correct result, intercepted defect image, annotation text, etc

2. Defect status mainly includes:

Active (New / open), repaired, closed, reopened, deferred, unrepeatable, duplicate, not defect

3. The severity of defects mainly includes:

Fatal, serious, general, minor, suggestive

4. What is a software defect?

The so-called software defect refers to a problem, error or hidden functional defect that destroys the normal operation ability in computer software or program. The existence of defects will lead to the software products can not meet the needs of users to some extent. IEEE729-1983 has a standard definition of defect: from the internal point of view of the product, defect is the error, fault and other problems existing in the process of software product development or maintenance; From the outside of the product, defect is the failure or violation of a function that the system needs to realize.

5. How to judge whether it is a software defect?

Poor user experience

There are obvious error messages on the interface

The function is incomplete, resulting in the loss of function

Imperfect function

Incorrect logic, inconsistent with requirements specification

The interaction between modules is not good, and problems are encountered in integration testing with other modules

The performance of the program is not good enough to bear the pressure test

6. Which five principles must software defects comply with?

The software does not reach the function indicated in the product manual

The software has errors that the product manual indicates will not occur

The software function exceeds the scope specified in the product manual

The software fails to achieve the goal that should be achieved although not specified in the product manual

Software testers find it difficult to understand, difficult to use, slow to run, or bad for end users

7. What are the main causes of defects? What is the main reason?

No instruction, design, coding, other

No instructions were prepared

8. When you find a defect, how should you confirm that it is indeed a defect?

Firstly, software requirements specification, user manual and online help can be used as auxiliary tools to identify and judge defects.

Secondly, by increasing their understanding of the industry background knowledge of testing software products, they can find the neglected problems.

Finally, collect, learn and share the methods and experiences of others to judge defects through communication.

9. What should you do before formally submitting a defect?

Reconfirm whether it is a defect, record each step of defect inspection (current defect), prepare defect report and submit defect report

10. How to deal with the defects that cannot be solved?

First, such defects should be recorded in detail and submitted to developers as soon as possible

Secondly, we should reasonably arrange the time to find the defects that are difficult to reproduce

Finally, pay attention to the defects that are not in progress during the test

11. What is a duplicate defect? How to avoid repeated defects?

It refers to the same type of defects that occur again in the statistical cycle.

A person can enter keywords to filter when submitting a test.

Multi person testing should be conducted in modules as much as possible, and should be screened before submission. Avoid duplicate submissions.

12 what are invalid defects? How to avoid invalid defects?

Software products that do not meet user needs can be identified as software bugs. Here, software products can be code segments, applications, software systems, product documents and other products of any software engineering behavior.

Refine requirements before submission to ensure correct understanding of requirements and avoid ambiguous defects in submission:

For the defects that you cannot grasp, discuss them before submitting

Before submitting a bug, you must ensure that the bug can be reproduced, and clearly describe the reproduction steps in the bug

Ensure the accuracy of the test environment and do a good job in version configuration management

13. What is a defect report? What are the uses?

It is used to record defects, classify defects, allocate reasonable resources to solve different defects, and track the defect handling process through defect report, so as to repair software defects.

Recording defects, defect classification and defect tracking

14. What are the five writing guidelines for defect reports?

Accurate, clear, concise, complete and consistent (5C principle)

15. What are the contents of defect report?

Number of defect, title of defect, basic information of defect, software and hardware environment of test, software version of test, type of defect, severity of defect, priority treatment level of defect, reproduction steps of defect, description of actual result of defect, description of expected correct result, intercepted defect image and annotation text

16. What is the organizational structure of defect reporting?

Number of defect, title of defect, basic information of defect, software and hardware environment of test, software version of test, type of defect, severity of defect, priority treatment level of defect, reproduction steps of defect, description of actual result of defect, description of expected correct result, intercepted defect image and annotation text

17. What problems should be paid attention to in writing defect report?

Self examination and questions:

Has the defect report contained complete, accurate and necessary information to the reader? Does a defect report report only one defect? Can the step be completely reproduced and the expression cleared? Whether the actual results and expected results are described accurately, etc

Avoid common mistakes:

Instead of "I" or "you", use verbs or "user" if necessary

Don't use vague words such as "seem", "probably", etc

Don't make any subjective criticism and ridicule on the quality of software

Uncertain defect testing problems should not be placed in the defect management database.

18. Defect classification?

The defects found during the test are generally divided into the following categories:

Code problem: not meeting the requirements and wrong function implementation; Bugs that affect product or project quality can be uniformly classified;

Design defects: page aesthetics, coordination, typos, etc

User experience: suggestions on products and projects are not required to be modified

Performance problems: used during performance test, tentative: network delay, memory problems, CPU occupation, hard disk problems

Security issues: security issues in business functions

Interface problem: used when data transfer between modules is involved

Configuration problem: a problem that occurs because the configuration provided is improper or the configuration cannot meet the actual requirements

Defect error severity:

Level 5 - enhanced software defect: the improvement opinions of the problem proposer on the test object or the suggestions and queries put forward by the tester.

Level 4 - Minor wrong software defect (Minor), which makes the operator inconvenient or troublesome, but it does not affect the operation and execution of functions, such as typos, nonstandard interface (inconsistent font size, irregular text arrangement, no obvious distinguishing mark between input area and read-only area), and unclear description of auxiliary instructions.

Level 3 - software defect with general error (major): the secondary function is not fully realized but does not affect the use. For example, the prompt information is not accurate, or the user interface is poor, the operation time is long, the module function part fails, the printed content and format are wrong, the deletion operation is not prompted, and there are too many empty fields in the database table.

Level 2 - critical software defect of serious error: the main function of the system is partially lost, the data cannot be saved, and the secondary function of the system is completely lost. The problem is limited to this module, resulting in module function failure or abnormal exit. Such as fatal error declaration, program interface error, database tables, business rules, default values without integrity and other constraints

Level 1 - fatal software defect: causing system or application crash, crash, system hang, or data loss, complete loss of main functions, resulting in abnormalities of this module and related modules. Such as code error, dead loop, database deadlock, database connection error or data communication error, without considering abnormal operation, function error, etc.

19. What if the defect submitted by the test is not recognized by the developer?

Step 1: repeatedly communicate with developers;

Step 2: repeat the existence of defects, and sort out the screenshots and steps of defect reproduction into documents for developers;

Step 3: if you still can't convince the developer, you can report the situation to the test team leader or test manager for evaluation and coordination.

20. Briefly describe the life cycle of defects.

1.New

  1. Open open

  2. Assign assignment

  3. Test test

  4. Verified confirmation

  5. Deferred extension

  6. Reopened reopen

  7. Duplicate duplicate

  8. Rejected rejected

  9. Closed

21. What types of defects can be divided according to severity?

Defect error severity:

Level 5 - enhanced software defect: the improvement opinions of the problem proposer on the test object or the suggestions and queries put forward by the tester.

Level 4 - Minor wrong software defect (Minor), which makes the operator inconvenient or troublesome, but it does not affect the operation and execution of functions, such as typos, nonstandard interface (inconsistent font size, irregular text arrangement, no obvious distinguishing mark between input area and read-only area), and unclear description of auxiliary instructions.

Level 3 - software defect with general error (major): the secondary function is not fully realized but does not affect the use. For example, the prompt information is not accurate, or the user interface is poor, the operation time is long, the module function part fails, the printed content and format are wrong, the deletion operation is not prompted, and there are too many empty fields in the database table.

Level 2 - critical software defect of serious error: the main function of the system is partially lost, the data cannot be saved, and the secondary function of the system is completely lost. The problem is limited to this module, resulting in module function failure or abnormal exit. Such as fatal error declaration, program interface error, database tables, business rules, default values without integrity and other constraints

Level 1 - fatal software defect: causing system or application crash, crash, system hang, or data loss, complete loss of main functions, resulting in abnormalities of this module and related modules. Such as code error, dead loop, database deadlock, database connection error or data communication error, without considering abnormal operation, function error, etc.

22. What types of defects can be divided according to priority

5. Security and privacy protection

Network arrangement, red line test, security test tool, linux security test, privacy protection

Safety test tool

  1. AppScan
    A security vulnerability scanning tool, which supports Web and mobile. Now security testing is very suitable for vulnerability scanning. It is equivalent to the process of "exploration" and "testing", and finally generates a very intuitive test report, which is helpful for R & D personnel to analyze and repair. Usually, security testing tools use this to scan some security vulnerabilities. It is more convenient to use and there are more online materials, It is suitable for many test students. The data is broad. You can try it.
    Official website: https://www.ibm.com/developerworks/downloads/r/appscan/
    reference resources: https://www.cnblogs.com/benpao1314/p/8065720.html

  2. Burp Suite
    A necessary integrated penetration testing tool for information security practitioners. It adopts automatic testing and semi-automatic testing, including Proxy,Spider,Scanner,Intruder,Repeater,Sequencer,Decoder,Comparer and other tool modules; The Proxy function can intercept HTTP/S Proxy servers (mobile phones and web); Spide r function - intelligent sensing web crawler; Intruder function can automatically attack web applications, which is very suitable for security testing. It is a necessary Swiss Army knife for web security personnel to intercept HTTP/HTTPS web packets, act as an intermediary between browsers and related applications, intercept, modify and replay data packets for testing.
    Official website: https://portswigger.net/burp/
    reference resources: https://www.cnblogs.com/nieliangcai/p/6692296.html

  3. Acunetix
    A network vulnerability scanning software, which can detect network security vulnerabilities.
    Official website: https://www.acunetix.com/

  4. Nmap
    A network connection scanning software is used to scan the open network connection of online computers. Determine which services are running on which connections, and infer which operating system the computer is running (this is also known as fingerprinting).
    Official website: https://nmap.org/
    reference resources: https://blog.csdn.net/m0_37268841/article/details/80404613

  5. sqlmap
    An open source penetration testing tool can be used for automatic detection, using SQL injection vulnerabilities to obtain the permissions of the database server. It has powerful detection engine and functional options for penetration testing of various types of databases, including obtaining data stored in the database, accessing operating system files, and even executing operating system commands through external data connection.
    Official website: http://sqlmap.org/ ,
    Download address: https://github.com/sqlmapproject/sqlmap/zipball/master
    Demo video: https://asciinema.org/a/46601
    course: http://www.youtube.com/user/inquisb/videos
    reference resources: https://www.freebuf.com/sectool/164608.html

  6. OpenVAS
    An open vulnerability assessment system can also be said to be a network scanner containing relevant tools. Its core component is a server, including a set of network vulnerability test program, which can detect security problems in remote systems and applications. OpenVas server can only be installed on Linux system. Next, let's introduce the method of using binary to build OpenVas and the use of the foundation.
    Official website: http://www.openvas.org/
    reference resources: https://www.freebuf.com/column/158357.html

  7. msfvenom
    reference resources: https://www.offensive-security.com/metasploit-unleashed/msfvenom/

  8. fortify
    Static code checking tool
    Official website: http://www.fortify.net/README.html
    reference resources: https://www.cnblogs.com/eyesmoon/p/7421477.html
    reference resources: https://www.freebuf.com/sectool/95683.html

  9. Drozer
    An Android security testing framework developed by MWR Labs. It is one of the best Android security testing tools at present. Official website: https://labs.mwrinfosecurity.com/publications/
    reference resources: https://www.cnblogs.com/lsdb/p/9441813.html

  10. nessus
    It is known as the world's most popular vulnerability scanner, which is used by more than 75000 organizations around the world. The tool provides a complete computer vulnerability scanning service and updates its vulnerability database at any time. Nessus is different from traditional vulnerability scanning software. Nessus can remotely control the local machine or remote end at the same time to analyze and scan the vulnerabilities of the system. Nessus is also one of the important tools for penetration testing. Therefore, this chapter describes how to install, configure, and start Nessus.
    Official website: https://www.tenable.com/downloads/nessus
    reference resources: https://www.cnblogs.com/cheyunhua/p/8084459.html

  11. zap
    OWASP Zed attack agent (ZAP) is one of the most popular free security audit tools in the world, which is actively maintained by hundreds of international volunteers *. It can help you automatically find security vulnerabilities in Web applications when developing and testing applications.
    Official website: https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
    reference resources: https://www.fujieace.com/kali-linux/owasp-zed-zap.html

linux Security Testing

1, Account check

cat /etc/passwd
grep :0: /etc/passwd    #Check whether a new user is generated, and the user whose UID and GID are 0
ls -l /etc/passwd      #View file modification date
awk -F: '$3= =0 {print $1}' /etc/passwd          #Check for privileged users
awk -F: 'length($2)= =0 {print $1}' /etc/shadow  #Check whether there is an air traffic order account

2, Check system Daemons

Locate the process leading to high traffic, and then analyze whether it is the horse hung by hackers through its behavior

iftop -nP  View traffic

If you first check with iptraf ng, if there are many UDP packets, they are basically installed with a back door

top (ps -ef)      #View process
lsof –c Suspicious process name  #View the associated file and find the external tcp connection

View the file path. And view the file creation time
whereis  Suspicious process name
ls -al   Suspicious process name
ps -aux(be careful UID Is 0)
lsof -p pid(View the ports and files opened by the process)
cat /etc/inetd.conf | grep -v "^#"    #(check daemon)

Check hidden processes
ps -ef|awk '{print }'|sort -n|uniq >1
ls /porc |sort -n|uniq >2
diff 1 2

3, Check the network connection and listening port

netstat Named Global

netstat –an
netstat –rn
ifconfig –a

netstat introduction interview must ask

The Netstat command is used to display various network related information, such as network connection, routing table, interface statistics, masquerade connection, multicast members, and so on.

Common parameters

-a (all)Show all options, not shown by default LISTEN relevant
-t (tcp)Show only tcp Related options
-u (udp)Show only udp Related options
-n Refuse to display aliases and convert all that can display numbers into numbers.
-l List only those with Listen (monitor) Service status of

-p Displays the name of the program that established the relevant link
-r Display routing information, routing table
-e Displays extended information, such as uid etc.
-s Statistics according to each agreement
-c This is performed at regular intervals netstat Command.

Tip: the status of LISTEN and LISTENING can only be seen with - a or - l

Practical command instance

1. List all ports (including listening and not listening)

List all ports netstat -a

# netstat -a | more
 Active Internet connections (servers and established)
 Proto Recv-Q Send-Q Local Address           Foreign Address         State
 tcp        0      0 localhost:30037         *:*                     LISTEN
 udp        0      0 *:bootpc                *:*
 
Active UNIX domain sockets (servers and established)
 Proto RefCnt Flags       Type       State         I-Node   Path
 unix  2      [ ACC ]     STREAM     LISTENING     6135     /tmp/.X11-unix/X0
 unix  2      [ ACC ]     STREAM     LISTENING     5140     /var/run/acpid.socket

List all tcp ports netstat -at

# netstat -at
 Active Internet connections (servers and established)
 Proto Recv-Q Send-Q Local Address           Foreign Address         State
 tcp        0      0 localhost:30037         *:*                     LISTEN
 tcp        0      0 localhost:ipp           *:*                     LISTEN
 tcp        0      0 *:smtp                  *:*                     LISTEN
 tcp6       0      0 localhost:ipp           [::]:*                  LISTEN

List all udp ports netstat -au

# netstat -au
 Active Internet connections (servers and established)
 Proto Recv-Q Send-Q Local Address           Foreign Address         State
 udp        0      0 *:bootpc                *:*
 udp        0      0 *:49119                 *:*
 udp        0      0 *:mdns    

2. List all Sockets in listening status

Display only listening port netstat -l

# netstat -l
 Active Internet connections (only servers)
 Proto Recv-Q Send-Q Local Address           Foreign Address         State
 tcp        0      0 localhost:ipp           *:*                     LISTEN
 tcp6       0      0 localhost:ipp           [::]:*                  LISTEN
 udp        0      0 *:49119                 *:*

List only all listening tcp ports netstat -lt

# netstat -lt
 Active Internet connections (only servers)
 Proto Recv-Q Send-Q Local Address           Foreign Address         State
 tcp        0      0 localhost:30037         *:*                     LISTEN
 tcp        0      0 *:smtp                  *:*                     LISTEN
 tcp6       0      0 localhost:ipp           [::]:*                  LISTEN

List only all listening udp ports netstat -lu

# netstat -lu
 Active Internet connections (only servers)
 Proto Recv-Q Send-Q Local Address           Foreign Address         State
 udp        0      0 *:49119                 *:*
 udp        0      0 *:mdns                  *:*

List only all listening UNIX ports netstat -lx

# netstat -lx
 Active UNIX domain sockets (only servers)
 Proto RefCnt Flags       Type       State         I-Node   Path
 unix  2      [ ACC ]     STREAM     LISTENING     6294     private/maildrop
 unix  2      [ ACC ]     STREAM     LISTENING     6203     public/cleanup
 unix  2      [ ACC ]     STREAM     LISTENING     6302     private/ifmail
 unix  2      [ ACC ]     STREAM     LISTENING     6306     private/bsmtp

3. Display statistics for each protocol

Display statistics for all ports netstat -s

# netstat -s
 Ip:
 11150 total packets received
 1 with invalid addresses
 0 forwarded
 0 incoming packets discarded
 11149 incoming packets delivered
 11635 requests sent out
 Icmp:
 0 ICMP messages received
 0 input ICMP message failed.
 Tcp:
 582 active connections openings
 2 failed connection attempts
 25 connection resets received
 Udp:
 1183 packets received
 4 packets to unknown port received.
 .....

Displays statistics for TCP or UDP ports netstat -st or - su

# netstat -st 
# netstat -su

4. Display PID and process name in netstat output netstat -p

netstat -p can be used with other switches to add "PID / process name" to the output of netstat, so that the programs running on a specific port can be easily found during debugging.

# netstat -pt
 Active Internet connections (w/o servers)
 Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
 tcp        1      0 ramesh-laptop.loc:47212 192.168.185.75:www        CLOSE_WAIT  2109/firefox
 tcp        0      0 ramesh-laptop.loc:52750 lax:www ESTABLISHED 2109/firefox

5. Host, port or user are not displayed in netstat output

When you don't want the host, port, and user name displayed, use netstat -n. Numbers will be used instead of those names.

It can also speed up the output because there is no need to compare and query.

# netstat -an

If you just don't want one of these three names to be displayed, use the following command

# netsat -a --numeric-ports
# netsat -a --numeric-hosts
# netsat -a --numeric-users

6. Continuously output netstat information

netstat will output network information every second.

# netstat -c
 Active Internet connections (w/o servers)
 Proto Recv-Q Send-Q Local Address           Foreign Address         State
 tcp        0      0 ramesh-laptop.loc:36130 101-101-181-225.ama:www ESTABLISHED
 tcp        1      1 ramesh-laptop.loc:52564 101.11.169.230:www      CLOSING
 tcp        0      0 ramesh-laptop.loc:43758 server-101-101-43-2:www ESTABLISHED
 tcp        1      1 ramesh-laptop.loc:42367 101.101.34.101:www      CLOSING
 ^C

7. Display address families not supported by the system

netstat --verbose

At the end of the output, there will be the following information

netstat: no support for `AF IPX' on this system.
netstat: no support for `AF AX25' on this system.
netstat: no support for `AF X25' on this system.
netstat: no support for `AF NETROM' on this system.

8. Display core routing information netstat -r

# netstat -r
 Kernel IP routing table
 Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
 192.168.1.0     *               255.255.255.0   U         0 0          0 eth2
 link-local      *               255.255.0.0     U         0 0          0 eth2
 default         192.168.1.1     0.0.0.0         UG        0 0          0 eth2

Note: use netstat -rn to display the number format without querying the host name.

9. Find out the port where the program runs

Not all processes can be found. Those without permission will not be displayed. Use root permission to view all information.

# netstat -ap | grep ssh
 tcp        1      0 dev-db:ssh           101.174.100.22:39213        CLOSE_WAIT  -
 tcp        1      0 dev-db:ssh           101.174.100.22:57643        CLOSE_WAIT  -

Find the process running on the specified port

# netstat -an | grep ':80'

10. Display the list of network interfaces

# netstat -i
 Kernel Interface table
 Iface   MTU Met   RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
 eth0       1500 0         0      0      0 0             0      0      0      0 BMU
 eth2       1500 0     26196      0      0 0         26883      6      0      0 BMRU
 lo        16436 0         4      0      0 0             4      0      0      0 LRU

Display details, such as ifconfig using netstat -ie:

# netstat -ie
 Kernel Interface table
 eth0      Link encap:Ethernet  HWaddr 00:10:40:11:11:11
 UP BROADCAST MULTICAST  MTU:1500  Metric:1
 RX packets:0 errors:0 dropped:0 overruns:0 frame:0
 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
 Memory:f6ae0000-f6b00000

11. IP and TCP analysis

View the IP addresses of the most connected to a service port

wss8848@ubuntu:~$ netstat -nat | grep "192.168.1.15:22" |awk '{print $5}'|awk -F: '{print $1}'|sort|uniq -c|sort -nr|head -20
18 221.136.168.36
3 154.74.45.242
2 78.173.31.236
2 62.183.207.98
2 192.168.1.14
2 182.48.111.215
2 124.193.219.34
2 119.145.41.2
2 114.255.41.30
1 75.102.11.99

TCP status list

wss8848@ubuntu:~$ netstat -nat |awk '{print $6}'
established)
Foreign
LISTEN
TIME_WAIT
ESTABLISHED
TIME_WAIT
SYN_SENT
  Take out all the States first,Then use uniq -c Statistics, and then sort.
wss8848@ubuntu:~$ netstat -nat |awk '{print $6}'|sort|uniq -c
143 ESTABLISHED
1 FIN_WAIT1
1 Foreign
1 LAST_ACK
36 LISTEN
6 SYN_SENT
113 TIME_WAIT
1 established)

4, View the history of all users who log in to this computer under normal conditions

last

5, Check the core file in the system

find / -name core -exec ls -l {} \;

6, View system and file exceptions

find -type f -mtime -5 #Find files changed in the last 5 days
find / -uid 0 –perm -4000 –print
find / -size +10000k –print
find / -name "..." –print
find / -name ".." –print
find / -name "." –print
find / -name " " –print    #Note that the SUID file is suspicious of files larger than 10M and spaces
find / -name core -exec ls -l {} ;  #(check the core file in the system)
Check system file integrity
md5sum –b file name
md5sum –t file name

7, Check system file integrity

rpm –qf /bin/ls
rpm -qf /bin/login
md5sum –b file name
md5sum –t file name

8, Backdoor scanning

Back door account check
cat /etc/passwd
grep :0: /etc/passwd    #Check whether a new user is generated, and the user whose UID and GID are 0
ls -l /etc/passwd       #View file modification date
awk -F: '$3= =0 {print $1}' /etc/passwd  #Check for privileged users
awk -F: 'length($2)= =0 {print $1}' /etc/shadow  #Check whether there is an air traffic order account
Rear door inspection
cat /etc/crontab
ls /var/spool/cron/
cat /etc/rc.d/rc.local
ls /etc/rc.d
ls /etc/rc3.d
find / -type f -perm 4000

STABLISHED
1 FIN_WAIT1
1 Foreign
1 LAST_ACK
36 LISTEN
6 SYN_SENT
113 TIME_WAIT
1 established)

### 4, View the history of all users who log in to this computer under normal conditions

```shell
last

5, Check the core file in the system

find / -name core -exec ls -l {} \;

6, View system and file exceptions

find -type f -mtime -5 #Find files changed in the last 5 days
find / -uid 0 –perm -4000 –print
find / -size +10000k –print
find / -name "..." –print
find / -name ".." –print
find / -name "." –print
find / -name " " –print    #Note that the SUID file is suspicious of files larger than 10M and spaces
find / -name core -exec ls -l {} ;  #(check the core file in the system)
Check system file integrity
md5sum –b file name
md5sum –t file name

7, Check system file integrity

rpm –qf /bin/ls
rpm -qf /bin/login
md5sum –b file name
md5sum –t file name

8, Backdoor scanning

Back door account check
cat /etc/passwd
grep :0: /etc/passwd    #Check whether a new user is generated, and the user whose UID and GID are 0
ls -l /etc/passwd       #View file modification date
awk -F: '$3= =0 {print $1}' /etc/passwd  #Check for privileged users
awk -F: 'length($2)= =0 {print $1}' /etc/shadow  #Check whether there is an air traffic order account
Rear door inspection
cat /etc/crontab
ls /var/spool/cron/
cat /etc/rc.d/rc.local
ls /etc/rc.d
ls /etc/rc3.d
find / -type f -perm 4000

Tags: unit testing computer

Posted on Tue, 21 Sep 2021 05:09:41 -0400 by jmabbate