在软件测试中web功能测试是很常见的，相较于性能测试，web功能测试难度还是比较小的，通俗来说web测试就是web网站的测试，基于BS架构的软件产品的测试，那么web功能测试具体包括哪几方面呢？
1.链接测试，在这方面主要考虑所有链接页面是否存在，所有链接是否按指示的那样确实链接到了该链接的页面，还要测试web应用系统上没有孤立的页面。
2.表单测试，表单一般指在界面进行和数据提交操作的，包括新增和修改数据，它具体还要涉及到输入框测试，下拉框测试，图片，视频，Excel，TXT等文件上传测试，表单提交按钮测试等。
3.搜索测试，搜索条件一般为2种情况：输入框、下拉框。对于多个条件的页面搜索可以按照下面的编号顺序去进行测试。
4.删除测试，删除时要测试具体删除条件，例如没选择数据进行删除时界面是否会有提示，选择一条数据与多条数据时有什么不同提示。
5.cookies/session测试 cookies/session通常用来存储用户信息，cookie通过在客户端记录信息确定用户身份，session通过在服务器端记录信息确定用户身份。
6.数据库测试，在web应用技术中，我们在进行功能测试的任何操作都可以归溯到是对于数据库的增删改查。 所以数据库测试实际就是通过前面讲过的测试手段来完成、只不过关注点是数据库表及表字段值的变化。

近期负责运维研发的工作，前段时间研究了一下WebSocket和Linux下伪终端的功能，主要目的是一直在思考，如何实现WebConsole功能，让公司的同事能够基于浏览器能够安全的登录到公司的服务器，并与公司的安全体系一起，实现权限可管理的、安全性有保证的Web端的shell的功能。


WebConsole简介

理论上来说应该叫做WebShell，它是一种以网页形势存在的一种命令执行环境，也可以成为一种网页后门。

WebShell因为简单易用，所以一方面常常用于服务器管理，可以方便管理员、站长甚至于程序员方便的登录到服务器，进行必要的操作和维护，但是另外一方面它常常容易被入侵者利用，从而达到控制服务器的目的。

目前常用的WebShell有Gateone、WebSSH2、shellinabox等等，产品很多。

如何实现伪终端

伪终端的实现原理，可以参考 Linux伪终端一文，在该文中进行了详细的原理和代码讲解。这里我们也简要描述一下：

实现步骤：

open /dev/ptmx
	
生成ptsname：调用ioctl(fd, syscall.TIOCGPTN, &n)，这里会得到当前终端编号，终端名格式为：/dev/pts/?
	
清除slave PTY lock：调用ioctl(f.Fd(), syscall.TIOCSPTLCK, &u)
	
启动/bin/bash进程，并把进程的输入输出绑定到伪终端中
这样/bin/bash进程的输入和输出，都在PTS上进行， 而前文我们分析过，PTS与PTM形成了一种双向管道的模式。

 

    PTM输出  --->  PTS输入
    PTS输出  --->  PTM输入


WebSocket实现WebConsole

WebSocket是很通用的技术，这里就不做过多的描述，可以参考一下WebSocket Helloworld!这篇文章。

有了前面的铺垫，我们很容易基于WebSocket来实现WebConsole了，具体的架构图如下所示：

 



webconsole.png

在浏览器端，需要嵌入xterm.js插件，实现对终端的输入输出支持能力，通过Websocket连接到后端服务后，在服务端把连接升级为WebSocket连接，并创建一个终端管理模型与一个/bin/bash进程

把终端管理模型的PTY Slave端的输入输出绑定到/bin/bash的输入输出中
	
把WebSocket连接的输入输出与PTY Master的输出输入绑定
这样一个WebConsole的雏形就完成了。

实现安全可靠的WebConsole

从web上访问shell功能，如何授权，并且保证系统安全性是一个需要深入考虑的问题。像上面那样，仅仅通过http提供服务支持，系统无法保证安全性。所以要做以下几个方面的考虑：

认证 ： 基于公司的登录体系
	
授权 ： 基于授权开通用户的服务器
	
网络安全： 基于公司内网体系/内部防火墙
	
审计：通过日志记录登录用户执行的所有命令
具体细节设计到一些公司安全方面的事宜，这里不便深入分析，有兴趣的朋友可以按照以上思路自己去实现。

今天主要介绍H5的web push:H5的Notification主要用于向用户展示通知而web push 主要用于订阅推送消息。

h5的Notification

