软件缺陷常见问题总结(软件测试入门速成篇)

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/JCY58/article/details/51931652

常见问题一:

统一性

不要在软件中使用中英文混合的提示,比如对于用户的操作提示,不要一会用“error”一会用“错误”;一会用“succeed”另一会用“成功”总之要统一。某局长使用心得:删除的时候提示Error,幸亏我英语水平好,可是你换成中文不行吗?

比如在我们开发过的系统出现过:

1operation is  succeed,具体看一下我们公司jira中哪个系统出现的问题。

2:另外,食药监项目初期阶段,日期控件有的采用中文,有的采用英文形式。

 

常见问题二:

容错性

对于保存提交的数据输入信息,在输入长度方面要么就限制用户的输入,要么就在客户端给出用户的醒目的提示、判断。不要出现系统崩溃,保存缓慢系统等无法响应等现象。

下图是我从公司jira中截图:


常见问题三:

互动性

在要求用户大量输入信息后,点击“保存”或者“提交”按钮,仅仅是因为用户的某个地方输入或者选中不正确,点击“确定”后发现所有输入的内容全部都被清空了,---花费很长时间的输入,仅仅是因为某个地方的输入不正确,而把该用户的所有其他的输入地方的输入都清空了,假如你是这个软件的使用者,你肯定会感觉到很恼火的。(保存不成功也可以理解的,但是不能把用户所有的输入信息全部清空吧)。

 

常见问题四:

用户体验

页面上的提示信息要让用户明白,比如不要对用户使用“记录”、“字段”等一些很专业的术语。

举例:比如食药监项目上的“信息发布”,张三同学程序中这样子提示的“流程已启动”这样的提示对那些局长们来说就很不合理。

 

常见问题五:

现在遇到的情况是程序人员的浏览器的版本都比较高(比如IE10IE11),在他们的开发机器上确实没有问题,但是在用户的环境中(比如用户环境中Winxp机器上的IE8.0浏览器下)就有问题。

兼容性测试举例如下:

针对App通常会考虑这些方面:

1)操作系统版本

包括Andoird版本,iOS版本

2)屏幕分辨率

3) 网络类型

比如Wifi3G4G下的功能情况

 

常见问题六:

兼容性

对于软件中很多都有导出成excel或者Word的功能,在更高版本的excel中打开这个导出的版本会不会出现乱码现象?(比如以前测试过的一个导出的excel功能,在office2003下打开正常,但是在office2007下打开却出现乱码现象)。

现在的很多系统都有导出ExcelWord功能。同时要注意向前兼容和向后兼容的问题。

 

常见问题七:

分辨率

客户端的页面在市场上主流显示器的分辨率显示下页面显示要正常,包括滚动条也要正常。

举例:以前的项目的某系统以前在1024*768分辨率下出现数据显示不完全正确。以前在中提缺陷管理系统提交过该缺陷。

 

常见问题八:

互动性

对于所有的删除信息在删除之前都要给出是否删除确认的提示或者放弃的提示。

扩展下:不仅仅是删除,包括危险操作之前、或者改变数据状态等。

 

常见问题九:

易用性

对于要求用户大量录入信息的页面,要支持Tab键的输入,Tab键的走向要一般要遵循从做左到右,从上到下的的原则。

 

常见问题十:

错别字

另外,要对程序中的错别字进行检查,比如把“登录”写成“登陆”;把“我同意”改成“我统一”。

目前:很多外面的系统都把“登录”写成“登陆”,其实这样是不正确的。

举例:如果系统中首页中的错别字,属于优先级比较高的问题。

比如下图就是我们的系统中《专题教育》首页。

 

常见问题十一:

安全性

SQL注入

SQL语言对于特殊字符的处理,尤其是查询语句的单引号的处理,

Sql注入本质有2个关键条件:

第一个是用户能够控制输入。

第二个是原本程序要执行的代码,拼接了用户输入的数据。

比如在文本框中输入‘ or 1=1,看是否构成:

Select * FROM member Where username='magci'and password='' or '1'='1'

1=1’是永真的,这条SQL语句是能通过验证的。

安全性举例:

上海食药监项目

 

常见问题十二:

安全性

任一输入文本域输入:<script>alert(hello);</script>,提交保存,下次再次访问时,直接把用户的输入直接反射给浏览器,如下图:

 

常见问题十三:

安全性

现在网站开发已经注意到:登录网站进入其内部网页后,直接拷贝网址,然后粘贴到另一IE 窗口输入,在其他机器上看是否可以绕过登录直接访问。

 

常见问题十四:安全性

对于需要登录的系统,在用户不操作的一定时间内,出于安全性考虑,最好要让用户重新登录才能重新使用该系统。

 

常见问题十五:

安全性

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

 

常见问题十六:

安全性

安全缺陷还可能存在于弹出的子窗口。有些设计不严格的软件,在主页面关闭的时候子页面还可以运行,这是一个缺陷。

 

常见问题十七:

互动性

如填写资料有错误的时候,应该能够提示错误的位置,让用户知道到底是哪些地方输入的不正确。

 

常见问题十八:

互动性

