标签：case 介入 测试人员 开发 测试数据 测试 自动化
自动化测试是在开发阶段就介入呢，还是等手工测试结束之后，系统功能稳定后，介入？ 首先，搞清楚自动化的目的是什么？ 提供工作效率，运行自动化测试用例可以同时做其他的工作，而且测试效率有了提升，大量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
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。