由谁测试-read.ppt

Scripting Web Tests July 2005 第九次广州软件测试交流会 单元测试经验分享 王 彤 内容介绍 从经历谈单元测试的意义 如何测试？ 由谁测试？ 难于实施的原因及对策 测试工具开发 测试用例设计 提高测试效果效率的方法 从经历谈单元测试的意义 做与不做，反差强烈 保证局部代码质量 改良代码整体结构 回归测试降低后期测试、维护升级成本 回归测试适应频繁变化的需求 使开发过程可控 如何测试？ 单元是什么？ 错误分类 测试方法分类 测试方法选择 人工动态测试简述 单元是什么？ 类？ (太复杂) 函数？(简单实用) 测试方法 从简单示例看方法选择 int Add(int a, int b){ return a-b;}; 自动方法 (无效) 人工动态方法(输入两个1，判断输出是否为2 ) 人工动态测试 设定初始状态 (输入) 执行程序 判断结果是否正确？(输出) 人工设定用例的输入和输出 其他工作可以自动化 小结 以函数为“单元” 分为有特征错误和无特征错误，后者占大多数 测试方法有：人工静态 人工动态 自动静态 自动动态 以人工动态测试为主要方法 由谁测试？ 开发还是测试？根据成本来决定 成本对比 存在问题及解决办法 由测试实施的话…… 成本，在三倍以上？ 两个条件：详细设计文档 足够的具有编码能力的测试员 可能的额外代价：耽误对系统测试、性能测试的准备工作 由开发实施的话…… 影响开发进度？(由测试做更慢) 测不出问题？(否，存在完整性问题) 解决完整性问题的方法：覆盖率检查测试部门核查 最佳方式：边开发边测试 (无需重复理解代码，测试促进开发) 测试部门的责任 能否实施，测试部门是关键 推动 培训 工具开发 完整性核查 小结 应由开发部门实施 解决完整性问题(覆盖率检查)(测试部门人工检查) 测试部门是关键(推动、培训、工具开发、复核) 难于实施的原因及对策 难于实施的原因 对策 也许是这样…… 程序员工作的主题是……解决问题 思维周期 岂干扰、中断思维 学习与实践有何不同？ 对策？ 测试行为分解 小结 对中断/干扰编程思维的本能抵制？ 对策1：自动生成测试代码 对策2：避免编写桩代码 对策3：用简单方法设计测试用例 简单高效，即使不对症，也大有补益 测试工具开发 基本功能 测试代码编写及生成 几个要点 与其他工具比较 测试工具基本功能 自动生成测试代码 开发成本不高 应用效益显著(节约时间 保持思维延续性) 测试代码---产品类 class CMyClass {public:? ? int Add(int i, int j); void Grow(int years) ? ?   CMyClass();? ? virtual ~CMyClass();private:? ? int mAge;? ?? ?//年龄? ? CString mPhase; //年龄阶段}; 测试代码---测试类 class CMyClassTester { CMyClass* pObj; //被测试类的对象指针  CaseBegin(); //用例初始化 CaseEnd(); //用例结束 ClassTest(); //执行本类中的所有测试函数 //各个测试函数加到此后 }; 测试代码---测试函数 void CMyClassTester::Add_int_int() {? ? //第一个测试用例? ? {CaseBegin(); ? ?? ?? ?? ??? //1? ? int i = 0;? ?? ?? ?? ?? ? //2? ? int j = 0;? ?? ?? ?? ?? ? //3? ? int ret = pObj-Add(i, j); //4? ? TestAssert(ret == 0);? ?? ?? //5? ? CaseEnd(); } ? ?? ?? ?? ?? ? //6 } 生成这样子的代码就OK了 void CMyClassTester::Add_int_int() {? ? //第一个测试用例? ? {CaseBegin(); ? ?? ?? ?? ??? ? ? //输入区? ? int ret = pObj-Add(i, j); ? ? //输出区? ? CaseEnd(); } ? ?? ?? ?? ?? ? } 更进一步…… void CMyClass