关于h5的Notification已经不是什么新的技术，但是最新chrome浏览器也是只有在https协议下面才有效。下面简单介绍一下Notification

语法

let myNotification = new Notification(title, options);

参数

一、title

定义一个通知的标题，当它被触发时，它将显示在通知窗口的顶部。

二、options 可选 options对象包含应用于通知的任何自定义设置选项。选项有：

dir: 显示通知的方向。默认是auto，跟随浏览器语言设置行为，你也可以通过设置ltr和rtl的值来覆盖该行为（虽然大多数浏览器似乎忽略这些设置）
lang: 通知的语言，如使用代表一个BCP 47语言标签的  DOMString 指定的。请参阅Sitepoint ISO 2字母语言代码页面，以获得简单的参考。
badge: 一个 USVString 包含用于表示通知的图像的URL, 当没有足够的空间来显示通知本身时。
body: 一个 DOMString 表示通知的正文，将显示在标题下方。
tag:  一个 DOMString 代表通知的 一个识别标签。
icon:  一个 USVString 包含要在通知中显示的图标的URL。
image: 一个 USVSTring包含要在通知中显示的图像的URL。
data: 您想要与通知相关联的任意数据。这可以是任何数据类型。
vibrate: 一个振动模式 vibration pattern 设备的振动硬件在通知触发时发出。
renotify: 一个 Boolean 指定在新通知替换旧通知后是否应通知用户。默认值为false，这意味着它们不会被通知。
requireInteraction: 表示通知应保持有效，直到用户点击或关闭它，而不是自动关闭。默认值为false。


以下选项列在最新规范中，但是目前浏览器可能尚未支持，大家可以随时尝试！

silent: 一个 Boolean 指明通知是否应该是无声的,即,不需要发出声音或振动，无论设备设置如何。默认值为false，这意味着它不会保持静默。
sound:一个 USVString 包含通知触发时要播放的音频文件的URL。
noscreen: 一个 Boolean 指定通知触发是否应启用设备的屏幕。 默认值为false，这意味着它将启用屏幕。
sticky: 一个 Boolean 指明通知是否应该是“粘”, 即不易被用户清理。默认值为false，这意味着它不会粘。


案例

function spawnNotification(theBody,theIcon,theTitle) {
  var options = {
      body: theBody,
      icon: theIcon
  }
  var n = new Notification(theTitle,options);
}


web push

用户订阅了一个站点的 Web Push 服务后，即使用户关闭了浏览器，一旦站点主动发送推送消息，用户都能收到，只要你的电脑是开着的。这是目前谷歌和苹果在 Chrome 和 Safari 上都力推的一种全新推送服务，Firefox最近也加入了这个阵营。

web push 优点

一、可以完美替代原来的Email订阅服务，因为 Email 订阅这个动作要用户主动发起，不管你在页面内放了多显眼的订阅标志，都得用户去主动点击，填写自己 Email 地址才行。而且，如果不使用邮件客户端，很多订阅的 Email 发出去犹如石沉大海，到达率很低。

Web Push 完全由浏览器开发商的标准协议发起，一旦用户访问开通了 Web Push 的站点 ，浏览器就会主动询问你是否要订阅，弹出的订阅框也都是浏览器开发者的标准规范。首先，它增加了用户订阅的可能性。

二，一旦用户点阅，只要你打开电脑，就会收到推送通知，没有邮件订阅时用户主动去查收邮件的问题，大大增加了订阅推送到达率。

三，Web Push 让站点为主，APP 为辅的网站可以摆脱 APP 安装量少的困扰，访问你站点的人，只有一小部分会安装你的 APP，而Web Push 不需要安装任何 APP 在电脑上，只要用户点击一次Allow来订阅消息即可。

web push 国内使用少的原因

1、Web Push 使用了 GCM 服务，而 GCM 在国内基本上很难连通，国内用户除非翻了，否则压根不可能订阅成功 Chrome 的 Web Push。
 
2、谷歌要求 Chrome 的 Web Push 必须用 https 加密传输，国内目前很多网站还在使用http协议。


所以目前国内web push 使用较少。

web push 流程

1、客户端完成请求订阅一个用户的逻辑
2、服务端调用遵从web push协议的接口，传送消息推送（push message）到推送服务器（该服务器由浏览器决定，开发者所能做的只有控制发送的数据）
3、推送服务器将该消息推送至对应的浏览器，用户收到该推送


web push实现细节

首先注册一个Service Worker，若注册成功，返回的Promise为resolve状态，如下：

