51Testing软件测试论坛

标题: 男孩女孩看过来：测试是为了什么，基于什么做测试 [打印本页]

作者: 菊子402 时间: 2010-2-11 16:35
标题: 男孩女孩看过来：测试是为了什么，基于什么做测试

测试人，谈谈你对测试的感悟！

做测试是为了什么

你肯定要说，学过理论，或者用膝盖都能想出来，测试当然是为了符合设计需求，保证产品质量等等等等。我劝你打住，理论我自己能google出来。
符合设计需求？，需求不是我定义的，定义那会儿也不让我参加，我哪知道那一条条定义想表明怎样一个cool的产品呢，怎么cool的呢？只能根据现有市场产品想像，揣摩公司老总的心理，看他们想卖出一什么东东。保证产品质量？，地球人都知道没有产品能做到没有bug，做到什么程度能被接受呢，别一出问题就往测试人头上摔。

基于什么做测试

别告诉我要根据需求文档，否则我当你没认真做过测试。
我先抛砖，我主张根据市场定位做测试。把产品交给测试人员时第一步要把产品定位描述清，用于哪个行业、什么人用、怎么用；然后才是功能定义、界面定义（不过好像没公司这么干）。

为吸引眼球附带激将，语气夸张，热烈欢迎大家沉着冷静地分析之讨论之，鲜花鸡蛋皆可，雁过留名！

作者: sunfly_3333 时间: 2010-2-12 10:22
做过技术支持，深刻的体会到产品质量对用户使用及市场拓展的重要性，做测试的目的有三：一，尽可能的发现有不同影响程度的bug，这样生活会变得丰富和有挑战；二，不会像开发那样，人未老，头先白；三，本人摩羯座，测试正是挣钱糊口的一条出路，性格的一种延续。
测试的依据：一，首先是需求文档，这个是基础，是最最基本的；二，对业务的理解，对系统架构的理解，这是重要的补充，往往有些bug是从宏观角度上浮现的。因为测试资源（文档、时间、人员等）的有限性，限制了发现bug的覆盖度，如果要保证测试的效率，就逃不开文档和测试人员的经验，尤其后者是更难能可贵、更突出人员能动性的。

作者: bobo45123 时间: 2010-2-16 21:39
做测试是为了什么？
除了保证产品的质量，想不出别的目的（质量好了，产品好销售，很容易提升品牌形象，NOKIA不正是一个例子吗）

基于什么做测试？
当然是基于用例文档来做测试了，至于楼主所说，‘别告诉我要根据需求文档，否则我当你没认真做过测试。’我怀疑贵公司一定没有需求文档和产品定义书吧。当然大部分公司的需求文档不会定义的很详细，只能将功能点的一个大概列出来。其它的就得测试人员去和研发人员沟通，一般去找平台人员去了解客户需要什么样的产品，什么功能等。然后去编写自己的测试用例文档，在实际测试过程中测试完全基于测试用例。

作者: 51testing-wn 时间: 2010-2-18 15:47
首先你需要了解什么是软件测试。其次，在不同公司人员的角色和分工都是不一样的，在每个阶段或者遇到问题的时候，你需要找到正确的人help or support you

作者: zhumingli 时间: 2010-2-19 13:17
测试人员需要了解产品在市场上，用户是如何使用的，这一点越发的重要了。很多情况下根据SRS来进行测试会脱离客户。

作者: 小不点蜗牛 时间: 2010-2-20 09:29
打酱油的，学习之

作者: lonewolf 时间: 2010-2-20 11:10
做测试是为了什么
你肯定要说，学过理论，或者用膝盖都能想出来，测试当然是为了符合设计需求，保证产品质量等等等等。我劝你打住，理论我自己能google出来。
-->做测试本来就是一件很简单的事。目的也很单纯。就是为了符合设计需求，保证产品质量...你用不用google，它都是这么一个道理。

符合设计需求？，需求不是我定义的，定义那会儿也不让我参加，
-->原则上，需求定义是不需要你参加的，那是别人的事儿！没有必要听你的意见。你的任务就是要保证他提出的需求在产品中被完全正确地实现出来了。

我哪知道那一条条定义想表明怎样一个cool的产品呢，怎么cool的呢？
-->不知道可以问，你不问就默认为你什么都知道，对需求或者对产品的错误理解就需要你自己负责任了。

只能根据现有市场产品想像，揣摩公司老总的心理，看他们想卖出一什么东东。
-->这是一个测试人员必须具有的素质或者能力。要能站在决策者，实现者等不同角色的角度上为最终使用产品的用户去考虑。

保证产品质量？，地球人都知道没有产品能做到没有bug，做到什么程度能被接受呢，别一出问题就往测试人头上摔。
-->基于这一点，所以就要事先制定一个过程和标准，测试和开发双方都接受的过程和标准。不然，这活就没法干。

