测试技巧整理文档

上一篇 / 下一篇  2008-07-29 11:19:25

一:软件中隐藏的缺陷

通常软件测试会暴露软件中的缺陷,经过修正后可以保证软件系统的功能满足需求并正确运行。但是,在系统测试和确认测试中,测试人员容易遗漏一些隐藏的缺陷。众所周知,软件测试不可能发现所有的缺陷,而软件开发周期各个阶段仍然存在注入缺陷的可能,但是,有一些缺陷是测试中容易忽略的,也就是说,通过测试方法和用例可以充分暴露这些缺陷,遗憾的是,它们往往被忽略或者某种原因忘记测试了,这就给软件留下了隐患或者危机。这些容易被忽略的缺陷包括:

  1、安装缺陷

  通常项目组完成代码后,发布时候安装打包是最后一个环节,而软件测试人员通常在测试的时候,没有仔细的测试这一部分,而把用例集中在其他功能上。安装时候的缺陷通常通过拷贝而不是运行安装程序方式给测试人员安装软件,结果正式安装时候出现问题,引起例如控件没有注册,注册表没有导入等。删除时候没有注意安装文件夹是否存在用户文件,造成数据丢失;使用绝对路径;安装顺序没有说明书。

  2、配置文件

  有些文件在ini等配置文件中写出了管理员口令密码等信息,而且是明文的!这是一个安全隐患。另外,有些安装文件的XML文件,为了方便在数据库和中间层连接文件中写入了Admin口令和密码。作为一个合格的软件测试人员,必须检查这些可以用记事本打开的文件。因为,一个稍有常识而且喜欢探索的用户,可能从中获取信息而成为不自觉的黑客。所以,配置文件可能成为软件安全方面的一个缺陷。

  3、网页安全缺陷

  现在网站开发已经注意到:登陆网站进入其内部网页后,直接拷贝网址,然后粘贴到另一IE窗口输入,可以绕过登陆直接访问。也许商业网站很关注这个问题,但是很多行业软件却很容易忽略。

  网页安全缺陷还可能存在于IE弹出的子窗口。有些设计不严格的软件,在主页面关闭的时候子页面还可以运行,这是一个明显的漏洞,而且还大大增加了错误发生的几率。

  4、判断顺序/逻辑缺陷

  对界面进行多个输入判断的时候,非常容易出现这种问题。例如判断年月顺序,判断长度,判断非空等。假如操作员仅仅满足单个条件,保存不能成功;而按界面从上之下顺序一一满足条件之后,保存是没有问题的。但是,改变一下输入的次序,校验失效。例如,一一满足条件之后,不保存,倒过来将上面的输入改成非法输入,然后保存,结果居然也能成功,这是因为原先的判断由于发生过,或者根据语句顺序只检查最后一个判断,所以没有报错。这种错误尤其在Java scrīpt脚本的页面中要注意。能够保存不能保证数据正确,有可能引起系统崩溃或者后续数据错误。所以,在测试的时候,不要按照正常的顺序输入,而是要打乱步骤,看看代码是否强健,是否在判断逻辑上没有错误。良好的代码应该经得起折腾,至少保存时会再此全部进行判断,而不只是简简单单走到判断的最后一行。

  5、调试语句和冗余信息

  维护项目和升级改造的推广系统最容易潜伏这类缺陷。典型表现在没有删除或者屏蔽调试语句。弹出一个界面不友好的提示信息,会使不明真相的用户产生误以为系统发生了严重故障,从而引起对软件的不信任感。页面中某个角落存在当前客户不需要的冗余按钮和功能也是一种缺陷。多余的功能会使用户以为是额外附加部分而去使用,其结果可想而知;而多余的按钮会误导好奇心强的用户操作,产生不必要的错误。

  同样值得关注的还有参数设置,由于没有实际数据,开发人员在调试或者单元测试的时候,习惯性的进行自我设定而忘了删除,软件测试人员可能会忽略掉了这部分测试,也可能导致在客户现场发生错误而影响系统发布和验收。

  6、不可重现的故障

  新参加软件测试的人员或者新来的开发人员总是要问,不可重现的缺陷是否需要记录,有必要吗?回答是肯定的。测试必须如实的记录发生的问题,也许不能重现,或者使非软件系统本身问题,但是,可能这些偶然性背后是有规律的,不记录这些,就不可能发现这些规律。

  7、多节点的逆向流转缺陷

  当前软件不少喜欢使用工作流来驱动。工作流的问题,就是可能出现多个流向分支。测试容易忽略的部分,就是工作流多节点的逆向流转。例如,通过不通过涉及两个分支,但是流程逆转的时候,有可能不是回到上一节点而是平级的另一个节点去了。软件测试要格外注意这类用例的设计。另外,有些时候默认分支在向前的时候是有默认值的,例如默认通过,那么保存的时候要提示用户是否通过,否则可能由于操作疲劳而走错了节点,引起回退。

  8、输入框缺陷

  试过往输入框粘贴数据而不是直接输入吗?可能这里会出现问题。按Ctrl+V的时候,输入框会根据长度大小自动截断输入长度。但是用鼠标,截断可能会失效。有一次测试人员就是用这种方法把一篇Word文档输入进去了,保存的时候,数据库崩溃。有些网站登陆的口令****可以拷贝下来的,只要放在剪贴板里面马上明文显示。

  输入框可以说是问题最多的部分,能够引起的麻烦也很多。日期、数字、文本等等,都需要耐心的测试一下。

  9、界面布局缺陷

  曾经有一次,项目经理回来向测试部反映一个问题,客户对界面不满意。原因很简单,因为界面上删除按钮和保存按钮挨得很近。结果有些操作不熟练的业务人员,很容易误按。这个问题是测试人员没有意料到的,因此注意关闭、删除、退出按钮与保存、下一步等按钮的距离。类似的按钮应按此规则排列分布。

  界面布局还可能发生在窗口最大化和最小化上,有可能窗口缩小的时候没有下拉框或不匹配分辨率,对用户来讲,这个错误实在很低级。有些用户由于操作习惯,非常不喜欢腾出手使用鼠标,尤其是大量输入的界面,因此,要注意设置键盘的快捷方式。还有,按Tab定位到下一焦点时要注意顺序,避免跳转太灵活而让操作人员感到无从适应,在界面进行维护或者修改的时候,不要忘了软件测试开发人员是否无意改变了这些快捷方式和跳转顺序。

  10、版本和补丁包的环境问题

  理论上讲,这属于兼容性测试应该覆盖的问题。有些客户很喜欢更新最新的软件版本或者微软时不时打些补丁包,问题就出现了。有时候升级不一定是好事。这些问题最好在测试的时候增加几个用例,多用不同软件版本的机器跑一跑。软件测试有个定律是:你没跑过的地方,就一定会出事。经常听到开发人员抱怨,怎么我的机器没问题,你的机器就有事了呢?这不能完全靠配置管理员解决问题,环境配置项是大家最容易忽略的。

  11、用户管理缺陷

  用户管理的角色和授权需要好好研究一下,作过测试的人员都知道,有时候为了测试的方便,测试用户都是具有超级权限的用户。而且,比较容易忽略用户管理这一部分的测试。往往发往客户的时候,很多测试用户都没有删除。

  另外,有些接口的用户和口令,到软件使用寿命结束都没有更改过。在一次测试中,软件测试人员发现,给一个用户授超级用户权限,之后更改这个用户为受限权限。使用中发现,用户居然没有真正回收权限,用户管理界面上没有任何不对。及早准备用户管理用例,不要等到测试快结束时候才想起。

  12、常识缺陷

  从逻辑或者统计学上讲,计算机是允许如此处理的,但是从常识上来讲,这些情况不可能发生。例如电话号码不可能出现小数点,终止时间不能大于开始时间等等。除此之外,常识还要结合业务特点来进行判断,因此,开发和测试人员要格外注意对自己知识的培养以及增加对需求细节的了解。不能因为一味追求进度而采用最简单的代码来实现,对用户来说,这些错误可能是很荒谬的。

  尽管我们不可能完美的测试一个软件,但是我们仍然可以改进我们的软件测试。每次测试结束,及时总结测试中的不足,进一步完善用例。思考一下那些容易忽略的软件缺陷,能提高对软件测试的认识,提高所在组织软件的质量。

