软件测试思想_V0728解读

《软件测试思想_V0728解读》由会员分享，可在线阅读，更多相关《软件测试思想_V0728解读（30页珍藏版）》请在装配图网上搜索。

1、1、 软件是一系列特定的顺序组织的计算机数据的指令的集合。裸机也包含软件。对软件的简单认识是：数据+程序数据：包括键盘输入，鼠标单击，磁盘文件，打印输出程序：可执行的流程，转换，逻辑和运算。软件并不是只是包括在计算机上运行的程序，与程序相关的文档，也被称为是计算机软件的一部分。它是程序 (Doucunetm) 、文档，的集合体。系统软件： 负责计算机系统中各种独立的硬件，使他们可以协调工作。系统软件使计算机使用者和他软件当作一个整体而不需要考虑底层每个硬件是如何工作的。应用软件： 是为了某种特定的目的而开发的软件，他可以是一个特定的程序，如一个图像浏览器，也可以是一组功能联系密切，可以互相协作

2、的程序的集合，比如微软的office ，也可以是独立的程序组成的庞大的软件系统，如数据库管理系统。编写软件的目的：为了解决现实问题。软件产品到底是什么：软件不仅指从互联网上下载下来或DVD 光盘安装到计算机程序，实际上制作软件还包含很多隐含的内容。如：数据库，操作动作，中间件（ tomcat、iis、weblogic 、wordpress websphere ），不同平台，这些地方都有可能存在缺陷（隐含内容等扩展） 。这些地方要铭记在心，因为这些全是可测试的象，并且有可能包含缺陷。BOOSBSDdoslinux电脑操作操作系Mac OS/更名为 (IOS)OS/2QNX操作系统windowsO

3、SAnroid软ios件系手机操作系统统Windows phone操作系统补丁程序塞班驱动程序编译器数据库管理存储器格式化文件系统管理用户身份验证驱动管理网络连接机器语言语言处理程序汇编语言诊断程序高级语言CPU主板2、 软件缺陷（ 1） 美国电气工程师按外部、内部给缺陷的定义：从产品内部看，是软件开发或维护过程中存在的错误、毛病等问题。从产品外部看，缺陷是系统所需实现的某种功能的失效和违背。简单地说，用户在软件使用过程中，遇到软件的某种功能，错误和异常都可以称为“软件缺陷”（ 2） 计算机软件或程序中的存在的某种破坏性的正常运行能力的问题，错误或隐藏的内容功能缺陷。（ 3） 软件缺陷除了失效

4、以外，还体现在其他方面，如软件未实现产品说明书要求的功能；软件出现产品说明书指明不应该出现的功能，（ 4） 软件出现说明书指明未提到的功能。（ 5） 软件难以理解，不易使用，运行缓慢，或者从软件测试人员的角度看，认为用户最终会觉得不好。软件测试人员是真正第一个使用软件的人，如果软件测试人员在使用软件的时候发现某些地方要不对劲， 无论什么原因，都要认定为缺陷 。但每一个使用软件的人都会有自己的想法和意见，要编写所有的用户都满意的软件是不可能的，所以在运用第 5 时，要记住一点： 要全面，客观准确，并非所有测试发现的缺陷都要修改的。不能判定是否是缺陷的时候要进行确认和验证两个过程。软件缺陷的定义二

5、：是人工的自动化的手段来运行机制或测试村个系统过程其目的在于检验它是否满足规定的需求，或弄清预期结果与实际结果的差别。3、 缺陷报告的组成一、缺陷编号缺陷类型 (type)缺陷严重程度(severity)微小的 (minor)一般的 (major)严重的（ critical ）致命的 (Fatal)urgentVery highurgentVery highhighmediumlow缺陷优先级 (priority)highmediumlow激活状态（ open/reopen已修正状态（fixed）缺陷状态status)关闭状态（ closed）拒绝的状态（ reject ）新提交的状态（new

6、 ）缺陷起源 (origin) ：被引起故障帮第一次检测的阶段）需求不清晰缺陷来源 (source)：引起缺陷的起因系统结构复杂对实时的应用要精心处理没有考虑到系统崩溃后的自我恢复或数据库备份，灾难性问题缺陷根源 (root sause) ：1、软件系统运行的复杂，不仅用户使用的计算机千变万缺陷根源指发生错误本身化，包括用户输入的数据容易引起一些问题。的根本因素通信端口多，加密手段的矛盾性，会造成系统的安全性和适用性新技术的采用，可能涉及技术或系统的兼容性问题，事先没有考虑到2、团队工作3、技术问题系统需求分析对客户需求理解不清楚，和用户的沟通存在一些困难。不同阶段的开发人员相互理解不一致，如

