功能测试

编码规范 1 前言 为确保系统源程序可读性，从而增强系统可维护性，java编程人员应具有基本类似的编程风格，兹制定下述Java编程规范，以规范系统Java部分编程。系统继承的其它资源中的源程序也应按此规范作相应修改。 2 适用范围 本文档将作为java编程人员软件开发的编程格式规范。在项目Java部分的编码、测试及维护过程中，要求严格遵守。 3 命名规范 定义这个规范的目的是让项目中所有的文档都看起来像一个人写的，增加可读性，减少项目组中因为换人而带来的损失。 3.1 Package 的命名 Package 的名字应该都是由一个小写单词组成。示例：unipost.trans 3.2 Class 的命名 Class 的名字每个单词必须由大写字母开头而其他字母都小写的单词组成。示例：FileMng 3.3 Class 成员的命名 变量、方法、属性：大小写混排的单词组成，首字母小写 示例： functionName、countNum、size 3.4 Static Final 变量的命名 Static Final常量：大写单词组成，单词之间使用“_”连接 示例： MAX_INDEX 3.5 前后台变量名称 前台变量 fg_变量名 后台变量 bg_变量名 3.6 参数的命名 参数的名字必须和变量的命名规范一致。 3.7 数组的命名 数组应该总是用下面的方式来命名： 1 byte[]

开发同学说，感觉我的等级划分是乱来的。所以特别来记录下缺陷等级程度的划分。 测试过程中发现的缺陷一般分为如下几类： 功能问题（FunctionError）：对产品、项目质量有影响，但尚难以确定是否是错误，暂时无法解决 功能缺陷（FunctionDefect）：不满足用户需求等bug的总称 页面缺陷（UIDefect）：页面美观性、协调性、错别字等 建议类（Suggestion）：对产品、项目的建议性意见，不强制要求修改 硬件性能：进行性能测试时使用，暂定：网络延时、内存问题、CPU占用、硬盘问题 安全性问题：进行系统安全测试时使用，暂不订具体标准 业务流程问题：进行业务流程测试时进行 数据库性能：暂不执行 模块间接口问题:涉及有模块间数据传递时使用 其他(Other):其它 根据各类缺陷的严重程度将缺陷分为5个等级，具体如下： 1、低(Low) -建议类错误，对软件的改进意见或者建议。如： 　　a、功能建议 b、操作建议 c、校验建议 　　d、说明建议 　　e、UI建议 2、中(Medium) -使操作者不合理或者不方便或操作遇到麻烦，但它不影响执行工作功能或重要功能，次要功能，对产品使用影响不大。如： 　界面错误： 　　a、使操作者不方便或者遇到麻烦，但不影响执行工作功能的实现 　　b、界面、控件的摆布、图标、输入输出不规范 提示类错误： 　　a、删除操作未给出提示 　　b

原文链接： https://www.cnblogs.com/ftl1012/p/javaCode.html 编码规范 1 前言 为确保系统源程序可读性，从而增强系统可维护性，java编程人员应具有基本类似的编程风格，兹制定下述Java编程规范，以规范系统Java部分编程。系统继承的其它资源中的源程序也应按此规范作相应修改。 2 适用范围 本文档将作为java编程人员软件开发的编程格式规范。在项目Java部分的编码、测试及维护过程中，要求严格遵守。 3 命名规范 定义这个规范的目的是让项目中所有的文档都看起来像一个人写的，增加可读性，减少项目组中因为换人而带来的损失。 3.1 Package 的命名 Package 的名字应该都是由一个小写单词组成。示例：unipost.trans 3.2 Class 的命名 Class 的名字每个单词必须由大写字母开头而其他字母都小写的单词组成。示例：FileMng 3.3 Class 成员的命名 变量、方法、属性：大小写混排的单词组成，首字母小写 示例： functionName、countNum、size 3.4 Static Final 变量的命名 Static Final常量：大写单词组成，单词之间使用“_”连接 示例： MAX_INDEX 3.5 前后台变量名称 前台变量 fg_变量名 后台变量 bg_变量名 3.6 参数的命名

