朋友，你是否了解发散测试？你尝试过发散测试么？你的发散测试的效果如何呢？
发散测试，顾名思义就是不以某个标准或者框框作为约束的一种测试，对于我们测试人员来说，给我们最大的约束的就是测试方案和测试用例，有时候别人写好的东西我们直接执行就行了，就像我们根本就不需要思考一样，那个时候，就觉得自己马上就成为一个随时被淘汰的角色，因为只是执行，我比自动化工具差多了。（具体差多少，自己可以比较时间，金钱，效率，成功率，犯错率等等，保证让你无地自容。）
还好，现代的软件测试还没有发展到那么强大--完全可以依靠工具。但是不管怎么样，作为测试人员，我们的首要目标就是在产品上市前多找出缺陷，保证不会因为我们的漏测将缺陷遗留到现场去。我们每轮迭代按部就班，兢兢业业的将我们的用例跑一遍，却时常感到有点不靠谱，总感觉有地方没覆盖到，测过的地方好像还是有点问题，但是用例确实是执行通过了。这时候，你有什么办法？
此时，你需要抛开用例了。
发散测试帮你的忙，你完全可以不用盯着用例一遍遍执行步骤，你完全可以依靠此时你对系统的理解和分析得出你自己的结论，哪些地方好像不足，哪些地方需要再覆盖一下。笔者总结点自己日常使用的方法，虽然是班门弄斧，但是还是觉得有一点用，毕竟，它们都曾经发现过我漏测的问题。
（1）、2-8原则：测试的同学都知道有2-8原则，80%的缺陷发生在20%的代码区，这一块基本上是缺陷的高发区，不光主流程有问题，各种小毛病层出不穷。可是，你提了多少张问题单了？你的覆盖是否全面了呢？越是这个时候越要小心，有可能你自己测试的时候就放过了不同的问题，而自己却觉得是已知问题而一带而过。这种问题不止一次发生在自己身上，深有体会，发散测试需要重点关注这样的场景，你会收到意想不到的收获。
（2）、对比需求，参照设计：我们的用例写好之后还有多少同学会回过头去看但是给我我们启发的设计方案？我们还是否能够一直跟着需求文档对需求文档了如指掌，甚至比需求人员还要熟悉？测试人员凭什么说自己能够代表用户在进行测试？不就靠这个么？如果你对需求的理解，对设计的了解不如开发人员，人家要你干什么呢，你测试完成后现场用户提了一堆问题你测试一点责任都没有？怎么可能，最先追溯的就是你测试。如果出现设计和需求重大偏离的还会遭到投诉。我们作为质量的把关人员，整天和开发混在一起，很容易按照他们的思维走，认为这个东西就是这样。我们测试完成之后还是要认认真真的过下需求和设计，确保理解的一致。
（3）、用户场景：试问一句，有多少同学确切的知道现场客户如何使用咱们卖出去的东西？长期在研发体系混的大部分不知道。总是觉得应该是这样用的吧！例如一个最大容量是500个同时请求的系统，一般情况下有多少人在使用？我们需要使用500个线程一直连接测试系统的抗压能力么？完全不用。老同学们都知道其实这个系统长久的运行一般都是300号人同时，一年能够有几次500人的机会。就像移动的系统，他的设计规格可能是容纳春节期间的用户量的，但是我们测试人员就不用一直测试，毕竟春节也就那几天电话、短信暴涨，平时也就正常值的6成到7成。我们测试结束后可以让几个同学一起登陆系统操作，模拟用户的真实场景，并发情况等操作，系统是否采用了保护措施，虽然开发可能跟你说，这种触发的概率低，但不能因为低就忽略它，如果不测试，它就是个隐患，不知道什么时候就迸出来。
（4）、异常场景：我们有时候就过分的迷信了自己。我们的系统是强大的，健壮的。但是一次下电、一次主备倒换、一次异常重启，一次网络故障，我们的系统就Down掉了。这叫健壮么？我们要考虑到一切场景，例如用户操作到一半突然系统故障了，就像取钱，万一正在吐钱的时候ATM挂掉了？怎么办?用户升级后需要重启系统我们是否还能保留原来的数据和状态让最终的用户毫无察觉系统在主备倒换？灾难过后的数据能否正常恢复，不怀好意的用户进行的非主流操作你是否能够给予他警告并让其无法执行？我们都覆盖了么?
（5）、我们要根据规范，测试，不是无原则的发散，我们的规范、结论也是大家集体讨论的结果，是产生效率的保证，我们根据规范就能发现一些不规范的地方，常见的规范包含UCD规范、online、inline规范，设计规范，接口规范。我们根据规范，让我们的系统不至于那么难看，不至于让人一看，这些个页面、功能就是一群江湖郎中做出来的。
给自己总结，给大家分享，测试之路，越走越宽！
发散测试，顾名思义就是不以某个标准或者框框作为约束的一种测试，对于我们测试人员来说，给我们最大的约束的就是测试方案和测试用例，有时候别人写好的东西我们直接执行就行了，就像我们根本就不需要思考一样，那个时候，就觉得自己马上就成为一个随时被淘汰的角色，因为只是执行，我比自动化工具差多了。（具体差多少，自己可以比较时间，金钱，效率，成功率，犯错率等等，保证让你无地自容。）
还好，现代的软件测试还没有发展到那么强大--完全可以依靠工具。但是不管怎么样，作为测试人员，我们的首要目标就是在产品上市前多找出缺陷，保证不会因为我们的漏测将缺陷遗留到现场去。我们每轮迭代按部就班，兢兢业业的将我们的用例跑一遍，却时常感到有点不靠谱，总感觉有地方没覆盖到，测过的地方好像还是有点问题，但是用例确实是执行通过了。这时候，你有什么办法？
此时，你需要抛开用例了。
发散测试帮你的忙，你完全可以不用盯着用例一遍遍执行步骤，你完全可以依靠此时你对系统的理解和分析得出你自己的结论，哪些地方好像不足，哪些地方需要再覆盖一下。笔者总结点自己日常使用的方法，虽然是班门弄斧，但是还是觉得有一点用，毕竟，它们都曾经发现过我漏测的问题。
（1）、2-8原则：测试的同学都知道有2-8原则，80%的缺陷发生在20%的代码区，这一块基本上是缺陷的高发区，不光主流程有问题，各种小毛病层出不穷。可是，你提了多少张问题单了？你的覆盖是否全面了呢？越是这个时候越要小心，有可能你自己测试的时候就放过了不同的问题，而自己却觉得是已知问题而一带而过。这种问题不止一次发生在自己身上，深有体会，发散测试需要重点关注这样的场景，你会收到意想不到的收获。
（2）、对比需求，参照设计：我们的用例写好之后还有多少同学会回过头去看但是给我我们启发的设计方案？我们还是否能够一直跟着需求文档对需求文档了如指掌，甚至比需求人员还要熟悉？测试人员凭什么说自己能够代表用户在进行测试？不就靠这个么？如果你对需求的理解，对设计的了解不如开发人员，人家要你干什么呢，你测试完成后现场用户提了一堆问题你测试一点责任都没有？怎么可能，最先追溯的就是你测试。如果出现设计和需求重大偏离的还会遭到投诉。我们作为质量的把关人员，整天和开发混在一起，很容易按照他们的思维走，认为这个东西就是这样。我们测试完成之后还是要认认真真的过下需求和设计，确保理解的一致。
（3）、用户场景：试问一句，有多少同学确切的知道现场客户如何使用咱们卖出去的东西？长期在研发体系混的大部分不知道。总是觉得应该是这样用的吧！例如一个最大容量是500个同时请求的系统，一般情况下有多少人在使用？我们需要使用500个线程一直连接测试系统的抗压能力么？完全不用。老同学们都知道其实这个系统长久的运行一般都是300号人同时，一年能够有几次500人的机会。就像移动的系统，他的设计规格可能是容纳春节期间的用户量的，但是我们测试人员就不用一直测试，毕竟春节也就那几天电话、短信暴涨，平时也就正常值的6成到7成。我们测试结束后可以让几个同学一起登陆系统操作，模拟用户的真实场景，并发情况等操作，系统是否采用了保护措施，虽然开发可能跟你说，这种触发的概率低，但不能因为低就忽略它，如果不测试，它就是个隐患，不知道什么时候就迸出来。
（4）、异常场景：我们有时候就过分的迷信了自己。我们的系统是强大的，健壮的。但是一次下电、一次主备倒换、一次异常重启，一次网络故障，我们的系统就Down掉了。这叫健壮么？我们要考虑到一切场景，例如用户操作到一半突然系统故障了，就像取钱，万一正在吐钱的时候ATM挂掉了？怎么办?用户升级后需要重启系统我们是否还能保留原来的数据和状态让最终的用户毫无察觉系统在主备倒换？灾难过后的数据能否正常恢复，不怀好意的用户进行的非主流操作你是否能够给予他警告并让其无法执行？我们都覆盖了么?
（5）、我们要根据规范，测试，不是无原则的发散，我们的规范、结论也是大家集体讨论的结果，是产生效率的保证，我们根据规范就能发现一些不规范的地方，常见的规范包含UCD规范、online、inline规范，设计规范，接口规范。我们根据规范，让我们的系统不至于那么难看，不至于让人一看，这些个页面、功能就是一群江湖郎中做出来的。
给自己总结，给大家分享，测试之路，越走越宽！
