软件测试第02章

格式：ppt
大小：387.50 KB
文档页数：45

下载文档原格式

/ 45

智慧树知到答案 SPSS软件与应用章节测试答案

第一章单元测试1、多选题：下列属于SPSS运行窗口的是（）。

选项：A:脚本窗口B:方法窗口C:数据窗口D:结果窗口答案: 【脚本窗口;数据窗口;结果窗口】2、多选题：SPSS处理实际问题的一般步骤包括（）。

选项：A:结果的解释和表达B:数据的加工整理C:数据的统计分析D:数据的准备答案: 【结果的解释和表达;数据的加工整理;数据的统计分析;数据的准备】3、多选题：进行数据编码的过程中，需要考虑变量的（）。

选项：A:类型B:名称C:赋值D:个数答案: 【类型;名称;赋值;个数】4、单选题：在某调查问卷中，有这样一个问题：“请问您来自哪个省？”从问题类型来看，这个问题属于（）。

选项：A:唯一选项字符型问题B:一般字符型问题C:一般数值型问题D:唯一选项数值型问题答案: 【一般字符型问题】5、单选题：在某调查问卷中，有这样一个问题：“在淘宝、拼多多、京东、网易严选中，请问您最经常使用的购物网站是什么？（限选2项）”要对这个问题进行编码，需要设置（）个变量。

选项：A:1B:3C:4D:2答案: 【2】6、单选题：对于量表中反向计分的题目，其赋值最常通过（）完成。

选项：A:计算变量B:分类汇总C:变量重新编码D:实用程序答案: 【变量重新编码】7、判断题：学习了SPSS软件，就可以不必学习统计学方法了。

（）选项：A:错B:对答案: 【错】8、判断题：数据视图中，一行代表一个个案，即一个研究对象的全部资料都体现在这一行之中。

（）选项：A:对B:错答案: 【对】9、判断题：字符型变量也可以进行算术和比较运算。

（）选项：A:对B:错答案: 【错】10、判断题：SPSS数据文件的纵向合并就是添加个案的过程。

（）选项：A:错B:对答案: 【对】第二章单元测试1、多选题：下列可用于计数资料的描述性分析的是（）。

选项：A:直方图B:条形图C:饼图D:散点图答案: 【条形图;饼图】2、多选题：下列属于计量资料离散趋势指标的是（）。

软件测试技术基础课后习题答案

3. 简单分析软件缺陷产生的原因，其中那个阶段引入的缺陷最多，修复成本又最低？
解：软件缺陷产生的主要原因有：需求规格说明错误；设计错误；程序代码有误；其他。其中在需求分析阶段引入的缺陷最多，修复的成本又最低。
4. 当用户登录某网站购物完毕并退出后，忽然想查查购物时付账的总金额，于是按了浏览器左上角的“退回”按钮，就又回到了退出前的网页，你认为该购物软件有缺陷吗？如果有，属于哪一类？
解：有缺陷。其所属类别与软件产品说明书的要求有关。
5. 什么是软件测试？简述其目的与原则。
解：软件测试是为了尽快尽早地发现在软件产品中所存在的各种软件缺陷而展开的贯穿整个软件开发生命周期，对软件产品（包括阶段性产品）进行验证和确认的活动过程。
测试目的：（1）证明：获取系统在可接受风险范围内可用的信心；尝试在非正常情况和条件下的功能和特性；保证一个工作产品是完整的并且可用或可被集成。（2）检测：发现缺陷、错误和系统不足；定义系统的能力和局限性；提供组件、工作产品和系统的质量信息。（3）预防：澄清系统的规格和性能；提供预防或减少可能制造错误的信息；在过程中尽早检测错误；确认问题和风险，并且提前确认解决这些问题和风险的途径。
8. 简述软件测试过程。
解：软件测试过程主要包括如下6个活动：测试计划；测试需求分析；测试设计；测试规程实现；测试执行；总结生成报告。
9. “软件测试能够保证软件的质量”这句话对吗？软件测试和软件质量之间是什么关系？
解：不对。软件测试是保障软件质量的手段之一，但不是唯一手段。测试是产品高质量的必要非充分条件，软件测试不能决定软件质量。
快速原型模式首先构造一个功能简单的原型系统，然后通过对原型系统逐步求精，不断扩充完善得到最终的软件系统。原型系统在扩充完善过程中不断被检查、测试和修改。

