6. 网络性能测试
　　基于硬件的测试：主要是通过各种软件工具，仪器等测试整个系统的网络运行环境，一般由系统集成人员负责 ；
　　基于应用系统的测试：主要测试用户数目与网络带宽的关系，通过测试工具准确展示带宽，延迟，负载和端口的变化是如何影响用户响应时间的；
　　网络性能测试的用例设计主要针对后一种类型，可以独立进行测试，也可以和用户并发性能测试，疲劳强度与大数据量测试结合起来，在原有的基础上采用工具来调整网络设置，从而达到监视网络性能的目的；如下网络性能测试用例；
　　目的： 测试系统运行在不同网络带宽条件下的性能情况，以及与并发用户数量的关系；
　　方法：在不同的广域网带宽下使用LOADRUNNNER录制邮件系统得相关事务操作脚本，然后以不同的带宽和并发用户数进行压力测试，并记录在各种用户条件下各种事务的响应情况，同时记录路由器端口的流量和其他数据；
　　运行时间：
　　并发用户数与事务响应时间：
　　7. 服务器性能测试
　　服务器性能测试主要是对数据库，WEB服务器，操作系统的测试，目的是通过性能测试找出服务器的瓶颈，为系统扩展，优化提供相关的依据；分为：
　　高级服务器性能测试：在特定的硬件条件下，由数据库，WEB服务器，操作系统相应领域的专家进行的性能测试；
　　初级服务器性能测试：在系统运行前面的性能测试时，通过测试工具对数据库，WEB服务器，操作系统的使用情况进行监控，然后进行综合分析，找出系统瓶颈；性能测试的主要目的是在软件功能良好的前提下，发现系统瓶颈并解决，而软件和服务器是产生瓶颈的两大来源，因此服务器测试一定要和前面的测试结合起来进行；在进行用户并发性能测试，疲劳强度与大数据量性能测试时，可以完成对服务器的监控并对服务器性能进行评估；这类部分的测试用例一般不必单独编写。
四、WEB性能测试用例设计
　　WEB 性能测试用例设计模型是设计性能测试用例的一个框架，在实际项目中，需要对其进行适当的剪裁，从而确定性能测试用例的范围和类别，裁减的依据是性能测试策略和测试范围；在测试用例主要框架确定后，接下来要如何设计各类性能测试用例中具体数据。
　　基于用户的测试多在用户现场进行，而为了测试目的而进行的测试多在开发环境即开发团队的内部进行；为了测试目的而设计的测试用例场景主要根据测试设计人员的经验来进行，但是仍要参考用户的实际场景，用户实际使用场景是设计所有测试用例的依据，性能测试用例设计首先要分析出用户现实中的典型场景，然后参照典型场景进行设计。比较常见的用户场景有如下三种：内不同时段的使用场景；系统运行不同时期的场景；不同业务模式下的场景；各类测试用例设计的细节：
　　1. 确定用户使用系统情况的方法
　　确定用户对系统的使用情况是设计用例具体数据的基础，后面并发用户数据设计，疲劳强度设计以及各种场景设计都要依赖对用户使用系统情况的分析，分析用户使用情况经常采用现场调查和分析系统日志两种方法；
　　用户现场调查：通过和用户进行沟通，可以确定用户的人员组成情况；这类方法适用于用户群体固定且目标测试系统没有投产前的情况；
　　分析系统日志：当用户比较分散，现场调查比较困难时，可以采用对系统日志进行分析的方法，作为对用户现场调查的补充；
　　2. 并发用户数量设计
　　设计并发用户数量前，首先要了解确定系统大并发用户数量的方法；可以根据系统的大使用人数或者大在线数量来评估大并发用户数量的方法；
　　极限法：取大在线用户数作为大并发数，这种方法适用于系统已经投产目标用户群体不确定的门户网站，可以通过分析日志来进行测试；也可以使用系统已经注册的用户数量作为系统的用户数量，按照经验公式来估算大用户数量；
　　用户趋势分析：对软件生存周期内的用户未来走势进行分析，预测系统可能达到的大使用用户数目，从而估算系统的大并发用户数目，这种方法多用于用户数目逐渐增多的情况；
　　经验评估法：多用于系统的使用用户数目相对稳定而且比较明确的系统；
　　并发用户数量的设计基本是按照大并发用户的数量的百分比来设计的，对于某一特定的用例，需要注意：
　　一按照各类用户同时递增的方式来设计用户数量，是为了按照由浅入深的方法来发现系统的瓶颈；二并发用户的大值一般不会超过前面计算的大并发用户数量的 20% ，除非是为了测试系统能支持的大并发用户数量；三设计用户数量时要考虑成本，因为每组用户数都意味着至少执行一次测试；
　　3. 系统不同时间段场景的设计
　　不同时间段的场景更接近用户使用情况，它也是设计核心模块和组合模块并发性能测试用例的基础，不同时间段场景分析的数据主要是前面的需求分析和日志分析结果；不同时间段场景的设计基本原则有两个：一是选择典型的场景进行测试；尤其要选择场景中并发用户数目较大的场景；二是要覆盖全面，设计出的用例要覆盖到压力可能较大的时间段；用户场景的设计一般与后面的业务模式结合起来进行；
　　4. 业务模式的设计
　　业务模式的设计是不同时间段场景设计的特例，也是设计核心模块和组合模块并发性能测试用例的基础，设计业务模式的目的是专注于某些功能模块的组合，按时间段来设计场景通常会涉及很多模块，如果系统存在的由应用软件引起的瓶颈则很难定位，所以才抽象一些特定的业务模式来进行用例的设计；
　　按照业务模式和时间段的场景来设计性能测试用例时，会涉及到如何设计每个模块并发用户数目的问题，通常会取各个相关模块在24小时内大的并发用户数目进行组合；
　　5. 大数据量测试用例的设计
　　历史数据相关的大数据量测试设计与并发用户的测试设计很类似，首先要确定系统数据的长迁移周期，确定了系统的大数据量后，接下来选择一些前面的核心模块或者组合模块的并发用户测试用例作为其主要内容即可；
　　运行时大数据量测试主要根据模拟系统运行时可能产生的大数据量来进行测试，这类测试用例通常根据实际情况去分析设计；
　　6. 一些特定测试用例的设计
　　疲劳强度测试，大用户测试，容量测试等一些特殊的测试用例设计，根据用户的需求进行，这类用例的相关要求通常十分明确；
　　性能测试用例重要的是注意用例间的关系，孤立的设计各类用例只能增加测试成本，浪费人力。性能测试用例设计人员应该追求设计既能覆盖性能测试需求，又能以较低的成本来执行测试用例；
　　五、WEB性能测试用例设计总结
　　1. 测试用例可用性总结
　　对于一个比较完善的性能测试项目，经常会有一些测试用例不能执行，，因此测试完成后应该分析哪些用例不能执行以及不能执行的原因，这样可以为下次测试打好基础。
　　2. 用例执行效果分析
　　通过对用例执行效果进行分析，可以为升级或者开发新的性能测试用例提供有利的参考，不是所有的用例都能导致系统瓶颈的出现，因此应该分析哪些用例能够发现系统问题，哪些用例执行时没有太大效果。分析那些设计好的用例不但有助于以后设计用例，还可以为再次执行提供参考：当下次测试进度压力较大时可以先执行重要的用例，跳过那些尝试性的，不容易发现问题的用例；
　　3. 用例执行时间分析
　　分析用例的执行时间是为下次规划性能测试提供参考，由于很多用例执行时间不是特别确定，导致性能测试计划也具有一定的不确定性。通过分析用例的执行时间可以为以后的制定测试计划提供参考；
　　总之，性能测试用例的设计是需要通过不断分析总结才能做好，不但要分析性能测试用例的可用性，执行效果，执行时间，还应该分析用例的设计方法，设计思路等。