白盒测试到底怎么做

[kernelkoder]

以前做过一点白盒测试,就是搞代码覆盖率,达到100%结束,代码本身什么逻辑自己一点都不知道,大家是怎么做白盒测试的?白盒测试和单元测试是一样的吗?具体测试写什么方面

[以专业开发人员为伍]

可悲啊。这种“白盒”能发现什么问题呢？ 单元测试本身就是一种白盒测试。但是，白盒测试不是你说的那种悲催的目的。 单元测试只是一种手段而已，关键是要测试的目的是什么。在设计测试用例的时候，要考虑到时间成本，要注意不能过度低级地把不好的东西（原本应该留下“灰色地带”进行删除的）当作外在标准，要知道需求总是千变万化的、架构总会在三四个月之后重构的。 进行自动化测试，要在整个工程开发中进行，而不是跟在人家开发人员屁股后边滞后一两个月才进行，更不能只做一丁点皮毛。 要使用随机生成测试数据，要打乱测试顺序，要对几乎所有的测试用例进行多线程并发，绝不是用固定的顺序、固定的测试数据来测试。只有这样才能真正发现bug。

[以专业开发人员为伍]

要 用 源 代 码 开 发 工 具 直 接 编 写 测 试，要 在 源 代 码工 程中 直 接 附 带测 试 工程，要 让 开 发 人 员 做 测 试（而 不 是 手 工 测 试 人 员去自 欺 欺 人地 搞 自 动化 测 试）。

[cat_yan]

sp1234这个斑竹 什么叫过度低级？开发出来的功能并不是只是为了彰显开发有多牛X。逻辑有多复杂，用各种高端的技术；每一个功能是给用户使用的，并不是没有用户都是你这么牛X的人，他们是懂得傻瓜式操作。。。

[kernelkoder]

谢谢指教,非常感谢

[火山企鹅]

引用 2 楼 sp1234 的回复:

要 用 源 代 码 开 发 工 具 直 接 编 写 测 试，要 在 源 代 码工 程中 直 接 附 带测 试 工程，要 让 开 发 人 员 做 测 试（而 不 是 手 工 测 试 人 员去自 欺 欺 人地 搞 自 动化 测 试）。

这说话也太武断了！什么叫手工测试人员去自欺欺人的搞自动化测试？显然是不太懂测试，我来给你补一下。 对于代码级别的测试，通常采用白盒测试手段进行，而具体的白盒测试手段大家最熟悉的就是单元测试，至于单元测试具体由谁来做？这并无定论，可以由具备代码能力的专业测试人员来做，也可以由开发人员自己来做，甚至可以采用Peer Review的方式让其他开发人员来做。在采用TDD模式开发的项目中，也可以由开发或者测试人员先编写好测试案例，然后再实现功能代码，只不过通常从效率角度考虑，大多数项目和公司，单元测试都是由开发人员自己在做，测试人员主要负责更高级别的测试，例如集成测试，系统测试，验收测试等。

[火山企鹅]

引用 楼主 kernelkoder 的回复:

以前做过一点白盒测试,就是搞代码覆盖率,达到100%结束,代码本身什么逻辑自己一点都不知道,大家是怎么做白盒测试的?白盒测试和单元测试是一样的吗?具体测试写什么方面

再回答一下楼主的问题，你以前做白盒测试主要为了达到一定的覆盖率，不考虑代码本身的逻辑，其实是错误的，真正的代码测试是需要考虑代码的逻辑的。因为单元测试的覆盖率有很多种，例如分支覆盖，路径覆盖，语句覆盖等，而语句覆盖是这里边严谨程度最低的，也是最容易的，同时语句覆盖通常不考虑代码之间的逻辑，估计你以前做的都是语句覆盖。而一段代码只做到了语句覆盖率100%，其实是有问题的，并不能保障这段代码不存在潜在风险，所以，通常我们做代码测试是需要做多做覆盖率来保证真正的质量，至于在具体编写测试脚本时，可以采用熟悉或者项目采用的单元测试框架，例如Junit，NUnit，XUnit等等。

[火山企鹅]

【本人微信订阅号：大维谈测试】可以搜索wei_talk_testing添加，或者扫描下方二维码。

[BrightFireOfCy]

eclipse 默认F6 vs默认F10

看这里==============================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================当然是开玩笑的