二:门户网站类的导航条测试点如下:

       功能方面:

        1) 一、二级导航中的文字链接页面打开方式一致;要么新页面,要么当前页面;

        2) 各链接页面正确显示,不出现错误;

       UI方面:

        1) 一、二级导航中的文字颜色、大小、风格显示一致;

        2) 每选中导航中的页面,相应的该页面的导航文字为选中显示状态;让用户知道自己在看的是那一页;

        3) 导航条中的页面文字显示正确,无错别字;

        4) 同一导航在不同地方显示的内容和排列的顺序一致;

       兼容性方面:

       在不同的浏览器下查看页面显示是否正确;

       易用性方面:

        1)导航名字容易明白,见名知道其意思;页面内容和其名字表达内容相呼应;

        2)导航栏排列方式符合用户使用逻辑,查看简单,分类级别层次不超过2层;

三:WEB安全性测试
  一个完整的WEB安全性测试可以从部署与基础结构、输入验证、身份验证、授权、配置管理、敏感数据、会话管理、加密。参数操作、异常管理、审核和日志记录等几个方面入手。
1.
安全体系测试
1) 
部署与基础结构
  网络是否提供了安全的通信
  部署拓扑结构是否包括内部的防火墙
  部署拓扑结构中是否包括远程应用程序服务器
  基础结构安全性需求的限制是什么
  目标环境支持怎样的信任级别