7、：软件设计对需要分析有误差，编程人员对系统设计规格说明书某些内容不够重视，或存在误解对于设计或编程上的一些假定或依赖性，相关人员没有充分沟通。项目组成员水平参差不齐，新员工多，培训不足算法错误语法错误计算和精度问题系统结构不合理， 算法不科学接口参数传递不匹配， 导致模块集成出现问题1、缺乏质量文化，不重视质量计划，对质量、资源， 任务，成本等平衡性把握得不好， 容易挤掉需求分析， 评审， 测试时间， 遗留的缺陷会比较多。系统分析时对客户需求不是很清楚，或者和用户沟通存在一些困难。4、项目管 理 问开发周期短题开发流程不够完善，存在太多随机性或缺乏严谨的内审或评审机制，容易产生问题文档不完善，

8、风险评估不足大多数软件缺陷并非源自编程错误， 从众多从小到大的项目进行研究而得出的结论是一致的，导致软件最大的原因是产品说明书，第二大来源是设计院，这里产生软件缺陷的原因与产品说明书是一样 -随意，易变，沟通不足，有一句话叫“说不出就做不到”用到软件开发和测试身上再合适不过。代码错误可以照片于的复杂性，文档不足或普通低级错误。 而看上去是编程错误的代码是产品说明书和设计方案造成的。还有一类误解，即本来正确的当成缺陷，还有一些是多处重复出现，实际上是一个原因引起的，一些可归咎于测试错误。产品说明书常常没写，说不出来就做不到，其他原因是说明虽然有，但是不完整，不停的更改，不停的更改，或者产品说明书

9、内容没有同开发小级其他成员沟通过。缺陷报告（二）缺陷编号 (Defect ID)缺陷标题 (summary)缺陷的发现者 (Defect by)缺陷发现日期 (Defect By)缺陷所属模块 (subject)指派缺陷的版本(Defected in release)指派给谁处理 (assigned to)缺陷状态 :status:new open,rejected ,fixed,reopen,closed缺陷的严重程度: urgent,very high high,medium,low优先级 urgent,very high high,medium,low缺陷的严重程序和优先级的关系：严重程

10、度一般不会修改，优先级可以适当妥协，严重程度较低的，但是优先级可能最高。4、 第一个软件缺陷的领导者是美国海军将军，编译器的发明者，领导了 cobol 语言，（面商业的通用语言）-cobol common business oriented language5、 以另外一种方式来思考，两个人对同一个软件都会持不同的见解，一个说很完美，一个说缺陷很多，一定是一个人以某种运行软件时暴露了大量的问题。6、 软件结构的分类单机软件C/S(client/server 客户端 )服务器：如： qc,msn,qq ，游戏，特点：客户端采用专门的软件分布式软件B/S(broner/server) 浏览器 /

11、服务器电子商务网站， 论坛，优点，软件的更新，只需要服务器程序。客户端：是更新后的效果，开发维护容易。不足：客户显示效果不如b/s ，但是目前正在优化，朝着 (rich client 富客户端趋势发展)，技术 javascript jquery7、 主流的浏览器IE,firefox,safari( 苹果 ),chrome ，opear8、 ENIAC:电子数字积分计算机， elect onic numberical integrator and caluator美国宾西法尼亚大学，莫尔学院， 19469、 测试的步骤（1）编写测试用例（ 2）编写测试用例（ 3）执行用例，发现缺陷，提交缺陷报告

12、（ 4）验证所发现的缺陷是否得到修改（ 5）编写测试总结报告10、测试计划的组成简介参考文档测试文档提交文档熟悉系统需求编写测试计划执行用例测试进度总结报告Alpha 测试Beta 测试测试资源描述严重程度问题的严重程度和优先级缺陷优先级缺陷跟踪及返测版本号风险分析测试策略黑盒测试，白盒测试，灰盒测试手工测试、自动化测试，基准测试并发测试综合场景测试功能测试，性能测试疲劳强度测试内存泄漏测试数据容量测试极限测试递增测试安装测试硬件兼容测试策略兼容性测试软件兼容界面测试文档测试恢复测试回归测试易用性测试对比测试测试负载测试 70 吨是负压力测试 70 吨是压力容量测试 60 是容量测试策略中的术

13、语：黑盒测试 （功能测试）：软件测员只需要知道要什么-而无法看到盒子里的软件是如何运行的。只要进行一些输入，就能得到输出结果。他不知道软件如何运行，为什么这样，只知道程序做了什么？动态黑盒测试常常称为行为测试，因为测试的是软件在使用过程中的实际行。有效的动态测试需要关于软件行为的一些定义-即需求文档或产品说明书。好的产品说明书会提供这些细节。白盒测试（透明盒测试） ：软件测试员可以访问程序员的代码，并通过检查代码的线索来协助测试 -可以看到盒子里面。 测试员根据代码检查判断多或少可能出错的数据。并据此定制测试。 有时也称为结构化分析，找出动态黑盒测试难以发现或隔离的软件缺陷，为黑盒测试测试员在

