完整的系统测试过程

为了更清晰的知道系统测试过程，先写一些测试方面的概念：

1、软件测试分为四个阶段：单元测试、集成测试、系统测试、验收测试。

（1）单元测试：测试函数，依据LLD，一般开发人员完成，属于白盒测试。

（2）集成测试：测试模块和接口，依据HLD，开发人员和测试人员完成，属于灰盒测试。

（3）系统测试：测试整个软件，依据SRS，测试人员完成，属于黑盒测试。

（4）验收测试：测试整个软件，分为α测试【软件公司内部测试环境下完成，但必须要求客户参与，请客户到公司参与内测，测试环境可控】和β测试【客户环境下测试，测试环境不可控】。

2、每个阶段的四个活动：测试计划、测试方案、测试用例、测试执行。

3、回归测试

（1）目的就是验证缺陷是否修复，是否引入新的缺陷。

（2）策略：选择性回归和完全回归。

4、常见的系统测试类型：功能测试、性能测试、GUI测试、易用性测试、可靠性测试、兼容性测试、安装测试等等。

 

 

完整的系统测试流程和过程是怎样的：

先概述一下：需求审查【测需求文档】，熟悉需求--》需求评审【需求人员、测试人员和开发人员一起】--》制定测试计划【测试组长或测试经理完成】-》设计测试方案【资深的测试工程师完成】--》提取测试项【根据SRS】--》设计测试用例--》用例评审【根据项目进展选择性开展】--》执行测试用例--》编写测试报告【测试组长完成】

注：以上概述的测试流程每个公司不一样，不过大致都如此。

一、需求审查

拿到需求人员给我们的SRS，先熟悉，熟悉的过程也是测试SRS的过程。因为你不能保证需求人员给我们的就是客户真实的想法。

怎么熟悉需求呢？

1、结构：组成被测软件的所有东西

2、功能：被测软件提供的所有功能

3、数据：被测软件所能处理的数据（类型、大小、数量、内容），被测软件初始化的数据有哪些，相关的配置数据有哪些

4、平台：被测软件是什么环境下进行：硬件、操作系统、测试工具等

5、操作：用户怎么操作，明确什么样的用户来使用，正确的操作，异常的操作

6、时间：时间对被测软件功能的影响：时差、冬令时、夏令时、特殊时间点

二、需求评审

目的：开发和测试针对SRS不理解、理解错误的地方提出来，提高软件的质量。这样做整个软件后期维护成本低一些，项目开展更加顺利。

三、制定测试计划

核心：分工、进度把控、风险预估

四、指定测试方案

核心：1、指导用例工作：指导用什么方法来设计测试用例

           2、指导执行工作：指导怎么搭建环境、指导怎么进行缺陷管理、指导怎么进行回归测试等

五、提取测试项

主要是系统测试分析，系统测试分析的目的是：明确测试点、提取测试项、测试需求分析。有三个方法：质量模型分析法、功能交互分析法、用户场景分析法。

1、质量模型分析法

（1）功能性：

适合性：是否提供了相应的功能

准确性：功能是否正确

互操作性：产品间是否有相互交互数据的能力

保密安全性：是否允许经过授权的用户访问、是否允许系统正常访问数据和信息

依从性：软件功能方面是否遵从法律法规、标准、规范和协议等

（2）易用性：

易理解性：界面上的内容（图标、文字、图片等）是否正确且容易理解

易学习性：用户学习软件的能力。如用户文档、提示信息

易操作性：用户能否操作的能力。（键盘操作、快捷键操作、能选择不输入操作、向导式操作[更复杂的业务流程只需记住第一步即可]、菜单级数<一般不超过3级>、拖曳式操作）

吸引性：[界面是否漂亮]界面上的内容、颜色；界面元素的排版、布局、大小、文字的字体、颜色[GUI测试]

依从性：软件功能方面是否遵从法律法规、标准、规范和协议等

（3）效率：

时间特性：提供适当的响应时间和吞吐率能力。[关注性能指标]

资源利用性：软件处理业务请求所消耗的系统资源、CPU使用率、内存占用率、磁盘I/O[关注硬件资源利用率]

（4）可靠性：

成熟性：软件出现错误不会崩溃的能力

容错性：各种错误情况

易恢复性：软件在崩溃的情况下是否能恢复、恢复的程度、恢复的耗时

依从性：软件功能方面是否遵从法律法规、标准、规范和协议等

（3）可移植性：

适应性：适于不同的环境能力[兼容性测试]

易安装性：安装测试

共存性：软件在公共环境中与其他软件独立共存的能力。关注软件之间资源冲突，读写同一个文件、占用同一个端口、操控同一个设备

易替换性：升级测试

依从性：软件功能方面是否遵从法律法规、标准、规范和协议等

2、功能交互分析法

（1）考虑软件内部功能间的相互影响

（2）常见功能交互：功能同时使用、功能顺序使用

（3）原因：

       a.资源冲突情况：读写同一个文件、占用同一个端口、操控同一个设备

       b.某个功能的执行结果对另一功能的执行产生影响

3.、用户场景分析法

（1）用户：人、某一款软件、某一个设备

（2）场景：用户为了达到目的，将多个功能串起来使用。

（3）用户场景：通过事件流来确定的。

（4）事件流：同一事件不同的触发顺序和处理结果形成事件流。

（5）事件流类型：基本流、备选流

（6）基本流：程序从开始执行到成功结束所经过的最短路径。

（7）备选流：各种错误的情况。

（8）步骤：

     a.明确基本流和备选流

     b.根据基本流和备选流确定场景

     c.合并重复场景

在测试点提取的过程中，详细的还要考虑输入框、下拉框、链接、文本框、cookie、session等等，这些测试点我都有整理，可以多看看。隐性的测试点也要考虑到，如果你们公司有需求矩阵，将测试点提取出来后对一下，保证测试点都完全准确性。

六、设计测试用例

1、测试用例是为特定的目的而设计的一组测试输入，执行条件和预期结果，以便测试某个程序路基和核实是否满足某个特定需求！

2、测试用例的八大要素：编号、测试项、标题、预置条件、输入条件、步骤、预期结果、重要性。

根据这八大要素去编写测试用例，思路会更加清晰。

3、常用的测试用例的方法：

等价类划分法、边界值法、正交排列法、流程图法、状态迁移法、场景分析法、错误猜测法等。

4、总结测试用例设计的要点和注意事项：

测试用例设计是个不断思考的过程，首先要搞清楚自己所测试的软件系统的需求和功能，以及所有能变化的因素，将这些功能点列成一个设计框架，在分别细化各个功能点的测试方法和期望结果，细化过程中，通过等价类划分，正交矩阵等方法来详细各个测试点，保证覆盖的充分性，同时站在用户的角度，考虑用户常用和不常用的操作路径，依次来取舍测试要点。测试用例设计也是个不断优化的过程，平时发现的bug，总结经验，积累更多的经验，测试用例也会更全面，软件品质也能得到更好的保障！

七、执行测试用例

1、搭建测试环境，主要针对服务器b/s、c/s

2、先进行预测试（冒烟测试）：选择高级别或基本功能的测试用例

3、转系统测试评审：确定有没有必要往下继续测试

4、正式执行测试用例

5、缺陷管理

6、回归测试

八、编写测试报告

进行总结性的评价，一般由测试组长完成，得出最后的结论：能否发布？是否通知用户进行验收？通过各种数据统计分析（工作量、用例数、缺陷数等）