软件测试系列（4）-测试执行过程

拿到软件之后，要做的事：

一、查看软件是否完整

软件的组成：程序文档 数据

程序（安装文件压缩文件）是必须有的，没有程序，那测试什么。还要注意程序的版本号是否与文档的描述一致。

文档应该有较为齐全的文档（用户需求规格说明书、用户（操作）手册、开发需求、设计文档、数据字典……）这些文档是我们进行测试的依据，是我们评判软件是否满足用户需求的根据。

数据，是指可供还原的数据库文件（数据库文件的类型ms sql mdf bak oracle物理备份（数据文件dbf控制文件ctl缺一不可） 逻辑备份exp imp命令XXX.dmp）

但是不是所有的软件都有数据库，有些会自动配置数据库和程序

二、明确测试目的和目标

做什么类型的测试

工作内容有哪些：测试组长指派

功能性测试：需求、计划、用例、缺陷

只编写需求文档的编写：一定要细化需求文档

只编写测试用例：用例的完整，编写步骤详细，风格的一致（自动化的覆盖）

只执行已有测试用例：严格执行，“偷师”模仿公司中的文档的风格

思考：执行已有用例的次数，即回归测试的次数

哪些模块适合做自动化功能测试，在软件的多个版本中都变化不大或者没有变化

回归缺陷报告：“偷师”模仿公司中的文档的风格，注意问题的重现

三、搭建测试环境，安装软件

按照文档上的所标注的软件的推荐和最低配置要求来进行测试环境（硬件和软件）的搭建，并按照文档上的安装章节或安装文档来安装软件。

测试环境一定要达到所要求的配置，特别是在性能测试中，如果当前环境超过推荐要求，必须与委托方、客户、开发组沟通

最好是真实环境

如果没有相关文档，则测试环境的选择需要具有普遍性和一般性。如操作系统使用较多的是windows，那么测试环境中的操作系统应该选择windows操作系统。

四、熟悉需求或用户手册（看文档）

·总览文档，有哪些功能模块

·细读文档（在允许的情况下，结合软件操作），整个软件的操作流程

·在文档上标识出编写需求时会被用到的约束或者限制条件

五、熟悉整个软件的“数据流”

为了准备相关模块的测试数据

为了测试删除模块，必须通过其他的模块添加数据

测试时比如修改，删除的对象最好是自己添加的新数据，尽量不要用已有的数据

比如：需求中规定用户名的长度最少4位，有可能在列表中发现原来的数据中有“aaa”用户名，这并不表示这个一个bug，需要自己添加才能确定是否为错误

图片也有这种情况

六、编写测试计划和测试需求

1、测试计划

一般一个软件的测试不是由一个人完成的，会分成测试组长和测试组员。这时测试组长负责编写测试计划，测试组员负责编写测试需求。

测试计划是对整个测试过程做一个计划，为什么测试，测试什么，在哪里进行测试，测试时使用什么方法，在什么时间由谁做什么。

（即5W1H原则，why为什么对软件进行这些测试，what测试什么，when测试的不同阶段的起止时间，where在哪里进行测试即测试环境who由谁进行测试how怎样进行测试即使用的方法。）

目的：1、使领导能够对整个测试过程有一个直观了解，便于资源（人+物）的分配

2、能够让测试人员对于自己在什么时间做什么有一个了解

3、也能够让其他人员了解测试人员的工作以便进行一些配合工作。

2、测试需求

测试需求即找到待测功能点的约束或者限制条件，这样能够对需要测试的地方一目了然，不会有遗漏等，有利于编写测试用例。

1）细分待测软件的功能模块，细分至按钮或输入框等

依据：软件的菜单栏、文档中的系统结构图或功能模块图、uml

理由：只有针对软件的最小的功能单元进行测试，才能最大程度地去发现缺陷。功能划分的越细，找到的缺陷数越多

目的：方便测试的有序整洁性。

2）编写需求标识

依据：根据项目组定义的需求标识规则编写需求标识

理由：给每个需求编写一个标识，可以对之后的测试用例的编写以及缺陷发生的地方有明确的来源

3）测试需求或测试要点（针对每一个细分的最小的功能单元，编写约束或限制条件）

“按钮”约束或限制条件：点击按钮后，软件在适合性和准确性方面的预期结果

“输入框”约束或限制条件：输入数据的类型、范围、长度、特殊要求

约束或限制条件的来源：

1、需求规格说明书或用户手册中对于功能点的描述

以下来源需要对需求进行评审

2、分析数据字典或数据库中表结构和数据

3、从软件的提示信息中提取某个功能点的约束或限制条件

4、从客户或开发人员处获得某个功能点的约束或限制条件

5、从其他类型相似的软件处获得，一般首先本公司

当测试需求由多个人编写时，需要注意风格的一致性，在编写前就要统一风格。

需求中的约束或限制条件是使用等价类、边界值等测试方法的前提，是有效等价类、无效等价类划分的前提

每一个约束或限制条件应该有若干个测试用例予以覆盖

当编写完测试计划和测试需求之后，需要对测试计划和测试需求进行评审（开发测试客户），评审通过之后才能进行测试用例的编写

七、编写测试用例

针对每一个测试需求编写若干个测试用例。为方便测试用例的编写，防止遗漏可以先对测试需求进行进一步的提炼。

对软件的测试从六大特性着手：功能性、易用性、可靠性、可维护性、可移植性、效率。以此可将测试分为功能性测试和非功能性测试。

1、对于功能性测试：

方法：等价类划分法、边界值分析法、正交法（因果图+判定表）、错误推断法

