测试用例

if __name__ =="__main__":　　#运行标记为markA的用例，并生成测试报告　　pytest.main(["-m=markA","--html=report.html"]) 大部分资料中都说要在terminal终端运行，所以个人习惯直接写在os.system()里，相对上面的写法，下面这种就是终端怎么写这里怎么写就可以了。 if __name__ =="__main__": 　　#运行标记为markA的用例，并生成测试报告 　 os.system('pytest -m "markA" --html=report.html --self-contained-html') 来源： https://www.cnblogs.com/nicole-zhang/p/11387316.html

1.什么是接口测试 接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。 2.为什么做接口测试 首先，节省测试成本，数据模型推算，底层的一个bug能够引发上层的8个左右bug，而且底层的bug很容易引起全网的宕机。相反接口测试能够提供系统复杂度上升情况下的低成本高效率的解决方案。 其次接口测试不同于传统开发的单元测试，接口测试是站在用户的角度对系统接口进行全面高效持续的检测。 最后接口测试是自动化并且持续集成的，这也是为什么接口测试能够低成本高收益的根源。 总之接口测试是保证高复杂性系统质量的内在要求和低成本的经济利益的驱动作用下的最佳解决方案，接口测试是一个完整的体系，也包括功能测试、性能测试。 3.接口测试的适用范围 接口测试一般应用于多系统间交互开发，或者拥有多个子系统的应用系统开发的测试。接口测试适用于为其他系统提供服务的底层框架系统和中心服务系统，主要测试这些系统对外部提供的接口，验证其正确性和稳定性。接口测试同样适用于一个上层系统中的服务层接口，越往上层，其测试的难度越大。接口测试在淘宝的应用是一个自下而上的发展过程。 接口测试实施在多系统多平台的构架下，有着极为高效的成本收益比

#coding=utf-8 from __future__ import print_function #开始执行该文件时，该函数执行 def setup_module(module): print('\nsetup_module()') #结束执行该文件时，该函数执行 def teardown_module(module): print('teardown_module()') #单元测试函数执行之前该函数执行 def setup_function(function): print('\nsetup_function()') #单元测试函数执行之后该函数执行 def teardown_function(function): print('\nteardown_function()') #case1 def test_1(): print('- test_1()') #case2 def test_2(): print('- test_2()') 输出 bogon:test macname$ pytest test.py -s ============================= test session starts ============================== platform darwin -- Python 3.6.3, pytest-5.1.0,

移动互联网时代，越来越多的互联网企业不断地追求一个“快”字，但是在众多企业在软件测试过程中都普遍存在不断缩短的迭代周期与落后的测试流程之间的矛盾，而RPA的出现就能很好的解决这一矛盾。 机器人流程自动化 （RPA）可以大幅地削减测试成本，并且提高测试的准确率和测试速度，缩短测试周期，并且RPA的部署简单，投入较少，帮助企业抢先一步抢占用户，占领市场。 当前，市场上众多的自动化测试工具都普遍存在一下问题： 1、操作复杂 市面上大部分的自动化测试工具，都是将自动化脚本以代码的形式展现给编写人员，这就要求测试人员需要具备一定的阅读和编写代码的能力，但是，绝大部分的测试人员是不具备这项能力的。这就造成了自动化测试工具和软件测试人员间的一个不可调和的矛盾，同时也提高了工具的使用门槛。 2、业务流程不清晰 上面提到了，由于脚本以代码形式展现在测试人员面前，因此很难清晰地展现该用例所涉及的业务流程，不熟悉该用例的测试人员，可能需要反复阅读代码，才能了解该用例所涉及的业务流，这样也就加大了测试遗漏的风险。 3、测试用例编写成本高 单条测试用例，从脚本录制，到代码编写，可能花费数小时的时间，费时费力。这便无形中增加了测试的成本，同时也造成了大部分的测试人员不愿意使用自动化工具。 RPA软件对于软件自动化测试是颠覆性的，RPA在软件自动化测试中的优势： 图形化流程展示 测试用例（业务流程

一般几轮系统测试完后，会进行验收或用户测试，因为是自家产品，我这里就简称内测活动，主要对象是公司内部人员，大家可以借鉴讨论。 内测活动的由来 产品后端之前是PHP做的，由于发展后端需要换成Java，替换原有功能的同时，新增了很多功能，基本前后端重做，确认产品上线日期后，各方时间都很紧，按照最初的设计排期，测试组会有两周的时间进行测试（第一周完成一轮系统测试，第二周就进行回归，并会更早的介入测试），中途由于某些原因，提测时间后延了一周，加上产品上线时间不能改变，于是测试时间缩短一半（压力很大，也许这是测试的硬伤吧），事已至此，只有改变测试策略，一周的时间内让产品的质量基本能达到上线标准。 内测活动策略设计 目前产品前端包括安卓、IOS、微信小程序、WEB端。后台有两个，包括总后台和子系统后台。 ● 测试范围：这次的内测范围是安卓和IOS端的全部功能，其他端已经进行过测试。产品主要包括A，B，C，D大功能模块，E通用功能模块，如登录注册，分享等。 ● 测试资源：测试组，产品组，运营组，设计组，其他（开发、领导等）。 ● 测试环境：主要体现在测试机型上面，包括安卓和IOS（测试机不够就用自己的手机，部分还使用了模拟器)。 ● 测试目标：执行完成所有模块的测试用例。 ● 其他：测试用例已经完成，并通过组内评审，其中A模块（439条），B模块（372条），C模块（92条），D模块（146条）

