测试用例的设计思考
毕业后的第一家公司个人认为除了加班巨多还是很不错的，我认为前司对于测试的流程和规范是非常棒的，对于测试用例的设计和评审都会有较高的要求。在前司的一年确实学到很多和测试流程和测试设计相关的知识。以下为自己的经验之谈，就是在一个模块到我手里的时候，如果是我来负责测试设计，我会从以哪些方面考虑。之前的部门是嵌入式产品，所以并不是所有行业所有模块都通用哈，只是提供一个基本的框架，思路，当然很多模块都可以从以下几点切入，思考。
1.兼容性：
浏览器： 需要产品或者需求侧明确给出要支持哪些浏览器，常见的浏览器要覆盖哪些，如 chrome，firefox，360极速等
操作系统：需要支持哪些操作系统使用以及最佳分辨率或者兜底的分辨率使用是正常的，若是支持WIN7,WIN10操作系统使用，如果用户的是WIN7系统比较旧，需要明确用户需要装哪些补丁。或者干脆不支持。
移动端：支持哪些平台，ios android ，适配哪些主流手机和 不同的os版本等。
2.前端UI
字符：输入框不支持的特殊字符或者非法字符有哪些，还是说所有字符都允许
空格：是否有对空格做校验，包括行首，行末，行中做校验和处理，如果有那么处理的策略是怎么样的
边界值：输入支持多少个字节的输入 不输入 或者超过边界值是否做了处理 是否有对应的提示
提交： 涉及到提交的，是否有对提交次数做限制，比如说我快速点击2次，是否真的提交了2次
函数： 是否都对要求的浏览器做了处理，相关按钮，动画在不同的浏览器是否都可以正常点击。（之前遇到过一个问题，就是一些按钮在IE上无法点击。）
最大值： 若涉及到一些配置条数，比如说支持多少条IP的配置，也要确认边界值，以及最大条数时候对性能带来的影响，应该在评审时候评估出来
3.功能性
即模块的主要功能保证
首先明确该模块的产生背景，该模块作用的技术细节，是在什么条件下会使用该模块，支持的部署模式有哪些。是否会和第三方的设备或者平台对接。使用该模块的角色权限。
模块是否有所需要的的库或者资源。 模块在新老设备上是否都可用。模块是适用于什么架构的设备是X86 还是ARM，小性能机器还是大性能机器。
需要我们了解模块的前前后后需求背景，技术实现之后，才在这之上设计相关的用例。
4.性能性
响应：页面的响应时间应该在多少ms之内，最多不超过多少ms
性能：设备支持的最大性能，比如说设备最大多少的吞吐和转发不丢包，一些性能指标我们应该明确清楚
内存：设备上新增了功能模块，那么这个模块启用时候占用的内存区间是多少，若是占用太高不释放，是否会对别的模块使用内存造成影响
5.稳定性&&6.可靠性
设备可以稳定运行多久，稳定性测试，在半个月或者一个月或者更久之内，设备上的相关服务进程的id没变，句柄数，总体保持稳定，模块功能始终生效正常使用
设备是否抗摔，设备上相关的模块，若涉及到插卡的这种是否不容易松动或者掉落，对应的指示灯是否都正常运行（物理层面的）
网络方面：丢包 ，延时，抖动，模块的通信质量是否都符合预期，让人不会感到明显的停顿
7.安全性
是否对特殊字符做限制，是否有做防止SQL注入（一般是代码方面做检验，现在ORM框架应该都会有处理方法）
用户设立密码是否有简单密码校验或者不允许简单密码机制，包括连续的数字，以及和用户名高度重合，是否必须要包含字母，数字以及最短多少位的限制
是否做了防暴破机制，用户一直登录失败，密码错误，有账号冻结限制或者给用户安全提示
（这块我接触的不多，安全测试或者渗透测试应该是有专员负责才对。不是很懂这块，允悲）
8.运维性
配置：配置是否有做备份策略，比如当前设备的配置是可以允许导出以及再导入恢复配置的。 配置是否有做兜底策略，若当前页面的配置丢失，当前页面是否能打开只是没内容还是直接加载配置报错，涉及到底层的配置，若客户的配置挂掉了。
设备的linux驱动里是否会延续上一次的配置或者是兜底配置，还是干脆模块就失效，不可用了。
日志：操作该设备的人的账号权限，角色，操作日期，进行的操作是否有明确记录。
用户操作了哪些模块或者改动了哪些配置，是否有暴露后门方便技服有专门的深层日志查看
日志是否在设备上有做定时清理策略。日志写入的路径是否正确。
升级： 用户升级设备时候，若涉及到重启设备生效，那么设备的升级时间以及重启时间在多久之内，可以接受
在升级设备或者相关的配置或库的时候，若不幸升级失败，是否可以回滚到上一个版本，让设备继续保持可用状态
9.易用性
提示： 提示的文案是否合理，是否会给客户带来歧义，是否有错别字
配置： 涉及到让客户配置的页面，比如说网络相关的配置，是否点进来这个页面有默认配置好的值还是纯客户手动一个个配（因需求而异）
操作： 操作是否关联的页面tab比较多，尽量让为同一模块服务的配置在一个页面或者在一个大的tab里