软件测试概要

第一章：软件测试概述①软件缺陷定义：（1）软件未达到产品说明书中已经标明的功能；（2）软件出现了产品说明书中指明不会出现的错误；（3）软件未达到产品说明书中虽未指出但应当达到的目标；（4）软件功能超出了产品说明书中指明的范围；（5）软件测试人员认为软件难以理解、不易使用，或者最终用户认为该软件使用效果不良。

②软件缺陷的特征：•“看不到”——软件的特殊性决定了缺陷不易看到•“看到但是抓不到”——发现了缺陷，但不易找到问题发生的原因所在③软件缺陷产生原因：（1）软件产品说明书（需求）——56%（不专业—专业~~信息传递）（2）设计——27%（设计不规范）（3）编写代码——7%（4）其他——10%（软、硬件设备之间的配备问题）④软件测试发展历程：早期―→测试1957年―→为了确信自己的产品20世纪70年代―→Glenford Myers 《软件测试艺术》——“测试是为发现错误而执行一个程序或系统的过程”20世纪80年代早期―→软件质量、Bill Hetzel 《软件测试完全指南》——“测试是以评价一个程序或者系统属性为目标的任何一种活动。

测试是对软件质量的度量”20世纪90年代―→测试工具盛行2002年―→Rick和Stefan《系统的软件测试》——“测试是为了度量和提高被测软件的质量，对测试件进行工程设计、实施和维护的整个生命周期过程”⑤今天的软件测试面临的挑战：•软件在国防现代化、社会信息化和国民经济信息化中的作用越来越重要，由此产生的测试任务越来越繁重•软件规模越来越大，功能越来越复杂，如何进行充分而有效的测试成为难题•面向对象的开发技术越来越普及，但是面向对象的测试技术却刚刚起步•对于分布式系统整体性能还不能进行很好的测试•对于实时系统来说，缺乏有效的测试手段•随着安全问题的日益突出，信息系统的安全性如何进行有效的测试与评估，成为世界性难题⑥软件开发与软件测试的关系：•测试与开发各阶段的关系项目规划阶段，需求分析阶段，详细设计和概要设计阶段，编码阶段，测试阶段（软件开发生命周期）•测试与开发的并行性⑦软件测试的发展趋势：•测试工作将进一步前移。

02软件测试方法2-黑盒测试

19
第2章软件测试方法章
2.8单元测试方法 2.8单元测试方法
2.8.1黑盒测试黑盒测试
2.8.1.2等价类划分等价类划分例子2：保险费率计算
程序界面：
20
第2章软件测试方法章
2.8单元测试方法 2.8单元测试方法
2.8.1黑盒测试黑盒测试
2.8.1.2等价类划分等价类划分例子2：保险费率计算：输入数据说明
c
c c c u u u c u u c c u c u u
u c c c c c c c u u u u u u c u u u c c c c c u c c c c u u u u u u u c u u c c u c u c c c c u
30
第2章软件测试方法章
2.8单元测试方法 2.8单元测试方法
年龄 20 ～ 39 40 ～ 59 60岁以上20岁以下 60 20 性别婚姻抚养人数男女已婚未婚 6点 4点 2点 2 5点 3点 3点 5点
1人扣0.5点，最多3点(四舍五入取整数)
21
第2章软件测试方法章
2.8单元测试方法 2.8单元测试方法
2.8.1黑盒测试黑盒测试
2.8.1.2等价类划分等价类划分例子2：保险费率计算：输入数据说明
31
第2章软件测试方法章
2.8单元测试方法 2.8单元测试方法
2.8.1.3组合测试组合测试
2.8.1黑盒测试黑盒测试
组合覆盖（全对偶）：组合覆盖（全对偶）：
一个详细例子：一个函数有三个参数一个详细例子：一个函数有三个参数v1,v2,v3;v1有三个取有三个取 v2有两个取值 v3有两个取值有两个取值，有两个取值。值，v2有两个取值，v3有两个取值。

第02章__ANSYS软件的基本使用方法.

