测试基础、规则

前天，老吴以他软件测试的经验跟我们讲解了下嵌入式测试的一些方法和要求，没有及时的做笔记和总结，很惭愧。

首先，重点检查测试包里有没有《软件理论手册》、《软件需求说明书》、《软件设计说明书》（《软件模块设计说明书》）、《软件编码报告》、《软件用户手册》。而且这些文档都应该为正式文档，这样才能方便我们测试人员对代码进行测试。如果不是正式的版本，则当我们测试人员需要查找一些函数的时候会带来很大的不便。
而cpp文件名称应与设计子函数名称一一对应，各cpp文件按设计要求放在每个模块子目录下。但有时候，一些程序员并不是专业的计算机专业出身的或一时头脑发热，并没有把每个函数分别设计成一个cpp文件，导致测试人员工作量增大。

每个cpp文件头部、函数头部都应该有注释以下六个条件：
1.前置条件，函数执行时全局或局部变量应满足的条件或应赋予的值
2.后置条件，函数运行后全局或局部变量应处于的状态或取值
3.入口参数，含类型、取值规定
4.出口参数，含类型、取值规定
5.功能说明，函数或方法所完成的功能与使用的算法说明
6.修正说明，原版本信息、修改内容说明、新版本信息。

每一轮测试时发现的BUG整理出一个测试文档，测试文档的名称应包含文档的类型信息、文档形成时间的信息、文档版本的信息、文档版次的信息。每个团队的命名规则可能不尽相同。测试文档中，每个BUG编号信息应包括标识及源码版本信息、类型与流水号信息、缺陷状态。缺陷状态用（）括起来，分为：“待处理”、“已关闭”、“未修复”、“待修复”、“关闭”，其中，
“待处理”：测试员新添加BUG时，BUG编号后面标志为“待处理”；
“已关闭”：如果程序员对上一轮提交的BUG“已修改”，经测试员对下轮代码再次测试确定无误后，将BUG编号后面改为“已关闭”；

“未修复”：如果程序员对上一轮提交的BUG“已修改”,经测试员对下轮代码再次测试发现仍有该类型的BUG，将BUG编号后面改为“未修复”；

"待修复"：如果程序员对上轮提交的BUG提出需要讨论，并未对其进行修改，测试员应将上一轮BUG编号后面改为“待修复”；

“关闭”：对“待修复”、“未修复”的BUG后面改为“关闭”，并在新的一轮测试报告中重新体现出来。

老吴还给我们讲了一些关于单元测试的内容，比如，对于复杂度大于20的函数应采用灰盒测试方法而不采用白盒测试方法。灰盒测试即给一模块输入量，同时在分支的入口的出口打“桩”，观察两个桩函数的输出状况来判断程序出现BUG的位置，再进行相应的白盒测试。

由于嵌入式测试和软件测试有一定的区别，所以老吴并没有给我们详细的讲解测试的方法，只是简单的讲了一些规范，但这也让我受益匪浅。