功能测试

一、基本控件 单选按钮 是否只能选择一个选项 未进行选择时是否有默认值 多选钮 可以选择多个选项 按钮 按钮点击是否有效 点击按钮后的跳转页面或者提示是否正确（按钮为新增功能时重复点击是否提交多条重复信息） 按钮的点击有效范围 下拉菜单 下拉菜单的选项是否唯一 下拉选项是否可选 日期选择控件 注意选择起止日期的大小问题，终止日期不得小于起始日期 控件有效的选择范围 输入框 输入内容限定（号码，邮箱，验证码，金额<允许输入小数位数>） 输入特殊字符 输入内容含空格 列表 列表显示列唯一 当列表显示金额数值较大，是否显示完整 目录树 菜单树哪些选项是可选，哪些选项是禁止选 菜单树选项禁止输入内容 菜单树父子级关系正确 二、基本功能 新增功能 新增数据正确（数据库查看保存记录的一致性） 新增数据失败 新增数据的唯一性 修改功能 哪些项可以进行修改 可修改项进行修改保存后，修改项的生效时间（立即生效还是规定设置时间后生效） 删除功能 删除后数据是否再数据已经删除或者记录失效处理，不在页面进行显示 手机获取验证码 频繁获取验证码次数的限定,获取次数达到最大限定次数后是否锁定该手机号码，锁定一定的时间后再允许获取验证码操作 验证码的有效时间 文件上传功能 上传文件格式（excel兼容） 上传文件大小 上传文件数量 文件导出/下载功能： 下载文件名在不同浏览器是否存在乱码问题 文件格式是否正确

我们的测试计划 依次重复测试软件的每个功能板块，进行多次测试后，记录总结测试结果。 我们是否需要测试，直到我们的软件是完美的？ 我们的软件需要进行测试，但是软件是为一部分人服务的，软件只可以做的更好，但是不会完美，所以我们只要做的足够好即可。 对于测试来说什么是“足够好”？ 我认为，对于测试来说，目标用户的体验足够好才能代表这个软件足够好。 “退出的标准”是什么 （1）集成测试用例设计已经通过评审 （2）所有源代码和可执行代码已经建立受控基线，纳入配置管理受控库，不经过审批不能随意更改 （3）按照集成构件计划及增量集成策略完成了整个系统的集成测试 （4）达到了测试计划中关于集成测试所规定的覆盖率的要求 （5）集成工作版本满足设计定义的各项功能、性能要求 （6）在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准 每个项目团队定义什么是你的beta版本“足够好”？你的测试矩阵是什么？ 1.界面美观，并且使用户使用起来没有不便，按钮的位置合适舒适； 2.软件性能好，不会出现闪退、程序崩溃等问题； 3.软件功能基本满足用户的需求； 4.通过账号、密码登录，有一定的保密性。 测试矩阵： 软件功能 测试事务 并行测试 代码检规 新建笔记 插入图片 调用相机 二维码分享 × × 来源： https://www.cnblogs.com/teamProject/p/5551251.html

[+] 目的 范围 术语解释 测试用例原则 1 系统性 2 连贯性 3 全面性 4 正确性 5 符合正常业务惯例 6 仿真性 7 可操作性 测试用例主要元素 测试用例编写规范 1 常规的测试用例 2 初始化的测试用例 3 边界的测试用例 4 空值的测试用例 5 格式错误的测试用例 6 溢出的测试用例 7 关联的测试用例 8 唯一值的测试用例 9 权限不足的测试用例 10 角色权限的测试用例 测试用例编写细则 1 测试用例命名规则 2 测试用例编号规则 测试用例编写方法 1 测试用例编写准备 2 测试用例编写方法 1 目的 统一 用例编写的规范，为测试设计人员提供测试用例编写的指导，提高编写的测试用例的可读性，可执行性、合理性。为测试执行人员更好执行测试，提高测试效率，最终提高公司整个产品的质量。 测试 2 范围 适用于集成 测试 用例和 用例的编写，现在编写用例的辅助工具为 系统测试 TestDirector 8.0。 3 术语解释 集成测试： 集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。 系统测试 ： 系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的 “先知者问题 ”。 4 测试用例原则 4.1 系统性 1.

