互联网产品快速迭代下是否需要写详细测试用例

          由于自己在互联网电商公司工作，产品需求很多，平台功能迭代很快，有时一个功能需求评审+开发+测试 +上线总共只有1天时间的计划，而且有些紧急需求不允许delay，这时我们如何分配实际执行测试时间和测试用例编写时间？

       我认为我们不能一味的 墨守以前的测试流程，测试用例固然重要，但是如果写测试用例消耗了绝大部分测试时间，那将是得不偿失的，写过用例的都是知道，用例在实际执行中发现的BUG 并不比自由测试（根据自己的经验和对需求的理解，以及一些测试场景的自由组合）发现的BUG多甚至少很多，但是自由测试或者错误猜测方式测试需要较多的测试执行时间，这时候如果用例编写占用了大量时间 势必会压缩测试执行的时间，所以我提倡的是 在需求评审的时候进可能的深入理解需求，然后以列测试点的方式，抽象出需求中的测试点 及 可能影响的其他功能点，然后执行测试，根据自己的经验和对业务的理解 结合测试点列表 进行功能点测试及业务场景测试，尽量给测试执行提供尽可能多的时间,如果说一个测试人员没有这个能力，需要按测试用例执行测试才能开始测试，那绝对不是一个合格的测试人员，而且也不能写出高效的测试用例，既然写不出高效的测试用例，执行什么呢？执行那些敷衍上级的测试文字描述吗？剩下的那点可怜的测试时间能把被测对象测好吗？，反过来能写出高效的测试用例的测试人员，那执行测试的时候也可以不用按照既有测试用例进行高效的测试，毕定用例是死的，被测产品的功能组合是千变万化的，难道都列举出来？有个测试点列表已经够了，测试的时候可以参照测试点列表，只要测试点覆盖的够好就OK。

        至于详细测试用例是为以后的回归测试或自动化测试用的，可以在测试结束后补充一些或在适当时间定一个测试计划集中时间补充。天下没有无BUG的程序，也无100%充分的测试，只有合理安排资源和时间才能更好的完成自己的工作，才能更多的体现自己工作的价值；避虚务实才能更好的发挥我们测试人的作用。