软件测试
概念：验证软件功能是否满足用户的需求。
软件测试就是证明软件不存在错误的过程（最基本的活动就是找bug）；
软件测试就是为了证明程序能够正确运行。
对一个功能进行一系列的操作，看它最后呈现给我的界面是否与我想要的一致。
测试与调试的区别：
目的不同：
测试的任务是发现程序中的缺陷；
调试的任务是定位并且解决程序中的问题。
参与角色不同：
测试主要是由测试人员和开发人员来执行，黑盒测试主要由测试人员完成、单元/集成测试主要是由开发人员执行；
调试由开发人员完成。
执行的阶段不同：
测试贯穿整个软件开发生命周期；
调试一般在开发阶段。
软件测试的目的和原则
目的：验证软件有或没有问题。
原则：以客户为中心，遵循软件测试的规范、流程、标准和要求。
1. 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。
2. 成功的测试是发现了至今为止尚未发现的错误的测试。
3. 测试并不仅仅是为了找出错误。通过分析错误产生的原因、阶段及错误发生的趋势。
一、帮助项目管理者了 解当前软件开发过程中的缺陷，以便及时纠错、改进。
二、帮助测试人员设计出有针对性的测试方法，改善 测试的效率和有效性。
三、让开发人员知道错误产生的重灾区，加强自测试，
四、让客户清楚我们专业的质 量保证团队，可以向他们提交一份满意的答卷。
4. 没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法。
5. 根据测试目的的不同，还有回归测试、压力测试、性能测试、安全测试等，
分别为了检验修改或优化过程是否引发新的问题、软件所能达到处理能力和是否达到预期的处理能力等。
6. 软件测试为了建立软件的信心。
7. 从测试的目的出发，大概可以分为两类：
为了验证程序能正常工作的测试；
为了验证程序不能正常运行的测试。
什么是需求：
IEEE定义：
软件需求是
(1)用户解决问题或达到目标所需条件或权能(Capability)。
(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
(3)一种反映上面(1)或(2)所述条件或权能的文档说明。
它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，
比如性能要求，质量标准，或者设计限制。
（满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，
包含用户需求和软件需求————满足用户的合理期望）
用户需求：可以简单理解为甲方提出的需求，
如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。
该需求一般比较简略。
软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。
软件需求是测试人员进行测试工作的基本依据。
（把用户需求转化为可以指导开发人员写代码，指导测试人员写测试用例的文档）
什么是测试用例(Test Case)：
测试用例：
为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
把你进行测试的一系列过程记录下来。
好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试。
评价测试用例的标准：对比好坏代码的评价标准
用例表达清楚，无二义性。
用例可操作性强。
用例的输入与输出明确。一条用例只有一个预期结果。
用例的可维护性好。
用例对需求的覆盖率高，
暴露程序Bug的能力强力。
用例的基本要素可以参见如下例子：
| 测试用例escp-439：单位用户注册成功 | |
|---|---|
| 步骤动作： | 期望的结果： |
| 进入注册页面，选择注册 | 系统展现注册页面 |
| 输入符合要求的单位名称、单位邮箱、密码、确认密码、 组织机构代码、验证码，并确认同意《用户注册协议》， 提交注册信息 | 系统进行注册操作，发送激活邮件。注册成 功后，跳转到注册成功页面，并提示用户进 行激活操作。 |
| 进入注册用的邮箱，进行激活操作 | 激活成功 |
| 用注册的邮箱和密码，进行登录操作 | 登录成功，系统展示欢迎页面 |
| 测试方式 | 手工 |
| 重要性 | 重要 |
| 测试环境 | CHROME,IE10+ |
| 测试前提 | 系统运行正常，邮件服务器已开启 |
| 功能模块 | 注册登录 |
测试用例带来的好处：
测试执行者的依据
使得工作可重复，自动化测试的基础
评估需求覆盖率
用例的复用
积累测试的方法思路以供后续借鉴
- 使用中带来困扰
测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还多 - 解决如下问题：
不知道是否较全面的测试了所有功能 测试的覆盖率无法衡量 对新版本的重复测试很难实施 存在大量冗余测试影响
测试效率
测试过程中可能会遇到以下问题：
不知道是否较全面的测试了所有功能
测试的覆盖率无法衡量
对新版本的重复测试很难实施
存在大量冗余测试影响测试效率
测试用例的产生就是为了解决上述的问题。
