小编热衷于收集整理资源,记录踩坑到爬坑的过程。希望能把自己所学,实际工作中使用的技术、学习方法、心得及踩过的一些坑,记录下来。也希望想做软件测试的你一样,通过我的分享可以少走一些弯路,可以形成一套自己的方法,并应用到实际中。

目录

前言

1、安装缺陷

2、配置文件

3、网页安全缺陷

4、判断顺序/逻辑缺陷

5、调试语句和冗余信息

6、不可重现的故障

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

8、输入框缺陷

9、界面布局缺陷

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

11、用户管理缺陷

12、常识缺陷

结语


前言

通常软件测试会暴露软件中的缺陷,经过修正后可以保证软件系统的功能满足需求并正确运行。但是,在系统测试和 确认测试中,测试人员容易遗漏一些隐藏的缺陷。

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

这些容易被忽略的缺陷都有哪些呢?让我们一起往下看吧。

1、安装缺陷

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

[popexizhi:这个不是太大的问题,记入结构化过程,以后注意就可以。]

2、配置文件

  有些文件在ini等配置文件中写出了管理员口令密码等信息,而且是明文的!这是一个安全隐患。

[popexizhi:这个是个新的值得关注一下,原来也零散的发现但从没有考虑到系统中来。]

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

[popexizhi:就像上面说到的一样,注意可用记事本打开的文件]

3、网页安全缺陷

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

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

4、判断顺序/逻辑缺陷

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

[popexizhi:界面操作的执行顺序问题]

5、调试语句和冗余信息

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

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

6、不可重现的故障

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

[popexizhi:当前推荐建立不可重新性问题的库,定期检索使用]

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

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

[popexizhi:这个和我考虑的循环问题的处理相关,但在的角度不一致]

8、输入框缺陷

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

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

9、界面布局缺陷

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

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

[popexizhi:这个现在属于GUI交换专家的参考建议,既然国内都把它放入测试,我就多加个分类吧!]

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

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

11、用户管理缺陷

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

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

12、常识缺陷

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

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

结语

感谢每一个认真阅读我文章的人!!!

如果下面这些资料用得到的话可以直接拿走:

1、自学开发或者测试必备的完整项目源码与环境

2、测试工作中所有模板(测试计划、测试用例、测试报告等)

3、软件测试经典面试题

4、Python/Java自动化测试实战.pdf

5、Jmeter/postman接口测试全套视频获取

6、Python学习路线图

重点:配套学习资料和视频教学

那么在这里我也精心准备了上述大纲的详细资料包含:电子书,简历模块,各种工作模板,面试宝典,自学项目等。需要的朋友

软件测试中,容易被忽略的缺陷有哪些?相关推荐

  1. 软件测试中Bug的分类(类型)

    软件测试中Bug的分类: 1.按严重程度分类: 是指bug对软件质量的破坏程度,即此bug的存在将对软件的功能和性能产生什么样的影响. 崩溃(Blocker):系统无法正常运行.阻碍开发或测试工作的问 ...

  2. 软件测试笔记(十六)- 缺陷轰炸和beta测试

    了解如何利用其它人员从不同角度使用软件,发现可能忽略的缺陷. 一.让别人测试你的软件 成为高效的测试员的另一条途径是借助他人的力量.如果能让更多的人在软件发布之前查看软件,即使他们不是专业测试员,也嫩 ...

  3. 软件测试中7个看透不说透的真理

    希望这篇文章会对大家有所启示. 软件测试中7个看透不说透的真理 真相1:测试并不能找出所有的bug 真相2:测试覆盖率与测试的效果几乎没有相关性 真相3:测试工作量呈指数增加 真相4:开发者偏差 真相 ...

  4. 软件测试中的“黑天鹅”

    1.软件测试中的"黑天鹅"   几年前,我带领的一个测试小组遗漏了一个严重的bug到网上,当用户反馈这个bug后,我们对它进行了深入的分析和重现,最终所有人一致认为,这个bug能够 ...

  5. 软件测试问题分类,软件测试中常见问题分类说明

    软件测试中常见问题分类说明 一. 规范化问题 包括软件规范和业务规范两大类,软件规范问题主要指操作过程中显而易见的错误或缺陷,非人性化设计.友好度较差等:业务规范问题主要指使用非标准或非惯例的业务术语 ...

  6. 阿里研究员:软件测试中的18个难题

    简介:对于软件测试来说,怎么样才算测够了?如何评价测试的有效性?那么多测试用例,以后怎么删?在软件测试中会遇到非常多的问题,阿里研究员郑子颖分享了18个他总结出的难题以及相关看法,希望对同学们有所启发 ...

  7. 什么是软件测试中的黑天鹅

    1,黑天鹅以及软件测试中的黑天鹅 在发现澳大利亚的黑天鹅之前,欧洲人认为天鹅都是白色的.所以说"黑天鹅"代表了一个小概率事件,它罕有发生,但一旦出现,就具有很大的影响力." ...

  8. 软件测试中的杀虫剂效应与金字塔模型

                                        软件测试中的杀虫剂效应与金字塔模型 今天包括后面的文章,我们除了聊自动化以外,也来聊一下软件测试中的一些基础知识. 基础知识也非 ...

  9. 论黑盒测试与白盒测试在软件测试中的不同作用

    一.引言: 黑盒测试着眼于外部结构,不考虑内部结构,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能说明:而白盒测试着眼于内部结构,对软件的过程性细节做细致的检查.随着软件市场的成熟,人们对 ...

最新文章

  1. CenterNet算法快速入门
  2. 周信东c语言实验二实验报告,周信东主编最新版C语言程序设计基础实验一实验报告.doc...
  3. NSThread的使用
  4. ncnn-mobile
  5. 机器学习算法基础——k近邻算法
  6. EfficientDet目标检测谷歌官方终于开源了!
  7. 收藏 | PyTorch常用代码段合集
  8. v8声卡调音软件_声卡出现杂音怎么办?教你几招解决杂音问题
  9. 了解PS、学习使用html语义化标签和CSS术语
  10. 阿里云云计算 11 ECS初体验-- 动手实验
  11. 【收集】个人认为比较实用的电脑工具软件(附带安装包下载)
  12. android逆向工程反编译指南(详细教程)
  13. python requests接收chunked编码问题
  14. MATLAB绘图:导出矢量图
  15. eps在c语言,C语言中eps指的是什么东西?
  16. asp.net把网站发布到本机IIS上
  17. 【软考】系统集成项目管理工程师(十二)项目沟通管理
  18. GOE:Nintendo Switch™ 对战忍者口香糖动作游戏 『Ninjala』决定于2020年6月25日发售
  19. 【2020-COLING】Regularized Graph Convolutional Networks for Short Text Classification 用于短文本分类的正则化图卷积网络
  20. python根据一个list的index获取list

热门文章

  1. word中表第一行和最后一行加粗,其余不变
  2. 女孩子适合什么牌子蓝牙耳机?双11高颜值小清新蓝牙耳机推荐
  3. 从零搭建树莓派远程监控小车,udp视频传输,qt上位机
  4. Java开发工程师就业方向有哪些选择?
  5. ListView的两种实现方法
  6. android 画板之橡皮擦功能开发
  7. 强酸和激光可破解iPhone手机加密数据
  8. 写英文论文的一些总结
  9. 刷新认知,真正走向大众认知的易用性极强RPA产品——影刀RPA
  10. 喜欢有点幸福到忧伤的旋律