测试前置条件及测试点-阿里云开发者社区

开发者社区> 开发与运维> 正文

测试前置条件及测试点

简介:
一、引言
  本文档根据目前公司的实际情况,规范了软件产品提交测试的前置条件以及需提交的文档资料,避免造成测试的反复和资源的浪费。另外,文档还明确了各测试阶段需要关注的一些测试点,为我们的软件测试工作明确了目的和方向。
  二、测试前置条件
  当研发部门完成了软件项目的开发任务之后,软件产品开始进入测试环节。在开发人员提交测试之前,需要遵守测试的前提条件,如果没有限定测试前的前提条件,测试人员需要花费大量的时间去完成一些简单的并且很容易发现的错误,这样会造成很大的人员浪费。因此,对于开发部门提交给测试部门的软件产品,除领导亲自特批外,均必须满足以下条件才允许提交:
  1、 开发部门完成软件的白盒测试
  2、 开发部门完成软件的冒烟测试。
  3、 对于新增功能,必须提供功能列表、功能详细说明、流程明细以及关联的模块;对于修改功能,必须提供修改功能列表、具体修改内容以及影响的模块。
  4、 对于没有完成的功能,不能提交测试,希望在代码中注释掉。
  5、 对于需要与其他系统进行集成测试的软件,需要明确测试环境以及参数的配置,并且详细说明系统间具体是如何集成的。
  6、 对于需要进行性能测试的部分,提供详细说明以及需要达到的各项性能指标。
  三、测试点设计
  1、系统功能测试
  1.1  链接测试
  链接是Web应用系统的一个主要特征,它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先,测试所有链接是否按指示的那样确实链接到了该链接的页面;其次,测试所链接的页面是否存在;最后,测试web应用系统上是否有孤立的页面。
  1.2  表单测试
  当用户给Web应用系统管理员提交信息时,就需要使用表单操作,例如:用户注册、登陆、信息提交等。在这种情况下,我们必须测试提交操作的完整性,以校验提交给服务器的信息的正确性,例如:用户填写的出生日期与职业是否恰当,填写的所属省份与所在的城市是否匹配等。如果使用了默认值,还要校验默认值得正确性。如果表单只能接受指定的某些值,则也要进行测试。如:只能接受某些字符,测试时可以跳过这些字符,看系统是否会报错。
  1.3  cookie测试
  如果Web应用系统使用了Cookies,就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用,是否按预定的时间进行保存,刷新对Cookies有什么影响等。
  1.4  数据校验测试
  如果系统中根据业务规则需要对用户的输入进行校验,那么就必须要保证这些校验功能正常工作。例如,省份的字段可以用一个有效列表进行校验。在这种情况下,需要验证列表完整而且程序正确调用了该列表(例如在列表中添加一个测试值,确定系统能够接受这个测试值)。
  1.5  应用程序特定的功能需求
  尝试用户的所有操作,这是用户之所以使用网站的原因,必须确保:1、功能点是否能正确使用;2、流程是否能正常运转。
  2、系统性能测试
  性能测试是测试过程中不可或缺的一个环节,它是通过自动化的测试工具模拟多种正常、峰值以及异常条件来对系统的各项性能指标进行测试。
  性能测试主要包含负载测试和压力测试
  2.1负载测试
  负载测试是为了测量Web系统在某一负载级别上的性能,以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量,也可以是在线数据处理的数量。例如:Web应用系统能允许多少个用户同时在线?如果超过了这个数量,会出现什么现象?Web应用系统能否处理大量用户对同一个页面的请求?
  通过负载测试,确定在各种工作负载下系统的性能,目标是测试当负载增加时,系统各项性能指标的变化情况。
 2.2压力测试
  压力测试是测试系统的限制和故障恢复能力,也就是测试Web应用系统会不会崩溃,在什么情况下会崩溃。黑客常常提供错误的数据负载,直到Web应用系统崩溃,接着当系统重新启动时获得存取权。
  压力测试是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大服务级别的测试。
  性能测试主要指标:
  (1)响应时间(RT):反映在完成某个业务所需要的时间。
  (2)吞吐量(TPS):反映单位时间内能够处理的事务数目。
  (3)服务器资源占用。
  3、用户界面测试
  3.1  站点地图和导航条
  确认测试的站点是否有地图。有些网络高手可以直接去自己要去的地方,而不必点击一大堆页面,另外新用户在网站中可能会迷失方向。站点地图和导航条可以引导用户进行浏览。需要验证站点地图是否正确?确认地图上的链接是否确实存在?地图有没有包括站点上的所有链接?是否每个页面都有导航条?导航条是否一致?每个页面的链接是否正常?导航条是否直观?
  3.2  颜色和背景
  由于web日益流行,很多人把它看作图形设计作品。而有些开发人员对新的背景颜色更感兴趣,以至于忽略了这种背景颜色是否易于浏览。通常来说,使用少许或尽量不使用背景是个不错的选择。如果您想用背景,那么最好使用单色的,和导航条一起放在页面的左边。否则,图案和图片可能会转移用户的注意力。
  3.3  图形测试
  在Web应用系统中,适当的图片和动画既能起到广告宣传的作用,又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有:
  (1)要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。Web应用系统的图片尺寸要尽量地小,并且要能清楚地说明某件事情,一般都链接到某个具体的页面。
  (2)验证所有页面字体的风格是否一致。
  (3)背景颜色应该与字体颜色和前景颜色相搭配。
  (4)图片的大小和质量也是一个很重要的因素,一般采用JPG或GIF压缩。
  3.4  内容测试
  内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。信息的正确性是指信息是可靠的还是误传的。例如,在商品价格列表中,错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行,例如使用Microsoft Word的“拼音与语法检查”功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的链接或入口。
  3.5  表格测试
  需要验证表格是否设置正确。用户是否需要向右滚动页面才能看见产品的价格?把价格放在左边,而把产品细节放在右边是否更有效?每一栏的宽度是否足够宽,表格里的文字是否都有折行?是否有因为某一个的内容太多,而将整行的内容拉长?
  3.6  整体界面测试
  整体界面是指整个Web应用系统的页面结构设计,是给用户的一个整体感。例如:当用户浏览Web应用系统时是否感到舒适,是否凭直觉就知道要找的信息在什么地方?整个Web应用系统的设计风格是否一致?对整体界面的测试过程,其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式,来得到最终用户的反馈信息。对所有的可用性测试来说,都需要有外部人员(与Web应用系统开发没有联系或联系很少的人员)的参与,最好是最终用户的参与。
  4、系统兼容性测试
  兼容性测试主要考虑到以下几个方面的兼容:
  4.1平台的兼容性
  需要测试在不同操作系统下(例如windows/Linux/Unix等)以及在同一操作系统不同版本下(例如winxp/win2003server/vista/win7等)的运行情况,避免软件在某一操作系统下能正常运行,但在另外的操作系统下就会运行失败。
  4.2浏览器的兼容性
  由于浏览器是web客户端的核心,而不同厂商的浏览器对Java、JavaScript、ActiveX、plug-ins或不同的HTML规格有不同的支持,所以需要对不同的浏览器进行测试,确保软件在不同浏览器下的运行都是没问题的。
  4.3分辨率的兼容性
  测试主流分辨率下的页面显示是否正常?字体大小是否合适?文本图片是否对齐等?
  4.4打印机的兼容性
  4.5组合测试
  5、系统安全性测试
  对于网站系统,安全性测试非常重要,如果用户信息被黑客泄露,客户在交易时,就不会有安全感。
  安全性测试主要关注以下几点:
  (1)现在的Web应用系统基本采用先注册,后登陆的方式。因此,必须测试有效和无效的用户名和密码,要注意到是否大小写敏感,可以试多少次的限制,是否可以不登陆而直接浏览某个页面等。
  (2)Web应用系统是否有超时的限制,也就是说,用户登陆后在一定时间内(例如15分钟)没有点击任何页面,是否需要重新登陆才能正常使用。
  (3)为了保证Web应用系统的安全性,日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
  (4)当使用了安全通信协议SSL时,还要测试加密是否正确,检查信息的完整性。
  (5)服务器端的脚本常常构成安全漏洞,这些漏洞又常常被黑客利用。所以,还要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。
  6、系统接口测试
  在很多情况下,系统都不是孤立的,往往会有很多外部系统与之对接。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等。
  6.1服务器接口
  第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务,然后查看服务器记录,并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库,确认事务数据已正确保存。
  6.2外部接口
  有些web系统有外部接口。例如,网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候,要使用web接口发送一些事务数据,分别对有效信用卡、无效信用卡和被盗信用卡进行验证。也就是说,测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。
  6.3错误处理
  接口的错误处理是最容易被忽略的地方。通常我们试图确认系统能够处理所有错误,但却无法预期系统所有可能的错误。尝试在处理过程中中断事务,尝试中断用户到服务器的网络连接,尝试中断web服务器到信用卡验证服务器的连接。在这些情况下,看看会发生什么情况?系统能否正确处理这些错误?

最新内容请见作者的GitHub页:http://qaseven.github.io/

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章