单元测试经验分享

第九次广州软件测试交流会

1单元测试经验分享

王彤Copyright©WWW.GZTEST.NET2007-2-32内容介绍从经历谈单元测试的意义如何测试？由谁测试？难于实施的原因及对策测试工具开发测试用例设计提高测试效果效率的方法3从经历谈单元测试的意义做与不做，反差强烈保证局部代码质量改良代码整体结构

回归测试降低后期测试、维护升级成本

回归测试适应频繁变化的需求

使开发过程可控4如何测试？单元是什么？错误分类测试方法分类测试方法选择人工动态测试简述5单元是什么？类？(太复杂)函数？(简单实用)6崩溃异常超时7测试方法人工根据语法特征或行为特征判断错误，只能发现有特征错误自动静态动态(分析代码)(执行代码)根据人工定义的程序的行为判断错误需测试用例8从简单示例看方法选择

int

Add(inta,intb)

{

returna-b;

};

自动方法(无效)人工动态方法

(输入两个1，判断输出是否为2)将+写成-9人工动态测试

设定初始状态(输入)执行程序判断结果是否正确？(输出)人工设定用例的输入和输出其他工作可以自动化10小结以函数为“单元”分为有特征错误和无特征错误，后者占大多数测试方法有：

人工静态人工动态自动静态自动动态以人工动态测试为主要方法11由谁测试？开发还是测试？根据成本来决定成本对比存在问题及解决办法12事项边开发边测试由测试部门测试理解代码

无需额外费时理解代码

理解别人写的代码难度大，耗时多可测性问题及时解决

累积人员要求

无需额外能力需有编程经验，且三日不写手生

文档要求

有无文档均可

须有详细设计文档

沟通自行修正

反复沟通

促进编程

提高编程效率无成本对比13由测试实施的话……成本，在三倍以上？两个条件：

详细设计文档

足够的具有编码能力的测试员可能的额外代价：

耽误对系统测试、性能测试的准备工作14由开发实施的话……影响开发进度？(由测试做更慢)测不出问题？(否，存在完整性问题)解决完整性问题的方法：

覆盖率检查

测试部门核查最佳方式：边开发边测试(无需重复理解代码，测试促进开发)15测试部门的责任能否实施，测试部门是关键推动培训工具开发完整性核查16小结应由开发部门实施解决完整性问题

(覆盖率检查)

(测试部门人工检查)测试部门是关键

(推动、培训、工具开发、复核)17难于实施的原因及对策

难于实施的原因对策18也许是这样……

程序员工作的主题是……解决问题思维周期岂干扰、中断思维学习与实践有何不同？对策？19测试行为分解行为特点对策编写

测试代码费时长，会中断、干扰思维自动生成编写

桩代码费时长，会中断、干扰思维，可选尽量避免设计

测试用例使设计明确化和细化，可能促进思维。复杂方法费时多，干扰思维使用简单方法20小结

对中断/干扰编程思维的本能抵制？对策1：自动生成测试代码对策2：避免编写桩代码对策3：用简单方法设计测试用例简单高效，即使不对症，也大有补益21测试工具开发基本功能测试代码编写及生成几个要点与其他工具比较22测试工具基本功能自动生成测试代码开发成本不高应用效益显著

(节约时间保持思维延续性)23测试代码---产品类classCMyClass{

public:

int

Add(inti,intj);

void

Grow(intyears)

CMyClass();

virtual~CMyClass();

private:

int

mAge;

//年龄

CString

mPhase;//年龄阶段

};24测试代码---测试类class

