CppExplore

在c++的世界里，程序設計的優雅讓位于程序的穩定性、健壯性。“好程序是測出來的”這句話在C++領域里得到了充分體現。下面是我在開發中使用的測試方法，拋磚引玉，和大家交流下。
測試期間，關閉對core文件的限制，使用命令：ulimit -c unlimited
（1）開發階段，使用cppunit維護測試用例。我一般是用于測試解析類、算法類。
從http://sourceforge.net/projects/cppunit/下載最新版本，解壓，看安裝文檔，一般是./configure & make & make install。
下面舉例說明我使用cppunit的方法。假設自己的源碼位于src目錄下，里面有class1.h/class1.cpp/class2.h/class2.cpp。相對src建立平級目錄test存放測試工程，為class1/class2分別建立測試類文件testClass1.h/testClass2.h,建立main函數所在文件test.cpp、makefile。
testClass1.h代碼如下,testClass2.h類似。

#include "class1.h"
#include <iostream>
#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(==);
        }
};

#include "testClass1.h"
#include "testClass2.h"
#include <iostream>
#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;
}

EXE=test
SRC=test.cpp
INC_PATH=-I ../src -I (cppunit頭文件的目錄) -I(依賴的其他頭文件路徑)
LIB_PATH=-L (cppunit動態庫所在的目錄) -L (依賴的其他庫所在目錄)
    LIB=-lcppunit -ldl 
all:
    g++ $(SRC) $(LIB_PATH) $(LIB)  $(INC_PATH) -o $(EXE)

再有新的需要測試類，增加相應的測試類，稍微修改下test.cpp即可(增加一句＃include,一句CPPUNIT_TEST_SUITE_REGISTRATION)。
保證開發結束后，解析類、算法類等不會有錯誤。
（2）白盒測試階段。
這個基本是功能邏輯性測試，檢測所有數據結構按要求變化以及保證各線程之間變化的一致性。這是最基本也是最全面的一次測試，保證測試的功能覆蓋率100％。白盒測試期間可以在代碼里加一些宏編譯選項或者增加程序交互功能用于觀察所有數據結構的變化。
保證測試完畢沒有功能性、邏輯性的錯誤。
（3）內存測試階段。使用valgrind檢測顯式內存泄漏、內存讀寫錯誤。
從http://www.valgrind.org/下載最新版本，解壓，看安裝文檔，一般是./configure & make & make install。
檢測內存一般使用命令valgrind --tool=memcheck -v --leak-check=full ./待測程序錯誤的地方會用==×××==（×××表示數字）標出。
使用一路模擬客戶端做陪測。
保證測試完畢，單路客戶端陪測的情況下沒有任何的顯式內存泄漏，沒有任何的內存讀寫錯誤。
（4）寫批量客戶端模擬程序。建議熟悉一門方便socket編程的腳本語言，推薦perl。腳本語言簡單，實現快速，特適合做陪測。
首先寫一個能讀取配置文件信息，按配置文件的要求向相應的server，按配置文件的流程發送信令的perl程序。
下面是我rtsp相關的一個server陪測的配置文件：

ip=127.0.0.1
port=9115
url=rtsp://172.24.202.190:554/asset/service?USERID=320101312345670001&ChanelNo-PUID=0-320101000200000001&PlayMethod=0
<s,2>
<p,2>
<u,2>
<p,2>
<t,2>

其中ip是server IP,port是rtsp端口，url是發送信令帶的url。<>表示按順序發送的信令,這個配置文件表示先發送一個setup,然后sleep 2秒，再發送一個play，然后sleep 2秒，繼續......這個程序可作為（3）中的陪測程序

在上面程序的基礎上修改，讀取配置文件后，死循環按順序發送信令，假設該程序稱做B。
寫一個新的perl文件，完成如下功能，起幾十路使用某配置文件的B程序，sleep幾秒后，再起幾十路使用其它配置文件的B程序.....,或者一起起也可以，自行設計,最后killall所有，從頭循環運行。
總之盡可能的模擬客戶端的所有行為，包括突然斷聯等，并且保證一定的壓力。
（5）壓力下測試內存。繼續在valgrind下測試，使用（4）中的測試腳本做配測。
保證壓力下無異常狀態、無數據不一致狀態、無顯式內存泄漏、無內存讀寫異常
（6）穩定性以及內存泄漏測試。
陪測腳本起幾百路客戶端，保證主程序的cpu占用率在70％以上，持續運行20多小時。
測試期間，關注進程對內存的占用率，是保持在恒定水平還是隨運行時間的增長而增長。
測試完畢，保證主程序負荷運行長時間而不宕機、沒有內存泄漏發生。
（7）代碼覆蓋率測試。gcov
gcov是隨gcc安裝的，可以檢查陪測程序對目標程序的代碼覆蓋情況。
不斷修改測試腳本，保證測試盡量全面。代碼被執行的次數也可以做為以后性能測試的一個參考。
（8）性能測試。gprof
同gcov一樣，gprof也是隨gcc安裝的，它可以檢測目標程序中所有函數的調用時間，并根據消耗時間排序，方便找出性能瓶頸。
找出系統的主要性能瓶頸，經過性能測試后，一般會發現影響系統的主要因素還是數據結構和算法。

測試期間，任何的coredump/任何的內存讀寫異常，務必處理掉。墨菲法則說，一個事情如果有可能變糟，事實則是會變的更糟。任何一個微小的、出現幾率極小的bug，如果不在研發測試階段解決，都可能造成以后更大代價的返工，甚至給客戶的運營帶來災難。希望在每個人身上生效的都是馬太效應，而不是墨菲法則。

以上都是我個人摸索的結果，沒有參與過測試培訓，也沒有和其他同事交流過，因此可能有閉門造車的嫌疑，還請看這篇文章的高手們不吝賜教。