不知不觉，已经软件测试行业干了7年多了， 7年里面一直在漂泊，就如软件测试本身，需求和相关技术漂浮不定，网上以及书店里面的测试相关书籍越来越多，仿佛这个行业如此红火，殊不知其中难言的隐。接下来的一段时间打算写一些测试相关的一些基本理论，技术，以及特点，也算是对自己的it生涯有个交待，要不真心没有存在感。
看了一些文章，也看了一些书籍，其实书上的东西千篇一律，大部分仍然不厌其烦的介绍测试框架，测试介入时间，测试重要性，以及测试过程中的一些技术手段，疑惑的是，貌似前者更像产品，后者则像是搞开发，其实测试职业最大的特点就是需求，对需求越熟悉的人，划分越细，维度越多的人越有可能发现更多的问题。
所以，每当一个测试er来到一个新公司，他所遇到的问题其实都是类似的，新的需求，新的技术，新的环境（每个公司测试的地位以及文档完善程度都不同）。
如何能够快速融入到一个新的环境呢？根据我17份工作经历，我总结出了如下几个必问的问题，一旦这些问题搞明白了，我觉得剩下的就是熟练度了：
首先,环境问题:
针对测试的平台不同，os,unix,windows,android,ios,不同的测试环境下有哪些要求？
1.首先是电脑平台上需要哪些开发环境？
git
svn
java jdk
ant
tomcat
hudson
eclipse
testng
.net
python
cywin
browsers
xcode
root
attach app
2.移动平台环境？
是否是开发机
是否root
andriod是否重签名
ios端是否是debug版本的包，是否有签名
其次，测试工具：
1.官方测试工具？：
一般来说，android和ios端的官方测试工具相对来说更靠谱，第三方的工具只是外包了一下，不敢保证是否没有bug，另外由于第三方的测试工具非盈利性质，则会导致文档不全，不稳定。
2.第三方工具？：
好的第三方工具应该能够广为流传，导致相关学习文档很多，另外最重要的一点就是官方网站的相关下载能够更新日期比较近，说明没有过时。
2.DIY工具？：
很多公司里面由于人员流动以及项目对时间的要求，虽然也有一些测试脚本，但是由于没有更多的时间让你去开发，所以导致测试脚本以及框架异常简陋，不仅不方便使用，而且维护成本极高，这种情况下自己要有判断，若是测试任务比较紧迫，则还是测试为主，若是时间略宽松，还是要自己重新组织下，这个很重要，不要怕麻烦。。。现在不麻烦，以后更麻烦，而且东西越多你越懒得高。每个测试框架其实就是一个独立的产品，产品好坏对测试效率以及测试质量有深远的意义。
第三，测试用例：
1.简单的例子
任何一款软件产品都会有最简单的测试流程，同样，我们测试需要有一个主干，然后以此为基点再展开来更多的测试点，由于公司并非学校，不过给你太多时间去熟悉，另外也不会总有人有空去带你，所以需要你最短时间内能够走通几个最主要，也是最简单的流程。
2.测试流程控制（难点）
测试流程，即测试步骤，很多产品的功能非常复杂，导致测试点非常多，经常在同一页面，或者是步骤的时候有非常多的测试点，这个时候就需要测试人员有自己的把握能力，去区分什么养的action是可以促进测试流程进行下去的，另外针对一个测试点，如何能够最简到达测试点，
a.尽量简化非验证点的测试步骤，以确保测试的稳定性，
b.同一系列的测试用例，尽量能够同用同一套测试步骤流程（局部微调），以减少工作量和后期维护成本。
c.对于测试中共用的参数，一定要汇总起来集中配置，并且注明好含义。
3.测试验证控制（难点）
测试工作最大的工作量在于大量的验证，通过模拟不同的场景，取得结果后分析结果的正确性。由于测试结果比较分散，另外测试中会遇到很多非唯一的输出，其实验证是一个不容忽视的工作，一个好的测试验证，不仅要验证是否信息缺少，信息错误，跟要验证是否信息冗余：
a.针对测试结果中的能够确定的数据结构，需要进行优选验证，比如xml，json的数据格式是否正确？标签个数？属性个数？命名空间?
b.针对具体的属性，或者是内容，需要验证其正确性的同时，要做好注释，以保证，看到测试结果报告后不需要人工二次分析，耽误时间。
c.测试比对的集成，由于一般来说比对的测试结果不可能只有一个assertequals，但是往往测试框架的逻辑是遇到assert的指针就跳出该case，导致测试不能呢准确定位，因为同一个测试点不一定只有一处错误，所以，需要自定义方法把测试结果集成起来后，将测试中的错误统一输出以供分析。
第四，维护性以及不足
每当遇到一个已经存在的测试框架的时候，千万不要以为万事大吉，因为有可能在你眼前就是一座实实在在的烂尾楼，由于开发工作毕竟不是软件测试人员的主要工作，所以大部分公司的测试脚本相关文档并不完善，更新也不及时，到时脚本中大量冗余的信息可能会误导新接触的人。所以我们需要关系测试框架是否有维护？哪些已经废弃了，哪些仍然在用？配置文件d都定义一些什么东西？ 另外我们也需要关系测试框架的不足指出，由于测试框架并非有人这么高的灵活性，导致框架在测试方面都会或多或少的有局限性，越早了解这些，越少走弯路，要了解哪些东西是可以做但是还没来的级做，哪些东西是技术局限，做不了，难点在哪。带着物尽其用，但也不能过其用的心态才能更踏实的展开工作。
最后，参考资料
当然，一个新的环境里面需要有新的技术积累，每个人都是这么过来的，若是能够站在前人的肩膀上，必然事半功倍，所以可以了解下，就算没有具体的资料，也需要知道重点使用的技术点在哪里，以方便自己有针对性的google。
软件测试是一个很严肃的职位，需要参与者脑子中有很明确的目标导向，也需要当事人能够适应各种各样的环境——从需求不明确到明确，从测试参与的时间点不同，从现有的资源。
希望大家能够共勉！