测试用例

问：你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎样解决。 首先，将问题提交到缺陷管理库里面进行备案。 然后，要获取判断的依据和标准： 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据； 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；根据用户的一般使用习惯，来确认是否是缺陷；与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。 等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。 问：给你一个网站，你如何测试？首先，查找需求说明、网站设计m等相关文档，分析测试需求。 制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试设计测试用例：功能性测试可以包括，但不限于以下几个方面： 链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回等。 提交功能的测试。 多媒体元素是否可以正确加载和显示。 多语言支持是否能够正确显示选择的语言等。 界面测试可以包括但不限于一下几个方面：页面是否风格统一，美观页面布局是否合理

在PAT的OJ系统上用Java解题时，需注意下面这些地方，否则都不知道错在哪里（第一次入坑好久没出来） 不要输入package名字 自己在本地调试的时候，可以在中间用System.out.print等输出语句调试，但是在PAT的OJ系统上，只有输出最终结果的时候，才可使用System.out.print等输出语句 类名必须为Main.否则出现编译错误，“class xxx.java is public,should be declared in a file named xxxx” 牛客网 PAT历年真题及模拟题在线编程练习 的 OJ会公开一些测试用例，方便排除bug，而PAT本身是没有公开测试用例的，有时侯根本不知道哪里错了 来源： CSDN 作者： 开发维护 链接： https://blog.csdn.net/zhouhuakang/article/details/49924483

Web测试中，各类web控件测试点总结 一 、界面检查 　　进入一个页面测试，首先是检查title，页面排版，字段等，而不是马上进入文本框校验 　　1、页面名称title是否正确 　　2、当前位置是否可见 您的位置：xxx>xxxx 　　3、文字格式统一性 　　4、排版是否整齐 　　5、列表项显示字段是否齐全,列表项字段名称是否跟表单统一 　　6、同一页面，是否出现 字段名称相同、值取不同的问题。 　　7、数据加载情况：除了文本框的值，还要注意： 　　复选框，是否保存打√，或者保存不打√ 　　下拉框，是否保存选择的值 　　多文本框，值是否都被保存，空格，换行是否保存 二、单文本框（type=text） 　　边界：字段长度 　　判空：是否可以为空 　　唯一性：是否唯一 (小归结：边界、判空、唯一性、特殊字符、正确性) 　　考虑语言，操作环境 　　特殊符号测试输入： 　　' or 1<>'1　　　' or '1'='1　　' or '1'<>'2　　"|?>< 　　where a='xxx'　　　下划线是否允许　　输入全部空格 输入 单引号 　　><script>alert(“123”);</script>> 　　特殊字段输入限定： 　　框内容是否合法（tel，ip，url，email）序号等，直接限制输入数字，其他过滤掉 　　输入金额文本框，整数首位为0，过滤掉，小数点后面

背景 最近在弄 appium，然后顺便发现了 Selenium 框架和这本书，恰好这本书也介绍了一些软件测试&自动化测试的理论知识，遂拿过来学习学习。所以本文几乎没有实践内容，大多都是概念和工具的 mark，后续若有实践，我会来补充的。 一、软件测试 分类 1、根据项目流程阶段划分 需求分析 设计 编码 单元测试 集成测试 系统测试 验收测试 2、白盒测试、黑盒测试、灰盒测试 白盒测试的意义：有时候输出是正确的，但内部其实已经错误了，这种情况非常多。 灰盒测试的意义：如果每次都通过白盒测试来操作，效率会很低，黑盒又太过笼统，因此折中的灰盒测试比较适合。 3、功能测试与性能测试 功能测试 主要检査实际功能是否符合用户的需求。 功能测试又可以细分为很多种：逻辑功能測试、界面测试、易用性测试、安装测试、兼容性测试等。 性能测试 主要有 时间性能 和 空间性能 两种。 时间性能：主要是指软件的一个具体的响应时间。 空间性能：主要指软件运行时所消耗的系统资源。 4、手工测试与自动化测试 自动化测试不能完全地替代手工测试 ，自动化测试的目的仅仅在于让测试人员从烦琐重复的测试过程中解脱出来，把更多的时间和精力放到更有价值的测试中， 例如探索性测试。而自动化测试更多的是用来进行冒烟测试和回归测试。 自动化测试是本文要探讨的重点。 5、冒烟测试、回归测试、随机测试、探索性测试和安全测试 冒烟测试

