ATE = Automatic Test Environment
ATE is the technical architecture to run daily build, so it is also the technical base of Continuous Integration. The most important activity is daily build.
üDaily build is the most important Continuous Integration activity. Integration Team run the nightly build at every mid-night, then at the morning, developer will get the info of the current status: including build, static code checking, multi-type test checking, coverage and memory leak. Developer hereby can get the knowledge quickly for new problems and current status. Due to developer always can get the problem information at the first time, the corresponding fixing work will be much easier comparing with traditional way.
How To Maintain a Single Source Repository?
Subversion is used to store all things required for a Continous Integration BUILD. The build means daily build in our practice, it includes source codes, acceptance test cases, install scripts, test tools and 3rd party library.
Why select SVN as Source control System?
The most inportant is we can use unix command to manage our source. For CC, it is difficult for us to automatically download all things required for a daily build.
Our ATE system based one Unix system.
How To Automate the Build?
The build here means building the binary software. For our software,C++ is our development langauage, so MAKE used to build the binary package. We make RPM or PKG package.
How to Make Your Build Self-Testing?
How many kind of Self-Testing included in our daily build?
@Module Test - White box testings (Developers write test cases)
@Integration Test - Black box testings
- Test team make the test plan as the software feature requirement, write the test cases according to the test tools, report the test cases results to bugzilla.
@Source Code quality Test - flexelint
Flexelint can be used to qualify your source codes' quality. The most difficult point is how a design Flexelint rule. It is very easy to integrate flexelint into ATE.
@Coverage Test - How to verify your test cases coverage rate?
On Linux Platform, lcov is the selected Coverage Test tool. Lcov is an extension of GCOV, which provides information about which part of the codes are actually executed (i.e. "Be covered") while running. The extension consists of a set of PERL scripts which build on the textual gcov output to implement the HTML based functionality. In the Continuous Integration process, lcov is used for integration test and module test to get the coverage information. Using the genhtml srcipts, the html mode report of coverage rate will be got and analyzed.
The ant scripts language is used for the entire coverage test implementation. The following figure demonstrates the coverage test ant script file structure.
@Installation Test - OAM team deploy related the test cases.
Last topics, All test cases should run automatically, ANT scripts used in our ATE system.
How To Make it Easy for Anyone to Get the Latest Executable or Everyone can see what's happening?
The answer is CruiseControl. We use the CruiseControl to deploy our every daily build into internal web page. Every one can view the project status daily by web pages. CruiseControl also support send daily build result to team member's mail box.
Anything can be optimized for our ATE?
Whole Acceptance test should last about 5 hours,so we run daily in middle night when different site all not in office, but one problem happened, so development problem maybe found later.
Actually, every build should be triggered by each Check-in.
So We need divide Acceptance Test cases into quickly set(Module test and build binary) and Longer set(IT,CT,Install T).
阅读(789) | 评论(0) | 转发(0) |
