51Testing软件测试论坛

标题: 关于测试的问与答（上）( 转载 ) [打印本页]

作者: 愚人 时间: 2010-7-16 14:26
标题: 关于测试的问与答（上）( 转载 )
尊重作者知识产品，您若喜欢并转载，请标明出处：http://www.javaeye.com/topic/692657

作为芸芸众程序员的一员，我对软件开发中的一切都有着自己的问题。今天是关于测试，作为一名唯物主义者，我相信众物都有其神，于是我找到了测试之神。

我问：神仙哥哥，为什么我们需要测试呀？

大神用他那一贯充满怜悯的眼神看着我，说到：我可怜的孩子们啊，愿上帝保佑你们。之所以需要测试，都是上帝的错啊，上帝创造了你们，但是因为没有测试，所以你们都是不完美的、不理智的，你们会犯错。

我说：我明白了，因为我们每个人都各不相同，我们会被情绪、环境左右，不理智、价值驱动，而我们的大脑也是有限的，更糟糕的是那狭小的大脑只有该死的5%得到了开发，所以我们需要测试。

大神点点头，他对5%这个数字充满了怜悯，当然，他对任何事情都充满怜悯。我想，我该叫他怜悯之神。

我接着问：我们需要测试，可是，为什么我看测试人员只是天天敲键盘而已啊？

怜悯之神说：你的工作难道不也是天天敲键盘吗？

我想了一下，说：那不一样，我敲键盘是在写代码，那些漂亮的页面、增删改查都是代码实现的。

怜悯之神说：开发人员敲键盘是在写代码，测试人员敲键盘是在获取当前系统的信息，这两者真正的工作都是那些脑力活动，是在敲击键盘这个物理行为之前以及伴随这些物理行为的脑力活动。如果你敲击键盘的时候没有进行思考，那么你就不是在进行开发和测试；而且，如果你在思考但是没有敲击键盘，你还是可能在进行开发和测试。

我说：关键是思考。

怜悯之神说：是的。他显然对后半句犹豫了一下，但是还是说了，人类一思考，上帝就带领我们发笑。

我想，这有什么好笑的吗，连朝鲜昨晚都进球了。我说，其实对软件开发人员来说，我们也应该通过使用自己的产品来对他进行测试。

怜悯之神点点头，说，如果你都对自己的产品感到担心和鄙夷，别人为什么要买它？

我说，可是，除非我们开发的是开发工具，否则我们根本不可能用它。地球人都知道，在某个神奇的地方，做减肥药的从来不喝自己的减肥药，买火腿肠的从来不吃火腿肠....人人都需要是化学家。

怜悯之神说：完全由软件开发人员构成的测试样本不太可能代表整个用户群。

我自言自语道，所以我们需要测试人员，需要另一个角度的思考。

等等，我说，尽管测试人员测试了，但是为什么系统还是存在缺陷哩，难道他们不对所有可能性都进行测试的吗？

怜悯之神翻了我一个白眼，他叹了口气，说道，该死的5%啊。作为报复，在下面的叙述中，我将称他为白眼之神。

白眼之神说，对任何程序而言，可能进行的测试数据都是无限的。测试也许可以令人信服的表明存在缺陷，但是永远无法表明不存在缺陷。

我想了想，说，你说的有道理，我们现在的系统需要导入客户的遗留数据，光报表就多达20万，如果一张张的校验报表内容和样式，那么一定会死人的。

白眼之神说，那你们是怎样测试的哩？

我说，抽取样本测试哈。我说，我明白了，由于我们无法测试所有的可能性，那么任何测试实际上都是某种程度的样本测试，这些样本以某种方式代表整个可能测试集合的一个部分或者片段。测试只是采样！

白眼之神点点头，说，实际上，采样也是一个心理过程，而且是一个感性过程，令某人满意的样本也许会让另外一个觉得一点都不满意。

我接着说，由于不可能进行穷举测试，所以我们往往在两个目标间徘徊：希望测试能够覆盖所有令人感兴趣的条件，希望测试集减少到可以管理和承受的程度。就像吃自助餐，希望吃到所有东西，但是又要不把肚皮撑破。

