请做过单元测试的朋友进来看看我制订的初步测试计划
公司用C#开发,目前进行单元测试计划.公司的测试员代码能力一般,采用配合开发人员做单元测试.我的计划是:1.白盒测试
1)代码审查阶段:用FxCop分析代码是否规范,然后填写代码审查表
2)单元测试阶段:用NUnit进行单元测试,让开发人员写出测试用例,把软件Bug 清单和测试用例执行结果提交测试负责人
2.黑盒测试
进行界面,功能方面的测试.测试人员写出测试用例,填写软件Bug清单
3.评审、提交阶段
1)对源代码文件进行同级评审，给出评审结论
2)提交以下文档
源代码文件包括测试用例代码文件
测试用例执行结果文件
《单元测试报告》
《软件Bug 清单》
这是目前制订的初步计划,请大家看看,不知道有没有不完善要补充的地方.
回复 #1 abens0426 的帖子
代码审查阶段，还可以作pclint检查；白盒测试阶段，需要作用例设计，考虑测试覆盖率问题。
可以和我交流，我也正在负责单元测试开展。
[ 本帖最后由 bozaibuffer 于 2006-6-8 10:00 编辑 ] 谢谢bozaibuffer的回复
公司不允许用QQ,只能用MSN
我的MSN:abens0426@hotmail.com
希望能和你交流~ 我在原内容上加“注”
1.白盒测试
1)代码审查阶段:用FxCop分析代码是否规范,然后填写代码审查表
2)单元测试阶段:用NUnit进行单元测试,让开发人员写出测试用例,把软件Bug 清单和测试用例执行结果提交测试负责人
注：
a。是否界定一下单元，比如是到类级别还是函数级别。
b.如果这个系统比较大，可否可以考虑分别做unit testing和integration testing.
unit testing: 开发人员测试自己的units
integration testing: 开发小组组长（或类似角色）组织，做模块内的联合测试。
2.黑盒测试
进行界面,功能方面的测试.测试人员写出测试用例,填写软件Bug清单
注：但不知功能测试具体采用什么标准。（不过好像您的这个帖子只讨论单元测试）
如果有功能说明文档，可以把功能说明整理为一个一个条目，然后针对每个条目做测试用例。这里同样要考虑覆盖率。
3.评审、提交阶段
1)对源代码文件进行同级评审，给出评审结论
2)提交以下文档
源代码文件包括测试用例代码文件
测试用例执行结果文件
《单元测试报告》
《软件Bug 清单》
注：
可以考虑做Acceptance testing。就是以用户需求说明书为准（如果有的话）。也是把需求条目化，直接检验每个需求条目是否达到要求。 个人认为太泛了,能适用所有的项目.
如果每个项目的计划都一样,那写的必要性就值得考虑了 建议做代码规范审查最好跟开发组长或经理以及开发骨干商量一下，取得他们的同意和支持；单元测试的话还是尽量要让测试人员来做包括测试用例；评审可粗可细甚至可以不作，要根据团队的精力和能力来做，一口吃不成胖子，建议先集中精力做好一方面，然后慢慢扩充。 谢谢分享！ 谢谢了 :victory: :handshake :loveliness: :lol :) :hug: :kiss: :kiss: :kiss: :kiss: :kiss: 找很久了，感激不尽啊 回复 2# bozaibuffer
可以仔细向你请教吗，我给你发的短信，要是可以话互加好友可以吗 单元测试最好还是开发来做，毕竟这样效率更高，而且项目一般也不会等测试写完用例测完再做集成，这样测试的意义就不大了，测试还是主要集中做模块和接口测试。开始的粒度要粗点。
页:
[1]