function registerServiceWorker() {
  return navigator.serviceWorker.register('service-worker.js')
  .then(function(registration) {
    console.log('Service worker successfully registered.');
    return registration;
  })
  .catch(function(err) {
    console.error('Unable to register service worker.', err);
  });
}


关于Service Worker，我之前文章有提及，但是没有关于这方面的详细文章，大家可以自行网上搜索。

随后测试window环境下是否有Notification对象，测试成功，调用Notification.requestPermission请求用户授权发送推送，若授权成功，将会返回'granted'。

接下来要做的就是使用注册好的Service Worker对象，调用pushManager.subscribe方法，从客户端获得刚刚所说的PushScription对象。

function subscribeUserToPush() {
  return navigator.serviceWorker.register('service-worker.js')
  .then(function(registration) {
    const subscribeOptions = {
      userVisibleOnly: true,
      applicationServerKey: urlBase64ToUint8Array(
        'BEl62iUYgUivxIkv69yViEuiBIa-Ib9-SkvMeAtA3LFgDzkrxZJjSgSnfckjBJuBkr3qBUYIHBQFLXYp5Nksh8U'
      )
    };
 
    return registration.pushManager.subscribe(subscribeOptions);
  })
  .then(function(pushSubscription) {
    console.log('Received PushSubscription: ', JSON.stringify(pushSubscription));
    return pushSubscription;
  });
}


解释：

1、userVisibleOnly是为了保证推送对用户可见，

2、application server key则如前文所说，是推送服务器用以识别应用服务器的密钥，这里的密钥包含了公钥和私钥，传输的是公钥。

3、PushScription的endpoint也是在这个过程中生成的，生成公钥和私钥可以使用web-push库。

这里再次说明一下推送服务器的不可选择性，在调用subscribe生成PushScription时，浏览器会向它指定的中转服务器发送请求来生成endpoint和其余部分，这是没法控制的。

4、PushScription中的auth和p256dh是用来控制带载荷的push message的。

获取到PushScription对象后，将其发往应用服务器，此处简化了存储，使用nedb存下PushScription并返回Promise：

function saveSubscriptionToDatabase(subscription) {
  return new Promise(function(resolve, reject) {
    db.insert(subscription, function(err, newDoc) {
      if (err) {
        reject(err);
        return;
      }
      resolve(newDoc._id);
    });
  });
};


存储完毕后，接下来就是开发后台管理逻辑，使得管理员能够触发向用户推送消息的事件，应用服务器所做的逻辑就是遍历在数据库中存储的所有PushScription并推送消息，以下是使用web-push库完成配置密钥及联系邮箱的示例：

web-push请参见github: https://github.com/web-push-libs/web-push

const vapidKeys = {
  publicKey:
'BEl62iUYgUivxIkv69yViEuiBIa-Ib9-SkvMeAtA3LFgDzkrxZJjSgSnfckjBJuBkr3qBUYIHBQFLXYp5Nksh8U',
  privateKey: 'UUxI4O8-FbRouAevSmBQ6o18hgE4nSG3qwvJTfKc-ls'
};
 
webpush.setVapidDetails(
  'mailto:web-push-book@haorooms.com',
  vapidKeys.publicKey,
  vapidKeys.privateKey
);


不要忘了配置你在谷歌云服务（例如FCM）申请到的GCMApiKey:

webpush.setGCMAPIKey('<Your GCM API Key Here>');

配置完成后，就可以将subscription发送出去，使用web-push的sendNotification接口：

webpush.sendNotification(pushSubscription, 'Your Push Payload Text');

参考

NotificationAPI : https://developer.mozilla.org/en-US/docs/Web/API/notification/Notification

Push API : https://developer.mozilla.org/en-US/docs/Web/API/Push_API

Push API（Working Draft）: https://www.w3.org/TR/push-api/

Web Push Protocol（Internet Draft）: https://tools.ietf.org/html/draft-ietf-webpush-protocol-12

Notification（Recommendation）: https://www.w3.org/TR/notifications/

     
1.单个逻辑功能


　　对于单个逻辑功能，测试工程师需要关注其是否正确实现了需求定义，并需明确该需求是否确实应该在需求中体现。
　　a:编辑框 b:按钮 c:图片/音频/视频 d:下拉框 e:单选按钮 f:复选框 g:Flash插件


　　2.链接测试


　　链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。


　　3.表单测试


