欢迎光临
梦想从学习开始!

BS软件测试要点总结!| 小熊测试

本文主要介绍 BS软件测试要点总结!| 小熊测试,小熊希望对大家的学习或者工作具有一定的参考学习价值,在测试领域有所提升和发展。

  所谓的浏览器服务器端测试,也就是常说Browse/Server(B/S)架构测试。是刚踏入测试行业的小白们,最先接触的测试。例如,业务逻辑很简单的门户**,业务较复杂的MES系统等。针对这类B/S架构的应用,在进行功能、自动化、性能、安全上有哪些重点呢?

  B/S架构功能测试

  B/S架构的功能测试相对来说是比较简单的,因为受到浏览器限制,往往不会出现什么复杂的操作,核心内容就是点完input点button,点完button点Link。但是B/S架构的测试却比C/S架构还麻烦,麻烦在技术上而不是业务上,而对于这里应用的功能测试主要需要注意以下几点:

  适配性

  这里主要指的是针对浏览器的兼容性,无论是从HTML到HTML5,或者是基本JS到Jquery等库,再说CSS的各个版本及调用方式的不同,都会带来在不同浏览器(IE7891011,Firefox版本太多了,Chrome几个主要版本,什么360,百度,搜狗,腾讯等等)不同的体验和感受。

  对于兼容性测试方面的内容,建议大家根据浏览器内核的不同,挑选有代表性的浏览器测试即可。当然,还有许多兼容性测试的辅助测试工具,自行百度,根据介绍挑选适合自己的就好。

  易用性

  B/S架构的易用性会比C/S更高,因为主要的操作都是通过鼠标左键来实现的,那么操作的距离,操作的步骤都是需要考虑的内容。虽然通过某些JS库或者Flex技术可以很好提供优秀的互动性,但右键的不支持和无法多层窗口,总是一个巨大的坑。除了鼠标以外,还有键盘结合鼠标的操作,也是易用性所要关注的部分。关于易用性,如果测试人员可以现实对用户的使用习惯进行调研,会对这部分的测试更有意义及针对性

 
 功能

  B/S架构的功能相对来说在业务上简单,在技术上难,由于客户端几乎无法实现业务的处理,所以所有的数据均要提交到服务器端来进行处理。对于这种情况验证的时候就比较强调以下两点:

  1.是否能够正确的发送数据到服务器端口,这个对抓包和理解包结构有一定的要求,也是大多数新手做功能测试最缺乏的技术。

  2.在服务器端处理返回的数据是否正确,同样也需要对抓包和包结构的理解有要求。

  通过这两点技术的突破后,B/S架构的测试会突然显的非常的简单,这也是在集成测试章节中所提到过的接口测试。

  在某些方面针对JavaScript的单元测试及动态调试也是功能测试中定位问题的一个有效手段。

  在实际执行测试中,大家普遍会觉得功能测试就是点点界面,没有什么技术含量。即便是停留在界面级别的功能测试,也可以很具有技术含量。这种体现就来自我们的功能测试用例,也是显示测试人员能力的主要标准之一。有时100条测试用例的执行结果,和1000条测试用例的执行结果是一样的。甚至后者还不如前者。所以需要大家考虑一下,我们怎样把测试用例写好?我们怎样通过测试需求的提取及业务理解后,在不影响测试覆盖度的情况下,用最少的测试用例达到最优的效果。没有几年的黑盒测试经验,你无法做到。所以看似简单的事情,永远是其他复杂事物的基础。盖房子要把地基打好了,这是很重要的。

  B/S架构自动化测试

  B/S架构的自动化测试应该算是比较成熟了,一方面是由于HTML或者JS技术相对来说成熟和规范的多,另一方面是UI未必是最重要的测试角度。

  通过DOM或者Xpath技术完成对对象的识别定位,框架即可准确的完成对元素的操作,这和JS本身的操作有很多类似之处。而如果不太在意UI部分,那么直接通过协议形式对服务器接口进行自动化测试,是更加高效的策略。

  B/S架构的自动化测试在UI方面主要还是浏览器兼容性测试,如果在静态部分针对HTML、JS、CSS进行有效的兼容性规范验证,那么效率和质量会进一步提高。

  随着测试技术的发展,曾经红遍一时的QTP也逐渐失去了部分市场,停留在UI层面的自动化也会被更好的测试策略所取代。对于.net支持优秀的Ranorex,对于浏览器兼容性测试的webdriver, 对于根据项目特色不同自行开发的自动化测试工具,这些都是未来发展的主流方向。需要我们不断学习,自学能力是小白们必备的基础。

  B/S架构性能测试

  B/S架构的性能测试是非常重要的也是相对来说比较简单的。一方面由于B/S架构无法评估客户端的数量,而且每一个用户对服务器的资源需求都要比C/S架构要高;另一方面B/S架构本质都是通过HTTP协议完成的,在报文结构和报文组织发送上非常的成熟。

  在B/S架构中性能测试的复杂在于两点:

  1.用户需求

  所谓的用户需求就是多少用户以什么样的规律来访问系统,访问系统的那些业务,在这种情况下需要评估系统能够支撑多少用户的这类行为,并且确保上线出现同样负载时能够正常合理的响应用户请求。

  这里对整个需求的把握、分析、引导都有较高的要求。网上有很多计算用户并发需求的公式,不得不说,大家不要迷恋公式,还是要从业务分析的角度去制定用户需求,这样才更具有实用性。

  2.脚本业务

  所谓的脚本业务也就是脚本中GET或者POST的Parameter是何含义,如何传输处理的。只有在理解了脚本业务后,才能正确的使用参数化、关联等脚本技术完成对用户行为的正确模拟,进一步帮助负载脚本正确的生成。对于脚本的调试等,大家可以通过对于接口的理解出发,这样能更有效的帮助大家彻底的理解,怎样做和为何这么做。

  B/S架构主要是针对服务器端的性能测试,但是对于客户端Browse也会有一定的性能要求,这方面主要在页面渲染和资源大小、网络传输有关。

  C/S架构安全测试

  B/S架构的安全测试往往是重点,因为可以注入的点实在是太多了,可以看到OWASP的前几名都是和B/S架构有关系的。

  无论是业务上的一些可能存在的时序或者注入,还是客户端的注入,都会带来十分可怕的结果,通过XSS完成Cookie窃取并且暴库的案例比比皆是。虽然有比较成熟的安全扫描工具可以帮助我们,但是并不代表就能够高枕无忧,这一块还是任重道远的。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持小熊分享邦(www.xxfxb.com),希望大家能坚持软件测试之路,谢谢。

赞(0) 打赏
未经允许不得转载:小熊分享邦 » BS软件测试要点总结!| 小熊测试

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