我的测试五年

从事测试已经快5年了。觉得有必要来进行一下回顾和总结。
刚毕业那会儿，其实是计划选择开发的(java或者php方向),不过经过很长时间审视了自己写的代码，实在是拿不出手，而且也不想拿这类代码到公司害人，所以还是决定其他的方向了。
不知道什么原因，选择了测试。当时主要是看了下招聘的内容，
1.知识面很广，无论是编程语言类，还是服务器类，操作系统方面等等。其实大部分公司招的开发也是这样，好像国内的公司招聘都这样，动则精通这，精通那，整个儿需要的人才就是一个怪物；
2.分析能力啊；
3.主观能力；
4.沟通能力
还行，进入了一家台企。主要是测试操作系统和各个部件的驱动程序以及自带的应用程序。实际的工作相对来说比较简单：灌系统(windows,linux都有），装驱动。然后检查驱动程序对应的设备的运行情况。由于设备的种类很多（要涉及到兼容性），所以每天的工作基本上是穿梭于不同的设备之间。上手很快。慢慢走向指导别人测试，同时利用闲暇时间，对bug进行了总结。发现每个新的项目，对应的模块都差不多，所产生的缺陷的种类也差不多，缺陷的现象也差不多，于是对bug做了提取，做了一个简单的bug查询系统，主要是为了后面同事快速了解对应的模块，曾经有的缺陷是什么？有哪些现象？而且由于我们当时的缺陷是要求用英文描述，英文不好的或者描述不清楚的同事，参考里面的内容也大致能写成符合标准的bug(bug的描述有要求，而且组员的缺陷描述需要组长来检查。一个缺陷至少要两个人看过才能提交上去），后来还为大家搭建了一个论坛，供大家讨论系统，驱动，设备等等一些知识。在这里浑浑噩噩的工作着，虽然工作不是我想要但是我还没想好测试究竟是如何去做的。初步的印象是，看看大家掌握的信息由多少，分析能力几何。不过在这期间，我每周末都参见一个培训机构的软件测试(CSTQB认证），在这里接触了很多其他公司的人，以及测试方式方法。这份工作持续了两年，与此同时培训结束了。我换了新的工作了。


这次是在一个数据中心项目里做测试。
这个数据中心主要是提供外部服务接口和对行业数据进行处理。由于是创业型项目，所以一些基础类设置很少很少。刚开始的进去的时候，基本上什么都没有。而且每次数据库中用到的数据，都是手动插入进去的，中心的数据都是没有的。刚进去的那会儿，开发一边按照数据交换规范开发，完成对应的规范后，直接本地打包然后发给测试。测试部署在自己的电脑中开始。经过几个星期的熟悉，给项目经理提了意见:1.没有版本号 2.没有发布流程。 3.数据库也没有进行管理（规范变更时，数据库的结构也会变更，但是DBA可能会忘记提交脚本，而应用程序只有在使用了变更数据的时候才会发现数据库可能有问题）4.没有版本库。后来的工作，我们有了测试环境，建立了版本号（数据库和应用程序都有），发布流程--我们设计了冒烟测试用例，通过了才进行详细的测试 ；定期做基线版本；对缺陷比较多的地方做code review。而且，我将我测试的那部分进行了脚本化(也推荐另外一位同事把测试脚本化，解放自己)。只要冒烟测试通过，通过不停的调整脚本数据，就可以对提交的内容进行测试，效率很高。由于对数据中心的整体的流程和各个子系统很熟悉，所以我有一部分时间会去现场部署或者去分析现场的异常日志，还有一部分时间会去客户那边听取意见和建议。不过当时还没有其他公司做这个东西（医疗行业的数据中心），所以都是摸索着前进。客户的东西有部分太理想化，虽然我们系统的架构很灵活（到目前为止，我还觉得当时的架构还是很棒的)，想要完全符合客户的想法，还是很难的。而且接入数据中心的厂商不多，推广力度也不大。逐渐数据中心慢慢变成可有可无的项目。10个月后我离开了。


思索半天，决定去金融行业看看。进入了一家外包公司。不过这个行业没我想象的那样。限制诸多，往细方面的内容还真的是不好做。金融行业对测试的重视度其实很不好。由于是外包行业，去过两家，一家管理比较规范，标准的开发测试流程。只是开发测试的沟通很费事，不过有幸分析这类复杂的系统，后来又一次机会，进入了他们的敏捷项目组，虽然有一位敏捷顾问会客串项目组，不过实际下来，还是一路摸爬滚打。


一点体会：
很多同事都觉得测试很简单。其实也可以做的很简单：按照已有的流程，来什么测什么，检验对应的需求，把提供的都提供，至少对于工作来说，基本上没什么大问题。但是测试不是为了提交缺陷. 看到投入了那么人力物力，但是却提供了一个很蹩脚的产品，作为完美主义的你，会有什么感想？要做好测试，远远不是那么容易的。比如下面的几点：
1.系统架构的理解
架构体现了一个系统的灵活性。知道了架构，就可以明白你现在接触的系统或功能是处在哪个层次。什么样的数据流会经过这里，符合什么样的业务会到这里。
各个层次之间是如何衔接的。数据是怎么来的，要到哪里去，会被怎么用。这些基本上成为了我关注的目标。
架构的理解，也可以划分测试的等级。有些内容需要从接口层去测试会更方便。而接口又分内部接口和外部接口。如何正确测试是一个很值得研究的内容。
同时不同的接口层，可能需要测试人员有不同的技术来满足测试，取决于对接口采取的技术的理解。同时，性能测试也可以按照接口来划分。一级一级的来
判断是哪一层出现瓶颈。
没有哪一种测试能全部覆盖到所有的测试类型。如果真的这样，那真是一个庞然大物。对测试的分割是有必要的，特别是在大型系统中。
2.沟通
系统设计的最终目的是为了满足业务需要。从业务的提出，到设计，到实现，到成型。如何确保这就是用户真正想要的？
和用户的沟通是很有必要的。而且有时候改变用户的想法也是有必要的。很到一定程度上，自己也是这个系统是用户。业务是被冠名的用户代表。
遇到被业务牵着鼻子走的情况，业务一会儿说要着，一会儿说要那。结果大家做的都很迷茫。有一种不知道要做的东西是啥的感觉。
如何获取沟通的成效，如何帮助产品定型，作为测试人员，也有一定的责任。可以问自己一下：如果你都不知道这东西是啥，你怎么去检验它的各个质量，
确保它的价值？这个是沟通的一方面，还有的是对缺陷的沟通判断缺陷的等级以及潜在的影响范围。
3.测试的设计
测试的设计，除了直接的需求文档外，上面两个了解多少，也直接决定了测试设计的好坏。测试的模型有很多了，比如启发式测试，上下文测试，Use Case测试，
ET测试等等。测试的设计决定了后面测试执行的行为。
4.自动化
曾经在一次沟通中，我提出我的观点：并不是所有的东西都需要做自动化。比如对于页面校验的内容，没有做自动化的必要。
页面校验的内容，数据校验类，在手工测试就已经测试完毕，该修复的缺陷都已经得到修复，而且，这部分一旦完成，后面的编码工作基本不会再会涉及到。除非有新的需求，那么对应的新的测试也会覆盖到。
碰到一个可测性很差的系统，而且当时还打算引入自动化测试。结果发现，这个自动化无法继续做下去了。
当时做这个自动化的初衷是为了做业务回归的。对主要的业务，每次版本上次前，都做一下冒烟。而且这部分案例当时也打算放到持续集成环境中run的。
不过这部分一直由于某些原因，没能进行下去。印证那句：理想是很丰满的，现实却是很骨感。
这部分的感想是，提高系统的可测性以及自动化脚本的设计（可靠性，可伸缩性和可维护性），都是值得考量的。
5.性能
性能测试又是一个更深入的内容了。一直都没做好。希望后面有机会能做好一点。
总结下来，主要是条件不具备。我能想到的性能测试需要的资源：1. 架构师  2.DBA  3.网络环境（需要尽量模型生产环境）  4.性能指标    
性能在设计阶段就引入，也许效果会好些。
6.有所为有所不为。测试的工作，有时候能贯穿到市场，也有时候能涉及到运维。不幸的是，这两件我都涉及到了。在数据中心的时候，曾参加展会，想潜在客户推荐我们的产品 ，同时也有幸看到行业的其他类型的产品，不能不说，也曾直径进入客户现场，获取用户的同时，满足用户的临时需求。这确是是一个大开眼界的机会，但是并不是什么事情都是需要自己去做的，了解是有必要，参与却不是必须的。


理想的测试
1.项目组的信息对称性，全员都有质量意识。业务人员对业务的有效性和可行性负责，设计人员对系统的安全性以及可伸缩性负责，开发人员对编码的质量负责，提交
的应用可测性良好，测试人员对整体的质量负责。
2.数据流的可视性，便于对数据流的跟踪测试,以便了解这个数据跑到哪里去了
3.可靠的自动化测试
4.线上系统的可视化监控，便于观察线上出现问题，项目组都能看到的线上的运行状况
5.快速的迭代响应的环境。能够有条件分析用户的潜在需求（或者指引用户)，慢慢修改。如今的软件开发，特别是互联网开发，快速迭代是必须的。