自动化测试的流程

　　自动化测试就和单元测试、集成测试、系统测试等阶段一样，都是一个独立而且完整的测试阶段。

　　它要经历自动化测试计划、自动化测试设计、自动化测试实现和自动化测试执行四个阶段(这就是所谓的V模型)。

　　按阶段来看的话，它介于集成测试和系统测试之间，或者说是介于集成测试和确认测试之间，又或者贯穿于集成测试、确认测试和系统测试这个阶段(这就是所谓的H模型)。具体要视具体情况来制定。比如你们的集成测试是做到子系统间的集成，那么这个阶段已经可以引入自动化测试了，要注意的一点是这个自动化测试最好由独立的自动化测试团队来完成，使得项目进度不至于在关键路径上停留，可以并行开展。

　　入口和出口准则相对比较容易。就像系统测试会进行系统预测试一样，自动化测试有自己的自动化测试用例，这部分的用例可能选取自系统测试用例或确认测试用例，而且很大一部分可能就是来自系统预测试的用例。通过执行这些用例可以获得出口的准则(这里只是指自动化测试活动的通过标准，不是软件系统的通过标准)，就是：所有的自动化用例100%的得以执行，用例密度达到10cases/Kloc(这个数字只是举例而已)。而入口准则则是通过了冒烟测试(但是这不是绝对的，有可能是系统预测试之后)。

　　这里要把冒烟测试、BVT测试和系统预测试几个概念弄清，冒烟测试一般是由开发人员执行的，可以没有测试用例，这种测试是带有随机性质的。BVT测试发生在每日构建中，通常正是由自动化测试工具来执行的。系统预测试由测试人员选取重要级别相对较高的系统测试用例来进行。

　　之所以这样安排是因为：自动化测试能在人之前发现错误，避免浪费无味的人力资源。

　　其实如果安排在系统预测试之后也是一种方案。它的意义在于：对于系统趋于稳定的时候适合采用这种方案。而前面的那种方案适合在测试用例相似性非常大的系统中开展。

　　这里又要纠正一个误区：自动化测试并非只是适合在需要大量回归的测试执行时才需要的。比如我们现在只做两轮的测试，这种情况是否就一定不适合采用自动化测试?答案是否定的，假如我们的系统有如下的特征性还是可以采用自动化测试：测试用例具有极大的相似性。也就是说，可能测试的步骤都是一样的，只是输入参数的不同。假设我们现在有一千条测试用例，每个用例的步骤都是一样的，只是输入数据不同(也就是说等价类非常多)，那么这种情况即使只做一轮的测试，没有回归，也还是可以采用自动化测试的。

　　关键是要结合具体情况进行具体分析。不能盲目的把书本上、课堂上的知识照搬照套。企业需要能随机应变的工程师。

　　至于说保证自动化的质量，那就不止是自动化本身的问题了。它取决于：人、技术、过程。好的过程需要有SEPG的参与，SQA的监督和指导。

　　保证了三者，才能保证自动化的质量。

　　以上内容为大家介绍了自动化测试的流程，希望对大家有所帮助，如果想要了解更多接口自动化测试相关知识，请关注多测师。https://www.aichudan.com/xwzx/