如何建立测试思维,如何去创建一个优秀的测试用例

对测试岗位的新人来讲,最重要的是如何建立测试思维,测试思维不是用户思维,很多人刚进入测试行业是完全把自己当做一个用户,模仿用户的行为去做测试,其实这是远远不够的,测试岗是软件质量保障非常重要的一环,我们不光是要面向功能性做测试,也要面向非功能性做测试,不光是测试软件的正常输入,也要测试软件的非正常输入;这样我们的测试用例才能覆盖的更全更广;

这里我选择大家都非常熟悉的、也是基本都做过的一个业务场景就是“用户登录”业务来举例,这个业务场景不光是大家都接触过,更是面试的时候面试官最喜欢问题的一个问题,通过这个问题,面试官就可以深入的了解到面试者他的测试功底到底如何;

这样一个大家都接触过的,看似简单明了的业务也许你会觉得太简单了,只要在界面上输入用户名和密码,然后点击登录按钮,发起登录请求,验证一下是否登录成功就可以了。但作为测试人员来讲我们不光是要走一个正常的业务流程,你更需要确保这个登录功能在各种应用场景下的功能是符合设计要求的,因为你是无法找到我们的客户会做哪些奇奇怪怪的操作的,甚至我们的客户可能都不是人,是电脑在模拟登录,所以你需要考虑的测试用例就需要更多、更全面,于是可能会有以下用例,比如:

1、输入已注册的用户名和正确的密码,验证是否登录成功;

2、输入已注册的用户名和不正确的密码,验证是否登录失败,并且提示信息正确;

3、输入未注册的用户名和任意密码,验证是否登录失败,并且提示信息正确;

4、用户名和密码两者都为空,验证是否登录失败,并且提示信息正确;

5、用户名和密码两者之一为空,验证是否登录失败,并且提示信息正确;

6、如果登录功能启用了验证码功能,在用户名和密码正确的前提下,输入正确的验证码,验证是否登录成功;

7、如果登录功能启用了验证码功能,在用户名和密码正确的前提下,输入错误的验证码,验证是否登录失败,并且提示信息正确。

等等…

有了以上的测试用例,我们是不是可以说已经大功告成了呢,因为基本上把我们该列举的操作都包含在里面了;
确实,以上的测试用例集已经囊括了主要的功能测试的场景。但是在一个优秀的测试工程师眼中,这些用例只是一个刚刚及格的水准。下面我们看一下有一定经验的测试工程师会再增加的测试用例:

1、测试用户登录的会话超时时间是否符合预期;

2、同一账户是否支持多浏览器同时登录;

3、用户名、登录验证码是否大小写敏感;

4、后台系统创建的用户第一次登录成功时,是否提示修改密码;

5、如果登录功能需要验证码,登录失败是否会自动刷新验证码;

6、点击验证码图片是否可以更换验证码,更换后的验证码是否可用;

7、如果验证码具有时效性,需要分别验证时效内和时效外验证码的有效性;

8、用户登录成功但是会话超时后,继续操作是否会重定向到用户登录界面;

等等…

看完这些用例,是不是觉得原来可以有这么多的测试用例。但是,正如开头所讲,一个软件除了能性测试外,它的非功能性测试也是非常重要的。软件功能性指的是软件提供给用户非常明确的可以看得着的业务功能,比如“正常用户使用正确的用户名和密码可以成功登录“、”非注册用户无法登录”等,。那什么是非功能性呢?我认为非功能性主要是安全性、性能以及兼容性。在上面所有的测试用例设计中,我们完全没有考虑对非功能性需求的测试需求,但这些往往是决定软件质量的关键因素。那么我们来看一下会包含哪些内容呢?

安全性测试用例包括:

用户密码在数据库中存储是否加密;

密码是否允许使用简单密码;

用户名、密码在网络传输过程中是否加密;

用户的核心个人信息在传输过程中是否加密比如手机号、身份证号;

不登录的情况下,在浏览器中直接输入需要登录后才能使用的 URL 地址,是否会重新定向到用户登录界面;

密码输入框是否不支持复制和粘贴;

用户名和密码的输入框中分别输入典型的“SQL 注入攻击”字符串,验证系统的返回页面;

用户名和密码的输入框中分别输入典型的“XSS跨站脚本攻击”字符串,验证系统行为是否被篡改;

连续多次登录失败情况下,系统是否会阻止后续的尝试以应对暴力破解;

同一用户在同一终端的多种浏览器上登录,验证登录功能的互斥性是否符合设计预期;

同一用户先后在多台终端的浏览器上登录,验证登录是否具有互斥性。

性能压力测试用例包括:

登录页面从请求到渲染完成的时间是否在3秒内;

用户登录请求发起到响应过来的时间是否小于3秒;

同一时间发起大量的登录请求是否会有高延迟问题;

高并发场景下用户登录的响应时间是否小于 5 秒;

高并发场景下服务端的监控指标是否符合预期;

高集合点并发场景下,是否存在资源死锁和不合理的资源等待;

长时间大量用户连续登录和登出,服务器端是否存在内存泄漏。

兼容性测试用例包括:

不同浏览器下,验证登录页面的显示以及功能正确性;

不同浏览器下,打开f12控制台是否有js脚本错误;

相同浏览器的不同版本下,验证登录页面的显示以及功能正确性;

不同移动设备终端的不同浏览器下,验证登录页面的显示以及功能正确性;

不同分辨率的界面下,验证登录页面的显示以及功能正确性。

说到这里,你还会觉得“用户登录”功能的测试非常简单、不值一提么?一个看似简单的功能测试,居然涵盖了如此多的测试用例,除了要覆盖明确的功能性需求,还需要考虑其他诸多的非功能性需求。另外,通过这些测试用例的设计,你也可以发现,一个优秀的测试工程师必须具有很宽广的知识面,如果你不能对被测系统的架构、关键的业务实现有深入的理解、不明白一些网络安全的基本知识、没有掌握性能测试的基本设计方法,很难设计出“有的放矢”的测试用例。通过“用户登录”功能测试这个实例,我希望可以激发你对测试更多的思考,并且开拓你设计测试用例的思路,以达到抛砖引玉的效果。

猜你喜欢

转载自blog.csdn.net/waitingwww/article/details/121410242