软件测试规范.docx
《软件测试规范.docx》由会员分享，可在线阅读，更多相关《软件测试规范.docx（11页珍藏版）》请在冰豆网上搜索。
软件测试规范
软件测试方法
1编写目的
本文档是测试组的日常工作规范，主要包括测试中提交问题、问题处理的规范，以指导测试人员按照正确的Bug提交流程、Bug书写格式、Bug问题处理来保证测试工作的有效进行。
2测试原则
判断bug的原则
1.软件未达到产品规格说明书（需求）标明的功能。
2.软件功能超出规格说明书指明的范围。
3.软件未达到规格说明书虽未指出但应达到的目标（隐含需求）。
4.软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
需要注意的是，测试人员报告Bug时，应当保证Bug是可以重现的。
对于有时不可重现的Bug，应当反复测试，直到最终确定Bug的发生场景为止。
描述bug的原则
1.简洁：
只解释事实和演示、描述Bug必需的细节；
2.单一：
每一个记录中针对一个Bug；
3.清晰：
要清楚地描述出Bug的发生场景，包括前置条件和操作的详细步骤；
4.再现：
按照预定步骤可以重现相同状况；
5.在报告Bug时只描述事实，不做评价；
6.必要的时候可以添加注释（remarks）；
7.可以上传屏幕抓图和其他附件。
测试流程
测试bug的方法
单元测试
Ø阶段目标：
检查各模块内部可能存在的各种缺陷，验证设计的模块的功能是否基本实现。
Ø测试环境：
开发环境
Ø输入配置：
《单元测试计划》、源代码、《软件需求规格说明书》、《设计说明书》、《测试用例》。
Ø输出配置：
《BUG一览表》。
Ø准备就绪准则：
1）编码完成、经过静态审查、评审；
2）输入配置均经过评审；
3）测试环境、测试程序、测试数据、测试工具等经过确认。
Ø对于测试计划、测试用例，准备使用前通过同行评审。
Ø当软件需求、软件设计或代码更改时，适当更改测试计划、测试用例，并在各有关测试类型中适当进行回归测试。
Ø主要任务：
1）进行白盒测试、可辅以黑盒测试，语句覆盖应达到100%；
2）局部数据结构测试（对数据类型、长度、变量初始化测试；检查相关全局变量）；
3）重要路径测试（对重要分支/条件、控制流程进行测试、检查分支的判断条件、计算方法等）；
4）边界测试（输入、输出数据的最大值、最小值，数据流判断条件的比较值、循环的最大次数、列表的最大长度等都属于边界值，对等于、大于、小于边界值的情况都要进行测试）；
5）错误处理测试（要求能预见各种可能的出错情况，并设置适当的出错处理，提示的错误应与实际相符，出错处理应在系统干预之前）；
6）运行时间测试（如果对模块运行时间有要求，应进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素，提高软件性能）。
Ø测试通过准则:
1）完成了上述主要任务；
2）程序中所有的逻辑路径至少进行过一次测试；
3）对于各模块的输入和输出可以进行，程序的主干路径畅通；
4）模块中设置了错误出口，运行中不至于崩溃或死循环；
5）用户界面不完美但能够工作；
6）各模块的测试用例至少执行了一遍；
7）修正了80%以上的缺陷，且未遗留1、2级缺陷。
集成测试
Ø阶段目标：
发现并排除各模块连接中可能出现的问题，验证软件的主要功能是否基本实现。
Ø测试环境：
开发环境
Ø输入配置：
被测软件、《集成测试计划》、《需求规格说明书》、《设计说明书》、、《测试用例》及其它相关文档。
Ø输出配置：
《BUG一览表》
Ø准备就绪准则：
1）单元测试通过评审，软件组装完毕；
2）输入配置均经过评审；
3）测试环境、测试程序、测试数据、测试工具等经过确认
Ø对于测试计划、测试用例，准备使用前通过同行评审
Ø当软件需求、软件设计或代码更改时，适当更改测试计划、测试用例，并在各有关测试类型中适当进行回归测试
Ø主要任务：
1）连接各个模块时，验证穿越模块接口的数据是否会丢失；
2）一个模块的功能是否会对另一模块的功能产生不利影响；
3）各个子功能组合起来，能否达到预期要求的父功能；
4）全局数据结构是否合理；
5）单个模块的误差是否会累积放大到不可接受的程度
Ø测试通过准则：
1）完成了上述主要任务；
2）模块组装的顺序符合设计要求；
3）模块之间的数据传输可以进行；
4）组装后软件的主要功能可以正常启动和退出；
5）用户界面不完美但能够工作；
6）有关模块接口的测试用例至少执行了一遍；
7）修正了3级缺陷80%以上、4级缺陷60%以上，且未遗留1、2级缺陷。
系统测试
系统测试采用黑盒测试的策略对整合版本进行系统测试。
对系统的功能性（功能实现是否正确；是否满足需求、设计）、安全性（身份鉴别、访问控制、日志管理、数据保密性、数据备份与恢复）、可靠性（容错性、数据保护、系统运行稳定性）、易用性（易理解性、易学性、易操作性）、效率（查询效率、统计效率）等方面进行测试。
Ø安全性：
1）身份标识和鉴别功能；
2）登录失败处理功能，系统对登录失败用户提供错误提示信息；
3）正常访问控制和处理能力，系统可以对不同的用户配置不同的操作权限和数据访问权限；
4）日志管理功能，系统具有日志查询和归档功能；
5）日志内容完整性，日志内容基本完整，包括操作人员、操作类型、操作内容、操作时间等信息；
6）数据保密性，数据在传输过程中，用户名和密码采用了加密措施；
7）数据存储保密性，系统的数据采用何种加密措施，实现实时存储保密性；
8）数据的备份与恢复，提供专用数据备份与恢复手段，数据备份的周期时间。
Ø可靠性测试：
1）测试系统是否可以屏蔽用户的误操作；对错误有正确提示；
2）测试系统输入错误数据时，系统是否不会崩溃、异常退出或丢失数据；
3）测试系统有错误操作时，系统是否不崩溃、异常退出或丢失数；
4）测试系统，通过输入的不同（如数据格式或长度等符合、不符合软件设定的要求），验证系统人机接口有效性检验功能是否正确。
Ø易用性测试：
1）测试系统的用户界面显示信息是否正确。
2）测试系统的用户界面显示信息是否利于用户理解。
3）测试系统的用户界面是否直观清楚。
4）测试系统的用户界面是否易用户于浏览。
5）测试系统提示的格式是否一致。
6）测试系统的菜单的格式是否一致。
7）测试系统帮助的格式是否一致。
8）测试系统提示、菜单、帮助中的术语是否一致。
9）测试系统输入界面和输出界面在外观、布局、交互方式上是否一致。
10）测试系统功能类似的相关界面是否在在外观、布局、交互方式上是否一致。
11）测试系统多个连续界面依次出现的情况下，界面的外观、操作方式是否一致。
12）测试系统是否易用操作。
13）测试系统的操作是否有快捷键。
14）测试系统是否有向导或操作引导。
15）测试系统是否有操作提示信息
Ø覆盖性测试：
1）必填项验证。
2）是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口使用，并适当地显示。
3）字母数字数据项是否能够正确回显，并输入到系统中。
4）图形模式的数据项（如滚动条）是否正常工作。
5）是否能够识别非法数据。
6）文字用语的一致性：
检查菜单、界面按钮或者Label等、ToolTip、窗口标题；（比如选项设置，在主界面的有按钮可以进入选项设置对话框，或者菜单中有菜单项可进入选项设置对话框中，那么，按钮、菜单、对话框的标题都应该统一用词，如用“选项”或者“设置”，而不能又用“选项”，又用“设置”，或者还有其他的的用词。
）
7）有依赖关系的控件，比如（几个选项供选择（CheckBox或者RadioBox），每个选项下面都有独立的设置（其他的控件：
Edit、ComboBox、CheckBox等），那么当所属的选项没有选中时，其下面的控件应该是Disable的，相反为Enable。
8）类型判断：
整型、浮点型的数据输入框中，不允许输入非表示数据的其他字符串（如：
abcd或者其他字符等）；
9）大小判断：
数据类型的数据如有大小范围限制的，要对输入的大小进行判断（如：
表示月份的输入框中，只能允许输入1－12的数字。
10）长度判断：
如果是程序处理的字符串有长度限制，但是输入框中没有对输入的数据长度进行限制，将有可能会造成程序错误，或者处理后的结果和输入的不相符合。
11）正确性判断：
表示路径的或者文件名全路径的输入框，要对输入的路径是否为有效的路径进行判断，如：
输入aaaa或者C:
\\//等为不正确的输入。
12）相关性检查：
删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。
检查按钮的功能是否正确如新建、编辑、删除、关闭、返回、保存、导入等功能是否正确。
数据相关性：
下来列表默认值检查，下来列表值检查，如果某个列表的数据项依赖于其他模块中的数据，同样需要检查，比如，某个数据如果被禁用了，可能在引用该数据项的列表中不可见。
13）检查信息的完整性：
在查看信息和更新信息时,查看所填写的信息是不是全部更新,更新信息和添加信息是否一致。
14）信息重复：
在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理。
15）检查添加和修改是否一致：
检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型。
16）重复提交表单：
一条已经成功提交的纪录，返回后再提交，看看系统是否做了处理。
对于Web系统检查多次使用返回键的情况 在有返回键的地方,返回到原来页面,重复多次，看会否出错。
17）搜索检查：
有搜索功能的地方输入系统存在和不存在的内容,看搜索结果是否正确.如果可以输入多个搜索条件,可以同时添加合理和不合理的条件,看系统处理是否正确。
18）上传下载文件检查：
上传下载文件的功能是否实现，上传文件是否能打开。
对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。
下载文件能否打开或者保存，下载的文件是否有格式要求，如需要特殊工具才可以打开等。
19）必填项检查：
应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加“*”；对必填项提示返回后，焦点是否会自动定位到必填项。
20）用户检查：
任何一个系统，都有各类不同的用户，同样具有一个或多个管理员用户，检查各个管理员之间是否可以相互管理，编辑、删除管理员用户。
同时，对于一般用户，尝试删除，并重建同名的用户，检查该用户其它信息是否重现。
同样，提供注销功能的系统，此用户再次注册时，是否作为一个新的用户。
21）系统数据检查：
这是功能测试最重要的，如果系统数据计算不正确，那么功能测试肯定是通不过的。
数据检查根据不同的系统，方法不同。
对于业务管理平台，数据随业务过程、状态的变化保持正确，不能因为某个过程出现垃圾数据，也不能因为某个过程而丢失数据。
22）确认提示检查：
系统中的更新、删除操作，是否提示用户确认更新或删除，操作是否可以回退（即是否可以选择取消操作），提示信息是否准确。
解决bug的流程
工具：
Bugfree
Bugfree简介
BugFree基于PHP和MySQL开发，是免费且开发源代码的缺陷管理系统。
服务器端在Linux和Windows平台上都可以运行；客户端无需安装任何软件，通过IE，FireFox等浏览器就可以自由使用。
登录地址
http:
//192.168.1.200:
8080/Bugfree/site/login
Bug的等级定义
将bug严重等级划分为五等级
1级bug——严重错误，包括：
1. 由于程序所引起的死机,非法退出
2. 死循环
3. 导致数据库发生死锁
4. 数据通讯错误
2级bug——功能错误，包括：
1. 功能不符
2. 数据流错误
3. 程序接口错误
4. 轻微的数值计算错误
3级bug——普通错误，包括：
1. 界面错误
2. 打印内容、格式错误
3. 简单的输入限制未放在前台进行控制
4. 相关错误提示不合理或未予提示
4级bug——较小错误，包括：
1. 显示格式不规范
2. 长时间操作未给用户进度提示
3. 提示窗口文字未采用行业术语
4. 可输入区域和只读区域没有明显的区分标志
5. 系统处理未优化
5级bug——测试建议
Bug的三种状态
状态
说明
Active（活动）
Bug的初始状态。
任何新建的Bug状态都是Active。
可以通过编辑修改Bug的内容，并指派给合适的人员解决。
Resolved（已解决）
解决Bug之后的状态。
Closed（已关闭）
已修复Bug在验证无误之后关闭，该Bug处理完毕。
如果没有真正解决或者重新复现，可以重新激活，Bug状态重新变为Active。
Bug的七种解决方案
类型
解决方案
详细说明
三种无效的Bug
ByDesign
设计需求就是这么设计的
Duplicate
这个问题别人已经发现
NotRepro
无法复现的问题
四种有效的Bug
Fixed
问题被修复
External
外部原因（比如浏览器、操作系统、其他第三方软件）造成的问题
Postponed
发现的太晚了，下一个版本讨论是否解决
Won’tFix
是个问题，但是不值得修复
Bug的生命周期
新建的Bug处于Active状态，可以通过编辑指派给合适的解决者。
解决Bug之后，Bug状态变为Resolved，并自动指派给创建者。
创建者验证Bug。
如果未修复，再重新激活，Bug状态重新变为Active；如果已经修复则可以关闭，Bug状态变为Closed，Bug生命周期结束。
已经Closed的Bug如果重新复现，也可以直接激活。
Bugfree的书写规范
1、标题：
明确标明bug所在模块，并简要描述bug的影响以及表现形式。
2、复现步骤：
详细描述bug的复现步骤以及影响，并将重要前台界面的显示情况截图。
3、开发人员修改完毕之后要将修改后的效果等相关信息在“注释”中描述清晰。
升级会员 