男孩女孩看过来：测试是为了什么，基于什么做测试

菊子402

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

• 做测试是为了什么

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

• 基于什么做测试

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

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

zmy

议论的好热闹哦！路过，不过也学习了！

redmine

94090555

superliming说的极是，提高测试人员的技术含量是一个不二法则，只有你牛了，才会有量。顶！

zjzszj

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

superliming

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

dumb_dora

这两天也和同事讨论到这个问题，他们问，你们做测试是为了什么？

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

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

kinney

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

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

parater

说的太多，没有全看完，

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

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

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

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

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

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

94090555

怎样做才能改变现状呢,这确实是我们测试人员应该讨论的一个话题,顶!

菊子402

archonwang: 目前，很多公司对测试的态度始终是可有可无，可能就是基于此考虑的。

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

菊子402

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

94090555

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

菊子402

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

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

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

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

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

菊子402

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

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

小贝流浪记

路过  学习

菊子402

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

还有，我灰常灰常想问大家的是，你对现在的测试模式满意吗（前提是你真的很喜欢并热爱它，想着转行的就先别搅和啊，呵呵），当你兢兢业业地完成了所有测试文档列明的要求后，它出现了一个不在文档、影响很“恶劣”的bug（严重且丢人 ）， 你会理直气壮地说是编文档的人的失误吗？更常见的情况是，我们做测试的人都认为它或它的一部分是次的设计，跟不上时代，换我们是用户肯定不买，这种情况下，我们肯定还是严格按照文档要求认真完成测试工作，但我们的内心怎样呢，想突破想提高吗，怎么做呢？

fbs19871014

为了发现错误而执行程序

猫猫的拖鞋

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

纯属个人观点。

cathrinlinqi

1.做测试为什么?
简单来说，就是为了证明代码的正确，证明代码所实现的功能符合需求。测软件的健壮性，流程的正确性。

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