软件测试流程11-9-27

软件测试流程

软件测试流程

目录

1、测试计划阶段 ............................................................................................................................. 2

1.2、测试计划考虑问题 .......................................................................................................... 2 1.2、测试策略 .......................................................................................................................... 3 1.3、详细测试解说 .................................................................................................................. 4

1.3.1、功能测试 ............................................................................................................... 4 1.3.2、其他非功能测试 ................................................................................................... 5 1.3.3、策略符合要求 ....................................................................................................... 6

2、测试执行阶段 ............................................................................................................................. 8

2.1、执行阶段操作 .................................................................................................................. 8

1、测试计划阶段

做测试需要做好准备工作，把做一件事需要做的准备工作做好，明确做这件事的目的，最终达成目的并验证结果是我们要做的事情。

测试计划的内容：

1、测试范围：本次测试的测试范围，如：测试软件功能范围、测试方法等 2、简单应用测试平台测试潜在的问题。 3、人力资源的分配

1.2、测试计划考虑问题

1、要充分考虑测试计划的实用性，即测试计划与实际之间的接近程度和可操作性（必须对需求有透彻的理解）。说的明确一点就是要“计划”“如何”去做“测试工作”，而不是“如何编写测试计划”。

(1) 测试内容：对一个软件来说测试计划中会明确本次测试做哪些测试？

如：系统测试：在整个系统测试中会有（界面测试、功能测试、性能测试、兼容性测试等测试）

(2)测试目的：保证产品质量是否达到预期的指标。

(3)测试标准：需要考虑本次测试需要输入哪些测试用例，bug级别定义、优先级定

义、bug管理流程定义。这个都需要在执行测试事明确。计划中应该包含这些内容。

(4)资源分配：应用测试平台，同步测试。

(5)测试风险：大多考虑到的就是项目开发延期、测试人员不足用例无法全面覆盖测

试点、时间不足用例无法全部执行、bug无法及时修改导致无法验证、测试人员技能不足导致测试进度拉长。

(6)软件测试策略一般都是分开来做相关测试方案。

2、要坚持“5W1H”的原则，明确测试内容与过程。 ◇ 明确测试的范围和内容（WHAT）； ◇ 明确测试的目的（WHY）；

◇ 明确测试的开始和结束日期（WHEN）； ◇ 明确给出测试文档存放位置（WHERE）； ◇ 明确测试人员的任务分配（WHO）； ◇ 明确指出测试的方法和测试工具（HOW）。

1.2、测试策略

对需求进行分析，列出具体的功能列表。（一般根据功能交互文档就能明确出此功能的大体功能，一层层的分下去，一直到没个功能表单。然后考虑到使用那些测试方法？工作一旦做到执行阶段，我们可以更好的根据这些功能表一点一点的覆盖。

对于一个个测试该如何进行测试？如下：

1、功能测试

1.1、功能范围（划分出各自负责的功能模块） 1.2、使用测试方法（等价类、边界值等测试方法方法） 1.3、测试标准（符合设计、需求和规范文档对该功能的描述）

2、界面测试 3、兼容性测试

1.3、详细测试解说 1.3.1、功能测试

1). 链接测试

1. 测试所有链接是否按指示的那样确实链接到了该链接的页面。（这里需要我们一个一个的点击连接测试）

2. 测试所链接的页面是否存在 （及链接是否有效，可以运用网上的死链接测试工具，进行死链接检测）

3. 保证Web应用系统上没有孤立的页面（所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问）

2). 表单测试

1. 注册、登陆、信息提交等，必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。（首先要写出测试用例，然后一个个逐一测试） 2. 检验默认值的正确性。

3. 如表单只能接受指定的某些值，测试时跳过这些字符，看系统是否会报错。

3). Cookies测试（session测试同） 1. Cookies是否起作用

2. Cookies是否按预定的时间进行保存 3. 刷新对Cookies有什么影响

4). 数据库测试

