一、测试计划

测试计划（Testing plan），描述了要进行的测试活动的范围、方法、资源和进度的文档；是对整个信息系统应用软件组装测试和确认测试。 它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可以有效预防计划的风险，保障计划的顺利实施。

测试计划编写6要素？（5W1H）

1. why——为什么要进行这些测试；

2. what—测试哪些方面，不同阶段的工作内容；

3. when—测试不同阶段的起止时间；

4. where—相应文档，缺陷的存放位置，测试环境等；

5. who—项目有关人员组成，安排哪些测试人员进行测试

6. how—如何去做，使用哪些测试工具以及测试方法进行测试。

标准模版

二、测试用例

测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。是描述测试过程具体步骤的文档，包括测试的输入参数、条件、配置、预期输出结果等，并以此来判断被测软件的各模块是否正常工作。

1.测试用例的编写通常包括以下内容：

1）测试用例编号；

目的：好的测试用例编号，可以更好的去了解此项用例所针对的模块，也有助于记忆和新用例的增加。

规则：测试用例编号采用“版本+细类+编号”的形式。

“版本”为设计此测试用例的软件版本。

“细类”为小模块中的汉字头一个字母，以最多5个字母为标准。

“编号”为BUG用例的编号，以4位为标准，依次递增。

例如：引导系统V2.01版本中，候车点设置，用例编号可以书写为：
2.01_HCDSZ_0001

2）测试项目；

3）测试标题；

4）重要级别：优先级（致命、严重、一般、微小、建议）

是对缺陷的严重程度做出的判断。一般分为高（highs）级别，中（mediums）级别,低（lows）级别等。一些管理软件中也分为严重，重要，轻微等级别。只是名称的不同，在实际工作中，我们还要根据项目内容及bug详情来做具体的判断。另外还有一种小版本确认测试，也称为“冒烟测试”，其重要级别要优于高级别，但并不是所有项目必须。

5）预置条件/前提条件；

预置条件是对测试的特殊条件或配置进行说明，即执行本用例必须要满足的条件，如对数据库的访问权限

6）操作步骤；

操作步骤要求简介不冗余，思路清晰，能快速定位，并且步骤中还要包含设备或操作环境等信息；

7）预期结果/期望结果；

8）测试结果/实际结果；

9）复现概率：

复现率则是判断该bug是否为必现或者出现的概率有多大，这在测试过程中也十分重要。

10 ）测试用例的参考信息（便于跟踪和参考）

11 ）开发人员和测试人员

12 ）测试执行日期

测试用例示例

项目/软件	技术出口合同网络申领系统 （企业端）	程序版本	1.0.25
功能模块名	Login	编制人	xxx
用例编号-	TC-TEP_Login_1	编制时间	2002.10.12
相关的用例	无
功能特性	用户身份验证
测试目的	验证是否输入合法的信息，允许合法登陆，阻止非法登陆
预置条件	无	特殊规程说明	如数据库访问权限
参考信息	需求说明中关于“登陆”的说明
测试数据	用户名=yiyh 密码=1
操作步骤	操作描述	数 据	期望结果	实际结果	实际结果	测试状态（P/F）
1	输入用户名称，按“登陆”按钮。	用户名=yiyh，密码为空	显示警告信息“请输入用户名和密码！”
2	输入密码，按“登陆”按钮。	用户名为空，密码=1	显示警告信息“请输入用户名和密码！”
3	输入用户名和密码，按“登陆”按钮。	用户名=yiyh，密码=2	显示警告信息“请输入用户名和密码！”
4	输入用户名和密码，按“登陆”按钮。	用户名=xxx，密码=1	显示警告信息“请输入用户名和密码！”
5	输入用户名和密码，按“登陆”按钮。	用户名=xxx，密码=2	显示警告信息“请输入用户名和密码！”
6	输入用户名和密码，按“登陆”按钮。	用户名=空，密码=空	显示警告信息“请输入用户名和密码！”
7	输入用户名和密码，按“登陆”按钮。	用户名=yiyh，密码=1	进入系统页面。
8	输入用户名和密码，按“登陆”按钮。	用户名=Admin，密码=admin	进入系统维护页面。
9	输入用户名和密码，按“登陆”按钮。	用户名=yiyh'',密码=1	显示警告信息“请输入用户名和密码！”
10	输入用户名和密码，按“登陆”按钮。	用户名=yiyh，密码=1''	显示警告信息“请输入用户名和密码！”
11	输入用户名和密码，按“重置”按钮。	用户名=yiyh，密码=1	清空输入信息
测试人员		开发人员			项目负责人