2)
输入验证
l  
如何验证输入
A. 
是否清楚入口点
B. 
是否清楚信任边界
C. 
是否验证Web页输入
D. 
是否对传递到组件或Web服务的参数进行验证
E. 
是否验证从
数据库中检索的数据
F. 
是否将方法集中起来
G. 
是否依赖客户端的验证
H. 
应用程序是否易受
SQL注入攻击
I. 
应用程序是否易受XSS攻击
l  
如何处理输入
3) 
身份验证
  是否区分公共访问和受限访问
  是否明确服务帐户要求
  如何验证调用者身份
  如何验证数据库的身份
  是否强制试用帐户管理措施
4) 
授权
  如何向最终用户授权
  如何在数据库中授权应用程序
  如何将访问限定于系统级资源
5)
配置管理
  是否支持远程管理
  是否保证配置存储的安全
  是否隔离管理员特权
6)
敏感数据
  是否存储机密信息
  如何存储敏感数据
  是否在网络中传递敏感数据
  是否记录敏感数据
7)
会话管理
  如何交换会话标识符
  是否限制会话生存期
  如何确保会话存储状态的安全
8)
加密
  为何使用特定的算法
  如何确保加密密钥的安全性
9)
参数操作
  是否验证所有的输入参数
  是否在参数过程中传递敏感数据
  是否为了安全问题而使用HTTP头数据
10)
异常管理
  是否使用结构化的异常处理
  是否向客户端公开了太多的信息
11)
审核和日志记录
  是否明确了要审核的活动
  是否考虑如何流动原始调用这身份
2. 
应用及传输安全
  WEB应用系统的安全性从使用角度可以分为应用级的安全与传输级的安全,安全性测试也可以从这两方面入手。
  应用级的安全测试的主要目的是查找Web系统自身程序设计中存在的安全隐患,主要测试区域如下。
  注册与登陆:现在的Web应用系统基本采用先注册,后登录的方式。
A.必须测试有效和无效的用户名和密码
B.
要注意是否存在大小写敏感,
C.
可以尝试多少次的限制
D.
是否可以不登录而直接浏览某个页面等。

  在线超时:Web应用系统是否有超时的限制,也就是说,用户登陆一定时间内(例如15分钟)没有点击任何页面,是否需要重新登陆才能正常使用。
  
操作留痕:为了保证Web应用系统的安全性,日志文件是至关重要的。需要测试相关信息是否写进入了日志文件,是否可追踪。
  备份与恢复:为了防范系统的意外崩溃造成的数据丢失,备份与恢复手段是一个Web系统的必备功能。备份与恢复根据Web系统对安全性的要求可以采用多种手段,如数据库增量备份、数据库完全备份、系统完全备份等。出于更高的安全性要求,某些实时系统经常会采用双机热备或多级热备。除了对于这些备份与恢复方式进行验证测试以外,还要评估这种备份与恢复方式是否满足Web系统的安全性需求。

四:常见的WEB测试方法

