转眼间已经毕业一年多了，也工作了一年多，从刚开始择业时的迷茫中还没有完全走出来（刚毕业的我打算去做开发，因为觉得自己没什么经验转做测试），上学期间，经常听到老师同学们说开发多难测试多简单，甚至很多选开发的同学都有些瞧不起做测试的。做了一年多的测试后，我才渐渐意识到我们当时的认识多无知，测试和开发根本就不能分开，要是一个开发不懂测试，他的code肯定是bug百出，而要是一个测试不懂开发，他只能一直做手动测试，发展空间太过局限。而如果一个测试想真的一直在测试行业做下去，他必须要懂既开发又懂测试，这就是我目前的职业规划，成为一名开发测试工程师（SDET）。所以最近在工作之余，我开始更全面的学习测试知识，也终于有种学以致用的感觉，这种感觉让你很有成就感和自豪感，哈哈。。。
废话了一大堆，下面说一下我对软件测试的认识，最近在测试培训课的老师的PPT上看到了这张软件测试全景图，帮助我解答了好多困惑，所以贴出来跟大家分享（百度一下就能找到，有时候最可悲的是你都不知道自己不知道）：
图1. 软件测试全景图
从图中我们可以看出，软件测试的过程就像一个八卦图，我们做软件测试的目的就是保证软件的质量，而从这个目的出发，我们最终要做的就是发现软件所存在的缺陷（bug）,大家都清楚，在现实环境中没有一个软件是十全十美，但软件的应用却已经涉及到每个行业，是现代人生活中不可或缺的工具。
为了保证软件质量这个目的，我们就要确定自己的测试目标，当然不同行业的不同软件的测试侧重点不同，现在的工作中，我主要做的是对微软ERP系统（Dynamic AX）的功能测试，安装测试和兼容性测试。但据我了解好多其他软件比如订餐排队软件，支付软件都要涉及到性能测试，负载测试压力测试还有安全性测试，而根据最近的好多新闻，我们更是能意识到软件的安全性测试也是一个很重要的部分。所以，在以后的学习中，我会更偏重去学习和做安全测试，因为我也很同情那些受害者同时也对那些骗子恨之入骨。
确定了测试目标后，我们就要找到合适的测试方法，测试的方法主要分为黑盒测试、白盒测试还有介于两者之间的灰盒测试。
知道用哪种方法后就要设计测试用例，设计好的测试用例要参加评审，而评审团队一般都由产品经理，开发人员，测试人员，还有验收放组成。而在设计测试用例的时候，我们要清楚，测试用例是为了某个特殊的目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。同时也要注意，一个测试用例只能对应一个测试点，测试点和用例是1对1的关系；一个需求点可以对应多个测试用例，需求点和用例是1对多的关系。有时候有些大型系统的测试用例有成百上千个，所以对于一些使用频繁的测试用例，我们可以考虑编写自动化代码来执行。
所以，执行测试用例的过程就是找bug的过程，这也是为什么要一个测试点对应一个测试用例，这种情况下，要是用例执行失败，说明此部分的功能有一个bug，在后面报bug的时候，才能一一对应，而不至于一个用例报出好多个bug,这样对后续bug的修复和统计都带来很大麻烦。
以上这个从质量-->目标-->方法--> 用例--> 缺陷的过程是一种动态测试过程。而下面我们也要从静态测试的角度来考虑测试发现缺陷的过程。
从质量出发提取出测试思想到用思想指导管理再到实施计划最后发现缺陷（bug）清楚bug的过程，我认为更是对整个团队的考验和要求，这一块我还不怎么理解，只是觉得作为一个团队中的一员，不仅需要及时有效的和开发以及其他的人员比如需求，管理者做好沟通，还需要在做好自己工作的同时，做好记录和分享，这时体现的更是一个团队的合作能力。从我自身经验考虑，其实在及时跟其他同事分享这方面我做的还远远不够，很多时候，我做事时会自己做笔记记录自己在分析test case的过程中遇到的错误和解决方案，以防下次继续碰到，但却没有及时和其他成员分享导致在别人遇到同样问题时依然需要花费很多时间和精力去解决，尤其是当人员更换较快的时候，我们更应该这样做，这是对自己负责也是对整个团队负责的表现，毕竟我们不是孤军奋战，我们整个团队的目标就是保证我们的系统可以安全稳定的使用。但是在实施测试的不同阶段，需要做的回归测试我还是稍微有些研究，这方面可以见另一篇文章：BVT&BAT&SVT
再来说说软件缺陷的定义即何为bug？ （美）Ron Patton 在其著作的《软件测试》一书中把符合下列五个规则的问题称为缺陷：1. 软件未达到产品说明书标明的功能；2. 软件出现了产品说明书指明不会出现的错误；3. 软件功能超出了产品说明书指明的范围；4. 软件未达到产品说明书虽未能指出但应达到的目标；5. 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。根据不同的类型，bug一般分为： 功能缺陷；性能缺陷；兼容性缺陷；用户界面缺陷；设计文档缺陷；可靠性缺陷；安全性缺陷；易用性缺陷；还有安装/卸载缺陷等。
总而言之，我们最终的目的是发现bug（Tester）修复bug（Dev）清除bug（Project Leader）甚至到后面还要做到预防bug（The team）。这里面我们要注意的是开出bug后要按照bug的优先级和严重性随时跟踪，直到开发人员resolved bug后，我们再retest，要是确定bug已经修复完成，就可以closed bug，只有到closed之后，才算该bug的生命周期结束。