==需求测试用例==

客户需求列表－需求说明书	开发人员－系统说明书-功能列表	测试人员－－功能点测试列表
1注册功能	1用户可以自动注册	（对比发现问题）

= 接口测试用例＝

接口 A 的函数原型
输入 / 动作	期望的输出 / 相应	实际情况
典型值 …
边界值 …
异常值 …
接口 B 的函数原型
输入 / 动作	期望的输出 / 相应	实际情况
典型值 …
边界值 …
异常值 …
…

= 路径测试的检查用例=

检查项	结论
数据类型问题 （１）变量的数据类型有错误吗？ （２）存在不同数据类型的赋值吗？ （３）存在不同数据类型的比较吗？
变量值问题 （１）变量的初始化或缺省值有错误吗？ （２）变量发生上溢或下溢吗？ （３）变量的精度不够吗？
逻辑判断问题 （１）由于精度原因导致比较无效吗？ （２）表达式中的优先级有误吗？ （３）逻辑判断结果颠倒吗？
循环问题 （１）循环终止条件不正确吗？ （２）无法正常终止（死循环）吗？ （３）错误地修改循环变量吗？ （４）存在误差累积吗？
内存问题 （１）内存没有被正确地初始化却被使用吗？ （２）内存被释放后却继续被使用吗？ （３）内存泄漏吗？ （４）内存越界吗？ （５）出现野指针吗？
文件 I/O 问题 （１）对不存在的或者错误的文件进行操作吗？ （２）文件以不正确的方式打开吗？ （３）文件结束判断不正确吗？ （４）没有正确地关闭文件吗？
错误处理问题 （１）忘记进行错误处理吗？ （２）错误处理程序块一直没有机会被运行？ （３）错误处理程序块本身就有毛病吗？如报告的错误与实际错误不一致，处理方式不正确等等。 （４）错误处理程序块是“马后炮”吗？如在被它被调用之前软件已经出错。
…

=功能测试用例=

功能 A 描述
用例目的
前提条件
输入 / 动作	期望的输出 / 相应	实际情况
示例：典型值 …
示例：边界值 …
示例：异常值 …
功能 B 描述
用例目的
前提条件
输入 / 动作	期望的输出 / 相应	实际情况
……

=健壮性测试- 容错能力 / 恢复能力测试用例=

异常输入 / 动作	容错能力 / 恢复能力	造成的危害、损失
示例：错误的数据类型 …
示例：定义域外的值 …
示例：错误的操作顺序 …
示例：异常中断通信 …
示例：异常关闭某个功能 …
示例：负荷超出了极限 …

=性能测试用例=

性能 A 描述
用例目的
前提条件
输入数据	期望的性能（平均值）	实际性能（平均值）
性能 B 描述
用例目的
前提条件
输入数据	期望的性能（平均值）	实际性能（平均值）
……

=界面测试用例－界面检查表=

检查项	测试人员的类别及其评价
窗口切换、移动、改变大小时正常吗？
各种界面元素的文字正确吗？（如标题、提示等）
各种界面元素的状态正确吗？（如有效、无效、选中等状态）
各种界面元素支持键盘操作吗？
各种界面元素支持鼠标操作吗？
对话框中的缺省焦点正确吗？
数据项能正确回显吗？
对于常用的功能，用户能否不必阅读手册就能使用？
执行有风险的操作时，有“确认”、“放弃”等提示吗？
操作顺序合理吗？
有联机帮助吗？
各种界面元素的布局合理吗？美观吗？
各种界面元素的颜色协调吗？
各种界面元素的形状美观吗？
字体美观吗？
图标直观吗？
…

=信息安全测试用例=

假想目标 A
前提条件
非法入侵手段	是否实现目标	代价－利益分析
……
假想目标 B
前提条件
非法入侵手段	是否实现目标	代价－利益分析
……

=压力测试用例=

