Test requirements extracted from the code

Server-side testing, software requirements are basically equal to the product specification, only about, not exhaustive. In the case of insufficient demand, what can we do to excavate the testing requirements?

Now known requirements: The server supports version upgrades for clients, there are two upgrade rules:

First: Minimum version upgrade: Depending on the type of client, upgrade is required if the current version is less than the minimum version requirement

Second: Specify version upgrade: Force or prompt to upgrade to the specified version based on a client type + version information

If 2 upgrade rules are met at the same time, the second is preferred. The configuration file is as follows:

The general testers can analyze the following two points as follows:

1. When two rules are met at the same time, how to choose?
2. The first rule: the current version of the minimum version, you are prompted to upgrade. What about the minimum version of the current version?

The second rule: the current version of the minimum version, you need to force the upgrade, the current version of the minimum version of the time?

Assuming that the current client type is only one, set only the PC client, you can generally write the following test cases:

So this kind of design, is comprehensive, and then into a layer of analysis, and what is missing?

1. What is the relationship between a product and two rules? 1 pairs of more? Can there be multiple rules for specifying version upgrades for each product?

2, there are 14 products in total operation, each type of product needs to cover the test?

3, the client and the server is how to interact with the client to pass what data to the server, the server returned what to the client? What is the whole process of upgrading, clear?

4, before considering the 2nd, too rough, "outside, in addition to", there is =.

The interface core function code for the client and server side is as follows:

Getproductitem is the interface between the server and the client, the client passes szproductid,szversion to the server, and then the server makes a judgment, returning the correct data to the item class for the client to call.

BOOL Cconfig::getproductitem (const char *szproductid, const char *szversion, Productitem &item)

{

First determine the productdetail of the product according to ProductID

Productdetail *pproduct = findproduct (Szproductid);

If the Szproductid passed by the client is empty, the default

if (!pproduct)

{

M_strdefaultproduct Store the ID of the defaultproduct read from the configuration file

Pproduct = Findproduct (M_strdefaultproduct.c_str ());

Returns False if the default is null

if (!pproduct)

{

return false;

}

}

Version grayupdate configured according to szversion within the determined ProductID

The Find () function returns an iterator that points to an element with a key value, and returns an iterator to the tail of the map if it is not found

Auto iter = Pproduct->mapversioninfo.find (szversion);

If not found, use default version information (Force upgrade block)

if (iter = = Pproduct->mapversioninfo.end ())

{

iter = Pproduct->mapversioninfo.find (default_version);

if (iter = = Pproduct->mapversioninfo.end ())

{

return false;

}

}

On the server side, the Strminversion,strnewversion,lsdownloadurl exists item, which is returned to the client, and the client controls how the upgrade is enforced or prompted.

Item.strproductid = pproduct->strproductid;

Item.strwebservicesurl = M_strwebservicesurl;

Item.strminversion = iter->second.strminversion;

Item.strnewversion = iter->second.strnewversion;

Item.lsdownloadurl = iter->second.lsdownloadurl;

return true;

}

The FINDPRODUCT implementation process is as follows:

The server waits for the client to send the client-related data before the server starts, loads the configuration file, reads the configuration file under the corresponding server <CONFIG> data into Szconfig, and then calls the Loadconfig method.

Loadconfig method Function: The data in the configuration file, the default configuration of the Product ID read to Szproductid, all other information of the product read into the Pproductdetail.

BOOL cconfig::loadconfig (const CHAR *szconfig)

{

if (NULL = = szconfig)

return FALSE;

tixmlelement element ("");

Element. Parse (Szconfig, NULL, Tixml_encoding_utf8);

The data for the Defaultproduct element in the configuration information is present in Szproductid.

Const CHAR *szproductid = Tixmlgetvalue (&element, "defaultproduct");

if (!szproductid | | strcmp (Szproductid, "") = = 0)

{

return FALSE;

}

M_strdefaultproduct = Szproductid;

The Szwebservicesurl variable is temporarily unused (formerly old code) and can be ignored

Const CHAR *szwebservicesurl = Tixmlgetvalue (&element, "Webservicesurl");

if (Szwebservicesurl)

{

M_strwebservicesurl = Szwebservicesurl;

}

Reads the information from the first element of product in the configuration file, returning the value inside the Pproductdetail class

Tixmlelement *pproductdetail=element. Firstchildelement ("Product");

if (!pproductdetail | |!) Readproductdetail (Pproductdetail))

{

return FALSE;

}

return TRUE;

}

The purpose of the Readproductdetail function is to read part of the data under product to the Pproductdetail member variables strProductID and Mapversioninfo (within the version set).

After reading the code, know the approximate process is as follows: First service starts, will be each product under the Pproductdetail save, and then the client sends Szproductid,szversion to the server side, the server is first in the m_ Lsproduct (list) to find their own corresponding pproductdetail information, if not found, then use the default version, and then according to Szversion in a determined ProductID to get the Grayupdate configuration version, if not found, With the default version information, the resulting data is saved in the item class, which is returned to the client.

The doubts before the thinking, the answers are as follows:

1. There is a product that has multiple specified version upgrades, and the test case needs to be increased.
2. Operating line is 14, but according to the procedure internal implementation method (container loop control to find product ID), is not necessary to configure 14, test 4, 4 products can be passed the normal test, you can guarantee 14 no problem.
3. Interactive process, interface input and output has been indicated.
4. equals the time is what situation, have to communicate with development.

The fixed test points are as follows:

Test requirements extracted from code