一、为什么要进行软件测试
- 软件的非正常运行或其自身的缺陷(BUG)会引发很多问题；
- 软件是由代码和文档组成的，而这些都是由人来设计和编写的，只要是人都可能会犯错；
- 环境也会影响软件，以致出现软件"失效"现象；
- 软件测试活动贯穿整个软件开发生命周期，是关键的质量保证活动之一；
只要是软件，就会有BUG，而我们就需要找BUG；
实例一: ATM取款机(功能性错误)
例如账户余额10000元，在ATOM机上取出2000元，查询账户余额7900元，这明显是银行的软件系统出现故障，将你的账户的多扣了100元，这就是一个严重的BUG。
实例二: 证券公司的系统瘫痪(性能错误)
2007年1月，招商证券的客户发现，在公司网站竟然无法登陆，一部分客户转向电话服务寻求帮组，却发现电话线路出现同样的阻塞。与此同时发现网络拥堵的不只是招商证券。1月15日至16日，申银万国的网络客户也发现，自己根本无法进行交易。当天申银万国解释称，网上交易系统拥堵是由于交易量激增，原系统容量不足引起的。
二、软件测试的发展史
- 70年代以前，主要以调试为主，也不完全叫测试；
- 70年代~80年代中期，测试基础理论以及技术的形成，测试作为软件质量保证(QA)的主要职能；
- 80年代后期~90年代中期，随着测试的发展，慢慢的与QA分离(注重于过程和质量的监督)，开始关注工具对测试的影响；
- 90年代以后~至今，随着质量体系的完善，测试开始关注过程管理对软件测试的重要性，慢慢形成各种测试模型、测试能力成熟度模型；
三、软件测试的定义
使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。
软件测试的目的: 尽可能早的发现并改正被测软件中的缺陷(BUG)，提高软件质量。
四、什么是测试
- 制造业的定义: 以质检产品是否满足需求为目标；
- 软件行业的定义:
验证软件的正确性(证实)；
发现软件中的缺陷(证伪)；
证实: 自研公司、小公司、互联网行业；[证明软件是可用的即可]
证伪: 银行，电信，移动；[证明软件是存在错误，找出来解决]
QC: 质量检测
QA: 质量保证
五、软件的生命周期
软件生命周期: 计划阶段、需求分析、设计阶段、编码、测试、运行与维护；
- 计划阶段
a、确定软件开发总目标；
b、给出软件的功能、性能、可靠性以及接口等方面的设想；
c、研究完成该项目的可行性，探讨问题解决方案；
d、对可供开发使用的资源、成本、可取得的效益和开发进度做出估计；
e、制定完成开发任务的实施计划；
例如(计算器之计划阶段):
a、研发一个计算器；
b、支持加减乘除，所有运算都需要在一定时间之内完成；
c、该项目目前不存在任何技术障碍；
d、需要3个月之内完成所有开发和测试工作，并推向市场；
e、具体计划参见一级计划；
- 需求分析
a、功能需求；
b、性能需求；
c、软件需求分析说明书SRS；
例如(计算器之需求分析):
a、功能需求
十进制加减乘除；
八进制加减乘除；
二进制加减乘除；
十六进制加减乘除；
b、性能需求
32位十进制加法需在2秒内完成；
16位十六进制乘法需在10秒内完成；
- 设计阶段(核心)
a、概要设计(HLD):在设计阶段把各项需求转换成相应的体系结构，每一部分是功能明确的模块；
b、详细设计(LLD):对每个模块要完成的工作进行具体的描述；
例如(计算器之设计阶段):
a、概要设计
整个软件分为六个模块:界面模块、主控模块、加法模块、减法模块、乘法模块、除法模块。主控模块调用后面的四个模块；
加法模块包含: 加法主函数、十进制加法函数、二进制加法函数、八进制加法函数以及十六进制加法函数；
b、详细设计
加法主函数的流程图；
- 编码阶段
a、开发进行编码
例如(计算器之编码阶段):
a、用开发语言实现详细设计中的所有函数；
- 测试阶段
a、对软件功能需求进行测试；
b、对软件性能需求进行测试；
例如(计算器之测试阶段):
a、对计算机的功能进行测试；
b、对计算器的性能进行测试；
- 运行与维护
a、软件交付完成进入正式使用以及后期的维护工作；
例如(计算器之运行与维护):
a、计算机提供用户使用，使用中如发现问题反馈给客户或技术支持人员，问题解决后为用户进行软件升级；
外包公司、自研公司、项目外包、人力外包....
六、软件中的研发模型
- 典型的软件开发模型有哪些？
- 瀑布模型
- V模型(比较重要)
- W模型
- H模型(比较重要)
- 敏捷开发模型(比较重要)
- 迭代开发模型(比较重要)
- 增量开发模型
软件开发模型对指导测试工作的进行具有重要的意义，但任何模型都不是完美的；
事实上，随着软件质量要求越来越为大家重视，软件测试也逐步发展成为一个独立于软件开发的一系列；
在实际工作中，要灵活运用各种模型的优点。例如在W模型的框架下，运用H模型的思想进行独立的测试，并同时将测试与开发紧密结合，寻找恰当的就绪点开始测试并反复迭代测试，最终保证按期完成预定目标；
-
瀑布模型: 应用最广泛的一种模型，最容易理解和掌握
1.1 瀑布模型
优点: 流程简单、文档驱动；
缺点: 测试活动置后；
-
V模型: 基于瀑布模型的演变，认为测试是开发后的串行活动
1.2 V模型
优点: 开发测试相对应、文档驱动；
缺点: 忽略了测试对象；
-
W模型: 基于V模型的演变
1.3 W模型
优点: 将测试贯穿到整个软件的生命周期中，且除了代码要测试，需求、设计等文档都要测试；更早的介入到软件开发中，能尽早的发现缺陷，并进行修复；测试与开发独立起来，并与开发并行；
缺点: 对有些项目，开发过程中根本没有文档产生，故W模型无法使用;于需求和设计的测试技术要求很高，实践起来很困难;
-
H模型: 这个是当前实际项目中使用最多的，例如"华为"的项目
1.4 H模型
1.4 H模型
在H模型中，软件测试过程活动完全独立，贯穿于整个产品的周期，与其他流程并发地进行，某个测试点准备就绪时，就可以从测试准备阶段进行到测试执行阶段；软件测试可以尽早的进行；软件测试可以根据被测物的不同而分层次进行；
敏捷开发模型
这是一种新的模型，前面的几种都是属于传统型。它能适应快速需求变化，交付周期短，轻量级的开发模型。-
增量开发模型
项目被划分为一些列的增量，每一个增量都交付整个项目需求中的一部分功能。需求按优先级进行划分增量的交付。
1.6 增量开发模型
一般都是大型项目，例如功能需求多，开发周期长的。
- 迭代开发模型
项目被分为大量的迭代过程，一次迭代就是一次完整的开发循环，是一个可以发布的可执行产品，属于软件开发周期中最终产品的一个子集。
七、为什么会引入缺陷
软件缺陷
通常被叫做BUG，是指计算机软件或程序中存在的某种破坏正常运行能力的问题、错误或者隐藏的功能缺陷。缺陷标准定义
a、从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等问题；
b、从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背；问题所在
缺乏有效的沟通，或没有进行沟通；
软件本身的复杂度；
发开人员自身的编程错误；
需求的不断变更；
测试的时间问题；
...
八、缺陷的类型
缺陷的表现形式不仅仅体现在功能的失效方面，还体现其他方面，主要类型有:
- 软件没有实现产品规格说明所要求的功能模块；
- 软件中出现了产品规格说明指明不应该出现的错误；
- 软件实现了产品规格说明没有提到的功能模块；
- 软件没有实现了虽然产品规格说明没有明确提及，但应该实现的目标；
- 软件难以理解，不容易使用，运行缓慢，或从测试员的角度看，最终用户会认为不好；
九、测试用例
测试用例(Test Case简称TC)又称之为测试案例，是为了某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
a、测试点、测试什么，可以从标题中体现；
b、构造测试场景；
c、预期的结果；
十、测试执行
测试执行就是根据测试用例运行被测软件。
十一、软件测试的主要工作
- 掌握软件测试理论，熟悉测试流程，能熟练使用合适的测试方法设计测试用例；
- 能够独立编写测试计划，搭建测试环境，执行项目测试并输出相应的测试报告；
- 对数据库和Linux技术，使用熟练；
- 沟通能力强，问题定位于分析能力强；
- 有自动化测试经验或性能测试经验优先；
- 至少熟悉一种对自动化工具或脚本(Java或Python)；
- 有测试创新思想(质量度量新标准)；
十二、软件测试的原则
1. 测试的标准是用户需求；
2. 测试贯穿整个生命周期；
3. 测试不仅仅是单纯的软件本身的测试；
4. 软件外在没有失效不代表软件系统是可用的；
5. 软件的完美度没有完全正确的，测试只能帮助软件更加完美，更加正确；
6. 穷尽测试时不可能的(有些条件组合非常多，穷尽测试时不可能的)；
7. 测试应该尽早介入(早起引入的问题站到整个问题数目的50%以上)；
8. 二八原则(80%的缺陷或错误会集中出现在20%区域中);
9. 杀虫剂效应(就是要不断更新用例，因为反复的执行相同的测试用例将会发现新缺陷的能力几乎为零)；
10. 测试活动依赖测试对象(测试的关注点不一样，有的更多关注安全和性能的测试)；
11. 选择第三方测试(避免自己测试自己开发的程序)；
十三、SVN工具的使用
版本控制
版本控制，通过文档控制记录各个模块的改动，并给每次改动添加序号，用于存储、追踪目录和文件的修改历史。
作用：企业中用来实现文件共享，上传，下载，版本控制，测试人员主要用来上传，下载文件，从服务器上面下载，或者上传文件到服务器版本控制软件
1、GIT 分布式版本控制系统
2、SVN 集中式版本控制系统
- SVN服务端
SubVersion: 实现服务系统的软件，即是SVN服务端程序;
SubVersion还需要配合Apache服务器使用，为了简单操作直接使用VisualSVN(集成了SubVersion和Apache)；
使用：
Repositories： 仓库
1、 建仓库 Create New Repository
仓库名字：
2、建立项目组
3、创建人员
在Users上面点击右键 Create User
用户：zhangsan
密码：123456
4、将对应人员添加到项目组
5、设置代码仓库的访问权限
在仓库上点击右键 Properties属性
6、 每个仓库都会有一个"连接地址"
在仓库上点击右键 Copy URL to Clipboard(剪切板)
URL：https://event/svn/test1701/
注意: SVN服务端在公司一般都是不用我们设置操作的，都会项目经理创建好并设置好对应的权限！
- TortoiseSVN: 是SVN客户端程序，为windows外壳程序集成到windows资源管理器和文件管理系统的Subversion客户端;
与代码仓库建立链接:
- 链接地址: https://event/svn/test1701/
- 用户名: zhangsan
- 密码: 123456
具体操作:
- checkout 检出，将服务器上最新的代码仓库下载本地"只需要做一次"
- update 更新，从服务器上将其他人所做的修改下载到本地"每天上班必须要做的事情"
- commit 提交，将工作提交到服务器(提交之前最好是先操作update)"每天下班之前至少做一次"
图标含义:
右键TortoiseSVN -> 设置settings -> 图标集Icon Set
绿色的钩子: 常规
红色的感叹号: 修改
黄色的感叹号: 冲突
灰色的钩子: 只读
红色的XX: 已经删除
锁标志: 锁定
蓝色的加号: 增加
灰色的减号: 忽略
蓝色的问号: 无版本控制
SVN操作:
- 添加文件
- 查看版本
- 修改文件
- 删除文件
- 更新
- 指定版本更新
- 解决冲突
- 版本库浏览器
- 提交失败原因
- 版本控制器最常见的两个错误:
- 超时
SVN原则: 先更新再提交;只有本地版本号大于等于服务器版本号时，才能提交，否则会报错out data; - 冲突
仅仅在两个人同时修改同一行代码时，才会出现冲突，但更多最好不要多人同时修改同一个文件;
(双击错误信息，版本对比)
main.txt.mine(冲突版本:自己的)
main.txt.r9(数字小的，是未冲突版本)
main.txt.r10(数字大的，是冲突版本:对方的,即服务器的)
而在main.txt中也会出现自己代码以及对方代码，即标识出哪现冲突【 <<< 存放的是自己修改的代码 ==== 存放的是服务器最新的代码 >>>> 】
- 超时
diff一个工具程序，它可以比较两个文件之间的不同。通常它被用来比较同一个文件，在不同版本间的差异。
如何比对文件，并解决冲突？
例如文件名为`test.txt`，当前版本20:
- 黄色感叹号，表示冲突文件，即`test.txt`；
- `test.txt.mine`自己版本文件；
- `test.txt.r20`当前服务器最新版本文件；
- `test.txt.r19`当前服务器最新版本的上一个版本文件；
解决:
选择冲突文件，右键TortoiseSVN -> diff with"xxx.xxx.xxx" (选择需要对比的文件) -> 找到冲突点并解决
删除多余文件，只留下一个`test.txt`文件即可;
再次`commit`上传到服务器；
(右键菜单没有显示SVN相关内容: 开始菜单中的搜索 —> regedit —> HKEY_CLASSES_ROOT/*…/TortoiseSVN —> 右键TortoiseSVN —> 权限 —> 高级 —> 所有者 —> 将所有者改为administrator —> 应用 —> 确定 —> 确定 —> 重启电脑)
搜索regeditTortoiseSVN选项
