1. 你真的懂测试吗
1)你在学校里学过测试吗？
2)如果不懂得有效地进行测试，你不仅得不到功劳，也没人欣赏你的苦劳，你拥有最多的将只是疲劳。
3)职业软件工程师应当掌握需求开发、系统设计、编程、测试、维护所有技能。
2. 测试的目的是什么
1)测试的目的是为了发现尽可能多的缺陷，不是为了说明软件中没有缺陷。
2)推论：成功的测试在于发现了迄今尚未发现的缺陷。所以测试人员的职责是设计这样的测试用例，它能有效地揭示潜伏在软件里的缺陷。
3. 一些常识和经验之谈
1)测试能提高软件的质量，但是提高质量不能依赖测试。
2)测试只能证明缺陷存在，不能证明缺陷不存在。
3)测试主要困难是不知道如何进行有效地测试，也不知道什么时候可以放心地结束测试。
4)每个开发人员应当测试自己的程序（份内之事），但是不能作为该程序已经通过测试的依据。
5)80-20原则：80％的缺陷聚集在20％的模块中，经常出错的模块改错后还会经常出错。
6)测试应当循序渐进，不要企图一次性干完，注意“欲速则不达”。
测试的分类
1. 测试阶段
1)单元测试：又称为模块测试，是针对软件设计的最小单位程序模块，进行正确性检验的测试工作。由开发小组执行。
2)集成测试：也叫组装测试或联合测试，即对由模块组装起来所形成的软件系统进行正确性检验的测试工作。由开发小组执行。
3)系统测试：为了验证设计实现的输出是否符合需求而做的测试工作。由专职测试工程师完成。
4)升级测试：针对日常用户提出新增功能需求、改进效率、优化需求或软件BUG等所作软件产品修改情况而进行测试的工作。由专职测试工程师完成。
2. 测试方式
1)白盒测试：关心软件内部设计和程序实现，测试依据是设计文档。
2)黑盒测试：不关心软件内部，只关心输入输出，测试依据是需求文档。
3. 测试错误类型分类
|
错误类型 |
出现情况 |
|
A错误 |
引起程序异常中断或死机的错误等 |
|
B错误 |
业务功能实现错误、程序执行结果错误、程序无法正常运行、性能未能达到规定要求、界面设计不符合本系统的界面设计规范等 |
|
C缺陷 |
功能操作不方便、缺少操作提示、缺少错误捕捉、提示信息是英文、提示信息表达不清楚让人难以理解等 |
|
D建议 |
为程序更完善，测试工程师和开发人员提出的建议 |
测试规范
1.
测试流程
2. 测试内容
|
测试阶段 |
主要依据 |
测试人员、测试方式 |
主要测试内容 |
|
单元测试
|
详细设计 |
由开发小组执行白盒 |
接口测试、路径测试
|
|
集成测试 |
系统设计文档 |
由开发小组执行白盒测试和黑盒测试 |
接口测试、路径测试 功能测试、性能测试
|
|
系统测试 |
需求文档 |
由测试小组执行黑盒测试 |
功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/测试 、防病毒测试 |
|
β测试 |
需求文档 |
由用户执行黑盒测试 | |
|
升级测试 |
产品升级单 |
先编码工程师白盒测试和黑盒测试 ，后测试工程师黑盒测试 |
涉及修改的功能测试，针对客户端产品必须进行注册、升级、多种环境的测试 |
3. 测试准则
测试执行准则：
同时满足以下条件，允许开始测试：
（1）测试计划已经制定并且通过了审批
（2）测试用例已经设计并且通过了审批
（3）被测试对象已经开发完毕并等待测试
测试完成准则：
基于全部测试用例覆盖基础上，最终遗留问题符合要求（如：A类问题<0，B类问题<=2，C类问题<=4，D类问题<=8），且不影响用户的正常使用情况下结束测试。
测试文档模板：
（1）测试计划模板
（2）测试用例模板
（3）测试分析报告模板
4. 测试计划模板
|
测试计划的类别 |
递交时间 |
责任人 |
审批者 |
|
单元测试测试计划（与开发计划合并） |
在详细设计阶段可以起草，最迟在实现阶段之初递交 |
项目经理 |
架构设计师 |
|
集成测试测试计划 |
在设计阶段可以起草，最迟在实现阶段之初递交 |
项目经理 |
架构设计师 |
|
系统测试测试计划 |
在概要设计阶段可以起草，最迟在实现阶段递交 |
测试策划师 |
部门经理 |
|
升级测试 |
根据承诺升级完成时间 |
架构设计师 |
|
一、测试对象
二、测试总体起止时间
三、测试策略
四、测试环境
（一）测试环境列表
（二）测试网络环境
五、测试特性分析
（一）某子系统或（功能测试）
（二） 某子系统或（性能测试）
（三） 某子系统或（安装测试）
六、测试安排
（一）测试人员
（二）测试进度
七、风险分析
八、测试通过准则
九、交付的文档
5. 测试用例模板
|
测试用例的类别 |
递交时间 |
责任人 |
审批者 |
|
集成测试测试用例 |
最迟在单元测试开始之初递交 |
项目经理 |
测试策划师 |
|
系统测试测试用例 |
最迟在集成测试开始之初递交 |
测试策划师 |
总体组 |
|
升级测试用例（简单设计） |
升级代码修改完成前 |
测试工程师 |
架构师 |
一、 测试项结构图
二、测试用例描述
（一）某个测试项
|
子系统名称 |
|
业务功能概述 |
|
|
序号 |
输入（操作）说明 |
输出说明（预期结果） |
测试情况 |
|
|
|
|
|
6. 测试分析报告模板
一、引言
（一）编写目的
（二）项目背景
（三）定义
（四）参考资料
二、测试执行情况
（一）测试项目
（二）测试机构和人员
（三）进度计划与实际差异
（四）测试结果
三、软件需求测试结论
四、评价
（一）软件能力
（二）缺陷和限制
（三）建议
（四）测试结论
五、附件
（一）测试问题统计表
（二）测试遗留问题统计表
测试的组织1. 自我测试不具有说明力
开发人员应当测试自己的程序，这是他分内的工作。但是开发人员在测试自己的程序时，很难做到客观、公正，所以自我测试不具有说服力。
2. 避免开发人员与测试人员产生矛盾
开发人员的注意事项：
不要敌视测试人员。要理解测试的目的就是发现缺陷，是测试人员的工作职责。不要以为测试人员吃饱了没事干，存心找茬。
不要轻视测试人员。
测试人员的注意事项：
发现缺陷时不要嘲笑开发人员，别说他的程序真臭、到处是Bug。
在开发人员压力太大时或心情不好时不要火上浇油，发现缺陷时别大声嚷嚷。
测试人员与开发人员的关系非常好，要避免 “手下留情”。
3. 合理地减少测试工作量
观点：用较低的代价实现有效的测试，不应为了追求完美的测试而不失一切代价。
如何合理地减少测试工作量。
（1）减少冗余的测试
•白盒测试与黑盒测试的方式虽然不同，但往往有“异曲同工”之妙。在很多地方，白盒测试与黑盒测试会产生一模一样的效果（或者能推理出来），这样的测试是冗余的。
•在集成测试、系统测试阶段，可能要执行多次“回归测试”。每一次“回归测试”都会存在不少的冗余，应当设法剔除不必要的重复测试工作。
（2）减少无价值的测试
•无价值的测试通常是由于不懂得测试技术引起的。例如功能测试，在等价区间之中，本来只要测试一个典型的输入就行了，如果有人在此区间测试了100次，那么其中99次就是无价值的。
（3）如何“偷工减料”
•有一些“短、平、快”的项目。采用“偷工减料”的方式来降低测试代价。基本方法是找出软件中需要优先测试的部分（见下表），其它次要部分可以忽略或将来再测试。
（4）“偷工减料”方法的测试优先级
•哪些功能是软件的特色？
•哪些功能是用户最常用的？
•哪些功能出错将导致用户不满或索赔？
•哪些程序是最复杂、最容易出错的？
•哪些程序是相对独立，应当提前测试的？
•哪些程序最容易扩散错误？
•哪些程序是全系统的性能瓶颈所在？
•哪些程序是开发者最没有信心的？
（5）测试何时结束：符合测试通过准则
主要测试内容及技术
1. 接口与路径测试
数据一般通过接口输入和输出，所以接口测试是白盒测试的第一步。
针对模块接口测试，应检查以下几方面：
•参数与变量的属性是否区配
•参数与变量所使用的单位是否一致
•传递给另一被调用模块的变量元素与参数的个数是否相同
•调用内部函数时，变量的个数、属性和次序是否正确
•是否会修改只是作为输入值的变量
•出现全局变量时，这些变量是否在所有引用它们的模块中都有相同的定义
•有没有把常数作为变量来传递
针对路径测试时条件覆盖，应注意以下几方面：
•不同数据类型的比较
•不正确的逻辑操作或优先级
•应当相等的地方由于精度的错误而不能相等
•不正确的判定或不正确的变量
•不正常的或不存在的循环终止
•当遇到分支循环时不能正常退出
•不适当的循环变量
•边界条件的考虑：如处理第N维数组的N个元素容易出错，循环执行到最后一次循环体时•可能出错
2. 功能测试
•功能测试的基本方法是构造一些合理输入（在需求范围之内），检查输出是否与期望的相同。如果两者不一致，即表明功能有误。
•功能测试看起来比较简单，只要看得懂《需求说明书》，谁都会做。难点在于如何构造有效的输入。
•功能测试的方法：
1)等价划分 2)边界值分析 3)错误推测 4)因果图功能图
3. 健壮性测试
•健壮性是指在异常情况下，软件还能正常运行的能力。健壮性有两层含义：一是容错能力，二是恢复能力。
•容错性测试通常构造一些不合理的输入来引诱软件出错，例如：
1)输入错误的数据类型。如“猴”年“马”月。
2)输入定义域之外的数值。
3)粗暴一些方式俗称“大猩猩”测试法。例如在测试客户机－服务器模式的软件时，把网络线拔掉，造成通信异常中断。
4)重要数据事务保护测试。
•恢复测试重点考察一下几项：
1)系统能否重新运行。
2)有无重要的数据丢失。
3)是否毁坏了其它相关的软件硬件
4. 性能测试
•性能测试即测试软件处理事务的速度，一是为了检验性能是否符合需求，二是为了得到某些性能数据供人们参考（例如用于宣传）。
•在获取测试的“绝对值”时，我们要充分考虑并记录运行环境对测试的影响。例如网络环境、计算机主频和外部设备都可能影响软件的运行速度。
•性能测试的一些注意事项：
1)不要试图让人拿着钟表去测时间，应当编写一段程序用于计算时间以及相关数据。 2)应当测试软件在标准配置和最低配置下的性能。 3)为了排除干扰，应当关闭那些消耗内存、占用CPU的其它应用软件（如杀毒软件）。 4)不同的输入情况会得到不同的性能数据，应当分档记录。例如传输文件的容量从100K到1M可以分成若干等级。5)由于环境的波动，同一种输入情况在不同的时间可能得到不同的性能数据，可以取其平均值。
5. 用户界面测试
•用户界面风格统一性。
•用户界面易用性。
•用户界面提示的正确性与易理解性。
•用户界面的错误字。
6. 安全测试
•安全性是指防止系统被非法入侵的能力，既属于技术问题又属于管理问题。
•安全性测试有如下步骤：
1)客户登录终端的控制的测试。 2)猜密码的测试。 3)用户密码加密的测试。 4)以黑客的身份测试。5)权限控制是否合理、正确。
7. 压力测试
•压力测试也叫负荷测试，即获取系统能正常运行的极限状态。
•压力测试的主要任务是：构造正确的输入，使劲折腾系统却让它刚好不瘫痪。
1)大容量数据库记录测试，请考虑：数据显示速度、查询速度、网络传输速度、数据库查询响应时间。
2)大容量企业端用户访问测试，请考虑：数据显示速度、查询速度、网络传输速度、数据库查询响应时间。
3)长时间运行。
4)并发性测试。
8. 可靠性测试
•可靠性是指在一定的环境下、在给定的时间内、系统不发生故障的概率。由于软件不像硬件那样可以“加速老化”，按此定义，软件可靠性测试可能会花费很长时间。
•比较实用的办法是，让用户使用该系统，记录每一次发生故障的时刻。计算出相邻故障的时间间隔，注意要去掉非工作时间。这样我们可以方便地统计出不发生故障的“最小时间间隔”、“最大时间间隔”和“平均时间间隔”。其中“平均时间间隔”会让人们大体了解到系统“可靠”的程度。
9. 安装 测试
•安装测试的目的：避免“大风浪都挺过来了，却在阴沟里翻了船”
•安装程序不再是件难事，关键是不要麻痹大意。主要测试工作：
1)至少在标准配置和最低配置两种环境下测试；
2)如果有安装界面，应当尝试各种选项，如选择“全部”、“部分”、“升级”等。
3)平台移植性测试，在多个操作系统环境测试。
4)卸载，再安装，安装到不同的目录下，多次安装等情况
10. 防病毒测试
对测试疑惑问题1：有了“黑盒”测试为什么还要“白盒”测试？
•黑盒测试只能观察软件的外部表现，即使软件的输入输出都是正确的，却并不能说明软件就是正确的。
•白盒测试能发现程序里的隐患，象内存泄漏、误差累计问题。在这方面，黑盒测试存在严重的不足。
问题2：由于单元测试要写测试程序，非常麻烦，能否等到整个系统全部开发完后， 再集中精力进行一次性地单元测试呢？
•如果这样做，在开发过程中，缺陷会越积越多并且分布得更广、隐藏得更深，反而导致测试与改错的代价大大增加。最糟糕的是无法估计测试与改错的工作量，使进度失去控制。因此为图眼前省事而省略单元测试或者“偷工减料”，是“得不偿失”的做法。
问题3：如果每个单元都通过了测试，把它们集成一起难道会有什么不妥吗？集成测试是否多此一举？
•要把N个单元集成一起肯定靠接口耦合，这时可能会产生在单元测试中无法发现的问题。例如：数据通过不同的接口时可能出错；几个函数关联在一起时可能达不到预期的功能；在某个单元里可以接受的误差可能在集成后被扩大到无法接受的程度。所以集成测试是必要的，不是多此一举。
问题4：在集成测试的时候，已经对一些子系统进行了功能测试、性能测试等等，那么在系统测试时能否跳过相同内容的测试?
•不能！因为集成测试是在仿真环境中开展的，那不是真正的目标系统。再者，单元测试和集成测试通常由开发小组执行。根据测试心理学的分析，开发人员测试自己的工作成果虽然是必要的，但不能作为成果已经通过测试的依据。
问题5：既然系统测试与β测试的内容几乎是相同的，为什么还要β测试？
•软件的最终用户各色各样。测试小组至多能够模仿小部分用户的行为，但并不具有普遍的代表性。
问题6：能否将系统测试和β测试“合二为一”？
•系统测试不是一会儿就能做完的，比较长时间的用户测试很难组织。
•系统测试时会找出相当多的软件缺陷，软件需要反反复复地改错。如果让用户发现“内幕”，一是丢脸，二是会吓跑买主。所以还是关起门来，先让测试小组做完系统测试的好。
很全面