Engineering Computation
2018年10月9日星期二
FM&MEI 2
Chapter 2 Basic analysis procedures of ANSYS
The short history of ANSYS
1970年，Doctor John swanson洞察到计算机模拟工程应该商品化，于是创建ANSYS公司，总部位于美国宾西法尼亚州的匹兹堡，目前是世界CAE行业最大的公司。三十多年来，ANSYS公司一直致力于分析设计软件的开发、维护及售后服务，不断吸取当今世界最新的计算方法和计算机技术，领导着有限元界的发展趋势，并为全球工业界所广泛接受，拥有全球最大的用户群（50000）。 ANSYS公司对软件的质量非常重视，新版的ANSYS 软件必须通过7,000道标准考题。业界典范的质保体系，自动化规范化的质量测试使ANSYS公司于1995年5月在设计分析类软件中第一个通过了ISO9001的质量体系认证。
Engineering Computation
2018年10月9日星期二
FM&MEI 6
Chapter 2 Basic analysis procedures of ANSYS
The basic features of ANSYS
后处理功能强(the postprocessing ability) 可获得任何节点、单元的数据。具有列表输出、图形显示、动画模拟等多种数据输出形式，具有时间历程分析功能，可叠加不同荷载工况以及进行各种数学计算等功能。开放性好(the programmable ability) 允许用户在ANSYS系统上进行二次开发和扩展新的用户功能。包括在用户程序中调用ANSYS系统、开发新的用户单元、在ANSYS系统中调用用户子程序、建立用户蠕变准则等等。

02软件测试方法1

一经开发就能进入测试以验证是否符合产品需求帮助引导出高质量的产品需求。帮助引导出高质量的产品需求。如果没有可能在一开始就弄清楚所有的产品需它们可以分批取得。对于已提出的产品需求，求，它们可以分批取得。对于已提出的产品需求，则可根据对现阶段原型的试用而作出修改可以在早期就获得项目进程数据，可以在早期就获得项目进程数据，可据此对后续的开发循环作出比较切实的估提供机会去采取早期预防措施，增加项目成功的机率。算。提供机会去采取早期预防措施，增加项目成功的机率。有助于早期建立产品开发的配置管理，产品构建（），自动化测试有助于早期建立产品开发的配置管理，产品构建（ build），自动化测试，缺陷），自动化测试，跟踪，文档管理。跟踪，文档管理。均衡整个开发过程的负荷经验教训能反馈应用于本产品的下一个循环过程，经验教训能反馈应用于本产品的下一个循环过程，大大提高质量与效率
4
第2章软件测试方法章
2.1软件测试与软件开发的关系 2.1软件测试与软件开发的关系
2.1.2迭代模型迭代模型
5
第2章软件测试方法章
2.1软件测试与软件开发的关系 2.1软件测试与软件开发的关系
优点（电通智能电网门户项目例子电通智能电网门户项目例子）优点（E电通智能电网门户项目例子）：
18系 2.1软件测试与软件开发的关系
2.1.4RUP
优点：
提高了团队生产力，在迭代的开发过程、需求管理、基于组件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面，针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导，并确保全体成员共享相同的知识基础。
20
第2章软件测试方法章
2.2软件测试与质量的关系 2.2软件测试与质量的关系

02软件测试方法5-系统测试

2.9.2.2软件性能指标并发用户数
响应时间
吞吐量
资源利用率
27
第2章软件测试方法
2.9集成后系统的测试方法 2.9.2性能测试
2.9.2.2软件性能指标-并发用户数并发用户数是指在某一给定时间内，某个特定点上进行会话操作的用户数。
窗体标题
输入文本输入文本文本
组
输入文本输入文本
大负载下系统检查系统在大负载情况下业务的功能性处理流程是否正确
2.9集成后系统的测试方法 2.9.2性能测试
功能与性能的关系
功能焦点在于软件“做什么”，关注软件物质
主体发生的“事件” 性能关注于物质“做得如何”，这是综合“空间”和“时间”考虑的方案，表现为软件对 “空间”和“时间”的敏感度。(资源和速度) 软件性能实现是建立在功能实现的基础之上的。
第2章软件测试方法
2.9集成后系统的测试方法 2.9.2性能测试
2.9.2.1什么是软件性能？-总结
发出请求
窗体标题
输入文本输入文本输入文本输入文本
请求
组
文本
用户感受到响应
返回数据应用服务器 DB服务器
呈现时间
系统响应时间
26
第2章软件测试方法
2.9集成后系统的测试方法 2.9.2性能测试
I
13
第2章软件测试方法
2.9集成后系统的测试方法 2.9.1业务流程测试
基于场景设计测试用例数据设计：一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据，如表所示。