对测试需求的提炼是针对每个测试需求点使用等价类划分法生成等价类分析表或使用正交法生成判定表。

对于等价类分析表使用边界值分析法选取有效等价类和无效等价类中的可以代表整个等价类的数据。然后设计测试用例，使得测试用例能够尽可能多的覆盖有效等价类，但是每个测试用例至多只能覆盖一个无效等价类，这是为了明确定位错误所发生的位置。

对于判定表是选取其中有效的每一列生成一条相对应的测试用例。

2、对于非功能性测试

没有相关的方式方法，只能针对测试需求中的每一点进行逐项的检查。会产生多个测试用例。

测试用例中的编写：

1、确定测试用例所属的模块，

依据：最好与该条用例所覆盖的测试要点或需求要点所属的模块相一致，若不一致，用例中应该添加一个元素：需求标识。

理由：为了发现缺陷时能够追踪溯源

2、确定测试用例的编号

依据：根据项目组定义的用例编号规则编写用例编号

理由：后面的缺陷报告中有一个元素为发现该缺陷时所执行的测试用例

3、编写测试用例的操作步骤和测试数据，

依据：测试需求中所写的约束或限制条件，对测试需求使用方法（等价类划分法、边界值分析法等）进一步提炼所生成的等价分析表或者判定表

最好在这里加上一个预置条件，对于测试数据要进行详细的描述，然后写上一个确定的数据。步骤中的相关名词要遵循规格说明书或软件的原词。

4、编写预期结果

依据：需求规格说明书或用户手册/操作手册等文档

要将执行操作步骤之后发生的结果写的详细，不要笼统。这里也要遵守原词。

例如：以下为QTP工具中的flight示例的用户名的一条测试用例

编写完测试用例之后，最好对测试用例进行一次评审。

八、执行测试并记录缺陷

等测试用例设计完成之后，开始执行测试用例。

对于功能性测试用例，如果软件需要开发的版本较多将会经常进行回归测试，这时可以使用功能自动化测试工具来对测试用例进行录制生成自动化脚本，对脚本进行优化修改，这样就实现了自动化测试。

如果软件的版本较少，进行自动化测试将划不来。这是利用人工的方式执行测试用例。按照测试用例的步骤一步一步进行操作，查看最后的结果是否与测试用例中的预期结果相符合。若相符则该条测试用例通过，否则及时记录bug+测试用例编号+问题描述+截图，并将实际结果进行一个记录并进行截图操作。

九、编写缺陷报告

当测试用例执行完成之后，针对没有通过的测试用例进行缺陷报告的编写。实际结果与预期结果之间存在差异，这说明该功能与用户的需求不相符，这即为缺陷。缺陷可以按照严重程度分成五级或四级。

P1级：导致系统崩溃；主业务流程出现断点；导致死机；导致程序模块丢失；内存泄漏）

P2级：被测数据处理错误；软件错误导致数据丢失；用户需求未实现

P3级：被测功能不能正确实现

P4级：功能实现不完美或细小的错误

P5级：建议性问题

分成四级是将P4和P5共同组成P4级。

缺陷有六个状态：打开、分析、修改、搁置、验证、关闭。

1、在执行测试用例时，发现实际结果与预期结果不相符时，即发现缺陷，并将缺陷进行记录，这时状态为打开

2、项目经理或组长和相关人员对缺陷进行审查，若确认这不是一个缺陷，则将这个缺陷关闭。否则对缺陷进行分析，判断缺陷发生的位置以及当前的技术是否可以修改，这时状态为分析

3、若能够进行修改则将这个缺陷指派给开发人员进行修改，修改完成之后，缺陷状态更改为已修复，这是测试人员并不需要立即进行验证测试，而是等待下一个版本发行

4、若不能进行修改，则将缺陷状态变更为搁置，以待下一个版本再进行修复

5、软件的下一个版本发行之后，测试人员对已修复的缺陷再次执行测试用例，验证缺陷是否修复，这是特别注意回归测试的关联测试，修复一个缺陷却引起更多缺陷的情况不是不存在。

6、发现缺陷修复成功之后，将缺陷状态置为关闭。如果修复不成功，再次打开一个缺陷。

缺陷报告包含的元素：缺陷编号、缺陷名称、缺陷发生的模块、发现时间、发现人、修复时间、对缺陷的简单描述、测试环境、缺陷版本、缺陷状态、严重等级（五级或四级）、优先等级、是否可复现、复现步骤、预期结果、实际结果、最好加上发现缺陷时的截图以证明缺陷确实存在。

优先等级一般分为两级：一级指在下一个版本中必须修复的，对应于严重等级中的平、P1至P3，二级指在下一版本中可以不修复，可以留待之后的版本再修复，对应于严重等级中的平、P4和P5

十、编写测试报告

测试报告是对整个测试做一个总结，对所测试的结果做一个记录和分析，为纠正软件中存在的问题提供一份依据。

测试报告包括的内容：

1、对哪些功能点使用什么方法以及工具进行测试

2、对测试结果和缺陷进行统计分析

3、对测试做出结论，该软件是否通过测试，是否可以发布，并给出一定的建议。

4、附加上测试通过情况表

十一、对整个测试做一个总结

整个测试完成之后，自己可以做一个小总结，归纳一下测试中遇到的问题，如何解决的；总结一下经常发现缺陷的地方。丰富自己的经验，也为下一次测试做准备。在下一次测试中发生同样问题怎样解决以及重点关注发现缺陷频率较高的地方。

如果你觉得文章能给你带来帮助，请关注我的公众号并帮忙转发!