1、selenium中如何判断元素是否存在？ - isElementPresent 2、selenium中hidden或者是display ＝ none的元素是否可以定位到？ - 不能 3、selenium中如何保证操作元素的成功率？也就是说如何保证我点击的元素一定是可以点击的？ - 添加元素智能等待时间 driver.implicitly_wait(30) - try 方式进行 id,name,clas,x path, css selector 不同方式进行定位，如果第一种失败可以自动尝试第二种 -Selenium保证元素成功率是通过元素的定位，当然它的定位方法很多，一定能有合适的。但是在自动化工程的实施过程中，高质量的自动化测试不是只有测试人员保证的。需要开发人员规范开发习惯，如给页面元素加上唯一的name,id等，这样就能大大地提高元素定位的准确性。当然如果开发人员开发不规范，我们在定位元素的时候尽量使用相对地址定位，这样能减少元素定位受页面变化的影响。只要我们元素定位准确，就能保证我的每一个操作符合我的预期 4、如何提高selenium脚本的执行速度？ - Selenium脚本的执行速度受多方面因素的影响，如网速，操作步骤的繁琐程度，页面加载的速度，以及我们在脚本中设置的等待时间，运行脚本的线程数等。所以不能单方面追求运行速度的，要确保稳定性，能稳定地实现回归测试才是关键。

文章目录 一个测试活动完整的过程 测试计划工作的目的、测试计划文档的内容包括什么？ 测试用例通常包括那些内容？ 测试人员在软件开发过程中的任务是什么？ 软件测试分为几个阶段，各阶段的测试策略和要求是什么？ 单元测试 请回答集成测试和系统测试的区别，以及它们的应用场景主要是什么？ 你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎么解决？ 请问你觉得测试项目具体工作是什么？ 软件测试方法 黑盒测试 边界值分析法 因果图法 判定表法 白盒测试 语句覆盖 判定覆盖 条件覆盖 判定/条件覆盖 条件组合覆盖 性能测试 性能测试类型 负载测试：是指对系统不断地增加压力或增加一定压力下的持续时间，知道系统的某项或多项性能指标达到安全临界值，例如某种资源已经达到饱和状态等 压力测试:压力测试是评估系统处于或超过预期负载时系统的运行情况，关注点在于系统在峰值负载或超出最大载荷情况下的处理能力。 恢复测试 强度测试 疲劳强度测试 每一阶段测试基于的文档 一个测试活动完整的过程 项目立项前测试人员不需要提供任何工件 项目经理 通过和客户交流，完成 需求文档 ，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。 项目经理通过综合开发人员、测试人员以及客户的意见，完成 项目计划 。然后SQA进入项目

文章目录 游戏测试的主要内容 游戏测试基本流程 游戏测试用例 游戏bug 游戏弱网测试 游戏功能性测试 游戏接口测试 游戏测试的主要内容 功能测试 主要验证功能是否符合需求设计 主要考虑功能正确性，不考虑游戏底层结构及代码错误 通常从界面着手测试，尽量模拟用户可能出现的操作 性能测试 测试点 客户端CPU使用率 客户端内存占用率 客户端网络流量使用情况 客户端耗电量 客户端帧率（FPS） 测试方法 分析代码 工具监测 iOS：xcode自带的instrument 安卓：emmage和GT（需要root权限） 压力测试 服务器CPU使用率 服务器内存占用率 系统吞吐量（TPS） 事务响应时间 事务成功率 兼容测试 机型适配测试 操作系统兼容测试 屏幕分辨率兼容测试 游戏版本兼容测试 安全测试 内存修改测试 客户端加密测试 客户端反编译测试 网络安全测试（用抓包工具测试 避免重复抓包） 接口测试 服务器各个接口数据测试，主要用工具来实现 接口安全测试，重复发送请求，查看接口处理情况 日志测试 客服端日志 服务端日志 弱网测试 测试点 不同网络情况下游戏的运行情况 不同丢包率情况下游戏的运行情况 通过工具设置网络代理来实现 常用的工具 win:fiddle、mac:network link conditioner gm工具测试（运营、客服人员使用） 测试gm工具的功能实现

