软件测试自学笔记.docx
《软件测试自学笔记.docx》由会员分享，可在线阅读，更多相关《软件测试自学笔记.docx（23页珍藏版）》请在冰豆网上搜索。
软件测试自学笔记
使用的教材是：
《软件测试》，RonPatton著，机械工业出版社，2002年版
自学知识点总结：
U1
1.软件缺陷案例：
迪斯尼的狮子王；
因特尔奔腾浮点除法软件缺陷；
美国航天局火星极地到登陆；
爱国者导弹防御系统；
千年虫；
2.软件缺陷的定义：
软件没有达到产品说明书标明的功能；
软件出现了产品说明书指明不会出现的错误；
软件功能超出了产品说明书指明的范围；
软件未到达产品说明书虽未标明但应到达的目的；
软件测试员认为软件难以理解，不易使用，运行速度缓慢；
3.造成软件缺陷的原因：
产品说明书：
很多东西产品说明书没写，或不够明确，或经常更改；
设计方案；
代码编写；
4.软件缺陷的修复费用
随着时间的推移时间费用呈几何级增长；
5.软件测试员的任务和应该的素质：
任务：
找出软件缺陷，尽可能早些，确保其得以修复；
素质：
探索精神；创造性；
坚持不懈；追求完美；
判断准确；老练稳重；
故障排除能手；说服力；
U2
A.人员组成：
1.项目管理者，程序管理员或监制人自始至终驱动项目；
2.设计师，系统工程师是项目小组的技术专家；
3.程序源，开发人员，代码编写者设计，编写，和修复软件缺陷；
4.测试员和质量评判员负责找出并报告软件缺陷；
5.技术作者，用户助手，用户培训专员，手册编写者编制软件产品附带的说明文档和联机文档；
6.结构管理者负责把程序员编写的所用程序文档
B.开发模式以及对应的测试方法：
1.大棒模式
软件已经完成，软件说明书已经齐备就是软件本身；同时，本能够再回身修复已经无法挽回的缺陷，所以测试员的任务只是向客户报告已经发现的错误；
2.边写边改模式
由于刚开始几乎没有文档和计划，小组成员可以快速展现其成果，所以这种模式适合快速制作且用完就扔的小项目；
3.流水模式
此模式的项目都要经过一系列步骤。
一个步骤完成后，项目小组进行检查，决定是否进入下一步骤；
创意，设计，分析，开分，测试，最终产品；
特别强调产品的定义，开发或代码编写只是其中的一个模块；
每个步骤都是分立的，没有交叉；
不能后退；
测试人员能够制定精确的测试计划和进度，测试对象也十分明确；
由于测试只在最后进行，所以一些开始隐藏的缺陷在产品发布前可能被发现，修复费用较高。
4.螺旋模式
主要思想是开始不必详细定义所有细节。
从小开始，定义重要功能，努力实现，接受用户反馈，进入下一阶段。
重复以上步骤直到得到最终产品。
明确目标，可选方案和限制条件；
指出并解决风险；
评估方案；
本阶段的开发和测试；
计划下一阶段；
确定进入下一阶段的方法；
此模式包括一点大棒模式，一点边写边改模式，一点流水模式，由于发现问题较早，费用较低，是一种很好的开发模式。
测试员也很喜欢此模式，由于在软件开始阶段就能参与，能够较早的影响软件。
软件的来龙去脉都很清楚。
在软件末期，不需要匆匆忙忙在短时间内进行全部测试，测试一直在进行，直到最后宣布全部成功。
C.产品的组成：
1.客户要求，利用焦点人群聚焦软件功能；
2.产品说明书；
3.软件设计文档：
构架：
数据流示意图；
状态变化示意图；
流程图；
注释代码；
4.测试文档：
测试计划；
测试案例；
软件缺陷报告；
归纳，统计和总结；
5.进度表；
D.软件产品的组成：
市场宣传材料；说明文件；
标签和帖子；图标和标志；
安装；产品支持信息；
示例和模版；用户手册；
帮助文件；错误信息；
U3
A.
1.完全测试程序是不可能的
1.1输入量太大；
1.2输出结果太多；
1.3软件实现途径太多；
1.4软件说明书没有客观标准；
2.软件测试是有风险的行为；
2.1主要原则是如何将无边无际的可能减少到可以控制的范围，如何针对风险做出明智选择，去粗存精；
2.2目标是找到合适的测试量，使测试不多不少；
3.测试不能显示潜伏的缺陷；
4.杀虫剂怪象
4.1是描述测试越多，程序的免疫力越强的现象。
这与农药杀虫是一样的，总用一种农药，害虫就有了抵抗力，农药的效力就难以发挥；
4.2为避免此现象，程序员要不断的编写不同的新的测试程序，对程序的不同部分进行测试，以发现更多软件缺陷；
5.发现的软件缺陷越多，就说明软件缺陷越多；
5.1程序员怠倦；
5.2程序员往往犯同样的错误；
5.3许多软件缺陷其实是大灾难的征兆；
6.难以说清的软件缺陷；
7.并非所有软件缺陷都能修复；
7.1程序员要进行良好的判断，搞清楚在什么情况下不能追求完美；项目小组需要对每一个缺陷进行取舍，根据风险决定修复哪些，不修复哪些；
7.2没有足够的时间；
7.3不值得修复；
7.4不算是真正的缺陷；
7.5修复的风险太大；
8.产品说明书不断变化；
9.软件测试员在项目小组中不受欢迎；
9.1早些发现软件缺陷；
9.2控制情绪；
9.3不要总是报告坏消息；
10软件测试是一项讲究条理的技术专业；
B
1.准确与精确
2.验证与合法性检查
验证是保证软件符合产品说明书的过程；合法性检查是保证软件满足客户要求的过程；
3.测试与质量评判；
质量评判的任务是创建和加强促进软件开发和避免软件缺陷的标准和方法；
4.质量与可靠性
可靠性是质量的一个方面；
OUTLINE：
A：
2，，1
3，4，5
6，，7
8，9，10
B.1->2->3->4
U4测试产品说明书
1.黑盒子测试
测试员只需要知道软件要做什么，看不到盒子里如何运作。
只要进行一些输入，就能得到某些输出。
白盒子测试
测试员能够访问程序员的代码，通过检查代码来协助测试；
静态测试
只测试程序不运行的部分，也就是只进行检查和审阅；
动态测试
运行和使用软件
2.使用静态黑盒子测试产品说明书
确保最终产品符合客户要求以及正确计划测试量的唯一方法是在产品说明书中完整描述产品；
通过询问设计人员或编制人员甚至可以测试没有写出来的产品说明书。
2.1对产品说明书进行高级审阅
a）设身处地为客户着想，
b）研究现有的标准和规范，标准和规范的区别是程度不同。
标准更加确定，标准必须遵守，而规范是可选的，但也应遵守，公司的习惯用语和约定；行业要求；国家标准；图形用户界面；硬件和网络标准；
c）审查和测试同类软件
规模，复杂度，测试性，质量/可靠性
2.2产品说明书的低级测试技术
2.21产品说明书的属性检查清单：
准确，精确，完整；
贴切，合理，一致；
代码无关性；可测试；
2.22产品说明书的用语检查清单：
已拒绝，已接受；良好，快速；
所有，都是；有些，有时；
如果，那么，否则；因此，显然，必然；诸如此类，以此类推；
U5闭着眼睛测试软件
1.对软件进行动态黑盒子测试；
在没有软件说明书时可以把软件本事当作产品说明书，逐步探索其特性；
通过测试和失败测试；
对软件测试案列进行设计和执行时，总是先进行通过测试；在进行破坏性实验之前检查软件的基本功能是否实现是很重要的；
等价分配
分步骤的将过多的测试案列减少到具有同样效果的小范围的过程；
为减少测试案例过度的进行等价分配，会增加漏掉软件缺陷的风险；
等价区间：
测试相同目标或暴露相同软件缺陷的一组测试案例；
在选择等价区间时，把相似的输入，输出，操作进行分组，这些分组就是等价区间；
2.数据测试
2.1边界条件
软件计划的操作界限的边缘条件；
2.2边界条件类型
在选择等价分配需要的数据时，应选择边界数据；
2.3测试边界线
不仅要对临近边界的合法数据进行检查，对刚刚超出边界的非法数据也要进行检查；
2.4
次边界条件，内部边界条件；
2.52的乘方
2.6ASCII表
2.7默认值，空白，无输入，空值，零值；
2.8非法，错误，不正确，垃圾数据；
3.状态测试
3.1测试软件的逻辑流程；
3.2建立状态转化图；
软件可能进入的每一种独立状态；
进入/退出每种状态的设置条件和输出结果；
从一种状态进入另一种状态的条件和输出；
3.3减少要测试的状态和转化的数量；
每种状态都要访问一次；
测试看上去最常见最普遍的状态转化；
测试状态之间最不常用的连接；
测试所有错误状态和输出结果；
测试随即状态转化；
3.4竞争条件和时序错乱；
3.5重负，重复和压迫测试；
重复测试，不断重复同一种操作，目的是看内存是否不足；
压迫测试，使软件在不理想的条件下工作，限制软件的必要条件；
重负测试，
U6代码检查
1.静态白盒子测试，检查设计和代码
1.1在不运行的情况下仔细审查软件的设计，体系构架和代码以找出软件缺陷的过程；
1.2好处有两个，一是能早些发现问题，找出动态黑盒子测试难以揭示或遇到的缺陷；二是可以为动态黑盒子测试的案例提供思路；
2.正式审查
2.1坚持的原则：
准备，遵守规则，确定问题，编写报告；
2.2步骤：
同时审查，公开陈述，检查
3.编码的标准和规则
3.1可靠性，移植性，可读性，维护性
3.2标题，标准，解释说明，示例；
4.通用代码审查清单：
数据声明错误，数据引用错误；
计算错误，比较错误；
流程控制错误，子函数参数错误；
输入输出错误，其它检查
OUTLINE:
U7.透过X光眼睛测试软件
1.动态白盒子测试
利用查看代码的功能和实现方法得到的信息来判断哪些需要测试，哪些不需要测试，如何测试等。
2.动态白盒子测试和调试
软件测试员应该尽量把问题缩减到能够演示软件缺陷的最简化测试案例；负责调试的程序员从此继续，判断是什么原因导致的软件缺陷，并设法修复。
3.分段测试
3.1单元和集成测试
自底向上的测试驱动，自顶向下的测试存根，用户驱动和独立驱动；
3.2分析产品说明书指定黑盒子测试的案例，利用等价划分对测试案例进行删减和增加；
3.3利用模块的白盒子信息，对测试案例进行删减和增加；
4.数据范围
4.1数据流：
各变量的立即值；
4.2内边界；
4.3等式和公式：
查看等式和公式的变量，在正常输入和输出外，指定他们的测试案例和等价划分。
4.4错误强制；
5.代码范围
测试案例没有覆盖软件的哪些部分；
哪些测试案例是多余的；
为使测试范围更准确，应该建立哪些新的测试案例；
5.1程序语句和代码行范围；
5.2分支范围；
5.3条件范围；
U8.配置测试
1.配置测试是用硬件测试软件操作的过程；
1.1硬件包括主机，组件，接口，外设，可选项和内存，驱动程序；
1.1分离配置缺陷
软件可能包含在很多配置中都会出现的缺陷；
软件可能包含只在某一特定配置中出现的缺陷；
硬件设备或设备驱动程序可能包含仅由有软件揭示的缺陷；
硬件设备或设备驱动程序可能包含其它许多软件揭示的缺陷；
1.2计算工作量；
2正式执行
2.1确定需要哪些硬件类型；
2.2确定可用的硬件商标，型号和驱动；
2.3确定可能的特性，模式或选项；
2.4将明确后的硬件配置缩减到可以控制的范围；
2.5明确使用硬件配置的软件的唯一特性；
2.6设计在每一种配置中要执行测试案例；
2.7在每一种配置中执行测试；
2.8反复测试知道项目小组满意为止；
3获得硬件
3.1只购买可以或将来经常使用的配置；
与硬件生产厂商联系，看他们是否能够租借甚至赠送某些软件；
向全公司的人发送软件演示或电子邮件，询问他们办公室或家里都有什么硬件，是否允许进行一些测试；
如果预算充足，和项目管理员一起与专业配置和兼容性测试实验室联系外协；
3.2明确硬件的标准，查看硬件的产品说明书；
3.3对其它硬件进行配置测试；
U9.兼容性测试
1.测试程序之间能否正确交互和共享信息。
平台和程序的不同版本
1.1向前兼容和向后兼容；
1.2测试多个版本的影响；流行性，念头，类型，厂家
2.标准和规范
2.1高级标准，产品普遍遵守的规章；
2.2低级标准，本质细节
3.数据兼容性
3.1不通过文件的复制，剪切，粘贴等
3.2DDE和OLE；
3.3程序的打开保存等文件操作；
3.4程序的导入，等和其它程序的兼容性操作；
U10.外国语言测试
1.翻译问题
向左读和向右读；图形中的文字；
ASCII，Unicode；扩展字符；
文本扩展；快捷键和热键；
使文字和代码分离；字符计算；
2.本地化问题
2.1内容；
2.2数据格式；
3.配置和兼容性问题；
3.1外国的平台配置；
3.2数据共享性；
U11.易用性测试
1.用户界面测试，软件程序同用户交互的方式成为用户界面
1.1符合标准和规范
如果要在某个平台上测试软件，就要把该平台的标准和规范作为产品说明书的补充内容，和产品说明书一样，制定相应的测试案例；
1.2直观性
用户界面是否洁净，不唐突，不拥挤；
用户界面组织和布局是否合理；
是否有多余的功能；
能否通过帮助按钮得到帮助；
1.3一致性；
菜单选项和快捷键；按钮位置和相似的按键；术语和命令；听众；
1.4灵活性；
状态跳转；状态终止和跳过；数据的输入和输出；
1.5舒适性；
恰当；性能；错误处理信息；
1.6正确性；
市场定位偏差；可见即可得；不良媒体；语言和拼写；
1.7实用性；
2.辅助功能测试；
2.1视力损伤；听力损伤；运动损伤；认知和语言障碍；
2.2高对比度；切换键；声音卫士；声音显示；
粘滞键；筛选键；鼠标键；串行键；
2.3这是法律；
U12.测试文档
1.测试文档的类型
市场宣传材料和广告；
包装上的文字和图形；标签和不干胶条；
最终用户协议；授权/注册登记表；
安装和设置指导；指南和向导；
示例和模版；用户手册；
联机帮助；错误提示信息；
2.怎样测试
不管文档是不是代码，像用户那样对待它是非常有效的测试方法。
仔细阅读，尝试每个示例，
检查清单：
跟随每个步骤，检查每个图形；
听众；屏幕抓图和图表；拼写和语法；
标题和内容；样例和示例；进口内容；
术语；逐步执行；
3.文档测试的重要作用；
提高易用性；提高可靠性；降低支持费用；
4.测试文档的本质
文档常常得不到足够的重视，预算和援助；
文档编写者可能对软件不甚了解；
印刷文档的编制需要很长的时间；
U13.网站测试
1.需要测试哪些基本类型
不同字体，颜色，大小的文字；
超级连接中的文字和图片；
图形和照片；不断播放的广告；
下拉式选择框；用户输入数据的地方；
2.黑盒子测试
首先为网站建立状态转换表，每个网页作为不同的状态，超级链接作为状态之间的连线；
2.1文字；
2.2超级连接；
2.3表单；
2.4图形；
2.5对象和其它零碎功能；
3.灰盒子测试；
仍然把软件当作黑盒子测试，通过简单查看软件内部机制作为补充；
4.白盒子测试
4.1动态内容；
4.2通过变成方式建立的网页；
4.3数据库驱动的网站；
4.4服务器性能和加载；
4.5安全性；
5.配置测试和兼容性测试；
5.1
硬件平台；
5.2调制解调器速率；
5.3视频分辨率和色深；
5.4浏览器软件和版本；
5.5浏览器选项；
5.6浏览器插件；
6.易用性测试
6.1不标准的超级链接颜色；
6.2滚动文字，滚动条和不断播放的动画；通过滚动显示的长页面；
6.3过期信息；孤页；
6.4没有导航支持；复杂的页面地址；
6.5使用不成熟的技术；使用框架；
6.6过长的下载时间；设置的最长用户等待时间太长；
U14.测试工具和测试自动化
1.好处：
速度；准确度和精确度；
效率；坚持不懈；
2.本质或坏处；
软件变更；不要花费太长时间使用不能达到测试目的的测试工具和测试自动化；
人眼和直觉是不可替代的；编写宏，开发工具和编制猴子都属于开发工作；
验证难以实现；容易过分依赖自动化；
有些测试工具是侵入式的，可能导致测试的软件不正常失败
3.测试工具
3.1查看器和监视器
可以看到平时看不到的软件操作细节；
3.2分析工具
二进制-十六进制计算器；
文本编辑软件；
电子表格软件；
数据库软件；
文件对比软件；
屏幕截图和对比软件；
秒表;
VCR或者电子照相机；
3.3驱动程序
用于操作或控制测试软件的工具；
3.4管道
和驱动程序不同，它能接收或响应测试软件发出的数据；
3.5施压和增负工具；
能够给软件增加压力和负荷；
3.6噪声发生器和干扰发射器
随机性
4.测试自动化
4.1宏的录制和回放；难以同步，验证难以实现；
4.2可编程的宏；验证难以实现，不能设置条件来分支测试；
4.3完全可编程的自动测试工具；
5.随机测试，猴子测试员，目的是模拟用户操作
5.1笨猴子，
5.2不太笨的猴子；单击哪里，测试结束怎么办，记录测试的过程；
5.3聪明的猴子；
U15.臭虫轰炸和BETA测试
1.多人测试的好处：
1.1不同人之间不仅看到的不同，测试的方法也不同；
1.2有助于消除杀虫剂怪象；
1.3有人帮助测试有利于消除烦躁心情；
1.4观察别人处理问题的方式是学习新的测试技术的好方法；
2.共享测试；
2.1小组成员之间在一定时间内互换测试任务；
2.2能够帮助寻找软件缺陷的最佳伙伴是产品支持和客服服务小组；
2.3小组成员都放下现在手中的活一起对软件的某一部分进行臭虫轰炸。
3.提交测试
3.1想擅长各方面软件测试的公司提交或转包部分测试；
3.2主要是配置和兼容性测试，本地化测试；
4.BETA测试
4.1把软件分发给选定的潜在客户群，他们在实际环境中使用软件。
一般在项目末期进行，理想的情况下是验证准备发给实际用户的软件。
4.2需考虑选定的客户以及他们是否进行了测试；
4.3能帮助找到配置和兼容性，易用性的软件缺陷，对其它类型没有帮助；
4.4需要耗费软件测试员的大量时间；
U16.计划测试
1.计划测试的目的
1.1规定测试活动的范围，资源，方式，进度；明确正在测试的项目，要测试的特性，要执行的测试任务，每个任务的负责人，与计划相关的风险；
1.2计划测试的最终目的是交流软件测试小组的意图，期望以及对将要执行的任务的理解；
2.计划主题清单；
2.1高级期望
计划测试的目的；
测试的软件；
软件质量可靠性的目标；
2.2人，地点，事；
2.3定义；
2.4团队之间的责任；
2.5哪些需要测试，哪些不需要测试；
2.6资源需求；
2.7测试阶段；
2.8测试策略；
2.9测试进度；
2.10测试案例；
2.11测试人员的任务分配；
2.12风险和问题；
2.13软件缺陷报告；
2.14频度和统计；
U17.测试案例的计划和组织
1.测试案例的计划，重要原因：
组织性，重复性，跟踪，证实；
1.1测试设计：
明确指出设计包含的特性及其相关的测试，提炼测试方法，如果要求完成测试还明确指出测试案例和测试程序，指定特性通过或失败的规则；
标识符，要测试的特性，方法，测试案例论证，通过/失败规则；
1.2测试案例：
编写用于输入的实际数据以及预期的输出结果；还明确指出使用具体测试案例产生的测试程序的任何限制；
标识符，测试项；输入说明，输出说明，案例之间的依赖性；环境要求，特殊要求；
1.3测试程序：
明确指出为实现相关的测试设计而操纵软件系统和实验具体的测试案例的全部步骤；
标识符，目的；程序，程序步骤，衡量标准；特殊要求，偶然情况；
日志，设置，启动，关闭，终止，重置；
1.4细节和真实；
2.测试案例的组织和跟踪：
凭脑子记，书面文档，电子表格，自定义数据库；
U18.报告发现的问题
1.报告软件缺陷的基本原则：
1.1尽快报告软件缺陷；
1.2有效描述软件缺陷：
1.21单一；
1.22短小；
1.23明显和通用；
1.24再现；
1.3在报告软件缺陷时不做评价；
1.4补充和完善软件缺陷报告；
2.分离和再现软件缺陷：
2.1不要想当然地接受任何假设；2.3检查时间依赖和竞争条件的问题；2.5状态软件缺陷
2.2不要忽视硬件；2.4考虑资源依赖性和内存，网络，硬件共享的相互作用；2.6与压力和符合相关的边界条件问题；内存泄漏和数据溢出等白盒子问题可能会慢慢自己显露出来；
3.软件缺陷的评价：
3.1严重性
3.11严重性表示软件缺陷的恶劣程度，反映对产品和用户的影响；
3.12一是系统崩溃，数据毁坏；2是操作性错误，结果错误，功能遗漏；3小问题，错别字，UI布局；4建议
3.2优先级
3.21优先级是表示修复软件缺陷的重要程度和应该何时修复；
3.221立即修复；2.在发布前必须修复；3如果时间允许应该修复；4.可能会修复，不修复也能发布；
4.软件缺陷的生命周期
4.13种基本和2种附加的状态：
打开，解决，关闭；审查，延迟；
4.2基本运行流程：
打开，解决，关闭；
4.3附加流程；打开，审查，打开或延迟或关闭；
4.4
循环流程；解决或关闭或延迟到打开；
5.软件缺陷的报告和跟踪系统
5.1标准：
测试事件报告：
标识符，总结，事件描述，影响
5.2手工软件缺陷报告和跟踪；
5.3自动软件缺陷和跟踪。
U19.评价成效
1.日常测试中的频度；
1.1描述软件项目特定属性度量单位的术语称为频度；
1.2使用软件缺陷跟踪数据库作为软件频度的来源是评价测试员自身进度和项目状态及其有效的工作方式；
1.3软件缺陷跟踪数据库最常用也是最重要的功能是执行查询；然后才能根据数据制作各种图表；
2.常用项目级频度；
2.1发现的软件缺陷越多，说明未发现的软件缺陷也越多。
根据这一原则，很容易建立查看软件状况的频度和图表，不仅能够确定测试工作的状态，也能确定整个项目的状态；
2.2每个主要功能区域发现软件缺陷数量的项目级饼图；前提是测试工作已经统一通过整个项目；
2.3随着时间的推移发现的软件缺陷的数量和累积曲线；还要标注项目的进度和其它重大事项；
2.4红色是打开的软件缺陷，越大说明程序员工作繁重；黄色区域是解决的软件缺陷，越多说明测试员工作繁重；绿色区域代表关闭的软件缺陷，说明项目即将关闭，准备发布。
U20.质量评测
1.质量费用，质量费用包括整合费用和非整合费用。
1.1整合费用是用于一次性计划与执行测试的全部费用，保证软件按照预期的方式运行。
如果发现软件缺陷，则要花费时间进行分离，报告，回复测试等，这些是非整合费用。
1.2如果在软件发布之间发现，则属于内部失败；如果在发布之后由用户发现则属于外部失败；外部失败的非整合费用大于整合费用和内部失败的非整合费用的总和。
2.职业名称
2.1软件测试，职责是找到软件缺陷，有效地描述他们，通知相应人，跟踪软件缺陷直到解决；其次另一特点是不对质量负责，主要是因为质量不是靠测试提高的，
升级会员 