完整的系统测试过程

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

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、回归测试

八、编写测试报告

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

 

 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值