软件测试思想V0728.docx
《软件测试思想V0728.docx》由会员分享，可在线阅读，更多相关《软件测试思想V0728.docx（45页珍藏版）》请在冰豆网上搜索。
软件测试思想V0728
1、软件是一系列特定的顺序组织的计算机数据的指令的集合。
裸机也包含软件。
对软件的简单认识是：
数据+程序
数据：
包括键盘输入，鼠标单击，磁盘文件，打印输出
程序：
可执行的流程，转换，逻辑和运算。
软件并不是只是包括在计算机上运行的程序，与程序相关的文档，也被称为是计算机软件的一部分。
它是程序（Doucunetm）、文档，的集合体。
系统软件：
负责计算机系统中各种独立的硬件，使他们可以协调工作。
系统软件使计算机使用者和他软件当作一个整体而不需要考虑底层每个硬件是如何工作的。
应用软件：
是为了某种特定的目的而开发的软件，他可以是一个特定的程序，如一个图像浏览器，也可以是一组功能联系密切，可以互相协作的程序的集合，比如微软的office，也可以是独立的程序组成的庞大的软件系统，如数据库管理系统。
编写软件的目的：
为了解决现实问题。
软件产品到底是什么：
软件不仅指从互联网上下载下来或DVD光盘安装到计算机程序，实际上制作软件还包含很多隐含的内容。
如：
数据库，操作动作，中间件（tomcat、iis、weblogic、wordpresswebsphere），不同平台，这些地方都有可能存在缺陷（隐含内容等扩展）。
这些地方要铭记在心，因为这些全是可测试的象，并且有可能包含缺陷。
电源
高级语言
电脑操作操作系统
操作系统
2、软件缺陷
（1）美国电气工程师按外部、内部给缺陷的定义：
从产品内部看，是软件开发或维护过程中存在的错误、毛病等问题。
从产品外部看，缺陷是系统所需实现的某种功能的失效和违背。
简单地说，用户在软件使用过程中，遇到软件的某种功能，错误和异常都可以称为“软件缺陷”
（2）计算机软件或程序中的存在的某种破坏性的正常运行能力的问题，错误或隐藏的内容功能缺陷。
（3）软件缺陷除了失效以外，还体现在其他方面，如软件未实现产品说明书要求的功能；软件出现产品说明书指明不应该出现的功能，
（4）软件出现说明书指明未提到的功能。
（5）软件难以理解，不易使用，运行缓慢，或者从软件测试人员的角度看，认为用户最终会觉得不好。
软件测试人员是真正第一个使用软件的人，如果软件测试人员在使用软件的时候发现某些地方要不对劲，无论什么原因，都要认定为缺陷。
但每一个使用软件的人都会有自己的想法和意见，要编写所有的用户都满意的软件是不可能的，所以在运用第5时，要记住一点：
要全面，客观准确，并非所有测试发现的缺陷都要修改的。
不能判定是否是缺陷的时候要进行确认和验证两个过程。
软件缺陷的定义二：
是人工的自动化的手段来运行机制或测试村个系统过程其目的在于检验它是否满足规定的需求，或弄清预期结果与实际结果的差别。
3、缺陷报告的组成
一、
low
low
新提交的状态（new）
系统运行的复杂，不仅用户使用的计算机千变万化，包括用户输入的数据容易引起一些问题。
缺陷根源（rootsause）：
缺陷根源指发生错误的根本因素
通信端口多，加密手段的矛盾性，会造成系统的安全性和适用性
对于设计或编程上的一些假定或依赖性，相关人员没有充分沟通。
接口参数传递不匹配，导致模块集成出现问题
文档不完善，风险评估不足
]
大多数软件缺陷并非源自编程错误，从众多从小到大的项目进行研究而得出的结论是一致的，导致软件最大的原因是产品说明书，第二大来源是设计院，这里产生软件缺陷的原因与产品说明书是一样------随意，易变，沟通不足，有一句话叫“说不出就做不到”用到软件开发和测试身上再合适不过。
代码错误可以照片于的复杂性，文档不足或普通低级错误。
而看上去是编程错误的代码是产品说明书和设计方案造成的。
还有一类误解，即本来正确的当成缺陷，还有一些是多处重复出现，实际上是一个原因引起的，一些可归咎于测试错误。
产品说明书常常没写，说不出来就做不到，其他原因是说明虽然有，但是不完整，不停的更改，不停的更改，或者产品说明书内容没有同开发小级其他成员沟通过。
缺陷报告
（二）
缺陷编号（DefectID）
缺陷标题（summary）
缺陷的发现者（Defectby）
缺陷发现日期（DefectBy）
缺陷所属模块（subject）
指派缺陷的版本（Defectedinrelease）
指派给谁处理（assignedto）
缺陷状态:
status:
newopen,rejected,fixed,reopen,closed
缺陷的严重程度:
urgent,veryhighhigh,medium,low
优先级urgent,veryhighhigh,medium,low
缺陷的严重程序和优先级的关系：
严重程度一般不会修改，优先级可以适当妥协，严重程度较低的，但是优先级可能最高。
4、第一个软件缺陷的领导者是美国海军将军，编译器的发明者，领导了cobol语言，（面商业的通用语言）-cobolcommonbusinessorientedlanguage
5、以另外一种方式来思考，两个人对同一个软件都会持不同的见解，一个说很完美，一个说缺陷很多，一定是一个人以某种运行软件时暴露了大量的问题。
6、软件结构的分类
单机软件
C/S（client/server客户端）服务器：
如：
qc,msn,qq，游戏，特点：
客户端采用专门的软件
分布式软件
B/S（broner/server）浏览器/服务器电子商务网站，论坛，优点，软件的更新，只需要服务器程序。
客户端：
是更新后的效果，开发维护容易。
不足：
客户显示效果不如b/s，但是目前正在优化，朝着（richclient富客户端趋势发展），技术javascriptjquery
7、主流的浏览器
IE,firefox,safari（苹果）,chrome，opear
8、ENIAC:
电子数字积分计算机，electonicnumbericalintegratorandcaluator美国宾西法尼亚大学，莫尔学院，1946
9、测试的步骤
（1）编写测试用例
（2）编写测试用例
（3）执行用例，发现缺陷，提交缺陷报告
（4）验证所发现的缺陷是否得到修改
（5）编写测试总结报告
10、测试计划的组成
简介
参考文档
测试文档
提交文档
熟悉系统需求
编写测试计划
执行用例
测试进度
总结报告
Alpha测试
Beta测试
描述严重程度
测试资源
缺陷优先级
问题的严重程度和优先级
缺陷跟踪及返测版本号
风险分析
测试策略
手工测试、自动化测试，
黑盒测试，白盒测试，灰盒测试
负载测试70吨是负
压力测试70吨是压力
容量测试60是容量
基准测试
并发测试
综合场景测试
递增测试
安装测试
软件兼容
文档测试
测试策略中的术语：
黑盒测试（功能测试）：
软件测员只需要知道要什么-----而无法看到盒子里的软件是如何运行的。
只要进行一些输入，就能得到输出结果。
他不知道软件如何运行，为什么这样，只知道程序做了什么？
动态黑盒测试常常称为行为测试，因为测试的是软件在使用过程中的实际行。
有效的动态测试需要关于软件行为的一些定义-----即需求文档或产品说明书。
好的产品说明书会提供这些细节。
白盒测试（透明盒测试）：
软件测试员可以访问程序员的代码，并通过检查代码的线索来协助测试---可以看到盒子里面。
测试员根据代码检查判断多或少可能出错的数据。
并据此定制测试。
有时也称为结构化分析，找出动态黑盒测试难以发现或隔离的软件缺陷，为黑盒测试测试员在接受软件进行测试时设计和应用测试用例提供思路。
动态白盒测试是指利用查看代码功能（做什么）和实现方式（怎么，做）得到的信息来确定哪些测试，哪些不需要测试，如何开展测试，如何开展测试。
动态白盒测试的另一个常用名称是结构化测试，因为软件测试员可以查看并使用代码的内部结构从而设计执行测试。
动态白盒测试不仅仅是查看代码的运行情况，还包括直接测试和控制软件，动态白盒测试包括以下四个部分：
直接测试底层函数，过程，子程序和库，在micrsoftwindows中这样[称为应用程序编程接口（API）。
以完整的程序的方式从顶层测试软件，但是根据对软件运行的了解调整测试用例；从软件获得读取变量和状态信息的访问权，以便确定测试与预期结果是否相符，同时强制软件以正常测试难以实现的方式运行；估算执行测试时“命中”的代码量和具体代码，然后调整测试，却掉多余的测试用例，补充遗漏的用例。
一定不要把动态白盒测试和调试（debugging）搞浑了，不是一个概念。
动态白盒测试的目标寻找软件缺陷，调试的目标是修复缺陷。
软件测试员应该把问题缩减为能够演示软件缺陷的最简化的测试用例。
如果白盒测试，甚至还要包括那些值得怀疑的代码行信息静态测试：
测试不运行的部分，只是检查和审核。
如果要进行了动态白盒测试的思路：
一，首先可以确定模块属于程序中的底层模块，可以由高层模块调用，但是自己不能调用其他模块，通过查看代码可以确认这一点。
（合理的做法是编写一个测试驱动以独立于程序其他部分的形式测验该模块），测试可以是多种形式的，可以是输入字符串并查看结果的，也可以是文件读取测试字符串的预期结果的独立程序。
二，分析说明书，确定应该采用户黑盒测试用例，运用等价类划分技术减少测试用例集合。
在进行了白盒测试之前，一定要根据说明书建立黑盒测试用例，用[这种方式可以真正测试模块的功能和作用。
如果先从模块的白盒角度建立测试用例，检查代码，就会偏向于以模块工作方式建立测试用例。
程序员或许误解了说明，于是测试用例就会不对。
动态测试：
是通常意义上的测试----使用和运行软件。
10、
11、缺陷报告要注意的问题
（1）一个报告只提交一个缺陷
（2）缺陷描述准确，易读，使用最少必须步骤，保证缺陷可以重现，缺陷的描述要做到追根溯源，简明扼要，面面俱到。
制定统一的checklist，并且经过项目负责人的评审，如果遇到歧义，和开发人员交流，以checklist为准，对缺陷的严重性，优先级准确，客观。
（3）在提交缺陷时，一定要认真审核，确保缺陷是有限的。
（4）不要为了引起开发的重视而夸大缺陷
（5）及时报告缺陷
（6）不做任何评价
（7）对于不可重现的缺陷也要报告
（8）因类测试人员以边界值或错误猜想法的设计用例而发现的缺陷，可能引起开发的不认同，测试人员要分析引导开发了解系统的潜在风险，提高开发人员的质量意识。
12、缺陷报告的处理流程
关闭
13、八种编写测试用例方法
（1）等价类
（2）边界值
（3）因果法
（4）判定法
（5）场景法
（6）正交法
（7）状态转换法
（8）测试大纲法
（9）随机测试（猴子测试）
等价类：
对程序的规格说明有意义的，合理的输入数据集合。
如果用户输入的是有效等价类中的数据，程序应该正确计算执行。
等价类划分是把海量（无限）的测试用例减得很小。
一个等价类和等价划分是指测试相同目标或者暴露相同软件缺陷的一组测试用例。
步骤：
一、划分等价类，二细分等价类，三建立等价类，编写测试用例
适合场合：
任何有输入的地方都可以使用等价类。
无效等价类：
对程序的规格说明不合理无意义的输入数据集合，如果用户输入无效等价类中的数据，程序应该给予错误提示，不允许用户输入。
相比于有效等价类，无效等价类主要软件的健壮性（容错性），程序异常处理能力。
选择等价类的原则：
对于不同的有效等价类，尽可能在一条测试用例中使用测试仪，这样可以减少测试数量，在一条用例中覆盖多的有效等价类，对于不同控制的无产等价类，一条用例只覆盖一条，一个控制的无效等价类，可以考虑无效的组合，排除其他因素的干扰。
（注：
老采矿者的话，适用于这个原则：
“出去找一样东西，并且就只找这样东西”。
根据一些关键的关键来进行等价划分，这些关键就是：
边界条件，次边界条件，空值，无效数据（非法，错误，不正确，垃圾数据（重复，压迫，重负）），默认值，空值，0值，，空白，无
等价类划分的目标：
把可能的测试用例集缩减到可控制且仍然足以测试软件的范围内。
不过，为了减少测试用例的数量的过度划分等价类，就有漏掉那些可能暴露软件缺陷的风险。
边界值法：
一般取六个值。
边界的数据类型：
数值，字符，位置，数量，速度，地点，尺寸
而这些类型需要考虑的特征：
第一个/最后一个,最小值/最大值,开始/完成,超过/在内,空/满,最短/最长,最慢/最快,最早/最迟,最大/最小,最高/最低,相邻/最远。
软件的每一部分寻找边界是非常重要的，，边界就会发现得越多，可能得出的软件缺陷就越多。
因果法：
因果法适合场合：
因果限制每个控件的条件，不宜过多，最多两个，比较适合单选钮，复选框，下拉列表。
四个因果符号：
恒等=
非~
或V
与^
因果中的条件：
互斥E
包含I
唯一O
要求R
屏蔽M
使用因果法的步骤：
（1）找出所有的输入动作，编写，
（2）找出所有的结构。
（3）在步骤1的基础上，找出输入动作限制关系和组合关系。
如2,3互斥
注：
哪些是不能组合的，哪些是能组合在一起的确，是测试用例的数量。
（6）在步骤2的基础上，找出输入输出的限制组合关系。
（7）什么样的输入组合步骤，会产生什么样的输出组合
（8）根据判定表编写测试用例
正交表：
正交排列法是以正交表为基础的，根据控制的个数与每个控制取值个数不同，选定一个合适的正交表后，然后进行映射即可。
正交表的使用场合：
在一个界面中有多个控件，有多个值，测试时考虑不同组合。
LnMk
N下标k上标
N表示表的行数，也就是需要测试的组合的次数。
K表示表的列数，表示控件的个数，（因素的个数或因子数）
M是每一个控件的取值个数（各因素的水平数，在因素状态数表示每个摈件有两种选择）
使用正交表编写测试的步骤：
（1）根据控件的个数把每个控件的取值个数，选择一个合适的正交表编写用例。
（2）把程序的控件的取值整理成表格（熟悉需求）
（3）把控件名称映射到正交表，把每个控件取值正交表的每道取值。
（4）编写测试仪用例。
正交表的一对应一条用例。
正交表的特点：
正交表的思想选择数据时要均匀，零星一的进行的进行选取，而不能集中某个局部，保证控件都组合，并且每个控件组合的次数都在应该相同，每个控件的取值应该接近；控件的取值个数相同最多个（也就是说其中的选项数都是几种，如打印范围和颜色灰度都是3可选项，所以选底为3的，按控件值最多的选取，）
注：
正交表360网盘
场景法：
场景法的定义模拟用户使用可能场景（情景）主要测试仪软件重要功能，是否实现，此方法结合等价类使用，以软件需求为中心，充分理解业务之上，以等价类为基础。
场景法的主要概念，基本流（正确流）-有效等价类-按照正确的业务流来实现的一样操作路径。
备选流（出错流）-无效等价类，导致程序出错。
状态转换图的应用场合把所有的状态操作步骤，操作顺序是场景法具体实施应用。
核心：
一连串状态分解，进行程序分析，可以把复杂的程序，流程简单化。
定义：
找出软件的所有状态惟及导致状态变化的所有的输入动作，进而图形的方法把相关联的用户输入动作状态一起，真实的模拟出用户操作顺序流程，编写测试用例。
状态转换图的步骤：
（1）找出程序的所有的输入入动作，并进行编号，找出所有的状态，找出是什么动作导致状态发生，画出状态转换图（一般情况下这是个反复的过程）
把关联的动作和状态联系起来。
状态转换图注意事项：
每种状态的至少访问一一次，无论用什么办法，每一种状态都必须测试；
从一种状转入另一种状态所需的输入和条件；
进入或者退出某种状态时的设置条件及输入出结果。
测试看起来最常见最普通的状态，可以根据产品说明书，通过与客户开发人员沟通，了解哪些是常用更重要的：
测试状态之间最常用户分支，这此分支最容易产品设计者忽略，也要测试
测试所有错误状态及其返回值，错误提示不正确等情况是常有。
测试大纲法：
应用场合：
在程序和模块中，涉及到多窗口和多动作间有一定关联性，为了弄甭窗口口之间的关系，或者说动作与动作之间的关系，我们可以用大纲法
测试大纲法，找出所有窗口以及窗口的输入动作。
找出窗口与窗口之间的关联。
随机测试：
向普通用户一样，对软件进行测试。
测试方法的重要级：
高到低
场景法/等价类和边界值/因果法/判定表/正交排列法/状态转换法/测试大纲法/使用错误猜测和随机/测试补充用例（根据需求文档中如果有错误类型，用报错来看用例有无遗漏，特别适合硬件测试的错误码报错）
个人觉得这么多方法，就场景，等价，边界值是最最常用的。
14、软件测试阶段的划分
单元测试的概念：
针对性每个单元的测试，确保每个模块正常工作。
在底层进行的测试称为单元测试（unittesting）或者模块测试（moduletesting），单元测试，底层软件缺陷被找出并修复之后，就集成在一起，对模块组合进行了集成测试。
直到整个产品，至少是产品的主要部分，在称为系统测试的过程中一起测试。
驱动模块：
模拟上一个模块（调用被测模块的那个模块）
集成测试：
通常单元测试基础上，将所有的程序模块进行了有序的测试。
集成测试是检验单元或部件的接口关系，逐步成为符合要求程序部件或整个系统。
自顶向上：
成佬，深度优先。
自底向上；面向过程的系统采用的两种方法。
系统测试仪：
对集成的软件进行了整理体的测试仪确认测试，在系统测试之前，对软件的重要性进行测试，确认软件的主要功能，可以全面的系统测试修复。
Alpha测试：
开发环境下进行的测试，由于开发方包括测试仪人员进行的测试，主要由用户参与，最好在测试仪人员的指导下，进行了全面细致的测试仪，
自顶向下
Beta用户环境下进行测试，主要由用户参与，最好在测试人员的指导下，进行了全面细致的测试。
15、测试模型
V模型
验收测试
W模型
集成测试
W模型有两种
W模型也有局限性，W模型和V模型都把软件的开发[视为需求，设计，编码等一系列的串行的活动，无法实现迭代，自发性，变更调整。
X模型
X模型是对V模型的改进，X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的效接，通过集成最终为可执行的程序。
X模型的左边描述的是针对单独程序片断进行编码和测试，此后将进行频繁的交接，通过集成是终成功可执行程序。
然后对这些可执行程序进行测试，已通过集成测试的成员可以封装并提交给用户，也可以作为更大规模和范围内集成的部分。
多根并行曲线的变更表示可以在各个部分发生，X模型还定位了探索性测试，这是不进行事先测试的特殊类型的测试。
这一方式往往能帮助有经验的测试人员找出更多的软件错误，但这样可能对测试造成人力，物力财人的浪费，对测试人员的熟练度要求高。
H模型
其它流程
H模型提示了一个原理，软件测试是一个独立的流和，贯穿于产品整个生命周期，与其它流程并发操作。
软件测试过程模型V模型是软件开展瀑布的模型的变种，主要反映测试活动分析设计的关系，局限性：
把编码作为最后一个活动，需求分析产生的错误直到后期的验收测试才能发现。
W模型————增加了开发阶段的同步测试仪，形成W模型，测试与开发同步进行，有利用尽早发现问题。
局限性：
仍把开发活动看成需求开始到编码的串行活动。
只有上一阶段完成才能进行一下一阶段的活动，不能支持迭代，自发性以及变更调整，
H模型是完全独立的，某个测试点准备就绪时，就可以从准备阶段到测试执行阶段，软件测试可以尽早的进行软件测试可以根据被测试物的不同而分层次进行。
V模型强调了整个软件项目开发中需要经历的若干个级别，并与每一个开发并发对应，忽略了测试对象不应该仅仅包括程序，没有明确指出需求设计的测试。
W模型：
补充了V模型中忽略的内容，强调了测试计划等工作的先行对系统需求和系统设计院的测试，与V模型要相同，测试软件测试进行流程的说明
H独立的，只要测试准备完成，就可以执行。
软件测试ronpatton张小松
16、软件测试工程师应该具备的素质：
（1）探索者
（2）故障排除员（3）不放过任何蛛丝蚂迹难以重现的缺陷不会当作偶然而放过。
（4）追求完美，当无法企及时，不苛求，尽力接近目标。
好的软件测试人员知道何时无法企及完美，何时时达到够好。
（5）判断准确（6）注重策略和外交（7）善于说服（8）学习能力强
（9）表达能力强、沟通能力（10）耐心（11）细心（12）信心（13）责任心（14）能承受抗压能力（15）软件测试是一项批判性工作，所以要具有批判性精神，软件测试是一项要坚持必要的原则的工作
（16）好的软件测试人员，要对软件的开发全过程有个总体的了解.
17、软件失败的术语：
缺点：
dffect偏差：
variance故障：
fault失败:
failure问题：
problem
矛盾：
inconsictency错误:
error特殊：
feaure事件incient
缺陷：
bug异常：
anomaly
术语的多样化由于公司文化和开发软件的过短。
公司或开发小组用来称呼软件总理的意义不是很重要，但重要的是，讨论用什么词来描述软件问题意义在于：
对软件测试员来说了与自己合作的产品开发小组的特点是很重要的，提及软件问题的方式反映出他们处理整个开发的过程的方式，可以看出他们是谨慎，小心还是简单生硬。
18、产品说明书
辅助性术语：
产品说明书有时称为说明（spec）或产品说明书（productspec），是软件开发小组的一个协定，它对开发的产品进行了定义，给出细节，如何做，做什么，什么时候做。
19、软件缺陷的修复费用
软件缺陷的费用是随着时间的推移而增加的，费用指数级的增长，随着时间的推移，费用呈十位增长。
1000
100
10
1
说明书设计编码发布
20、软件测试员的目的
软件测试员的目的是尽可能找到软件缺陷并确保期限得以修复，但要记住，“修复”并非指软件一定要改正软件，可以在用户手册中加一段注释或为用户提供特殊的培训（这样也算处理发生一部分的缺陷的方式）
21、几个臭名昭著的软件错误的研究
迪斯尼的狮子软件缺陷是由于兼容性测试没有做到位的著名案例，因为没有做好兼容性测试的工作，所以带来了昂贵的成本代价，如果早一点发现缺陷就不会产生后期如此大的影响。
英特尔奔腾浮点除法说明是对软件缺陷的重视程序和处理方式会极大的影响企业。
所以这里再次证明运用缺陷规则中第5点，要注意的事，无论什么不对劲的地方，都要定义为缺陷，即使不修改也要在用户手册中说明，因为处理缺陷的方式好坏，很大程度上会有后期影响。
美国航天局火灾星极登陆者探测器，这个软件缺陷从测试阶段上来看完全是因为没有按照测试阶段执行完成，不进行系统测试带来的问题。
爱国者导弹防御系统这个软件缺陷要值得注意的地方是在测试的时候再小的问题也要引起重视，并分析后期带来的影响。
千年虫的问题，在1974千年虫的问题测试时一些预见的措施不足，危险的预见2004说明预见能为我们屏蔽很多潜在风险，降低或减少一些不必要的成本支出。
千年虫的中，程序员应该对这个显疏忽疑问而不是仅仅将程序设计到1999年，由于他没有这样做，软件测试人员就应该测试并发现该缺陷，然后由开发小组确定是否修正。
22、软件行业中，用来描述制造并交付他人的软件产品组件术语是可交付部分（deliverable），解释所有的可交付部分是最简便的方法是分门别类。
23、一个
升级会员 