CMyClassTester{

CMyClass*pObj;//被测试类的对象指针

CaseBegin();//用例初始化

CaseEnd();//用例结束

ClassTest();//执行本类中的所有测试函数

//各个测试函数加到此后};25测试代码---测试函数void

CMyClassTester::Add_int_int(){

//第一个测试用例

{CaseBegin();

//1

inti=0;

//2

intj=0;

//3

intret=pObj->Add(i,j);//4

TestAssert(ret==0);

//5

CaseEnd();}

//6}26生成这样子的代码就OK了void

CMyClassTester::Add_int_int(){

//第一个测试用例

{CaseBegin();

//输入区

intret=pObj->Add(i,j);

//输出区

CaseEnd();}

}27更进一步……void

CMyClassTester::Add_int_int(){

//第一个测试用例

{CaseBegin();

//1

inti=;

//2

intj=;

//3

intret=pObj->Add(i,j);//4

TestAssert(ret==);

//5

CaseEnd();}

//6}28测试代码---成员访问void

CMyClassTester::Grow_int{

{CaseBegin();

intyears=1;

pObj->mAge=8;

pObj->Grow(years);

TestAssert(pObj->mAge==9);

TestAssert(pObj->mPhase=="儿童");

CaseEnd();}

}29工作方式测试工具负责生成测试代码，接收/处理测试结果由开发环境编译测试代码，执行测试工程即运行测试测试结果通过进程间通讯技术发送到工具测试代码相当单纯30要点---运行控制voidRunTest()

{

CMyClassTestertester;

tester.Add_int_int();

}通过修改代码来控制执行哪个测试31要点---预期输出的判断

TestAssert(boolresult,

char*file=__FILE__,

intline=__LINE){

if(!result)

SendMsgToTool(file,line);}测试失败时，发送文件名和行号给工具32要点---访问私有成员测试私有函数读写私有成员前/后置操作

友元拷贝33与其他工具的比较

与xUnit比较(效率差异)

与自动测试工具比较(应用方式不同)无特征错误有特征错误人工测试效果自动测试效果34演示免费工具演示35小结基本功能

(自动生成测试代码)编写规范的测试代码作为模板，用工具生成之可以参考现有产品36测试用例设计简单地设计测试用例37测试用例基本要素设定输入执行判断输出38有限证明程序正确?已测试的输入

可以证明正确未测试的输入

可能含有错误假设用例本身没有错误！39完整性问题????未测试的输入

往往不知道还有多少……40好的用例好的用例就是完整性高的用例集合每一种可能输入都有对应用例完整地定义了程序的行为在用例所覆盖的范围内，任何修改引入的错误都可以发现(回归测试)是“每一种输入”，非“每一个输入”41什么叫一种输入？如…char*strtrm(char*pstr);去除字符串两边的空格“ABCD”(右边有空格)“AAAA”(两边无空格)NULL(空指针)就是“等价类”42如何编写健壮的程序？即使不考虑测试……编程时各种输入都要考虑正常输入(几种正常输入?)边界输入(几种边界输入?)非法输入(几种非常输入?)就是“功能点”43功能点等价类只有左边有空格，返回删除左边空格后的结果左边有空格只有右边有空格，返回删除右边空格后的结果右边有空格两边都有空格，返回删除两边空格后的结果两边有空格两边都没有空格，返回原串两边无空格空串，直接返回空串空指针，直接返回空指针功能点与等价类对应关系示例44设计用例的简单方法用例与功能点具有对应关系程序功能细化、明确化，列成“什么输入，应产生什么输出”的形式，就是测试用例45输入输出是……输入(读取的数据)

参数成员变量全局变量外部媒体输出(改写的数据)

返回值输出参数成员变量全局变量

外部媒体输入要设定初始值，输出要判断结果是否符合预期只考虑真正需读/写的数据46小结完整性高的用例集就是好用例程序功能细化、明确化，就是测试用例47开发测试过程开始编写实现代码时才生成测试代码

(函数名/参数等已确定)完善第一个用例将程序功能细化，用拷贝/修改的方式建立其他用例只调试失败的测试，使用测试代码调试其实并没有多做什么48提高效果效率的方法如何提高测试效果？如何提高测试效率？49提高测试效果效果就是测试用例完整性如何衡量完整性？

如果保证完整性？50白盒覆盖找出遗漏用例void

Func(int*p){

if(p){*p=0;}

else{return;}}假如未测试空指针，则else分支未覆盖理想的覆盖组合：

100%语句、条件、分支、路径覆盖51白盒覆盖的缺陷void

Func(int*p){*p=0;}特殊输入通常导致崩溃、异常、超时，正是自动

动态测试的理想猎物不能发现“忘记处理某些特殊输入”形成的