测试用例

加载测试用例规则： Pytest从我们当前运行的目录开始查找所有目录，查找以test_开头的测试文件，以Test开头的测试类，以test_开头的测试函数 来源： https://www.cnblogs.com/wang-mengmeng/p/11434787.html

对于开发人员来说，往往对各种测试方法感到疑惑。特别是在整合代码的时候，我们就能深刻感觉受到测试的重要性。很多开发人员只注重写代码，轻视测试的重要性。总是代码一写完提交然后就交给测试组测试了，没多久测试组发回测试报告。然后又苦恼的修改自己代码的bug，慢慢地就开始讨厌测试组人员。没有经过自己细心测试的代码，不仅浪费了别人时间更影响到了自己的心情。 企业级项目实战(带源码)地址 ： http://zz563143188.iteye.com/blog/1825168 收集五年的开发资料下载地址： http://pan.baidu.com/share/home?uk=4076915866&view=share 接下来为大家细心讲述一下各种测试应用的环境及作用 一、测试环境和角色 黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试 ： 这些测试的范围正好是逐步递增的关系，但是测试的人员角色是不同。 黑盒测试、白盒测试、单元测试：开发人员分在不同的开发阶段要做的事情 黑盒测试、集成测试、系统测试：测试人员在测试周期内级层做的工作 验收测试：一般是在用户方做的工作 二、根据不同的范围 测试可以分为单元测试、集成测试、系统测试和验收测试。 体现了测试由小到大、又内至外、循序渐进的测试过程和分而治之的思想。 三、测试的功能 1.单元测试 粒度最小，一般由开发小组采用白盒方式来测试

文件目录 文件里面的结构就是常规的 unittest框架的写法 总执行文件 # #coding=utf-8 import unittest, time, os, multiprocessing import unittest #引入框架 import HTMLTestRunner_Chart import sys reload(sys) sys.setdefaultencoding('utf8') #创建一个测试套件 testunit=unittest.TestSuite() #把测试用例目录里面 test开头的测试用例文件提取出来，并获取了里面的测试用例 n='/Users/lucax/Desktop/工作/自动化覆盖/codemao_request_houtai/script/user_manage/old_Cat_mange/' discover=unittest.defaultTestLoader.discover(n,pattern ='old_Cat_mange*.py',top_level_dir=n) #下面通过不断筛选提出不要的部分，最后剔除到只有模块名.类名.测试用例名称 for test_suite in discover: 　　for test_case in test_suite: 　　　　testunit.addTest(test_case) n='

题目描述： 输入格式：   输入第 1 行给出正整数 T (≤10)，是测试用例的个数。随后给出 T 组测试用例，每组占一行，顺序给出 A、B 和 C。整数间以空格分隔。 输出格式：   对每组测试用例，在一行中输出 Case #X: true 如果 A+B>C，否则输出 Case #X: false，其中 X 是测试用例的编号（从 1 开始）。 输入样例： 4 1 2 3 2 3 4 2147483647 0 2147483646 0 -2147483648 -2147483647 输出样例： Case #1: false Case #2: true Case #3: true Case #4: false 具体实现（Java）： package com.hbut.test; import java.util.Scanner; public class Main { public static void main(String[] args) { Scanner sc = new Scanner(System.in); int n = sc.nextInt(); for (int i = 1; i <= n; i++) { long a = sc.nextLong(); long b = sc.nextLong(); long c = sc.nextLong(); System

实战项目-用例评审-问题总结 内部班项目用例评审，总结的问题；供大家参考！提升用例最好的方式，可以互相执行下（评审），就会明白自己的差距或者需要避免的点在哪里。（前提是会） 1）覆盖率 原型中提到的一定要覆盖全面；未提到的规则，自己要想的明白，写出来（有时候原型或者UI与实际的东西并不是相符的） 2）排版 注意整体用例的排版（执行的先后顺序） 3）模板 公司模板可不用修改 4）标注 文档中禁止使用多颜色（显得不是太正规） 5）正确性 测试时首先要保证功能的正确性-正确的视角--重点（多位同学遗漏） 6）业务用例 业务场景用例，可以单独拆分出来；当然也可以合并在功能用例里 7）书面语 注意描述用语；尽量使用书面语 8）业务关系 一定要注意前后功能点的业务关系；业务视角用例一定要写清楚--重点；例：还款总额与申请借款；还款后的还款总额是否对应变化等 9）xmind书写用例 使用xmind书写用例时，要注意分支的正确性；子功能点要在父功能点的后面分支 10）sheet页 不同的功能模块，可不用分开书写；放在同一个sheet页就可以 11）关于数据 如果有计算模块的话，需要在用例中表明数据及计算公式 ===往期精选技术文章=== 我能学习测试吗？学完后可以就业吗？ 请看：Dotest-董浩- 我能学习，就业吗？ 那如何自学软件测试呐？ 请看：Dotest-董浩- 软件测试应该怎么自学？

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、测试设计 　　　　测试设计是对测试计划的细化。也是以文档的形式输出。主要内容有测试环境的描述、用例执行的顺序（一般都是功能性用例到易用性、兼容性再到安全性、异常行为等）、用例的设计规定

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，过滤掉，小数点后面

测试计划、测试方案、测试策略、测试用例的区别 转自： https://www.cnblogs.com/zhangyublogs/p/5124735.html 一 测试计划 测试计划是指描述了要进行的测试活动的范围、方法、资源和进度的文档。它主要包括测试项、被测特性、各阶段的测试任务、时间进度安排，谁执行任务和风险控制等，可以包括测试策略。 二 测试方案 测试方案是指描述需要测试的特性、测试的方法、测试环境的规划、测试工具的设计和选择、测试用例的设计方法、测试代码的设计方案。 三 测试策略 侧重需求分析，评估风险，定义测试范围，确定测试方法，制定测试启动、停止、完成标准和条件。 四 测试用例 根据测试计划，制定完成测试任务的具体测试步骤。 五 测试计划与测试方案区别 序号 角度 测试计划 测试方案 1 组织方式不同 管理文件 技术文件 2 目的不同 强调“做什么” 强调“怎么做” 3 具体要求不同 组织架构、工作任务分配、工作量估计、人力物力资源的分配、进度的安排、风险的估计和规避、各任务通过准则等 测试需求的细化、测试组网图的设计、自动化测试框架的设计、测试数据和测试脚本的设计、测试用例设计的原则等 ------------------------------------ 测试方案模板 1 目的 2 范围 3 术语和缩略语解释 4 参考文献 5 测试目标 6 测试范围 测试序号

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，过滤掉，小数点后面