单元测试到底怎么做？该由谁来做！

CMMcloud 2003-01-13 11:19:43

在一个大的项目中，单元测试是不是要专门的人员来做？还是由程序员自己做？
如果由程序员自己做，那么仅靠这种方法好吗？

我们公司的单元测试一般是按函数或者类来做的，不知你们哪里是如何进行的呢？

欢迎大家来参与讨论！来者就有分！

...全文

1667 41 打赏收藏转发到动态举报

写回复

用AI写文章

41 条回复

切换为时间正序

请发表友善的回复…

发表回复

LiwuxLiang 2003-09-05

打赏
举报

开发人员自己做；
不过我觉得用例应该由测试人员审核。
很多开发人员自己编制的用例非常不全面。
可能是角度不同罢。

metome 2003-08-28

打赏
举报

单元测试应该由程序员自己来测，因为他们比较熟悉自己程序的逻辑结构，测试会做的比较全面。

web700 2003-08-16

打赏
举报

单元测试自己编码自己完成,后也可以互相交叉测试完成

hlding 2003-06-24

打赏
举报

严格地说,单元测试应该是有编码人员自己进行测试,除单元测试外的其他种类的测试是应该由转么的测试人员进行;

ntlan 2003-06-23

打赏
举报

白盒由程序员自己测试，黑盒理所当然的由测试组人员测试！

商海连横 2003-06-22

打赏
举报

mark!

fastpoint 2003-05-16

打赏
举报

6月份我的书《测试思想和实践》第6章类测试非常适合你！哈哈

ldkk 2003-05-16

打赏
举报

《测试思想和实践》...等待中...
楼上的书交给哪里出啊？国内测试方面的书很少，能够理论联系实际的更少，希望新书能够开拓大家的视野！

piaocl 2003-05-15

打赏
举报

白盒测试
小公司：开发人员自己来测试
稍微大点公司：测试组配备专门的白盒测试人员，白盒测试一般不交给测试部门去测试
因为现在国内公司一般招聘的测试人员都是做黑盒测试。
大公司：测试项目有的会外包，并且白盒测试工具有自己开发的，有买来的
他们会把程序员的代码来REVIEW一遍，编写测试用例（每个测试人员只是管自己的部分，他这部分需要调用他不知道的接口，会任意输入值，带入自己的测试用例中），用自动化工具执行，生成报告。

当然测试用例中不可能走到所有的分支，因为有些情况是不能100%出现的。

bravebarbarian 2003-05-14

打赏
举报

说了一大堆,到底怎么实现白盒测试,怎么做到走遍每个分支?怎么实现自动测试?
楼上的都是理论家吗?
给我讲讲实际是怎么做的
谢了,各位.

twinsant124 2003-03-14

打赏
举报

to peon():
good:)

wjhs 2003-03-12

打赏
举报

学习学习！

peon 2003-03-12

打赏
举报

xUnit的本质是白合测试，当然至少开始时要程序员来作

与一些其它的自动测试工具不同，xUnit只是一个测试框架，测试的代码是程序员写的，和“捕获/回放”有本质的不同

xUnit的主要用途是单元测试，
一个软件的测试不是只有单元测试就可以的，测试也不只是代码测试，xUnit并没有说自己包办一切
但是可以想象一个软件如果没有经过严格的单元测试，
就像盖房子的砖和钢材水泥不合格，之前的设计，后来的集成测试又能有什么用？！

idlecrook 2003-01-27

打赏
举报

xunit，写代码人负责

standout 2003-01-27

打赏
举报

me!

simon2003 2003-01-27

打赏
举报

单元测试事实上是由开发人员做的。单元测试属白盒测试范畴，所以在大部分的软件公司中，主要是成本的考虑。1、能够进行白盒测试的测试人员的成本太高。
2、如果专门的测试人员进行白盒测试，则要求设计人员写非常详细的设计文档，成本自然提高，而且影响进度。通常的软件公司的详细设计文档都不会特别详细，能够满足大家交流和评审即可。

对于单元测试，对不同的产品测试强度是不同的。
例如：公司通常会开发自己的构件库。例如在开发工具的组件基础上做增强组建，还有一些各个子系统要共用的业务组建。

对这些组件要进行严格的测试，通常是技术负责人，直接开发人员、QA人员都要参与。首先是代码检查，然后依照白盒测试的一些常规方法进行测试，最后，还要由专门的测试人员进行不间断的反复测试。

