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

parater

说的太多，没有全看完，

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

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

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

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

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

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

kinney

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

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

dumb_dora

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

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

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

superliming

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

zjzszj

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

94090555

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

redmine

zmy

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