测试与调试（负责人：孙媛媛） 　一、功能检查 　　1 、功能是否齐全，例如：增加、删除、修改 　　2 、功能是否多余 　　3 、功能是否可以合并 　　4 、功能是否可以再细分 　　5 、软件流程与实际业务流程是否一致 　　6 、软件流程能否顺利完成 　　7 、各个操作之间的逻辑关系是否清晰 　　8 、各个流程数据传递是否正确 　　9 、模块功能是否与需求分析及概要设计相符 　　二、面向用户的考虑 　　1 、操作方便性，如：按键次数是否最少 　　2 、易用性，面对用户的操作是否简单易学 　　3 、智能化考虑 　　4 、提示信息是否模糊不清或有误导作用 　　5 、要求用户进行的操作是否多余，能否由系统替代 　　6 、能否记忆操作的初始环境，无需用户每次都进行初始化设置 　　7 、是否不经确认就对系统或数据进行重大修改 　　8 、能否及时反映或显示用户操作结果 　　9 、操作是否符合用户习惯，比如：热键 　　10 、各种选项的可用及禁用是否及时合理 　　11 、某些相似的操作能否做成通用模块 　　软件数据处理测试用例模板 　　一、输入数据 　　1 、边界值 　　2 、大于边界值 　　3 、小于边界值 　　4 、最大个数 　　5 、最大个数加 1 　　6 、最小个数 　　7 、最小个数减 1 　　8 、空值、空表 　　9 、极限值 　　10 、 0 值 　　11 、负数 　　12

测试数据设计方法一： 构造测试数据时，需要看数据的来源，数据的来源一般来讲有三个个，一个是根据被测系统需求的分析，针对正常业务，异常情况，边界情况等来构建完整的数据，又称为“造”数据。 这不仅仅包括最基本的基础数据，比如：用户、权限、配置、原数据等，还包括上面提到的业务数据。对于比较小型的系统来说可行度高，对于大型的系统来说可能较为复杂。 测试数据设计方法二： 第二种方式就是利用现有系统，这适合已有类似系统，测试是针对升级或者增加功能的产品化的系统。这种情况把已经在生产环境中运行的数据导出。在此基础上再进行数据的整理、 加工为测试数据。 测试数据设计方法三： 还有一种方式就是将现有非电子化的业务数据录入到系统中，在验证业务的同时也完成了测试数据的积累。即边测试边积累数据。但是这种情况积累的数据往往有一定局限性，因为 已、经发生的业务数据基本是正确的、一致的，而且可能缺少某些特定业务的数据（不常发生的业务）。这样就需要根据对测试需求的分析，追加新的测试数据，以便能完整覆盖业务 类型。 测试数据应用： 1，不该为空的数据是否有校验； 2，该有默认值的数据默认值是否正确； 3，引用其它功能生成的数据，是否会实时刷新； 4，页面关闭或系统重启后，数据的初始化设置等 5，数据的长度、类型控制是否合理，比如身份证号，实际业务中会有字母，且会出现在最后 一位 对应方法： 等价类、边界值、场景法

（一）什么时候进行冒烟测试 测试是测试人员确认软件存在bug的过程，此过程中不可避免是需要开发人员要 不停的修改bug，那么常常会发现 一个功能的改动，导致下一轮系统测试出现问题 。 即发现也许以前修改的bug的确是解决了，可是 由于修改一个或多个bug导致其他 功能模块出现新的问题 ，测试跑不通了，只能测试终止。 那么我们如何确保开发人员修复了bug后，这个bug的修复没有影响到其他 功能模块呢？这时就需要进行冒烟测试啦。 （二）什么是冒烟测试 冒烟测试是自由测试的一种，由开发人员与测试人员共同进行。 在测试过程中发现问题，测试人员找到了一个Bug，然后开发人员会来 修复这个Bug，冒烟测试是否通过决定了下一轮系统测试是否可以执行。 使用一袋烟的功夫 快速对软件的主要功能进行测试 冒烟测试的重要性 不作用于本身而是 决定了下一轮测试是否能达到理想的效果 与 系统测试 不同之处在于冒烟测试是一种不 要求覆盖面有多广测试 ，但是要 保证 被测对象的主要部分功能要得到测试，不要求每一个功能都面面俱到 ， 但是要保证所有 被修改过以及与修改相关的功能、主要的功能都是可用的 ， 即证明这个版本可进行系统测试 (三)执行冒烟测试的前提 前面提到冒烟测试是与开发的合同协作，因此有几个合作前提： a) 初步了解代码中进行了什么更改。若要理解该更改，必须理解使用的技术 b)

