转:从web三层架构解析软件测试内容

B/S架构的系统,都会使用如下的基础软件架构:

数据访问层:实现对数据的访问功能,如增加、删除、修改、查询数据。

业务逻辑层:实现业务的具体逻辑功能,如学生入学、退学、成绩管理等。

页面显示层:将业务功能在浏览器上显示出来,如分页显示学生信息等。

在实际项目中,可能会根据情况在业务逻辑层增加层级,对于软件测试,也无非是针对这3层架构进行的测试或者测试过程中都会涉及到这3层架构。

数据访问层:

1. 常出现的问题可能是数据库字段长度不正确,导致保存的数据被截断或提示错误。

2. 写入的数据正确性。

3. 还常会出现开发人员数据库操作时对表名和字段名书写错误导致功能失效。

4. 部分功能在需要确保一切都没有问题时才完成更改,这时需要涉及到对事务处理的正确性。

5. 对数据库层的exception处理。

6. 数据库设计不合理导致性能问题,如数据库完整性设计不合理,垃圾数据累积导致性能下降,索引的设计等。

业务逻辑层:

1.
需求制定时的漏洞,不够严密,导致开发的代码有业务需求方面错误。之前有个经历就是一个不懂软件的老板最初在制定需求时,没有删除数据的功能,但是后来需要增加删除数据功能,可是未经过需求评审,开发完成后,提交测试,对基础数据删除后,引用该数据的模块都无法正常工作

2. 业务逻辑和流程与需求不符合,归结为开发人员对需求的理解不透彻;

3. 其他一些需求没有达到要求,如安全,提示信息的标准,性能等;

4.
编码错误。主要包括局部数据结构错误(变量初始化,地址溢出等等),边界条件错误,模块接口错误,代码独立路径错误,异常处理不恰当等等,这就涉及到详细的单元测试和集成测试了;

5. 软件设计构架导致的错误,如缓存机制等等,需要从性能和时效性两方面着手考虑,否则提交的数据不能被及时看到。

页面显示层:

1. 前端JS错误,如长度或格式校验错误等等;

2. 本地化错误,如用户使用习惯不同导致的错误,多语言翻译错误等;

3. 页面展示,如内容显示不全,显示错误,界面颜色不匹配;

4. 易用性不好,如页面导航错误,提示语不友好,不易学等;

5. 兼容性错误,如分辨率兼容,浏览器兼容,键盘以及OS的兼容问题。

在平时的测试工作中,也经常会遇到除此之外的问题,如配置类的错误,包括web服务器的配置,网站config的配置等。这些均会影响到软件的可用性。

时间: 2024-10-26 22:08:03

转:从web三层架构解析软件测试内容的相关文章

关于WEB三层架构的思考

1.MVC设计思想 MVC程序设计思想是目前比较流行的WEB开发的模式,其中,M(model)是模型,即JavaBean,用来封装和保存数据:V(view)是视图,即JSP,用来显示内容:C(controller)是控制器,即servlet,用来处理业务逻辑.大致流程是这样的:编写一个JSP页面用来获取信息(如登录页面获取用户登录名.密码),并将信息封装到JavaBean中,提交到服务器端由WEB容器将数据封装成request请求,交给servlet来处理.servlet从请求中获取用户信息到数

简单的web三层架构系统【第二版】

昨天写了 web三层架构的第一版,准确的说是三层架构的前期,顶多算是个二层架构,要慢慢完善. 第一版里,程序虽说能运行起来,但是有一个缺陷,就是里面的SQL语句,是使用的拼接字符进行执行.这样安全系数很低,如果有心人的话,可能会SQL注入,重新拼接字符,然后篡改我们的数据库内容,导致不可挽回的损失. 在第二版本,也就是这一版里,我对原来的SQL语句进行了重构,使用带参数的SQL语句对数据库进行操作,这样做的好处是,无论用户输入的是什么格式的字符,SQL语句都会原封不动的把这些字符写入到数据库中,

WEB三层架构与MVC

