[开发测试] 测试计划和测试用例

明确测试的目标，增强测试计划的实用性；
坚持“5W”规则，明确内容与过程：
a：what（做什么）：测什么；
b：why（为什么）：为什么作为测试目标；
c：when（何时做）：测试的前提条件、测试进度安排；
d：where（在哪里）：测试环境；
e：who（什么人）：由谁来做；
f：how（如何做）：用什么方法做。
采用评审和更新机制，保证测试计划满足实践需求：测试计划创建完毕后必须提交给由项目经理、开发经理、测试经理、市场经理等组成的评审委员会审阅；
测试计划中不要包含详细的测试技术指标、测试步骤和测试用例：测试计划和测试详细规格、测试用例之间是战略和战术的关系。

确定测试资源：?

测试资源的分类：

测试资源的规划：
a：初期，测试组长首先介入，参与需求评审、?确定测试需求和测试范围、制定测试策略和测试计划等；
b：测试前期，需要资深的测试设计人员、测试脚本或测试工具开发人员参与或负责软件测试需求的制定和分解、设计测试用例、开发测试脚本等工作；
c：测试中期，主要是测试的执行，测试需求的数量取决于测试自动化实现的程序。测试自动化程度高，人力的投入则不需要明显的增加，测试自动化程度低，对执行测试的人员要求就比较多；
d：测试后期，资深的测试人员可以抽出部分时间去做新项目的准备工作。

?确定工作量：

团队工作效率越低，测试工作量越大；
测试的质量要求越高，测试的工作量越大；
不同的开发阶段的测试工作量的差异也较大。新产品第一个版本的测试工作量要大一些，若后续版本功能增加加多，则后续版本测试量变大；
编程质量越低，测试的工作量越大；
程序复杂度越高，测试的工作量越大；
之前测试的缺陷多且分布广，测试工作量大；
风险越多，等级越高，测试工作量越大。

?任务细分：工作分解结构表方法

列出本项目需要完成的各项任务；
对每个任务进一步细分，可进行多层次细分，直到不能细分为止；
根据任务的层次给任务进行编号。

?测试工作量估算：

W=Wo+Wo*R1+Wo*R2+Wo*R3，W为总工作量，Wo为一轮测试的工作量。

常见里程碑：

测试计划签发、测试用例签发、自动测试脚本完成、功能测试完成、性能测试完成等。进度安排是确定里程碑的起止点。

风险识别：

? ? ? ? 建立风险项目检查表，将测试范围、测试过程中的风险识别出来，按风险内容进行逐项检查、逐个确认，确定哪些是可避免的风险，哪些是不可避免的，对可避免的风险要尽量采取搓丝去避免。

类别：人员风险、环境风险、测试范围(广度)、测试深度、回归测试、需求变更、用户期望、测试技术、测试工具。

风险评估：

? ? ? ? 从成本、进度及性能三个方面对风险进行评估，通过评估可以确定这些风险的特点或可能带来的危害，根据风险发生的概率和带来的影响确定风险的优先级。

风险控制：

制定风险管理计划和风险应急处理方案，来降低风险和消除风险；
对风险的处理还要制定一些应急的、有效的处理方案；
做计划时，估算资源、时间、预算等要留有余地，不要用到100%；
制定文档标准并建立一种机制，保证文档及时产生。对所有工作多进行相互审查，及时发现问题。

?冒烟测试：

????????也叫软件包验证测试（BVT），在很短的时间内，先测重要功能，优点是时间短，缺点是覆盖率很低，冒烟测试通过后，才可以进行更大规模的测试。

测试策略：

描述当前测试项目的目标和所采用的测试方法；
描述在规定的时间内哪些测试内容要完成，软件产品的特性或质量在哪些方面得到确认；
描述测试不同阶段（单元测试、集成测试、系统测试）的测试对象、范围和方法；
描述每个阶段内所要进行的测试类型（功能测试、性能测试、压力测试等）

测试用例：?

? ? ? ? 对一项特定的软件产品进行测试任务的描述，制定输入，预期结果和一组测试项的执行条件的文档，体现测试方案、方法、技术和策略，内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。

测试用例元素（内容）：

? ? ? ? 测试用户里必须给出测试目标、测试对象、测试环境要求、输入数据和操作步骤，概括为5W1H：