14、接受软件进行测试时设计和应用测试用例提供思路。动态白盒测试是指利用查看代码功能（做什么）和实现方式（怎么，做）得到的信息来确定哪些测试， 哪些不需要测试，如何开展测试，如何开展测试。 动态白盒测试的另一个常用名称是结构化测试，因为软件测试员可以查看并使用代码的内部结构从而设计执行测试。动态白盒测试不仅仅是查看代码的运行情况，还包括直接测试和控制软件，动态白盒测试包括以下四个部分：直接测试底层函数，过程，子程序和库，在micrsoft windows中这样 称为应用程序编程接口（ API）。以完整的程序的方式从顶层测试软件，但是根据对软件运行的了解调整测试用例； 从软件获得读取变量和状态信息的访

15、问权，以便确定测试与预期结果是否相符，同时强制软件以正常测试难以实现的方式运行；估算执行测试时“命中”的代码量和具体代码，然后调整测试，却掉多余的测试用例，补充遗漏的用例。一定不要把动态白盒测试和调试(debugging) 搞浑了， 不是一个概念。 动态白盒测试的目标寻找软件缺陷， 调试的目标是修复缺陷。 软件测试员应该把问题缩减为能够演示软件缺陷的最简化的测试用例。 如果白盒测试， 甚至还要包括那些值得怀疑的代码行信息静态测试：测试不运行的部分，只是检查和审核。如果要进行了动态白盒测试的思路：一，首先可以确定模块属于程序中的底层模块，可以由高层模块调用，但是自己不能调用其他模块，通过查看代码

16、可以确认这一点。（合理的做法是编写一个测试驱动以独立于程序其他部分的形式测验该模块），测试可以是多种形式的，可以是输入字符串并查看结果的，也可以是文件读取测试字符串的预期结果的独立程序。二，分析说明书， 确定应该采用户黑盒测试用例，运用等价类划分技术减少测试用例集合。在进行了白盒测试之前，一定要根据说明书建立黑盒测试用例，用 这种方式可以真正测试模块的功能和作用。如果先从模块的白盒角度建立测试用例，检查代码，就会偏向于以模块工作方式建立测试用例。程序员或许误解了说明， 于是测试用例就会不对。动态测试：是通常意义上的测试- 使用和运行软件。10、11、缺陷报告要注意的问题（ 1） 一个报告只提交

17、一个缺陷（ 2） 缺陷描述准确，易读，使用最少必须步骤，保证缺陷可以重现，缺陷的描述要做到追根溯源，简明扼要，面面俱到。制定统一的 checklist，并且经过项目负责人的评审， 如果遇到歧义， 和开发人员交流，以 checklist 为准，对缺陷的严重性，优先级准确，客观。（ 3） 在提交缺陷时，一定要认真审核，确保缺陷是有限的。（ 4） 不要为了引起开发的重视而夸大缺陷（ 5） 及时报告缺陷（ 6） 不做任何评价（ 7） 对于不可重现的缺陷也要报告（ 8） 因类测试人员以边界值或错误猜想法的设计用例而发现的缺陷，可能引起开发的不认同，测试人员要分析引导开发了解系统的潜在风险，提高开发人员的

18、质量意识。12、 缺陷报告的处理流程测试人员提交缺陷报告new开发经理 / 项目经分配缺陷报告理open开发人员处理缺陷报告fixed测试人员返测通过关闭13、 八种编写测试用例方法（ 1） 等价类（ 2） 边界值（ 3） 因果法（ 4） 判定法（ 5） 场景法（ 6） 正交法（ 7） 状态转换法（ 8） 测试大纲法（ 9） 随机测试（猴子测试）等价类：对程序的规格说明有意义的，合理的输入数据集合。如果用户输入的是有效等价类中的数据，程序应该正确计算执行。等价类划分把海量（无限）的测试用例减得很小。一个等价类和等价划分是指测试相同目标或者暴露相同软件缺陷的一组测试用例。步骤：一、划分等价类，二

