1.0 软件的测试计划
1.1 概念：
是描述测试目的、范围、方法和软件测试的重点等内容的文档。软件测试计划作为软件项目计划的子计划，在项目启动初期是必须规划的。
软件测试计划是指导测试过程的纲领性文件，软件测试计划需要描述所有要完成的测试工作，包括测试项目的背景、测试目标、测试范围、测试方式、所需资源、进度安排，测试组织以及与测试有关的风险等方面内容。
1.2 原则
1.制定测试计划应该尽早开始。即使还没掌握所有细节，也可以先从整体计划开始，然后逐步细化来完成大量的工作。今早地开始制定测试计划，可以是我们大致了解所需的资源，并且在项目的其他方面占用该资源进行测试。
2.保持测试计划的灵活性。制定测试计划时应该考虑要能很容易的添加测试用例、测试数据等，测试计划本身应该也是可变的，但是要受变更控制。
3.保持测试计划简洁易读。测试计划没有必要很大、很复杂、实际上测试计划越简洁易读，它越有针对性。
4.争取多方面来评审测试计划。多方面人员的评审和评价会对获得便于理解的测试计划很有帮助，测试计划应该像项目其他交付结果一样受控于质量控制。
5.计算测试计划的投入。通常，制定测试计划应该占整个测试工作大约1/5的工作量，测试计划做得越好，执行测试用例就越容易。
1.3 如何制定软件测试计划
1.认真做好测试资料的收集整理工作。
A.软件的类别及构成是指软件的类别余额用途（不同的软件有不同的考虑重点）、软件的结构、软件所支持的平台、软件的主要构成部分、各自功能及各部分之间的联系、每一构成部分所使用的计算机语言等信息。
B.软件的用户界面，用户界面风格是类似于Windows软件，还是类似网页类软件。而且，测试人员还需要掌握用户界面各部分的功能、联系、以及界面中组成部分的特性、操作特点等。
C.在所测试的软件涉及第三方软件的情况下，必须对这个第三方软件的功能及它与所要测试的软件之间的联系有一定的了解。
2.明确测试的目标，增加测试计划的实用性。
测试的目标必须是明确的，可以量化和度量的，而不是模棱两可的宏观描述。另外，测试目标应该相对集中，要避免罗列一系列轻重不分的目标。根据对用户需求文档和设计规格文档的分析，确定被测软件的质量要求和测试需求需要达到的目标。
3.坚持‘5W’原则，明确内容和过程。
| 5W | 解释 | 目的 |
|---|---|---|
| what | 做什么 | 明确测试的范围和内容 |
| why | 为什么做 | 可以帮助测试团队了解测试的目的 |
| when | 何时做 | 确定测试的开始和结束日期 |
| where | 在哪里 | 给出测试文档和软件存放位置 |
| how | 如何做 | 指出测试方法和工具 |
4.采用评审和更新机制，保证测试计划满足实际需求。
测试计划写完后，如果测试不经过评审就发给测试团队，其内容很有可能不准确或有所遗漏，甚至造成软件需求变更引起的测试范围增减测试体现在其中，舞蹈测试执行人员。
1.4 面对的问题
1.与开发的意见不一致
2.缺少测试用具
3.培训不够
4.管理部门缺少对测试工作的理解和支持
5.缺乏用户的参与
6.测试时间不足
7.过分依赖测试人员
8.测试人员处于进退两难的状态
9.不得不说‘不’
1.5 衡量测试计划的标准
一个好的测试计划应具备那些特点：
1.测试计划应能有效的引导整个软件工作正常运行，并能使测试部门配合开发部门保证软件质量，按时将产品推出。
2.测试级阿虎所提供的方法应能使测试高效的运行，即能在较短的时间内找出尽可能多的软件缺陷。
3.测试计划应该能够提供明确的测试目标、测试策略、具体步骤以及测试标准。
4.测试计划既要强调测试重点，也要重视测试的基本覆盖率。
5.测试计划所制定的测试方案应尽可能充分利用公司提供给测试部门的人力物力资源。而且应是可行的。
6.测试计划所列举的数据必须是准确的。比如外部软件、硬件、兼容性要求的数据，输入、输出数据等。
7.测试计划对测试工作安排应有一定的灵活性，使测试工作可以应付一些突然的变化情况，比如需求变更。
1.6 制定测试计划
1.6.1 首页
项目名称
测试计划
公司名称
日期
1.6.2 文档修改记录
| 版本 | 版本描述 | 作者 | 日期 | 备注 |
|---|---|---|---|---|
| V1.0 | 初始版本 | 张三 | 2021年7月 | 修改了哪些内容 |
| V2.0 |
1.6.3 引言
1.6.3.1 项目背景
1.说明待开发的软件系统的名称
2.项目的委托单位、开发单位、协作单位、用户单位
3.项目背景：开发的意图、应用目标、作用范围以及其他向读者说明的有关该软件开发的背景资料。
4.保密说明：本项为可选项，一般软件公司都会要求对软件开发的设计文档进行保密，不允许复制、使用和扩散到公司之外的范围，如果需要强调，需要相关的保密说明。
5.版权说明：本项为可选项。若有必要，才要做有关的描述。
1.6.3.2 项目目标
通过本次测试，除了发现可能存在的系统缺陷外，同时建立一套较完整的测试规范和一套较完整的测试用例库。
1.6.3.3 编写的目的
从总体上明确我们要测试的软件或系统的功能木块和实现方法，从而在后期测试活动中更好的把握测试范围，制定适当的测试策略和测试方法。并为测试过程中测试人员和后期实施人员提供工作指导。
本文档的预期读者包括：项目经理、系统设计人员、开发人员、测试。
1.6.3.4 专业术语
提示：对文档中的专业术语进行结束说明：
| 序号 | 简称 | 术语名称 |
|---|---|---|
| 1 | CEO | 首席执行官 |
| 2 | CFO | 首席财务官 |
| 3 | CTO | 首席技术官 |
| 4 | COO | 首席运行官 |
| 5 | HR | 人力资源 |
| 6 | KPI | 关键绩效指标法 |
| 7 | OKI | 目标与关键成果法 |
| 8 | JD | 工作说明书或工作规范 |
| 9 | HC | 招聘名额 |
| 10 | Delay | 项目延期 |
| 11 | Deadline | 某个项目或任务的最后期限 |
| 12 | UV | 指访问某个站点或点击某条新闻的不同IP地址的人数 |
| 13 | PV | 页面浏览量、点击量 |
| 14 | LBS | 基于位置的服务 |
| 15 | PRD | 需求文档 |
| 1 6 | BRD | 商业需求文档 |
| 17 | MRD | 市场需求文档 |
| 18 | UED | 用户体验设计 通常他们的产出是设计稿 |
| 19 | test requirment | 测试需求 |
| 20 | test plan | 测试计划 |
| 21 | test case | 测试用例 |
| 22 | test reports | 测试报告 |
| 23 | development environment | 开发环境 |
| 24 | test enxironment | 测试环境 |
| 25 | preview environment | 预发环境 |
| 26 | online environment | 线上环境、正式环境、生产环境 |
| 27 | TL | 团队管理者 |
16.3.5 参考资料
提示：列出所有文本文档所使用的参考资料：
1.技术可行性报告
2.软件开发计划书（项目计划书）
3.需求分析报告
4.与本项目有关的已发表的文件或资料
5.本文件中各处引用的文件、资料，所采用的的软件开发标准和规范
注意：必须列出文件、资料的作者、标题、编号、发表日期和出版单位，以及说明这些文件的来源，若某些文件有保密要求，则要说明其保密级别。
1.6.4 测试准备
1.6.4.1测试环境准备
提示：如服务器、客户端软、硬件要求及网络环境要求等。
1.服务器
| 硬件配置要求 | |
|---|---|
| CPU | |
| 内存 | |
| 磁盘空间 |
| 软件配置要求 | |
|---|---|
| 操作系统 | Windows、Linus、Unix、mac |
| 数据库 | mysql、sqlserver、Oracle |
| 服务 | |
| 项目文件包 | 开发人员编写好的源代码文件包 |
2.网络 WiFi、4G、3G、弱网等
1.6.4.2 测试人员职责
| 角色 | 职责 |
|---|---|
| 测试经理 | 1.组织测试培训 2.指定测试规范 |
| 项目测试负责人 | 1.组织测试环境搭建 2.指定测试计划 3.控制测试进度 4.与相关部门、人员沟通 5.分析测试结果 6.编写测试报告 |
| 测试人员 | 1.编写测试需求 2.设计测试用例 3.准备测试数据4.按计划执行测试用例 5.记录、报告所发现的缺陷 6.推动开发修复和解决缺陷 |
1.6.4.3 测试进度表
设定固定日期的测试进度表
| 测试任务 | 日期 |
|---|---|
| 测试计划编写 | 2021.4.2-2021.5.2 |
| 测试用例编写 | |
| 第一阶段测试 | |
| 第二阶段测试 | |
| 第三阶段测试 | |
| 采用相对日期的测试进度表 |
| 测试任务 | 开始日期 | 期限 |
|---|---|---|
| 测试计划完成 | 需求说明书完成且评审通过之后三天 | 3天 |
| 测试案例完成 | 测试计划完成 | 2周 |
| 第一阶段测试通过 | 开发编码完成，且开发自测完成 | 3周 |
| 第二阶段测试通过 | 第一轮测试完成 | 2周 |
| 第三阶段测试通过 | 第二轮测试完成 | 2天 |
测试人员任务分配表
| 测试人员 | 测试人员任务 |
|---|---|
| A | 功能测试 |
| B | 兼容性测试 |
| C | 性能测试 |
| D | 接口测试 |
| E | 自动化测试 |
测试任务安排表
1.6.5 测试策略
说明本次测试中所采用的何种方法和策略（例如：黑盒测试、白盒测试）
本次测试活动涉及到界面测试、易用性测试、兼容性测试、业务测试和压力测试等
1.6.6 测试范围及测试重点
1.6.6.1 测试范围
注明本次测试活动中涉及的木块名称及子模块名称
| 系统功能模块 | 子功能 | 说明 |
|---|---|---|
| 客户端程序 | 系统管理 | 用户登录、注销 |
| 待办事宜 | 列表、查看 | |
| 文件管理 | 列表、查看、查询、文件下载 | |
| 通知公告 | 列表、查看、查询、文件下载 | |
| 日程管理 | 列表、查看、查询、文件下载 | |
| 通讯录 | 列表、查看、查询 | |
| 接口端 | 用户登录验证接口 | 提取用户账号和密码等进行验证 |
| 待办事宜提取接口 | 根据条件提取待办事宜 |
1.6.6.2 测试重点：
针对不同的项目要求侧重点不同而设计
| 分类 | 测试项 | 重要性 | 通过标准 |
|---|---|---|---|
| 登陆 | 用户登陆验证接口 | 高 | 1.提取的数据内容和数量正确无误 2.依据用户需求说明书的要求显示数据。 |
| 登陆 | 高 | 1.依据用户需求说明书，所有功能实现正确并符合要求 2.界面美观、布局合理、字体大小样式符合设计要求 |
1.6.6.3 不测试的模块
| 模块 | 说明 |
|---|---|
| XX子功能 | 不测试XX子功能，但是要测试XXX是否正确 |