测试目标：why——为什么而测？功能、性能、可用性、容错性、兼容性、安全性等；
测试对象：what——测什么？被测试的项目，如对象、函数、类、菜单、按钮、表格、接口、整个系统等；
测试环境：where——在哪里测？测试用例运行时所处的环境，包括系统的配置和设定等要求，也包括操作系统、浏览器、通讯协议等单机或网络环境；
测试前提：when——什么时候开始测？测试用例运行时所处的前提或条件限制；
输入数据：which——哪些数？在操作时，系统所接受的各种可变化的数，如数字、字符、文件等；
操作步骤：how——如何测？执行软件和程序的先后次序步骤等，如打开对话框、点击按钮等。?

测试用例写作说明：

用例编号/序号：简单唯一；
用例说明：
1.也称测试点、检查点、测试概述、用例概述、测试说明；
2.用一句话对测试用例进行概述；
3.可以总结测试目的；
4.可以用疑问句表示；
5.可以用“检查、验证、测试”等字眼（如验证QQ默认安装）；；
6.最好看到这句话就能知道如何测试；
7.尽量唯一（决策表可能会有重复的测试说明）；
8.用例执行多轮时，越往后执行可能越快，如果用例写得好，直接看概述就行。
初始条件：
1.也称预置条件、前提条件；
2.初始条件要是一个状态，而且是静态的，如管理员已登录后台；
3.初始条件是第一步操作步骤之前的状态，不能太远，不用从头写到尾；
4.很多项目中不写预置条件。
操作步骤：
1.若对数据要求高，需要把数据分离出来；
2.步骤都要有序号；
3.每一步用分号分开，最后用一个句号；
4.每一步必须换行；
5.参数前加冒号（如用户名：admin）；
6.涉及按钮界面用【】、“”等成对符号间隔；
7.功能的详细用例步骤4-6步左右；
8.最后一步一定是个动作，不能写结果。
预期结果：
1.是一个状态；
2.如果参考文档中有描述，原封不动的抄过来；如果文档中没有具体要求，则点要一致，可以有几个点，如QQ默认安装成功，应能启动、默认选项匹配等。
用例状态：
1.通过、失败（用例评审）、阻塞、未执行、搁置（有争议）、无效用例...
2.初始条件达不到时，一般用例状态设置为阻塞。
3.看如何执行用例，执行完关心什么来定。
优先级：用例的执行顺序（由评审确定）。

测试用例的评审和管理：?

保证测试用例质量的方法：
1.首先，要对用户需求、服务质量要求、产品特性有深刻且全面的理解；
2.其次，采取正确、恰当的方法进行用例设计；
3.再者，按照测试用例的标准格式或规范的模板来书写测试用例；
4.最后，对测试用例的检查、评审，也是提高测试用例质量的主要且有效的手段。
测试用例评审要点：根据检查单或检查表进行评审；
测试用例的优先级：优先级的分类（先做和后做不代表重不重要）：

冒烟测试小版本确认测试（BVT），也叫冒烟测试、构建版本测试，是一组你想先运行的以确定这个给出的小版本是否可以测试的测试用例。只测试最基本功能，不测次要功能、错误、边界、性能、界面等。
高测试软件基本功能、重要错误、重要边界的用例的集合。
中测试次要功能、各种边界、错误以及配置测试（环境）的用例。
低最少或最后被执行的测试用例。这并不意味着这些测试都不重要，只是说他们在项目的生命期间不是常常被运行，例如GUI（界面）、错误信息、可用性、压力和性能测试等。

如何设置测试用例的优先级：
1.考虑成本、时间、人员等因素；
2.考虑用例的关联性；
3.考虑用例的干扰性；
4.决定执行用例的先后顺序。
注意事项：
1.兼顾测试充分性与效率；
2.考虑测试执行的可再现性。

?测试用例评审要点：

根据检查单或检查表进行评审：
a：用例“文字校对”：错别字、病句、语句不通顺、含义不清晰、语句有歧义、格式不一致、标点不一致、中英文混合等；
b：用例质量：遗漏用例、冗余用例、不清晰用例、错误用例、不可测用例等；
确定用例的优先级；
规划服务器和客户机；
用例的分工执行与人员安排；
记录评审过程，记录测试环境规划。

?用例设计与编写方法总结：

通过测试：主要用户验证系统和它陈述的需求一致，确认软件至少能做什么，一般通过分析需求说明书来设计测试用例；
失败测试：纯粹为了破坏软件而设计和执行的测试案例，也称迫使出错测试。主要用于证明“一个系统不会做不需要它做的事情”；
随机测试：也称即兴测试，是指临时准备的、即兴的bug搜索测试过程。
缺点：无法度量随机测试的实际覆盖率；
? ? ? ? ? 许多测试都是冗余的；
? ? ? ? ? 测试数据因为是随机的，重复测试是不可能的。?