但是在这里我觉得要反驳一下了。不是过激的争论，辩论，而是一种观点。为什么明明都是手工测试，我比你发现的bug就是多；为什么明明都是手工测试，我比你发现的bug更有含金量，级别更高，重要程度更高（我们暂时忽略级别确定的合理性，假定级别都是客观且正确的）；为什么明明都是手工测试，我对业务的理解就是比你强，我更能被大家认可，被客户认可。
所以，我想说，手工测试是一件入门非常简单，但做好非常难的事情，往高走也相当的不容易。“她”简单到一个什么都不懂的人，都可以不经过任何培训，来了就照着用例，甚至没有用例自己乱点，就发现bug。
“她”难到如何通过最小的执行代价，获得最大的质量保证，覆盖最多的用户场景，这是一门艺术。真正的测试专家，一定是有黑盒测试专家一席之地的，每个公司也都一定有测试的业务专家。
PS：我这里用的“她”，是我在猜测，如果“她”是一门艺术，那么能代表这门艺术的一定是一位柔美的女子吧
言归正传，我们开始进行测试分析的干货内容，首先我们明确测试分析都要分析哪些，下面给一个列表，包括但不限于吧。
被测物是什么
项目目标
需求来源
开发实现
需求目的
销售相关
用户群
测试范围
测试目的
。。。
。。。
我们一一道来，看看每一项我们都能分析出来什么。首先，我后续描述的大部分思想，来源于海盗派测试分析，2017年初出版的，出自独立软件测试顾问邰晓梅，一个热爱学习的Learning Geeker，我在10年从业软件测试，17年初看到这本书，从未想到我工作这么久，一本不讲测试开发、不讲自动化、不讲Devops的书能让我收获如此颇丰，如果你也爱看书，爱测试，非常建议认真的读一读这本书，受益匪浅。
被测物：是指我们到底测试的是什么东西，他是怎么工作的，用户是怎么玩的。
项目目标：是指我们为什么要做这个项目，他能给用户、给公司带来什么价值？
需求来源：是指谁给我们提的需求，为什么给我们提了这个需求，是要解决什么问题么？我们有更好的解决用户问题的办法么？
开发实现：是指开发是如何实现这个需求的，他能帮助我们做到2点判断，1个是这么实现有没有漏洞、不足（别害怕，别害羞，多问，都想，多被怼），另外1个是，我怎么测更有针对性，当然首先你得忽略他是怎么做的，得想用户是怎么用的，先保证用户，再有针对性的深度测试
需求目的：用户要我们的产品干嘛，为什么提了这样的需求，为了解决什么实际问题，他们以前是否有过解决这类问题的尝试，那么是什么原因没有解决，而我们又怎么能帮他们更好的解决，真正在用我们软件的是哪一类人员，他们有没有什么操作习惯？我们能不能去客户现场待一段时间，真正观察一下他们如何用我们的产品的。（PS：如果你看过海盗派测试分析，这里就是就相对于书中的KYM，Know you mission，想了想还是作者总结的好，比我厉害）
销售相关：我们的产品售价多钱，假设我们要把产品卖给一个客户，销售团队是怎么介绍的，他是怎么引导用户让其对我们的产品上瘾的。我们的目标客户是哪一类的，他们有什么特性。别惊讶，这会帮你知道用户最初和最多的是怎么用我们的产品的，你自然知道在时间紧张的时候如何圈定测试范围。
用户群：谁在用我们的产品，一般什么时候用，用什么手机，用什么浏览器，这里也就可以分析出来后期测试时兼容性覆盖的范围，当然有的公司有自己的数据统计或者第三方的统计，这个更好，附上几张图大家可以参考下，来源于某公司的GrowingIO中的统计
测试范围：有效识别测试范围，其实可以避免测试资源的浪费，或者说定义不同阶段，不同时间下的测试范围，有差异性的保证测试资源和测试产出的性价比，是一个有技巧的事情，附图。从Story测试到product，测试投入范围的变化。
测试目的：这个本该一开始就列出来的，刻意放到了最后，因为我觉得如果不了解上面这些问题，你的目标应该是虚的，或者像大部分的测试方案，千篇一律，失去了灵魂。所以测试目的最终会告诉我们什么时候可以测试准出，什么时候可以资源释放，什么时候可以交付用户，测试目的应该是项目目的的一个子集。
总之，测试有3种分析
基于需求的分析
基于用户的分析
基于风险的分析
测试也有2种设计
基于场景的设计
基于数据的设计
推荐启发式测试策略做为测试分析的模型吧，具体这个模型怎么使用，就不在这里多说了，百度一下一大堆专业的分析，我从我的角度告诉你他能带来什么。简而言之，就是当你在测试设计阶段，通过这个模型，能让你更多的分析和完整的思考，而测试执行阶段，又能帮助你进行测试的反思和场景的组合，蛮棒的，所以还是希望大家能从测试分析做起，能从看得起黑盒测试开始。
下一篇文章，我们聊聊如何设计测试用例吧，貌似更“无聊”了。
最后，我附上一句话，出自Cem Kaner。“好的测试人员并不是可以发现很多bug或使很多的开发人员感到羞辱的人。好的测试人员是那些促成合适的bug得以修复的人”
