需求阶段测试人员需要做些什么工作？
我目前想到的是测试人员需要通过跟开发、客户进行沟通，测试需求评审会议等来熟悉熟悉需求，便于了解业务，请各位指点 你说的是需求调研阶段吧？ 主要还是熟悉业务需求为主。 了解需求，提出可测试性需求 这个要看测试人员是直接从开发那获取需求（可能没有与用户接触的机会）还是从用户那获取需求了-大多数公司测试人员一般都不是直接接触用户的吧 需求阶段，测试人员根据客户提供的文档，阅读理解分析需求。和开发，lead沟通确认理解的正确性。待将所有的需求通过流程图画出来后，划分story，测试人员一起brain storming，想出尽可能多的测试用例。 回复 3# 愚人
提出可测试需求，会有文档产出吗？ 本帖最后由 51testing-wn 于 2013-3-16 18:33 编辑
1. 获取需求：获取测试对象是我们最初的工作，正儿八经的 ：-）
了解你团队的成员，从他们那里取得各种需求。他们可以是项目经理，项目开发的同事，高级工程师等。总之你得了解你所在部门特别是所在项目的成员，懂得如何这些人员进行沟通（如果沟通又是另外一个“沉重”的话题了 请参考其他论坛文章）。
获取的需求可是文档化的文档，比如需求文档，用例文档（user story,use case），implement proposal开发实现方案文档；也可以是team agreement团队协作 的文档，比如项目（feature）分析和实现建议的文档，邮件，在线会议讨论，甚至口头约定等。
2. 学习需求：整理获取的文档，了解项目的业务背景，技术知识，测试知识，测试工具等。
举例说明，某个产品要实现“文件系统完整性检查”的需求，需要集成第三方的软件Tripwire。你得理解实现这个需求的目的，从而逐渐了解这个项目的业务背景。从需求"文档完整性检查"的描述来看，我们可以了解到这是属于安全性领域的范畴。
3. 分析需求：在了解整体流程的基础上，分析每个功能的业务处理过程：
a)明确需求的范围
b)明确每个功能的业务处理过程
c)不同的功能点在业务流程上的组合
d)挖掘显示需求背后的隐式需求
comment on 20130313 待完善 了解需求，发现需求不合理的地方或就目前的需求来看测试过程可能出现的风险，进行需求评审 需求阶段，测试人员需要研究需求，
1.通过需求了解项目的业务逻辑；
2.确定项目的搭档；
3.确定需求的可测试行和不可测试行，挖掘隐藏需求，提出存在的风险；
4.更加需求写测试计划，编写测试用例（这一点要结合公司的性质，有的公司需要，有的公司不需要） 本帖最后由 mjy1989 于 2013-3-13 17:22 编辑
主要测试的需求
页:
[1]