这个作业属于哪个课程 < 2020 春 W 班 (福州大学) > 这个作业要求在哪里 < 作业要求 > 这个作业的目标 团队练习使用Git使用，口罩预约系统 作业正文 < 作业正文 > 其他参考文献 <《构建之法》> 学号 贡献度 221701412 22 221701414 18 221701417 4 221701418 10 221701420 10 221701429 10 221701431 22 221701439 4 part.00 GitHub地址 https://github.com/theTuring/live-project Part.01 组员职责分工 陈浩男：前端界面 UI 开发设计、项目架构、后端 黎家泽：参与界面 UI 开发设计、后端文档导出 刘志勇：完成项目的测试，提供修改建议 王肃南：根据作业要求，完成原型设计 郑斯彬：后端编码 程伟行：后端编码 黄晓东：后端编码 关敏：参与测试和讨论 Part.02 提交日志截图 Part.03 程序运行截图 Part.04 程序运行环境 Part.05 GUI 界面 项目原型 https://rjognp.axshare.com 本次项目的界面由 Java swing 组件编写，GUI 界面详见下面两项。 Part.06 基础功能实现 入口页面 口罩预约 中签查询功能 成功中签 预约失败 Part.07

摘要： 随着科学技术的飞速发展，软件的功能越来越强大，软件的复杂性也越来越高，从而大大增加了软件测试与可靠性评估的难度。为了保证一个软件系统的质量，有必要针对软件的测试与可靠性评估方法进行专门地研究。本文就是针对这一领域所做的一些研究。 　　 一.软件测试的定义 　　软件测试（Software testing）是软件生存期（Software life cycle）中的一个重要阶段，是软件质量保证的关键步骤。通俗地讲，软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码进行最终复审的活动。1983年IEEE提出的软件工程术语中给软件测试下的定义是：“使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。这个定义明确指出：软件测试的目的是为了检验软件系统是否满足需求。 　　从用户的角度来看，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，所以软件测试应该是“为了发现错误而执行程序的过程”。或者说，软件测试应该根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现程序错误或缺陷。 　　 二.软件测试的生命周期 　　测试主要依据是被试系统的研制任务书和技术规格书，是对软件整体功能和性能的综合测试与评估

[原创]什么是测试驱动开发? 一 什么是测试驱动开发? 测试驱动开发，英文全称Test-Driven Development，简称TDD，是一种不同于传统软件开发流程的新型的开发方法。它要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码，并加速开发过程。 二测试驱动开发原理? 测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码，然后只编写使测试通过的功能代码，从而以测试来驱动整个开发过程的进行。这有助于编写简洁可用和高质量的代码，有很高的灵活性和健壮性，能快速响应变化，并加速开发过程。 三测试驱动流程? 1 定义应用程序的要求 2 熟悉应用程序的功能区域，确定要使用的单项功能项或功能要求 3 创建验证要求的测试列表 4 为功能或要求定义接口和类 5 编写测试代码 6 运行测试 7 根据测试生成产品代码 8 重新运行测试，根据测试修改产品代码，直到所有测试都通过 9 整理代码 10 重复上面的步骤 来源： https://www.cnblogs.com/mayingbao/archive/2006/04/26/385855.html

1、 页面启动是否正常，是否有相应的提示框、页面错误提示等。 2、 页面的每项功能是否符合实际要求。 3、 菜单、按钮操作是否正常、灵活、能处理一些异常操作。 4、 能否接受正确的数据输入，能否对异常数据的输入有提示、容错处理等（尤 其对一些边界值、峰值、易忽略数据、最大值、最小值等）。 5、 数据的输出结果是否准确，格式清晰，并且符合使用者阅读 6、 功能逻辑是否符合使用者习惯。 7、 系统的各种数据状态是否按照正常的业务流程而变化，并保持稳定。 8、 是否支持各种应用的浏览器环境。 9、 与外包应用的接口是否有效（比如邮件）。 10、 系统的所有链接是否按照指示确实连接到该链接的页面，该连接的页 面是否存在，有没有存在鼓励的界面。 11、 Web 安全测试：XSS、CSRF 以及 SQL 注入等。 来源： https://www.cnblogs.com/ceshizhilu/p/12467856.html

