工作中遇到的一些问题;
1.时间段任务多，测试用例应该写不写？为什么要写测试用例？面对这种情况我们应该怎样写测试用例？
2.如果一方的测试任务特别多，我们该怎样调配人手介入配合？面临的问题是没参与过这块的业务，不知道该怎么入手，熟悉花费的时间太长？
3.代码回滚对这个系统的影响？具体看回滚的内容是什么？
4.回归测试是什么？我们回归测试都测些什么？场景测试和基础功能测试的区别是什么？
5.回归测试的覆盖率要达到多少？
1.首先我们需要明白我们需要做些什么？（1.尽可能的暴露出测试的软件与 客户需求不符的地方，也就是我们要非常的清楚软件是不是客户想要的那个样子，也就是软件的质量是否达到客户期望水平 2.我们要时时的向本次参与这个项目的所有人时时的反应软件目前各种问题，离客户期望的样子有多远，也就是让所有人明白我们现在做的东西质量怎么样，那么其实我们的用例就是一个很好的让大家深入知道我们到底测了那些东西的一个产物，我曾看过一本书，他说与事实为友，我们才能更好的认识自己，看到自己的不足，然后针对这些不足之处一一的解决掉，我也觉得是这样的）
任务多时间少，我们该怎么处理用例问题？我个人理解，这种情况属于特殊时期，那我们应该做一些特殊的措施。1.根据时间多少来定，写多少，可以抓住产品经理最关注的一些业务场景，也就是重点业务场景，和痛点业务场景，我理解的痛点业务，在评审需求的时候一些复杂的或者容易出错的场景，我觉得抓住重点和痛点业务也就是解决了大家最关心的问题，至于什么输入框限制了什么的我们可以根据时间多少来定要不要反应在用例里面 2.用例的步骤详细程度，也是视时间来定，如果时间段我们可以简化步骤，因为参与这个项目的同事肯定也是有一定业务基础的，我们适当的简化应该也是可以看懂的
2.测试任务多时我们需要应该怎么样让同事快速的接入呢？
首先要明白一下几个问题：们参与过此项目的人，不懂业务是硬伤，也不知道这个系统的核心和复杂业务层是什么。
可以让临时参与进来的同事参与到此次发版计划的回归测试当中，当然需要我们平时尽可能写一些比较详细的回归测试用例，目的就是要拿着你这个用例，他要做的是不需要懂业务，只要能跑通，是你写的这个用例想要的结果就行、
3.代码回滚问题：我们需要和开发同事确认一下我们具体回滚的那些内容，回滚了多少，是前端的，还是后端的，回滚的这些主要对于那些内容有影响，经过这些了解我们应该可以初步的定位我们接下来要主要针对那块重测多少，测什么，等，当然我们不提倡代码回滚，因为回滚就意味着我们对某些东西要重测，无疑是增加了我们的工作量。
4.回归测试：我理解回归测试包括三部分部分（1.常用业务场景可以理解为重点业务和痛点业务回滚 2.主要修改部分和新增部分回归 3.缺陷回归）
场景测试和基础功能测试我理解是：基础功能冒烟，和场景冒烟，基本上是重合的，但是有时候，一些常用场景冒烟用不上一些功能点，比如:一些常用场景用的最多的就是新增，删除和修改几乎不用，所以冒烟场景往往就测个新增就行了，但是在功能点上，我们要保证删除个修改是可用的，不能一点就报错，如果纯粹的测功能点，可以暂时的不考虑连续的业务场景，也可以在测场景的时候一起测，但是场景没有测到的功能点，需要单独，点一下，看看。
5.至于回归测试的覆盖率能达到多少这个要根据实际情况来定，反正回归测试就是最后发版前的我们整体通跑环境，跑重要场景，重要的功能模块，以及比较严重的缺陷。