软件测试测试用例编写及执行规范

软件测试测试用例编写及执行规范第1章测试用例编写概述 (4)1.1 测试用例定义 (4)1.2 测试用例目的 (4)1.3 测试用例编写原则 (4)第2章测试用例结构 (4)2.1 测试用例编号 (4)2.2 测试用例标题 (4)2.3 测试用例描述 (4)2.4 预置条件 (4)2.5 测试步骤 (4)2.6 预期结果 (4)2.7 实际结果 (4)2.8 测试结论 (4)第3章测试用例编写规范 (4)3.1 编写规则 (4)3.2 测试用例命名规范 (4)3.3 测试用例描述规范 (4)3.4 测试步骤与预期结果规范 (4)第4章测试用例执行流程 (4)4.1 测试用例执行准备 (4)4.2 测试用例执行过程 (4)4.3 测试用例执行结果记录 (5)4.4 测试用例执行异常处理 (5)第5章测试用例执行管理 (5)5.1 测试用例执行计划 (5)5.2 测试用例执行进度监控 (5)5.3 测试用例执行结果汇总 (5)5.4 测试用例执行报告 (5)第6章测试用例评审 (5)6.1 评审目的 (5)6.2 评审流程 (5)6.3 评审标准 (5)6.4 评审结果处理 (5)第7章测试用例维护 (5)7.1 测试用例更新时机 (5)7.2 测试用例更新流程 (5)7.3 测试用例版本管理 (5)7.4 测试用例维护记录 (5)第8章测试用例管理工具 (5)8.1 测试用例管理工具选型 (5)8.2 测试用例管理工具使用 (5)8.3 测试用例管理工具维护 (5)8.4 测试用例管理工具优化 (5)第9章自动化测试用例编写 (5)9.1 自动化测试用例特点 (5)9.2 自动化测试用例编写规范 (5)9.3 自动化测试用例编写工具 (5)9.4 自动化测试用例编写实践 (5)第10章自动化测试用例执行 (5)10.1 自动化测试用例执行策略 (5)10.2 自动化测试用例执行过程 (6)10.3 自动化测试用例执行结果分析 (6)10.4 自动化测试用例执行优化 (6)第11章移动端测试用例编写与执行 (6)11.1 移动端测试用例特点 (6)11.2 移动端测试用例编写规范 (6)11.3 移动端测试用例执行策略 (6)11.4 移动端测试用例执行实践 (6)第12章测试用例编写与执行最佳实践 (6)12.1 测试用例编写最佳实践 (6)12.2 测试用例执行最佳实践 (6)12.3 测试用例管理最佳实践 (6)12.4 测试团队协作最佳实践 (6)第1章测试用例编写概述 (6)1.1 测试用例定义 (6)1.2 测试用例目的 (6)1.3 测试用例编写原则 (7)第2章测试用例结构 (7)2.1 测试用例编号 (7)2.2 测试用例标题 (7)2.3 测试用例描述 (8)2.4 预置条件 (8)2.5 测试步骤 (8)2.6 预期结果 (8)2.7 实际结果 (8)2.8 测试结论 (8)第3章测试用例编写规范 (8)3.1 编写规则 (8)3.1.1 测试用例目的明确 (8)3.1.2 测试用例独立 (9)3.1.3 测试用例简洁明了 (9)3.1.4 测试用例分类 (9)3.1.5 测试用例优先级 (9)3.2 测试用例命名规范 (9)3.2.1 命名原则 (9)3.2.2 命名示例 (9)3.3 测试用例描述规范 (9)3.3.1 测试用例标题 (9)3.3.2 测试用例描述 (9)3.3.3 描述示例 (10)3.4 测试步骤与预期结果规范 (10)3.4.1 测试步骤 (10)3.4.2 预期结果 (10)3.4.3 步骤与预期结果示例 (10)第4章测试用例执行流程 (11)4.1 测试用例执行准备 (11)4.2 测试用例执行过程 (11)4.3 测试用例执行结果记录 (11)4.4 测试用例执行异常处理 (12)第5章测试用例执行管理 (12)5.1 测试用例执行计划 (12)5.2 测试用例执行进度监控 (13)5.3 测试用例执行结果汇总 (13)5.4 测试用例执行报告 (13)第6章测试用例评审 (14)6.1 评审目的 (14)6.2 评审流程 (14)6.3 评审标准 (14)6.4 评审结果处理 (15)第7章测试用例维护 (15)7.1 测试用例更新时机 (15)7.2 测试用例更新流程 (16)7.3 测试用例版本管理 (16)7.4 测试用例维护记录 (16)第8章测试用例管理工具 (17)8.1 测试用例管理工具选型 (17)8.2 测试用例管理工具使用 (17)8.3 测试用例管理工具维护 (17)8.4 测试用例管理工具优化 (18)第9章自动化测试用例编写 (18)9.1 自动化测试用例特点 (18)9.2 自动化测试用例编写规范 (18)9.3 自动化测试用例编写工具 (19)9.4 自动化测试用例编写实践 (19)第10章自动化测试用例执行 (20)10.1 自动化测试用例执行策略 (20)10.2 自动化测试用例执行过程 (20)10.3 自动化测试用例执行结果分析 (20)10.4 自动化测试用例执行优化 (21)第11章移动端测试用例编写与执行 (21)11.1 移动端测试用例特点 (21)11.2 移动端测试用例编写规范 (21)11.3 移动端测试用例执行策略 (22)11.4 移动端测试用例执行实践 (22)第12章测试用例编写与执行最佳实践 (23)12.1 测试用例编写最佳实践 (23)12.2 测试用例执行最佳实践 (23)12.3 测试用例管理最佳实践 (24)12.4 测试团队协作最佳实践 (24)第1章测试用例编写概述1.1 测试用例定义1.2 测试用例目的1.3 测试用例编写原则第2章测试用例结构2.1 测试用例编号2.2 测试用例标题2.3 测试用例描述2.4 预置条件2.5 测试步骤2.6 预期结果2.7 实际结果2.8 测试结论第3章测试用例编写规范3.1 编写规则3.2 测试用例命名规范3.3 测试用例描述规范3.4 测试步骤与预期结果规范第4章测试用例执行流程4.1 测试用例执行准备4.2 测试用例执行过程4.3 测试用例执行结果记录4.4 测试用例执行异常处理第5章测试用例执行管理5.1 测试用例执行计划5.2 测试用例执行进度监控5.3 测试用例执行结果汇总5.4 测试用例执行报告第6章测试用例评审6.1 评审目的6.2 评审流程6.3 评审标准6.4 评审结果处理第7章测试用例维护7.1 测试用例更新时机7.2 测试用例更新流程7.3 测试用例版本管理7.4 测试用例维护记录第8章测试用例管理工具8.1 测试用例管理工具选型8.2 测试用例管理工具使用8.3 测试用例管理工具维护8.4 测试用例管理工具优化第9章自动化测试用例编写9.1 自动化测试用例特点9.2 自动化测试用例编写规范9.3 自动化测试用例编写工具9.4 自动化测试用例编写实践第10章自动化测试用例执行10.1 自动化测试用例执行策略10.2 自动化测试用例执行过程10.3 自动化测试用例执行结果分析10.4 自动化测试用例执行优化第11章移动端测试用例编写与执行11.1 移动端测试用例特点11.2 移动端测试用例编写规范11.3 移动端测试用例执行策略11.4 移动端测试用例执行实践第12章测试用例编写与执行最佳实践12.1 测试用例编写最佳实践12.2 测试用例执行最佳实践12.3 测试用例管理最佳实践12.4 测试团队协作最佳实践第1章测试用例编写概述测试用例是软件测试过程中的核心组成部分，它对于保证软件质量、发觉潜在缺陷具有重要意义。

