从代码里提取的测试需求

       服务器端的测试，软件需求基本等于产品说明书，只有大概，没有详尽。再需求不充分的情况下，我们可以从哪些方面来挖掘测试需求呢？

现已知需求：服务器支持对客户端的版本升级，存在两种升级规则：

第一：最低版本升级：按照客户端的类型，如果当前版本小于最低版本要求则需要进行升级

第二：指定版本升级：根据某个客户端类型+版本信息，强制或者提示升级到指定版本

      如果同时满足2种升级规则，优先匹配第二种。配置文件如下：

一般测试人员都能分析到以下两点如下：

1. 两种规则同时满足时，怎么选择？
2. 第一种规则：当前版本《 最低版本，则提示需要进行升级。那当前版本》最低版本的时候呢？

          第二种规则：当前版本《 最低版本，则需要强制升级，那当前版本》最低版本的时候呢？

 假设当前客户端类型只有一种，设只有PC客户端，一般都能写出以下的测试用例：

 

  那这样的设计，算全面了么，再深入一层分析，又缺少了什么呢？

1、  产品和两个规则的关系如何？1对1，1对多？每个产品都可能存在多个指定版本升级的规则？

2、  总共运营上存在14个产品，每类产品都需要覆盖测试？

3、  客户端与服务器是怎么进行交互的，客户端传递什么数据到服务器，服务器返回什么给客户端？升级的整个流程是什么样的，清楚么？

4、  之前考虑的第二点，太粗糙，》之外的，除了《，还有 = 。

                                                                                                                             

客户端和服务器端的接口核心函数代码如下：

//GetProductItem为服务器端与客户端之间的接口函数，客户端传szProductID，szVersion给服务器端，然后服务器就此作出判断，返回正确的数据到item类中，供客户端调用。

bool CConfig::GetProductItem(const CHAR *szProductID, const CHAR *szVersion, ProductItem &item)

{

// 先根据ProductID确定产品的ProductDetail

    ProductDetail *pProduct = FindProduct(szProductID);

    //如果客户端传递的szProductID为空，则用默认的

    if (!pProduct)

    {

   //m_strDefaultProduct存储从配置文件中读取的DefaultProduct的ID

      pProduct = FindProduct(m_strDefaultProduct.c_str());

   //如果默认的为空，则直接返回false

        if (!pProduct)

        {

            return false;

        }

 }

 

//根据szVersion在确定的ProductID内得到grayupdate配置的版本

//find()函数返回一个迭代器指向键值为key的元素，如果没找到就返回指向map尾部的迭代器

    auto iter = pProduct->mapVersionInfo.find(szVersion);

    //如果没有找到，就用默认版本信息（强制升级块）

    if (iter == pProduct->mapVersionInfo.end())

    {

        iter = pProduct->mapVersionInfo.find(DEFAULT_VERSION);

        if (iter == pProduct->mapVersionInfo.end())

        {

            return false;

        }

    }

 

// 在服务器端将strMinVersion，strNewVersion，lsDownloadUrl存在item，返回给客户端，由客户端控制怎么强制升级还是提示升级。

    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;

}

FindProduct的实现过程如下：

服务器在等待客户端发送客户端相关数据过来前，服务器启动时，就加载配置文件，读取对应服务器下的配置文件<CONFIG>里的数据到szConfig中，然后调用LoadConfig的方法。

//LoadConfig方法作用：将配置文件里的数据，默认配置的产品ID读取到szProductID，产品的其他所有信息读取到pProductDetail中。

BOOL CConfig::LoadConfig(const CHAR *szConfig)

{

    if (NULL == szConfig)

        return FALSE;

 

    TiXmlElement element("");

element.Parse(szConfig, NULL, TIXML_ENCODING_UTF8);

 

// 取配置信息中DefaultProduct元素的数据存在szProductID中。

    const CHAR *szProductID = TiXmlGetValue(&element, "DefaultProduct");

    if (!szProductID || strcmp(szProductID, "") == 0)

    {

        return FALSE;

    }

    m_strDefaultProduct = szProductID;

 

// szWebServicesURL 变量暂时未被使用（以前的旧代码），可以忽略

  const CHAR *szWebServicesURL = TiXmlGetValue(&element, "WebServicesURL");

    if (szWebServicesURL)

    {

        m_strWebServicesURL = szWebServicesURL;

}

 

//读取配置文件中Product的第一个元素的信息，将里面的值返回pProductDetail类中

   TiXmlElement *pProductDetail=element.FirstChildElement("Product");

    if (!pProductDetail || !ReadProductDetail(pProductDetail))

    {

        return FALSE;

    }

    return TRUE;

}

 ReadProductDetail函数的作用就是将product下对应的部分数据，读取到pProductDetail的成员变量strProductID和mapVersionInfo（版本集合内）.

     看完代码，得知的大致流程如下：首先服务一启动，就会将每个Product下的pProductDetail保存起来，然后客户端发送szProductID，szVersion给服务器端，服务器端首先是在m_lsProduct（list）下查找出自己对应的pProductDetail信息，如果没有找到，则使用默认版本，然后根据szVersion在确定的ProductID内得到grayupdate配置的版本，如果没有找到，就用默认版本信息，将得到的数据都保存在item类，返回给客户端。

那思考之前的疑惑，解答如下:

1. 存在一个产品，有多个指定版本升级的情况，测试用例需要增加。
2. 运营线是有14个，但是根据程序内部实现方法（容器循环控制找产品ID），是没必要配置14个的，测试4个，4个产品都能依次正常通过测试，就能保证14个没问题。
3. 交互过程，接口输入输出已表明。
4. 等于的时候是什么情况，得与开发沟通。

 修正测试点如下：