软件测试理论(2)

软件测试的分类
1、按测试策略分类
黑盒/白盒测试、动态/静态测试、手工/自动测试
2、按测试阶段分类
单元测试、集成测试、（确认测试）、系统测试、验收测试
3、按测试方法分类
功能测试、性能测试、压力测试、负载测试、易用性测试、安装测试、界面测试、配置测试、文档测试、兼容性测试、安全性测试、恢复测试

单元测试：又称模块测试，是最小单位的测试，单元测试是在系统开发过程中进行的测试活动。目的是确保每个模块能正常工作。
集成测试：又称综合测试，是在单元测试的基础上将通过测试的单元模块按照设计要求组装成系统或子系统，再进行测试。目的在于检验与软件设计相关的程序结构问题。
确认测试：软件在由集成测试进入系统测试之前，需要对软件是否可以进入系统测试进行评估过程的测试。
系统测试：是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机的硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际的运行环境下，对计算机系统进行全面的功能覆盖。
验收测试：是软件产品交付用户正式使用前的最后一头工序，是以用户为主的测试。目的是向客户和承包人证明产品是可靠的。

黑盒测试：又称功能测试、数据驱动测试或基于规格说明书的测试。
白盒测试：又称结构测试、逻辑驱动测试或基于程序本身的测试。
冒烟测试：对应用程序关键的功能进行的测试。
回归测试：对某些已经进行过的测试的某些子集再重新进行一遍，已保证上述改变不会传播无法预料的副作用或引发的问题。

Alpha 测试：由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。
Beta 测试：由软件的最终用户们在一个或多个客房场所进行。

关于单元测试

1. 单元测试多采用白盒测试技术

    静态审查代码
    动态单元测试
   

2. 单元测试的意义

   一个好的单元测试将会在产品开发的阶段发现大部分的缺陷，并且修改它们的成本也很低。
   在软件开发的后期阶段，缺陷的发现并修改将会变得更加困难，并要消耗大量的时间和开发费用
   无论什么时候做出修改都要进行回归测试
   经过单元测试的系统，系统集成过程将会大大地简化

3. 桩模块（Stub）和驱动模块（Driver）

   桩模块：集成测试前要为被测模块编制一些模拟其下级模块功能的“替身”模块，以代替被测模块的接口，接受或传递被测模块的数据，这些专供测试用的“假”模块称为被测模块的桩模块。
   驱动模块在大多数场合称为“主程序”，它接收测试数据并将这些数据传递到被测试模块。

关于集成测试

1. 非增式集成方法
2. 增式集成方法：
   自顶向下测试
   自底向上测试

软件测试的原则

1. 尽早地进行软件测试，并把软件测试贯穿于整个软件生命周期。
2. 软件测试应追溯需求。
3. 测试应由第三方来构造。
4. 穷举测试是不可能的，要遵循 Good-enough 原则。
5. 必须确定预期输出结果。
6. 必须彻底检查每个测试结果。
7. 充分注意测试中的群集现象。80/20原则
8. 其他值得注意的规律和经验。比如订单，要关注数量的锁定，缺货等情况，app要涉及到中断，兼容，扣费，网络

什么是评审

• 在正式的会议上将软件项目的成果（包括各阶段的文档、产生的代码等）提交给用户、客户或有关部门人员对软件产品进行评审和批准。其目的是找出可能影响软件产品质量、开发过程、维护工作的适用性和环境方面的设计缺陷，并采取补救措施，以及找出在性能、安全性和经济方面的可能的改进。

过程改进的策略
1. 重诊断，轻评估。 要以诊断和解决测试过程中的实际问题作为测试过程改进的目的，而不能盲目追求商业评估，例如实施ISO9000的认证等。
2. 实施制度化的同时，建设企业文化。 实施全面制度化的管理是过程改进的有效保障，制度和组织文化是互相依存的。
3. 引入软件工具。 推行配置、自动化测试和缺陷跟踪等工具，将有效地分解事务性工作，可以缓解人力资源不足的困难。
4. 建设管理和工程基础。 要在测试过程改进前期为相关部门和员工进行基础管理和基本软件工程的课程培训。
5. 发动全员参与。 优化过程改进，需要做到：第一，站在高于项目管理的层面；第二，站在项目管理的层面；第三，站在开发人员和测试人员层面。

软件测试的六个要点
- 测试过程的质量决定测试工作的成败
- 使用早期软件生存周期测试技术可避免缺陷转移到后续阶段
- 测试工具应用（捕获/回放工具、结构覆盖工具）
- 改进测试过程必须有专人负责
- 测试是一个专业技术学科，要求富有经验的专门技术人员
- 培养创新的、积极的合作精神

测试工作流程

测试流程：

1. 产品人员设计完原型和文档后，召开需求评审会，参会人员有开发，测试，产品。需求评审后之后，会产生一个完善之后的原型和需求文档。
2. 测试组负责人需要依据需求文档，项目周期、项目特点、工具、人员安排制定测试计划。
3. 测试人员就开始写测试用例（需要有冒烟测试用例和普通的测试用例），在写用例过程中会产生一些疑问，要及时和产品人员确认清楚，并要求他们回归需求文档。（开发就开始概要设计和编码）。
4. 测试人员完成用例后，组织测试用例评审。参与人员有开发，测试，产品。
5. 等待开发提交测试版本，提交后优先执行冒烟测试。冒烟测试的结果，需要邮件周知相关人，开发，测试，产品，其中重要的是开发领导，测试领导和产品。冒烟不通过等待开发重新提交版本，冒烟通过了进入执行用例进行测试阶段。
6. 测试阶段会发现一些问题，比如需求定义不明确，业务逻辑有冲突，要和相关人员沟通并定义清晰，得到结论后必须要求产品人员更新文档。
7. 每个人负责的模块测试结束后，小组内部要进行交叉测试（此时会进行一些性能测试）。
8. 测试通过后提交产品验收。产品验收期间协助产品验收。
9. 产品验收完毕后，项目部署仿真环境。此时需要线上的账号，所以一般也是产品和业务人员验收为主，各个公司情况不同，有些会给测试人员分配账号，进行基本流程的测试（细节视公司情况而定）。
10. 仿真环境ok了，部署线上。
11. 有些公司从测试环境提交验收的时间点开始，会要求写一些操作手册之类的文档，一些测试的报告，比如bug统计，bug的覆盖。