我们在变化中成长。假设你拒绝了变化，那么，你就拒尽了新的美丽和新的机遇。

初始软件测试

“这是一个杯子，主要用来喝水的，它的质量应该如何考量

总结了下，有几个方面问题：

1、既定清晰的需求都有按要求实现，只不过实现方式不合甲方胃口，如图表不够丰富，只有概要，没有详细。

2、系统界面没有统一的样式，甲方不客气的说像草稿。

3、流程没有体现甲方日常工作内容、步骤。

4、风控系统很肤浅，指标不实用。

在这个测试过程中，我比较正式地参加甲方组织的各种需求讨论会议，期间也认识到原始需求到需求基线其实还是有设计落实过程的，其把握的度就要看负责人或产品经理的灵性了。作为测试人员，在需求评审过程中就要对比原始需求（要详细了解具体日常工作内容，行业特殊性等）和需求基线的不同，给予自己的意见，在测试过程中不时提醒自己。而对需求的理解是否深刻，有时候不是参加正式需求评审就能达到的，还需要深入到用户实际的工作场景，了解实际业务和流程。而对于自己无法准确把握（风控系统），用户又无法准确提供的需求就要定好界限，实现到什么程度。最后，好用的软件不仅是功能的实现，一个界面样式都能让你从头再来。原计划短期内交付的项目，由于后续各种修改需求一直到了次年3月，才基本结束相关测试活动。

完成定点联系企业管理系统的测试之后，我进入了电子办税服务厅项目组，在这里个人的业务掌握程度得到认可。首先，对核心系统（电子办税服务厅接口调用提供方）的相关业务（文书、申 等）熟悉，并与对应系统的中软项目组人员都可以打成一片（也是吸取在陕西时沟通不顺的教训，详细后面性能测试提到）。其次，对电子办税厅的需求理解充分，得益于当时的需求人员耐心引导（为了税务事业，头发都花白了的同事），最后是自己对相关系统的后台数据表结构都比较熟悉。出现问题之后，能快速的理清思路，定位原因。问题出现之后，当你有理有据的跟相关负责人沟通时，他们也会心悦诚服。在经过一年多的团队配合之后项目组启动跟金三对接工作（要2个月完成，又是看星星赏月亮的好时光），项目经理将接口联调的任务交由我负责，也是看在我对原有两方系统及人员的了解。

性能测试实践

测试当然不仅有功能测试。第一次接触性能测试也是在国税门户项目组，只不过测试对象不是国税门户 站。其实那个软件系统的具体业务我都不太清楚（惭愧），只知道是叫一户式查询系统。当时虽然了解过性能测试的原理，但是具体如何开展还是有点懵逼。在测试主管的协助指导下（说是一步一扶都不过分），艰难完成。

在此，额外截取下当时某个业务场景测试的结果数据（没有找到曲线图了，发一下当时用表格记录的数据，你没看错，是5并发时间95s！！！）

执行这次测试之后，了解到同性能测试如下相关信息：
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），项目组办公室、税局机房、联通机房等，还记得在机房呆过一个晚上之后，汗渍都是绿的。遇到问题找合作方沟通时，响应速度跟指标差的场景一样–慢。当然，自己的沟通方式也是有缺点的，比如跟合作方说你的系统有问题，不能仅是口头形式，要包含具体证据（ 错日志、测试结果 告等），并且定下解决时间，必要时还需要甲方在场。

但不管如何，最终是完成了原定的测试目标。过程是艰辛的，但让我在今后的做事方式更加有条理、按步骤、踏实、耐心。