引言

将我公司软件开发的细节按软件工程的周期进行划分,并从下面这几个部分总结软件更改的思路和一些准则,希望可以在数值更改方面或更改测试方面提供一些思路，并提高测试的质量和效率。

我们按软件工程的开发测试流程进行划分，可分为下面8个主要部分：理解需求分析、功能定义、接口定义、功能模块/函数划分、功能模块/函数初始化及功能实现、功能模块/函数接口衔接及限制、功能模块/函数功能测试及代码规范确认、做好文档记录。

在实际测试工作中，发现程序的bug主要是由下面5类错误组成：

①代码设计时设计人员没想好程序运行的流程。

② 没有确认自己这段代码的目的，这个很重要。要不就是没有达到设计目的，要不就是设计的目的不明确，导致变量定义、代码结构、函数实现方面有混乱。

③ 一些笔误和粗心。特别是没读懂或读完原来的程序就进行修改，尤其是功能模块/函数定义、MCU的寄存器及接口部分往往被忽略。

④ 对控制逻辑的理解,完全按照逻辑文字的要求来写代码。理解有歧义时,往往按代码编写人员自己的理解写代码。

⑤ 对公司或部门的标准和经验的理解不足。

而这5类错误中有4类错误主要集中在软件设计部分。因此我们强烈建议：嵌入式软件的设计和开发，不要混在一起，最好分为两个单独的过程，即软件设计过程和代码开发过程。传统的设计人员，喜欢对整个软件开发过程进行研究，且更侧重代码编程、代码测试和项目规划，并将设计和开发混在一起进行。现在则提出将软件设计这部分单独提出来，并对软件设计这部分进行过程分析。先设计再编写代码的思路被提出。

本文将通过5个具体实例（集中在数值更改测试方面），说明先设计再编写代码的思路在黑盒测试中的作用和方法。

1数值更改黑盒测试的思路

首先描述一下数值更改的几种设计思路和模式。一般设计员进行数值更改是使用直接查找工程文件的方法。查找到需要更改的数值，就直接使用新数值进行更改。多数设计员认为只要没有漏改数值，就不会有问题。但不幸的是，还是会被测试人员发现一些bug。我们将按照上文到的软件工程开发测试流程的8个模块进行分析，提供一些数值更改的思路。

案例1软件设计过程中没有确认自己这段代码的目的，对一些公司或部门的标准和经验的理解不足。

我们规定按键采样的有效时间为80~120 ms,这是长期实验和工程实验积累下来的经验值，在这个采样范围内，绝大多数人按键感觉良好，很少有延迟或过快的抱怨。

但如果对这个需求了解不清楚,认为只要有按键采样在80~120 ms范围内就可以了，而对MCU的时间基准范围要求不严，就有可能导致很大的误差。如某控制器的按键处理是以50 ms为时间基准，连续判断3次，如图1所示。

图1

采用50 ms为时间基准，采样出来结果的区别就很大。最大采样为100 ms+49 ms+49 ms，即198 ms；最小采样为100 ms+1 ms+1 ms，即102 ms,差别是96 ms，故时间基准要调整到5~10 ms，连续判断20~10次较可靠。

案例2软件设计过程中没有确认自己这段代码的目的，导致一些笔误。

我们应该了解定义为unsigned int，unsigned char，signed int， signed char的不同,不但要注意不同字节大小之间变量运算的问题，而且还要注意有符号和无符号字节之间的运算问题。

下面是在某款支持ANSI/ISO C99标准的编译器上调试的例子：

unsigned int u161=0x0305;

signed int s161=-0x0102;

unsigned char u81=0x05;

signed char s81=-0x02;

signed int temps,temps1,temps2,temps3;

unsigned int tempu,tempu1,tempu2,tempu3;

temps=s161 -u161;

tempu=s161 -u161;

temps1=s161 *u161;

tempu1=s161 *u161;

temps2=s81 -u81;

tempu2=s81 -u81;

temps3=s81 *u81;

tempu3=s81 *u81;

图2是编译、运行后对运行结果按十进制查看的内容。 图3是编译、运行后对运行结果按二进制查看的内容。

图2

图3

下面这个实际例子是个典型的有符号和无符号减法运算的问题。当外机阀门开度变化较大时,会出现开/关的不断循环动作。其原因是：阀门开度变化达到一个较大的数值(如一百多)，使阀门开度下调时计值溢出。

