功能测试

首先来看下面几个场景你是否熟悉 1、你正在开发一个系统，你不断地编码-编译-调试-编码-编译-调试……终于，你负责的功能模块从上到下全部完成且编译通过！你长出一口气，怀着激动而又忐忑的心情点击界面上的按钮，顿时你刚刚的轻松感烟消云散：系统无法正常工作，你想读的数据显示不出来，你想存的东西也送不到数据库……于是，你再次回到IDE里，设断点、调试、一层一层跟踪，当你精疲力尽终于将数据送到数据库里，你又发现了其它问题，于是你继续设断点、调试、编译、调试…… 2、你狂躁地敲击着键盘和鼠标，咒骂着不断出现的bug：啊？这里怎么没返回值啊！哎？这里不该是0啊！不对啊，这里怎么没数据……你永远不知道还有多少bug，你也永远不知道你的改动会不会引入其它bug——这里有几十个甚至上百个类，几百几千个方法！我不能都照顾到啊！你感觉bugs像敲击鼹鼠游戏中的鼹鼠：打下了这个，另一个又从其它洞口露出头来…… 3、也许是毕业答辩的演示，也许是客户的审查，你小心地打开自己要演示的系统，进行着预定的操作，忽然，有个功能不能正常运行，你大汗淋漓，在答辩老师或者客户质疑且不满的目光下你试了又试，但还是于事无补……于是，答辩老师可能扭头便走，客户可能愤然离去，然后离去的还有你的学位证和项目奖金。当后来你检查代码时，发现这一切竟然只是因为一个底层工具类中一个方法输出结果为空。

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 1. 背景与挑战 随着公司国际化战略的推行以及本土业务的高速发展，后台支撑系统已经不堪重负。在吞吐量、稳定性以及可扩展性上都无法满足日益增长的业务需求。对于每10万元额度的合同，从销售团队准备材料、与客户签单、递交给合同部门，再到合同生效大概需要3.5人天。随着业务量的快速增长，签订合同的成本急剧增加。 合同管理系统是后台支撑系统中重要的一部分。当前的合同系统是5年前使用.NET基于 SAGE CRM 二次开发的产品。 一方面，系统架构过于陈旧，性能、可靠性无法满足现有的需求。另一方面，功能繁杂，结构混乱，定制的代码与SAGE CRM系统耦合度极高。由于是遗留系统，熟悉该代码的人早已离职多时，新团队对其望而却步，只能做些周边的修补工作。同时，还要承担着边补测试，边整理逻辑的工作。 在无法中断业务处理的情况下，为了解决当前面临的问题，团队制定了如下的策略： 1). 在现有合同管理系统的外围，构建功能服务接口，将系统核心的功能分离出来。 2). 利用这些功能服务接口作为代理，解耦原合同系统与其调用者之间的依赖； 3). 通过不断构建功能服务接口，逐渐将原有系统分解成多个独立的服务。 4). 摒弃原有的合同管理系统，使用全新构建的(微)服务接口替代。 2. 什么是微服务 多年来，我们一直在技术的浪潮中不断乘风破浪

前几天做了一个语音播报功能,本地测试ok,但是上线要求https协议费了点时间 1.启动失败情况出现如下错误请检查php.ini 文件 disabled_functions 函数是否禁用了 stream_socket_server(); 2. workerman.log 仅用于记录workerman自身相关启停等日志. 如果启动不成功会写入日志 3.客户端常见报错,手册地址: http://doc.workerman.net/faq/client-connect-fail.html 4.上代码把修改,start_io.php 5.修改start_web.php 6.前端代码调用 7. 最后一步后端服务启动停止, 如果出现报错,请参考 步骤一 排除 ### 启动服务 php start.php start -d ### 停止服务 php start.php stop ### 服务状态 php start.php status 来源： CSDN 作者： qq_31570703 链接： https://blog.csdn.net/qq_31570703/article/details/103628915

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

说明：该篇博客是博主一字一码编写的，实属不易，请尊重原创，谢谢大家！ 接着上一篇博客继续往下写 ： https://blog.csdn.net/qq_41782425/article/details/103568475 八、SVN的安装使用 1.SVN的安装 说明： SVN分为服务器和客户端，博主以windows server2008 作为服务器，以windows7 作为客户机 准备工作： 在虚拟机中回到纯净版快照，来进行SVN的安装演示 1.1 安装服务器程序 在windows server 2008中进行安装VisualSVN-Server，傻瓜式安装 安装完成 1.2 安装客户端程序 在虚拟机windows7 x64中安装客户端TortoiseSVN 傻瓜式安装 1.3 安装客户端语言包 傻瓜式安装即可 2.SVN的使用 2.1 创建版本库 在VisualSVN Servers\Repositories上右键选择Creat New repository，创建新的版本库，并在文本框中输入库名称 创建名为Student的学生版本库后，右击该库新建文件夹 版本库架构如下（博主自己创建的，公司工作的时候大同小异） 2.2 安全配置(权限分配) 右键点击界面上的Users文件夹，选择create user 用户创建如下 右键点击界面上的Groups文件夹，选择create Group