pytest 参数 1.参数：-s 运行过程中执行print打印函数：pytest -s，以下两个输出 上边带参数，下边不带 2.参数： --collect-only 收集将要执行的用例，但不会执行用例：pytest --collcet-onty 3.参数：-k args（关键字args：可以是py文件名，也可以是函数名，若py文件名和函数均包含 则需要严格指定 xx.py 以运行py文件） 运行包含关键词的用例：pytest -k "install"，如下图： 4.参数：-x 用例运行失败则立即停止执行 5.参数：--maxfail=num 用例运行时 允许的最大失败次数，超过则立即停止，pytest --maxfail=3 6.参数：--tb=选项（选项：'auto', 'long', 'short', 'no', 'line', 'native'） 用例运行失败时，展示错误的详细程度 7.参数：-l 或--showlocals 用例运行失败时，打印相关的局部变量，pytest -l 8.参数：-v 或 -q 打印用例执行的详细/简略过程，pytest -v ，pytest -q 9.参数：--lf / --last-failed 只执行上次执行失败的测试 10.参数：--ff / --failed-first 先执行完上次失败的测试后，再执行上次正常的测试 11.参数：-

软件的生命周期（prdctrm） 计划阶段（planning）-〉需求分析（requirement）-〉设计阶段（design）-〉编码（coding）->测试（testing）->运行与维护（running maintrnacne） 1 ，问：你在测试中发现了一个 bug ，但是开发经理认为这不是一个 bug ，你应该怎样解决。 答： 首先，将问题提交到缺陷管理库里面进行备案。 然后，要获取判断的依据和标准： 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据； 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷； 根据用户的一般使用习惯，来确认是否是缺陷； 与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷； 合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。 等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。 2 ，问：给你一个网站，你如何测试？ 答： 首先，查找需求说明、网站设计 m 等相关文档，分析测试需求，制定测试计划，确定测试范围和测试策略，一般包括以下几个部分： 功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试 设计测试用例： 功能性测试可以包括，但不限于以下几个方面：

显式功能性需求(Functional requirement)的含义从字面上就可以很好地理解，指的是软件本身需要实现的具体功能， 比如“正常用户使用正确的用户名和密码可以成功登录”、“非注册用户无法登录”等，这都是属于典型的显式功能性需求描述。 非功能性需求主要涉及安全性、性能以及兼 容性三大方面。 在上面所有的测试用例设计中，我们完全没有考虑对非功能性需求的测试，但这些往往是决定软件质量的关键因 素。 　 安全测试 用例： 　 　 　 性能测试 用例： 　 　　 兼容性测试用例： 　　 来源： https://www.cnblogs.com/huxiaoxi/p/11357619.html

手工测试用例 PK 自动化测试用例 首先，需要区分手工测试和自动化测试用例的不同。 1.手工测试用例： 关注某个功能点 可考虑多种异常情况并做出相应的处理，通过人为的逻辑判断当前步骤的功能实现正确与否 人工执行具有一定的步骤跳跃性 人工测试步步跟踪，能够细致的定位问题 主要用来发现功能缺陷，适用于测试阶段 2.自动化测试用例： 关注的是流程，多个功能点 用例步骤关联性强 保证产品主题功能能正确完成和让测试人员从繁琐重复的工作中解脱出来 自动化测试的每个用例的起始页面和退出页面一般是同一个页面，从哪里开始，到哪里结束（为了保证每次测试的初试环境是一样的） 目前自动化测试主要用于冒烟测试和回归测试（冒烟测试执行的是主体功能点的用例。回归测试执行全部或部分的测试用例） 自动化测试用例设计原则： 不需要将所有的手工测试用例转化为自动化测试用例 选择功能较为稳定的功能模块进行测试。当功能变动大时，脚本的维护需要花费更多的精力 选择的用例如为主体流程，可用于冒烟测试 自动化测试也可以用来做配置检查，数据库检查等。也算用例拓展的一部分。 如果平时在手工测试时，需要构造一些复杂数据，或重复一些简单机械式动作，就可以使用自动化脚本创造 准备复杂的测试数据。对于大的应用系统，数据之间的关系和准备过程都会很复杂，甚至有其他外部系统导入、传输或计算出来的数据

1、常见的 测试 用例设计 方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计 工作 中的应用。 　　1）等价类划分 　　常见的 软件测试 面试 题划分等价类: 等价类是指某个输入域的子集合.在该子集合中，各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类 其它 值的测试.因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 　　2）边界值分析法 　　边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例，可以查出更多的错误. 　　使用边界值分析方法设计测试用例，首先应确定边界情况.通常输入和输出等价类的边界，就是应着重测试的边界情况.应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据. 　　3）错误推测法 　　基于经验和直觉推测程序中所有可能存在的各种错误， 从而有针对性的设计测试用例的方法. 　　错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例. 例如， 在 单元测试