　　当用户通过表单提交信息的时候，都希望表单能正常工作。如果使用表单来进行在线注册，要确保提交按钮能正常工作，当注册完成后应返回注册成功的消息。如果使用表单收集配送信息，应确保程序能够正确处理这些数据，最后能让顾客收到包裹。要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。


　　当用户使用表单进行用户注册、登陆、信息提交等操作时，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。


　　4.页面缓存功能


　　根据web系统的体系构架不同，在系统开发过程中可能采用Cookie、Session、Cache等方法来优化、处理数据信息。


　　a:cookie


　　当用户访问一个web系统，服务器为了在下一次用户访问时，判断该用户是否为合法用户、是否需要重新登录、或者希望客户端记录某些数据信息时，服务器可以根据业务的需求设定并发送给客户端浏览器。cookie一般是以某种具体的数据格式记录在客户端的硬盘中。


　　通常情况下，cookie可记录用户的登录状态，服务器可保留用户信息，在下一次访问时无须重新登录，对于购物类的网站，也可利用Cookie实现购物车功能。进行Cookie测试时需要关注cookie的信息的正确性，当用户主动删除cookie信息，在访问时，验证能否无须重新登录。点击商务网站可添加商品信息后删除Cookie，刷新后查看购物车中的商品是否成功清除。


　　b:Session


　　Session一般理解为对话，在web系统中表示一个访问者从发出第一个请求到最后离开服务，这个过程维持的通信对话时间。Seesion除了表示时间外，还可能根据实际的应用范围包含用户信息和服务器信息。当某个用户访问web系统时，服务器将在服务器为该用户生成一个session，并将相关数据记录在内存中，某个周期后，如果用户未作任何操作，则服务器将释放该session，简单而言，session信息一般记录在服务器的内存中，与Cookie不同。测试过程中需关注Session的实效时间。


　　c:Cache


　　Web系统将用户或系统经常访问或使用的数据信息存放客户端Cache（缓存）或服务器端Cache中，以此提高响应速度。与Cookie和Session不同，Cache是服务器提供的响应数据，只是存放在客户端或服务器端。用户发出请求后，首先根据请求内容从本地读取，如果本地存在所需要的数据，则直接加载，减轻服务器的压力，若本地不存在相关数据，则从服务器中的Cache中查询，若还不存在，则进行进一步的请求相应操作。很多时候服务器用Cache提高访问速度，优化系统性能。在web系统前端性能测试时，需关注Cache对测试结果的影响。


　　5.脚本功能实现


　　为了实现一些特殊的效果或功能，系统往往会使用JavaScript、VBSScript脚本编程技术。


　　6.文件上传下载


　　在测试时需要考虑文件上传格式、上传内容、上传能否正确打开、上传过程中如果出现异常是否有提示信息。对于文件下载则需要考虑的文件能否正确打开使用、下载过程能否中断，中断是否能续传，下载保存的文件是否正确等。


　　7.数据库测试


　　当用户通过表单提交信息的时候，都希望表单能正常工作。


　　如果使用表单来进行在线注册，要确保提交按钮能正常工作，当注册完成后应返回注册成功的消息。如果使用表单收集配送信息，应确保程序能够正确处理这些数据，最后能让顾客收到包裹。要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。


　　当用户使用表单进行用户注册、登陆、信息提交等操作时，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。


　　web兼容性测试


　　web系统通常体现在客户端的兼容性，服务器一般不做兼容性测试，因为在设计开发过程中即确定了了服务器的架构。


　　1：浏览器兼容性


　　主流浏览器：IE，FireFox、Chrome、Safari等，浏览器的差异主要体现在javaScript、ActiveX和HTML解码方法处理不同，因此需要在web系统测试时注意，尤其是通过某个控件跳转浏览器时更需要注意。


　　2：系统兼容


　　主要的操作系统  window
 XP ，windows 7、windows 8，mac系统。在测试过程中需要关注被测试对象在不同操作系统上的表现、尤其是有数据交互时。


　　3：显示分辨率


　　不同的显示分辨率可能会导致web页面变形，严重时会导致功能无法使用，因此需要测试在不同分辨率下的系统表现。常见的分辨率：1280X1024、1024X768、800X600等，即使在某些分辨率下不能工作，也需要给出提示信息。


　　4：插件兼容


　　在web系统应用了一些控件，如文本编辑器，文件上传下载，这些控件也需要考虑在不同的操作系统，不同的分辨率下的应用表现。


(本文转载自网络，感谢原文作者,如有版权问题请及时留言,我会第一时间处理)