一、界面 1、登录界面是否清晰合理美观，无乱码（文字简洁、无错别字）
二、功能（主要采用等价类、边界值方法） 1、输入正确的用户名、密码，是否登录成功 2、输入错误的用户名或者密码，登录失败有没有提示（用户名或密码为空） 3、用户名、密码支持的字符类型 4、输完用户名之后按Tab键是否能到输入密码的框，输完密码之后按回车能否登录 5、如果有记住用户名密码的功能，下一次打开页面，是否默认有用户名密码 6、用户名、密码是否大小写敏感 （具体还可以考虑：这个用户名密码是否已注册）
三、安全性 1、在登录页面，输入的密码是否隐藏显示 2、多次登录失败，系统会不会阻止后续的尝试以应对暴力破解 3、用户名、密码能否支持复制、黏贴 4、在浏览器中直接输入登录成功后的URL地址，验证是否会重新定向到用户登录界面 5、密码输入框内的密码是否都可以在页面源码模式下被查看
四、兼容性 1、不同操作系统上同版本的浏览器能否正常打开登录界面，界面正常 2、相同操作系统的不同浏览器能否正常打开登录界面，界面正常 3、这个登录界面能否在移动手机端正常打开
五、性能压力 1、输入正确用户名、密码之后点击登录按钮，直到登录成功打开页面，需要多长时间（小于3秒） 2、多个用户同时进行登录操作，相应登录的时间是否会变长（小于5秒）
功能测试： （1）按钮功能，开门（运行中按开门键不开门），关门，电梯内按钮功能（电梯按键在按下时是否点亮，按错楼层是否可以取消）； （2）上升，下降（每一层申请是否有效，是否可以正常停靠），超载时是否会忽略其它楼层的上行和下行申请，电梯的两边按钮是否都可以使用； （3) 电梯内电话、灯光等
性能测试： 反应时间、关门时间、速度(是否造成人体不适）
压力测试： 超载，碰撞电梯壁
安全测试：
（1）进入电梯喊话，外面是否听到，拨打手机是否有信号； （2）停电（不会坠落。电梯门可以通过外力打开，紧急电话可用），报警装置（超载），通风状况； （3) 停靠位置，有人扒门（不会强制关门），若有异物阻碍，会停在当前楼层； (4) 监控装置
UI测试：标识的承重和人数，仅提供可到达楼层的按钮，美观程度，光滑程度、形状 6、可用性：按键高度、操作是否方便 7、稳定性：长时间运行情况，
HTTP 是一种不保存状态，即无状态（stateless）协议。HTTP 协议自身不对请求和响应之间的通信状态进行保存。也就是说在 HTTP 这个级别，协议对于发送过的请求或响应都不做持久化处理
基于Session实现的会话保持 在会话开始时（客户端第一次像服务器发送http请求），服务器将会话状态保存起来（本机内存或数据库中），然后分配一个会话标识（SessionId）给客户端，这个会话标识一般保存在客户端cookie中，以后每次浏览器发送http请求都会带上cookie中的SessionId到服务器，服务器拿到会话标识就可以把之前存储在服务器端的状态信息与会话联系起来，实现会话保持（如果遇到浏览器禁用cookie的情况，则可以通过url重写的方式将会话标识放在url的参数里，也可实现会话保持） 基于cookie实现的会话保持 基于cookie实现会话保持与上述基于Session实现会话保持的最主要区别是前者完全将会话状态信息存储在浏览器cookie中，这样一来每次浏览器发送HTTP请求的时候都会带上状态信息，因此也就可以实现状态保持。
两者优缺点 基于Session的会话保持优点是安全性较高，因为状态信息保存在服务器端。缺点是不便于服务器的水平扩展。大型网站的后台一般都不止一台服务器，可能几台甚至上百台，浏览器发送的HTTP请求一般要先通过负载均衡器才能到达具体的后台服务器，这就会导致每次HTTP请求可能落到不同的服务器上，比如说第一次HTTP请求落到server1上，第二次HTTP请求落到server2上。而Session默认是存储在服务器本机内存的，当多次请求落到不同的服务器上时，上述方案就不能实现会话保持了（常用解决方案是中间件，例如Redis，将Session的信信息存储在Redis中，这样每个server就都可以访问到）。 基于cookie的会话保持的优点是服务器不用保存状态信息，减轻服务端存储压力，也便于服务端做水平扩展。缺点是不够安全，因为状态信息是存储在客户端的，这意味着不能在会话中保存机密数据，另一个缺点是每次HTTP请求都需要发送额外的cookie到服务端，会消耗更多带宽。
1. 负载测试： 找到系统稳定时（或满足性能需求下）的最大吞吐量；（要有响应时间、成功率的限制，比如定义：99.9%的响应时间必需在1ms之内，平均响应时间在1ms以内，100%的请求成功） 2. 稳定性（通过浸泡测试soak test）： 以系统稳定时的最大吞吐量（或满足性能需求时的最大吞吐量），长时间对系统进行测试，已检查系统是否稳定 3. 压力测试： 找到系统极限值，系统瓶颈（系统崩溃临界值）（要求：响应时间可以变慢，但系统不能崩溃；）
测试人员关注（单次业务相关指标）： 并发用户数 响应时间：TP（百分比分布统计） 吞吐量：tps/qps 成功率 失败率
开发人员关注（系统层面指标）：
- Tomcat、数据库等；
- 容量：系统能承载的最大访问量是多少？系统最大的业务处理量是多少？
- 稳定性：是否支持7*24小时（一周）的业务访问？
运维人员关注（硬件资源相关指标 ）： 硬件资源消耗情况：CPU、内存、I/O读写速度、网络带宽等
横着一行为 32 个 bit，为四个字节。
4位版本号 指定 IP 协议的版本。对 IP v4 来说，为 4。 4位头部长度 标识该 IP 头部有多少个 32 bit (即多少行)，四位最大表示 15，所以 IP 头部最长为 60 字节。 -8位服务类型 包括一个三位的优先权字段(现在已忽略)四位的 TOS 字段和一位保留字段(保留需置 0 )。四位的 TOS 字段分别表示：最小延时，最大吞吐量，最高可靠性和最小费用。这四位中最多只有一位置 1。应用程序根据需要设置(比如 ssh 需要最小延时，ftp 需要最大吞吐量)。 16位总长度 是指整个 IP 数据报的长度，以字节为单位，因此 IP 数据报最大长度为 65536 字节。但由于MTU的限制，长度超过MTU的数据报都将被分片传输，所以实际传输的 IP 数据报的长度都远远没有达到最大值。 16位标识： 唯一地标识主机发送的每一个数据报。其初始值由系统随机生成，每发送一个数据报，其值就加一。该值在数据报分片时被复制到每个分片中，因此同一个数据报的所有分片都具有相同的标识符。 3位标志字段： 第一位保留。第二位标识禁止分片。设置后，IP 将不对该数据报分片，当该数据报长度超过 MTU 时，IP 模块将丢弃该数据包并返回一个 ICMP 差错报文。第三位表示更多分片。除了数据报的最后一个分片外，其他分片都要把该位置 1. 13位分片偏移 是分片相对原始 IP 数据报开始处(仅指数据部分)的偏移。实际的偏移值是该值左移三位(乘 8 )后得到的。因此，每个 IP 分片的数据部分的长度必须是 8 的整数倍。 8位生存时间 TTL (time to live)： 是数据报到达目的地之前允许经过的路由器跳数。发送端设置(通常是64)。数据报每经过一次路由，该值就被路由器减一， 为零时，路由器将丢弃该数据报，并向源端发送一个ICMP差错报文。TTL可以防止数据报陷入路由循环。 8位协议： 用来区分上层协议。/etc/protocols 文件定义了所有上层协议对应的字段的数值。例如，ICMP 是1，TCP 是6，UDP 是17。 16位头部校验和： 由发送端填充，接收端对其使用 CRC 算法检验头部在数据传输过程中是否损坏。 32位源端 IP 地址： 用来表示 IP 数据报的发送端 32位目的端 IP 地址： 用来表示 IP 数据报的接收端 选项字段： 是可变长的可选信息。最多包含 40 字节，可用的选项有： 1. 记录路由：将途径的路由器的ip地址填入选项部分，用于跟踪数据报的传递路径。 2. 时间戳：告诉每个路由器将数据报被转发的时间(或时间与IP地址对)填入IP头部的选项部分，这样就可以测量途径路由 之间数据报传输的时间。 3. 松散路由选择：指定路由IP地址列表，数据包发送过程必须经过其中所有路由器。 4. 严格路由选择：数据报只能经过被指定的路由器。
模糊查询（like，between，is null）： 模糊查询—LIKE
其中%是代表的有多个任意值，_代表一个任意值
数据查询-排序 ：
asc:升序（默认） desc:降序 默认id是升序排序
分组查询—GROUP BY： group by的常规用法是配合聚合函数，利用分组信息进行统计，常见的是配合max等聚合函数筛选数据后分析，以及配合having进行筛选后过滤。
测试计划是总体的安排。测试用例比较具体化的，针对性比较强。
在C++的类继承中，构造函数不能被继承（C11中可以被继承，但仅仅是写起来方便，不是真正的继承）
**建立对象时，**首先调用基类的构造函数，然后在调用下一个派生类的构造函数，依次类推； **析构对象时，**其顺序正好与构造相反；
继承时，构造函数和析构函数的调用顺序
- 先调用父类的构造函数，再初始化成员，最后调用自己的构造函数 2.先调用自己的析构函数，再析构成员，最后调用父类的析构函数 3.如果父类定义了有参数的构造函数，则自己也必须自定义带参数的构造函数 4.父类的构造函数必须是参数列表形式的
float和double型变量都是不精确的，所以不可以使用“”或“!=”来比较float变量与数字，应使用“>=”或“<=”的形式。比如float变量a在if语句写为if(a0.0)，则是错误的。
x=5 y=6 i=7
绝对路径:pwd 查看网卡端口号： netstat –lnp 列出所有端口 netstat -ntlp | grep 22 网络端口： 网络连接： 路由信息：route
通过重启路由、sfc修复命令、重装驱动、更换网络等方式修复均无果，只好启动很久以前安装在移动硬盘中的备用系统，结果发现在该系统下，网络正常。
git可以使用四种主要的协议来传输资料: 本地协议（Local），HTTP 协议，SSH（Secure Shell）协议及 git 协议。其中，本地协议由于目前大都是进行远程开发和共享代码所以一般不常用，而git协议由于缺乏授权机制且较难架设所以也不常用。
最常用的便是SSH和HTTP(S)协议。git关联远程仓库可以使用http协议或者ssh协议。
【特点/优缺点】 ssh： 一般使用22端口； 通过先在本地生成SSH密钥对再把公钥上传到服务器； 速度相较慢点 https： 一般使用443端口； 通过用户名/密码授权，可用性比较高； 速度相较快点 一般企业防火墙会打开80和443这两个http/https协议的端口，因此在架设了企业防火墙的时候使用http就可以很好的绕开安全限制使用git了，很方便；而对于ssh来说，企业防火墙很可能没打开22端口。
HTTPS利于匿名访问，适合开源项目，可以方便被别人克隆和读取(但没有push权限)； SSH不利于匿名访问，比较适合内部项目，只要配置了SSH公钥极可自由实现clone和push操作。
本文地址：http://mdekt.bhha.com.cn/quote/580.html 康宝晨资讯 http://mdekt.bhha.com.cn/ , 查看更多