自动化测试介入的时机

自动化测试是在开发阶段就介入呢，还是等手工测试结束之后，系统功能稳定后，介入？ 　　首先，搞清楚自动化的目的是什么？ 　　提供工作效率，运行自动化测试用例可以同时做其他的工作，而且测试效率有了提升，大量case可同时运行 　　提供运行的准确性和稳定性，避免外界因素的影响 　　避免重复劳动，防止大量的手工回归测试，节省成本 　　对测试人员而言，也是提高技能的一种手段 　　上面的4点，是我对自动化测试目的一个总结，我对自动化是否有意义的判断也是基于上面的认知。当然你也可能会有其它一些想法。 　　对于上面提到的那个问题, 我觉得还是不好解释，毕竟场景不同，其对应的方案也会不一样。从我现在所在的团队来看，这样的问题，我会从整个项目的周期来判断，下面是目前我们的一个做法，当然并不是很完整，我简单说一下过程。 软件开发流程，大家比较清楚的可能是瀑布流程，敏捷开发这些。不管采用什么样的流程，测试的工作如何接入配合到开发流程中才是最重要的，最关键的。而不是去考虑什么时间去做自动化测试，自动化测试应该是在合适的时间就得开展。 　　现在，我们不会去区分角色，功能测试人员和自动化测试人员应该就是一个人，测试人员应该对应于一个产品，而不是一种技能。 　　项目前期，kickoff结束，测试同学就应该参与到项目中，对项目的需求进行一定的把握。下面的流程是我们测试的一些关键时间点： 　　1. 需求评审 　　这个阶段可以了解项目的背景，并开始和开发，PD沟通一些功能上的设计问题。为后面设计case提供一些思路。 　　2. 开发设计&&测试用例设计 　　有些工作并不一定要等到开发全部完成再进行，紧密沟通合作，保证项目向前推进。在开发设计阶段就可以参与进来，并在开发设计完成后，对应完成测试用例的设计，明确哪些case可以实现自动化，并选择好测试框架和工具。 　　3. 分层测试&&可自动化的部分先行 　　在未得到稳定的测试版本之前，可以准备测试数据，一键部署的脚本，已经对应测试框架，测试代码的编写。不一定要全部完成，但至少准备工作都得做好。 　　4. 冒烟&&测试执行 　　提测之前，对部分重点功能进行常规冒烟测试。达到预期后，进行功能测试。这个测试工程中，即可以对一些自动化测试的case进行编码调试，后面这些功能可以在回归执行中有非常大的作用。 　　5. bugfix版本，自动化回归 　　对应一些bugfix的版本，除了验证bug之外，还得将之前的功能进行回归，这个阶段，自动化的case将节省不少的精力。 　　6. 稳定版本，自动化回归，预发环境自动化验证 　　在发布上线之前，会准备一个稳定的环境，做一次全量的测试执行，当然自动化case也是这个时候的重点。 　　7. 发布上线，冒烟 　　待上述测试执行都结束了，意味着项目也就安心上线发布了。这个时候需要简单的冒烟测试即可。 　　经历这么一个项目的过程，自动化的case肯定是需要占有一定的比例。当然，大家肯定还是存在下面的一些疑问 　　开发还未提交测试，或者功能也未稳到，如何进行自动化的测试？ 　　这个问题，我从下面的2点进行解释，其实前面我也有提到这些。 　　a.接口测试，待测的接口肯定需要事先定义好，这里更多的应该是测试数据的准备，已经测试类的编写，case的逻辑可以体现出来，当然调试case需要放到功能开发出来，但是我们的准备工作要都搞定。 　　b. UI自动化，大家都会说页面还没出来，怎么写？道理是一样的，设计出来的场景是事先通过需求文档，交互PRD这些进行确认过的，同样，需要的测试数据可以先准备出来，代码的逻辑也可以写出一部分，这个时候缺的应该就是页面元素。 　　如果设计的合理，我们的case应该做到测试数据和测试代码进行分离，这样你需要的部分可以配置为参数的形式，后期传入 　　现在，在阿里不管是接口测试还是UI自动化，基本上都是在与开发同步进行，我们需要将自动化的作用最大化，提高测试的效率。 　　所以，我最终的建议是尽量提前来做，将自动化的价值最大化。

标签：case,介入,测试人员,开发,测试数据,测试,自动化
来源： https://www.cnblogs.com/shyzzx/p/14835538.html