宽 带上网已经不是什么新鲜事情，人们对相关的网络器件已经不再陌生，比如说常见的路由器。对于一般的网络用户，他们能知道怎样使用路由器来上网、玩游戏等就 已经感到很满足了，通常情况下对路由器的深层技术很少去过问研究，但做为兴趣广泛的技术爱好者，对这方面的知识是非常感兴趣的。但限于各种条件的制约，这 些爱好者都非开发者，很大程度上无法深入了解真正的技术实现过程以及相关的核心内幕。正是基于此点，笔者凭借自身的知识沉淀，尽最大努力为爱好技术的读者 架设一坐能通向深层核心的桥梁，为大家揭开路由器的神秘面纱，剖开其核心内脏。为使读者能清晰明白的理解掌握，笔者尽量将专业的技术内容转化为容易接受的 知识讲解，其中可能有不足偏颇之处，还请大家多见谅。 概述 什么是路由器? 互联网是依靠路由器连接起来的，路由器是互联网或者说IP网络的核心设备。宽带接入的不断增长，带动了路由器的需求不断增加。 路由器究竟是什么样的技术产物? 谈到路由器的开发，我们就不免要谈到“嵌入式”设备的开发，没错，通俗的说，路由器就是一种嵌入式产品。那么究竟什么是嵌入式设备呢? 　 　其实就目前而言，嵌入式设备已经不断深入我们的日常生活方方面面。通俗的讲，嵌入式设备是指具有计算机功能，但又不称为计算机的设备或器材，它几乎包括 了我们周围的所有电器设备 PDA、手机、机顶盒、汽车、微波炉、电梯、安全系统、自动售货机、医疗仪器、立体音响

软件缺陷的定义 来看一下 Ron Patton 为我们的软件缺陷所下的定义。 1、软件没有实现产品的说明书所描述的功能。（个人觉得 “ 描述 ” 比 “ 宣称 ” 更贴切） 2、软件实现了产品说明书描述不应有的功能。 3、软件执行了产品说明书没讲的操作 4、软件没有实现产品说明书没讲但应该实现的功能。 5、从软件测试员的角度来看，软件难以理解、不易使用、运行缓慢，或者最终用户认为不对。 为什么一个定义要这么多条来描述？这个 “ 缺陷 ” 的定义有这么复杂么？不，它其实并不复杂，作者只是想更加全面的来给“缺陷”下定义。下面我们来以建一栋房子为例，来说明一下每一条定义的意思。需要说明的是没有十分完美而且一成不变的产品说明说，而且在实际项目中，它可能非常简陋，模棱两可，甚至经常变动。 1、软件没有实现产品说明书的描述的功能。房子的主人希望有一个落地的大窗户，让阳光更好的照进屋子里，而且他特意在房子的设计图纸中画出来，并且还加以说明。结果，他看到的是四面全是墙壁，只有一个小门的房子。那么对于测试人员来说，他就是一个缺陷。 2、软件实现了产品说明书中描述的不应有的功能。由于房子的主人生活在南方，天气温暖，而请来的泥瓦匠是北方的，结果给主人建造的房子具然有一个大大的取暖的烟筒，而且主人特意在房子的设计图纸中说明，自己的房子不要烟筒。那么对于测试人员来说，这也是个缺陷。 3

简陋的测试流程 　　先说笔者入职的第一个家公司，笔者是第一个入职的专职测试人员，相信一两个测试的公司还是不少的，入职后各种项目都在进行当中，上面给我的定位是并没完全融入到项目中去。而通过指派任务的方式。 下面是简陋的流程图： 需求分析与架构设计 ： 　　我们做的是某一移动公司内部使用的项目，需求分析与架构全部由项目经理完成，之后由项目经理给具体某个开发人员分配任务，具体对某个功能模块的实现。这个对项目经理的经验与技术要求很高，他既然担任了需求分析师，又担任架构师的角色。 程序员编码 ： 　　因为我们开发语言用的是JAVA 语言，IDE用myeclipse 中自带的CVS版本管理工具，开发人员完成代码后，提交到版本库中。 测试 ： 　　笔者入职后的第一个任务是搭建缺陷管理工具，禅道项目管理，通过推广对发现的问题进行跟踪。后来正明效果并不好，因为对于一个六七人的开发团队项目，开发人员更喜欢测试人员能当面反馈，这样更能提高效率。对一个小bug 通过当面交流的方式就可以将问题修复。 　　对于当时的环境，并没有测试线。开发人员在本机上将项目进行部署运行。测试人员通过局域网访问开发人员的机子进行访问。或在测试人员本机上进行部署测试。这也是一个致命的缺点。因为开发人员测试人员使用的电脑存在太多不稳定性，这些都会造成问题的出现，有时候难以判定是系统问题还是环境问题。 上线 ： 　

一. 软件测试方法 软件测试方法：白盒测试、黑盒测试、灰盒测试、静态测试、动态测试 白盒测试：是一种测试用例设计方法，在这里盒子指的是被测试的软件，白盒，顾名思义即盒子是可视的，你可以清楚盒子内部的东西以及里面是如何运作的，因此白盒测试需要你对系统内部的结构和工作原理有一个清楚的了解，并且基于这个知识来设计你的用例。 白盒测试技术一般可被分为静态分析和动态分析两类技术。 静态分析主要有：控制流分析技术、数据流分析技术、信息流分析技术。 动态分析主要有：逻辑覆盖率测试(分支测试、路径测试等)，程序插装等。 白盒测试优点：迫使测试人员去仔细的思考软件的实现；可以检测代码中的每条分支和路径；揭示隐藏在代码中的错误；对代码的测试比较彻底；最优化。 白盒测试缺点：昂贵；无法检测代码中遗漏的路径和数据敏感性错误；不验证规格的正确性。 黑盒测试又叫功能测试，这是因为在黑盒测试中主要关注被测软件的功能实现，而不是内部逻辑。在黑盒测试中，被测对象的内部结构，运作情况对测试人员是不可见的，测试人员对被测产品的验证主要是根据其规格，验证其与规格的一致性。 在绝大多数没有用户参与的黑盒测试中，最常见的测试有：功能性测试、容量测试、安全性测试、负载测试、恢复性测试、标杆测试、稳定性测试、可靠性测试等。 灰盒测试：白盒测试和黑盒测试往往不是决然分开的，一般在白盒测试中交叉使用黑盒测试的方法

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