测试用例

测试用例的编写需要按照一定的思路进行，而不是想到哪写到哪，一般测试机制成熟的公司都会有公司自己自定义的测试用例模板，以及一整套的测试流程关注点，当然我们自己在测试生涯中也应当积累一套自己的测试框架，所有功能性的测试都可以依据框架的思路来进行，达到事半功倍的效果。 功能测试框架可以包括：界面友好性测试、功能测试、链接测试、容错测试、稳定性测试、常规性能测试、配置测试、算法测试等等。 1.1.1 界面友好性测试 1. 风格、样式、颜色是否协调 2. 界面布局是否整齐、协调（保证全部显示出来的，尽量不要使用滚动条 3. 界面操作、标题描述是否恰当（描述有歧义、注意是否有错别字） 4. 操作是否符合人们的常规习惯（有没有把相似的功能的控件放在一起，方便操作） 5. 提示界面是否符合规范（不应该显示英文的cancel、ok，应该显示中文的确定等） 6. 界面中各个控件是否对齐 7. 日期控件是否可编辑 8. 日期控件的长度是否合理，以修改时可以把时间全部显示出来为准 9. 查询结果列表列宽是否合理、标签描述是否合理 10. 查询结果列表太宽没有横向滚动提示 11. 对于信息比较长的文本，文本框有没有提供自动竖直滚动条 12. 数据录入控件是否方便 13. 有没有支持Tab键，键的顺序要有条理，不乱跳 14. 有没有提供相关的热键 15. 控件的提示语描述是否正确 16. 模块调用是否统一

对于一个 测试 人员来说测试用例的设计编写是一项必须掌握的能力。但有效的设计和熟练的编写却是一个十分复杂的技术，它需要你对整个软件不管从业务还是从功能上都有一个明晰的把握。 一、问题： 许多测试类书籍中都有大幅的篇章介绍用例的设计方法，如等价类划分，边界值，错误推断，因果图等。但 实际应用 中这些理论却不能给我们很明确的行为指导，尤其是业务复杂，关联模块紧密，输入标准和输出结果间路径众多时，完全的遵循这些方法只能让我们在心理上得到一种满足，而无法有效的提高测试效率。有时我们只有依靠以前项目的用例编写经验（或习惯），希望能在这一个项目中更加规范，但多数情况下我们规范的只是“书写的规范”，在用例设计上以前存在的问题现在依旧。 当好不容易用例基本完成，我们却发现面对随之而来的众多地区特性和新增需求，测试用例突然处于一种十分尴尬的境地： 从此几乎很少被执行 已经与程序的实现发生了冲突（界面变动，功能变动） 执行用例发现的bug很少 根本没有时间为新的功能需求增补用例 有时间补充，但用例结构越来越乱， 特性的用例与通性用例之间联系不明确（以新增需求为主线列出所有涉及到的更改，但特性与通行之间的数据或业务联系在用例中逐渐淡化） 知道怎样执行这个用例，但它要说明什么呢？（多数用例给我们的 感觉 是只见树木，不见森林，只对某一功能，无法串起） 通过上面的一系列问题可以看到

1、 软件测试阶段有哪些任务 ①、制定测试大纲（测试计划） ②、制作测试数据（测试方案） ③、单元测试（程序测试，一般由开发人员进行） ④、功能测试 ⑤、性能测试 ⑥、集成测试（子系统测试） ⑦、系统测试 ⑧、验收测试 ⑨、测试报告及向下阶段提交系统运行、维护用户手册 2 、 自动化测试 概念：为了提高工作效率，节省人力和成本，把人为驱动的测试转化为机器执行 3、自动化测试的过程 需求分析 测试计划 框架搭建（附带工具选择） 测试用例设计（编写测试用例或开发测试脚本，并文档化） 测试——调试测试（针对自动化测试脚本） 评估（评估测试结果并改进测试过程） 4、 自动化测试技术 录制/回放（依赖工具） 脚本技术 数据驱动（data driven)的自动化测试 关键字驱动（keyword driven）的自动化测试 业务驱动 5、自动化测试方案选择需要考虑的方面 ①、项目的影响（能否帮助项目进度、覆盖率、风险） ②、复杂度（是否容易实现，包括数据和其他环境等） ③、时间（实现自动化需要多少时间） ④、早期需求和代码的稳定性（需求或代码能否证明是在范围内变化的） ⑤、维护工作量（代码能否能长期保持相对稳定） ⑥、覆盖率（自动化测试能否覆盖程序的关键特性和功能） ⑦、资源（是否拥有足够的人力、硬件和数据资源来运行自动化测试） ⑧、执行（负责执行的人员是否有足够的技能和时间去运行） ⑨

