（1）你们公司的测试流程是什么？

1.需求评审：需求评审主要是我们产品，开发，测试一起参加的，主要是针对产品的需求进行分析，产品经理会针对这项目需要作出什么样子的功能，有什么样子的要求限制进行说明，然后大家一起讨论可行性，制定大概需要的时间。

这里面实际应该有一个需求的分析，也就是我们测试的组员对产品制定需求进行分析，这样子也是对需求文档的一个测试，毕竟项目在越早发现缺陷，损失越小。所以需求分析也是对需求的可行性进行一个分析，讨论怎么依据需求来编写测试用例

2.编写开发、测试计划：开发计划我们不说，说说测试计划。测试计划，描述了要进行的测试活动的范围、方法、资源和进度的文档；是对整个信息系统应用软件组装测试和确认测试。它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可以有效预防计划的风险，保障计划的顺利实施。这个是来自百度的解释，也就是说我们制定有效的测试计划，我们应该遵循我们制定的计划来进行我们的工作，项目的不同阶段，我们需要做什么事，遵循计划来。

3.测试的测试用例编写：测试用例是根据需求文档来编写的，其中编写测试用例的方法和手段有很多种，其中我给大家以黑盒测试来说一写方法：a划分等价类，b边界值分析法,c错误推测法,d因果图法,e判定表组成法,f场景法。以上这些方法大家可以了解一下，有一些在我的博客也有谈到，后面文章也会对这些测试方法进行说明举例，让大家有一个深入的认识

4.测试用例评审：编写好测试用例之后，不是说我觉得写了这些就OK了，还需要对测试用例进行评审，不同公司可能对测试用例评审的参与人员要求不一样，有的可能只是测试组内进行评审，有的可能会与开发，产品一起进行评审，这样子的好处是开发知道我们要怎么会，会对哪些功能哪些细节多注意一些，同时开发或者产品给我们测试提一些测试覆盖的建议，或者是测试用例的冗余，从而达到提升软件质量的目的

5.在我们编写测试用例的同时，我们的开发也在进行紧张的编码工作，等到产品做出来，开发会先自测，然后觉得O了，他们便会提测，通过发邮箱或者其他一些手段，告诉我们可以测试。

6.接到提测通知之后，我们就可以开始测试了，当然是基于你已经部署好了测试环境的情况下。冒烟测试：我的理解是对软件基本的功能与流程的测试，比如说，我开发了一个电商购物网站，最主要的就是购物下单支付流程，所以需要对这些功能进行测试，假如说这些个功能都没实现的话，那么下面的测试也就没必要，最主要的功能没实现，开发需要去修改，代码的改动对整个的软件影响还是很大的。所以冒烟测试不通过，直接打回让开发再改。

7.冒烟测试通过之后，我们就进行正式的测试，一般会有三轮的测试。第一轮测试之后，把发现的BUG提到公司的缺陷管理工具上面，让开发改，开发改好之后，部署到测试环境，并且修改管理工具上面的状态。接着我们对BUG进行回归测试，验证BUG还存不，如果存在，修改缺陷管理工具的状态为重新打开。直到BUG修复完成，我们把缺陷关闭掉。当我们在第一轮测试时，提交的BUG都改了，或者剩下一些疑难杂症时，按照我们的计划可以开始下一轮的测试。在一轮一轮的测试中，发现的BUG 会越来越少，知道我们把BUG全部消灭或者剩下一些不影响使用的BUG，我们就可以进行验收测试了。在我们公司是扔给产品，他说好，可以了。那我们就进行发布了。

8.产品上线之后，我们还需要进行回归测试，毕竟正式的生产环境和测试环境还是有一些区别，毕竟环境是一个很玄学的东西，回归测试可以依据测试用例的优先级来测，把要的功能，重要的功能测一下，还有需要对之前存在BUG的功能进行测试。测完之后，整个的项目就可以进入下一个版本迭代了。

（2）如何设计测试用例？

等价类划分法、边界值分析法、场景法，因果图、错误推测法

1. 等价类划分：把所有可能输入的数据分为若干个区域，然后从每个区域中取少量有代表性的数据进行测试即可，分为有效等价类和无效等价类。

2. 边界值分析法：取稍高于或稍低于边界的一些数据进行测试，使用离点、上点、内点确定取值。

3. 错误推测法：测试经验丰富的人喜欢使用的一种测试用例设计方法。

一般这种方法是基于经验和直觉推测程序中可能发送的各种错误，有针对性地设计。只能作为一种补充。

4. 因果图方法：比较适合输入条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出。

5. 场景法：通过模拟业务场景来对系统的功能点或业务流程的描述，从而提高测试效果的黑盒测试方法