现在急需要一个好的方案
是否要根据对产品的了解，以及和研发人员的沟通写需求，然后分析再写用例？？
现在只是通过文字表格的方式把产品的功能点写出来了。如何才能让该产品测试比较规范的执行。
比如：分析功能点的方法，写用例，用例覆盖，执行等。都么有一个好的流程规范。
有好的建议大家提一提。 需求一般分为显式需求和隐式需求两种
一、显式需求提取参照需求说明书：
1、逐个罗列出功能点，功能描述
2、考虑交叉功能点
3、画出业务流程图
二、对于隐式需求
1、针对行业知识，向客户（提需求的人）和项目组内熟悉产品的人请教。切记，“闻道有先后，术业有专攻”，在这方面很多人需要习惯并且擅长向他人学习，你就要问的他都烦。
2、针对用户实际需求，要问清楚他想解决的问题和以后的期望值，做到“未雨绸缪”，想客户之所想。期望值虽然暂时达不到，但一定会为你了解产品有非常大的帮助。
3、软件实际需求，在了解用户需求的基础上，向技术人员请教，了解当前产品所能达到的目标。
综上，把所有需求功能点罗列在一张表格里，找对应人员确认，查缺补漏。
“三人行，必有我师焉”，多动手，多跑跑，多聊聊，切勿“闭门造车” 看过上面的一些评论了，我再帮助大家补充一些，思路再展开看看
1、测试需求和可测试需求的区别。
可测试需求是产品需求的一部分，与之平行的包括可制造需求、可维护需求等，是为了配合产品整个生命周期而加入到产品需求的部分，是作为产品设计开发的要求列出设计开发计划的内容。
产品需求的内容有很多，很多人都知道$APPEARLS的原则进行需求分析，楼上说的显式需求和隐式需求也是产品需求的一个分类方法。
测试需求不是产品需求，测试需求是对应产品需求、产品规格、产品设计产生的对测试项目起指导作用项目文档。是为了制定测试计划而必须的。
2、测试需求与产品需求的关系
测试需求提取在流程上来说，3楼已经说过了。
从技术手段上来说，测试需求是从产品需求、产品规格中进行提取的。在产品设计中进行补充的，在产品计划中进行调整的。如果这4个前提准备得非常充分，那么测试需求就没有存在的必要了，直接通过测试计划和用例设计就可以满足质量保证的要求。 所以说，测试需求是为了满足产品质量需求的一个指导书。
测试需求的内容区别于常规的产品需求，强调的是业务应用场景的考虑，是为了让产品用起来的需要。所以我们看到产品需求的功能场景时，在测试需求里要描述其应用场景，什么人、什么能力、什么状态、什么环境、什么常用操作等等。
除了应用场景外，测试需求还要考虑实施交付和维护保证的环节。也就是为测试计划中的测试范围、测试环境、交付要求、可靠性指标等进行的准备。
测试过程依赖于三种角色的角度（开发者、使用者、维护者），也就是这三种角色对产品的质量需求形成了测试需求。 好贴 想要得到比较完整的测试需求，感觉首先需要搞请获取需求的来源
1、需求规格说明书
产品功能、UI控制、UI规范、业务规则、效率标准
2、设计规格说明书
数据库表、数据流程、运行环境、软件部署、性能指标
3、国家政策法规
4、行业标准
5、约定俗成
操作习惯、行业术语
6、企业应用场景 以下内容出自QC的帮助文件，关于测试需求的工作流，可以参考一下：
1、The Requirements Specification Workflow
You begin the application testing process by specifying testing requirements. Requirements describe in detail what needs to be tested in your application, and provide the test team with the foundation on which the entire testing process is based.
By defining requirements, you can plan and manage tests that are more focused on business needs. Requirements are then associated to tests and defects to provide complete traceability and to aid the decision-making process.
This section describes how you use the Requirements module to specify testing requirements. The requirements specification workflow consists of the following:
Define Testing -> Create RequireMents ->Detail Requirements -> Analyze Requirements
2、Defining the Testing Scope
The test team begins the testing process by gathering all available documentation on the application under test, such as marketing and business requirements documents, system requirements specifications, and design documents.
Use these documents to obtain a thorough understanding of the application under test and determine your testing scope—test goals, objectives, and strategies.
Ask the following questions when determining your testing scope:
What is the main purpose and direction of the application?
What are the major features of the application?
What is the relative importance of each element in the application functionality?
What are the critical or high-risk functions of the application?
What are your testing priorities?
Do your customers/end-users agree with your testing priorities?
What are your overall quality goals?
2、Creating the Testing Requirements Outline
Quality Assurance managers use the testing scope to determine the overall testing requirements for the application under test. They define requirement topics and assign them to the QA testers in the test team. Each QA tester uses Quality Center to record the requirement topics for which they are responsible.
Requirement topics are recorded in the Requirements module by creating a requirements tree. The requirements tree is a graphical representation of your requirements specification, displaying the hierarchical relationship between different requirements.
For example, consider a flight reservation application that lets you manage flight scheduling, passenger bookings, and ticket sales. The QA manager may define your major testing requirements as: Application Security, Application Client System, Application Usability, Application Performance, Application Reliability, Profile Management, Booking System, Flights Reservation Service and Reservations Management. For the complete example, refer to the QualityCenter_Demo project.
3、Defining Requirements
For each requirement topic, a QA tester creates a list of detailed testing requirements in the requirements tree. For example, the requirement topic Application Security may be broken down into the following requirements:
Each requirement in the tree is described in detail and can include any relevant attachments. The QA tester assigns the requirement a priority level which is taken into consideration when the test team creates the test plan.
4、Analyzing your Requirements Specification
QA managers review the requirements, ensuring that they meet the testing scope defined earlier. They assign the requirement a Reviewed status once it is approved.
To help review the requirements, you can generate reports and graphs. For more information, see Generating Reports, and Generating Graphs.
You can then use the requirements as a basis for your test plan. The tests you create during the test plan phase should cover these requirements. For more information on requirements and tests coverage, see Linking Tests to Requirements. These tests are also linked to defects, thereby providing complete traceability throughout the testing process. For more information on linking defects, see Linking Defects. 提示版主。下次回帖的时候打字不要太细心，有点错别字，就知道是原创啦。。 没人管了 本人做了一些通俗总结
1.根据用户需求规格说明书，写出自己的理解
2.根据用户需求规格说明书，提取出功能点所需要实现的功能
3.根据提取出的功能，对复杂功能点进行细分
4.根据提取出的功能，进行拓展各功能点是如何工作的
4.1功能点描述中是否有模糊的字眼
4.2功能点描述中是否有，有别于其他常规描述
4.3功能点描述中是否有关联点
4.4发散性思考，考虑各功能点的异常情况
5根据提取出的功能，进行组合，看看各功能点之间的兼容性
5.1认真阅读需求，思考该功能点实现后的流程，把各小功能点进行组合
5.2 思考该模块是否为一个独立的模块，若不是，需要跟其他模块联合起来测试
5.3 思考各功能点之间是通过什么操作进行连接的？连接结果是否正确
以上仅表个人观点 提示版主。下次回帖的时候打字不要太细心，有点错别字，就知道是原创啦。。
wangmengdong 发表于 2010-11-24 18:16 http://bbs.51testing.com/images/common/back.gif
囧。。。是不是原创大家可以去搜索索索。 回复 31# 默默巫
我见云老大的帖子，经常有错别字。。一看就是自己一个字一个字打上去的。。哈哈。。 学习中，非常好 个人理解：一个项目的需求=行业的需求（该行业一些属性，特殊点等）+用户特别的需求（localization)+软件自身的要求（比如：合适的架构，布署与测试的环境要求....). 如何及怎么样提取用户的有效需求呢？ 详细的回答前面很多行友都作了相关的回答，我只写一个概要的了，如何提取？ 我想在提取前要做些相关的准备的，如对该行业的业务流程及相关注意点的了解，对客户对这项目最终期望的了解及相关软件行业技能知识的了解，，，，有了些前提才能从各种途径收集到的需示来有效提取了（如需求会议文档，项目规划文档，开发的相关文档等）
页:
1
[2]