基于什么做测试
别告诉我要根据需求文档，否则我当你没认真做过测试。
-->当然要基于需求了！而且需求大于一切！你可以站在最终用户的角度上提出一些建议，但只要建议没被采纳，需求没被修改，你都要严格按照需求上的规定来。每个人有每个人该负的责任，需求有问题，定义需求的那个人会负责任。没有按照需求来测试，那你就要负责任了！

我先抛砖，我主张根据市场定位做测试。把产品交给测试人员时第一步要把产品定位描述清，用于哪个行业、什么人用、怎么用；然后才是功能定义、界面定义（不过好像没公司这么干）。
-->你说的这些不都是需求中要明确的东西么？“把产品定位描述清，用于哪个行业、什么人用、怎么用...”这都是需求中要说明白的东西，可能形式多种多样，口述，形成文档，给你的类似产品作为参照等等，但一般正式的形式还是要形成文档保存下来。不然，100个测试人员对某产品有100种理解，到底谁认为有bug，谁认为不是问题？听谁的好呢？

作者: freedom_me 时间: 2010-2-20 11:34
抬头就见领导了~鸥

作者: archonwang 时间: 2010-2-20 14:06
标题: 回复 1# 的帖子
想法不错，可惜可实施性不强，我个人的观点难免偏颇，见谅。
1. 做测试为什么？
简单点，一份工作，养家糊口，喜欢的话可以深入研究。测试是一项后备工作，如果所开发的产品不是性命攸关，或是与经济金钱直接挂钩的，测试的重视程度可能就么有想象的那么多。目前，很多公司对测试的态度始终是可有可无，可能就是基于此考虑的。至于理论方面，做测试为什么，我想没有必要多讨论，仅提一点：测试投入费用/测试产出价值最好要远远小于1，接近0，那么，才有可能对测试重视起来。当然，里面还有很多的潜在费用和价值。

2. 基于什么？
尤其不能依靠自己的想象，无论如何，测试是一项可实施，可对照的具体工作，按照市场，这句话好大，如果感觉不爽，不如直接面对市场，只不过你考虑的是产品层面还是后端支撑方面。如果是产品层面的测试，首先要有的就是行业经验，没有行业经验，没有资格谈论面向市场的产品层面测试。所以强调的是：不能依靠想象来做，必须有可参照的内容，否则天马行空，咋整都对。

作者: cathrinlinqi 时间: 2010-2-21 10:29
1.做测试为什么?
简单来说，就是为了证明代码的正确，证明代码所实现的功能符合需求。测软件的健壮性，流程的正确性。

2.基于什么？
基于需求，严格按照需求上的思想来测。当然还可以进一步，从客户角度考虑，对需求上的有些不是很好的地方可以提出自己的看法，可能会被客户接受并修改需求，当然是比较好的，这时就可以根据修改后的需求来测。也有可能不被客户接受也没有修改需求，这时你就得保留自己的想法，还是要根据原先的需求来测试。总而言之，言而总之，对测试者而言，需求最大，绝不能根据自己的想法来测试，否则会出大问题的。

作者: 猫猫的拖鞋 时间: 2010-2-21 14:54
行业经验这东西，不是说有就有的，某些行业了解起来简单，某些行业，不参与到行业中，很难通过文档和g.cn或百度得到理想结果的。
只能说，要用心去研究行业知识，然后基于需求的基础上提出改进意见。
尤其不能依靠自己的想象！很赞这句话，思维五花八门，项目功能如何实现，页面如何定义，这些都是需求时比你有经验的前辈考虑的。否则，不依靠需求，怎样去定义功能的完成情况以及如何展开有效的测试呢？

纯属个人观点。

作者: fbs19871014 时间: 2010-2-22 09:56
为了发现错误而执行程序

作者: 菊子402 时间: 2010-2-22 11:16
标题: 备受鼓舞

哇，我以为只会有一两个人回复我呢，真的很高兴看到这么多人的留言。粗看一遍，感觉大家都是很有想法的人，和你们一起讨论肯定很有收获，我要再仔细看看然后引用你们的回复哦！

还有，我灰常灰常想问大家的是，你对现在的测试模式满意吗（前提是你真的很喜欢并热爱它，想着转行的就先别搅和啊，呵呵），当你兢兢业业地完成了所有测试文档列明的要求后，它出现了一个不在文档、影响很“恶劣”的bug（严重且丢人

），你会理直气壮地说是编文档的人的失误吗？更常见的情况是，我们做测试的人都认为它或它的一部分是次的设计，跟不上时代，换我们是用户肯定不买，这种情况下，我们肯定还是严格按照文档要求认真完成测试工作，但我们的内心怎样呢，想突破想提高吗，怎么做呢？