功能测试，简单的理解就是黑盒测试，就是检测黑盒子，找到里面存在的缺陷。 功能测试新人学习计划： 1. 对于产品的学习---站在客户的角度学习产品、看待问题 测试人员不是简单地按照开发人员的设计文档去撰写测试相关文档，对于设计文档的准确性同样负有责任。测试人员需要认真学习需求说明书，审核设计文档。同时，要站在客户的角度去理解功能设计是否合理。 2. 熟悉各种测试文档：对比自己的测试角度与思维，一边提高自己对功能测试的认识，也一边提升自己的测试能力。 3. 了解功能测试的流程：瀑布模型与敏捷开发模式的区别，每个公司每个项目之间也同样存在区别。 4. 对产品整个安装包各层软件的了解：必不可缺的基本技能 5. 学习自动化测试工具：对于功能测试而言，自动化测试是提高工作效率、保证测试质量及减少累积的 回归测试工作量的重要保证。所以，自动化测试是功能测试人员的另一基本技能。随着对功能测试越来越重视，自动化测试已经成为业界的一个重要考量指标。 那么，如何学习 自动化测试 呢？ 首先，要理解功能测试用例自动化所依附的自动化开发框架，二是要学会自动化功能测试用例的自动化工具，三是要依据一定的规范开发功能测试用例的自动化脚本。 在功能测试中，最终结果固然很重要，中间的过程也不容忽视，否则会对整个应用带来潜在的或重或轻的问题。 在 黑盒测试 中，对测试人员的基本要求是他要知道软件的外在行为

Android APP功能测试包含APP的安装卸载测试，界面测试，业务功能测试，APP特性测试，交叉事件测试，兼容性测试，升级更新测试，消息通知测试，功能键测试，手势测试等 1-APP的安装和卸载 1.1安装 软件在不同操作系统（Android 5.0/Android 6.0/Android 7.0/Android8.0及其他小迭代系统版本）上是否正常安装 软件在不同的品牌手机（华为/三星/OPPO/VIVO等其他品牌手机）上是否正常安装 软件在不同屏幕分辨率/屏幕大小的手机上是否正常安装 第三方平台直接安装（豌豆荚/应用商店/手机助手等），是否正常安装 安装过程中，是否可以取消，点击取消后，写入的文件是否如需求说明处理 安装过程中，提示信息中不能出现代码、符号、乱码等。 安装过程中，意外情况（如死机，重启，断电）的处理是否符合需求 安装时，是否识别有SD卡（存储卡），是否默认安装到sd卡中 安装空间不足（内存或者磁盘空间不足）时是否有相应提示 安装若需要网络验证，弱网或者断网情况下安装是否正常 安装若有具体的安装手册，依照手册安装是否正常安装 安装完成后，是否生成多余的目录结构和文件 首次安装完成后，是否正常启动APP 版本覆盖安装后，是否正常启动APP 1.2卸载 直接删除安装文件夹卸载是否有提示信息，是否正常卸载 直接卸载APP应用程序是否有提示信息，是否正常卸载 卸载过程中

软件测试模式-敏捷测试 Agile Testing——遵循敏捷宣言的一种测试实践 一、敏捷宣言 个体交互 重于 过程和工具 可用的软件 重于 完备的文档 客户协作 重于 合同谈判 响应变化 重于 遵循计划 注：在每对比较中，后者并非全无价值，但我们更看重前者。 二、敏捷测试的特点 强调从客户角度进行测试。 重点关注迭代测试新功能，不在强调测试阶段。 尽早测试，不间断测试，具备条件即测试。 强调持续的反馈。 预防缺陷重于发现缺陷。 三、敏捷测试VS传统测试的区别 1、传统测试： 测试是质量的最后保护者。 严格的变更管理。 预先的计划和细节的准备。 重量级文档。 各个阶段测试严格的入口和出口标准。 更多在回归测试时进行重量级的自动化测试。 严格依赖流程执行。 测试团队和开发团队是相对独立的。 2、敏捷测试： 开发和测试人员是紧密合作，大家都有职责对软件负责。 变更是可接受的，拥抱变更。 计划随着进展时常调整。 只需要绝对必要的文档。 各迭代之间已经没有明显的入口和出口标准。 所有阶段都需要自动测试，每个人都需要做，是项目集成的一部分。 流程不再需要严格执行。 团队是无缝隙合作。 四、基于脚本的测试 1、SBT（Script-based Testing）： 强调的是先做测试设计，然后在做测试。 2、ST（Scripted Testing）： 强调的是先做测试设计，然后在做测试。 3、ET