​  周二的时候与一位朋友交流时，朋友向我知不知道《测试计划书》应该怎么写，我很惊讶:"网上应该有很多啊,结合自己的实际情况写一篇就好了."只是朋友很无奈的说网上很多,要么就是一成不变的模版,要么就是满幅的长篇大论,有借鉴意义,但对于写,作用不大.由于惊叹于朋友所说,抱着"负责任"的态度,搜索了一下,令人失望的是真如朋友所说.相信也会有很多的PM朋友在工作中也会遇到类似问题,毕竟我们有那么多文档要写,有鉴于此区区利用业余时间简单整理了一份《测试计划书》特此拿出来与大家分享

测试计划

一、目的

在软件程序中往往存在着许多预料不到的问题，可能会被疏漏，许多隐藏的错误只有在特定的环境下才可能暴露出来。如果不把着眼点放在尽可能查找错误这样一个基础上，这些隐藏的错误和缺陷就很难被查出来，会遗留到运行阶段中去。站在用户的角度我们希望通过软件测试暴露软件中隐藏的错误和缺陷，并进行修复，从而为用户提供好的产品；同时经过测试发现系统中的漏洞，为公司的运营以及后期维护降低成本

二、背景

根据自己的项目实际情况填写就好

三、测试摘要

测试是程序的执行过程，目的在于发现错误，一个好的测试用例在于能发现至今未发现的错误；而一个成功的测试是发现了至今未发现的错误的测试。在整个测试环节中会因为环境、人员以及需求的变更从而导致相应的风险，对于所有可以导致的风险罗列如下：

1业务不熟：测试人员对被测系统的业务流程不熟悉，体现在对需求的理解上把握不准、理解不透侧、理解错误等。

2定位效应：测试过的可靠的功能，特别是在多次回归且没有发现问题，在此后往往会认为此功能是可靠的。

3疲态：某一些功能点一直由某一位测试人员测试，经过多次回归后，测试人员对该功能点的测试显示出倦意和缺乏兴趣。

4同化效应：经过和开发的长时间接触，往往会被开发的思维逻辑所同化，渐渐丧失从用户角度出发的测试观察点。

5测试用例/数据设计不充分：某些时候由于编写测试人员的个人因素或时间的

限制等方面因素导致。

6错误或缺失测试方法：对功能点没有采用正确的测试方法，或某些测试方法被忽视，如边界测试等，导致测试不充分。

7测试用例实施不充分：测试用例由于各种原因没有完全测试，如在回归测试中。

四、测试范围

1. 功能测试

1.1基本功能模块测试

根据《开发需求说明手册》分析各个功能模块。针对各个功能模块进行功能的测试。

2 WEB功能测试

2.1链接测试

链接测试的内容：

测试所有链接是否按指示的那样确实链接到了应该链接的页面；

测试所链接的页面是否存在；

保证Web 网站上没有孤立的页面。所谓孤立页面是指没有链接指向该页面，只有知道正确的URL 地址才能访问。

链接测试可以手动进行，也可以自动进行。

链接测试必须在集成测试阶段完成，也就是说，在整个Web 网站的所有页面开发完成之后进行链接测试。

主要测试网站的链接是否正常，其中包括测试链接页面的正确性、页面是否存在、是否存在孤立页面。

2.2表单测试

表单就是一些需要在线显示和填写的表格。

表单有一些标准操作，如确认、保存、提交等。

主要测试表单的正确性和规范性，是否适合常用表单的使用习惯。

主要测试方法为：边界值测试、等价类测试，以及异常类测试。

2.3 Cookies测试

测试内容

Cookies是否能正常工作；

Cookies是否按预定的时间进行保存；

刷新对Cookies 有什么影响等。

2.4设计语言测试

测试的语言，除了HTML 的版本问题外，不同的脚本语言，例如使用Java、JavaScript、ActiveX、VBScript或Perl 等开发的应用程序也要在不同的版本上进行验证。

2.5数据库测试

数据校验

根据业务规则，需要对用户输入进行校验，则要保证这些校验功能正常工作。

一般测试数据的一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。再就是数据的安全性测试，一般采用SQL注入的方法。

3. 可用性测试

可用性/易用性方面的测试一般采用手工测试的方法进行评判。

3.1导航测试

导航测试的内容：

测试网站的导航能力是否良好，比如页面结构、导航、菜单、连接等是否良好。

常采用手工对网页进行浏览、根据一般用户的浏览习惯来进行评判。

一般此过程让最终用户参与这种测试，效果将更加明显。

导航是否直观？

Web 系统的主要部分是否可以通过主页访问？

Web系统是否需要站点地图、搜索引擎或其他的导航器帮助？

测试Web 系统的页面结构；

导航条、菜单、连接的风格是否一致？

各种提示是否准确，确保用户凭直觉就知道是否还有内容，内容在什么地方。

最好让最终用户参与导航测试，效果将更加明显。

3.2图形测试

图形测试的内容：

(1) 要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。图片尺寸要尽量地小，并且要能清楚地说明某件事情。

(2) 验证所有页面字体的风格是否一致。

(3) 背景颜色应该与字体颜色和前景颜色相搭配。

(4) 图片的大小和质量也是一个很重要的因素，一般采用JPG 或GIF 压缩。

常采用手工测试。

3.3内容测试

内容测试用来检验web网站系统提供信息的正确性、准确性和相关性。如文字标题是否与文字内容符合，是否存在不需要的文字。

常采用界面浏览的方式。

3.4整体界面测试

测试整个网站系统的页面结构设计是否符合用户需求规范，是否给用户的一个整体感。

一般常采用界面浏览的方式，最好是有最终用户的参与。

例如，当用户浏览Web 网站时，应考虑

