所谓的浏览器服务器端测试，也就是常说Browse/Server(B/S)架构测试。是刚踏入测试行业的小白们，最先接触的测试。例如，业务较复杂的MES系统等。针对这类B/S架构的应用，在进行功能、自动化、性能、安全上有哪些重点呢？
文章源自玩技e族-https://www.playezu.com/61802.html
B/S架构功能测试 B/S架构的功能测试相对来说是比较简单的，因为受到浏览器限制，往往不会出现什么复杂的操作，核心内容就是点完input点button，点完button点Link。但是B/S架构的测试却比C/S架构还麻烦，麻烦在技术上而不是业务上，而对于这里应用的功能测试主要需要注意以下几点： 文章源自玩技e族-https://www.playezu.com/61802.html
适配性 这里主要指的是针对浏览器的兼容性，无论是从HTML到HTML5，或者是基本JS到Jquery等库，再说CSS的各个版本及调用方式的不同，都会带来在不同浏览器（IE7891011，Firefox版本太多了，Chrome几个主要版本，什么360，百度，搜狗，腾讯等等）不同的体验和感受。 对于兼容性测试方面的内容，建议大家根据浏览器内核的不同，挑选有代表性的浏览器测试即可。当然，还有许多兼容性测试的辅助测试工具，自行百度，根据介绍挑选适合自己的就好。 文章源自玩技e族-https://www.playezu.com/61802.html
易用性 B/S架构的易用性会比C/S更高，因为主要的操作都是通过鼠标左键来实现的，那么操作的距离，操作的步骤都是需要考虑的内容。虽然通过某些JS库或者Flex技术可以很好提供优秀的互动性，但右键的不支持和无法多层窗口，总是一个巨大的坑。除了鼠标以外，还有键盘结合鼠标的操作，也是易用性所要关注的部分。关于易用性，如果测试人员可以现实对用户的使用习惯进行调研，会对这部分的测试更有意义及针对性 文章源自玩技e族-https://www.playezu.com/61802.html
功能 B/S架构的功能相对来说在业务上简单，在技术上难，由于客户端几乎无法实现业务的处理，所以所有的数据均要提交到服务器端来进行处理。文章源自玩技e族-https://www.playezu.com/61802.html
对于这种情况验证的时候就比较强调以下两点：文章源自玩技e族-https://www.playezu.com/61802.html
1.是否能够正确的发送数据到服务器端口，这个对抓包和理解包结构有一定的要求，也是大多数新手做功能测试最缺乏的技术。文章源自玩技e族-https://www.playezu.com/61802.html
2.在服务器端处理返回的数据是否正确，同样也需要对抓包和包结构的理解有要求。 通过这两点技术的突破后，B/S架构的测试会突然显的非常的简单，这也是在集成测试章节中所提到过的接口测试。 在某些方面针对JavaScript的单元测试及动态调试也是功能测试中定位问题的一个有效手段。 在实际执行测试中，大家普遍会觉得功能测试就是点点界面，没有什么技术含量。即便是停留在界面级别的功能测试，也可以很具有技术含量。这种体现就来自我们的功能测试用例，也是显示测试人员能力的主要标准之一。有时100条测试用例的执行结果，和1000条测试用例的执行结果是一样的。甚至后者还不如前者。所以需要大家考虑一下，我们怎样把测试用例写好？我们怎样通过测试需求的提取及业务理解后，在不影响测试覆盖度的情况下，用最少的测试用例达到最优的效果。没有几年的黑盒测试经验，你无法做到。所以看似简单的事情，永远是其他复杂事物的基础。盖房子要把地基打好了，这是很重要的。文章源自玩技e族-https://www.playezu.com/61802.html
文章源自玩技e族-https://www.playezu.com/61802.html
B/S架构自动化测试 B/S架构的自动化测试应该算是比较成熟了，一方面是由于HTML或者JS技术相对来说成熟和规范的多，另一方面是UI未必是最重要的测试角度。 通过DOM或者Xpath技术完成对对象的识别定位，框架即可准确的完成对元素的操作，这和JS本身的操作有很多类似之处。而如果不太在意UI部分，那么直接通过协议形式对服务器接口进行自动化测试，是更加高效的策略。 B/S架构的自动化测试在UI方面主要还是浏览器兼容性测试，如果在静态部分针对HTML、JS、CSS进行有效的兼容性规范验证，那么效率和质量会进一步提高。 随着测试技术的发展，曾经红遍一时的QTP也逐渐失去了部分市场，停留在UI层面的自动化也会被更好的测试策略所取代。对于.net支持优秀的Ranorex，对于浏览器兼容性测试的webdriver， 对于根据项目特色不同自行开发的自动化测试工具，这些都是未来发展的主流方向。需要我们不断学习，自学能力是小白们必备的基础。 文章源自玩技e族-https://www.playezu.com/61802.html
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窃取并且暴库的案例比比皆是。虽然有比较成熟的安全扫描工具可以帮助我们，但是并不代表就能够高枕无忧，这一块还是任重道远的。