void Fun_EXV1_Run( void ){

int temp_step=0;//定义为整型，真正的问题在这里

signed int actual_DOS=150;

//这里要求进行数值更改，原来是50，现更改到150

……

temp_step=EXV1_TargetStep;

//任务通信得到新的temp_step的值

……

temp_step=temp_stepactual_DOS;

//求得当前阀门开度，整型减有符号，有可能高位置1

……

if ( temp_step > 50 ){

temp_step=temp_step 50;

}

……

}

有效的更改方法很简单，将int temp_step 更改为signed int temp_step,定义为有符号整型。并再输出接口函数进行符号判断。由判断结果进行输出。

案例3软件设计过程中对控制逻辑的理解,完全按照逻辑文字的要求来写代码。没有进行需求分析思考，导致相关功能模块/函数接口衔接及限制上的错误。如某控制器逻辑更改为：外风机启动后3 s压缩机才启动，但没考虑到感温包故障检测需要5 s。导致测试时发现开机前有感温包故障时，压缩机会先开启2 s，然后立即关闭。

有效的更改方法很简单，逻辑更改为外风机启动后10 s,压缩机才启动。如此既能达到系统的需求，又兼顾了故障检测的时间。

案例4代码开发过程中没想好程序运行的流程，以及在功能模块/函数接口衔接及限制方面可能犯的错误。

如某控制器的模式转换检测时间100 ms，而风速转换检测时间50 ms。测试时发现自动风速条件下转模式时，进入制热防冷风时刻，内风机会先动作一下再停下来。其原因是，软件先检测到有风速变化，便先按风速函数运行，延后50 ms才到模式转换函数，故风机先按风速函数运行动作一下，再到制热防冷风条件，关内风机。更改倒也简单。将模式转换检测时间更改为50 ms，而风速转换检测时间更改为100 ms即可。

如某控制器通信的处理，需注意不少控制器是直接传递温度值，这样就有加100再传递的问题（预防通信数据传递负数）。这时要小心越界（通信传递数值可能会超过255）和显示处理。如此不仅仅主控程序要考虑是加100还是加30等数值。显示板的程序也需要考虑同步更改。

案例5代码开发过程中功能模块/函数功能测试及代码规范确认不认真，导致一些笔误。如将十进制和十六进制写错等。temp_display=0x23与temp_display=23，其结果是完全不同的。

某控制器程序更改送测是因为：更改保护次数不同，负载的动作是否合理。制热正常运行当中出现排气高温保护，前两次的排气高温保护时内风机会立刻关闭，没有吹余热，而出现第三次排气高温保护时内风机才会吹余热。结果测试发现机组处于单冷机型时，负载不动作。

if(Out_Status3_main& 0x04)!=0){

//应该是0x08，0x04是笔误

Create_Task(0x02,0x02);//机组运行结束

}

但更改程序时,将通信协议的BIT2、BIT3看错，如图4所示,导致单冷机型无法开启内风机。

图4

以上的案例更改虽然是数值更改，但体现了代码开发过程中对功能模块/函数功能测试及代码规范确认的必要性。

2典型的数值更改测试思路

针对数值更改的设计思路和模式，相应的测试思路如下：

① 首先确定设计更改的需求是否达到目的。

② 确认设计更改点所处的功能模块的功能是否满足要求。

③ 找出该更改点涉及的相关功能和接口。找相关接口要注意查阅相关的设计文档，如接口定义、通信协议、程序结构、芯片资料、设计标准等。设计人员的笔误往往集中在更改点涉及的相关接口。

④ 确认更改点涉及部分的功能是否满足要求。

⑤ 按测试要求做好测试记录并最后出具报告。

3总结

总的原则是：软件更改及测试需要建立一个完整的闭环流程，并有意识地区分软件设计和代码设计这两个节点。这里分作3个部分进行描述。

首先是送测信息的全面性。送测申请单应该先体现设计的更改评估，包括更改原因及具体更改点、更改涉及点描述。然后由测试人员按上文提到的数值更改测试思路出具测试方案，进行闭环控制。

其次，对设计人员不要急着进行代码修改。关键是理清更改的思路，按软件工程的开发测试流程先进行更改点的软件设计。明确了更改的目的，并确认了更改点最少又能达到更改目的的方法，再进行代码更改。确认更改点及更改涉及点是否完整，有没有遗漏。最后对自己的代码进行功能确认和代码风格确认，并做好文档记录。

最后是测试环节。对测试人员，测试的难点主要集中在找出该更改点涉及的相关功能和接口。这里就要注意以前述数值更改设计思路为指引，从相关的设计文档中寻找更改点。