作者: 小贝流浪记 时间: 2010-2-22 14:57
路过学习

作者: 菊子402 时间: 2010-2-22 17:32

原帖由 sunfly_3333 于 2010-2-12 10:22 发表
做过技术支持，深刻的体会到产品质量对用户使用及市场拓展的重要性，做测试的目的有三：一，尽可能的发现有不同影响程度的bug，这样生活会变得丰富和有挑战；二，不会像开发那样，人未老，头先白；三，本人摩羯座，测 ...

我也做过支持，用户抱怨说产品不好用，干测试这几年就一直在研究，得出两个个人结论：一是非定制的产品在定义需求时要调众口，所以会采用大概定义的方法，只定义要实现怎样的功能，具体到怎么实现就完全由开发掌握，而测试时tester测到功能实现了，实现的方法没有定义，用得有些别扭也不会理直气壮地报bug，或者是自己已经被“洗脑“了根本没发现有问题；这是一个没有相应文档规范的测试点该如何把握的问题。二是再详细的设计也有疏漏，落了用户用起来很方便的功能，这其实也是bug（deffect）。
你说测试需要对业务和系统架构的了解，我很赞同，同时还想补充一点，这些理解和经验在测试中增长的速度真的会很慢，尤其对于所测产品周期不长且不属同一种类的测试员（我这一类型的）来说更是费心费力却回报不大。一直都在想怎样才能在最短的时间内熟悉它的业务和使用者的习惯，完成有文档规范出的功能点测试，还不漏掉文档没涉及到的又肯定是成熟产品所必需的功能点。
虽有些想法，但还不成熟，不知你有没有我这样的感受，你是怎么想的呢，其他人有好主意欢迎跟帖啊！

作者: 菊子402 时间: 2010-2-22 18:04

原帖由 bobo45123 于 2010-2-16 21:39 发表

基于什么做测试？
当然是基于用例文档来做测试了，至于楼主所说，‘别告诉我要根 ...

呵呵，我之所以那么说就是想让大家详细说一下，看来目的达到了。你说的没错，我现在的项目根本没有文档，因为这个产品采用Agile模式开发，给测试的功能需求文档被cut掉了，这就要求我们最大可能地去理解设计员的思路，揣测用户的喜好，结合开发的实现（我们太伟大了

）。

我也做过只有文档的项目，文档就是一切。当然百密一疏，文档也是人写的，设计员不可能哪个点都写到写详细，因为他的想法还不成熟呢，呵呵，同意我的说法吗，大家肯定都遇到过这种情况。

在我看来，文档是个指导员，他告诉我们最最重要的那些，没说的就要揣摩了。我们不能光测试文档说到的内容，在你们的用例里肯定也有超出文档范围的case，是吧，那验证点的依据是什么呢，你们怎么把握的呢？

作者: 94090555 时间: 2010-2-23 09:27
LZ:用得有些别扭也不会理直气壮地报bug，或者是自己已经被“洗脑“了根本没发现有问题；
---易用性在测试中也是非常重要的,我们回顾一下，80年代末微软的MS_DOS版文字处理软件，该软件提供了很多很强的文字编辑功能，但是要求用户必须学习并记住很多神秘的按键才能完成任务。这样的软件可以说具有很高的功能性（提供给用户很多必要的功能），但易用性很低（用户必须花大量时间和精力去学习、使用它们）。
测试人员被同化的现象:这个无论哪个测试行业都是会出现的,接触多了,错的多了,习惯成自然了,但并是说这样就对了,测试中一定要避免这种现象了生,否则将失去存在的意义.
我也比较赞同楼上sunfly和lonewolf的观点,测试首要的依据就是需要分析和规格说明,这都没有,都不知什么是对和错你怎么测试?其次是业务知识,这个是业务领域所必须的,然后是行业知识,测试本来就是一门很深的技术,如果只站在需要说明和业务的角度难有建树!