第02章_边界值分析法

报表的第一行和最后一行
数组元素的第一个和最后一个
循环的第 0 次、第 1 次和倒数第 2 次、最后一次
在多数情况下，边界值条件是基于应用程序的功能设计而需要考虑的因素，可以从软件的需
求规格或常识中得到，也是最终用户可以很容
易发现问题的。
还有没有从软件规格说明中看不到的边界值呢？
小结 1
预期输出
等腰三角形等腰三角形! 等边三角形非三角形等腰三角形等腰三角形等腰三角形
8
9 10 11 12 13
100
100 1 2 199 200
199
200 100 100 100 100
100
100 100 100 100 100
等腰三角形
非三角形等腰三角形等腰三角形等腰三角形非三角形
情况进行处理。程序员把 ≤ 误写成了 < ，计数器发生少计数一次。
学习目标
边界值与边界值分析法边界值分析选取测试数据 ★ 常见的边界值类型边界条件设计测试用例的步骤边界条件测试用例设计法 ★
边界值分析法
边界值分析法：是对输入或输出的边界值进行测试的一种黑盒测试方法。
2.健壮性边界条件测试用例设计法
用例 1 2 3 4 5 6 7 8 9 10 11 a 100 100 100 100 100 100 100 100 100 100 100 b 100 100 100 100 100 100 100 0 1 2 199 c 0 1 2 100 199 200 201 100 100 100 100 预期输出 c超过取值范围等腰三角形等腰三角形等边三角形非三角形等腰三角形 c超过取值范围 b超过取值范围等腰三角形等腰三角形等腰三角形