web三层架构是指: >用户接口层(UI Layer) >业务逻辑层(Bussiness Layer) >持久化层 关于业务逻辑和用户接口 在早期的web开发中,因为业务比较简单,并没有这三层的划分.用户数据的呈现及输入的接收.封装.验证.处理.以及对数据库的操作,都放在jsp页面中.这时的开发,好比盘古尚未开天辟地,整个web开发就是一片“混沌”.随着业务越来越复杂,人们开始考虑更好的利用OOP这把利刃来解决问题.于是有人发现把业务逻辑抽取出来并形成与显示和持久化无关的一层,能够让业务

Django——WEB三层架构与MVC

而我发此文的目的有二:一者,让初学者能够听到一家之言,是为解惑:二者,更希望抛砖引玉,得到专家的批判. 许多学生经常问我,MVC到底和WEB三层架构有啥关系? 开始时,我也只能给他们一些模糊的回答.时间长了,自己的良心开始受到谴责.对于一个程序员来说,这个问题显得挺学究.我在跟自己的许多程序员朋友以及同 行(Java讲师)都对MVC和WEB三层架构的关系做了探讨.现在可以说对WEB三层架构和MVC之间的关系理出了头绪.此可谓教学相长. 先说说Web三层架构这个古老话题.地球人都知道web三层架构

理论与实际相结合——三层架构解析

通常在程序编程中我们所说的三层架构是指:显示层(UI).逻辑层(BLL)和数据访问层(DAL).对于这三层来说,分工明确,各自有各自负责的领域. UI层:1.负责向用户显示数据  2.负责采集用户输入的信息 BLL层:1.从DAL获取数据,以供UI显示 2.从UI中获取指令或数据,经业务逻辑送达到DAL DAL层:1.主要用于对数据源的增删改查的操作. 通过它们各自负责的领域我们可以看出,BLL层属于中间层,它负责UI和DAL层之间的通信.那么通常我们还会加入一个实体层(Enity):主要负责返

Java Web 三层架构详解

java 三层架构ssh 一个spring2.5+hibernate3.2+struts2.0组合框架,使用spring的 IoC来管理应用的 所有bean,包括struts2的 action,充分发挥了spring轻量级框架的 优势.  摘 要: 针对当前Web应用程序开发面临的问题,结合目前比较流行的开源框架Spring.Struts和hibernate,提出了一种开发J2EE Web应用的轻量级解决方案,以帮助开发人员在短期内搭建结构清晰.可复用性好.维护方便的Web应用程序.并且,通过案

简单的web三层架构系统【第五版】

接上一版,今天差不多就是三层架构后台代码的完结了,这一版写完,接下来就是前台的制作了,前台不太熟悉,还在深入学习.过一段时间在写,今天先把后台代码写完. 三层架构包括DAL层, BLL层, UI层(也就是web层),前几版重点放在DAL上,也就是数据访问层代码的编写.其实BLL层中的代码编写起来容易,真正的要灵活的用起来,还是需要一些算法方面的基础的,BLL业务逻辑层,主要处理逻辑方面的东西,这一层不太涉及也不需要编写数据库中的代码,因为在DAL层中已经编写完成,只需要在BLL中定义使用即可.

简单的web三层架构系统【第三版】

今天是第三版,和前几天一样今天还是要对代码进行优化,三层架构是一种思想,具体能不能使得整个系统安全和高性能,还是要看代码编写的是否合理,逻辑性是否严谨. 昨天偶然间看到别人写的三层架构中,竟然没有在方法中传递单个参数,而是直接声明了一个对象整体的当传参.最后上网查,发现原来是在系统里多加了一层,叫做模型层,就是用来在系统的各层之间传递数据的,这样就避免了为一个方法传递多个参数现象. 具体深入的模型层使用还在学习当中,今天就用学到的一点简单的模型层知识,对代码进行再一次优化. 首相先建立一个模型层

Web三层架构及MVC

关于 三层架构(3-tier application) 通常意义上的三层架构就是将整个业务应用划分为:表现层(UI).业务逻辑层(BLL).数据访问层(DAL).区分层次的目的即为了“高内聚,低耦合”的思想. 1.表现层(UI,也称用户接口层):通俗讲就是展现给用户的界面,即用户在使用一个系统的时候他的所见所得. 2.业务逻辑层(BLL):针对具体问题的操作,也可以说是对数据层的操作,对数据业务逻辑处理. 3.持久化层(数据层DAL):其功能主要是负责数据库的访问,可以访问数据库系统.二进制文件