本章目的：
1.确立测试目标；
2.以目标为导向建立着手方式以及基本策略。
刚刚入行的时候，曾经购买过一些测试理论的书籍，几百页的书罗列了各种基本测试技巧以及概念，但是却 - useless，因为能够对工作有帮助的内容很少。但是呢，我认为针对理论的探索还是非常有必要的，就跟打仗一样，如果攻击目标以及攻击手段尚不明确，如何进行具体实施部署呢？
测试目标:
在有限的时间内，尽可能早，尽可能多的发现软件的缺陷，并且可以重现。
所以，这里标注的关键字是我们所关注的侧重点，而根据不同的侧重点，我们也需要采取相应的策略才能达到目的。
下面来逐条分析：
有限：
侧重点：
现在软件行业竞争激烈，功能层出不穷，意味着版本迭代周期更短，而测试这个缓解，对于任何一个项目而言，其实，预估时间都是变数之一，因为我们不知道会发现什么问题，当出现问题的时候，不知道开发需要多久才能修复，所以为了能够在有限的时间内完成项目，需要有侧重点的去进行测试：
比如一个用户注册网页，如果时间允许，我们当然可以测试各种非法输入以保证网页健壮性，最理想的状况则是不同浏览器下当非法输入的时候，前端能够给出友好的提示，但是时间有限的情况下，就没有必要枚举出所有的非法输入了，考虑到一些用户的习惯，以及网页的使用人群，我们给出常见的非法输入以及测试案例，就可以了，另外浏览器，根据市场需求重点叠加几款主流浏览器就好了。
案例一：
注册邮箱.
完整测试用例：
1.正确输入新邮箱，注册成功，前端后提示，自动跳转，后端存储相关数据。
2.非法输入：
不带. 不带@ 中文字符 特殊字符 邮箱已经存在
3.浏览器 :
ie6,7,8,9,10,firefox,chrome,safari 移动端浏览器 各种应用内嵌浏览器 禁用js的浏览器
缩减版测试用例：
1.正确输入新邮箱，注册成功，前端后提示，自动跳转，后端存储相关数据。
2.非法输入：
不带. 不带@ 邮箱已经存在
3.浏览器 :
ie7,firefox,chrome
这个里面考虑到主流用户的输入习惯以及网络环境，我们将重心放到主流的浏览器，以及常见的异常处理，但是，没有测试的点，不意味着放弃，实际上也是需要记录下来，为下个版本或者以后完善网页。
比如手机浏览器打开pc网页进行邮箱注册，如果css支持不好，我们是否能够加入自动跳转至移动站点呢？
说根本，测试只是发现问题，并且提出建议，但是绝非决断者，决断则是由市场，技术资源，时间资源，以及需求工程师共同决定的。
是否自动化？
自动化一直是测试领域里面的双刃剑，很多公司愿意在其中投入很多精力，很多tester也很愿意多少能够掌握一些，貌似就是高级和专家的代名词，其实不然，当我们做测试自动化的时候，在其中花费的时间人力成本，以及其能够发现的问题多少，运行稳定性，可维护性，都是要一开始就考虑的。
对于已经有自动化测试框架的项目而言，回归测试自然要做，但是一般来说，新功能还是最好能够在稳定后，再加入自动化测试脚本为宜，毕竟编写脚本是需要时间的，其中难免遇到各种编程问题，然编程毕竟并非tester所擅长，所以比如五个工作日，预期花3天脚本，1天运行测试，1天verify，不如花3天测试，两天verify。
对于暂时没有自动化测试框架的项目而言，在日常测试任务饱和的情况下，我个人还是希望自动化的搭建可以跟日常测试并行，一部分人专门去搭建框架，并且将稳定的回归测试案例加入框架，然后再培训后来者，确认书写规范，大家都可以把自己的模块的case添加进去。
如果项目周期够长，项目开始跟结束之间工作不饱和，也可以分阶段目标展开自动化框架的开发。
早：
测试介入时间：
对于一个成熟的公司而言，测试介入的最佳时机就是需求评审的时候，我曾经在一个智能交通系统项目中，多次在需求里发现，商业逻辑以及技术架构逻辑问题，避免了开发的无用功。
但是要做到这一点其实是有难度的：
一方面，很多公司测试介入的时候，已经需求尘埃落定，或者已经开发了大半。
一方面，需求缺陷很多公司并不算是软件缺陷，所以知识口头上或者邮件上进行确认修改，而不计入tester的绩效或者工作量。
所以这个时候，个人主观能动性非常重要，因为往往测试部门总是最后一个知道需求的，需要主动去跟项目经理询问，去向需求询问。其实这里是比较麻烦的，因为很多时候，需求跟开发达成一致后直接就开始项目， 并非不愿意通知测试，一是没有硬性要求，二是很多时候也没顾上，所以测试在这里心态一定要放正，不要别人不搭理你，你就得过且过，因为项目最后质量不高，以一起受到拖累。
测试顺序:
其实测试顺序跟测试侧重点是类似的，很多时候，测试里面有个概念称为“准入测试”，意味着如果准入测试的测试用例不过，则不予测试，这其实非常好，一般来说，我们设计测试用例的时候，把最基本的case设计成准入测试用例，最好能够覆盖最基本的功能商业逻辑。具体不同的项目要求跟公司要求有所不同，最好是测试用例评审的时候就把相关的准入测试用例确认清楚，并且能够与大家达成一致。
多：
广度：
我这里面的广度主要是指功能层面的测试覆盖度，覆盖度的大小取决于不同人对事物看待的角度以及工作经验，还有对项目的理解，对项目实现技术的理解，好的思考方式，主要还是要从用户的角度去衡量一个产品的功能，因为代码里不是循环 就是逻辑判断，但是如果不能够覆盖可能发生的用户需求，就会产生问题，这里需要集思广益，哪怕再不合理的用户操作，我们都要想清楚，现实中是否有可能发生，以此为基本去设计用例，我们不仅要覆盖所有的逻辑分支，逻辑分支中不包含的也需要去设计。容错能力也是一个软件是否优秀的标准之一。
深度：
测试深度又是另外一组概念，就我目前经验而言，我认为有三点需要考虑：
1.隐性功能，很多时候，最终用户在使用功能的时候，后台不仅仅只做了与前端相关的任务，而还会有一系列相关的后台任务在运行，如打log，定时计划任务等，这些隐性的东西很可能由于我们测试环境搭建，实现数据准备而导致没有覆盖到，另外有些问题，比如log打错了，前端元素id重复，id拼写错误，都不会影响到用户使用体验，但是对项目的长期发展是不利的，因为这种问题多了以后就很棘手了，所以我们要实现能发现。避免后续隐患。
2.公用模块的改变，公用模块分为跨部门的公用模块，以及同一个项目的公用模块，每当接口或者表结构，公用元组数据发生改变的时候，一定要考虑清楚相关部门跟模块的影响，测试这个行业需要能够把工作分散化，大家各尽其责，需要有大局观，而不是独揽大局，你只需要分析清楚，再把相关模块或者影响的项目的测试任务分担出去，就大功告成了。
3.技术层面，其实这个领域比较有难度，因为你需要对软件环境有个整体把握，比如我曾经遇到一个问题就是后台创建的Linux文件夹超过了系统上限，导致数据生成失败，这种问题测试的时候很难发现，因为测试只是功能，真正线上的用户要比实际测试所产生的数据多的多，再比如项目引用系统编码的项目，但是生产环境的系统编码跟测试环境的系统编码不一致，线上的服务器跟测试环境的cpu，内存差别，导致线上出问题，类似这样的问题很多，一方面需要自己不断总结完善，另外一方面也需要多思考，多尝试，多交流。我们固然不能发现所有的问题，但是如果可以避免的项目风险，为什么不避免呢?
环境：
其实环境属于深度的分支，其实总的来说就是兼容性，但是因为环境这个因素太重要，变数也太多，所以放在这里单说，
前端环境主要是最终用户的使用环境，类似浏览器，类似用户的操作系统的版本，若是移动端，还设计android平台不同版本，不同的手机尺寸，不同性能的手机，不同的移动浏览器，以及各种流氓杀毒软件是否会对软件进行误报。
后端，则是jdk版本，系统变量，数据库版本，数据库的基本配置等。
很多时候开发也搞的不是很清楚环境对项目的影响，因为毕竟资源有限，往往他们只在一套环境下开发，所以这里我们需要push需求去明确测试环境的要求，他们必须明确，因为若是这个无法明确，在本应该重点关注的环境下没有用心测试，导致最终用户体验不好，放弃软件，这种风险还是非常可怕的。
重现：
排除干扰：
在测试中，经常会发现一些无意中发现的问题，很多问题在特定的环境下出现，有时候很难重现，所以我们需要排除干扰，能够最简洁的途径重现bug，这个里面有一点很重要，如果问题不是很大，先记下来，不要在主要功能还没测试完的情况下在这里花费过多的时间，
步骤稳定：
我们需要剔除掉无关bug产生的不必要的操作，以提高开发人员的分析效率。
差不多能想到这些吧，以后再补充。
另外，在工作中，还有两个因素也值得考虑：
一个是持续性，测试本来就是一门反复的工作， 所以枯燥是难免的，我们需要持续良好的心态，通过自动化，或者自动部署等手段去持续我们的cases运行效率，需要持续的跟各部门的人沟通。对自己的岗位也要有耐心，因为产品的理解不是一两天的事情，只有干久了，对产品理解优势才能体现出来。
二个是坚持和妥协，这是一把双刃剑，很多时候，明明觉得自己的逻辑是对的，但是还是无情的被否决了，这是很正常的，一个时间不允许完善，一个是可能需求觉得这个问题也许不是这么重要，毕竟每个人角度看待都不同，所以呢，我们有时候要妥协，但是遇到测试完临时加需求，而给的测试时间不够的时候，我们需要坚持立场，这个不是妥协一次的事情，而是，以后搞多了，不仅你工作量变大， 出问题的风险增加，还费力不讨好，毕竟除了问题全是测试的，没人会同情你。我现在在发现一些问题的时候，很少去断定是否正确，更多的时候我喜欢用不一致，与需求不一致，同一事物在不同地方展现不一致，功能不一致，流程不一致，很多公司的文档不齐全，项目的管理也很松散，测试，这种对标准需要要求的行业，更多的时候要懂得四两拨千斤的道理，以彼之矛攻彼之盾。
（完）