曹老师 11:05:05
测试需求分析和提取是在在业务需求形成的后期、设计测试用例的前期进行的工作。
雪大嫂11:06:50
很多公司这步也是省略的，和用例放在一起分析了。
pent11:09:41
我们也有一个测试设计的过程，比如针对一个功能需求，包括测试范围、测试策略，逐步细化得出一套测试思路，最后得出测试用例列表。好像和上面说的测试需求差不多？要求要在测试设计文档上体现你的设计思路，而不仅仅是最后的一堆用例；范围、重点是什么，要从哪些角度进行测试，测试的策略，然后应用什么用例设计方法，最后形成一个用例列表；对用例的评审基本上也是针对测试设计而言，没有具体去评审用例了。
雪大嫂11:16:34
OH，其实是个用例的框架，但没有步骤。如用等价类法，就说明分成几个等价类，有哪几个，就可以了，是这样吗？
pent11:19:22
1.1. 测试范围
根据测试准备阶段的相关信息（如开发类型、开发策略、时间要求等），确定测试范围。
可以结合本规范第一章列出的测试类型，选择必要的测试类型。对测试范围的分类有助于确认测试重点。
1.2. 测试策略
针对功能实现原理和测试范围、测试类型，有针对性的制定测试重点和测试策略、迭代策略。
1.3. 测试设计
根据测试计划阶段的测试范围、测试重点、测试策略，进行测试用例的设计（包括测试的关注点）
1.4. 测试列表
该列表可以按实际需要变化，用例名称一般就是该用例的测试目的，测试要点是该用例覆盖到的测试要点，是基于2.3 测试设计而来，用例ID是对应另一份测试用例文档的用例ID。
雪大嫂11:33:06
序号 测试需求描述 对应测试用例编号
1. 成功登陆 TC_MRRM_WEB_001_01
2. 密码错误导致登陆失败 TC_MRRM_WEB_001_02
3. 用户名错误导致登陆失败 TC_MRRM_WEB_001_03
4. 连续失败登陆超过三次 TC_MRRM_WEB_001_04
得到以上真理和讨论精华，心里逐渐明白三分，放于此，以便以后学习之用。