语句覆盖是指选择足够的测试用例，使得运行这些测试用例时，被测程序的每一个语句至少执行一次，其覆盖标准无法发现判定中逻辑运算的错误； 判定覆盖是指选择足够的测试用例，使得运行这些测试用例时，每个判定的所有可能结果至少出现一次，但若程序中的判定是有几个条件联合构成时，它未必能发现每个条件的错误； 条件覆盖是指选择足够的测试用例，使得运行这些测试用例时，判定中每个条件的所有可能结果至少出现一次，但未必能覆盖全部分支； 判定/条件覆盖是使判定中每个条件的所有可能结果至少出现一次，并且每个判定本身的所有可能结果也至少出现一次； 条件组合覆盖是使每个判定中条件结果的所有可能组合至少出现一次，因此判定本身的所有可能解说也至少出现一次，同时也是每个条件的所有可能结果至少出现一次； 路径覆盖是每条可能执行到的路径至少执行一次； 其中语句覆盖是一种最弱的覆盖，判定覆盖和条件覆盖比语句覆盖强， 满足判定/条件覆盖标准的测试用例一定也满足判定覆盖、条件覆盖和语句覆盖， 条件组合覆盖是除路径覆盖外最强的， 路径覆盖也是一种比较强的覆盖，但未必考虑判定条件结果的组合，并不能代替条件覆盖和条件组合覆盖。 https://www.cnblogs.com/jerry19880126/articles/2623433.html 来源： https://www.cnblogs.com/rnanprince/p

接口测试 [腾讯 TMQ] 接口测试用例设计 腾讯移动品质中心 · 2018年01月17日 · 最后由 于静 回复于 20 天前 · 21794 次阅读 本帖已被设为精华帖！ 目录 作者：刘燕 团队：腾讯移动品质中心（TMQ） 导语 随着测试分析和分层测试的深化，“接口测试”出现在我们视野的频次越来越高。那么接口测的用例设计常用哪些方法呢？本文将详细描述。 1 接口测试 1.1 接口测试 接口：主要是子模块或者子系统间交互并相互作用的部分。 这里说的接口是广义的，客户端与后台服务间的协议；插件间通信的接口；模块间的接口；再小到一个类提供的方法；都可以理解为接口。 接口测试：是指针对模块或系统间接口进行的测试。 1.2 接口测试发现的典型问题 接口测试经常遇到的bug和问题，如下： （1）传入参数处理不当，导致程序crash； （2）类型溢出，导致数据读出和写入不一致； （3）因对象权限未进行校验，可以访问其他用户敏感信息； （4）状态处理不当，导致逻辑出现错乱； （5）逻辑校验不完善，可利用漏洞获取非正当利益等。 2 接口测试用例设计 上图为一个典型的接口。一个接口通常是有输入输出的，输入就是我们常见的入参，输出有时有，有时没有。调用相关接口，接口会执行相关处理逻辑。 接口测试的用例设计，主要从输入和接口处理两方面考虑： 1）针对输入，可按照参数类型进行设计； 2）针对接口处理

前言： 怎么设计自动化测试用例？是不是所有的手动用例都适合转成自动化测试用例？ 设计自动化测试用例需考虑的方面： 1、并不是所有的手工用例都要转为自动化测试用例。 考虑到脚本开发的成本，不要选择流程太复杂的用例。如果有必要，可以考虑把流程拆分成多个用例来实现脚本。 2、选择的用例最好可以构建成场景。 例如，一个功能模块，分多个用例，多个用例使用同一个场景。 3、选择的用例可以带有目的性。 例如，这部分是用例做冒烟测试，那部分用例是做回归测试等，当然，会存在重叠的关系。如果当前用例不能满足需求，那么唯有修改用例来适应脚本和需求。 选取的用例可以是主体流程，这部分适用于冒烟测试。 4、选取的用例可以是你认为是重复执行，很烦琐的部分。 例如，字段验证、提示信息验证这类，这部分适用于回归测试。 5、自动化测试也可以用来做配置检查、数据库检查。这些可能超越了手工用例，但也算用例拓展的一部分，项目负责人可以有选择地增加。 6、平时在手工测试时，如果需要构造一些复杂的数据或重复一些简单的机械式动作，则告诉自动化脚本，让它来帮你，或许你的效率会因此而得到提高。 在编写自动化测试用例过程中应该遵守以下几点原则： 1、一个用例为一个完整的场景，从用户登录系统到最终退出并关闭浏览器。 2、一个用例只验证一个功能点，不要试图在用户登录系统后把所有的功能都验证一遍。 3、尽量少的编写逆向逻辑用例