19、细分等价类，三建立等价类，编写测试用例适合场合： 任何有输入的地方都可以使用等价类。无效等价类：对程序的规格说明不合理无意义的输入数据集合，如果用户输入无效等价类中的数据，程序应该给予错误提示，不允许用户输入。相比于有效等价类，无效等价类主要软件的健壮性（容错性），程序异常处理能力。是选择等价类的原则： 对于不同的有效等价类， 尽可能在一条测试用例中使用测试仪，这样可以减少测试数量，在一条用例中覆盖多的有效等价类，对于不同控制的无产等价类， 一条用例只覆盖一条，一个控制的无效等价类，可以考虑无效的组合，排除其他因素的干扰。(注：老采矿者的话，适用于这个原则：“出去找一样东西，并且就只找这样东西

20、” 。根据一些关键的关键来进行等价划分，这些关键就是：边界条件，次边界条件，空值，无效数据（非法，错误，不正确，垃圾数据（重复，压迫，重负），默认值，空值， 0 值，空白，无等价类划分的目标： 把可能的测试用例集缩减到可控制且仍然足以测试软件的范围内。不过，为了减少测试用例的数量的过度划分等价类，就有漏掉那些可能暴露软件缺陷的风险。边界值法：一般取六个值。边界的数据类型：数值，字符，位置，数量，速度，地点，尺寸而这些类型需要考虑的特征：第一个 /最后一个 ,最小值 /最大值 ,开始 / 完成 ,超过 /在内 ,空 /满 ,最短 /最长 ,最慢 / 最快 , 最早 / 最迟 ,最大 / 最小 ,

21、最高 / 最低 ,相邻 / 最远。软件的每一部分寻找边界是非常重要的， ，边界就会发现得越多，可能得出的软件缺陷就越多。因果法：因果法适合场合：因果限制每个控件的条件，不宜过多，最多两个，比较适合单选钮，复选框，下拉列表。四个因果符号：恒等=非 或 V与 因果中的条件：互斥E包含 I唯一 O要求 R屏蔽 M使用因果法的步骤： （ 1）找出所有的输入动作，编写，（2）找出所有的结构。（3）在步骤 1 的基础上，找出输入动作限制关系和组合关系。如 2,3 互斥注：哪些是不能组合的，哪些是能组合在一起的确，是测试用例的数量。（ 6） 在步骤 2 的基础上，找出输入输出的限制组合关系。（ 7） 什么样

22、的输入组合步骤，会产生什么样的输出组合（ 8） 根据判定表编写测试用例正交表：正交排列法是以正交表为基础的，根据控制的个数与每个控制取值个数不同，选定一个合适的正交表后，然后进行映射即可。正交表的使用场合：在一个界面中有多个控件，有多个值，测试时考虑不同组合。LnMkN 下标 k 上标N 表示表的行数，也就是需要测试的组合的次数。M 是每一个控件的取值个数（各因素的水平数，在因素状态数表示每个摈件有两种选择）使用正交表编写测试的步骤：（1） 根据控件的个数把每个控件的取值个数，选择一个合适的正交表编写用例。（2） 把程序的控件的取值整理成表格（熟悉需求）（3） 把控件名称映射到正交表，把每个控

23、件取值正交表的每道取值。（4） 编写测试仪用例。正交表的一对应一条用例。正交表的特点：正交表的思想选择数据时要均匀，零星一的进行的进行选取，而不能集中某个局部，保证控件都组合，并且每个控件组合的次数都在应该相同，每个控件的取值应该接近；控件的取值个数相同最多个（也就是说其中的选项数都是几种，如打印范围和颜色灰度都是 3 可选项，所以选底为 3 的，按控件值最多的选取， ）注：正交表360 网盘场景法：场景法的定义模拟用户使用可能场景（情景）主要测试仪软件重要功能，是否实现，此方法结合等价类使用，以软件需求为中心，充分理解业务之上，以等价类为基础。场景法的主要概念，基本流（正确流） -有效等价类

24、 -按照正确的业务流来实现的一样操作路径。备选流（出错流） -无效等价类，导致程序出错。状态转换图的应用场合把所有的状态操作步骤，操作顺序是场景法具体实施应用。核心：一连串状态分解，进行程序分析，可以把复杂的程序，流程简单化。定义：找出软件的所有状态惟及导致状态变化的所有的输入动作，进而图形的方法把相关联的用户输入动作状态一起，真实的模拟出用户操作顺序流程，编写测试用例。状态转换图的步骤： （ 1）找出程序的所有的输入入动作，并进行编号，找出所有的状态，找出是什么动作导致状态发生，画出状态转换图（一般情况下这是个反复的过程）把关联的动作和状态联系起来。状态转换图注意事项：每种状态的至少访问一一

25、次，无论用什么办法，每一种状态都必须测试；从一种状转入另一种状态所需的输入和条件；进入或者退出某种状态时的设置条件及输入出结果。测试看起来最常见最普通的状态，可以根据产品说明书，通过与客户开发人员沟通，了解哪些是常用更重要的：测试状态之间最常用户分支，这此分支最容易产品设计者忽略，也要测试测试所有错误状态及其返回值，错误提示不正确等情况是常有。测试大纲法：应用场合：在程序和模块中，涉及到多窗口和多动作间有一定关联性，为了弄甭窗口口之间的关系，或者说动作与动作之间的关系，我们可以用大纲法测试大纲法， 找出所有窗口以及窗口的输入动作。找出窗口与窗口之间的关联。随机测试：向普通用户一样，对软件进行测

26、试。测试方法的重要级：高到低场景法 / 等价类和边界值 / 因果法 / 判定表 / 正交排列法 / 状态转换法 / 测试大纲法 / 使用错误猜测和随机 / 测试补充用例（根据需求文档中如果有错误类型，用报错来看用例有无遗漏，特别适合硬件测试的错误码报错）个人觉得这么多方法，就场景，等价，边界值是最最常用的。14、 软件测试阶段的划分单元测试的概念：针对性每个单元的测试，确保每个模块正常工作。在底层进行的测试称为单元测试（ unit testing ）或者模块测试 (module testing) ，单元测试，底层软件缺陷被找出并修复之后，就集成在一起，对模块组合进行了集成测试。直到整个产品，至

27、少是产品的主要部分，在称为系统测试的过程中一起测试。驱动模块：模拟上一个模块（调用被测模块的那个模块）集成测试：通常单元测试基础上，将所有的程序模块进行了有序的测试。集成测试是检验单元或部件的接口关系，逐步成为符合要求程序部件或整个系统。自顶向上：成佬，深度优先。自底向上；面向过程的系统采用的两种方法。系统测试仪：对集成的软件进行了整理体的测试仪确认测试，在系统测试之前，对软件的重要性进行测试，确认软件的主要功能，可以全面的系统测试修复。Alpha 测试：开发环境下进行的测试，由于开发方包括测试仪人员进行的测试，主要由用户参与，最好在测试仪人员的指导下，进行了全面细致的测试仪，Beta 用户环

28、境下进行测试，主要由用户参与，最好在测试人员的指导下，进行了全面细致的测试。自顶向下单元测试增式集成集成测试自底向上非增式集成混合测试系统测试：功能性测试、安全性测试、可靠性，负载测试、易用性测试，强度测试仪，配置安装测试仪，卸载测试，文档测试，故障恢复测试，界面测试，容量测试，兼容性测试，分布置式测试，可用性测试仪。Alpha 测试验收测试Beta 测试15、 测试模型正式验收测试V 模型需求分析验收测试系统测试概要设计集成测试详细分析编码单元测试W 模型用户需求V&V用户需求验收测试设计需求分析与需求分析与系统测试 V&V 确认与与系统设计系统测试设计概要设计详细设计V&V 单元设计测试详

29、细设计单元测试编码W 模型有两种交付验收测试实施确认测试集成集成测试需求测试系统安装验收测试需求分析概要设计系统构建系统测试概要设计详细设计详细设计模块集成集成测试编码实现单元测试W 模型也有局限性， W 模型和 V 模型都把软件的开发 视为需求，设计，编码等一系列的串行的活动，无法实现迭代，自发性，变更调整。X 模型程序片段封版测试设计执行测试工具配置测试设计编码完成执行模型工具配置工具配置集成测试设计探索性测试程序片段执行测试X 模型是对 V 模型的改进， X 模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的效接，通过集成最终为可执行的程序。X 模型的左边描述的是针对单独

30、程序片断进行编码和测试，此后将进行频繁的交接，通过集成是终成功可执行程序。 然后对这些可执行程序进行测试， 已通过集成测试的成员可以封装并提交给用户， 也可以作为更大规模和范围内集成的部分。 多根并行曲线的变更表示可以在各个部分发生， X 模型还定位了探索性测试，这是不进行事先测试的特殊类型的测试。这一方式往往能帮助有经验的测试人员找出更多的软件错误，但这样可能对测试造成人力，物力财人的浪费，对测试人员的熟练度要求高。H 模型测试流程测试准备测试执行其它流程H 模型提示了一个原理，软件测试是一个独立的流和，贯穿于产品整个生命周期，与其它流程并发操作。软件测试过程模型V 模型是软件开展瀑布的模型

31、的变种，要反映测试活动分析设计的关系，局限性：把编码作为最后一个活动，需求分析产生的错误直到后期的验收测试才能发现。W 模型增加了开发阶段的同步测试仪，形成W 模型，测试与开发同步进行，有利用尽早发现问题。局限性：仍把开发活动看成需求开始到编码的串行活动。只有上一阶段完成才能进行一下一阶段的活动，不能支持迭代，自发性以及变更调整，主H 模型是完全独立的， 某个测试点准备就绪时， 就可以从准备阶段到测试执行阶段，软件测试可以尽早的进行软件测试可以根据被测试物的不同而分层次进行。V 模型强调了整个软件项目开发中需要经历的若干个级别，并与每一个开发并发对应，忽略了测试对象不应该仅仅包括程序，没有明确

32、指出需求设计的测试。W 模型：补充了 V 模型中忽略的内容， 强调了测试计划等工作的先行对系统需求和系统设计院的测试，与 V 模型要相同，测试软件测试进行流程的说明H 独立的，只要测试准备完成，就可以执行。软件测试 ron patton 张小松16、 软件测试工程师应该具备的素质：（ 1） 探索者（ 2）故障排除员（ 3）不放过任何蛛丝蚂迹难以重现的缺陷不会当作偶然而放过 。（ 4）追求完美，当无法企及时，不苛求，尽力接近目标。好的软件测试人员知道何时无法企及完美，何时时达到够好。（5） 判断准确（ 6）注重策略和外交（ 7）善于说服（ 8）学习能力强（ 9） 表达能力强、沟通能力 (10)耐

33、心 (11)细心 （ 12）信心 （13）责任心 (14)能承受抗压能力 (15)软件测试是一项批判性工作， 所以要具有批判性精神， 软件测试是一项要坚持必要的原则的工作(16)好的软件测试人员，要对软件的开发全过程有个总体的了解.17、软件失败的术语：缺点： dffect 偏差： variance矛盾： inconsictency缺陷： bug异常： anomaly故障： fault 错误 :error失败 :failure问题： problem特殊： feaure事件 incient术语的多样化由于公司文化和开发软件的过短。公司或开发小组用来称呼软件总理的意义不是很重要，但重要的是， 讨论

34、用什么词来描述软件问题意义在于：对软件测试员来说了与自己合作的产品开发小组的特点是很重要的， 提及软件问题的方式反映出他们处理整个开发的过程的方式，可以看出他们是谨慎，小心还是简单生硬。18、产品说明书辅助性术语： 产品说明书有时称为说明 (spec)或产品说明书 (product spec) ，是软件开发小组的一个协定，它对开发的产品进行了定义，给出细节，如何做，做什么，什么时候做。19、软件缺陷的修复费用软件缺陷的费用是随着时间的推移而增加的，费用指数级的增长，随着时间的推移，费用呈十位增长。1000100101说明书设计编码发布20、软件测试员的目的软件测试员的目的是尽可能找到软件缺陷并

35、确保期限得以修复，但要记住，“修复”并非指软件一定要改正软件，可以在用户手册中加一段注释或为用户提供特殊的培训 （这样也算处理发生一部分的缺陷的方式）21、几个臭名昭著的软件错误的研究迪斯尼的狮子软件缺陷是由于兼容性测试没有做到位的著名案例，因为没有做好兼容性测试的工作，所以带来了昂贵的成本代价，如果早一点发现缺陷就不会产生后期如此大的影响。英特尔奔腾浮点除法说明是对软件缺陷的重视程序和处理方式会极大的影响企业。所以这里再次证明运用缺陷规则中第5 点，要注意的事，无论什么不对劲的地方，都要定义为缺陷，即使不修改也要在用户手册中说明，因为处理缺陷的方式好坏，很大程度上会有后期影响。美国航天局火灾

36、星极登陆者探测器，这个软件缺陷从测试阶段上来看完全是因为没有按照测试阶段执行完成，不进行系统测试带来的问题。爱国者导弹防御系统这个软件缺陷要值得注意的地方是在测试的时候再小的问题也要引起重视，并分析后期带来的影响。千年虫的问题，在1974 千年虫的问题测试时一些预见的措施不足，危险的预见 2004 说明预见能为我们屏蔽很多潜在风险，降低或减少一些不必要的成本支出。千年虫的中，程序员应该对这个显疏忽疑问而不是仅仅将程序设计到1999 年，由于他没有这样做，软件测试人员就应该测试并发现该缺陷，然后由开发小组确定是否修正。22、软件行业中，用来描述制造并交付他人的软件产品组件术语是可交付部分（ de

37、liverable ），解释所有的可交付部分是最简便的方法是分门别类。23、一个软件产品的诞生要经历的步骤：产品说明书产品审查设计文档进度表测试计划以前版本用户调查软件体系结构易用性数据软件代码竞争对手的信息外观说明最终产品对客户的研究结果，其实只是原始材料，并没有描述要做的产品，只是确定是否需要（不需要） 以及客户要求的功能，产品说明书上综上述信息以及没有提出必须要实现的需求，真正地定义产品是什么时候，有哪些功能，外观如何，产品说明书千差万别，有些非常严格，一旦定没有特殊理由是不作更改的，而有些开发小组可以直接在餐巾纸上写出产品说明书，这样做的好处是非常灵活，但是存在的风险并非所有人站在一起

38、，而且最终的产吕在开发前是什么时候样的无从得知，其实这种就相当于开发模型中的大爆炸模型，软件产品的一个关键部分是进度表，必须要有某种机制来跟踪进行度，从简单的Ganntt 图表到使用项目软件详细跟踪每一分钟的任务，各种机制不一而足，制定进度表的目的是了解哪项工作做了， 还有多少工作要做，何进全部完成。软件设计文档，对于一个稍大一些的程序需要有1 个设计过程来规划软件如何编写。24、常见的软件设计文档的清单，结构文档，描述软件整体设计的文档，包括软件所有的主要部分的描述以及相互之间的交流的交互方式。数据流图：表示数据在程序中如何流动的正规示意图，有时称为泡泡图，因为它是用圆圈和线画的。状态转换图

39、，把软件分解为基本的状态或条件的另一种正规示意图，表示不同的状态间转换的方式。流程图：用图形描述程序逻辑的传统方式。流程图现在不流行了，但是一旦投入使用，根据详细的流程图编写程序代码是很简单的。代码注释：你写 1 次代码，别人至少得看 10次，在软件代码中嵌入注释是极极其重要的。便于维护代码的程序员轻松掌握25、测试文档：测试计划（测试计划前面有细展开），测试用例，缺陷报告，测试工具和自动化测试，度量统计总结，用户手册（用户手册是测试文档的重点），联机帮助 /帮助文件，指南向导，样例、示例和模块，授权/ 注册登记表，最终用户许可协议，广告和宣传，错误信息，图票和标志，说明文件，标签和不干胶，产

40、品支持信息。26、错误提示：错误提示是软件产品最容易忽视的部分，通常是由程序员来写，他们很少计划这些信息。27、软件项目 / 程序经理 / 监制人员：驱动人员：驱动整个项目，他们通常负责编写产品说明书，管理进度，进行重大的决策，体系架构师/ 系统工程师 /产品小组技术专家，他们经验丰富，可以胜任设计整个系统架构和软件和程序员工作密切。程序员，开发人员，代码制作设计者，设计并编码软件，修复软件中的缺陷，他们和项目经理和设计师密切合作制作软件，然后和项目经理测试密切合作，进行测试并报告发现的问题，软件测试和质量保证是存在差别的。技术作者，用户协调专员，用户培训专员，手册编写员，文案专员，编制软件产

41、品附带文件，配置管理员，负责把程序员的代码和技术作者写的资料组合在一起，合起来成为一个软件包。28、开发模型大爆炸模型，边写边改模型，瀑布模式，螺旋模式，四种模式是常用模式，但实际软件开发中不止四种，每个模式都有自己的优缺点。作为软件测试员，可能遇到以上所有模式，你需要采用当前的模式来制定测试技术，大爆炸的优点是简单， 计划，进度安排与正规的过程几乎没有，所有精力花在开发软件和编写代码的基础上。这样的情况下，因为他们直到最后才知道会拿到什么软件。边写边改模式是项目小组未有杉其他开工模式时采用的开发模型，这是大爆炸基础上更进一步至少考虑了产品需求。作为边写边改的项目软件测试员，需要和程序员一样清

42、醒地认识到自己将陷入无休止的循环往复。几乎每一天都有可能拿到软件版本并着手测试，边写边改是最有可能遇到的。这种模式是软件开发的入门。瀑布模型的步骤：构思分析设计开发测试最 终产品端采用瀑布模型的项目从最初的构思到最终的产品都要经过一系统步骤，每上步骤结束时，项目小组组织审查，并决定是否进行下一步，如果项目未准备好的放话，就停滞下来。瀑布模式非常强调产品的定义。 注意，开发或编码阶段， 只是其中单独的一块，瀑布的分布步骤是分立的， 没有交叉的。 优点： 对于拥有精确清晰的产品定义的训练有素的开发人员而言的项目，该模式的效果较好。该模式的目标是在编写代码之前解决所有的未知，并明确所有的细节都已确定

43、并有文档记录。而且实现在软件之中，测试小组得以制订精确的进度和计划，测试对象非常明确，在分辨功能还是缺陷上一点问题也没有。缺点：因为测试仅在最后一次进行，所以在一些根本性的问题可能出现在早期，但是直到准备发布产品才有可能性发现。螺旋模式不太理想，但该模式确实经历了很工的路来解决其他模式中存在的问题，同时有一些好的突破。螺旋模式于1986 年 barry boehm 在美国计算机种工发的螺旋模式加强螺旋模式每一闪循环包括六个步骤一，确定目标不，可选方案，限制条件，二明确并化解风险，三评估可选方案，当前阶段开发和测试，计划下一阶段。六确定下一阶段的方法。螺旋中包含了一点瀑布模式（分析，设计，开发，

44、测试的步骤）边写边改模式（螺旋模式的每一次） 和大爆炸模式 （从外界观察） ，加上该模式发现问题早，成本低特点，可以说是非常好的开发模式。软件测试喜欢该模式，因为通过参与最初的设计阶段，可以最早的影响产品，可以把产品的整个来胧去脉弄得很清楚， 并在项目末期， 不至于最后一分钟还在匆匆忆忙的测试。 软件测试的工作测试仪一直在进行以最后一步只是验证表面的部分没有问题。敏捷软件开发： 敏捷软件开发一目的通过过程和工具理解个人的交流，通过全面的文档， 理解运行的软件，通过合是的谈判得到客户的协作，在计划的执行中做作用变更的响应。也主浊说，在某一方面，有的时候，更应评价在另一方面的价值，。敏捷软件一发很

45、容易偏离主题而造成混乱。一种方法是观察，了解，再决定是否采用此方法，每一个公司，每一个项目，每一个小组都会选择适合自身的情况的模式，选择有对的， 也可能是错的。 软件测试的工作是所处的开发环境中最大努力的工作。29、造成软件无法完美有四点原因？输入量破译多，输出结果太多，软件执行路径太多，软件说明书是主观的30、软件测试是有风险的如果不去测试所有的不选择了冒险。如何把数据巨大的可能的测试减少到可以控制的范围，以及如何针对风险做出明智的选择，哪些测试重要， 哪些不重要，测试量和发现缺陷之间是有关系的，我们的目标是找到最优的量，使测试不多不和，软件测试工作和防疫员的工极为相似，可以报告担缺陷的存在

46、， 你可以测试，并报告缺陷的存在， 任何情况下都不能保证软件缺陷没有了。唯一的方法是继续测试，可能还会找到一些。31、找到的缺陷越多，说明软件缺陷越多生活中的害虫和软件缺陷一样， 两者成群出现。 软件测试人员会在很长时间内找不到缺陷， 接着找到一个， 之后很快找到第2 个。可能的原因： 程序员也有心情不好的时候， 程序员往往会犯同样的错误，某些软件缺陷是冰山一角， 软件测试人员会发现某些缺陷开始似乎毫无关联，但是最后发现它们是属于同一逐步形成主要原因造成的。软件缺陷一个接着一个，反过来， 怎么也找不到缺陷，也是有可能的， 就是软件真的经过精心设计，确实是真的存在极少的缺陷，所以很难找。32、杀

47、虫剂怪事用于描述软件测试越多，其对测试免疫力越强的现象（注：确实，这个现象自己也深有体会， 一些前被经过提及的缺陷在后期的开发上，程序员也会有意识地避免掉发生一些问题。所以就重复的问题会变少。）每一圈都要重复测试过程，每一次循环都要接到软件进行测试，经过几个回合， 能发现的软件缺陷都妇现了，再测试下去也不会有新的发现。克服这种杀虫剂怪事的现象（就是对测试免疫力增加）：软件测试员必须不断编写不同的测试程序， 对程序的不同部分进行测试（做测试到编写测试程序对测试人员更高的要求，编写用例弱爆了）33、不是所有的软件都要修复，不需要修复的软件缺陷有这些原因（一）没有足够的时间 （二）不算真正的软件缺陷

48、 （三）修复的风险太多 （四）不值得修复决策过程通常由软件测试人员、 项目经理和程序员共同参与。 站在各自的立场上看待缺陷是否应该或不应该修复都有自己的看法和观点。但是关于错误决策的后果：只有时间才能说明这样的决策是对的，还是错的。英特尔处理器的缺陷34、什么时候是缺陷难以说清楚?软件中存在问题， 程序员没有发现，测试员没有发现，用户没有发现， 是否算缺陷？没有答案。从另外的角度看， 两个人对于同一个软件产品的质量持有完全不同的看法和见解。一个人会说，软件缺陷很多， 一个人说软件很完美。那么一定是一个人以某种方式运行时显露了大量软件缺陷，而另一个没有这样做。尚未发现和观察到的缺陷称为潜在缺陷。

49、记住一句话：一棵树倒在没有人听到的森林中，它发出声音了么？而不能不能判定的是否为缺陷的情况下我们要进行确认和验证两个过程。35、产品说明书从没有最终版本假定我们的产品有一份最后定版的且不得更改的产品说明书。有了竞争对手，发布了类似的产品， 继续按照产品说明书开发， 发布没有竞争力的产品和重整人马，重新讨论产品功能，重写说明书，弄好经过修订的产品， 明智是选择是后者。作为软件测试人员应该要想到产品说明书可能发生改变。未曾计划测试的功能会增加。所以灵活地制订测试计划和执行测试的技术。36、软件测试的目标？软件质量保证人员的目标？测试：尽可能早地找出缺陷，确保其得以修复（testing ），最理想的

50、是在软件代码编写之前。质量保证人员： 主要职责是创建和执行改进软件开发过程并防止软件缺陷发生的标准和方法。 (quality assurance QA)测试和质量保证的工作会有交叉之处37 、软件测试是检查和批评同事工作，挑毛病，公布发现的问题，普遍不会受欢迎。保持成员和睦的建议：早点找出缺陷，控制情绪，不是总是报告坏消息。37、软件开发过程和软件测试两个基础的概念？两者是有区别的， 不是一个意义， 不能误用和混淆。 软件行业很多看似乎相同的术语很少取得一致认识。软件测试员应该常常澄清 小组中使用术语的含义，最好在术语定义上取得一致而不是在“正确性”上争论38、精确和准确？软件测试人员必须要知

51、道精确和准确之间的区别。最好的结果是准确和精确的完全结合。（注：个人感觉个人准确和精确在错误提示这一块也有明显的体现）软件测试要精度还是要准度很大程序上取决于产品是什么，最终取决于开发小组的目标 。39、确认和验证确认和验证两个词常常互换使用， ，但是他们的定义对于软件测试的区别是很重要的。 确认是保证软件符合产品说明书的过程，验证是保证软件满足用户要求的过程（注：可以间确认的参照物是产品说明书，验证的参照物是需求本身。如果不通俗， 再举这样一个例子可能形象一些， 如果有一个功能是拿一杯水来，那么这个过程中看水看来没有是确认的过程， 而拿水这个功能背后的真正需求是口溻， 那么我们要验证的是解渴了么？在我们发现了一个问题后， 无法判定它是不是一个缺陷的情况下， 或者定义为缺陷没有那么直观， 那么我们要进行确认和验证两个过程。 先看产品说明书，