软件测试基础理论
软件测试
目录
测试人员应该具备的技能
1. 基本知识
1.1 软件
1.2 什么是软件测试
1.3 软件测试的目的
1.4 软件测试的定义
1.5 软件测试的原则
1.6 软件质量模型（iso9126）
1.7 软件质量模型保证（SQA）
1.8 QC和QA
1.9 软件测试的流程
1.10 软件测试报告包括什么？
2. 软件的bug（缺陷）
2.1 软件的Bug
2.2 Bug的分类
2.3 软件各个阶段的
2.4 常用缺陷管理工具
2.5 提交缺陷注意事项
3. 测试环境
4. 测试人员
4.1 测试人员
4.2 软件测试工程师
5. 测试用例
6. 开发和测试的生命周期
6.1 软件生命周期模型
7. 举例设计模式
8. 软件测试、分类、基本原则
8.1 软件测试基本概念
8.2 软件测试的基本原则
8.3 *软件测试分类
8.4*黑盒测试中的性能测试
9. 软件测试工具（黑/白）
9.1 测试工具
9.2 黑盒测试工具
9.3 白盒测试工具
10. 测试管理
11. 面试小题
11.1 如何看待自动化测试
11.2 登录功能的测试与设计？
11.3 注册功能的测试与设计？
11.4 黑、白盒测试的方法？
11.5 术语
11.6 CMM能力成熟模型
11.7 TDD测试驱动开发
测试人员应该具备的技能
https://www.cnblogs.com/fnng/p/3830555.html（这个链接点击学习）
1. 基本知识
1.1 软件
软件：计算机中与硬件相结合的一部分，包括程序和文档。
1.2 什么是软件测试
在规定条件下对程序进行操作，从而发现问题，对软件质量进行评估的过程。
测试的方法：个人复查、抽查和会审、黑盒测试、白盒测试。
软件测试用例包括：输入数据和预期输出结果。
1.3 软件测试的目的
以最少的人力、物力、时间找到软件中的缺陷并修改，从而回避商业风险。软件测试的目的是为了发现错误而执行程序的过程，并不涉及改正错误。软件测试的目的是尽可能多的找出软件的错误。
1.4 软件测试的定义
使用人工和自动手段来运行程序，目的在于检验是否满足需求。
1.5 软件测试的原则
- 所有测试追溯到用户需求；
- 把尽早和不断的测试，作为座右铭；
- 测试工作要有专业的人员来执行；
- 80%的错误出现在20%的模块中；
- 设计测试用例时，要考虑各种情况；
- 一定要写缺陷报告；
- 制定严格的测试计划；
- 完全测试不可能，测试需要终止；
- 注意回归测试（修改了旧代码后，要确认没有引入新的问题）；
- 妥善保存一切测试文档；
1.6 软件质量模型（iso9126）
- 功能性；
- 可靠性（1、尽量不出问题；2、出了问题不能影响主体功能；3、如果影响了主体功能，要尽快回复；）
- 易用性（用户体验好）；
- 效率；
- 可维持性（更新）；
- 可移植性（跨越不同系统平台）；
1.7 软件质量模型保证（SQA）
目的：使软件制作过程对于领导是可见的。
定义：它是一套计划和方法来向领导层保证。
5个基本标准：
- 保证有计划地进行；
- 保证遵循了步骤和需求；
- 及时通知给对应人员；
- 高管可以接触到项目内部；
- 软件质量需要测试工作来保证；
1.8 QC和QA
QC：检验产品质量；
QA：审计过程的质量；
工作关系：QC进行质量控制，QA是确保QC按步骤执行；
1.9 软件测试的流程
- 需求分析；
- 编写测试用例（测什么，怎么测）；
- 评审测试用例；
- 搭建测试环境；
- 等待程序的开发包；
- 部署测试包；
- 冒烟测试（测试主体功能是否有问题）；
- 执行测试用例；
- Bug跟踪处理（回归测试）；
- N轮之后符合要求；
- 测试结束；
编写测试文档（登录模块的测试用例），根据需求文档进行测试用例的编写：
1.10 软件测试报告包括什么？
- 对整个软件系统有个完整的质量评价和总结；
- 对自己本身的测试工作给予评价和总结：测试结论（测试是否通过）、罗列主要问题、严重缺陷、测试用例执行的情况（数量）
- 要给下一阶段的测试给予建议和意见；
- 首页
- 引言（目的、背景、缩略语、参考文献）
- 测试概要(测试方法、范围、测试环境、工具)
- 测试结果与缺陷分析（功能、性能）
- 测试结论与建议（项目概况、测试时间 测试情况、结论性能汇总）
- 附录（缺陷统计）
2. 软件的bug（缺陷）
2.1 软件的Bug
2.2 Bug的分类
2.3 软件各个阶段的
2.4 常用缺陷管理工具
2.5 提交缺陷注意事项
3. 测试环境
测试环境=硬件+软件+网络。必须考虑，缺一不可。
搭建测试环境的要点：真实、干净、无毒、独立
4. 测试人员
4.1 测试人员
评价测试人员的标准：发现的有效Bug数、编写的有效测试用例数
测试设计人员的职责：设计测试用例，设计测试过程、脚本；
测试经理：指定测试计划；
评估测试活动：测试经理组织召集开发和测试的相关人员来做。
测试人员日常工作5件事：
QA：分担测试人员压力的角色
SQA:Software Quality Assurance 软件质量保障。独立于项目之外的第三方监督机构。权利与项目经理平行，监督整个项目的管理、需求分析、维护、设计、编码、测试、维护等，但是国内这个职位不理想。
4.2 软件测试工程师
如何成为一名优秀的测试工程师：
名师指点——基础知识——测试技术——醒目经验
理论+实践+理论+实践
-
- 不断学习充电；
- 阅读原版书籍；
- 阅读缺陷中管理系统中的缺陷报告；
- 阅读高手写的测试用例；
- 学习产品相关的业务知识；
5. 测试用例
测试用例（TC）：Test Case。在测试执行之前设计的一套详细的测试方案（环境测试、测试步骤、测试数据、预期结果）。测试用例=输入+输出+测试环境。
6. 开发和测试的生命周期
6.1 软件生命周期模型
7. 举例设计模式
设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。
单例模式：
保证一个类仅有一个实例，并提供一个访问它的全局访问点。
适用于：当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时；当这个唯一实例应该是通过子类化可扩展的，并且客户应该无需更改代码就能使用一个扩展的实例时。
工厂模式：
定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method 使一个类的实例化延迟到其子类。
适用于：当一个类不知道它所必须创建的对象的类的时候；当一个类希望由它的子类来指定它所创建的对象的时候；当类将创建对象的职责委托给多个帮助子类中的某一个，并且你希望将哪一个帮助子类是代理者这一信息局部化的时候。
8. 软件测试、分类、基本原则
8.1 软件测试基本概念
软件测试：程序测试+文档测试。
目的是：检验实际的软件系统是否符合用户的需求。
图：测试的基本概要
8.2 软件测试的基本原则
图：软件测试的基本原则
8.3 *软件测试分类
图：测试的详细攻略
- 白盒测试的6种覆盖准则由弱到强依次是：
语句覆盖、判定覆盖（分支覆盖）、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖。
- 静态测试：不实际运行被测软件，而只是静态的检查程序代码、界面或文档中可能存在的错误的过程。
如：在测试代码的过程中，程序=代码+注释
程序适当加一些空行，空行是不占内存的，反而使得程序结构看起来更加的清晰。
注：一个Tab键是4个空格。
- 动态测试：实际运行被测试程序。
- 单元测试：对软件中最小可测单元进行检查和验证。（也称模块测试），针对软件设计的基本单元——程序模块，进行正确性检验的测试工作。目的在于发现各个模块内部可能存在的各种差错。单元测试需要从程序内部结构出发设计测试用例，多个模块可以平行、独立地进行测试，单元测试的测试用例主要根据详细设计的结果来设计。JUnit主要用来完成：单元测试。
单元测试能够发现约80%的软件缺陷。
如：C中的单元一般是指1个函数。单元就是人为规定的最小的被测功能模块。
单元测试的一般步骤：编译运行程序——静态测试——动态测试
桩模块、驱动模块：
如：假设主函数main() 调用函数fun() 是由2个人研发的。但是不是同时研发完成，则
1.没有主函数，怎么测试fun函数？
模拟写出main函数，模拟的函数就是驱动模块。
2.没有fun函数，怎么测试main函数？
模拟写出fun函数，没必要有fun函数的内容和细节，但是能被main调用，这个模拟的fun函数就是桩模块。
桩函数：
- 在单元测试中被其它模块调用；
- 在自顶向下的集成过程中尤为有效；
- 集成测试：用来检查各个单元模块结合到一起能否协同配合，正常运行。（也称组装测试，联合测试）：在单元测试的基础上，将所有模块按设计要求集成在一起进行测试，以检验总体设计中各模块间的接口设计问题、模块之间的相互影响、上层模块存在的各种差错及全局数据结构对系统的影响等方面。 集成测试分为渐增组装测试和非渐增组装测试。
集成测试包括：接口测试。
- 系统测试：集成测试后，将软件系统作为一个元素，放入整个实际的计算机系统中，与计算机硬件、其他软件、使用人员等系统元素结合在一起，在实际使用环境下进行综合全面的测试。
设计系统测试需要参考的文档：软件测试计划、软件需求规范、迭代计划。
系统测试包括：安全测试、性能测试、压力测试、功能测试、回归测试。
- 确认测试：（也称为验收测试）系统测试后，以用户测试为主。主要检验软件的功能和性能是否与需求说明书中的规定一致。
验收测试包括：正式验收测试、非正式验收测试（alpha测试、beta测试）；
软件测试一般分α、β、λ三个阶段：α是第一阶段，一般只供内部测试使用；β是第二个阶段，已经消除了软件中大部分的不完善之处，但仍有可能还存在缺陷和漏洞，一般只提供给特定的用户群来测试使用；λ是第三个阶段，此时产品已经相当成熟，只需在个别地方再做进一步的优化处理即可上市发行。
- 回归测试：对软件新的版本进行测试时，重复执行上一个版本测试的用例。，可以在任何阶段进行回归测试。
- 冒烟测试：对一个新版本进行系统大规模的测试之前，先验证下软件的基本功能是否实现，是否具有可测性。
- 随机测试：在测试中，所有的数据都是随机的，其目的是模拟用户的真是操作，并发现一些边缘性错误。
- UAT测试：（user Acceptance Test） 用户验收测试，用户可接受测试。通常是由最终软件的用户（通常这些用户不了解软件的具体逻辑，而对业务逻辑却相当熟悉）进行的测试，因此是面向最终用户的测试，结束之后通常就可以发布生产环境了。
8.4*黑盒测试中的性能测试
负载测试：（系统在最大能力下是否能正常工作）
模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载（如逐渐增加模拟用户的数量）或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源（如CPU、内存）等，以检验系统的行为和特性，以发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题。所以可以检验系统的最高能力。
压力测试：（系统最高能力的测试）
在强负载（大数据量、大量并发用户等）下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。所以是检测超出负荷下的行为。
Web性能测试指标：
- 响应时间
用户感受软件系统为其服务所耗费的时间，对于网站系统来说，响应时间就是从点击一个页面计时开始，到这个页面完全在浏览器里展现计时结束，的这一段时间间隔。
响应时间：2-5-8原则
- 当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以。
- 当用户在5-8秒以内得到响应，会感觉系统的响应速度很慢，但是还可以接受。
- 当用户在超过8秒后仍然无法得到响应时，就感觉很慢。
- 吞吐量
单位时间内客户端和服务器成功传送数据的数量。
- 资源使用率
常见的资源有：CPU占用率、内存使用率、磁盘I/O、网络I/O。
- 每秒点击数
指客户端每秒钟向服务器端提交的请求数量，如果客户端发出的请求数量越多，与之相对的平均吞吐量也就越大。
- 并发用户数
指在客户端的一批用户同时执行一个操作的数量。并发数反映了软件系统的并发处理能力。
9. 软件测试工具（黑/白）
9.1 测试工具
LoadRunner：负载压力测试（预测系统性能）；
JMeter+Badboy：基于JAVA的压力测试工具，Badboy用来进行脚本的录制；
Junit：白盒测试工具：针对代码测试；
TestLink：用户管理工具；
测试管理工具：对测试需求、计划、用例、实施进行管理
测试辅助工具：本身不执行，可以生成测试数据，为测试提供数据准备
负载压力测试：LoadRunner:预测系统行为和性能的工业标准级负载测试工具。模拟上千万用户同时实施并发操作，来实时监控可能发生的问题。
功能测试： QTP(quicktest professional):自动测试工具
白盒测试：C++ TEST（做C和C++的白盒测试）、JUnit（Java白盒测试）
缺陷管理工具：Mantis、BugFree、QC、TD
用例管理工具：TestLink、QC
测试辅助工具：SVN
9.2 黑盒测试工具
9.3 白盒测试工具
10. 测试管理
11. 面试小题
11.1 如何看待自动化测试
让QA从枯燥无味的手工重复性测试中解放出来，并且提高工作效率，通过自动化测试结果分析功能和性能上的缺陷。
11.2 登录功能的测试与设计？
| If else条件 |
|
用户名 |
密码 |
备注1 |
备注2 |
| 输入： 输入未输入 |
用例1 |
空 |
空 |
请输入用户名 |
光标回到用户名 |
| 用例2 |
空 |
非空 |
请输入密码 |
光标回到密码 |
|
| 用例3 |
非空 |
空 |
请输入用户名 |
光标回到用户名 |
|
| 验证： 全部输入 |
用例4 |
输入错误 |
输入正确 |
用户名输入错误 |
光标回到用户名，清空密码 |
| 用例5 |
输入正确 |
输入错误 |
密码错误 |
光标回到密码 |
|
| 用例6 |
输入正确 |
输入正确 |
验证正确 |
NULL |
11.3 注册功能的测试与设计？
11.4 黑、白盒测试的方法？
- 黑盒：
正交实验设计法、等价类（有效、无效），因果图、流程图、错误推测法、等值分析方法（使用最广）、
- 白盒：
基本路径法、逻辑覆盖法、
6种测试的覆盖：覆盖准则由弱到强依次是语句覆盖、判定覆盖（分支覆盖）、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖；
- 既可以黑盒，又可以白盒：
边界值法、
11.5 术语
PV：page view 页面浏览量；
QPS： Query Per Second每秒查询率（每秒请求数）；
TDD：Test-Driven Development 测试驱动开发；
11.6 CMM能力成熟模型
CMM ：Capability Maturity Model能力成熟模型 是SQA用来监督项目的一个标准质量模型。测试是发现Bug，但是SQA是预防问题。它是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。CMMI（Capability Maturity Model Integration，能力成熟度模型集成）将各种能力成熟度模型（即：Software CMM、Systems Eng-CMM、People CMM和Acquisition CMM）整合到同一架构中去，由此建立起包括软件工程、系统工程和软件采购等在内的诸模型的集成，以解决除软件开发以外的软件系统工程和软件采购工作中的迫切需求。这两种方法属于测试驱动开发的方式。
11.7 TDD测试驱动开发
测试驱动开发，英文全称Test-Driven Development，简称 TDD ，是一种不同于传统 软件开发流程 的新型的开发方法。它要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码，并加速开发过程。
- TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。
- TDD的基本思路就是通过测试来推动整个开发得进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程。
- TDD的重要目的不仅仅是测试软件，测试工作保证代码质量仅仅是其中一部分，而且是在开发过程中帮助客户和程序员去除模棱两可的需求。
- TDD首先考虑使用需求（对象、功能、过程、接口等），主要是编写测试用例框架对功能的过程和接口进行设计，而测试框架可以持续进行验证。