工作两年了，我一直希望让自己每年对测试的理解更深入一层。工作一年的时候我写了《 谈软件测试 --- 一年工作总结 》 ，谈轮了自己对各种测试的理解，这一年来，虽然对那些理概念的有所加强，自我感觉没有什么质的变化。前些天听我们公司的一位测试经理讲《敏捷测试》豁然开朗。他在学造飞机，而我一直在学造飞机里的一个发动机。我从来没想过，一个完整飞机的架构应该是怎样的。 　　如果想让测试在公司的项目中发挥出它最大的价值，并不是招两个测试技术高手，或引入几个测试技术，而是测试技术对项目流程的渗透，以及测试流程的改进与完善。虽然，当然测试行业前景乐观，许多中小企业也都在引入测试，但一百个公司就有一百种测试，每个公司对测试的看法不同，公司对测试的定位也不完全一样。本人前后经历两个公司，以自己的拙见浅谈一下对测试流程的看法。 这几天整理思路，回顾了前两份测试工作的流程与架构。 简陋的测试流程 　　先说笔者入职的第一个家公司，笔者是第一个入职的专职测试人员，相信一两个测试的公司还是不少的，入职后各种项目都在进行当中，上面给我的定位是并没完全融入到项目中去。而通过指派任务的方式。 下面是简陋的流程图： 需求分析与架构设计 ： 　　我们做的是某一移动公司内部使用的项目，需求分析与架构全部由项目经理完成，之后由项目经理给具体某个开发人员分配任务，具体对某个功能模块的实现。这个对项目经理的经验与技术要求很高

摘要：1. 登陆、添加、删除、查询模块是我们经常遇到的，这些模块的测试点该如何考虑 　1. 登陆、添加、删除、查询模块是我们经常遇到的，这些模块的测试点该如何考虑 　　1)登陆 　　① 用户名和密码都符合要求(格式上的要求) 　　② 用户名和密码都不符合要求(格式上的要求) 　　③ 用户名符合要求，密码不符合要求(格式上的要求) 　　④ 密码符合要求，用户名不符合要求(格式上的要求) 　　⑤ 用户名或密码为空 　　⑥ 数据库中不存在的用户名，不存在的密码 　　⑦ 数据库中存在的用户名，错误的密码 　　⑧ 数据库中不存在的用户名，存在的密码 　　⑨ 输入的数据前存在空格 　　⑩ 输入正确的用户名密码以后按[enter]是否能登陆 　　2) 添加 　　① 要添加的数据项均合理，检查数据库中是否添加了相应的数据 　　② 留出一个必填数据为空 　　③ 按照边界值等价类设计测试用例的原则设计其他输入项的测试用例 　　④ 不符合要求的地方要有错误提示 　　⑤ 是否支持table键 　　⑥ 按enter是否能保存 　　⑦ 若提示不能保存，也要察看数据库里是否多了一条数据 　　3) 删除 　　① 删除一个数据库中存在的数据，然后查看数据库中是否删除 　　② 删除一个数据库中并不存在的数据，看书否有错误提示，并且数据库中没有数据被删除 　　③ 输入一个格式错误的数据，看是否有错误提示

　　自动化测试用例的编写是实现项目自动化的核心，合理的用例设计是保证自动化效益和实用性的关键，也直接决定了自动化脚本是否具备可扩展和可维护性。由此，本篇文章主要为大家介绍了测试用例编写的规范和注意事项。 　 　一、自动化测试用例选择 　　自动化测试主要应用于基础功能的验证和回归，对于在项目迭代过程中不断修改的功能来说，手工测试的效率是大大高于自动化测试的。因此，我们在进行自动化之前，要挑选基础功能来进行自动化。在这个过程中，我们可以从手工测试用例中进行挑选，也可以专门为自动化编写一套用例。 　　在自动化初期，建议从手工测试用例中进行挑选。一方面手工测试用例的覆盖度最为全面，可以保证测试的全面性；另一方面，也会提高测试效率。我们挑选用例的原则是：清晰、简单、基础、改动小的功能。 　　 二、自动化测试用例编写 　　挑选完合适的用例之后，就是通过代码编写自动化用例的过程。这个过程主要包括数据预置、用例编写和用例后置三个步骤。 　 　1、数据预置 　　在进行用例编写之前，我们需要准备一些数据，保证用例能够真正的执行起来。比如，我们在测试一个网页登录功能，我们需要系统的URL参数、需要一个可以登录的用户名和密码；我们需要测试删除文件的功能，就需要提前上传一个文件，这个文件可以提前预置，也可以在执行删除操作之前，执行一个上传操作；通过哪种方式预置数据，需要根据项目的实际情况选择

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