输入选择框 输入框 验证输入框之前的标题是否正确 验证输入与输出是否信息一致 未输入任何信息，当输入框里面有提示信息时，查看提示信息是否合理 字段长度校验(边界值) 验证输入状态：当处于某种状态下，输入框是否处于可写或非可写状态。例如，系统自动给予的编号等栏位作为唯一标识，当再次处于编辑状态下，输入框栏位应处于不可写状态，如果可写对其编辑的话，可能会造成数据重复引起冲突等 验证对特殊字符输入的处理： a.输入域如对某些字符禁止输入时，是否有限制 b.中文、英文、空格，数字，字符，下划线、单引号 等所有特殊字符的组合 c.所有特殊字符测试（!~@#$^&*()_+{}|:“<>?/.,;‘[]=-`￥……（）–：《》？、。，；’【】、=-•） 验证二代身份证号： a.长度不等于18位的数字串，是否提示错误 b.特殊字符X在最后一位，是否校验通过 c.特殊字符X在前面17位中任意一位，是否提示错误 d.带字母（非X）、特殊字符、空格、汉字，是否提示错误 e.特殊的18位数字串，如‘00…00’,‘11…11’，是否提示错误 验证多行文本输入的处理： a.是否允许回车换行 b.保存后再显示能够保持输入时的格式 c.仅输入回车换行，检查能否正确保存；若能，查看保存结果。若不能，查看是否有正确提示 d.仅输入空格，检查能否正确保存；若能，查看保存结果。若不能，查看是否有正确提示

今天主要是讲了函数装饰器，真的是一个很强大的功能，总算整出来一点点贴近实际的东西，很开心，所以总结的有点晚了。 生成器的回顾： # 上节课程内容的补充，关于生成器只能运行一次的问题 # def test(): # for i in range(4): # yield i # # t = test() # t1 = (i for i in t) #此处只是产生生成器t1，不进行任何运算，并没有发生任何便利操作 # t2 = (i for i in t1) #此处只是产生生成器t1，不进行任何运算，并没有发生任何便利操作 # print(list(t1)) #此时生成器t1才开始运算遍历，此时t1生成器已经完成一次遍历，生成：[0, 1, 2, 3] # print(list(t2)) #此时t2才去调取t1生成器，但是此时生成器t1已经遍历过了，只有空，所以生成：[] #以上内容尤其要注意的是，t1和t2在被赋值的时候不进行任何运算，知道list()发生时才开始进行调用运行。 装饰器的引入： #装饰器的引入： #装饰器的定义：本质就是函数，功能是为其他函数添加附加功能 #原则：1.不修改被装饰函数源代码；2.不修改被修饰函数的调用方式 #装饰器涉及的基础知识：装饰器 = 高阶函数 + 函数嵌套 + 闭包 #测试仅用高阶函数实现功能： #功能需求，给函数增加测试运算时间的功能

''' 要求 ： 1、 设计至少五条用例 2、至少用两种方式往测试集合（套件）中添加测试用例 3、执行测试集合（套件）中的测试用例，生成测试报告 ''' # 测试的代码 # 设计用例，对此功能函数进行单元测试 users = [{'user': 'python23', 'password': '123456'}] def register_test(username, password1, password2): # 注册功能 for user in users: # 遍历出所有账号，判断账号是否存在 if username == user['user']: # 账号存在 return {"code": 0, "msg": "该账户已存在"} else: if password1 != password2: # 两次密码不一致 return {"code": 0, "msg": "两次密码不一致"} else: # 账号不存在 密码不重复，判断账号密码长度是否在 6-18位之间 if 6 <= len(username) >= 6 and 6 <= len(password1) <= 18: # 注册账号 users.append({'user': username, 'password': password2}) return {"code": 1, "msg": "注册成功"}

软件测试方法种类繁多，记忆起来混乱， 因此，我通过查阅资料，参考一些书籍，把常用的软件测试方法列出来，方便认识软件测试的方法。 从测试设计方法分类 测试名称 测试内容 Black box 黑盒测试 把软件系统当作一个“黑箱”，无法了解或使用系统的内部结构及知识。从软件的行为，而不是内部结构出发来设计测试. White box 白盒测试 设计者可以看到软件系统的内部结构，并且使用软件的内部知识来指导测试数据及方法的选择。 Gray box 灰盒测试 介于黑盒和白盒之间 总结： 实际工作中，对系统的了解越多越好。目前大多数的测试人员都是做黑盒测试，很少有做白盒测试的。因为白盒测试对软件测试人员的要求非常高，需要有很多编程经验。 从测试是手动还是自动上分类 测试名称 测试内容 Manual Test 手动测试 测试人员用鼠标去手动测试 （测试GUI） Automation 自动化测试 用程序测试程序 （测试API） 对于项目来说， 手动测试和自动化测试同等重要，都是保障软件质量的方法。 目前大部分的项目组都是手动测试和自动化测试相结合。因为很多测试无法做成自动化，很多复杂的业务逻辑也很难自动化， 所以自动化测试无法取代手动测试。 对于软件测试人员个人发展来说， 做自动化测试是个挑战，也是测试人员发展的一个方向，需要测试人员学习大量的开发知识。从长远角度来看，自动化测试肯定是越来越吃香的。