测试经验 --- 那些躲在角落的缺陷

众所周知,软件测试不可能发现所有的缺陷,而软件开发周期各个阶段仍然存在注入缺陷的可能,但是,有一些缺陷是测试中容易忽略的,也就是说,通过测试方法和用例可以充分暴露这些缺陷,遗憾的是,它们往往被忽略或者某种原因忘记测试了,这就给软件留下了隐患或者危机。这些容易被忽略的缺陷包括:

1、安装缺陷

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

2、配置文件

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

3、网页安全缺陷

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

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

4、判断顺序/逻辑缺陷

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

5、调试语句和冗余信息

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

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

6、不可重现的故障

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

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

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

8、输入框缺陷

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

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

9、界面布局缺陷

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

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

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

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

11、用户管理缺陷

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

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

12、常识缺陷

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

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

时间: 2024-08-05 01:56:05

测试经验 --- 那些躲在角落的缺陷的相关文章

读书笔记:读完互联网测试经验的感受

之前下载了一些互联网公司的测试经验和技术介绍,因为太忙一直没有时间看.最近又翻出来重新看了一遍,感触还是挺多的,可能也是由于工作时间长了后有了一些新的感悟. 主要有百度,腾讯,阿里下属的几个子公司(淘宝,支付宝,一淘),豆瓣等等,内容比较杂,有介绍测试经验和测试技术的,也有介绍自己的测试工具和自动化平台的.总体感觉互联网公司的测试工作还是比较高大上的,最起码比我们部门做的好多了.总结了一下,主要优点体现在以下几个方面:第一,尽早测试:第二,尽可能深入,测试从最底层开始,逐步上升集成:第三,尽量减

测试经验

很实用的一些测试经验,与大家共享,希望可以帮助到你们 1.迅速找出重要的程序问题 a.首先测试变更的部分,然后测试没有变化的部分.修改和更新都意味着新的风险 b.首先测试核心部分,然后测试辅助功能 c.首先测试能力,然后测试可靠性.先测试每个功能是否完全能用,然后在深入检查任何一个功能在很多不同条件的表现如何 d.首先测试常见情况,然后测试不少见的情况.使用常用的数据和使用场景 2.跟着程序员走 a.为程序员提供支持,很可能是测试使命的关键部分.在测试员测试程序员正在编写或刚刚完成的程序时,测试

【tool】Android应用测试经验总结

Android应用测试经验总结 启动: 1. 启动入口:桌面正常启动,最近运行启动,所有程序列表中启动,锁屏快捷启动 2. 其他入口:从其他程序开启应用,从外部以文件形式打开应用(如果有) 3. 退回:从其他程序退回时回到被测应用,被测应用打开其他应用再从桌面图标启动 以上需要交叉组合测试. 4. 异常启动:崩溃后启动,写文件时被强制杀进程后启动,网络请求未收到回包强制杀进程后再启动,网络超时时启动(启动需要有超时机制) 功能介绍,引导图,流量提示等: 1 全新安装程序第一次启动,会有些初始化,

如何借助测试经验图谱完成三个月总结?

一 我们组所有新员工在入职三个月的时间点,都会要求做一个阶段性总结,然后就总结的内容,我会找他作个面谈. 从目前所有人总结的内容来看,千差万别,虽然我们有规定总结的范围,比如「客观.量化及可视的工作成果」,但是每个人对这个范围的理解都不一样,所以结果也就不一样了. 如果非要找共同点的话,那就是大家都会去罗列工作的内容,比如熟悉了多少个工具,经历了多少个项目,提交了多少个 Bug 等等. 非要说这样写有没有问题,其实也没问题,确实有量化的工具数,也有量化的项目数,还有量化的 Bug 数. 但还是差

代码审查 本地测试经验汇总

软件测试虽然辛苦,但是掌握了一定的技巧之后将使你事半功倍. (1) 边界测试,测试用户输入框中的数值的最大数和最小数,以及为空时的情况. (2) 非法测试,例如在输入数字的地方输入字母. (3) 跟踪测试,跟踪一条数据的流程,保证数据的正确性. (4) 在开始测试时应保证数据的正确性,然后在从系统中找出各种BUG. (5) 接口测试,程序往往在接口的地方很容易发生错误,要在此模块测试勿掉以轻心. (6) 代码重用测试,在开发过程中有些模块功能几乎相同,程序员在重用代码时可能忘记在原有代码上修改或

多语言的测试经验分享

(转载)原文地址:https://blog.csdn.net/alice_tl/article/details/78907732#comments 所谓多语言测试,是指APP在多个使用不同语言的国家发布,则必须对多种语言支持的一种场景测试.比如希望在Google Play上发布一个APP,提供给全球用户下载,那么就需要支持英语.泰语.韩语.阿拉伯语等等不同国家的语言. 近期项目要接触到多语言测试,于是将自己的经验梳理了一下,可以给大家参考. 测试注意事项: 1.同一语言,不同国家的代号不同 不同

转:六年测试经验总结感悟

1.分享第一条经验:"学历代表过去.能力代表现在.学习力代表未来."其实这是一个来自国外教育领域的一个研究结果.相信工作过几年.十几年的朋友对这个道理有些体会吧.但我相信这一点也很重要:"重要的道理明白太晚将抱憾终生!"所以放在每一条,让刚刚毕业的朋友们早点看到哈! 2.一定要确定自己的发展方向,并为此目的制定可行的计划.不要说什么,"我刚毕业,还不知道将来可能做什么?","跟着感觉走,先做做看".因为,这样的观点会通过你的潜

WEB下渗透测试经验技巧(全)[转载]

Nuclear’Atk 整理的: 上传漏洞拿shell: 1.直接上传asp.asa.jsp.cer.php.aspx.htr.cdx….之类的马,拿到shell.2.就是在上传时在后缀后面加空格或者加几点,也许也会有惊奇的发现.例:*.asp ,*.asp...3.利用双重扩展名上传例如:*.jpg.asa格式(也可以配上第二点一起利用).4.gif文件头欺骗5.同名重复上传也很OK.: 入侵渗透中用到的命令,语法: set,systeminfo,ipconfig,ping,利用这些命令可以收

谈通过测试经验来识别开发中的问题

1.界面常见问题 1.1.对齐问题 设置左.中.右对齐,其中,数字一般为右对齐,文字常为左对齐: 栏目区域对齐,如下图所示,展现行数应该一致,控制不允许换行. 解决方案: 1.标题过长截断: 2.浮动显示全名. 1.2.文字用语业务化问题 解决方案: 规范界面用语,避免使用程序员技术语言,通过与业务人员沟通尽量贴近实际业务. 1.3.图标使用问题 图标的使用,为界面带来了活力,但是使用不当,让人产生疑问,如下图所示: 方案: 按图中文字描述,图片尽量与业务接近,并且区分开发. 2.复杂.灵活所带