软件测试技术02-软件质量模型

酒店：
• • • • • 建筑：客房、西餐厅、宴会厅、酒吧、健身房…… 设施：配套设施的品牌、档次环境：交通、风景…… 服务：服务品种、服务态度、响应客户要求的及时性…… ……
软件质量的三个层次
从质量的定义，我们可以引申出不同层次的软件质量： 1. 符合需求规格：符合开发者明确定义的目标，即产品是不是在做让它做的事情。目标是开发者定义的，并且是可以验证的； 2. 符合用户显式需求：符合用户所明确说明的目标。目标是客户所定义的，符合目标即判断我们是不是在做我们需要做的事情； 3. 符合用户实际需求：实际的需求包括用户明确说明的和隐含的需求。
4
软件测试的原则
• zero-bug vs. good-enough
• 防止过少和过量的测试。
• 木桶原则
• 不能有短板。测试仅作为重要的一环，不能仅依赖测试来保证质量；
• 80-20原则
• 能被发现的Bug仅占全部Bug的80%，还有20%只有在大范围、长时间使用下才能暴露。
5
软件测试的认识误区
软件质量与质量模型
• McCall 质量模型
产品运行正确性可靠性效率可使用性完整性产品修正可维护性可测试性灵活性
产品转移
可移植性可复用性互连性
12
影响软件质量的因素
流程技术组织
流程产品质量组织技术
上面三个方面是影响软件质量的铁三角，软件质量的提高应该是一个综合的因素，需要从每个方面进行改进，同时还需要兼顾成本和进度
本章内容
认识软件测试软件质量的定义软件质量管理体系软件质量活动
软件质量管理体系
ISO9000 流行的软件质量管理体系六西格玛

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

