Detailed explanation of the C ++ Server test process

A good C ++ Server test is also an important step in the C ++ development process. This article will begin from the development stage, white box testing stage, memory testing stage and other aspects.

In the world of C ++, the elegance of program design allows stability and robustness of programs. The "good program is tested" sentence is fully reflected in the C ++ field. The following is the test method I used in development.

During the C ++ Server test, disable the restriction on the core file and run the command: ulimit-c unlimited.

(1) Development Stage

Use cppunit to maintain test cases. I am generally used to test the parsing class and algorithm class.

Download the latest version from http://sourceforge.net/projects/cppunit/. For more information, see the installation document. It is generally ./configure & make install.

The following example shows how to use cppunit. Assume that your source code is located in the src directory, which contains class1.h/class1.cpp/class2.h/class2.cpp. Create a level directory test for src to store the test project, create the test class file testClass1.h/testClass2.h for class1/class2 respectively, and create the files test. cpp and makefile where the main function is located.

The testClass1.h code is as follows, similar to testClass2.h.

 
 

  
  
#include "class1.h"  
  
  
#include   
  
  
#include "cppunit/TestRunner.h"  
  
  
#include "cppunit/TestResult.h"  
  
  
#include "cppunit/TestResultCollector.h"  
  
  
#include "cppunit/extensions/HelperMacros.h"  
  
  
#include "cppunit/BriefTestProgressListener.h"  
  
  
#include "cppunit/extensions/TestFactoryRegistry.h"  
  
  
#include "cppunit/TextOutputter.h"  
  
  
#include "cppunit/CompilerOutputter.h"  
  
  
#include "cppunit/TestCaller.h"  
  
  
class testClass1:public CPPUNIT_NS::TestFixture  
  
  
{  
  
  
CPPUNIT_TEST_SUITE(testClass1);  
  
  
CPPUNIT_TEST(testCase1);  
  
  
CPPUNIT_TEST(testCase2);  
  
  
CPPUNIT_TEST_SUITE_END();  
  
  
public:  
  
  
virtual void setUp(){}  
  
  
virtual void tearDown(){}  
  
  
void testCase1()  
  
  
{  
  
  
testClass1 a;  
  
  
a.oper..;  
  
  
CPPUNIT_ASSERT_EQAL(a.get..,);  
  
  
}  
  
  
void testCase2()  
  
  
{  
  
  
CPPUNIT_ASSERT(==);  
  
  
}  
  
  
} 
 
 

The test. cpp Code is as follows:

 
 

  
  
#include "testClass1.h"  
  
  
#include "testClass2.h"  
  
  
#include   
  
  
#include "cppunit/TestRunner.h"  
  
  
#include "cppunit/TestResult.h"  
  
  
#include "cppunit/TestResultCollector.h"  
  
  
#include "cppunit/extensions/HelperMacros.h"  
  
  
#include "cppunit/BriefTestProgressListener.h"  
  
  
#include "cppunit/extensions/TestFactoryRegistry.h"  
  
  
#include "cppunit/TextOutputter.h"  
  
  
#include "cppunit/CompilerOutputter.h"  
  
  
#include "cppunit/TestCaller.h"  
  
  
CPPUNIT_TEST_SUITE_REGISTRATION(testClass1);  
  
  
CPPUNIT_TEST_SUITE_REGISTRATION(testClass1);  
  
  
int main()  
  
  
{  
  
  
CPPUNIT_NS::TestResult controller;  
  
  
CPPUNIT_NS::TestResultCollector result;  
  
  
controller.addListener( &result );  
  
  
CPPUNIT_NS::TestRunner runner;  
  
  
runner.addTest( CPPUNIT_NS::TestFactoryRegistry::getRegistry().makeTest() );  
  
  
runner.run( controller );  
  
  
CPPUNIT_NS::CompilerOutputter out( &result, std::cout );  
  
  
out.write();  
  
  
return 0;  
  
  
} 
 
 

The makefile file is as follows:

EXE = test

SRC = test. cpp

INC_PATH =-I ../src-I (directory of the cppunit header file)-I (path of other header files dependent)

LIB_PATH =-L (directory of the cppunit dynamic library)-L (directory of other dependent libraries)

LIB =-lcppunit-ldl

All:

G ++ $ (SRC) $ (LIB_PATH) $ (LIB) $ (INC_PATH)-o $ (EXE)

Add a new test class and modify test. cpp slightly (add a sentence: # include, CPPUNIT_TEST_SUITE_REGISTRATION ).

Make sure that there are no errors in the parsing class and algorithm class after the development is complete.

(2) white box test phase

This is basically a functional logic test that detects changes in all data structures as required and ensures the consistency of changes between threads. This is the most basic and most comprehensive test, ensuring that the functional coverage rate of the test is 100%. During the white box test, you can add some macro compilation options in the code or add the program interaction function to observe the changes in all data structures.

Ensure that the test is complete without functional and logical errors.

(3) memory test phase

Use valgrind to detect Explicit Memory leakage and memory read/write errors.

Download the latest version from http://www.valgrind.org/and decompress it. See the installation document. It is generally ./configure & make install.

The command valgrind -- tool = memcheck-v -- leak-check = full is generally used for memory detection. /Where the program to be tested is wrong, it will be marked with = ××× = (××× indicating a number.

Test with a simulated client. Ensure that the test is complete. When a single client is accompanied by the test, there is no explicit memory leakage and no memory read/write errors.

(4) Write a batch client simulation program

We recommend that you be familiar with a scripting language that facilitates socket programming. perl is recommended. The script language is simple and fast, so it is suitable for testing with you.

First, write a perl program that can read the configuration file information and send signaling to the corresponding server according to the configuration file's requirements.

The following is a configuration file related to my rtsp server companion test:

Ip = 127.0.0.1

Port = 9115

Url = rtsp: // 172.24.202.190: 554/asset/service? USERID = 320101312345670001 & ChanelNo-PUID = 0-320101000200000001 & PlayMethod = 0

The ip address is the server IP address, the port is the rtsp port, and the url is the url of the sending signaling band. <> It indicates the signaling sent in sequence. This configuration file indicates that a setup is sent first, then sleep for 2 seconds, then play is sent, and then sleep for 2 seconds to continue ...... this program can be used as a companion test program in (3.

Modify the configuration file based on the above program. After reading the configuration file, the infinite loop sends signals in order. Assume that the program is called B.

Write a new perl file and complete the following functions. Dozens of B programs that use a configuration file are started. After several seconds of sleep, A dozen more B programs that use other configuration files ....., you can also start from scratch, design it yourself, and killall at last, and run it cyclically from the beginning.

In short, try to simulate all client behaviors, including sudden disconnections, and ensure a certain amount of pressure.

(5) test memory under pressure

Continue the test under valgrind and use the test script in (4) for configuration testing.

Ensure no abnormal status, no data inconsistency, no explicit memory leakage, and no memory read/write exceptions under pressure.

(6) stability and Memory leakage test

With the test script, hundreds of clients are started to ensure that the cpu usage of the main program is more than 70% and runs continuously for more than 20 hours.

During the test, focus on the memory usage of the process, whether to maintain a constant level or grow with the running time.

The test is completed to ensure that the master program runs for a long time without downtime and no memory leakage occurs.

(7) code coverage test. Gcov

Gcov is installed with gcc and can check the code coverage of the target program by the companion test program.

Constantly modify the test script to ensure that the test is as comprehensive as possible. The number of times the code is executed can also be used as a reference for future performance tests.

(8) performance testing. Gprof

Like gcov, gprof is also installed with gcc. It can detect the call time of all functions in the target program and sort the call time according to the consumption time to locate performance bottlenecks.

Find out the main performance bottlenecks of the system. After performance testing, we usually find that the main factors that affect the system are data structures and algorithms.

During the C ++ Server test, any coredump/memory read/write exceptions must be handled. Murphy's Law says that if one thing may get worse, the fact will get worse. Any minor bug with a very low probability may cause rework at a greater cost if it is not solved during the R & D and testing phase, or even cause a disaster to the customer's operations. The Matthew effect is expected to take effect for everyone, not Murphy's Law.

1. Something you have to say about new and delete
2. Author of Java programming ideas: C ++ is not spam, but Java is arrogant.
3. Differences between Java and C ++ in scope
4. C/C ++ uses multiple methods to obtain the file size code
5. Reload, overwrite, and hide C ++ class member functions