5个自动化测试用例设计的原则_自动化测试用例的设计原则有哪些

最新推荐文章于 2024-05-08 09:19:41 发布

2401_84239901

最新推荐文章于 2024-05-08 09:19:41 发布

阅读量744

点赞数 5

分类专栏： 2024年程序员学习文章标签：自动化测试用例运维

本文链接：https://blog.csdn.net/2401_84239901/article/details/137659516

版权

2024年程序员学习专栏收录该内容

116 篇文章 0 订阅

订阅专栏

原则2：自动化测试用例的选择一般以“正向”为主。

手工测试用例分正常情况和异常情况，在设计的时候，可能往往会去设计很多异常情况来验证程序是否有Bug，并且一个正常情况的测试用例往往会对应几十个非正常情况的测试用例，而每种异常情况的测试用例都会有各种各样的预期结果。在自动化测试中，很多人喜欢将正常情况称为“正向”；反之，异常情况则称为“反向”。下面，我们试想以下，如果将这些异常情况全部转化、反应到自动化测试脚本中，那肯定需要非常繁琐的判断才能做到。这个对于自动化测试工程师来说，其现有的工作量还是今后的脚本维护量都是不可小视的。对于整个自动化测试项目来说，如果每个异常情况都要写进脚本中，那真的是花了大价钱买一堆小东西，小东西真正能发挥大作用的毕竟很少。因此，真正在自动化测试项目实施中，往往会舍弃反向用例，个别比较重要的除外。使每个东西都能发挥其最大的作用才是企业最想看到的。功能自动化测试主要还是用于回归测试，回归测试的目的就是保证新增功能后老功能是否能够正常继续运作。而自动化测试则是让测试人员从繁琐又枯燥的重复手工测试中解放出来，这就是目的和目标。

原则3：不是所有手工测试用例都可以使用自动化测试来实现的。

这里纠正许多测试从业人员的一个错误观念，刚接触测试自动化的普遍都会认为手工测试用例全部要转化为自动化测试用例，但是在真正实施的时候，却发现很多测试用例是自动化无法实现的，或者有些测试用例根本就没有必要去自动化的。例如，有些用例会牵涉到硬件设备辅助的，最简单的例子就是用例执行过程中需要使用刷卡机才能获取卡号信息（如果有技术能力，当然不排除自行开发接口供测试工具调用，但毕竟能有技术实力做到这一步的不多，能有这样的重视程度的更不多）；再比如，有些测试用例是需要与合作机构进行互动联调，联调时是需要和对方实时沟通，以及根据具体情况给予响应的，这些情况多数还是只能使用手工人为地来完成。当然，决定是否转化为自动化测试，必须事先有一个规范文档来定义哪些是需要转化为自动化测试哪些是不需要的，否则测试工程师就会不知所措，没有一个标准。一旦有了这个标准，自动化测试工程师就可以严格按照文档里的流程去完成需要转化部分的自动化测试用例的脚本开发工作了。

原则4：手工测试用例可以不用回归原点，而自动化用例往往是必须的。

很多有经验的自动化测试从业人员一定有这样的经历，很多时候脚本写完后，第一次执行没有任何问题，而第二次执行时立刻就会报错，原因就是没有回归原点。所谓回归原点就是执行的测试用例最终需要恢复其在执行前的初始状态，如果没有回归原点，就会把此脚本称之为死脚本。举个最简单的例子，比如添加用户功能，我们都知道每个用户名都是唯一的，当写完一个添加用户的脚本之后，执行第一次没有问题，因为执行前此用户还不存在，但是当执行第二次时，程序就会出现用户重复而报错，此时这个添加用户的脚本就失去了它的价值，在这种情况下，我们就需要在自动化测试用例的最后加上删除这个用户的步骤，这样在下次执行用例时就不会出现用户重复的情况了。当然，除了回归原点，还可以使用另一种方式进行，那就是初始化数据，比如ATM机取款，假设需要执行取款100元的操作，而银行卡余额是120元，当测试脚本第一次执行时可能没有任何问题，但是第二次系统就会报余额不足，这样就成为了死脚本，解决方案有两种：一种是直接进行初始化数据，每次执行用例之前都重置下余额（只需大于100即可）；第二种方法可以在用例执行前，先查询下余额是否大于100，若大于等于则继续，若小于则做一笔充值100的操作，这样即可解决。两种方式可以看具体情况使用，数据初始化方便，但有时候初始化之后可能会影响到其他自动化测试用例的执行，而第二种方式相对在脚本上需要稍微花点功夫。究竟使用哪种方式还需要具体情况具体分析。总之，在执行自动化测试用例之前做好数据准备，这也是自动化测试的关键步骤。

原则5：自动化测试用例和手工测试用例不同，不需要每个步骤都写预期结果。

在手工测试用例的设计过程中，几乎每一个测试步骤都有一个预期结果。但是，在自动化测试用例的设计中并不采用，在自动化测试用例中，只有准备在测试脚本中设置成检查点的步骤才有预期结果，其他所有的步骤只将它看作一个步骤，这样做的好处是一目了然、目的明显、层次分明，以后写测试脚本直接跟着自动化测试用例就行了。因为经过前面的探讨应该已经知道，自动化测试中并不是所有的东西都需要验证的。所以，作者在前面的章节中也提到过，基本上手工测试用例多多少少都要进行一些转换的，就是因为它们之间的格式是不一致的。举一个简单的例子，假设需要设计一个注册页面的自动化测试用例，有10几个表单需要填写，在手工测试用例中，每个表单的填写都一定会有预期结果，因为它的确在检查每一项是对了还是错了，只是用的是你的眼睛在检查而已，所以速度非常的快，甚至你自己潜意识都忽略了其实你已经检查了。但是，在自动化测试中，我们知道如果你要检查，那一定需要写代码，如果每项都检查，那代码量有多大是可想而知的，不是说做不到，只是这样做根本不符合自动化测试的特点。所以，绝大部分时候，这些在自动化测试中可有可无的检查，我们全部“不检查”，只当做一个业务流程和步骤，是不需要设立预期结果的。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数软件测试工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年软件测试全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。