执行这次测试之后，了解到同性能测试如下相关信息：
1、系统的部署组成，相关的服务器有哪些（此时还不知道具体的网络拓扑结构）。
2、相关场景的选择依据。
3、工具的使用，脚本的录制。
4、主要性能指标。
5、基于工具结果的简单分析。
原谅我当时的简单朴素，能把握的就这些了。
后续的项目测试过程中，也有从事性能测试相关经历，如税企通项目（C/S架构）、省国税门户网站等，但真正让我记忆深刻并且获益良多的是地税的网上申报项目。
网报项目的相关合作方有多个，网络、防火墙、CA认证服务、核心申报等分别是不同的公司负责交付，如果测试过程中有出现问题，往往不好定位是谁的责任。
在这种情况下，了解系统的网络部署拓扑结构尤为重要，之后才是具体的测试场景开展。
具体的测试场景开展：
1、熟悉了解网络拓扑图，相关机器、服务器的物理及网络部署，为之后进行分层次测试做好准备。
2、并发数的计算，按照计算公式C=nL/T（C代表并发数，n代表平均在线人数，L代表场景操作时间，T代表场景考察时间）是比较理想化的，由于项目并没有相关措施监控，因此难以获取到平均在线人数、操作时间等具体参数。这时就要结合实际系统使用情况考虑。如系统纳税人总数及申报总数，每月申报时间（1日到15日，一般最后一周或者3天为大多数），每天申报时间（上午9：00-12：00以及下午14：00-17：00）等信息去计算出每秒事务吞吐量即可得到并发数（事务吞吐量*业务场景时间）。
3、根据实际业务选择需要测试的业务功能场景。
4、性能测试场景，如系统最大并发数，单个节点最大并发数，不同网络接入点最大并发数，稳定性测试等。
5、其他指标如响应时间、资源使用。
…
确定以上方案和指标之后再进行具体的准备和执行。
执行过程中，当然不会那么顺利，开始从系统最外围即外网进行测试，结果不理想，那么就要定位原因，过滤出指标差的业务场景，然后单独测试，此时相关场景加上时间戳信息，再在各个服务器上采集日志，之后为了确认真实，再更换不同服务器地址进行测试对比不同接入点的结果。最后再拿具体的结果给对应的合作方讨论分析。
整体的设计方案执行下来，花了不少的时间。
具体执行测试时，公司内部的功能还算顺利，到分层测试时就比较麻烦。第一是需要在不同的办公地点进行（不能直接访问IP），项目组办公室、税局机房、联通机房等，还记得在机房呆过一个晚上之后，汗渍都是绿的。遇到问题找合作方沟通时，响应速度跟指标差的场景一样–慢。当然，自己的沟通方式也是有缺点的，比如跟合作方说你的系统有问题，不能仅是口头形式，要包含具体证据（报错日志、测试结果报告等），并且定下解决时间，必要时还需要甲方在场。
但不管如何，最终是完成了原定的测试目标。过程是艰辛的，但让我在今后的做事方式更加有条理、按步骤、踏实、耐心。
变化中成长
走过堤岸，有依依杨柳，迈入田野，是无边麦浪。人总会经历不同的旅途风景，在变化之间获得不同的成长见识。
第一份工作经历形成了我对测试的基本认识及工作方式，接到测试任务之后就会条件反射的设想需要开展的测试类型，相关方案。但对于这些工作是否可以更标准化、工程化的开展还只是一个朦胧的概念。
之后重新更换测试工作，工作开始并没有什么不同，只是测试执行之前要求必须编写测试用例。但随着时间的推移，让我体验到了不一样的氛围。
测试要尽早开始，并且排除随意性，有计划的进行，这是软件测试基础理论的原则之一。在公瑾，软件开发过程有比较完善的流程，期间测试人员要经过需求评审、测试用例评审、预测试评审（提交测试前的评审，由开发演示实现的功能）、测试报告评审等。在需求评审之后，要有详细的测试分析、用例，并且列入任务计划进行监控，用例的执行结果也可随时查看，了解测试进度。
落地手工功能测试的同时，我们在持续进行自动化功能测试和性能测试工作。
在很多公司看来，自动化测试是一个比较矛盾的事情，总要考量人力消耗和迭代发布版本维护原有脚本的成本。在没有建立自动化测试体系前，只能沦为个人兴趣或者形式。
我们的自动化测试工作到目前已经走过2年时间，自动化功能测试覆盖率达到95%以上，期间进行自动化测试的同学经历了从无到有，再到完整，并且常态化执行。现在使用Selenium分布式运行多台设备上的脚本，可以快速执行完原有功能的测试用例。在业务功能越来越复杂，测试用例越来越多的情况下，功能自动化测试的地位就越明显。
而对于性能测试，也变得相对易于开展。相关系统的用户使用场景数据可以轻松获取（比如并发数计算），测试执行也已经形成了一个常态化机制，不是经过某次测试之后就不再进行，或者优化后再次测试还需要人工再做一次。目前的接口性能测试和系统性能测试在确定业务场景和脚本后，具体的运行设计方案为自动每天执行，执行结果通过报表（不是测试工具本身的报表，而是测试结果保存到数据库后按照要求重新整理输出报表）展现，相关负责人可以通过结果进行选择性优化，然后再继续测试。
不管是功能自动化测试，还是接口、系统性能测试，我们都已实现工程化、自动化的工作方式，也践行了软件测试中经常提及的测试应该要持续进行的原则。
很容易发现，以前是一个人在摸索中战斗，不断的爬坑的测试过程，现在是工程化、自动化的在持续推进优化改进的过程。个人对体系趋势，优劣不言而喻。
以下是个人测试经验中的一些观点：
1、尽量把测试往前推，尽早发现，降低修复成本；
2、测试的目的不是发现Bug，而是预防Bug的发生；
3、通过各种技术手段和流程改进，逐步的解放公司内部测试人员，让他们把精力放在对产品的把握上。
特别是第2、3点，已经重新定位测试人员。而我们正在进行建设的自动化测试平台（ATP），她减低功能自动化测试的技术门槛，整合各种类型测试工作，及时反馈测试分析结果，提高测试效率的同时，将真正释放测试人员的能力，实现以上标准将不再是空谈。虽然我们现在不能说我们的测试工作已经达到这样的标准，但起码我们现已经走在正确的道路上。只要方向是对的，那么就一定会到达目标。
当然，不管有多好的工作起点平台，测试人员的素质才是决定最终测试质量的保证。在从原有重复的工作方式中解放后，测试人员的综合素质如所处行业知识、测试思维、测试设计方案都影响到具体的测试结果，这些都是工具、平台无法取代的。
测试勉励
IT工作是辛苦的，软件测试当然也不例外。每天执行用例、跟踪Bug，还要与开发、产品同学争吵PK，与人斗其乐无穷~但正是因为这些默默的付出，你让一场本该在用户面前发生的灾难，提前在自己面前发生了，你是否有一种救世主的感觉拯救了用户，也拯救了这一软件，避免了她被撇弃、卸载的命运。
如果对软件测试有兴趣，想了解更多的测试知识，解决测试问题,以及入门指导，帮你解决测试中遇到的困惑，我们这里有技术高手。如果你正在找工作或者刚刚学校出来，又或者已经工作但是经常觉得难点很多，觉得自己测试方面学的不够精想要继续学习的，想转行怕学不会的，可以加入我们，群。642830685，领取最新软件测试大厂面试资料和Python自动化、接口、框架搭建学习资料！
文章知识点与官方知识档案匹配，可进一步学习相关知识Python入门技能树首页概览211711 人正在系统学习中
来源：蜀山客e
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！