1. 数据一致性错误：主要是由于用户提交的表单信息不正确而造成的。 2. 输出错误：主要是由于网络速度或程序设计问题等引起的

1.3.2、其他非功能测试

1). 性能测试

1. Web系统响应时间 2. 超时的限制

2). 可用性测试 1. 导航是否直观

2. Web系统的主要部分是否可通过主页存取

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

4. Web应用系统导航帮助要尽可能地准确。Web应用系统的层次一旦决定，就要着手测试用户导航功能。

3). 图形测试

1. 要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间 2. Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面

3. 验证所有页面字体的风格是否一致

4. 背景颜色应该与字体颜色和前景颜色相搭配。

4). 内容测试

1. 检验Web应用系统提供信息的正确性、准确性和相关性（信息的正确性是指信息是可靠的还是误传的） 2. 整体界面测试

整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：

biodiscover.com当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信

息在什么地方？整个Web应用系统的设计风格是否一致？当然，对界面的整体测试并

不能单靠个人直觉来评定；每个人的审美观、专业角度、系统面向的行业及用户、甚 至性别与年龄等等，都是可能导致对界面作出不同评价的因素。

5). 兼容性测试（主要指浏览器）

1. IE测试（多版本至少要 版本6以上通过） 2. Firefox 3. Chrome

6). 安全性测试

1. 测试有效和无效的用户名和密码，要注意到是否大小写敏感, 是否可以不登陆而直接浏览某个页面等

2. Web应用系统是否有超时的限制，用户登陆后在一定时间内没有点击任何页面，是否需要重新登陆才能正常使用。

（补充说明出现问题，请将测试过程填写在测试报告表中）

1.3.3、策略符合要求

BUG管理流程

1、 由测试人员发现bug后，在scrum中新建bug。

2、 测试人员直接把bug指派到相应的管理者（一般是由测试组长、项目经理等人参与

bug分配）（打开）或者是在管理者那里就直接关闭 bug状态就直接改为关闭 3、 Bug经过成员领取到各位开发者手中，测试组长能够将该bug转移给相应的开发人

员。Bug状态不改变。状态改为 《已分配》。

4、 测试人员在做验证时，主要关注bug状态为 已修复的bug 如果bug任然存在或者

导致了新的bug。那么就《重新打开》然后新建新的bug。如果bug修复未修复，那么就重打开

5、 Bug修复验证完毕，就直接关闭。

缺陷等级划分

2、测试执行阶段

手工测试；在合适的测试环境上，按照测试用例的条件、步骤要求，准备测试数据：对系统进行操作，比较实际结果和测试用例的所描述的期望结果，以确定系统是否正常运行或正常表现。

对手工测试的管理相对要复杂得多，在整个测 试执行阶段中，管理上会碰到一系列问题，主要有：

• 如何确保测试环境满足测试用例所描述的要求? • 如何保证每个测试人员清楚自己的测试任务? • 如何保证每个测试用倒得到百分之百的执行?

• 如何保证所报告的bug正确、描述清楚、没有漏掉信息? • 如何跟踪bug处理的进度，严重的bug及时得到解决?

2.1、执行阶段操作

第一轮系统测试我们会执行我们所编写的所有测试用例，做好测试结果的记录，发现缺陷了提交缺陷报告。当第一轮测试结束后，我们把所有的bug单提交给开发人员，由他们进行修改。

在他们修复bug期间，我们会对第一轮系统测试做一个测试评估，出一个测试报告。还要根据实际情况，对我们写的测试用例进行修改和增加。开发改bug结束，提交一个新的版本给我们，我们重新搭建测试环境开始第二轮系统测试。首先是回归我们提交的缺陷报告，

然后会在用例中挑选一些优先级别比较高的用例来进行测试，发现问 题了继续提交缺陷报告，只到缺陷率低于用户要求了，我们就进行最后一轮的回归测试，结束系统测试。具体测试轮次是根据版本质量和项目复杂度而决定的。

（注：测试完成以后提交一份测试报告，说明测试内容及结果。）