育才学习网1. web应用软件的测试环境怎么写
定义测试策略 目前止您肯定参加议客户倚靠宽议桌问您：系统能处理千用户传统负载测试要求您编写脚本并执行测试试图给问题精确答案于种测试您需要定义处理含义及 1000 名典型用户站点情形您需要定义测试用例代表各种用户：例购买股票或注册新帐户接您必须估计用户些测试用例布数据进行假设即模拟真实用户与应用程序交互需要思考间（或等待间）负载测试期间某面致反映同数量真实用户站点情形 种几足处首先其结比您做假设更显确假设使结现偏差 其估计真实用户需要量客户端硬件每名虚拟用户给定需要处理能力内存量则典型客户端计算机处理约 200 名虚拟用户 2000 名用户并发处理级别测试需要 10 台客户端计算机 - 笔重投资测试使用 HTTPS 站点需要客户端硬件 终难向您发团队提供操作导向信息某处现故障难再现该问题 作备选案我建议您围绕些关键问题设计测试用例： ？？ 系统瓶颈哪系统能同步处理少并发请求 ？？ 响应间变接受前台机器能处理少名同步超级用户 ？？ 添加额外硬件结线形增 ？？ 任何稳定性问题妨碍站点运行于产环境 使用发团队（发团队参与能现问题领域）提供附加信息请关注些领域于示例其瓶颈能定单提交领域您派更具体问题例提交流程同处理少请求攻击些特定领域快且本用向发团队提供操作导向信息便能改进系统使用种同我推荐您记住遵循建议 关注负载测试我已提首先要做构建导致潜瓶颈稳定性问题脚本种数据第假设第二使您能够应用程序收集原始数据根据假设确定更高级别结用担识别低风险站点脚本编写问题例站点帮助领域或读文档领域编写脚本能现系统瓶颈 同步请求使用同步请求攻击瓶颈处主意模拟坏情况：即站点用户精确同间攻击瓶颈通使用户同步您重复进行测试同步结则难再现故障情况使用同步点做点同步点数较健壮（本较高）测试工具提供项功能同步点迫使每名虚拟用户直等剩余用户达脚本定义点才能始请求允许您精确并重复确定站点潜瓶颈区域能处理并发用户数例限 7 名并发同步用户 创建循环测试用例脚本使测试用例循环另种每测试用例迭代前站点应处于相同状态允许您间重复运行测试用例 使用超级用户使用我所称超级用户前面所提超级用户运行思考间设置零请记住思考间假设用于规测试使虚拟用户模拟真实用户虚拟用户思考间减半则服务器实际负载加倍另种服务器真关与负载关变量每秒请求数虚拟用户数量及其思考间结合起该负载 让我进行些数运算使概念更清晰面公式计算访问站点真实用户负载（请求数/秒）： 例某站点 100 名并发用户假设载间 10 秒思考间 30 秒则每秒 2.5 页我假设每页 3 请求则 Web 服务器转化每秒 7.5 请求 超级用户运行测试观察每秒请求数并与刚刚计算值比较根据我经验真实用户数与超级用户数比例通约 15:1于同示例意味着 （100/15） 名超级用户与 100 名普通用户相同负载再举例假设 10 名超级用户响应间变接受请注意转换真实用户数该点每秒请求数现您进行任何希望思考间假设甚至更改需重新运行测试几测试您能根据直觉超级用户数转换真实用户数允许您保持用户数控减少所需客户端硬件数量并包含负载测试软件本 些超级用户测试用例于机测试用要测试站点伸缩性添加第二台 Web 服务器负载平衡器并重复超级用户测试理想情况看见相同相应数前您能加倍超级用户数量 要答稳定性问题运行测试延间段内维持合理数量并发且未同步超级用户我项目熬通宵甚至 24 昼夜停持续间与应用程序关我称内置测试旦您已采取步骤识别并潜解决找瓶颈则重复同步点测试看限否所增用所支持新并发用户数重新运行内置测试努力提高数字目标重复该循环直达质量条 少用户呢 尽管向发团队提供价值信息使您更难于答议室问题您近似估计答案例假设站点坏情况瓶颈显示每台计算机于 20 名超级用户情况响应间超 10 秒根据您我建议公式计算结近似估计 300 名真实用户（20 名超级用户 * 15 名真实用户）您做与规用例相同假设通情况百少用户使用站点领域假设预期 50% 用户使用领域其领域例文档或数据库读取用户比例则没意味着具台 Web 服务器系统处理约 600 名用户 目前止我已讨论能明确指向站点瓶颈领域情况该何做影响性能领域止您应何做呢答案创建单独查看各领域测试脚本首先孤立运行些脚本起运行再比较结看站点领域另领域影响。
2. 软件测试环境
软件环境：从操作系统开始写，操作系统（Windows、linux）版本，浏览器（IE、firefox……）版本，把与被测网站系统有直接使用关系的软件都写入软件环境【所用的软件测试工具（缺陷管理工具、qtp、loadrunner……截图软件等）不能写入软件环境，独立出来单独写“测试工具”】，另外，如果电脑里还有与被测网站无关的软件也要全部加上，并且注明版本号（比如IE6、IE8、firefox3.0等）。
一般功能测试时对的要求是在干净的操作系统上进行，也就是说除了与被测系统有关的软件以外，不能带有其他软件，但如果有的话需要需要记录下来，以备bug再现时有依可寻。在做网站兼容性测试时应在被测电脑上安装上常用软件，看是否能与其他软件兼容。
3. 如果是测试环境写test或dev,如果是生产环境写什么
<profiles>
<profile>
<id>dev</id>
<properties>
<profiles.active>dev</profiles.active><；！--开发环境-->
</properties>
</profile>
<profile>
<id>test</id>
<properties>
<profiles.active>test</profiles.active><；！--测试环境-->
</properties>
</profile>
<profile>
<id>pro</id>
<properties>
<profiles.active>pro</profiles.active><；！--生产环境-->
</properties>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
</profile>
</profiles>
第三，在POM BUILD节点中增加如下配置
<resources>
<resource>
<directory>src/main/resources/${profiles.active}</directory>
</resource>
<resource>
<directory>src/main/resources</directory>
<excludes>
<exclude>test/*</exclude>
<exclude>pro/*</exclude>
<exclude>dev/*</exclude>
</excludes>
</resource>
</resources>
注意：尤其要注意，我们在配置这里的时候，主语顺序，否则配置不会生效的。要把需要过滤的放在最下面。
4. 软件测试的测试环境是什么
测试环境是指为了完成软件测试工作所必需的计算机硬件、软件、网络设备、历史数据的总称。
毫无疑问，稳定和可控的测试环境，可以使测试人员花费较少的时间就完成测试用例的执行，也无需为测试用例、测试过程的维护花费额外的时间，并且可以保证每一个被提交的缺陷都可以在任何时候被准确的重现。 简单的说，经过良好规划和管理的测试环境，可以尽可能的减少环境的变动对测试工作的不利影响，并可以对测试工作的效率和质量的提高产生积极的作用。
一、规划测试环境——让环境为你服务 对于“金山词霸”这样的软件，大多数测试工作都可以在一台单独的电脑上完成，而对于一套电信系统，为了执行测试用例，你可能会需要搭建一个由多台计算机以及其他网络设备组成，采用集群和负载均衡技术，并且接驳到Internet的计算机网络。 不同的行业应用，不同的质量目标，都可能会影响到测试环境的规划。
但从测试工作自身的要求来看，一条应当遵守的原则就是“尽可能的还原软件在用户那里最终实际运行的环境”——虽然在很多时候这是不现实的。^_^ 通常来说，我们所需要搭建的环境，主要是用于被测应用的系统测试——单元测试和集成测试由开发人员在开发环境中进行，而验收测试则在用户的最终应用环境中进行，因此都可以暂不考虑。
为了确定测试环境的组成，我们需要明确以下问题： 1。 所需要的计算机的数量，以及对每台计算机的硬件配置要求，包括CPU的速度、内存和硬盘的容量、网卡所支持的速度、打印机的型号等； 2。
部署被测应用的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本； 3。 用来保存各种测试工作中生成的文档和数据的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本； 4。
用来执行测试工作的计算机所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本； 5。 是否需要专门的计算机用于被测应用的服务器环境和测试管理服务器的环境的备份； 6。
测试中所需要使用的网络环境。例如，如果测试结果同接入Internet的线路的稳定性有关，那么应该考虑为测试环境租用单独的线路；如果测试结果与局域网内的网络速度有关，那么应该保证计算机的网卡、网线以及用到的集线器、交换机都不会成为瓶颈； 7。
执行测试工作所需要使用的文档编写工具、测试管理系统、性能测试工具、缺陷跟踪管理系统等软件的名称、版本、License数量，以及所要用到的相关补丁的版本。对于性能测试工具，则还应当特别关注所选择的工具是否支持被测应用所使用的协议； 8。
为了执行测试用例，所需要初始化的各项数据，例如登陆被测应用所需的用户名和访问权限，或其他基础资料、业务资料；对于性能测试，还应当特别考虑执行测试场景前应当满足的历史数据量。 当然，还有另外一个非常关键的问题：在测试过程中受到影响的数据如何恢复？ 明确了上面的问题后，明确哪些条件是可以满足的，哪些是需要其他部门协助调配、采购或者支援的。
建议在搭建测试环境之前，把上面的问题做成一张CheckList，并为每一项指定一个责任人，完成一项就填写一项，最终形成的文档则作为测试环境的配置说明文档使用。 当然，如果时间或其他条件允许，应当做好应急预案，尽量保证在环境失效时不会对正常工作产生太大的影响。