一个软件测试工程师发展到性能测试工程师的蜕变之路.docVIP

一个软件测试工程师发展到性能测试工程师的蜕变之路-纯经验分享 对任何事物,你都感兴趣,所以每当付诸实行时,你都觉得有无限的生机到来,而且从不会错过机会.虽然在短暂的人生里,你也可以体验到很多有意义的尝试. ——佚 ? 初识软件测试 这是一个杯子，主要用来喝水的，如何对它进行全面的测试分析？” 这是在第一次进入上家公司面试时，测试主管问我的题目，相关的回答已经有点模糊，但从这个问题可以大概了解到，测试主管在考察我的软件测试思维。 首先，显性需求，首先应该是杯子，不是瓶子、罐子等，用途是喝水的；隐性需求会比较笼统有些，如大小、高度、容积、制作材料、温度承受范围，还有一些其他细节如颜色、边角圆滑等。 其次，如何去准确获取、表现这些需求，即相关指标数据是多少。如要知道大小、高度、容积，得用到相关测量工具，如尺子、圆规。要知道温度承受范围，可能要用到温度计等。 在完成软件测试工作期间，测试用例设计、执行之前必须清晰了解原始需求（包括隐性需求），再之后需要有对应的测试方案，需要执行哪些类型的软件测试，要用到什么软件测试工具等。 功能测试实践 测试用例 在接下来的一年时间，让我真正接触到了项目开发、交付的实际生产过程，简而言之就是，工作任务是无止境的，永远有数不尽的需求要开发、测试，有茫茫多的Bug要跟踪。如何在这中间保持自己清晰的定位显得至关重要。由于在项目组中只有我一个测试人员，s所以我还是比较忐忑的。 　　测试主管了解之后，跟我强调了几点： 　　1、测试的依据，需求基线要清楚，要尽早参与； 　　2、测试要有计划方案，要有用例设计 　　3、Bug的跟踪，要有自己的主见、原则； 　　4、测试结果的把握，要有结果分析。项目的上线，要综合你的以上测试过程，结合目前的情况总结报告，甚至是项目经理也要听取你的意见。你的角色不仅是测试，也是质量保证。 　　当然，以上的情况只是测试中遇到问题的一点点，如沙漠中的一粒沙（这孩子究竟怎么过来的），但也让我认识到测试是独立的、重要的。 　　在后来的项目测试工作中，践行测试主管传递的思想原则的同时，我并行了解相关测试书籍、工具、技能，结合工作进行相关实践，逐渐地我的测试能力越来越强。 　　总结了下，有几个方面问题： 　　1、既定清晰的需求都有按要求实现，只不过实现方式不合甲方胃口，如图表不够丰富，只有概要，没有详细。 　　2、系统界面没有统一的样式，甲方不客气的说像草稿。 　　3、流程没有体现甲方日常工作内容、步骤。 　　4、风控系统很肤浅，指标不实用。 在这个测试过程中，我比较正式地参加甲方组织的各种需求讨论会议，期间也认识到原始需求到需求基线其实还是有设计落实过程的，其把握的度就要看负责人或产品经理的灵性了。作为测试人员，在需求评审过程中就要对比原始需求（要详细了解具体日常工作内容，行业特殊性等）和需求基线的不同，给予自己的意见，在测试过程中不时提醒自己。而对需求的理解是否深刻，有时候不是参加正式需求评审就能达到的，还需要深入到用户实际的工作场景，了解实际业务和流程。而对于自己无法准确把握（风控系统），用户又无法准确提供的需求就要定好界限，实现到什么程度。最后，好用的软件不仅是功能的实现，一个界面样式都能让你从头再来。原计划短期内交付的项目，由于后续各种修改需求一直到了次年3月，才基本结束相关测试活动。 性能测试实践 　　在此，额外截取下当时某个业务场景测试的结果数据（当时用表格记录 　　执行这次测试之后，了解到同性能测试如下相关信息： 　　1、系统的部署组成，相关的服务器有哪些（此时还不知道具体的网络拓扑结构）。 　　2、相关场景的选择依据。 　　3、工具的使用，脚本的录制。 　　4、主要性能指标。 　　5、基于工具结果的简单分析。 　　后续的项目测试过程中，也有从事性能测试相关经历，让我记忆深刻并且获益良多的是陕西地税的网上申报项目。 　　陕西网报项目的相关合作方有多个，网络、防火墙、CA认证服务、核心申报等分别是不同的公司负责交付，如果测试过程中有出现问题，往往不好定位是谁的责任。在这种情况下，了解系统的网络部署拓扑结构尤为重要，之后才是具体的测试场景开展。 　　1、熟悉了解网络拓扑图，相关机器、服务器的物理及网络部署，为之后进行分层次测试做好准备。 　　2、并发数的计算，按照计算公式C=nL/T（C代表并发数，n代表平均在线人数，L代表场景操作时间，T代表场景考察时间）是比较理想化的，由于项目并没有相关措施监控，因此难以获取到平均在线人数、操作时间等具体参数。这时就要结合实际系统使用情况考虑。如系统纳税人总数及申报总数，每月申报时间（1日到15日，一般最后一周或者3天为大多数），每天申报时间（上午9：00-12：00以及下午14：00-17：00）等信息去计算出每秒事务吞吐量即可得到并发数（事务吞