1．职业人生规划 首先从大学开始着重培养综合职业素养，即在软件项目开发工程中即可扮演开发内角色，又可担当项目管理辅助角色。在校期间，曾在计算机系主任辅助下完成了人生第一个五年职业人生规划，并在校学习和实践期间逐步改善，并最终获得一个较为清晰的人生目标。在校期间，曾在多间直属公司工作。从软件开发、软件测试、项目管理以及商业策划都有所接触，并实际项目得到许多体验。从职业人生规划长远来看，目标定位在高技术高管理或高技术低管理两块发展道路。从职业规划近期来看，主要需要提高以下几个方面的职业素养：对测试产品的理解程度；对测试产品预见性错误的判断；对测试产品性能点把握；对测试方案的把握与规划；对测试内容的协调、归纳与总结；对测试结果的分析与判断等。

2．使用LoadRunner测试的过程中,你主要评估了产品相关的哪几个方面的性能?LoadRunner的参数是如何反应这些性能问题的? 综合指标： 1) 平均响应时间（Response Time）：需要再关注最快和最慢的响应时间。 2) 吞吐量（ThroughOut） 3) 每秒点击率（Hits per Second） 4) 每秒成功交易数（TPS） 5) 网络延迟（Network Delay Time） 6) CPU占用率 7) 内存使用率 8) 内存页交换速率（Paging rate） 9) 磁盘交换率（Disk rate） 10) 交易错误率 在实际测试过程中往往根据本次性能测试目的选择需要检测的测试数据。如产品稳定测试方案中，应当检测的数据包括应用服务器、数据库服务器、压力机本身资源监控（如：全局CPU利用率、内存交换、吞吐量、页交换率、进程活动状态、交换区所有磁盘的活动次数、磁盘I/O、磁盘利用率、磁盘等待队列、物理I/O、命中率等）、各事务响应时间、事务通过率、事务错误率、网络负载等。从稳定性测试方案本身来说，首先需要考虑场景设计中的并发用户数值大小，这个参数应该是该测试组综合性能的50％或者更低。由于并发用户数大小将直接影响，以上各监测参数的变化情况，并最终影响测试结果。由此，在设计稳定测试并发用户时，需要考虑压力机的最大承受人数、测试机组的最大承受人数以及在较大并发量下实际发生交易的次数。还可以监测到在同等压力情况下，实际发生交易的响应次数，如：前30分钟内每五分钟可新建10篇公文，在服务器发生性能问题时每五分钟可新建的公文仅为2篇。 1) 全局CPU利用率：一般控制在85％以下，当CPU负载长期高于90％时，一般系统会出现大量丢包行为，如：应用服务器与数据库服务器之间请求数不足，或者造成服务器前端Apache宕机或者直接造成应用服务器宕机等危险操作。CPU使用率过高还会出现，如点击率迅速下降，导致服务器交易次数减少等。 2) 内存交换率：对于Windows下的应用服务器而言，内存使用率一般不会超过80％。在前期使用JProbe监测工具对Windows下WAS监测中发现。实际WAS启动后，内存总占用率约为的50％－60％，即便发生内存泄漏或者其它由于内存造成的性能问题，内存使用率一般不会超过80％。而对于Linux系统，如Suse、RedFlagDC等，由于其本身的使用机制与Windows系统不禁相同，在使用内存分配时，一般先将剩余的内存提前分配给应用服务。如果另一个进程需要请求资源，再从已经分配内存中释放部分内存或着调配部分剩余内存供请求的对象使用。由此，再Linux系统中可以使用Shell命令来记录各个时段的实际剩余内存数。而通过LoadRunner或者Was自带的Tivoli监测并不能有限的进行跟踪。当内存交换率偏高时，可以说明当前系统请求进程数增加另一方面可以怀疑程序存在内存泄漏。 3) 吞吐量：以稳定性测试持续加压为例，吞吐量曲线应该保持较为均衡的波形图。每个峰波中峰值的出现应该在两个对等的时间内完成。如果出现峰值突然放量增长，可怀疑是由于网络原因（丢包、网络延迟>>10ms、网络时快时慢）、程序脚本原因（如：关联、404、500等）。一般选取峰值较为稳定和接近的几个性能点，展开下一步的压力测试。 4) 监测程序是否存在内存瓶颈主要参考以下几个数值： 很高的页交换率 进程进入不活的状态 交换区所有磁盘的活动次数可高 可高的全局系统CPU利用率 CPU：合理的使用范围大约为60％－70％，如果CPU占用率持续超过95％，则CPU可能成为系统瓶颈。 很慢的响应时间 CPU空闲时间为0 过高的用户占用CPU时间 过高的系统占用CPU时间 长时间有很长的运行进程队列 磁盘I/O：磁盘交换率一直很高，表明I/O可能有问题。 过高的磁盘利用率 太长的磁盘等待队列 等待磁盘I/O的时间所占的百分率太高 太高的物理I/O速率 过低的缓存命中率 太长的运行进程队列 5）事务响应时间：控件的下载速度、控件的内存消耗情况等 3.使用LoadRunner测试的过程中,场景设计应该注意什么? 个人觉得应该分为不同测试目的而分开描述，以下罗列了一些所在公司前人的经验和自己的对测试场景设计理解。 验证测试是用于验证在特定的场景、时间、压力、环境和操作方式下系统能够正常的运行，服务器、应用系统和网络环境等软硬件设施还能否良好的支撑这些情况下用户的使用。验证性测试主要针对有明确的压力目标和预期结果，验证系统在这种压力下的各方面反映能够达到预期结果。 主要分以下几种： a) 压力测试：已知系统高峰期使用人数，验证各事务在最大并发数（通过高峰期人数换算）下事务响应时间能够达到客户要求。系统各性能指标在这种压力下是否还在正常数值之内。系统是否会因这样的压力导致不良反应（如：宕机、应用异常中止等）。 b) 稳定性测试：已知系统高峰期使用人数、各事务操作频率等。设计综合测试场景，测试时将每个场景按照一定人数比率一起运行，模拟用户使用数年的情况。并监控在测试中，系统各性能指标在这种压力下是否能保持正常数值。事务响应时间是否会出现波动或随测试时间增涨而增加。系统是否会在测试期间内发生如宕机、应用中止等异常情况。 c) 容错性测试：通过模拟一些非正常情况（如：服务器突然断电、网络时断时续、服务器硬盘空间不足等），验证系统在发生这些情况时是否能够有自动处理机制以保障系统的正常运行或恢复运行措施。如有HA（自动容灾系统），还可以专门针对这些自动保护系统进行另外的测试。验证其能否有效触发保护措施。 d) 问题排除性测试：通过原有案例或经验判断，针对系统中曾经发生问题或怀疑存在隐患的模块进行验证测试。验证这些模块是否还会发生同样的性能问题。如：上传附件模块的内存泄露问题、地址本模块优化、开启Tivoli性能监控对OA系统性能的影响等等。 测评测试是用于获取系统的关键性能指标点，而进行的相关测试。主要是针对预先没有明确的预期测试结果，而是要通过测试获取在特定压力场景下的性能指标（如：事务响应时间、最大并发用户数等） a) 评测事务交易时间：为获取某事务在特定压力下的响应时间而进行的测试活动。通过模拟已知客户高峰期的各压力值或预期所能承受的压力值，获取事务在这种压力下的响应时间。 b) 评测事务最大并发用户数：为获取某事务在特定系统环境下所能承受的最大并发用户数而进行的测试活动。通过模拟真实环境或直接采用真实环境，评测在这种环境下事务所能承受的最大并发用户数。判定标准阈值需预先定义（如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等） c) 评测系统最大并发用户数：为获取整个系统所能够承受的最大并发用户数而进行的的测试活动。通过预先分析项目各主要模块的使用比率和频率，定义各事务在综合场景中所占的比率，以比率方式分配各事务并发用户数。模拟真实环境或直接采用真实环境，评测在这种环境下系统所能承受的最大并发用户数。判定标准阀值预先定义（如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等）。取值标准以木桶法则为准（并发数最小的事务为整个系统的并发数）。 d) 评测不同数据库数据量对性能的影响：针对不同数据库数据量的测试，将测试结果进行对比，分析发现数据库中各表的数据量对事务性能的影响。得以预先判断系统长时间运行后，或某些模块客户要求数据量较大时可能存在的隐患。 问题定位测试在通过以上测试或用户实际操作已经发现系统中的性能问题或怀疑已存在性能问题。需通过响应的测试场景重现问题或定义问题。如有可能，可以直接找出引起性能问题所在的代码或模块。 该类测试主要还是通过测试出问题的脚本场景，并可以增加发现和检测的工具，如开启Tivoli性能监控、开启HeapDump输出、Linux资源监控命令等。并在场景运行过程中辅以手工测试。