是否感到舒适？是否凭直觉就知道要找的信息在什么地方？整个Web 应用系统的设计风格是否一致？

4.安全性测试

4.1登录验证

网站系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。

4.2缓冲区溢出

溢出攻击是通过溢出来控制计算机的指令序列，让计算机执行自己的恶意代码，是利用缓冲区溢出漏洞所进行的攻击行动。缓冲区溢出是一种非常普遍、非常危险的漏洞。

4.3日志文件

为了保证网站系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。

4.4安全漏洞（待定）

服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。

4.5跨站式脚本攻击（XSS）

跨站脚本攻击是指攻击者编写恶意脚本利用网站漏洞从用户那里恶意盗取信息。

5. 配置和兼容性测试

5.1平台测试

平台测试就是要测试兼容性问题：

同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。

因此，需要在各种操作系统下对Web 系统进行兼容性测试。

5.2浏览器测试

使用不同的浏览器对网站进行浏览测试，查看网站在不同浏览器中的兼容性问题。

浏览器是Web系统客户端最核心的软件，来自不同厂商的浏览器对JavaScript、ActiveX、plug-ins或不同的HTML 有不同的支持。

另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不能显示。不同的浏览器对安全性和设置也不一样。

5.3分辨率测试

对屏幕的分辨率进行调节来查看网站在不同分辨率下的显示效果，比如；分辨率低时界面文字显示太大，而

分辨率高时又有些文字显示时太小。

页面版式在640x400、600x800 或1024x768 的

分辨率模式下是否显示正常?

5.4 连接速率测试

用户在下载文章或演示的时候，可能会等待比较长的时间，但却不会耐心等待首页的出现。需要对链接速度进行测试。

五、测试的目标与原则

测试的目标是要以最少的时间和人力找出软件中潜在的各种错误和缺陷。如果成功地实施了测试，就能够发现软件中的错误。测试的附带收获是，它能够证明软件的功能和性能与需求说明相符。此外，实施测试收集到的测试结果数据为可靠性分析提供了依据。因此测试中需要明确的目标与原则如下：

1确保产品满足性能和效率的要求

2确保产品是健壮的和适应用户环境的

3测试的原则---Good Enough

4程序员应避免检查自己的程序。

5在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。

6充分注意测试中的群集现象。

7严格执行测试计划，排除测试的随意性。

8应当对每一个测试结果做全面检查。

9妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

六、测试提交文档

《产品错误代码说明文档》、《测试报告》、《功能测试方案（报告）》、《测试用例》、《总体测试方案》（可根据项目情况进行裁剪，不同文档需需要明确备注时间与日期）

七、测试质量目标

测试质量目标

确认者

所有的测试案例已经执行过

所有的功能测试已经执行通过

所有的重要等级为1/2的bug已经解决并已测试验证

每一部分的测试已经被负责人验证完成

重要的功能不允许有等级为1/2/3的bug

一般的功能或与最终使用者不直接联系的功能不允许有超过1/2的bug

部分轻量的功能可以有等级错误

发现错误等级的bug正在下将并接近0

在截止日内没有发现错误等级为1/2的bug

七、测试环境

1、机型（配置）

平台          机型（配置）              Ip地址         用途及说明           软件及版本        预计空间

2、软件测试环境

软件需求                  用途

3测试工具

测试工具                  用途

八、测试策略

测试人员在部署完环境，明确需求后，开始着手进行测试工作，并进行需求review、设计review、测试案例设计、执行测试。产品达到软件产品质量要求和测试要求后进行下一个测试环节，并提交相关的测试文档。

1、测试类型

测试类型             是否采用                                   说明

功能测试                采用            根据系统需求文档和设计文档，检查产品是否正确实现了功能。

流程测试                采用            按操作流程进行的测试，主要有业务流程、数据流程、逻辑流程、正反流程，检查软件在按流程操作时是否能够正确处理

边界值测试             采用            选择边界数据进行测试，确保系统功能正常，程序无异常。

容错性测试             采用            检查系统的容错能力，错误的数据输入不会对功能和系统产生非正常的影响，且程序对错误的输入有正确的提示信息

异常测试                采用              检查系统能否处理异常

启动停止测试         采用             检查每个模块能否正常启动停止、异常停止后能否正常启动

易用性测试             采用             检查系统是否易用友好

界面测试                 采用             检查界面是否美观合理

接口测试                 采用            检查系统能否与外部接口正常工作

配置测试                 采用            检查配置是否合理、配置是否正常

兼容性测试             采用            对于B/S架构的系统来说需要考虑用户端浏览器的版本。。

文挡测试                 采用           检查文档是否足够、描述是否合理

回归测试                 采用           检查程序修改后有没有引起新的错误、是否能够正常工作以及能否满足系统的需求

2测试技术

测试技术             是否采用               说明

编写测试用例        采用           在产品编码阶段编写测试用例

单元测试               采用           根据需要对相应单元进行测试

确认测试               采用           对照feature list 进行基本需求的确认，确认产品是否正确实现了功能。

验收测试               采用            对测试修复后进行验收

九、测试计划

1、测试时间进度

测试阶段          开始时间                  完成时间             测试人员            阶段完成标志

设计测试用例

通过审核

测试环境准备

部署完成

功能测试

完成指标

集成测试

完成指标

系统测试

完成指标

验收测试

完成指标

文档编写

建档备案

十、测试实施任务和时间安排

测试功能         开始时间         完成时间          测试人员          说明

可用性测试

流程测试

功能测试

安全性测试

兼容性测试

Web功能测试

界面测试

配置测试

当然这份测试计划中的内容也不是特别全，一部分自动化的测试内容没有涉及到，但只要根据相应需要测试的内容真写上就可以了。

当然关于自动化测试的内容可以通过关注公众号；PM产品之颠来获取，当然我也会持续更新。