标签：
在近3年的测试工作中，一直保持一颗好奇的心，不断的尝试新的测试方向，手工、自动化、白盒、性能、运维，在此对自己以往的测试工作进行一次总结。
过手的项目包含网站、电视频道、手机APP、社区终端机、银行金融系统，没有进入规模性测试团队，但流程大致一样，参加需求评审--编写测试计划--编写测试用例--测试用例评审（产品、开发、项目经理）--单个模块完成进行轮次测试（每测试一轮，进行测试结论）--几轮测试后没有功能性问题（相当于内测）--出测试报告--项目上线。
需求评审中多发表自己对需求产品的看法，用例评审中以测试为中心，要求思路清晰。
用例设计
好的测试用例是用恰当的用例覆盖更多的功能点。简单的功能写几百条用例，写的越细，需求改变，用例无法再次使用。用例写的太粗糙，有些功能点不能覆盖到。观点考虑全面，用例要灵活。多花时间研究被测的业务和需求。多学习别人的用例。
用例灵活
预期结果会写“给出相应提示”“匹配输入的内容”等模糊的预期结果。至于开发具体怎么设计是他的事儿。只要是合理的，不产生歧义的，使用户很容易理解的设计。如果产品需求中有明确的要求的，一定要写清楚。
检查文档
测试人员最繁琐的是一个项目下来要写许多文档，测试计划文档，测试用例文档，测试论次报告，测试报告文档，验收方案文档等等，要仔细检查文档。
测试要积累的技术
按我目前的工作，需要熟悉系统的结构，熟悉开发的语言，熟悉数据库，除了测界面测功能，可以查一下数据库，数据到底有没有存储成功，或者修改数据库数据查看前面效果。通过修改数据库表数据模拟业务流程。
在前台界面操作的时候，去查看一下服务器日志，是否有报错信息。通过服务器日志有时候也能定位或判断问题的原因。
多用页面分析或抓包工具，例如，按钮点击无效，那用debug工具查看页面上这个按钮的属性。用抓包工具看一下请求与响应。总之，在测之过程中试着去解剖被测系统。
测试发现问题
测试人员最激动人心的时刻就是发现bug了。当你发现一个bug的时候，不要急着就上报到缺陷管理系统或告诉开发人员。首先确定重现步骤。换个系统试试，换个浏览器再试试。或许，是你忘记清理浏览器缓存导致某个问题还在。好吧，最好试着定位与解析这个bug的根源。
第二点我要说的是，发现一个模糊的问题，应该试着站在多个角度去看待这个问题，站在用户的角度考虑这个问题的影响。站在开发角度去看待这问题的严重性与修复成本。向开发去说明这个问题对用户的影响。这样更能开发建立和谐的关系。
测试要掌握的知识点
1.了解测试本质
2.要学的是软件知识，测试是为软件服务的，软件工程，编程语言，架构，网络，一切与开发有关的知识，你都要学，这里要学的东西非常多，不要求深度但要求广度。我们在需求评审的时候，有时开发人员会说到技术实现，功能的逻辑，内部处理机制，架构层级等，如果你全部不懂那多“见外”呀，当然，这些知识无形中潜移默化的作用你的测试行为，对被测系统的理解深度以及发现问题的深度。
不要犹豫哪个技术好学，哪个技术有前途，哪个技术工资高。不管你学与不学，技术就在那里，你的技术水平不增不减。当然，也不能一直闷头苦学，学一段时间应该停下来总结与思考。我要走什么路线？我所走的路线还欠缺哪些能力？我还有哪些方面需要加强。当然，也应该关注一下未来的技术趋势。
职责决定价值
标签：
原文地址：http://www.cnblogs.com/shareyezi/p/4495967.html
