育才学习网1. 软件测试面试 叫我写一个自动化测试用例,能够实现24小时自动测试
1、首先，明确测试的产品和需求，例如：是一个web界面测试还是CLI测试；需求是对界面进行一个操作还是进行一系列的配置
2、明确测试产品和需求之后，然后就是选择测试工具或者直接用脚本进行接口的调用
3、然后就是回放进行测试，而24小时的话，你只需加一个循环操作，在循环操作里加一个if判断，如果时间到达24h，则break出循环即可。
总之，一个自动化测试用例，其是是对一个手工测试用例的脚本化，也可以说是程序化，然后加一些自己的逻辑判断，就可以实现24H自动化测试了
看看有没有帮上你~
2. 如何写好自动化友好的测试用例
1.步骤和数据的分离：好的测试用例，在执行的步骤（Step）的表达上应该是尽可能和数据相分离。
举例来讲，有一个ATM机取款的功能，可能有以下几个场景：1） 密码正确的登录2） 密码错误的登录3） 密码输入三次错误，卡被锁定4） 取少于余额的款项5） 尝试取大于余额的款项6） 尝试取等于余额的款项（考虑手续费）6） 取款额度大于当次的限制7） 取款额度大于当天的限制8） 取款次数大于限制次数等等不管你用什么用例设计的方法论来做指导，作为这个简单的例子，有经验的人都应该能看出，此处的很多步骤是可以重用的，总结下来如下（此处只列出了操作的步骤，略去了系统的交互中的反馈结果）：1） 插入卡->A：输入密码->B：按“确定”键->重复A-B2) A：选择取款功能->B：填写取款金额->C：点击“确定取款”的按钮->D：取现金->重复A-D因此，我们只需要写出两套比较完整的步骤，将密码和取款金额多数字用参数来表达即可。这样是不是简单了很多呢？2. 单独的测试基础数据准备工作第一个例子中的输入数据比较简单，但我们同样需要考虑的一个问题是：在测试中究竟我们输入什么样的具体数据呢？什么是”正确的密码“？什么又是”大于余额的款项“呢？对 于大的应用系统，数据之间的关系和准备过程都会很复杂，甚至也有其他外部系统导入、传输或计算出的数据。
一个比较好的做法是，将这些测试数据提前准备好，在每个阶段性测试前导入到系统中。一个比较典型的例子，假设要求你单独去测试几张复杂的财务报表，用其他的模块和外部系统，自己逐一的去创造数据，那会非 常耗时耗力。
这时，基础数据的准备就显得尤为重要，以此才能保证测试工作是高效的、测试结果是精确的。如果有可能，复杂的测试基础数据最好是提前准备好的，类似这里例子中简单的 一个帐号为1234567890，密码为66666的有效银行卡，里面有人民币1000元正，等等。
将这些内容预先准备好（可以用自动化工具来准备，或导 出已有的数据为一个SQL的脚本），写到你单独的测试数据准备文档中，而不是分散到 所有使用到它的case中才去描述。3. 测试用例的前置条件和后置条件除 了第二点中谈到的数据需要准备外，在测试用例这个Level，必须有一些条件满足，您才能开始执行它。
比如准备一个初始设置条件下的IE 浏览器和已安装过老版本该软件的XP系统。这些可重用的准入条件，可以考虑不作为特定用例的Step，而是把它提取出来，作为Setup Section或叫Pre-Condition。
对于后置条件或Post- condition，往往我们用它来做一些处理或恢复，比如在上面的取款例子中，如果我们要用相同的帐号重复测试，在正好取完所有金额，余额为零的情况 下，可以通过一些步骤或数据库脚本重置帐号余额。同样，您为某个用例设置浏览器禁用了Cookie，执行完该用例后，是不是也是需要回复到默认设置的状态 呢？集中的把这些步骤整理成一个相对独立的操作单元，具体用例中只要引用就可以了，这样会便于对用例的理解和在多处复用。
顺便说一下，对于一些类似软件运行环境的条件，比如安装和配置测试中，需要3种操作系统和3种浏览器的组合等，我们可以把他放在Test Set这个Level上来，不用写多个用例，只是在测试计划和执行的管理系统中作为测试集的一个环境参数，恰当地表达出来就可以。4. 常用业务操作（Knowledge Base）对于一个大型的应用，比如银行系统，开发和测试工作是长期的，持续的一个过程，这样的系统很适合引入自动化测试。
它业务逻辑复杂，测试技术性要求高，往往使用了不同厂商的工具和多种脚本语言（如Shell,Python等），也存在了很多可用的遗留脚本。这些完成一些预定业务操作的脚本单元，是可以直接借用的。
为了在公司和产品层面，管理好这些可复用的资源，一种好的方式是给它们标上号，如KB_PRJ01_Module02_XXX，集中管理起来，以后的用例中只要调用即可。举 例来说，在银行业务测试中我们，需要模拟和银联的接口，让测试帐号向外汇款，取得响应信息，并保存结果，这可能是个复杂而底层的处理过程，对一般员工是不 需要，也没有权限去深入掌握的。
这时，将他们包装成一个个Shell脚本或小工具，做好使用说明和统一建档，在以后的项目测试中，只要调用就可以了。如 此，可以大大提高各个有相关接口的模块的自动化测试工作效率。
根据以往工作中常见的一些问题，对于如何写好测试用例（不仅针对自动化测试），做以下做几点补充：推荐不推荐将用例的内容描述清楚，强调怎么操作，验证什么，然后期待的结果是什么。 Copy需求和设计文档中的内容；描述成：什么条件下，逻辑会是怎样。
这样对测试用例的阅读和执行人员，不具有可操作性。 期待的结果要写具体，如：系统反应是什么；结果数字是多少；用户被带到什么页面；显示什么成功信息；后台或数据库中该记录的修改后结果是怎么样的。
描述成：”验证系统返回正确结果“；”页面元素显示跟SPEC一致“；”操作成功“等 比较抽象的说法。 业务逻辑性较强的应用软件，做到以业务流为主线，来组织用例。
以页面形式组织用例。 以Module、F。
3. web自动化测试中稳定的功能有哪些
这个问题我从昨天开始看了两三次，想写点什么但又不知道怎样写。
从我看来，你这个问题问得太泛了。
web自动化测试中稳定的功能有哪些？这个。我真不知道怎样回答。
web自动化测试有很多工具，使用的工具不一样，就有不一样的答案。
但我想你应该有个误区，我们不是根据web自动化测试稳定的功能来写测试用例的，应该根据项目的特点来写自动化测试。
如果你公司的项目的开发周期足够长，需求变动少，那你可以为这整一个项目写一份完整的测试用例和自动化测试脚本。
如果你公司的项目开发周期短，需求变动频繁，那你可以总结之前公司发开发的项目，总结出它们相对比较稳定的功能，为这些功能模块专门写一个测试用例和自动化测试脚本，这部分是可以重复使用，而且维护难度低。
4. 自动化用例如何编写
通俗来讲，自动化用例分为功能用例（文字）和.代码用例（脚本）两个方面，先有功能用例在其转化为代码用例去执行；
1？？功能用例（文字）：
说明：通常执行自动化测试时，功能测试已执行完毕，而自动化测试本质上归属功能测试，所以自动化测试用例都是通过功能用例进行抽取和转化，只需要在功能用例模版上添加一列[是否自动化]即可；
2？？代码用例（脚本）
说明：代码用例就是将转化来的功能用例使用编程语言（python\java）来实现功能用例的操作步骤、预期结果等，当然在实际操作中要结合相应的用例执行框架比如python中的unittest\pytest或java语言中的junit\testng，具体详情可以到网络上找下黑马程序员自动化测试视频，之前在他们官网上看过一阶段视频。找不到去官网对话框问一下也能领取
5. 如何设计一个完整的测试用例
软件测试的W模型，就要求测试与开发同步，在开发设计需求设计说明书的时候就开始测试流程，一般情况下，讨论需求设计的时候需要测试主管或者组员的参与，了解这个项目设计的总体情况。
事实上，测试用例的编写一般是在需求设计说明书定下来之后才真正的开始的。因为测试用例的内容要以需求设计说明书为依据，设计说明书上没体现的功能，不需要在测试用例中体现。
编写测试用例（这里指功能测试用例的编写），首先要做的就是设计测试用例的模板。每个公司都有适合自己公司用例编写的模板，各有各的特点。
测试用例的格式包括，测试用例摘要、测试用例需求编号（一个需求设计说明书可以分好几个用例编写）、编写用例的日期、编写人员、编写日期、前置条件、准备数据等等。格式没有固定的要求，可以根据自己测试用例设计的思路，对测试用例的格式作相应的改变。
下面以一个登陆窗口为例，说说我设计登陆界面的思路和方法。我把这个测试用例分为三层结构，表单测试、逻辑判断、业务流程。
第一层，表单测试为最底层（最基础的）。这部分的测试用例是对登陆窗口这个界面的输入框、按钮功能、界面等最基本功能的32313133353236313431303231363533e4b893e5b19e31333332636336测试。
一般来说登陆用户名和登陆用户密码是输入框的形式体现，那么，我们需要的是针对这两个输入框进行功能的测试。这时，我们只要考虑这个输入框的功能，而不需要考虑业务方面的内容。
这样，我们考虑就是这个输入框的长度限制是多少？能否输入特殊字符？能否输入全角字符？当然，登陆窗口还有其他按钮，例如登陆按钮、退出按钮、界面设计等，这一层的测试用例只对他们最简单的功能的测试。我觉得这一层的测试用例对新开发项目很重要，也必须执行，因为这些是最基本的功能保证，当项目进入维护阶段后，如果没有修改就不需要执行这部分的测试了或者说把这层的用例优先级置为最低，时间不充足的情况就不用去执行。
第二层，逻辑判断层。根据需求的设计，各功能之间的简单逻辑联系。
以登陆窗口为例，账号登录，账号和密码必须对应才能登录，否则登录失败。根据这一点，我们就可以从这个要求设计这一层测试用例。
例如，账号和密码不一致时；账号为空时；密码为空时；账号密码对应时等等情况。输入这些情况时，程序是作怎么样的逻辑控制的？控制是否正确？是否有相应的提示信息？我觉得，这一层的用例时最常规的一层，平时使用这个软件用经常碰到的一些情况，在常规测试或修改这部分的功能之后，这一部分的测试用例也必须执行。
第三层，业务流程层。这部分不关心软件的本身的基本功能，而是关心这个软件的业务有没有实现，不同的需求就有不同的业务需求。
以登陆窗口为例，就可能有不同的需求，可能用户要求停用的账号能够登录系统（可能要求登录后不允许进行其他操作），也可能用户直接要求停用的用户账号不准登录系统。根据不同的业务需求，就有不同的业务流程。
这样这层的测试用例，我们就只要考虑业务需求，仍然以登录窗口为例，我们就只要考虑删除的用户能否登录？停用的用户能否登录？超级用户是如何登录的？普通用户是何种方式登录的？简单的说，这层的用例只描述业务流程，不关心具体这个业务是怎么实现的，执行这部分用例时，不要考虑哪个输入框控制了多少长度，能否输入空格等其他功能，因为这部分的测试需要基于上面两层的测试用例都已经测试通过了，所以在项目维护阶段或者说时间很紧迫的阶段，我们只需要执行这部分的用例，保证业务能够通畅的完成。其实个人觉得在执行这部分用例时，对包含了对基本功能的测试，一些明显的问题应该能被发现，虽然严格来说测试覆盖率很低，但是基本能达到要求。
这三层的组合起来才是一个完整的测试用例。这是我个人对测试用例设计的一个思路和方法。
真正设计这个测试用例的时候，可能会使用到黑盒测试用例的方法，例如等价类划分、边界值分析、错误猜测法（主要是个人经验）、正交分解等方法针对具体情况设计测试用例。分层测试用例的思路主要来自对自动测试实现的考虑。
因为我觉得，如果需要实现自动化测试就必须对测试用例进行细分，划分得越细就越有利于自动化的实现。以上三层的划分也并不是很全面，需要在实践中不断完善，例如可以增加对数据库的部分功能的数据校验的分析。
总之，测试用例写的细致、全面、步骤清晰，那么无论是用手工测试的方法还是用自动化测试的方法实现，只要能完整的跑完整个测试用例，就达到了测试的目标了。
转载请注明出处育才学习网 » 自动化测试用例怎么写