4.web的功能测试需要注意什么方面?

1) 测试用例计划（如：使用如何测试策略、如何的测试方法等） 2) 测试需求把握（如: 需求规格说明、设计文档等） 3) 测试环境的搭建（如：保证数据执行脚本版本与数据匹配、中间件服务器参数已全部优化、是否存在打包申请、是否有对包中代码行数记录、是否有对上一个版本中已修改的Bug进行描述） 4) 测试数据的准备（如：一些基础数据、基础信息等） 5) UI设计与操作易用性部分（如：是否符合客户的使用习惯、外观是否舒适、操作是否便捷，例如：OA系统中发送到最后一部时操作人员仅有一个时，是否考虑采用自动完成、列表上下翻页等） 6) 功能逻辑部分（如：OA系统中的公文流转、任务管理、分级管理、个人日程中的时间交集部分） 7) 数据迁移部分（如：数据从Db2迁移到Oracle或者反之是否可行，有多少成本，数据库脚本是否与包匹配、开发环境是否与测试环境一致） 8) 网络安全部分（如：是否存在溢出错误，远程提交错误与服务器本身的各种漏洞端口、操作系统最新补丁等） 综上所述，在实际项目测试中。个人认为功能测试重要之处是产品测试用例的抒写、维护和管理。以及在实际测试中，对测试Bug的描述 与跟踪。在产品发布前期对产品Bug的分类与归纳分析，并在一定辅助研发人员在同类开发中尽量减少下一次开发的实施成本。  

发表于 @ 2008年06月25日 18:46:31|评论(loading...)|收藏