极限名称 A	例如“最大并发用户数量”
前提条件
输入 / 动作	输出 / 响应	是否能正常运行
例如 10 个用户并发操作
例如 20 个用户并发操作
…
极限名称 B
前提条件
输入 / 动作	输出 / 响应	是否能正常运行
…

=可靠性测试用例=

任务 A 描述
连续运行时间
故障发生的时刻	故障描述
……
统计分析
任务 A 无故障运行的平均时间间隔	（ CPU 小时）
任务 A 无故障运行的最小时间间隔	（ CPU 小时）
任务 A 无故障运行的最大时间间隔	（ CPU 小时）
任务 B 描述
连续运行时间
故障发生的时刻	故障描述
……
统计分析
任务 B 无故障运行的平均时间间隔	（ CPU 小时）
任务 B 无故障运行的最小时间间隔	（ CPU 小时）
任务 B 无故障运行的最大时间间隔	（ CPU 小时）

= 安装 / 反安装测试用例=

配置说明
安装选项	描述是否正常	使用难易程度
全部
部分
升级
其它
反安装选项	描述是否正常	使用难易程度

2. 测试用例的常用方法

1、等价类

方法：根据需求列出输入，并对每一个输入的规则进行分析，然后对每一条规则进行正确和错误的罗列，最后将的所有的输入进行正确和错误用例的组合，一条正确的用例尽可能多的覆盖每个输入的不同有效数据，一条错误的用例只能含有一个无效数据（控制变量）。 对于一个输入应考虑它的：数据类型、长度、取值范围、是否可重复，是否为空（为空可分为不输入和输入空格），组成规则等内容 。

优点：简单高效，能快速评估测试用例数量；

缺点：只考虑了输入的有效和无效，对数据的组合比较随机，边界缺陷不容易发现 ；

适用范围：只在存在输入的需求都适用。

2、边界值

边界值分析方法的理论基础是假定大多数的错误是发生在各种输入条件的边界上，如果在边界附近的取值不会导致程序出错，那么其他取值导致程序错误的可能性也很小。

方法：对于存在边界的输入取边界的上点、内点、离点进行测试。

上点：边界上的点

内点：边界内的点

离点：闭区间间靠近上点但在区间外的一点，开区间则是在区间内的一点 主要是用于对等价类的补充

优点：能更容易发现边界，更全面系统的测试边界上可能存在的问题；

缺点：只能做为一个对其他设计方法的补充；

适用范围：有输入参数且存在取值边界或长度边界时。

3、判定表

方法：确定输入和输出，列出所有的条件桩和动作桩；填入条件项；针对每个条件项计算并填入动作项；化简，合并相似的规则。

优点：能把复杂的问题按各种可能的情况一一列举出来，简明而易于理解，也可避免遗漏；

缺点：条件桩过多时，用例呈指数增长，且在合并相似的项时存在漏测的风险；

适用范围：多个输入判断条件存在逻辑关系，且不分先后的情况。

4、正交实验法

从大量的测试点中挑选出适量的有代表性的点，应用依据迦罗瓦理念导出的正交表，合理安排测试数据的方法 。

优点：用于考虑到所有的组合又使例数量最少 ；

适用范围：输入的参数之间是独立的，不存在相互依赖的关系。

5、流程分析法

流程分析法是将软件系统的某个流程看成路径，根据流程的顺序依次进行组合，使得各个分支都能走到；。

方法：画出流程图，确定测试路径，选择测试数据；构造测试用例；

优点：覆盖了输入，处理和输入；

缺点：覆盖的输入取值不多，需要对业务比较了解 ；

适用范围：流程比较复杂的情况。

6、状态迁移法

即有深度和广度的状态树 。

方法：画出状态迁移图；通过迁移图画出状态转换树；从转换枝推导出测试路径；编写测试用例 。

优点：保证每一个节点的所有可达状态都被测试到；

缺点：没有对不可达的状态进行测试的覆盖；

适用范围：从一个操作可以到达多个可能的操作或从一个状态可以到达多个可能的规定状态 且状态取值或输入变化有固定的要求顺序。

7、因果图

因果图提供了一个把规格转化为判定表的系统方法，且它最终生成的就是判定表。

方法：把大的系统规格划分成可以测试的规格片段；分析哪些是原因、哪些是结果；画出因为图；把因果图转换成判定表；简化判定表；

