本来想用“优秀”，后来想想不过“合格”而已。最近工作与学习的想法，内容比较碎，先记录下来。
由于有写博客的习惯，写了不少关于测试的东西，常常被别人加群或直接加QQ问问题。可能是因为我写了不少东西的缘故吧！大多数提问者会认为我一定水平很高，然后，问我是做什么测试的？用什么工具？我的回答是：主要以功能测试为主，会用到一些辅助的工具，如 fiddler。他们无不大失所望。
关于我的第一份工作的情况，我在《一个测试员的工作与学习》中已经说的比较详细了。第二份工作（目前的这份工作）的经历等什么时候辞职的时候再整理吧！
这里可以简单简述一下自己目前工作情况，虽然我们公司的测试人员是坐在一起的，但我们每个人都会长期的跟不同的项目。刚工作时打了三个月的酱油（哪里需要就往哪里去）。后来一位大姐请产假，我就接替了网盘工作，再后来忙不过来，新招了一哥们跟着我做网盘。工作内容：
参加需求评审-->编写测试计划-->编写测试用例-->用例评审（召集产品，开发）-->项目上线后进行轮次测试（每测试一轮，发邮件出一轮测试结论）-->几轮过后没什么问题项目上灰度（相当于内测）-->灰度测试过后上全网-->出测试报告。
好吧！我来说说这个过程中的注意点：
沟通
搞IT的
嘛，一般典型的闷骚男（我也属于）。在网络都是文艺、愤青。现实工作环境中什么状态自己知道。我之前认识一搞开发的哥们技术没得说，钻研精神没得说。我去
向他请教问题，他跟我说话紧张，搞得我都提他着急。在工作中要与上级沟通，开发沟通，产品沟通，这方面确实需要注意加强。在需求评审中多发表自己对需求对
产品的看法。在用例评审中是以测试为主导的会议，所以，一定要思路清晰，有条不紊的评审用例。在测试过程开发或产品确认问题，协助开发定位问题都需要沟
通。两个词，淡定，谦虚。
用例设计
好的测试用例是用最恰当用例覆盖更多的功能点。有些人
写用例粒度很细，简单的几个功能就能写几百条用例。写得越细致，需求稍微一变。你的用例直接作废。写得太粗，很多功能点覆盖不到。我的观点是考虑要全面，
用例要灵活。考虑要全面很难，经验再丰富的人难免百密一疏。这个只能在血和泪的教训中去积累吧。多花时间研究被测的业务与需求。多看看别人写的用例从中也
会收获不少。
用例要灵活，例如，我一般预期结果会写“给出相应提
示”“匹配输入的内容”等模糊的预期结果，至于开发具体怎么设计是他的事儿。只要是合理的，不产生歧义的，使用户很容易理解的设计。我都认为是正确的。当
然，这可能会给读用例的人带来一点麻烦。还有，如果产品需求中有明确的要求的，一定要写清楚。
仔细检查你的文档
测试人员最繁琐的是一个项目下来要写许多文档，测试计
划文档，测试用例文档，测试论次报告，测试报告文档，验收方案文档等等，相信你在长期的工作中已经完全具备了这点儿能力，我想说的是细心。我们习惯在之前
的文档上拷贝一份修改。这样可以节省不少时间，但也容易出错。我就是这样，或日期，或数据忘记修改。好吧！身为一个测试员，这为自身能力表现打折不少。不
要小看这点事儿。写过的文档最好要反复检查两遍。
积累你的技术
老在开发面前表现的“小白”，我要是开发，我也鄙视
你！按我目前的工作，需要熟悉系统的结构，熟悉开发的语言，熟悉数据库，除了测界面测功能，可以查一下数据库，数据到底有没有存储成功，或者修改数据库数
据查看前面效果。如，我要测试网盘空间满了之后，上传文件的提示信息。通过功能你要上传多少个大文件空间才满呀？直接改数据库里面文件的大小不就搞定了。
在前台界面操作的时候，去查看一下服务器日志，是否有报错信息。通过服务器日志有时候也能定位或判断问题的原因。
多用页面分析或抓包工具，例如，按钮点击无效，那用debug工具查看页面上这个按钮的属性。用抓包工具看一下请求与响应。总之，在测之过程中试着去解剖被测系统。
发现问题之后
测试人员最激动人心的时刻就是发现bug了。当你发现一个bug的时候，不要急着就上报到缺陷管理系统或告诉开发人员。首先确定重现步骤。换个系统试试，换个浏览器再试试。或许，是你忘记清理浏览器缓存导致某个问题还在。好吧，最好试着定位与解析这个bug的根源。
第二点我要说的是，发现一个模糊的问题，应该试着站在多个角度去看待这个问题，站在用户的角度考虑这个问题的影响。站在开发角度去看待这问题的严重性与修复成本。向开发去说明这个问题对用户的影响。这样更能开发建立和谐的关系。
测试应该学些什么
这是常被问到的第二类问题，我不被重视，很少安排工作，应该学些什么？对于这个问题，我把测试人员的知识体系分两大块，一块就是测试知识，一块就是整个软件知识。
先说测试知识，测试基础类的，不少测试员是没读过什么
软件测试书籍（包括我个人也是最近读了几本）因为大学开软件测试专业的不多，培训学校更注重实践，可能不会给你讲太多理论性的东西（个人猜测，没培训
过）。大多测试测试人员非科班出身。测试门槛确实不高，熟悉一下就直接做了测试。没精力和必要花太多时间去学习基础理论。好吧！这也是问得我做是功能测试
时，大多数人表现出来的失望与不屑原因。好吧！我还是觉得你应该读几本测试的书《[软件测试]Ron Patton》 《全程软件测试》 《软件测试paul C. Jorgensen》《有效性能测试--测试人员的50条建议》 《软件测试技术经典教程+第2版》 ，当还有《微软的软件测试之道》以及最为经典的《软件测试的艺术》 ，如果你不知道关于软件测试都有哪些书的话，为什么不去当当网和china-pub输入“软件测试”几个关键字搜索一下呢？
当然了，你对这些不感兴趣，想学一些更实用，看上去很
厉害的样子的技术，可以搜索一下性能测试的书，自动化测试以及单元测试，探索性测试，敏捷测试等。不过，我还是建议打好测试的基础！即使再多的花样，再先
进的技术都是为测试服务的，你都不了解测试的本质是什么？那就是盲目的追求。
另外一个要学的是软件知识，测试是为软件服务的，软件
工程，编程语言，架构，网络，一切与开发有关的知识，你都要学，这里要学的东西非常多，不要求深度但要求广度。我们在需求评审的时候，有时开发人员会说到
技术实现，功能的逻辑，内部处理机制，架构层级等，如果你全部不懂那多“见外”呀，当然，这些知识无形中潜移默化的作用你的测试行为，对被测系统的理解深
度以及发现问题的深度。我曾多次用“隔衣挠痒”来说不懂开发的测试，什么感觉，你自己体会去吧！
当然，每个人都有自己的知识架构和自我的学习路线。不
要犹豫哪个技术好学，哪个技术有前途，哪个技术工资高。比对吧！看看各种技术社区相互吐槽。只能是没完没了吐槽。不管你学与不学，技术就在那里，你的技术
水平不增不减。当然，也不能一直闷头苦学，学一段时间应该停下来总结与思考。我要走什么路线？我所走的路线还欠缺哪些能力？我还有哪些方面需要加强。当
然，也应该关注一下未来的技术趋势。
职责决定价值
最近读的51testing《 软件测试，想说爱你不容易》一文，感受颇深。作者以工作七年测试员的感受来谈软件测试。
其中有一例子颇为深刻，一语道明其中的道理。如果做为
一个努力并挣扎中的测试员依然不明白为测试为什么低于开发。拿护士与医生来比喻测试与开发的关系再明了不过了。一个医院中最常见的两个职位就是医生与护
士。即使再优秀再专业的护士，治愈不了病人的病。同样，一个再优秀的测试员做不出软件来。名医很多，也许你随口就能叫出几个来，有谁能细数一下有名的护
士，除了开创者南丁格尔。恐怕叫不上一个来。其实测试与开发也是这样的关系。因为职责不同，当然有轻重之分。
存在既有价值，医院不能没有护士，软件开发中需要测
试。好吧！请正确看待自己职业。也许，你会转向更有价值的开发人员，或者架构师。或者不着边的工作。我想大多会继续选择在测试的道路上继续前行。那就尽量
让自己的价值最大化吧。带个测试团队，或做测试讲师，或出几本书，成为一个测试专家，探索一下测试的新技术，新模式。既然选择了并热爱那就努力前行吧！
敏捷测试
由于最近项目的情况，越来越决得流程的繁琐。在这么繁琐的流程下，并没有很好的保证产品的质量，测试人员的大部分时间都消耗在各种文档中。所以，开始了解敏捷测试。也想从中寻找想要的答案。
敏捷测试对测试人员提出了更高的要求。测试不再是流程中的一个环节，而是高度的融入项目的整个流程。也许这可以使测试人员的价值更大化，但需要你有足够的能力去迎接它。
敏捷测试人员的定义
我们这样定义敏捷测试人员：专业的测试人员，适应变
化，与技术人员和业务人员展开良好协作，并理解利用测试记录需求和驱动开发的思想。敏捷测试人员往往具有优秀的技术能力，知道如何与他人合作以实现自动化
测试，同时也擅长探索性测试。他们希望了解客户在做什么，以此更好地理解客户的软件需求。