1.1 黑盒测试框架笔记总结
仅仅只是根据产品需求来进行测试，这是远远不足的，需求是基础，但它不是全部。我们在进行测试的时候，每个人都应该有一个黑盒测试框架思想。做自己不知道如何测试一个产品的时候，自己就应该有测试原则。
1.1 常用测试用例设计方法
方法1：
（1）等价类划分：
1，取值范围值（1个有效等价类，2个无效等价类）
2，输入数据的个数（1个有效等价类，2个无效等价类）
3，输入必须遵守的规则（1个有效等价类和若干个无效等价类）
4，一组数据，不同数据的处理，只有一个能够构成有效值，其他都是为无效值
5，整型数，划分出整数/零/负数三个有效等价类，小数为无效类
例子：
（2）边界值分析方法
1，输入条件规定取值范围（边界上，处于边界内，外边上的测试值）
2，输入数据的个数（最小个数/最大个数/比最小个数多1少1/比最大个数多1少1）
3，输入数据有序集合结构（取第一个和最后一个元素）
边界值例子：
1，对i6-bit的整数而言32767和-32768是边界
2，屏幕上光标在最坐上/最右下位置
3，报表的第一行和最后一行
4，数组元素的第一个和最后一个
5，循环的第0次/第1次和倒数第2次/最后一次
注意：等价值划分方法和边界值划分法都是注重考虑输入条件，但是未考虑输入条件之间的联系，相互组合等。
（3）因果图
因果图方法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。
判定表的例子：
分别各处一个条件，然后A-B的条件产生的原因，如屌丝男个人情况与拜金女的动作
（4）正交实验设计方法
1，从大量实验数据中挑选适量的，有代表性的点，从而合理地安排测试的一种科学实验。类似的方法：聚类分析方法/因子方法等。
2，就是因子--影响因子的条件/外部因素
3，软件需求规格说明书中的功能要求进行
（5）功能图分析方法
1，方法1：基于一个状态的流程图和流转进行测试。如：产品的流程图；但我们要把流程图进行分析
2，方法2-语句覆盖（每个语句执行一次）；判定覆盖（真/假）；条件覆盖（多个条件组合而成的复合判定）；条件组合覆盖（设计足够的测试用例）
注意：在职业场所上，白盒测试很少出现的，主要分析的是代码，就如流程图就是代码显示，然后进行测试。
（6）错误推测方法
基于经验和直觉推测程序中所有存在的各种错误，从而有针对性的设计测试用例的方法。
1，程序中所有可能有的错误
2，容易发生错误的特殊情况
3，以前产品测试中曾经发现的错误
（7）需求文档转化法
1，所有的需求文档描述的文字信息，转化为用例
2，所有的示意图/流程图/状态图等信息，直接转化为测试用例
3，所有项目需求达到的口头共识，需求确认的邮件沟通信息，直接转化为测试用例
注意：需求文档和产品说明书是不同的概念，需求文档是产品说明的设计和理念，涉及更多的概念，包括正常的和异常等方法，而产品说明书只是主要的流程和场景。
需求文档是测试最基础的东西，必须要读透，读懂，然后测试齐全。
（8）随机测试法
随意测试，不考虑任何测试用例和需求，完全站在用户的角度对产品进行使用。
适合场景：
1，所有之前设定的用例已经执行完毕。
2，海量的条件组合无法一一遍历的时候
注意：所有的需求有可能测试不全，我们这时候就需要进行随机测试了。
（9）对象属性分析法
被测试系统中的元素定义为一个对象，并且给一个对象设定关联的相关属性和状态，并且将不同对象的属性和状态进行不同的组合，扩展测试用例。
例如：文件（属性：大小，路径{本地，网络}，文件名，文件编码，文件内容{文本，二进制}，文件类型，文件的读写属性，文件的共享属性）
1.2 如何沟通和获取足够的测试用例信息
（1）测试用例信息--完整的测试文档（不太适合现在快速开发和敏捷开发的方式），鼓励面对面交流，口头沟通，通过直接问的方式，了解清楚。
（2）进行口头沟通之前，我会先拿到所有的测试需求，然后做大脑上思考，有一个流程图，然后在纸质上写下功能点，方便进行测试。（其实直接写测试用例时间紧迫，可直接进行写一下测试功能点）
（3）在口头沟通之前，我们尽可能可以参与开发的会议，记录所有的要点。如果仅通过领导传达问题，这样会很容易丢掉很多沟通信息。
1.3 需求变更
（1）如果项目团队需求变更的时候，我们应该要做一下需求变更流程，可以建一个邮件组，做一个变更流程提醒，这样才会更好地推动自己对项目的影响力。
注意：建立了项目变更流程，这是面试简历很好的一个影响力。在公司里，提高自己的影响力上很重要的，领导注重得是你在项目中队项目的影响重要性。
（2）做法：
1，建立需求变更控制委员会控制需求变更的发生和频率
2，建立需求变更的通知的流程和机制，保证所有的项目相关人员及时准确的获取需求变更。
3，需求变更需要记录在案，将来作为项目跟踪和总结适用。
1.3.2 自动化测试
如果你要在正式环境下来进行自动化测试，这样会产生很多垃圾数据，会导致浪费成本；所以只能做测试环境下进行测试。
* 预言家的难题：
1，如何才能知道被测试软件确实完成了他应完成的任务？
2，被测软件是否输出了正确的结果？
3，在运行中是否会带来副作用；
* 擅长找到的问题：
1，程序崩溃
2，系统死机
3，程序挂起
4，突发异常
5，原有能用的功能出现问题
过度的依赖自动化测试会成为程序的最终成功带来隐患
1.3.3.4 测试概念理解
（1）测试的无穷特性
1，测试运行时的表现是否符合设计预期
2，用户为了某个功能而购买了软件，可是该软件是否实现了这个功能？
3，软件运行时，是否足够快，足够安全，足够稳定，等等。
解决以上问题的方式：在某个特定操作环境中运行该软件，并且模拟软件预期的使用方式来输入这些值。
问题：输入的内容太多，组合方式太多，可运行环境太多。
（2）测试的原则
1，把测试工作简化为先在所有输入（或者运行环境等）的全体集合中选择一个子集，然后在输入时使用选中的子集，最后通过推定认定是否这些输入已经足够多了
2，最终产品发布后，在进行测试已经无法提高已发布代码的质量了。
3，对于无限的测试，我们唯一的希望寄托于我们选择了正确的输入和其他测试决策。
4，随机测试不是好的测试方法，因为他缺乏必要的策略。
（3）局部探索式-
2.0 BUG的预防
2.0.1 web产品常见问题
（1）页面显示
* 产品的网页通常保证在1024*768的分辨率显示正常，常忽略800*600的分辨率
* 如果页面设计明确只考虑1024*768的需求，则只在1024*768下验证各个产品页面的显示正确无误。
预防：切好的设计页面和集成程序后的页面需要分别在两种显示分辨率下验证显示的正确性。
（2）浏览器兼容性
* 目前市场上的主要浏览器:IE6-IE11/chrome，360浏览器，firefox，sogou浏览器
* 通常情况下要保证IE6-11和firefox浏览器的兼容性，需要保证页面不变型，js执行均正常。
预防：设计组需要指定页面设计规范和js设计规范，保证主流浏览器的页面显示兼容性和js设计兼容性
（3）tab键的使用
* 页面中的tab翻页可以正常切换/支持tab按键切换要检验使用的正确性和合理性
预防：
* 需求设计过程中需要考虑tab键的使用合理性
* 程序设计或者页面设计出一个tab使用的通用原则和规范
（4）前进和后退的问题：
* IE有一个特性：就是允许前进和后退某一个页面，在某些特殊情况下，用户进行前进和后退，有可能造成数据不完整的提交，或者其他的问题。
预防：
* 制定一些标准的策略来处理IE的前进和后退操作，作为整个项目的共享，防止用户返回特定的数据提交页面和浏览页面，并进行重复操作。
* 项目经验：充值、
（5）页面提示语言、js提示语言、程序提示语言
* 通常情况下，产品人员不会将产品需求细化到某句话细化到某句话应该如何提示用户，所以不同的程序员会根据自己的语言特点来提示用户，这样会造成提示的语言风格完全不一样，造成产品友好度下降。
* 解决办法：产品人员和开发人员一起制定尽可能大而全的提示语言规范，并且座位规范说明提供给开发人员进行使用。
（6）语言文字提示（微软的标准）
* 全角字符和半角字符都要使用一个空格分开
* 英文和数字智鉴要有空格分开
* 汉字和英文、数字要有空格分开
* 语言中不要混用全角和半角标点
* 在语言中，永远不要用“你”这个字，应该用“您”，要做一些操作步骤描述，要多用“请”字
（7）文字缩略和折行：
* 输入框提交很长的字符，并且不折行，则提交数据后，有可能会把页面的拉的非常长。
* 如果要将文字后面的一些文字处理为省略号的时候，需要注意不要将中文截成半个字符。
预防方法：
* 提交公共处理字符的程序，解决上述问题，来进行公用。
（8）图片的显示和链接：
* 图片是否增加链接通常会被开发人员忽略掉
* 图片的显示位置通常会显示不同像素大小和比例的图，所以需要明确定义大图片如何缩减成为小图片的策略，及小图片如何拉伸显示为大的图片
解决办法：
* 提供的需求中明确图片是否需要链接以及链接的位置
* 需求中明确图片显示策略，是等比缩放显示，还是原大小显示，还是自适应显示，并且制定相应策略的统一处理模块
（9）输入判断问题：
* 所有键盘输入的特殊字符，均可以正常保存
* 需要特别处理英文单引号、英文双引号等引起程序错误的问题【崩溃】
* 需要处理“<”、“/”、“\”等容易保存出错的字符
预防方法：
* 开发公共处理特殊字符的模块，在系统中进行规范应用
* 数字框只能输入数字的内容
* 日期框需要判断日期是否合法
* 文本框需要判断字段长是否限制了
* 对于空格的处理，如果系统想trim掉字符串最开头和最后的空格，则需要整个系统都使用此策略，否则会造成传递不一致的问题
* 需要前台页面使用js来判断输入的合法性，同时后台逻辑也要添加判断输入合法性的判断
（10）多个IE同时访问的情况：
* 用户可能打开不同的IE使用相同的用户登录后进行操作，程序处理的时候要考虑到数据的一致性和同步问题
* 多个IE使用不同用户，则cookie操作不会出现用户信息混乱的问题
（11）安全考虑
* 在URL中不要带有明文的用户信息；写代码的时候，不要把密码等敏感的用户信息铭文的显示在url中
* 即使要传递密码参数也不要使用pwd、passpord这样的参数名称来进行传递，防止被截获
【注意：有一些东西是不需要缓存的，特别是用户名、密码等；有空可以多看看缓存有什么】
* 要在传递参数的操作中使用NoCache参数，防止将url参数进行缓存
预防方法：
* 简历标准的数据传输和命名规范，并制定一些网页开发模版或规范供参考
（12）防止sql注入
* 不要把数据库或者程序的任何报错信息显示在页面上
* 最好程序能够将select update delete这些关键字都过滤掉，不让用户提交包含这些数据的信息
* 数据库中设计到操作权限的表名和字段名用很通俗易懂的名字
* 输入框尽量过滤掉“<>”这样的字符，防止javascript攻击
预防方法：
* 出错的时候使用错误处理页面，建立标准的过滤关键字段程序，统一数据库设计命名规范，建立防js攻击的标准函数
（13）关于cookie：
* cookie没有设定过期时间
* IE不支持cookie的时间没有任何提示信息
* cookie中的敏感信息没有进行加密
预防方法：
* 明确cookie生存期，并对生成的cookie进行检查，建立标准的检查浏览器对cookie支持的程序函数
（14）各种资源连接的释放
* 有的时候，系统莫名访问不了，则有可能是数据库连接没有释放
* 压力测试的时候，连接释放如果效率不高，则有可能出现大量连接超时失败
预防方法：
* 系统资源的释放过程，最好通过代码review的方式来互相监督
（15）关于keepalive的设置：
* 如果需要在一个连接同时获取多个资源，则需要打开apache或者resin的keepalive参数为On，来提高系统的处理能力，减少多次建立连接所消耗的资源。如果大量的处理只是一次性连接，则不要打开keepalive设置
* 在实际工作中，需要将keeplive分别设置On或者off来验证哪个设置的性能更好
（16）系统上线的log配置：
* 上线以后，要关闭无用大量调试log信息
* 不要打开过多的log
预防方法：系统管理员对所有打开log级别进行确定，并群发相关人员
（17）用户易用性：
* 用户删除某个数据前，要明确提示用户是否要删除，默认把焦点选择为“否”
（18）平台产品常见问题
* 文档：程序实现和接口文档描述不一致
预防方法：leader定期对接口进行审核，保证文档、需求变更和程序实现保持一致
* 多表操作：详细设计文档缺失，接口对多表进行操作时候，经常会发生有些表的数据没有被更新的情况
预防方法：审核设计文档是否覆盖必要的逻辑，加强codereview
* 参数的容错处理：接口没有对参数进行必要的容错，参数出现错误的时候，接口也没有做相应的错误处理，文档也没有描述容错机制。
预防方法：明确每个接口对哪些情况进行必要的容错，并写到设计文档中，由leader进行文档审核
BUG预防总结：分析问题--找到具体原因--解决问题--总结问题--建立预防方法--规范流程和制度--监督执行
1.3 探索性测试--看笔记【1.2 探索性测试【原老笔记-观后感】】
1.4 实战的例子
例子：QQ传文件的例子，你希望QQ传文件具有什么样的功能，想更多的测试要点。（这题主要是考虑测试人员的发散思想能力）
QQ是一个用户，传是一个动作（离线，在线，手机，网络传），文件（二进制，本地，网咯，文件所属权限，文件的编码方法，），文件传给谁（一个人，多个人，是好友，非好友，黑名单），传入的时候加入黑名单
元素
1，文件类型（exe文件，二进制）
2，状态（是否打开）
3，速度
4，文件大小，文件是否被占用；文件是本地文件还是网络存储文件；文件能否正常读取/复制；3D文件；音频文件；镜像文件；视频；文本；源代码文件；图片；执行程序；压缩文件；不同类型传输；文件名长度；
5，文件数量
6，发送对象（一个人/多个人/陌生人/黑名单）
7，机器硬件：系统切换为英文/中文方式
8，时间
9，软件不同版本之间传送（不同QQ版本/手机端/PC端）
10，在线，离线，发送文件中网络中断，网络状态（本地网络/外部网络）
11，群文件
12，一对一，多对一
13，传输过程中的打断（断网，断电，拒收，取消）
14，传送过程中删除源文件
15，不同协议
16，界面
17，兼容性：操作系统，不同尺寸
18，防火墙
19，盘符
20，冲突（QQ/MSN/飞信）
21，本地缓存
22，传文件时与其他模块的并发操作，传送过程中，网络断开；传输文件的默认编码
23，文件从服务器的回复测试
24，对方状态（在线，不在线）,对方接收文件
25，传送提示，
26，断点续传
27，文件能否被正常读取/复制
28，
- 上一篇：Android--雷达扫描动态界面
- 下一篇：关于新浪微博里面长图加载功能的一点窥探
相关文章
图文推荐
- 文章
- 推荐
- 热门新闻