1、软件及软件测试
软件=程序+文档
软件测试=程序测试+文档测试
“程序”是指能够实现某种功能的指令的集合
“文档”是指软件在开发、使用和维护过程中产生的图文集合
2、常见软件系统架构
C/S架构
C/S架构的优点：
1 C/S架构的界面和操作可以很丰富。（客户端操作界面可以随意排列，满足客户的需要）
2 安全性能可以很容易保证。（因为只有两层的传输，而不是中间有很多层。
3 由于只有一层交互，因此响应速度较快。（直接相连，中间没有什么阻隔或岔路，比如QQ，每天那么多人在线，也不觉得慢）
C/S架构的缺点：
可以将QQ作为类比：
1 适用面窄，通常用于局域网中。
2 用户群固定。由于程序需要安装才可使用，因此不适合面向一些不可知的用户。
3 维护成本高，发生一次升级，则所有客户端的程序都需要改变。
B/S
B/S架构的优点：
1、客户端无需安装，有Web浏览器即可。
2、BS架构可以直接放在广域网上，通过一定的权限控制实现多客户访问的目的，交互性较强。
3、BS架构无需升级多个客户端，升级服务器即可。可以随时更新版本，而无需用户重新下载啊什么的。
B/S架构的缺点：
1、在跨浏览器上，BS架构不尽如人意。
2、表现要达到CS程序的程度需要花费不少精力。
3、在速度和安全性上需要花费巨大的设计成本，这是BS架构的最大问题。
4、客户端服务器端的交互是请求-响应模式，通常需要刷新页面，这并不是客户乐意看到的。
3、什么是软件测试
使用人工操作或软件自动运行的方式来检验它是否满足规定的需求弄清预期结果与实际结果之间差别的过程
预期结果
指用户的预期结果
实际结果
指的是软件的实际运行结果
软件缺陷
预期结果与实际结果之间的差别
4、开发人员的测试：是调试（Debug）还是测试（Test）?
调试
在源程序内定为错误
分析错误的原因
修改错误
在程序运行时检验程序功能
测试
诱发错误
重现错误
定位错误(功能·需求·模块)
记录错误
5、软件测试概述-测试原则
软件测试应该遵守哪些原则呢？
原则1：测试能显示缺陷的存在
原则2：穷尽测试是不可能的
原则3：测试尽早介入
原则4：缺陷的集群性
原则5：杀虫剂悖论
原则6：测试活动依赖于测试内容
原则7：没有失效不代表系统是可用的
原则8：测试的标准是用户的需求
原则9：测试贯穿软件整个生命周期
原则10：独立的测试团队
6、测试人员应具备的素质
技术能力（智商）
软件测试知识
测试工具的使用
操作系统
代码能力
数据库知识
网络知识
沟通交际能力（情商）
好奇心
主动沟通
胆大心细
不被别人绑架
要有怀疑的态度
个人素养（五心）
7、瀑布模型
特点：这是一种古老的瀑布模型，反映了实际和测试之间的关系
局限：仅仅把测试过程作为编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，如果前面设计错误，得一直到后期的验收测试才被发现，耗时耗力。
生命周期划分为：
制订计划
需求分析
软件设计
程序编写
软件测试
运行维护
优点：
1、开发的各个阶段班级清晰。
2、强调早期计划及需求调查。
3、适合需求稳定的产品开发。
缺点：
1、依赖于早期的需求调查，不适合需求的变化。
2、单一流程不可逆。
3、风险往往延至少后期才会显露，失去及早纠正的机会。
4、问题在项目后期才开始暴露
5、前面未发现的错误会传递并扩散到后面的阶段，看你导致项目失败
改良：
沿用瀑布模型的线性思想，细化了各个阶段，在某些重要关注的阶段之间掺入迭代的思想。
8、W模型
体现“尽早地和不断地进行软件测试”的原则
用户需求 验收测试准备
需求分析与系统设计 系统测试准备
概要设计 集成测试准备
详细设计 单元测试准备
编码 单元测试
集成 集成测试
实施 系统测试
交付 验收测试
9、快速原型模型
在开发真实系统之前，构成一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。
第一步建造一个快速原型，实现用户与系统的交互，用户对原型进行评价，进一步细化待开发软件需求。通过逐步调整原型使其满足用户的要求，开发人员可以确定用户的真正的需求。
第二步是在第一步的基础上开发出用户满意的软件产品。
优点：
克服瀑布模型的缺点，更好地满足用户的需求并减少由于软件需求不明确带来的项目开发风险，适合预先不能确切定义需求的软件系统的开发。
缺点：
不适合大型系统开发（适合开发小型的、灵活性高的系统）。前提要有一个展示性的产品原型，由此在一定程度上可能会限制开发人员的创新。
10、螺旋模型
螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型和瀑布模型相符合，螺旋模型沿着螺旋螺线旋转，即在坐标的4个象限上分别表示了4个方向的活动
优点：
螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。
缺点：
采用螺旋模型需要具有相当丰富的风险评估的经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失。过多的迭代次数会增加开发成本，延迟提交时间
11、软件测试与软件工程
软件测试与软件工程息息相关，软件测试是软件工程中不可缺少的一部分。
在软件工程、项目管理、质量管理得到规范应用的企业，软件测试也会进行得比较顺利，软件测试发挥的价值也会更大。
要关注软件工程、质量管理以及配置管理与软件测试的关系；在不同的开发模式下，如何进行软件测试
12、测试模型
随着测试过程的管理和发展，测试人员通过大量实践，从而总结出了不少测试模型，如常见的V模型、W模型、H模型等。这些与开发紧密结合，对测试活动进行了抽象，成为了测试过程管理的重要参考依据。
13、V模型
需求分析—》概要设计—》详细设计—》编码—》单元测试—》集成测试—》系统测试—》验收测试
优点：
开发V模型即包含底层测试又包含高层测试
底层测试：检验源代码质量的测试
高层测试：检查整个系统的需要
V模型清楚的标识出软件开发的阶段
它采用自顶向下逐步求精的方式，把整个开发过程分成不同阶段，每个阶段的工作都很明确，因此便于控制开发过程。当所有的阶段都完成之后，该软件的开发过程也随之结束。
缺点：
V模型一大缺点正是它自身的顺序性所导致。到了测试阶段，程序已经完成，错误已经产生，很多前期的错误一直到测试阶段才发现，甚至无法发现，往往无从修改了；
同时实际的开发过程中，在需求阶段就很难把用户的需求完全明确下来，因此，当需求变更时将会导致阶段反复，而且都要重复需求，设计、编码、测试、等过程，返工量非常大，模型灵活性比较低。
1、单元测试：又称为模块测试，针对单一的程序模块进行测试
2、集成测试：又称组装测试，在单元测试的基础上，对所有模块进行测试
3、系统测试：将整个软件看做一个整体来进行测试，包括功能、性能、兼容性
4、验收测试：
（1）内测版：内部交流版本，可能存在有很多bug，不介意用户安装
（2）公测版：面对所有用户，通过用户的反馈再去进行修改
（3）候选版：与正式软件相差无几
14、随机测试（探索测试）
随机测试主要是对被测软件的-些重要功能进行复测，也包括测试那些当前的测试用例没有覆盖到的部分。另外，对于软件更新和新增加的功能要重点测试。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其对以前测试发现的重大Bug,进行再次测试，可以结合回归测试一起进行。
15、灰盒测试
灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，既可保证黑盒的关注点又可掌控白盒的内部结构，但不会去对内部程序功能和运作做详细了解，灰盒测试结合了白盒测试和黑盒测试的要素。
16、黑盒测试的分类
功能测试(funct iontest ing)
-是黑盒测试的一方面，它检查实际软件的功能是否符合用户的需
求。
●逻辑功能测试(funct ionesting)
●界面测试(Test ing)
●易用性测试(usability testing)
●安装测试(installationtest ing)
兼容性测试(compatibillitytesting)
性能测试(performance testing)峰值(后面详细现在了解)
-是软件测试的高端领域，性能测试工程师的待遇和白盒测试工程师不相上
下，通常我们所说的高级软件测试工程师一般就是指性能测试或是白盒测试工程师。
●时间性能(事务响应时间等)
●空间性能(系统资源消耗)
●-般性能测试
●稳定性测试
●负载测试:通过负载测试来确定在各种工作负载下，系统各项性能指
标的变化情况。
●压力测试:通过确定- -个系统的瓶颈或者刚好不能接受的性能点，来
获得系统能够提供的最大服务级别。
17、黑盒测试:
黑盒能发现以下几类错误：
功能不对或功能遗漏。
界面错误。
数据库访问或者处理错误。
性能问题。
黑盒测试的缺点
不能测试程序内部特定部位;
如果程序未执行的代码无法发现;
不可能做到穷举测试
黑盒测试的优点
测试人员不需要了解实现得细节，包括特定的编程语言(没有编程经验的人也可
以设计测试用例) ;
测试人员和编程人员是相互独立的(黑盒测试用例设计与程序如何实现无关) ;
从用户的角度进行测试，很容易被接受和理解;
有助于暴露任何与规格不一致或者歧异的地方;
18、按是否查看源代码
黑盒测试：
又称数据驱动测试，完全不考虑程序内部结构和内部特性，注重
于测试软件的功能需求，只关心软件的输入数据和输出数据。
白盒测试：
指的是把盒子打开，去研究里面的源代码和程序结构。
19、H模型
测试流程：
测试准备:所有测试执行活动的准备;判断是否到测试就绪点;
测试就绪点:测试准入准则，即是否可以开始执行测试的条件;
测试执行:具体的执行测试的程序。
其他流程：
具体开发中的流程，如:设计流程
H模型的优点:
开发的H模型揭示了软件测试除测试执行外，还有很多工作;
软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行:
软件测试活动可以尽早准备、尽早执行，具有很强的灵活性;
软件测试可以根据被测物的不同而分层次、分阶段、分次序的执行，同时也是可以被迭代的。
H模型的缺点:
管理型要求高:由于模型很灵活，必须要定义清晰的规则和管理制度，否则测试过程将非常难以管理和控制;
技能要求高: H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小;
测试就绪点分析困难:测试很多时候，你并不知道测试准备到什么时候是合适的，就绪点在哪里，就绪点的标准是什么，这就对后续的测试执行的启动带来很大困难;
对于整个项目组的人员要求非常高:在很好的规范制度下，大家都能高效的工作，否则容易混乱。例如:你分了一个小的迭代，但是因为人员技能不足，使得无法有效完成，那么整个项目就会受到很大的干扰。
20、敏捷开发模型
敏捷开发(Agile Development)
以用户的需求进化为核心、迭代、循序渐进的开发方法
软件项目的构建被切分成多个子项目
各个子项目的成果都经过测试具备集成和可运行的特征
通过尽早、持续交付有价值的软件来使客户满意
即使在开发的后期，需求变更也是允许的
经常交付可工作软件
项目开发期间，业务人员和开发人员在一起工作
强化激励机制，为受激励的个人单独构建项目在团队内部，最富有效果和效率的信息传 递方法是面对面交谈
可工作软件是进度的首要度量标准
敏捷过程提倡可持续的开发速度
不断关注优秀的技能和好的设计，增强敏捷能力
简化
尽量简化所要做的工作
好的架构、需求和设计出自于组织团队自身
团队要定期反省如何更有效地工作，并相应地调整自己的行为
