公司用C#开发,目前进行单元测试计划.公司的测试员代码能力一般,采用配合开发人员做单元测试.我的计划是:
      1.白盒测试
       1)代码审查阶段:用FxCop分析代码是否规范,然后填写代码审查表
       2)单元测试阶段:用NUnit进行单元测试,让开发人员写出测试用例,把软件Bug 清单和测试用例执行结果提交测试负责人
      2.黑盒测试
       进行界面,功能方面的测试.测试人员写出测试用例,填写软件Bug清单
      3.评审、提交阶段
      1)对源代码文件进行同级评审，给出评审结论
      2)提交以下文档
          源代码文件包括测试用例代码文件
          测试用例执行结果文件
        《单元测试报告》
        《软件Bug 清单》

这是目前制订的初步计划,请大家看看,不知道有没有不完善要补充的地方.

代码审查阶段，还可以作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。就是以用户需求说明书为准（如果有的话）。也是把需求条目化，直接检验每个需求条目是否达到要求。

个人认为太泛了,能适用所有的项目.
如果每个项目的计划都一样,那写的必要性就值得考虑了

建议做代码规范审查最好跟开发组长或经理以及开发骨干商量一下，取得他们的同意和支持；单元测试的话还是尽量要让测试人员来做包括测试用例；评审可粗可细甚至可以不作，要根据团队的精力和能力来做，一口吃不成胖子，建议先集中精力做好一方面，然后慢慢扩充。

谢谢分享！

谢谢了