8．测试中断和恢复的规定
测试计划中这一部分给出了测试中断和恢复的标准。常用的测试中断标准如下：关键路径上的未完成任务大量的缺陷严重的缺陷不完整的测试环境资源短缺
9．测试完成所提交的材料
测试完成所提交的材料包含了测试工作开发设计的所有文档、工具等。例如，测试计划、测试设计规格说明、测试用例、测试日志、测试数据、自定义工具、测试缺陷报告和测试总结报告等。
2.6 制定测试计划
制定测试计划时，由于各软件公司的背景不同，测试计划文档也略有差异。实践表明，制定测试计划时，使用正规化文档通常比较好。为了使用方便，在这里给出IEEE软件测试计划文档模板。
IEEE829－1998 软件测试文档编制标准软件测试计划文档模板目录 1．测试计划标识符 2．介绍 3．测试项 4．需要测试的功能 5．方法（策略） 6．不需要测试的功能 7．测试项通过/失败的标准 8．测试中断和恢复的规定 9．测试完成所提交的材料 10．测试任务 11．环境需求 12．测试人员的工作职责 13．人员安排与培训需求 14．进度表 15．潜在的问题和风险 16．审批
根据IEEE829－1998软件测试文档编制标准的建议，测试计划包含了16个大纲要项，简要说明如下。
1．测试计划标识符
一个测试计划标识符是一个由公司生成的惟一值，它用于标识测试计划的版本、等级，以及与该测试计划相关的软件版本。
2．简要介绍
测试计划的介绍部分主要是对测试软件基本情况的介绍和对测试范围的概括性描述。测试软件的基本情况主要包括产品规格(制造商和软件版本号的说明)，软件的运行平台和应用的领域，软件的特点和主要的功能模块的特点，数据的存储、传递，每一个部分是怎么实现数据更新的以及一些常规性的技术要求，还要包括测试的侧重点
5 ．不需要测试的功能
这一部分列出了不测试的单项功能及组合功能并说明不予测试的理由。
6．测试方法（策略）测试策略描述测试小组用于测试整体和每个阶段的方法。要描述如何公正、客观地开展测试，要考虑模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素的影响，要尽可能地考虑到细节，越详细越好，并制作测试记录文档的模板，为即将开始的测试做准备。测试记录具体说明如下。
IEEE标准中指出，可以参考下面的文档来完成测试项目：
1) 2) 3) 4) 需求规格说明。用户指南。操作指南。安装指南。
总的来说，测试需要分析软件的每一部分，明确其是否需要测试，并说明理由。
4．测试对象
测试计划的这一部分需要列出待测的单项功能及功能组合。这部分内容与测试项目不同。测试项目是从开发者或程序管理者的角度计划测试项目，而测试对象是从用户的角度规划测试的内容
制定软件测试计划可以在以下几方面帮助我们: 1．使软件测试工作进行更顺利 2．促进项目参加人员彼此的沟通 3．及早发现和修正软件规格说明书的问题 4 ．使软件测试工作更易于管理
使软件测试工作进行更顺利
软件测试计划明确地将要进行的软件测试采用的模式、方池、步骤以及可能遇到的问题与风险等内容都做了考虑和计划，这样会使测试执行、测试分析和撰写测试报告的准备工作更加有效，使软件测试工作进行得更顺利。
认真做好测试资料的搜集整理工作
重点是收集与技术信息相关的内容 1) 软件的类别及其构成。软件的类别及其构成是指软件的类别与用途(不同类的软件有不同的考虑重点)、软件的结构、软件所支持的平台以及软件的主要构成部分、各自功能及各部分之间的联系、每一构成部分所使用的计算机语言等信息。如果进行白盒测试，那么测试人员还要熟悉各部分已建立的函数库中的函数以及这些函数的用途和其输入、输出。
可以把计划的内容简要地概括为八个方面，即： What(什么)——计划的目的、内容； Who（谁）——计划的相关人员； Where（何处）——计划的实施场所； When（何时）——计划实施的时间范围； Why（为什么）——计划的缘由、前景； How（如何）——计划的方法和运转实施； How much（多少）——计划的预算； Effect（效果）——预测计划实施的结果、效果
使软件测试工作更易于管理
制订测试计划的另一个目的，就是要对整个软件测试工作采取系统化的方式来进行，这样会使软件测试上作更易于管理。测试计划包含两种主要的管理方式，一是工作分解结构，二是监督和控制。
2.2 制定测试计划的原则
制定测试计划是软件测试中最有挑战性的一个工作。以下原则将有助于制定测试计划工作。
采用评审和更新机制
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。测试计划包含多方面的内容，编写人员可能受自身测试经验和对软件需求的理解所限，而且软件开发是一个渐进的过程，所以最初创建的测试计划可能是不完善的、需要更新的。需要采取相应的评审机制对测试计划的完整性、正确性、可行性进行评估
2.1 软件测试计划的作用
测试计划就是描述所有要完成的测试
工作，包括被测试项目的背景、目标、范
围、方式、资源、进度安排、测试组织，
以及与测试有关的风险等方面。
《ANSI/IEEE软件测试文档标准829-1983》将测试计划定义为：“一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。”
2.4 制定测试计划时面对的问题
制定测试计划时，测试人员可能面对以下问题，必须认真对待，并妥善予以处理。
1．与开发者意见不一致 2．缺乏测试工具 3．培训不够
4．管理部门缺乏对测试工作的理解和支持 5．缺乏用户的参与 6．测试时间不足 7．过分依赖测试人员 8．测试人员处于进退两难的状态 9．不得不说“不”
在管理学中，计划具有两重含义，其一是计划工作，是指根据对组织外部环境与内部条件的分析，提出在未来一定时期内要达到的组织目标以及实现目标的方案途径。其二是计划形式，是指用文字和指标等形式所表述的组织以及组织内不同部门和不同成员，在未来一定时期内关于行动方向、内容和方式安排的管理事件
无论是计划工作还是计划形式，计划都是根据社会的需要以及组织的自身能力，通过计划的编制、执行和检查，确定组织在一定时期内的奋斗目标，有效地利用组织的人力、物力、财力等资源，协调安排好组织的各项活动，取得最佳的经济效益和社会效益。
公正性声明
测试用例
特殊考虑经验判断
设想
7．测试项通过/失败的标准Байду номын сангаас
测试计划中这一部分给出了“测试项” 中描述的每一个测试项通过/失败的标准。正如每个测试用例都需要一个预期的结果一样，每个测试项同样都需要一个预期的结果。
一般来说，通过或失败的标准是由通过／失败的测试用例，缺陷的数量、类型、严重性和位置，可靠性或稳定性等来描述的。随着测试等级的不同和测试组织的不同，所采用的确切标准也会不同下面是通过/失败的标准的一些例子：通过测试用例所占的百分比；缺陷的数量、严重程度和分布情况；测试用例覆盖；用户测试的成功结论；文档的完整性；性能标准。
促进项目参加人员彼此的沟通
应该尽早编写，让所有相关人员清楚地了解测试方法、测试策略和进度安排等。既可以让其他团队了解测试团队的工作安排，也要让测试团队成员目标和步调一致
及早发现和修正软件规格说明书的问题
在编写软件测试计划的初期，首先要了解软件各个部分的规格及要求，这样就需要仔细地阅读、了解规格说明书。在这个过程中，可能会发现其中出现的问题，例如规格说明书的论述前后矛盾、描述不完整等。对规格说明书中的缺陷越早修正，对软件开发的益处越大，因为规格说明书从一开始就是软件开发工作的依据。
2) 软件的用户界面。用户界面的类别是指软件的用户界面风格类似windows软件，还是指令行软件，或是网页类软件。测试人员还需掌握用户界面各部分的功能、联系以及界面各织成部件的特性、操作特点等。 3) 在所测试的软件涉及第三方软件的情况下，必须对这个第三方软件的功能及其与所要测试的软件之间的联系有一定的了解
坚持“5W”规则
明确内容与过程 “What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）” 、“Who（谁来做）”、“How（如何做）” 1）why——为什么要进行这些测试； 2) what—测试哪些方面，不同阶段的工作内容； 3) when—测试不同阶段的起止时间； 4) where—相应文档，缺陷的存放位置，测试环境等； 5) who—项目有关人员组成，安排哪些测试人员进行测试； 6) how—如何去做，使用哪些测试工具以及测试方法进行测试。
2.5 衡量一份好的测试计划书的标准
一份好的测试计划书应具备哪些特点呢？
1．它应能有效地引导整个软件测试工作正常运行，并配合编程部门，保证软件质量，按时将产品推出。 2．它所提供的方法应能使测试高效地进行，即能在较短的时间内找出尽可能多的软件缺陷。 3．它提供了明确的测试目标、测试
的策略、具体步骤及测试标准。
3．测试项目
测试项目包括所测试软件的名称及版本，需要列出所有测试单项、外部条件对测试特性的影响和软件缺陷报告的机制等，具体要点如下：
1) 功能测试。理论上测试要覆盖所有的功能项，例如，在数据库中添加、记录等，这会是一项浩大的工程，但是有利于测试的完整性。 2) 设计测试。设计测试是检验用户界面、菜单结构、窗体设计等是否合理的测试。 3) 整体测试。整体测试需要测试数据从软件中的一个模块流到另一个模块过程中的正确性。
4．它既强调测试重点，也重视测试的基本覆盖率。 5．它所制定的测试方案尽可能充分利用了公司现有的、可以提供给测试部门的人力/物力资源，而且是可行的。 6．它所列举的所有数据都必须是准确的—— 比如外部软件/硬件的兼容性所要求的数据、输入/输出数据等。 7．它对测试工作的安排有一定的灵活性，可以应付一些突然的变化情况，如当时间安排或产品出现的一些变化的时候。