软件测试理论基础一、软件工程：从管理、技术两方面来研究如何更好的开发、维护计算机软件的学科。
七条基本原理：1、用生命周期计划严格管理生命周期：可以概括为定义、开发、应用和维护四个时期需求提出→可行性分析→高度化设计(HLD) →详细化设计(LLD) →coding（编码）→test（测试）→上线→售发生命周期中的计划：项目概要计划里程碑计划项目控制计划产品控制计划验证计划运行维护计划项目具有特定性，产品不具有特定性2、坚持进行阶段评审评审：（做质量保证的人）提前发现错误减少软件的损失QA 质量保证quality assuranceQC 质量控制quality control3、产品一致性控制及时的更新变更CCB 控制变更委员会(control changing )基准配置管理：（变动控制）文档、代码打上标签如：配置管理工具VSS4、采用最新的软件设计技术5、清楚地审查软件产品6、人员应该少而精7、不断改进软件工程的实践性持续改进：不断的在工作、测试中发现bug并且改进的过程测试体系、测试咨询常用的术语文档的英文名称软件需求说明书HLD 概要设计LLD 详细设计Coding 编码Unite test 单元测试System test 系统测试UAT 验收测试1、瀑布模型：软件生命周期的阶段和工作内容：阶段研究问题给出的标准和文档问题定义问题是什么？目标个规模报告书可行性研究有可行的方法吗？高层逻辑模型、数据流图、成本效益分析需求分析系统做什么逻辑模型、数据流图、数据字典、算法描述总体设计如何解决问题？系统流程图、系统结构层次图详细设计怎样具体实现？编码规格说明、HIPO图或PDL编码和单元测试给出正确的程序模块源程序清单、单元测试方案和结果综合测试给出符合要求的软件综合测试方案和结果、一致的软件配置维护持久的满足用户需求完整地维护记录、文档、软件新版本2、‘V’模型：需求分析验收测试（UAT) 概要设计系统测试详细设计单元测试Coding二、软件质量1、质量与质量模型因素（特性）：如正确性、精确性、可靠性、容错性、性能、效率、易用性、可理解性、简洁性、可复用性、可扩充性、兼容性等。
2、质量保证软件测试概念验证程序是否符合需求的一个过程测试：1、它能做什么2、它不应该做什么概念;广义：软件生存周期中所有的检查、评审和确认工作，其中包括了对分析、设计阶段、以及完成开发后维护阶段的各类文档、代码的审查和确认。
狭义：识别错误测试目的：为了度量和提高被测试软件的质量，对测试软件进行工程设计、事实和维护的整个生命周期。
测试分类：1按阶段分：单元测试：集成测试：系统测试：验收测试：2.按目的分（1）功能测试（2）非功能测试：A.性能:a.并发（响应时间）b.稳定性（7*24 5*8查找内存泄漏）c.容量测试，d.压力测试。
*测试数据的准备1.编造数据2.从项目组或生产环境中获取。
B．安全测试（复制链接，回退）C．界面测试（布局要合理，色调风格一致）D．易用性测试，安装/卸载测试E．本地化测试，兼容性测试，恢复/备份测试（实时系统）F．健壮性测试，可靠性测试（少）3透明度分白盒测试黑盒测试灰盒测试4执行方式静态测试动态测试二．测试要点1.测试规律BUG的80-20的原则1.在分析，设计，实现阶段的复审和测试工作能够发现和避免80%的Bug。
2.而系统测试又找到其余Bug的80%。
3.最后的5%的Bug只可能再有用户的大范围，长时间使用后才会暴露出来。
木桶原理软件质量不是只有软件测试一个方面决定的它是由各个方面共同决定的。
2.测试的重点1.良好的用例设计，2.好的测试工作管理（使工作有条不紊的进行减少风险）3.独立的测试环境4.软件测试的质量可以发现以下软件缺陷：1软件实现的功能的不正确2.‘缺少’软件没有实现的某个功能3.’多余”软件实现的某项功能在需求中没有定义。
软件测试本身的质量在于：发现软件缺陷并能区分其类型，提供关于软件质量和开发过程质量的信息。
5.软件测试度量A测试覆盖率：（a有多少需求被测试用例所覆盖。
被覆盖的需求/总需求*100%b被执行需求/总有效需求*100% 需求执行率或被测率c执行用例数/总用例数*100% 用例执行率（考察测试人员工作效率）d通过的用例/总的执行的用例*100% 用例通过率（评价软件质量）) B缺陷发现率：1.缺陷数目（1）统计个数（按严重级别按功能分布按开发人员按缺陷状态等统计）缺陷修复率=修复并已经通过的缺陷/发现的有效缺陷总数*100%缺陷遗留率=上线后发现有效缺陷/测试发现的有效缺陷*100%（考核测试人员）C测试成功率2008-8-5笔记一、测试分类1、阶段分：单元unite test （测试单元：把整个代码分成小的单元）最靠近编码集成integration test （自上而下、自下而上、宽度、深度四种集成方式）系统system test （把整个被测系统放到大的系统中测试）验收user acceptance test （由客户组织或委托第三方的测试，测试具有合同约定性质如果通过意味着客户接受了这个系统。
包括性能、功能的测试以及文档）前三个是开发商主导测试只有验收是用户来执行性能performance test功能functional test『Weblogic 中间件(Bea公司开发被Oracle收购) middle ware websphere (IBM公司的)Oracle DB2 用于大型企业SQL server 用于中小型企业Data base administrator 数据库管理员大型企业才会有』2、目的分：功能：检测功能好不好使。
非功能：性能：【性能测试即测试软件处理事务的速度，一是为了检验性能是否符合需求，二是为了得到某些性能数据供人们参考（例如用于宣传）。
】性能测试涉及--测试数据的准备：编造、从项目组或生产环境中获取并发：多人在线操作，响应时间，要求尽可能的短。
稳定：7*24或5*24小时，不当机不停机，正确执行。
容量测试：大数据的处理。
压力测试：即负荷测试，获取系统能正常运行的极限状态。
界面测试：网站，布局合理。
色调、风格的统一，不能出现窜行、错别字，图片不要过大等。
易用性：用户使用着方便。
安装/卸载（uninstall）：大部分软件都需要安装後才能使用。
安全测试：不允许绕过登录界面，进入系统中来。
本地化：汉化。
兼容性：测试软件运行在不同操作系统下，硬件环境下是否正常恢复/备份：健壮性：在异常情况下，软件还能正常运行的能力。
（含义：1、容错性可靠性测试：一定环境下，在给定的时间内，系统不发生故障的概率。
3、按透明度分：黑盒测试：black box 只注重输入输出，不管里面的实现情况，将整个系统当成一个黑盒子常用方法：等价类、边界值、因果图、错误推测法白盒测试：white box 更注重内部的逻辑结构分支。
灰盒测试：gray box 介于二者之间，即关心输入输出，也关心内部逻辑4、按执行方式分：静态测试：指不实际运行软件，主要是对软件的编程格式、结构等方面进行评估动态测试：运行程序，输入各种值来进行测试。
Alpha测试Beta测试回归测试：regression test 关联性冒烟测试：在测试之前对主功能和主路径的测试前哨测试：确认测试：嵌入式测试：主要测试和硬件有直接联系的软件如路由器二、测试的一些要点1、测试的规律Bug的80-20原则（1）、在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的BUG。
（2）、而系统测试也能找出其余BUG中的80% 。
（3）、最后的5%的Bug可能只有在用户的大范围、长时间使用后才会暴露出来。
80/20原则1、80%的工程量用在20%的需求上2、80%的开发成本花费在20%的部件上3、80%的错误是由20%的部件引起的4、80%的延期或返工木桶原理（1）软件质量的关键因素是分析、设计和实现，测试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会最终软件的质量（2）2、软件测试的重点（1）、测试用例的良好设计：用例覆盖是否全面用例是否有效- 测试用例的设计是整个软件工作的核心- 测试用例反映对被测对象的质量要求，决定对测试对象的质量评估（2）、测试工作的管理：工作有条不紊的进行减少风险- 尤其是对包含多个子系统的大型软件系统，其测试工作涉及大量人力和物力，有效的测试工作管理是保证有效测试工作的必要前提（3）、测试环境的建立：（或独立的测试环境）测试环境应该与实际测试环境一致功能测试：中间件数据库一致性能测试：中间件数据库程序硬件都要一致（4）、软件测试的质量：软件测试可以发现以下软件缺陷-软件实现的功能不正确-“缺少”，软件没有实现某项功能-“多余”，软件实现的某项功能在需求中没有定发现第一类软件缺陷的过程---“验证validate”发现後两类软件缺陷的过程---“确认verification”软件测试本身的质量在于：-发现软件缺陷并能区分其类型-提供冠以软件质量和开发过程质量的信息缺陷的数量+ 严重级别+ 功能分布来评判软件的质量缺陷的数量+ 严重级别+ 功能分布+ 开发人员来评价开发人员的开发质量。
缺陷严重级别共分5级（5）、软件测试度量测试覆盖率：-有多少需求被测试用例所覆盖，代码已经被测试了。
测试覆盖率=已被覆盖/ 总数（有效）×100%需求的执行率=已被执行的/总数*100% 测试执行用例执行率=已执行的测试用例/总数*100% 工作效率用例的通过率=已通过的/总的已执行数*100% 软件质量缺陷修复率=已修复的缺陷/ 发现有效的缺陷×100%缺陷遗留率=上线后发现的有效缺陷/ 测试有效缺陷×100%缺陷发现率-缺陷是何时被发现，并且有多少缺陷已经被发现。
缺陷：按严重性来分类- 缺陷数目- 缺陷的严重性按功能分布按开发人员按缺陷状态测试成功率：3、测试的原则(1)、所有的测试都应追溯到用户需求(2)、应该在测试工作真正开始前的较长时间内就进行测试计划(3)、8/2 原则应用于软件测试(4)、测试应从“小规模”开始，逐步转向“大规模”。
(5)、穷举测试是不可能的。
(6)、为了达到最佳效果，应该有独立的第三方来构造测试。
(7)、不充分的测试是不负责任的；过分的测试是一种资源浪费，同样也是一种不负责任的表现。
1.应当把“尽早和不断的测试”作为开发者的座右铭。
2.程序员应当避免检查自己的程序，测试工作应当由独立的专业的软件测试机构来完成。
3.设计测试用例时应当考虑到合法的输入合不合法的输入以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断；电源断电情况。
4.一定要逐一测试中的错误集中发现现象，这和程序员的编程水平和习惯有很大的关系。