软件在需要用户输入信息的时候,特别是填写个人信息的资料的时候,必填项后面,一律要用*等醒目的提示。让用户知道这个地方是必填写的

 

常见问题十九:

下拉框不选值的时候,应该有个默认值,并且要多检查程序中多处下拉框,因为很多情况下下拉框取不到值。

我们的有些系统,有些地方,现在的下拉框取不到任何值

 

常见问题二十:

程序人员经常在程序中加入调试信息,后来又忘记删除这些调试信息,这些调试信息给用户造成误解,认为该调试信息是系统严重的Bug

程序提交测试之前,程序员必须要删除该类型的调试信息。

 

常见问题二十一:

新增/修改信息保存提交后,系统应该给出“保存/提交/修改成功”提示信息,并自动更新显示。

保存文字的时候没有成功提示,不过能成功保存就算了。?

 

常见问题二十二:

编辑功能

对于编辑功能,点击“编辑”后,所有的值都要默认保持编辑前的初始值。比如某员工的籍贯是“上海市”,点击“编辑”按钮后,在籍贯这个地方默认的仍然是“上海市”。

其他字段信息也是如此。

 

常见问题二十三:

界面UI

界面布局缺陷:比如“删除”按钮和“保存”按钮挨得很近(这样很容易造成用户的误操作)。(注意关闭、删除、退出按钮与保存、下一步等按钮的距离。类似的按钮应按此规则排列分布。另外,注意按钮的大小是合理一致。

界面上删除按钮和保存按钮挨得很近。结果有些操作不熟练的业务人员,很容易误按,因此注意关闭、删除、退出按钮与保存、下一步等按钮的距离。类似的按钮应按此规则排列分布。

 

常见问题二十四:

资源释放

对于数据库有连接打开的地方,使用完毕要关闭。文件打开也要关闭。否则会造成系统资源内存泄漏。

这样的问题,要在编码阶段就需要避免,否则到最后上线或者用户使用阶段暴露出这样的问题,那用户体验就不是一般的差了。

从程序员的角度考虑——数据库连接使用完毕要关闭,文件打开要关闭

测试人员的角度考虑——系统越来越慢,甚至每隔一段时间需重启服务

 

常见问题二十五:

性能体验

对于经常大数据量的查询,对于查询的关键字段是不是要考虑使用到索引等或者其它方法提高查询的效率,2-5-8原则。

 

 

常见问题二十六:

容错性

需要做校验,如果校验不对需要在处理之前要有相关的提示信息

1       长度校验

2       数字、字母、日期、附件的大小等等的校验

3       范围的校验

比如:食药监项目中,上传附件的大小——系统异常。请检查下食药监的哪个模块?

再次强调:只要是用户输入的地方,也是最容易出问题的地方

 

常见问题二十七:

压力之下

软件在压力之下容易出错,比如:

下图为我们公司自己开发系统,在多用户并发压力测试情况下,学生学习时长为负数

 

常见问题二十八:

接口

程序在接口方面容易出错

1:内部接口问题(集成测试没做好)

2:外部接口

1)我们以前做电商的时候,网上订酒店的时候,用第三方酒店数据接口问题

2)我们自己做的教育OA项目的短信接口

 

补充一:软件测试注意的事项-测试人员如何迅速找出问题的经验

首先测试经过变更(修改的功能)的部分,然后测试没有变化的部分。修改和更新都意味着新的风险。

首先测试核心功能,然后测试辅助功能,测试产品所完成的关键和常用功能,测试完产品基本任务的功能(法院审判软件,首先一定要保证整个审判的流程能跑通)。

首先测试能力,然后测试可靠。先测试每个功能是否完全能用,然后在深入检查任何一个功能在很多条件不同条件下的表现如何。

首先测试常见情况,然后测试少见情况。使用常用的数据和使用场景。

首先测试常见威胁,然后测试罕见威胁。用最有可能出现的压力和错误情况进行测试。

首先测试影响大的问题,然后测试影响小的问题。测试在失效的情况下会产生大量破坏的产品部件。

首先测试最需要的部分,然后测试没有要求的部分。测试对团队其他人有重要意义的任何部分的任何问题。

 

补充二:测试人员一定要熟悉公司相关的业务

欧莱雅无线POS销售系统测试的时候,其中有个测试人员做的就很好:因为这个测试人员的优点是非常熟悉销售、促销、羽西会员,薇姿会员的业务等。另外,比如测试ERP软件的测试人员,肯定要对ERP的运作模式很熟悉,才有可能找出软件的缺陷,尤其是业务上的软件缺陷才是有价值的缺陷。

如果这点做不到,那么测试人员找出的软件缺陷肯定是纯软件的缺陷,价值不大。

所有的软件测试都是建立在业务之上的!

 

说明:提高公司的软件产品质量不是仅仅靠增加几个测试人员就能解决问题的,高质量的软件产品依赖与整个项目组中所有成员的共同努力比如:需求的明确与否,时间进度压力,开发人员的水平高低,开发人员的责任心,测试人员的水平与责任心,以及软件开发各个阶段的评审等工作。

 

金朝阳

2016717

展开阅读全文
博主设置当前文章不允许评论。

没有更多推荐了,返回首页