大家好今天来介绍自动化测试用例设计 的问题，以下是机器人网小编对此问题的归纳整理，来看看吧。
文章目录列表:
1.步骤和数据的分离：
好的测试用例，在执行的步骤(Step）的表达上应该是尽可能和数据相分离。举例来讲，有一个ATM机取款的功能，可能有以下几个场景：
1) 密码正确的登录
2) 密码错误的登录
3) 密码输入三次错误，卡被锁定
4) 取少于余额的款项
5) 尝试取大于余额的款项
6) 尝试取等于余额的款项（考虑手续费）
6) 取款额度大于当次的限制
7) 取款额度大于当天的限制
8) 取款次数大于限制次数
等等
不管你用什么用例设计的方法论来做指导，作为这个简单的例子，有经验的人都应该能看出，此处的很多步骤是可以重用的，总结下来如下（此处只列出了操作的步骤，略去了系统的交互中的反馈结果）：
1) 插入卡->A:输入密码->B:按“确定”键->重复A-B
2) 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、Function、测试类型、基本业务流、备选业务流的树状结构形式，分层次组织用例；使用用例管理工具。
Word格式的扁平组织结构，不利于管理和阅读。
用一个属性字段，建立用例和Spec等文档的某个章节间的映射。
无法和需求对应，以后难以计算 用例覆盖率，测试执行覆盖率。
每个Module、Function、特定业务的一组测试用例，之间做到独立、没有耦合。
用例之间有依赖，无法做到：挑选30%的用例做回归测试。
在时间和成本允许的情况下，尽量做到：用例粒度为“一种不同的操作，得到不同的结果，就单独写一个用例“。
在用例中的操作步骤中，甚至期待结果中，仍然存在条件分支。
对于复杂的业务操作过程，如”一次顺序的表单签核过程“和”一次完整的信贷手续“，单独增加一些贯穿整个业务流的大型测试用例。
对于一个长业务操作，只存在比较零散的细节用例。
将用例分优先等级，便于在回归测试时挑选核心业务或用户操作密集的用例。
用例 没有优先级和重要程度的定义。
如何设计一个完整的测试用例
软件测试的W模型，就要求测试与开发同步，在开发设计需求设计说明书的时候就开始测试流程，一般情况下，讨论需求设计的时候需要测试主管或者组员的参与，了解这个项目设计的总体情况
事实上，测试用例的编写一般是在需求设计说明书定下来之后才真正的开始的
因为测试用例的内容要以需求设计说明书为依据，设计说明书上没体现的功能，不需要在测试用例中体现
编写测试用例（这里指功能测试用例的编写），首先要做的就是设计测试用例的模板
每个公司都有适合自己公司用例编写的模板，各有各的特点
测试用例的格式包括，测试用例摘要、测试用例需求编号（一个需求设计说明书可以分好几个用例编写）、编写用例的日期、编写人员、编写日期、前置条件、准备数据等等
格式没有固定的要求，可以根据自己测试用例设计的思路，对测试用例的格铅扰誉式作相应的改变
下面以一个登陆窗口为例，说说我设计登陆界面的思路和方法
我把这个测试用例分为三层结构，表单测试、逻辑判断、业务流程
第一层，表单测试为最底层（最基础的）
这部分的测试用例是对登陆窗口这个界面的输入框、按钮功能、界面等最基本功能的测试
一般来说登陆用户名和登陆用户密码是输入框的形式体现，那么，我们需要的是针对这两个输入框进行功能的测试
这时，我们只要考虑这个输入框的功能，而不需要考虑业务方面的内容
这样，我们考虑就是这个输入框的长度限制是多少？能否输入特殊字符？能否输入全角字符？当然，登陆窗口还有其他按钮，例如登陆按钮、退出按钮、界面设计等，这一层的测试用例只对他们最简单的功能的测试
我觉得这一层的测试用例对新开发项目很重要，也必须执行，因为这些是最基本的功能保证，当项目进入维护阶段后，如果没有修改就不需要执行这部分的测试了或者说把这层的用例优先级置为最低，时间不充足的情况就不用去执行
第二层，逻辑判断层
根据需求的设计，各功能之间的简单逻辑联系
以登陆窗口为例，账号登录，账号和密码必须对应才能登录，否则登录失败
根据这一点，我们就可以从这个要求设计这一层测试用例
例如，账号和密码不一致时；账号为空时；密码为空时；账槐段号密码对应时等等情况
输入这些情况时，程序是作怎么样的逻辑控制的？控制是否正确？是否有相应的提示信息？我觉得，这一层的用例时最常规的一层，平时使用这个软件用经常碰到的一些情况，在常规测试或修改这部分的功能之后，这一部分的测试李神用例也必须执行
第三层，业务流程层
这部分不关心软件的本身的基本功能，而是关心这个软件的业务有没有实现，不同的需求就有不同的业务需求
以登陆窗口为例，就可能有不同的需求，可能用户要求停用的账号能够登录系统（可能要求登录后不允许进行其他操作），也可能用户直接要求停用的用户账号不准登录系统
根据不同的业务需求，就有不同的业务流程
这样这层的测试用例，我们就只要考虑业务需求，仍然以登录窗口为例，我们就只要考虑删除的用户能否登录？停用的用户能否登录？超级用户是如何登录的？普通用户是何种方式登录的？简单的说，这层的用例只描述业务流程，不关心具体这个业务是怎么实现的，执行这部分用例时，不要考虑哪个输入框控制了多少长度，能否输入空格等其他功能，因为这部分的测试需要基于上面两层的测试用例都已经测试通过了，所以在项目维护阶段或者说时间很紧迫的阶段，我们只需要执行这部分的用例，保证业务能够通畅的完成
其实个人觉得在执行这部分用例时，对包含了对基本功能的测试，一些明显的问题应该能被发现，虽然严格来说测试覆盖率很低，但是基本能达到要求
这三层的组合起来才是一个完整的测试用例
这是我个人对测试用例设计的一个思路和方法
真正设计这个测试用例的时候，可能会使用到黑盒测试用例的方法，例如等价类划分、边界值分析、错误猜测法（主要是个人经验）、正交分解等方法针对具体情况设计测试用例
分层测试用例的思路主要来自对自动测试实现的考虑
因为我觉得，如果需要实现自动化测试就必须对测试用例进行细分，划分得越细就越有利于自动化的实现
以上三层的划分也并不是很全面，需要在实践中不断完善，例如可以增加对数据库的部分功能的数据校验的分析
总之，测试用例写的细致、全面、步骤清晰，那么无论是用手工测试的方法还是用自动化测试的方法实现，只要能完整的跑完整个测试用例，就达到了测试的目标了
测试新人如何使用Python代码封装自动化测试的用例?
如何使用Python和Nose实现自动化测试？
本文我将详细介绍使用Appium下的Python编写的测试的例子代码对一个iOS的搜毕漏样例应用进行测试所涉及的各个步骤，而对Android应用进行测试所需的步骤与此非常类似。
然后按照安装指南，在你的机器上安装好Appium。
我还需要安装Appium的所有依赖并对样例apps进行编译。在Appium的工作目录下运行下列命令即可完成此任务：
$ ./reset.sh --ios
编译完成后，就可以运行下面的命令启动Appium了：
$ grunt appium
现在，Appium已经运行起来了，然后就切换当前目录到sample-code/examples/python。接着使用pip命令安装所有依赖库(如果不是在虚拟环境virtualenv之下，你就需要使用sudo命令)：
$ pip install -r requirements.txt
接下来运行样例测试：
$ nosetests simple.py
既然安装完所需软件并运行了测试代码，大致了解了Appium的工作过程，现在让我们进一步详细看看刚才运行的样例测试代码。该测试先是启动了样例应用，然后在几个输入框中填写了一些内容，最后对运行结果和所期望的结果进行了比对。首先，我们创建了测试类及其setUp方法：
classTestSequenceFunctions(unittest.TestCase):
defsetUp(self):
app=os.path.join(os.path.dirname(__file__),
'../../apps/TestApp/build/Release-iphonesimulator',
'TestApp.app')
app=os.path.abspath(app)
self.driver=webdriver.Remote(
command_executor='127.0.0.1:4723/wd/hub',
desired_capabilities={
'browserName':'iOS',
'platform':'Mac',
'version':'6.0',
'app': app
})
self._values=[]
“desired_capabilities”参数用来指定运行平台(iOS 6.0)以及我们想测试的应用。接下来我们还添加了一个tearDown方法，在每个测试数备完成后发送了退出命令：
deftearDown(self):
self.driver.quit()
最世烂后，我们定义了用于填写form的辅助方法和主测试方法：
def_populate(self):
# populate text fields with two random number
elems=self.driver.find_elements_by_tag_name('textField')
foreleminelems:
rndNum=randint(0,10)
elem.send_keys(rndNum)
self._values.append(rndNum)
deftest_ui_computation(self):
# populate text fields with values
self._populate()
# trigger computation by using the button
buttons=self.driver.find_elements_by_tag_name("button")
buttons[0].click()
# is sum equal ?
texts=self.driver.find_elements_by_tag_name("staticText")
self.assertEqual(int(texts[0].text),self._values[0]+self._values[1])
本文介绍到此，相信很多朋友都已经明白了。但是如果你对Nose和Python来运行Appium测试有任何问题或看法，可以给我留言，我们可以继续交流。
怎么软件测试啊？
软件测试属于IT行业中容易入门的岗位，代码量较少。0基础进入IT行业，完全是ok的，IT行业分好几种有开发，测试，UI，自动化，测开，运维等这些岗位。在这些岗位里面测试相对来说还是比较容易上手学会的。因为开发、运维、自动化这些都对代码的要求挺高，0基础的话对代码认识不是一、两天就可以学好的。
课程内容主要庆桥模有：
搭建Windows测试环境，JAVA编程，软件测试基础，数据库技术，用户界面技术，高效设计测试用例，阶段项目实训，搭建 Linux 测试环境，白盒测试，WEB技术，高效使用自动测试工具，软件质量保证，流行测试基础，企业级项目实训用例等！
学完可以从事：
功能测试工程师，消察性能测试工程师，安全测试工程师，白盒测试工程师，自动化测试工程师，接口测试工程师，测试开发工程师等。
互联网行业目前还是最热门的行业之一，学习IT技能之后足够优秀是有机会进入腾讯、阿里、网易等誉缓互联网大厂高薪就业的，发展前景非常好，普通人也可以学习。
想要系统学习，你可以考察对比一下开设有相关专业的热门学校，好的学校拥有根据当下企业需求自主研发课程的能力，能够在校期间取得大专或本科学历，中博软件学院、南京课工场、南京北大青鸟等开设相关专业的学校都是不错的，建议实地考察对比一下。
祝你学有所成，望采纳。
以上就是小编对于自动化测试用例设计 问题和相关问题的解答了，希望对你有用