看这里==============================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================当然是开玩笑的

[以专业开发人员为伍]

普及一下知识吧：为了“覆盖率”而写单元测试，“代码本身什么逻辑自己一点都不知道”，这就是“过的低级”的！ 开发人员如果写单元测试的目的正确了，他绝对不会写这种测试的。那么这种测试是谁写的？不言自明！

[以专业开发人员为伍]

这就是“过的低级”的 --> 这就是“过度低级”的 这就是过度低级的，这就是自欺欺人的测试。这种测试如果是程序员写的，那么也是为了低级的目的被那些外行给胁迫的。 而如果一个单元测试是审时度势地可以比较精巧地驱动出开发进度和质量的，根本不会产生“为了追求代码覆盖率，代码本身什么逻辑自己一点都不知道”这种感觉。能够产生后者这种感慨，那么你们的开发部门的领导必定也是不太懂自动化测试，而是只多懂一些手工测试理论。

[以专业开发人员为伍]

我们完全可以反观一下，如果一个手工测试人员，总是会准时地写出“透视出产品研发进度、关键机制”的白盒测试代码，它是干什么的？是干测试的？ 抄袭一些测试理论术语很容易。这些人写出来的测试用例，有多大价值呢？他们在工作中真的能像他们说的那样“这个覆盖率，那个覆盖率”，还能保证尽量在公司人力财力范围之内？他们做好，还是只会唱？ 凭心而论，你见过哪一个手工测试人员具有研发团队程序经理完全一样的编程水准，可以深度地解抛程序深层次内部，而还能够甘心做一个手工测试人员的？！ 事实上出现lz那种感慨，我们完全可以理解为这是手工测试人员“免为其难”的胡乱些什么白盒测试的“正常”结果。如果这是开发人员写的，那么就偏离了自动化测试的应有的角度。

[火山企鹅]

我严重不同意楼上的说法，你的每一个回复我个人认为感情色彩太浓烈，我不知道你本身是从事什么方面的工作，但是我觉得你并不真正了解测试，或者说你并没有见过真正做测试做得很专业的团队，公司。所以在这种情况下你说的话总是那么武断，我甚至都怀疑你有灌水的嫌疑，因为每次回帖，本来一个回复可以搞定的事情，非要写2-3个回复，就从这一点上而言，给人的感觉也不够专业。

[BrightFireOfCy]

引用 楼主 kernelkoder 的回复:

以前做过一点白盒测试,就是搞代码覆盖率,达到100%结束,代码本身什么逻辑自己一点都不知道,大家是怎么做白盒测试的?白盒测试和单元测试是一样的吗?具体测试写什么方面

不管百盒黑盒或者其他所有的测试方法，不知道业务逻辑是不行的。 测试的目的是什么？是去找实现和需求不一致的地方（测试证明不了你的程序是正确的，只能证明你程序不正确） 所以需求就是重点，业务逻辑是需求演变而来的，所以，不知道业务逻辑的测试是无效的，比如lz这种。

[缪军]

引用 8 楼 peacedog 的回复:

我来给你补一下...至于单元测试具体由谁来做？这并无定论

我有个现实问题: 如果不是开发者自己测试,比如:A接收工单,B做测试 那么直到工单通过测试所消耗的工时如何考核?到底是A耽误了时间还是B呢?

[火山企鹅]

引用 16 楼 microtry 的回复:

[quote=引用 8 楼 peacedog 的回复:] 我来给你补一下...至于单元测试具体由谁来做？这并无定论

我有个现实问题: 如果不是开发者自己测试,比如:A接收工单,B做测试 那么直到工单通过测试所消耗的工时如何考核?到底是A耽误了时间还是B呢?[/quote] 我认为你要规范，例如开发一个工单需要多少时间，如果开发人员在规定时间内完成，并交付给测试，那应该不算延误；测试也同样。另外，为了规避开发为了追赶时间而不确保质量的问题，应该引入缺陷考核。

[缪军]

引用 17 楼 peacedog 的回复:

我认为你要规范，例如开发一个工单需要多少时间，如果开发人员在规定时间内完成，并交付给测试，那应该不算延误；测试也同样。另外，为了规避开发为了追赶时间而不确保质量的问题，应该引入缺陷考核。

你们真的是这样做的?我的意思是耽误的时间算在谁头上?