这些组建相当于盖房子时要用到的建材，质量必须好。根据项目的预算，如果规格特别高，建材就要特别高档，否则就使用一般的。这里的好坏相当于测试的强度、投入的人月。

如果公司的基本组件的质量非常好，软件的架构合理，则普通程序员的开发工作就会相对简单，常规的单元测试的成本就会降低。只要项目小组的负责人进行好例行的检查，开发人员进行完必要的调试后，缺陷的发生率会降低很多。
而这个阶段，测试的主要目的是功能，即软件是否满足了用户的需求，功能方面、易用性方面、性能方面等等。

xqing157 2003-01-27

打赏
举报

我记得我在上学的时候，老师曾说起一个数据（真实性我没有亲自去考究）：
他说：
国外普通软件公司的测试覆盖率至少要做到C2级覆盖（所谓的分支覆盖），软件的缺陷一般要求低于20个/千行，好一点低于2个/千行。而全世界对软件要求最严格的NASA据说要求低于0.2个/千行。要注意的是缺陷的概念还不同于错误。

xqing157 2003-01-27

打赏
举报

现在很多的人一提到单元测试就搬出xunit，并号称单元测试由程序员自己做，而且发现了错误也不用记录，自己更正就行。我想，程序员自己做单元测试可能能解决一部分问题（至少比不做单元测试要好）,对于一些质量要求不高的东西，为了节省资源,这样干也确实是一种省事的做法。我对xunit这个东西并不是很熟悉。对于那些要求非常严格的软件如：航天软件，飞行自动控制软件，火车自动调度软件等，用户经常要问到的问题是：你给我的软件的可靠性是多少？一次运行的成功率是多少？另外，测试中的另一个问题：测试到底要进行到什么地步（测试充分性问题）。“不充分的测试是愚蠢的，而过度的测试是一种罪孽“。通常，传统的处理这些问题的方法是做到一定的覆盖。交付软件的时候给出测试覆盖率，“粗略”估计或评估出可靠性。测试的时候也是通过覆盖率来判断充分性的。不知道xunit能不能给出测试的各种覆盖率。xunit能够“自动执行测试”吧。还有别的很多工具也在号称“自动测试”，不过大都说的是“捕获/回放”，自动回归测试什么的。我总感觉这些东西好像有点像以前的批处理似的。
我理解自动测试应该至少包括两个功能：
1、自动生成测试用例。（满足一定覆盖的测试用例集，不是简单的功能）
2、自动判断测试结果的正确性
软件测试自从1975年以来提出了几个残缺的理论，至今连理论基础上的问题都没有解决。许多的工具都在号称自动测试，一个按钮解决了所有的问题！！！我搞不懂，既然工具把所有的问题都解决了，为什么理论上都还没有突破，软件测试问题居然还是软件工程的一个大问题。

john2003 2003-01-24

打赏
举报

单元测试应该又程序员进行白盒测试。简单方法可以用DEBUG工具设置一些变量的值，通过打印，DEBUG工具内部的WATCHER，观察一些关键的变量/表达式，是否正确实现了应该实现的逻辑。有时间的话开发一些辅助测试函数/工具进行测试，好处是修改时可以较方便的实现测试自动化。个人觉得程序员
将函数级的测试在单元测试中做好就很不错了，可以不用写正式文档。至于功能级的测试可以交给测试人员，需要测试计划/测试用例/测试报告，但是否叫单元测试可以讨论，有人叫子系统测试/功能测试等等，不同公司有不同的做法。开发人员可以参与部分，保证测试的柔性，有些公司可是按BUG数评价开发人员的，结果活干的多的不一定讨好。柔性测试是迅速通知开发人员解决问题，问题报告不采用正式流程，保证版本未正式生成/版本初期错误得到迅速修复。

panq 2003-01-23

打赏
举报

单元测试应该有两次，
程序员自己的测试，以白盒测试为主以黑盒测试为辅。
测试人员(或同组的程序员)的测试，完全是黑盒测试。(应该有边界值测试和性能测试)。
两次的单元测试非常有必要，我经常看到只有程序员自己的测试，往往结果很不如人意。

测试用例书在测试前必须要做成，测试人员将自己的测试内容，测试发现的BUG的情况（条目、类型、解决结果）记录在《单元测试报告》中。