作者: 菊子402 时间: 2010-2-23 14:05
标题: 回复 7# 的帖子
说得好！看得出你很有经验，很想和你探讨一下，我所见到的测试基本都是以需求文档为基础，结合行业经验，再加上测试员自己的经验和能力对产品进行验证，验证它能做到要求的功能，不发生明文要求避免的错误，我想我们对测试的理解偏差不大（有疏漏请指出哦）。如果我们去审视现在的模式时会发现，它处于很初级的阶段（什么是高级的我也不知道），为什么这么说呢，你看，我们依据别人给的文档一类明文规定的东西去做测试，所测的东西是已由开发员保证过质量的，测试完成后我们无论如何也不能说100%地排除了所有缺陷，就是说，首先我们依赖别人，其次我们的测试会有疏漏，那么如果你是产品负责人你会怎么看待我们的测试工作呢？在重要性上，设计和开发肯定是最重要的，测试肯定排在后面；在责任分担上，测试又依赖于设计文档的全面，这种依附怎能让测试有大的作为呢。所以大家都说测试难做、受夹板气、不被老板重视，我觉得这太正常不过了。只有国内的测试处于这种情况吗，为什么测试在国外大行其道，测试员对开发员大呼小叫，而国内的测试人低声下气？在我们的这种模式里存不存在问题，我们缺少什么呢，怎样才能提升测试的价值，改变现在的状态呢？大家对这种现象有什么感受，有没有办法改变呢？

作者: 菊子402 时间: 2010-2-23 14:18
标题: 回复 9# 的帖子
archonwang: 目前，很多公司对测试的态度始终是可有可无，可能就是基于此考虑的。

就是这点很刺激我

，我们也是有理想有能力的好青年嘛，就是喜好不同选择测试，可入行这么多年来工作没少做，却没得到多少成就感，自己也觉得测试的重要性不高，看着高高在上的开发，心里真不是滋味，我们怎么做才能改变这种现状呢？

作者: 94090555 时间: 2010-2-23 18:54
怎样做才能改变现状呢,这确实是我们测试人员应该讨论的一个话题,顶!

作者: parater 时间: 2010-2-23 19:01
说的太多，没有全看完，

不过大部分都很有道理，我觉得

每个人都从自身的处境出发，

行业不一样测试重点肯定不一样，

像UCD测试本身就没一个标准答案，

公说公有理！
我们现在做的功能性也很强，用户使用性

一般，对技术人员的要求超级高，是记性和
耐性的大考验！

作者: kinney 时间: 2010-2-23 22:22
挑别人的bug很好玩，很有成就感，于是就做测试了

开个玩笑

做测试比较符合我的性格吧，而且可以接触很多东西，也可以客串下技术支持什么的
测试得基于需求文档，写测试用例之前必须研究透需求，知道功能是什么，要什么，有可能是怎么实现的。
编写测试用例的时候就不能局限于需求了，一般需求文档都只是最基本的功能要求，如果测试用例局限于需求的话，那这个测试算完了。
测试还有一个重要的是要站在用户的角度去想问题，东西做出来了，功能是实现了，但用起来非常不方便，那也是属于不合理的地方。当然，易用性方面的争议也很大，作为测试人员很多时候只能提出建议，改不改你都做不了主

测试小鸟一点点心得吧，大家见笑

作者: dumb_dora 时间: 2010-2-24 09:15
这两天也和同事讨论到这个问题，他们问，你们做测试是为了什么？

* 做测试是为了什么
测试肯定是为了符合设计需求，保证产品质量，另外还要增加一点，站在用户的角度对软件进行完善。各个公司的开发模式可能不大一样，但为了公司能够健康的发展，为用户着想绝对是正确的。如果始终抱着这个心态，什么需求不能参与，什么软件能做到什么程度都迎刃而解了，世上无难事，就怕有心人呀。

* 基于什么做测试
测试确实是根据需求文档的，文档中不合理的地方可以提出来，但是没有被确认之前，你还就必须要根据文档。你大可以根据你的业务经验，工作经验对测试文档挑刺，前提是你对产品很熟，业务精通。

有点语无伦次，重在参与了

作者: superliming 时间: 2010-2-24 09:23
改变现状，首先要提高测试人员本身的技术含量，不要只会点鼠标。还有就是让本项目部人员知道软件质量的商业价值，当然老板知道更换。呵呵我相信只要有回报，国内的现状慢慢会改变的。我们一起为之改变努力工作

作者: zjzszj 时间: 2010-2-24 10:45
我也赞同测试的依据是需求文档。
从责任的角度看：
如果需求文档中有不正确的地方或者不符合实际情况和操作习惯，则可以在看需求文档时就向设计人员反映。如果设计人员仍然不予以修改，则后期出现任何这方面的问题，就不是测试的责任。
从工作的依据来看：
去考虑用户的真正需要，这对测试来说要求比较高，虽然我们有为用户考虑的必要，但是在很多时候我们没有这种能力。我们的工作重点在测试，当工作很繁忙的情况下，没有过多的时间让我们去了解。既然分工不同，自然是有道理的。

作者: 94090555 时间: 2010-2-24 11:22
superliming说的极是，提高测试人员的技术含量是一个不二法则，只有你牛了，才会有量。顶！

作者: redmine 时间: 2010-2-24 11:22

作者: zmy 时间: 2010-6-17 17:54
议论的好热闹哦！路过，不过也学习了！

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