文秀网1.自动化用例如何编写
通俗来讲，自动化用例分为功能用例（文字）和.代码用例（脚本）两个方面，先有功能用例在其转化为代码用例去执行；
1？？功能用例（文字）：
说明：通常执行自动化测试时，功能测试已执行完毕，而自动化测试本质上归属功能测试，所以自动化测试用例都是通过功能用例进行抽取和转化，只需要在功能用例模版上添加一列[是否自动化]即可；
2？？代码用例（脚本）
说明：代码用例就是将转化来的功能用例使用编程语言（python\java）来实现功能用例的操作步骤、预期结果等，当然在实际操作中要结合相应的用例执行框架比如python中的unittest\pytest或java语言中的junit\testng，具体详情可以到网络上找下黑马程序员自动化测试视频，之前在他们官网上看过一阶段视频。找不到去官网对话框问一下也能领取
2.软件测试面试 叫我写一个自动化测试用例,能够实现24小时自动测试
1、首先，明确测试的产品和需求，例如：是一个web界面测试还是CLI测试；需求是对界面进行一个操作还是进行一系列的配置
2、明确测试产品和需求之后，然后就是选择测试工具或者直接用脚本进行接口的调用
3、然后就是回放进行测试，而24小时的话，你只需加一个循环操作，在循环操作里加一个if判断，如果时间到达24h，则break出循环即可。
总之，一个自动化测试用例，其是是对一个手工测试用例的脚本化，也可以说是程序化，然后加一些自己的逻辑判断，就可以实现24H自动化测试了
看看有没有帮上你~
3.自动化测试脚本一般用什么语言写
我主要是做web测试的，最近也在研究自动化测试。
自动化测试主流的工具应该是QTP吧，这个你可以去51testing论坛搜到很多相关的资料。QTP是一个商业软件。
“不同的工具就要使用不同的脚本语言吗？”-对于这个，我才疏学浅，不好回答。但主流的脚本语言有java、ruby、python吧，
有些工具是跨平台、跨语言的。我使用cucumber+ruby+selenium-webdriver,cucumber用来写测试用例，ruby作为脚本语言，selenium-webdriver是用来驱动浏览器的。
如果楼主也是搞web测试的，我们可以交流交流
4.如何设计一个完整的测试用例
软件测试的W模型，就要求测试与开发同步，在开发设计需求设计说明书的时候就开始测试流程，一般情况下，讨论需求设计的时候需要测试主管或者组员的参与，了解这个项目设计的总体情况。
事实上，测试用例的编写一般是在需求设计说明书定下来之后才真正的开始的。因为测试用例的内容要以需求设计说明书为依据，设计说明书上没体现的功能，不需要在测试用例中体现。
编写测试用例（这里指功能测试用例的编写），首先要做的就是设计测试用例的模板。每个公司都有适合自己公司用例编写的模板，各有各的特点。
测试用例的格式包括，测试用例摘要、测试用例需求编号（一个需求设计说明书可以分好几个用例编写）、编写用例的日期、编写人员、编写日期、前置条件、准备数据等等。格式没有固定的要求，可以根据自己测试用例设计的思路，对测试用例的格式作相应的改变。
下面以一个登陆窗口为例，说说我设计登陆界面的思路和方法。我把这个测试用例分为三层结构，表单测试、逻辑判断、业务流程。
第一层，表单测试为最底层（最基础的）。这部分的测试用例是对登陆窗口这个界面的输入框、按钮功能、界面等最基本功能的测试。
一般来说登陆用户名和登陆用户密码是输入框的形式体现，那么，我们需要的是针对这两个输入框进行功能的测试。这时，我们只要考虑这个输入框的功能，而不需要考虑业务方面的内容。
这样，我们考虑就是这个输入框的长度限制是多少？能否输入特殊字符？能否输入全角字符？当然，登陆窗口还有其他按钮，例如登陆按钮、退出按钮、界面设计等，这一层的测试用例只对他们最简单的功能的测试。我觉得这一层的测试用例对新开发项目很重要，也必须执行，因为这些是最基本的功能保证，当项目进入维护阶段后，如果没有修改就不需要执行这部分的测试了或者说把这层的用例优先级置为最低，时间不充足的情况就不用去执行。
第二层，逻辑判断层。根据需求的设计，各功能之间的简单逻辑联系。
以登陆窗口为例，账号登录，账号和密码必须对应才能登录，否则登录失败。根据这一点，我们就可以从这个要求设计这一层测试用例。
例如，账号和密码不一致时；账号为空时；密码为空时；账号密码对应时等等情况。输入这些情况时，程序是作怎么样的逻辑控制的？控制是否正确？是否有相应的提示信息？我觉得，这一层的用例时最常规的一层，平时使用这个软件用经常碰到的一些情况，在常规测试或修改这部分的功能之后，这一部分的测试用例也必须执行。
第三层，业务流程层。这部分不关心软件的本身的基本功能，而是关心这个软件的业务有没有实现，不同的需求就有不同的业务需求。
以登陆窗口为例，就可能有不同的需求，可能用户要求停用的账号能够登录系统（可能要求登录后不允许进行其他操作），也可能用户直接要求停用的用户账号不准登录系统。根据不同的业务需求，就有不同的业务流程。
这样这层的测试用例，我们就只要考虑业务需求，仍然以登录窗口为例，我们就只要考虑删除的用户能否登录？停用的用户能否登录？超级用户是如何登录的？普通用户是何种方式登录的？简单的说，这层的用例只描述业务流程，不关心具体这个业务是怎么实现的，执行这部分用例时，不要考虑哪个输入框控制了多少长度，能否输入空格等其他功能，因为这部分的测试需要基于上面两层的测试用例都已经测试通过了，所以在项目维护阶段或者说时间很紧迫的阶段，我们只需要执行这部分的用例，保证业务能够通畅的完成。其实个人觉得在执行这部分用例时，对包含了对基本功能的测试，一些明显的问题应该能被发现，虽然严格来说测试覆盖率很低，但是基本能达到要求。
这三层的组合起来才是一个完整的测试用例。这是我个人对测试用例设计的一个思路和方法。
真正设计这个测试用例的时候，可能会使用到黑盒测试用例的方法，例如等价类划分、边界值分析、错误猜测法（主要是个人经验）、正交分解等方法针对具体情况设计测试用例。分层测试用例的思路主要来自对自动测试实现的考虑。
因为我觉得，如果需要实现自动化测试就必须对测试用例进行细分，划分得越细就越有利于自动化的实现。以上三层的划分也并不是很全面，需要在实践中不断完善，例如可以增加对数据库的部分功能的数据校验的分析。
总之，测试用例写的细致、全面、步骤清晰，那么无论是用手工测试的方法还是用自动化测试的方法实现，只要能完整的跑完整个测试用例，就达到了测试的目标了。
*自动化测试中稳定的功能有哪些
这个问题我从昨天开始看了两三次，想写点什么但又不知道怎样写。
从我看来，你这个问题问得太泛了。
web自动化测试中稳定的功能有哪些？这个。我真不知道怎样回答。
web自动化测试有很多工具，使用的工具不一样，就有不一样的答案。
但我想你应该有个误区，我们不是根据web自动化测试稳定的功能来写测试用例的，应该根据项目的特点来写自动化测试。
如果你公司的项目的开发周期足够长，需求变动少，那你可以为这整一个项目写一份完整的测试用例和自动化测试脚本。
如果你公司的项目开发周期短，需求变动频繁，那你可以总结之前公司发开发的项目，总结出它们相对比较稳定的功能，为这些功能模块专门写一个测试用例和自动化测试脚本，这部分是可以重复使用，而且维护难度低。
转载请注明出处文秀网 » 自动化测试用例怎么写
