需求表达是否规范。
以上是需求分析人员的工作，用户，开发人员与测试人员只是协助。
需求阶段就开始让测试人员进行测试，这恐怕有些概念上的错误。
需求结束后可以开始写测试用例，但测试是必须有代码出来后才可以。 大家总结的东西已经很多了，大部分和我想的差不多，我觉得大家都说的很有道理，有些地方我也深有体会，再此我也根据自己的实际工作中遇到的一些问题和大家讨论一下，希望各位大侠给予指点啊！呵呵！
是我刚从事（电子商务）测试工作的第一家公司，到公司后，才知道自己是公司唯一的一位测试人员，而且那个时候刚毕业，经验上几乎是一片空白，领导分配是任务，我一看就傻眼了，怎么办，而且公司没有什么需求文档，当时我真的是无从下手，就直接找开发人员，让他们给我讲业务流程，过了段时间，网站的各个业务流程差不多都了解了，而流程中涉及到功能就比较容易下手了。其他测试经验，大部分都是在网上学习，在工作中借此应用，这样就慢慢的上轨了。我觉得多问，多看，多学习，多积累是必不可少的，搞清楚需求，接下进行测试就比较容易下手了。 1. 如果你在项目中期加入，可以要早期加入项目的测试人员对整个系统的业务流程做个介绍，然后自己尝试去用系统以最快的速度熟悉系统的业务。
（下面两点适合任何时候加入项目的人）
2. 仔细研究业务分析和设计文档，并且多跟业务分析人员、开发人员沟通，尽可能的掌握需求；在按照自己的理解基础上设计测试用例，然后邀请PM、业务分析人员、开发人员一起评审，看是否对业务需求的理解存在出入；在发现bug的情况下，同样要跟业务和开发沟通，确定需求的理解没有偏差、也没有需求的变动。
3. （如果有可能的话）尽量多跟客户直接沟通，以了解客户使用系统的方式，多以客户的身份去测试系统是最为理想的。 这个问题，是需求管理阶段要解决的问题。
对于我们来说，需求有很多来源，来自市场，来自客户，来自公司的研发或测试，有时候领导一句话就是一个需求。
所以建立一个需求采集的渠道就非常有必要。但这些需求，很多都是原始需求或者是一种需要，要生成测试需求后才能进行测试。
所以我觉得应该有这样一个流程：
需求采集----需求整理----需求评审----生成测试需求----后续测试行为
需求采集就是通过建立的几个渠道，尽可能的收集需求，哪怕是领导或者客户有关的一句话，都要记录确认。
需求整理，是把收集上来的杂乱需求点，有条理的归类。
需求评审，确认需求的有效性和可行性。
生成测试需求，从测试角度去解读需求，把需求分离出一个个的测试点，以便展开后续的测试工作。
我觉得这样的流程是准确的，它是建立在信息流通的基础之上的。如果是单纯的靠自己理解，或者研发人员的讲解，这是不可信的。 1、反复阅读业务需求说明书，逐步了解；
2、对产生疑问的地方及时做好沟通，要弄的明明白白；
3、在开始测试时会深入理解业务的，同时也会产生更多的疑问，再次进行沟通。（只有实践了才能更深入理解）
我以前就是这么做的，效果还可以哦。 多提问，认真分析
不懂啊
:o还是很抽象受用
受用 好多讨论需求的话题。谁都知道需求重要，可领导就不愿意花时间搞需求。我们讨论的东西，也许只能作为一个衡量标准，告诉我们100分是怎样的。而实际工作中，只能向着100分积极靠拢，永远到不了，可能也就在50到60分之间挣扎吧。
页:
1
[2]