优点：能帮助我们按照一定步骤，高效的选择测试用例，设计多个输入条件组合用例；能考虑到多个条件组合起来可能出错的情况；

缺点：输入条件与输出条件的因果关系有时很难从SRS中得到，即便得到了也会因为因果关系复杂导致因果图非常庞大，从而使测试用例数目非常多；

8、输入域覆盖法

是一种综合的方法，综合了等价类和边界值等方法

9、输出域覆盖法

从输入结果倒推输入的测试方法

10、异常分析法

主要是构造环境异常来看测试结果

11、错误猜测法

方法选择：

所有输入选等价；给定范围加边界；条件孤立想判定
指定常量取正交；跨界操作流程法；多种状态迁移图
条件组合出因果；测试充分全覆盖；多种方法不唯一

测试用例关注点

3. 工具与软件

Excel表格

testlink

testLink是最广泛使用的基于Web的开源测试管理工具。它一起同步需求和测试用例。用户可以使用这个工具创建测试项目和文档测试用例。通过TestLink，您可以为多个用户创建一个帐户，并分配不同的用户角色。管理员用户可以管理测试用例分配任务。

它支持测试用例的自动和手动执行。测试人员可以用这个工具在很短的时间内生成测试计划和测试报告。它支持各种格式的测试报告，如Excel、MS Word和HTML格式。除此之外，它还支持与许多流行的缺陷跟踪系统集成，如JIRA、MANTIS、BugZILLA、TRAC等。因为它是一种基于Web的工具，多个用户以他们的凭据和分配的角色可以同时访问其功能。

禅道

禅道是一款开源项目管理软件。它集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体，是一款专业的研发项目管理软件，完整覆盖了研发项目管理的核心流程。

禅道将产品、项目、测试这三者的概念明确分开，产品人员、开发团队、测试人员，这三者分立，互相配合，又互相制约，通过需求、任务、bug来进行交相互动，最终通过项目拿到合格的产品。

三、 测试执行

四项任务

执行测试用例
记录原始测试数据
记录缺陷
对缺陷进行跟踪，管理和监控
· 测试结果的不一致可能是因为测试环境出错，测试人员人为误差、bug造成的

四个度量指标

测试覆盖率
测试执行率
测试通过率
缺陷解决率

注意事项

· 全方位观察执行结果（发现不一致先反思是不是自己操作错误，可以再次执行
· 加强测试过程记录
· 及时确认开发的问题
· 及时更新测试用例
· 与开发良好的沟通

四、测试结果/报告

1. 测试报告

（1） 测试报告是产品部与技术部进行沟通的主要手段。

（2）是一个测试活动的总结，项目是否结项的重要参考和依据。

（3）软测试报告是对测试过程和测试结果进行分析和评估，确认测试计划是否得到完整履行、测试覆盖率是否达到预定要求以及对产品质量是否有足够信心，并最终在报告中给出测试和产品质量的评估结论。

2. 测试报告反映的内容：

1.测试对象（版本）

2.测试内容

3.测试工具

4.测试记录

5.测试人员

6.测试时间

7.测试结果

8.风险评估

测试报告的内容（转载）

（1）测试项目的版本，测试项目内容的概述。

（2）测试的时间、地点、人员 。

（3）测试环境：测试环境的描述，包括客户端和网络环境。

测试资源：测试过程中的测试资源使用。

（4）缺陷统计：

一、测试结果的统计：包括测试的数据：bug数，解决数，遗留数。模块bug分布：bug走势图，缺陷遗留，需要说明的问题。测试数据分析。

二、测试用例的执行情况。

三、测试所覆盖的缺陷——测试组在这轮测试中所有处理的缺陷，报告了测试组长处理的缺陷和实施工程师验证的缺陷。不仅要写出覆盖缺陷的总数，还要写明这些缺陷的去向 测试新发现的缺陷数量。

四、上一版本活动缺陷的数量 ，经过此轮测试，所有活动缺陷的数量及其状态分类 。

（5）测试评估：

一、基于软件缺陷的质量评估。写明在这一版本中，那些功能被实现了，那些还没有实现，这里只需写明和上一版本不同之处即可 。

二、测试质量的评估

三、测试设置评估及改进

（6）规避措施。

（7）急待解决的问题——写明当前项目组中面临的最优先的问题，可以重复提出。

（8）附件。