1 UI测试看页面是否美观养眼(包括页面的布局是否合理,策划是否舒服美观,页面长度是否合理,前景色与背景色是否搭配,页面风格是否统一,色调是否适合人眼,会不会太刺眼,字体大小是否合适,字体的颜色是否与背景色搭配,字体链接时是否会出现设置怪异的背景色,字体颜色有没有与背景色太接近或差距太大导致我们没办法看清字体或刺激了我们的视觉,点击链接时图片和字体会不会产生移位),表格和DIV测试,是否网页设计师在表格或DIV里放置了过多的东西导致表格或DIV拉长,表格或DIV之间对齐了没有,中间是否有空隙,是否产生了错位,如果在表格或DIV中设置了溢位,表格或DIV中的内容是否可以全部看到,有没有出现一半字的情况,如果使用了框架结构.框架结构是否合理,表格每行的宽度是否足够,是否有折行

 2链接测试 点击链接时是否可以进入我们要找的页面,进入了我们要找的页面后能否正确返回,链接页面会不会是空白页面或孤立页面或根本没链接(也就是说链接的是自己本身),如果链接的是空白页我们是否可以再正确返回,如果使用了框架或内嵌框架是否可以正确在本框见页内显示要查找的页面,使用内容置顶时是否可以正确实现

 3表单测试 表单的测试包括单选按钮,复选框,文本框,密码项和菜单项和提交按钮类按钮的测试和后台数据库的测试.首先如果是单选按钮我们选择了一个后可不可以再选第二个,如果是复选框的话我们能不能同时选择多个选项,选择多个选项时若需要全选那摸我们是要一个个的选择还是只需要选择一次就可以,在文本框里我们输入的字数有无特别限定,若与特别限定条件不符那摸我们是否可以操作成功,在对用户名和密码的设置时用户名是否可以为数字,汉字,非英文 字符,中间是否可以有空格,标点符号,对密码的长度有无特别限定,若超过特别限定或少于特别限定我们是否可以操作成功,密码是否可以为汉字,英文,特殊字符和标点符号,中间是否可以空格,密码是否设置了屏蔽菜单项分级是不是太多,过长(特别是我们为了节省空间在导航上设置的菜单)点击菜单选项上的各分级目录是否可以正确进入链接页面,进入链接页面我们是否可以正确返回,点击提交按钮看是否可以提交成功,点击取消按钮看其是否生效,提交后看我们的资料是否保存成功,保存后刷新页面看我们的资料是否可以正确显示,我们是否还可以再回到原始页面,如果未输入用户名或密码会不会提示出错,错误提示是否可以关掉,提示出错后我们能否回到原始页面,用户提交的数据是否真实有效,如填写的所属省份与所在城市是否匹配,出生年月与身份证号是否匹配等

 4 兼容性测试 在各种配置不同操作系统上和分辨率不同的电脑上及使用不同的浏览器对其测试,看其是否可以正确显示,是否有图片和页面错位和太大太小等问题使有的部分无法看到,是否有图片或视频无法显示

 5 网络配置测试 看看网页是否可以打印或保存(如果是保密的网页或不想让别人保存的页面可以将其作成FLASH格式的,不让用户保存),看看网页冗余代码是否过多或容量太大导致网络运行速度过慢

 负载测试 多个用户同时上网,砍其最大的承受能力是多大,如果超过了这个极限会有何反应

 压力测试 看看几百,几千甚至几万个人同时上网网页还能显示不,运行速度会有怎样的变化,是否响应时间太长或运行过慢,他到啥时候会崩溃

 8安全测试 用户名和密码是否有长度限制,是否有复杂度限制,登陆次数是否受限,如果超过了登陆次数,关闭页面重新登陆是否还可以登陆进去,换了台电脑或在另外的地方登陆呢,WEB系统是否有超时限制,超时以后是否会提示登陆,日志文件是否记录登陆后用户进行的操作操作,是否记录登陆失败的操作,事物完成后,会不会记录拥护进行的操作,会不会记录用户名,是否在ASP,JSP,JAVAscrīpt,VBscrīpt等脚本语言里有设置可以访问服务器的语言,是否使用了安全套接字层协议SHTTP,若使用了这种协议,那摸在网页中是否有备份替换的页面

 9 接口测试 在处理过程中中断事务,看看会发生什么情况?订单是否完成?尝试中断用户到服务器的网络连接。尝试中断web服务器到信用卡验证服务器的连接。在这些情况下,系统能否正确处理这些错误?是否已对信用卡进行收费?


TAG:

 

评分:0

我来说两句

日历

« 2024-05-13  
   1234
567891011
12131415161718
19202122232425
262728293031 

数据统计

  • 访问量: 1550
  • 日志数: 2
  • 建立时间: 2008-04-24
  • 更新时间: 2008-07-29

RSS订阅

Open Toolbar