/**测试的流程中，
测试计划是对整个测试活动的安排，而
测试用例则是测试执行的指导**/
用例的来源：尽可能一切和项目有关的文档，分析分解功能点(理解功能点)；
组织方式：把握方便管理和跟踪的原则；
文件管理：Word或Excel或专门的测试用例管理工具。
跟踪(与其他材料的关联方式)
问题：需求的变更、设计的修改、需求的错误和遗漏等；
用例主要来源是需求和设计的说明，跟踪用例其实就是对需求和设计的跟踪；
可以将分解的功能点编号，与相应的用例联系起来(可以用表格)，这样需求和设计发生变化时，只需要跟踪“功能点”是否变化，是否增加了新的功能点；
重要和困难的是，手头的资料和信息不一定是最新的。
最初级最常规的做法：按需求或概要设计，得到软件功能划分图，然后据此按每个功能，采用等价类划分、临界值、因果图等方法来设计用例；貌似把所有的功能点都测试到了，但测试覆盖率却是不够的，测出的程序通常也是很脆弱的；
而有经验的测试人员则在写用例或测试时总会有更多的测试考虑点，比如在需求和设计里并不会点明的内部处理、转换，业务逻辑，相互影响的关系等，从而发现更多的问题；这就要靠我们对项目本身的了解和测试的经验，发现隐藏的测试点，从而保证测试覆盖率。
测试用例的划分
最经典的方法就是瀑布模型，从上到下，逐渐细分；但我们还需从更多的角度切入系统进行测试；
功能点切面：也是常见的；
特定切面：忽略表面上的功能，关注测试对象的某一个面；共通的操作；
如果把功能点切面说成是一种纵向划分法，那特定切面就是一种横向角度分析；
隐含切面：往往不是明显的某个功能项，可能是功能项后台的隐含处理，也可能是多个功能项之间的关联处理，甚至是某种特定情形下的处理；需要相应的
学习了解进行挖掘；
当然，还需要考虑系统实际业务情况和用户的实际应用角度；
其他相关系统：包括公司自有的系统模块、组件、函数，购买或免费得到的一些功能组件；对这些内容需要预先与开发组长等讨论清楚，是否需要测试；若时间紧张或其他原决定不测的，应在测试计划中说明；需要测试的，则具体可根据实际情况来设计；
除功能测试外的其他测试类型：包括可靠性、安全性、恢复性、配置按照测试等，这些测试类型都是一个单独的测试项。
———————————————分割线—————————————
作为一个测试计划来讲，核心的三个要素是时间，资源，范围。（这句话摘自
微软的
软件测试培训材料），时间就是什么时候做以及要花多久做，资源就是你要调用的人力、机器等资源，范围是你要测试的东西以及测试重点。
除以上提到的3项之外，还有比较重要的项目有策略（具体就是怎么测）、风险控制（一旦有问题采取什么应急措施）等项目。
要把一个计划做得很有实用性，按照笔者的经验，要注意以下几个方面：
a. 上面提到的三要素不能少
b. 测试策略一定要交待清楚，就是大概怎么测试
c. 需要其他人员（部门）协调的，要交待清楚
d. 在估计测试所需的时间、人力及其它资源时，尽量做到客观、准确、留有余地，特别是估计开发时间和debug时间，以及要对自己的执行用例速度，回归速度心里有数
e. 测试计划中每个阶段要明确表明，并且测试阶段的输入、输出文档要清楚
f. 测试计划中的时间段不宜太长（最好以day为单位），太长就比较模糊，不好度量，不好check
g. 一定要有风险控制，要不然计划缺乏可执行性
h. 计划写完之后不是装在兜里，要组织PM和Dev进行评审
i. 要不断更新计划，记住：每个计划都是动态的，不是一成不变的
(测试用例的实用性 和 回归测试用例的选择)
做用例之前，
1 要透彻了解程序(需求和架构)
2 做一个正式的测试设计，然后再写用例(设计方法就那么几种，再根据实际情况)
一般来说，设计一个比较实用的测试用例，注意如下几个方面：
a. 选用好的用例管理工具（这个很重要，千万不要用word，excel）—(这个是针对多人测试、用例及时更新来讲的吧)
b. 用例一定要及时更新（补充新的想法，删除过时的需求）
c. 做好用例分级
d. 做好用例评审，写用例之前可以征询相关人员的意见
e. 可以考虑结对编写，这个是不错的主意—(结对编写?)
f. 要全面，包括功能、性能、兼容性、安全性、易用性、容错性等等
g. 注意把握适当的颗粒度
—————————————分割线—————————————————
1 需求分析
a. 列出测试需求(根据需求规格说明书、帮助文档、软件的demo版，利用测试大纲法，以每个窗体为对象，每个窗体里面的控件为单位列出测试功能点)；
b. 需求等级划分，依据需求内容的重要程度划分为：高、中、低等；
c. 划分需求类型，(功能性、易用性、兼容性等)；
d. 评审需求(软件不熟悉的情况下采取以集体的形式整体讨论的方法评审需求或设立专人负责评审)
e. 需求列入TestDirector(评审后的结果在TestDirector要有体现)。
a. 根据功能点确定人员分工，具体的功能点分配给具体的组员;
b. 测试用例的编写，借助功能演示demo、前一阶段所编写的测试功能点等编写测试用例;
c. 要求组员对自己负责的功能点选择具体的设计测试用例的方法;
一般选择方法顺序：在考虑好被测试软件本身的特性后，一般首先边界值挑选最具有代表性的数据;然后使用等价类进一步补充;如果要考虑各功能的输入输出关系可以使用因果图、判定表法;但如果输入太多，可以使用正交排列法选择减少测试用例，并且是测试数据均匀分布。这些理性方法都使用完后，在测试执行阶段，可以使用随机测试法或者错误猜测方法进一步丰富你的测试用例。
d. 针对所设计的用例对软件的功能点(以及其他类型的需求)进行需求覆盖;
e. 用例评审，优化用例的数量确保用例的质量(设定专人评审)
f. 挑选冒烟测试用例(抽取用例总数的10%~20%左右进行冒烟测试来反映基本功能)
3 测试执行
测试执行工作应尽量做到详细，依据测试计划里面的测试的整体安排，但是因为根据实际工作进度要做适当调整。一般情况是当天晚上前安排好明天的具体工作，具体任务可以以测试用例的数量来衡量。测试组长的几个重要工作步骤：
a. 确认人力以及硬件资源是否到位，测试开启时间是否和测试整体计划相一致;
b. 按照测试计划着手准备具体的测试工作;
c. 在TD中，
Test Lab里面设置以天为单位安排组员当天的应完成的用例，以及利用TD分析功能总结当天执行用例的情况;
d. 指导组员工作，解决组员工作遇到的疑难问题;
e. 做好审查工作，监督组员工作;
f. 做好全组当天执行情况的总结(用例执行通过情况、发现bug数量、以及在各个模块中的分布情况等);
g. 将当天任务的执行情况书面化呈报上级领导(阶段任务完成后书写整个阶段的测试总结报告衡量当前版本软件的质量以及相关的发布问题);
4 下一版本的工作安排
根据软件更新功能的多少分为两种情况：
a. 一种是软件更新功能较少(新增加功能点是前一版本总功能的5%以内), 执行回归测试，根据新的功能点增加相关的需求和测试用例，确定新的功能点安排相关人员执行新加的测试用例;
b. 另外一种情况是软件的新增更能点较多，则按照新的
系统测试执行，首先进行冒烟测试，通过后进行详细的系统测试，测试过程中重点测试上一版本出现的缺陷(返测)、新增功能以及修改缺陷新增功能所影响到的模块。
新本版出现，总体按照测试执行阶段的测试工作流程进行测试同时注意特殊问题特殊处理。
5 提交缺陷(bug)
提交的缺陷需要测试部门专门人审查，通过审查后的缺陷，提交的TD中;主要审查下面几个方面：
a. 发现的问题是否是缺陷
b. 是否是重复的缺陷
c. 缺陷程度的优先级是否合理
d. 缺陷修复情况
/**来自网络的整理 http://bbs.51testing.com/thread-361724-1-3.html**/
