软件测试流程规范最全

软件测试流程规范

整体的流程图

1.详细的流程执行

1.1 计划与设计阶段

整体流程图

立项会议

· 项目可行性分析

· 确定项目经理

· 确定测试组长

· 项目正式立项

· 测试组长确定

需求评审

· 需求规格说明书

·

· 明确需求

· 消除歧义

· 会议讨论并确认

· 需求明确无异议

测试工作

启动

· 需求规格说明书

· 项目开发计划

· 测试预通知

· 组建测试小组

· 召开测试情动会

· 测试小组成立

· 开发方与测试方目

测试设计

阶段

· 需求规格说明书

· 项目开发计划

· 概要设计、详细

设计

· 其他相关文档

· 设计测试计划

· 设计测试用例

· 测试计划

设计内容

评审

· 测试计划

· 测试用例集

· 评审测试计划

· 评审测试用例集

1.1.1 立项会议

由高层主管立项会议，会议主要对项目的可行性进行分析，并且确定项目经理及项目测试组长。

1.1.2 需求评审

注：1．需求定义基本完成，此时应在评审会议召开之前发给测试团队，预留时间给测试相关人员熟悉、理解。

2．测试部参与人员由测试部经理指定，主要由测试组长、测试设计等人员组成（还应

包括配置管理人员、质量保证人员）。

1.1.3 测试工作启动

注：在正式测试任务下达前，开发团队应在项目（产品）开发计划完成后及时向测试团队下达预通知，告之较为确切的测试日期，提供当前最新的相关资料。部门经理和测试组长组建测试小组，并视具体情况决定是否需要调整人力、时间安排、测试环境等其它资源。测试小组成员可预先熟悉必要的项目（产品）资料。

1.1.4 测试设计阶段

1.1.4.1 设计测试计划

注：针对需求分析文档和项目开发计划文档测试完成后，测试组需要编写测试计划文档、制定测试测略及预估测试过程中的风险，并设计出合理的规避风险的策略，为后续的测试工作提供直接的指导。

1.1.4.2 设计测试用例

注：在需求分析文档确立基线以后，测试组需要针对项目的测试需求编写测试用例，在实际的测试中，测试用例将是唯一实施标准。

1.1.4.

2.1设计测试用例的常用方法

a．等价划分法

有效等价类:是指对于程序的规格说明来说是合理的有意义的输入数据构成的集合利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能

无效等价类:与有效等价类的定义恰巧相反

b．边界值法：

?边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种

情况下，其测试用例来自等价类的边界。

?通常情况下，软件测试所包含的边界检验有几种类型：数字、字符、位置、重量、大小、速度、方位、尺寸、空间等。

?相应地，以上类型的边界值应该在：最大/最小、首位/末位、上/下、最快/最慢、最高/最低、最短/最长、空/满等情况下。

?边界值分析的基本思想是使用在最小值、略高于最小值、正常值、略低于最大值和最大值处取输入变量值，记为：min、min+、nom、

max-、max考虑到健壮性测试，还可以加一个略大于最大值max+，

以及一个略小于最小值min-的值。

举例说明：例如要求0 < X<5,在编写用例时需考虑到以下几种

情况：

?x=0的情况

?x=5的情况

?x=-1的情况

?输入一个X大于5的值，例如输入X=6

c．错误推断法

基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性

的设计测试用例的方法。

思路：分析程序中最易出错的场景和情况，在此基础上有针对性的设

计测试用例，需要完成的前提条件如下：

●深度熟悉被测系统的业务、需求。

●对被测系统或类似系统之前的缺陷分布情况进行过系统的分析。

包括功能缺陷，数据缺陷，接口缺陷和界面缺陷等等。

举例说明：

聊天窗口功能

?输入特殊字符（全角，半角）后，窗口是否能够正常显示

?输入空格，是否能够过滤，是否会算入长度计算

?输入html字符

?输入脚本语言函数

?在需要密码验证，或者需要二次输入确认的地方，通过复制粘贴第一次的输入内容是否能够通过

1.1.4.

2.2接口测试的方法

?测试接口文档。

?根据接口文档编写测试用例（用例编写方法完全可以按照黑盒测试的用例编写规则来编写，如：边界值、等价划分等等设计方法）。

?和数据库中执行测试，查看接口返回的接口数据是否正确，主要检查返回的接口是否和接口文档中定义的一样，还有要检查返回的数据是否的保持一致。

?手工检测：对于CSRF、越权访问、文件上传、修改密码等漏洞，难以实现自动化检测的效果，这是因为这些漏洞涉及系统逻辑或业务逻辑，有时候还需要人机交互参与页面流程，因此这类漏洞的检测更多的需要依靠手动测试完成。手工检测网站URL、后台登陆是否具有SQL注入

◆举例说明：关于上传：

?上传文件是否有格式限制,是否可以上传exe文件；

?上传文件是否有大小限制,上传太大的文件是否导致异常错误,上传0K的文件是否会导致异常错误,上传并不存在的文件是否会导致异常错误；

?通过修改扩展名的方式是否可以绕过格式限制，是否可以通过压包方式绕过格式限制；

?是否有上传空间的限制,是否可以超过空间所限制的大小,如将超过空间的大文件拆分上传是否会出现异常错误。

?上传文件大小大于本地剩余空间大小，是否会出现异常错误。

?关于上传是否成功的判断。上传过程中，中断。程序是否判断上传是否成功。?对于文件名中带有中文字符，特殊字符等的文件上传。

1.1.4.

2.5兼容性测试的方法

?操作系统/平台兼容

?不同浏览器的兼容

?不同分辨率间的兼容

?风格统一

?重要的和常用的元素优先布局，且放置在醒目的位置

?布局合理紧凑，疏密有致

?明显区分只读区域与可编辑区域

?使用红色的符号’*'来标记必填项

?语句流畅，表述清晰，没有错别字

?字段名称通俗易懂、尽量使用专业术语

1.1.4.

2.5 易用性测试的方法

?易理解

?易学

?易操作

?吸引性

1.1.4.

2.6 APP兼容性测试

?分辨率：现在市场上分辨率是的各种各样的什么的分辨率都有了，所以需要在app在不同的分辨率设备上进行测试，显示UI的效果怎么样。

?系统：Android系统在不断升级，就会产生不同系统版本，对系统版本是不断进行兼容来对来符合的系统的版本。而在市场上开发了不同的定

制的版本，也需要进行兼容。

?机型：现在所涉及到厂商生产的出来的机器较多，所以需要使用不同厂商的不同分辨率来进行适配app的运行的情况

?语言：现在的很多的app已经支持较多的语言的，所以需要对语言方面进行测试，是app显示的语言国际化显示的效果

1.1.4.

2.7 测试用例的维护

存在以下几种情况，需对测试用例进行更新：

?先前的测试用例设计不全面或不准确

?部分严重的软件错误未在测试用例中覆盖

?新的版本有新功能的需求或改动

?编写的测试用例不规范或者语句错误

?旧的测试用例不再适用

1.1.4.3 设计内容评审

注：测试计划及测试用例的设计工作完成后，需通知项目组相关成员召开评审会议。在这之前需要将待评审的内容发给相关人员熟悉和理解。

1.2 实施测试阶段整体流程图

1.2.1 测试交接

1.2.2 实施测试

1.2.2.1 实施测试

注:实施测试用例将花费测试组大部分时间，这些工作都是建立在前期很多计划工作的基础上。