测试用例设计

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

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工具的功能实现

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

Web项目测试流程大致包含的几个阶段：立项、需求评审、用例评审、测试执行、测试报告文档 立项后测试需要拿到的文档 1.需求说明书 2.原型图（及UI图） 3.接口文档 4.数据库字典（表的数量、缓存机制） 需求评审 参加人员：开发、测试及需求人员，由需求人员主持讲解 为了会议的有效举行，测试及开发人员需要在会议开始之前熟悉需求文档及原型，将有疑问的点标注出来再会议中一一确认，对不明确的点要督促开发及需求一并关注，对不能立马得到肯定回复的点记录在一起，会议结束后，邮件整理好发出给各位参与人员。 在项目可控的进度中，需求评审是必要的环节。当然，有些比较小的项目会忽略此阶段，个人认为这是非常有必要的环节，这不但减少了后期开发、测试、需求人员的意见分歧，还保证了项目的进度。 用例编写（同时根据开发计划编写测试计划） 用例功能类型 大致分为7类： 1.主流程：该模块实现的主要功能流程 2.备选流：不一定完成执行一个功能，而是终止了流程 3.异常流：由于某些异常原因，使流程的功能无法实现 4.业务规则：必填项，强制的要求 5.正常类：返回功能、必填项输入范围、页面按钮的切换等 6.异常类：网络异常、返回异常等 7.界面检查：针对每个页面的样式及内容检查 注：几个大类中主流程、正常类、异常类和界面检查四个大类使用的比较多，一个项目不需要涵盖所有的用例类别

本文属于转载文章，仅供参考，原文链接： https://www.cnblogs.com/tynam/p/9078274.html 一、测试的流程 　　测试贯彻在产品生命周期中的每一个环节，从需求提出开始到测试计划、测试设计以及测试用例设计与评审及执行，最后进行回归测试。产品发布上线后跟踪用户使用的反馈，周而循环直到产品不在维护。 　　1、参与需求的评审 　　　　评审内容主要分为功能性、准确性、完整性、可测性、优先级和约束性。当然还有其他的性能要求、安全、可补充性、易用性等 　　　　功能性指描述功能的规格说明、状态变化、界面格式的定义等表述合理；准确性指需求清晰完整，无歧义；完整性指需求可以满足用户的使用；可测性指需求是否可以被测试用例覆盖到；优先级指优先完成那部分；约束性指某些事件是否需要一定的前提条件。 　　2、测试计划 　　　　测试计划应该以文档的形式输出，主要包含的几个点为测试对象（根据需求分析测试对象的应测特性和不测特性，不测说明原因）、测试通过或失败的标准（主要为测试用例的覆盖率和问题的修复率）、测试任务安排（谁负责什么模块）以及工作量的估算。还有其他的一些资源统计、项目简介等。 　　3、测试设计 　　　　测试设计是对测试计划的细化。也是以文档的形式输出。主要内容有测试环境的描述、用例执行的顺序（一般都是功能性用例到易用性、兼容性再到安全性、异常行为等）、用例的设计规定