白眼之神说，所以我们需要尽可能选择那些具有最强代表性的样本进行测试，而这是专业测试人员的优势。另外，多样化样本发现的问题可能超过大样本发现的问题，同样，测试团队多样化也可能发现更多的问题。

我说，我想想，我们现在也在进行测试，在开发中，我们采用了TDD的方式，我们单元功能测试的覆盖率很不错，这样，我想单元测试可以减少测试人员？减少系统测试？

神说，你会因为一架飞机保证它所有的部件在组装前都进行了测试而乘坐它的处女航吗？

我说，哦，罗老号发射失败了。

神说，但是，良好的单元测试能够为系统测试去除噪音。

我说，缺陷都不是自己钻进去的，而是开发人员放前去的。单元测试能够在一定程度上阻挡开发过程中缺陷的进入，同时阻挡一些简单的缺陷，系统测试不能捕获所有缺陷，相对单元测试，会花费更长的时间和成本，这些时间和成本能够通过单元测试得到部分节约。

神说，开发人员的测试保证了他对需求的理解和实现的一致，但是开发人员对需求的理解和真正的需求一定一致吗？

我说，所以需要测试人员来即时验收。

神说，另外，从心理学的角度说，一个人很难发现自己的错误，所以TDD和结对编程一起实践会有比较好的效果。

我说，好吧，测试很重要，可是为什么很多项目最后的集成测试阶段会那么长哩？这总是导致我们的项目延期。

神说，说说你们的集成测试阶段都在做些什么？

我说，噢，我们拉出一个发布分支，冻结代码提交，开始进行测试，查明缺陷原因，根据重要性修改缺陷，然后重新测试，以此循环。恩，问题在于我们每修复一些缺陷总会引入新的缺陷，所以这个时间拉得很长。

神说，修复缺陷的同时引入新缺陷，这叫做故障反馈率（FFR），也就是一个修复让系统中产生了另一个缺陷的情况所占的百分比。这个数值如果在50%以下就很幸福了，另外，压力和试图提高缺陷修复速度都会提高FFR。

我说，也就是修复缺陷的同时引入新缺陷是个正常情况。恩，可是我的问题是为什么最后的测试阶段需要花费这么长时间？

神说，难道你不觉得是你们经理错误的估计了最后集成测试阶段所应该花费的时间？

我说，oh。

神说，测试不等于除错，把整个集成测试阶段归于测试是不公平的。

我说，是的，如果区分开，相比测试，除错占据了更多时间。恩，我们现在的一个项目特性，由于开发时没有考虑性

能问题，导致上线时花费了大量时间。

神说，项目延期的主要问题在于测试推迟。

我说，是的，这个给我的印象很深，如果在开发阶段就进行大数据的测试，那么会节省很多时间。

神说，所以要测试先行，并且测试往往在项目开始开发前都已经开始了，测试需要贯穿于整个开发过程，而是不推迟到最后的集成测试阶段。TDD和持续集成是很不错的实践，但是它们仅仅是一部分。

我说，还好，我们还有测试，不像某些疫苗，直接上市。那么，测试保证了质量？

神说，你觉得蒙牛没有测试吗？

我说，....

神说，测试只是提供信息。至于这些信息的定义、重要性以及所要采取的反应都取决于人，而人做出的决定都是感性的，利益驱动的。

我叹口气，说，测试能够保证软件质量。

神说，如果开发的产品本身就质量低劣，进行测试你不觉得是浪费大家的时间吗？一段时间发现的缺陷越多，并不意味着剩下的缺陷越少，而是意味着会出现更多的缺陷。

我说，我明白了，测试只是反馈信息，除此之外，并不能做其他任何事情。正如我们去体检，体检报告只能反映当时我们的身体状态，至于健不健康，则取决于我们平时的生活习惯，这是两个分开的事情，体检并不保证我的健康。

神说，是的。