Pytest fixtures：清晰 模块化 易扩展 2.0/2.3/2.4版本新函数 text fixtures的目的是为测试的重复执行提供一个可靠的固定基线。 pytest fixture比经典的xUnit setUp/tearDown方法有着显着的改进： fixtures具有明确的名称,在测试用例/类/模块或整个项目中通过声明使用的fixtures名称来使用。 fixtures以模块化方式实现,因为每个fixture名称都会触发调用fixture函数,该fixture函数本身可以使用其它的fixtures。 从简单的单元测试到复杂的函数测试,fixtures的管理允许根据配置和组件选项对fixtures和测试用例进行参数化,或者在测试用例/类/模块或整个测试会话范围内重复使用该fixture。 此外,pytest继续支持经典的xUnit风格的setup方法。 你可以根据需要混合使用两种样式,逐步从经典样式移动到新样式。 你也可以从现有的unittest.TestCase样式或基于nose的项目开始。 Fixtures作为函数参数使用 测试用例可以通过在其参数中使用fixtures名称来接收fixture对象。 每个fixture参数名称所对应的函数,可以通过使用 @pytest.fixture 注册成为一个fixture函数,来为测试用例提供一个fixture对象。

总结： 1，做自动化测试遇到的最大困难 2，总共写过多少个自动化测试用例 3，自动化测试的优缺点 4，在使用Selenium中遇到的最大的问题？如何解决？ 5，有无发现selenium的BUG 6，与人工测试相比，Selenium测试的产出，相对的优势？ 7，项目中的测试覆盖率指什么？有总结测试覆盖率报告吗？自动化测试用例的最高覆盖率多少 8，自动化测试中遇到用例fail掉怎么排查故障？ 9，page object模式中，如何实现页面的跳转？ 10，你觉得自动化测试最大的缺陷是什么？ 11，你们公司的自动化投入产出比怎样？效益怎样？ 12，什么样的项目比较适合做自动化测试？什么样的不适合？ 来源： https://www.cnblogs.com/gaogo/p/11443054.html

转自 http://hi.baidu.com/%D2%D7%B1%D8%BA%C6/blog/item/f016729f4fbeaebbc9eaf4df.html 语句覆盖是指选择足够的测试用例，使得运行这些测试用例时，被测程序的每一个语句至少执行一次，其覆盖标准无法发现判定中逻辑运算的错误；判定覆盖是指选择足够的测试用例，使得运行这些测试用例时，每个判定的所有可能结果至少出现一次，但若程序中的判定是有几个条件联合构成时，它未必能发现每个条件的错误； 条件覆盖是指选择足够的测试用例，使得运行这些测试用例时，判定中每个条件的所有可能结果至少出现一次，但未必能覆盖全部分支；判定/条件覆盖是使判定中每个条件的所有可能结果至少出现一次，并且每个判定本身的所有可能结果也至少出现一次；条件组合覆盖是使每个判定中条件结果的所有可能组合至少出现一次，因此判定本身的所有可能解说也至少出现一次，同时也是每个条件的所有可能结果至少出现一次；路径覆盖是每条可能执行到的路径至少执行一次；其中语句覆盖是一种最弱的覆盖，判定覆盖和条件覆盖比语句覆盖强，满足判定/条件覆盖标准的测试用例一定也满足判定覆盖、条件覆盖和语句覆盖，条件组合覆盖是除路径覆盖外最强的，路径覆盖也是一种比较强的覆盖，但未必考虑判定条件结果的组合，并不能代替条件覆盖和条件组合覆盖。 举个例子吧 if A and B then Action1