我说，那么，很多大公司非常看重测试部门，原因其实是他们无法看清楚他们自己的开发过程，于是只能从测试里获取信息，而这些信息对整个软件开发来说只是一部分而已。我看到过有项目经理向测试人员询问是否可以交付，这根本上就是在推卸责任，信息和作出决定根本是两回事，如果是这样，不如让测试人员来当经理好了。

（未完待续）

作者: binddianxianzi 时间: 2010-7-16 14:30
有创意，支持下

作者: chengning 时间: 2010-7-16 15:17
谢谢分享

作者: 投缘 时间: 2010-7-16 17:17
真有创意！！

作者: Jackc 时间: 2010-7-16 17:30
前面说的都很好~

除了最后一句：“我说，那么，很多大公司非常看重测试部门，原因其实是他们无法看清楚他们自己的开发过程，于是只能从测试里获取信息，而这些信息对整个软件开发来说只是一部分而已。我看到过有项目经理向测试人员询问是否可以交付，这根本上就是在推卸责任，信息和作出决定根本是两回事，如果是这样，不如让测试人员来当经理好了。”

按照这个理解，MS算是最看不清开发过程的公司了。

作者: 愚人 时间: 2010-7-16 17:35

原帖由 Jackc 于 2010-7-16 17:30 发表
前面说的都很好~

除了最后一句：“我说，那么，很多大公司非常看重测试部门，原因其实是他们无法看清楚他们自己的开发过程，于是只能从测试里获取信息，而这些信息对整个软件开发来说只是一部分而已。我看到过有项 ...

呵呵，最后的是不同意，可能是还没完吧……

作者: Carl_Lew 时间: 2010-7-16 17:39
是否决定交付是项目经理说了算，但他也是以测试部门的测试结果和缺陷库状态为重要依据的，难不成他是火星来的神仙，呵呵

作者: gyjtest 时间: 2010-7-16 17:52
恩，挺好。。。

作者: peag 时间: 2010-8-4 09:13
::yxiao:::

作者: 愚人 时间: 2010-8-4 21:44
等着坐着写下半部分呢，可惜还没有……

作者: liuwwb 时间: 2010-8-5 15:08
很強大！

作者: how2fly 时间: 2010-10-28 20:18
很犀利，很轻大。。。

作者: 449180704 时间: 2010-11-4 13:39

强悍

作者: liangshi 时间: 2010-11-7 20:55
我在51testing上写了一篇博客文章表达了一些不同观点。

荣浩先生认为“测试只是反馈信息，除此之外，并不能做其他任何事情”。但是得出这一结论的推理过程是不严密的。

荣浩先生先用三鹿的例子精彩地指出一个事实：有些企业的负责人不顾质检信息，出于私利，发布有重大缺陷的产品。在这样的企业里，测试活动不能影响产品生产和发布，不能保证质量。之后，荣浩先生提出，如果产品质量非常低劣，测试可以发现大量的缺陷，但是“边测边改”的混乱过程无助于提高质量。

以上两个观点都是令人信服的。但是，它们是对两个极端情况的分析，并不能得出普遍结论“测试只是反馈信息”。在大多数企业中，企业负责人不会草菅人命，他们被客服电话所折磨，也希望自己的产品能有个好质量。在大多数项目中，代码质量即便达不到卓越，但也能够满足基本要求。在这样的环境中，测试可以保证质量吗？

我的观点是：测试不能“保证”质量，但是测试有助于提高质量。

全文：http://www.51testing.com/index.p ... space-itemid-222117

作者: Carl_Lew 时间: 2011-7-8 09:52

我在51testing上写了一篇博客文章表达了一些不同观点。

荣浩先生认为“测试只是反馈信息，除此之外，并不 ...
liangshi 发表于 2010-11-7 20:55

质量是怎么定义的？符合设计要求的就是高质量。所以测试是“保证”质量的一个过程，而不是仅仅为了“提高”。提高这个字眼很模糊，不定量，而企业在产品开发时需要严格的、可以量化的质量控制，达到什么质量事先都应该有期望值的，如果测试过程只是为了“提高”，那测试又能何时结束呢？

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)