2.1 软件测试的阶段
1.1单元测试
1.1.1概念
对软件中最小的可测试单元进行验证，侧重于单个模块；例如：c语言中，单元可看做是一个函数，而在java语言中单元则可以是一个类，应根据实际情况进行区分；
1.1.2单元测试原则
1.尽可能保证各个用例相互独立；
2.确保程序中的每一个独立路径都可以执行到；在上下边界及可操作范围内运行所有循环；检查内部数据结构以确保其有效性；应尽可能使用少的数据来覆盖更多的数据；
3.一般由开发人员来实施，用以检验所开发的代码是否符合设计要求；
1.1.3单元测试优点
1. 能尽早发现缺陷，且收益最好；
新型的敏捷研发，先编写单元测试用例，再进行代码开发，以保证代码可以通过单元测试的要求；编写用例时可确保对需求的二次理解。
2. 有利于重构；
3. 简化集成测试的过程；
4. 简化文档；
5. 提高程序猿的意识；
1.1.4单元测试的限制
1. 不可能覆盖所有路径；
2. 每行代码需要3~5行测试代码来验证，投入精力大；需要在投入和产出间平衡；
1.1.5单元测试框架
1. 针对java： J-Unit ；
2. 针对PHP语言：PHP-Unit ； etc.
1.2集成测试
1.2.1概念
在单元测试的基础上，测试在将几个软件单元按照设计规格书组装成组件、模块、子系统或系统的过程中，各部分工作是否达到或实现相应技术指标及要求的活动。
模块虽能单独运作，但是有的问题只有在全局上才会体现。组件往往是多个单元的集合。
1.2.2 集成测试的主要实施方案
- big bang（一次性集成）：
将所有的单元一次性组装起来，进行测试；
2. 自顶向下；
3. 自底向上：
从程序模块的最底层逐级向上测试：组件-子模块-模块-系统。
最常用的方法，对已经测试过的下级组装，不必再重复测试。
4. 核心系统集成：
对系统中核心的模块进行集成，再逐步扩大至系统其它功能。
5. 高频集成；
目前较为流行的敏捷开发，往往采用上述4和5结合的方式进行测试。
传统的瀑布式测试，往往采用上述2或者3的方式进行测试。
1.2.3 集成测试和单元测试的区别
|
|
测试对象 |
测试依据 |
测试方法 |
|
单元测试 |
软件详细设计 |
详细设计文档 |
白盒测试：关注软件内部 |
|
集成测试 |
软件概要 |
概要文档 |
黑盒测试为主：关注模块接口 |
1.3系统测试
1.3.1概念
将经过集成测试的软件，作为计算机系统的一部分，与系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效测试，以发现软件潜在的问题，保证系统的正常运行。
企业当中，如果有专职的测试人员，往往是针对系统测试这个阶段的。
1.3.2关注点
1. 从功能上，关注系统本身的使用情况；
2. 关注系统与其他相关系统间的关联性；
3. 系统在不同使用压力下的情况；
4. 关注系统在真实环境下的表现；
1.3.3系统测试和集成测试的区别
|
|
测试角度 |
测试内容 |
|
集成测试 |
偏于技术角度验证 |
各个单元模块间的接口 |
|
系统测试 |
偏于业务角度验证 |
整个系统的功能和性能 |
1.3.4系统测试的类别
1. 恢复测试：关注软件运行失败的各种条件，并验证其恢复过程能否正常执行。
2. 安全测试：验证系统内部的保护机制，以防止非法入侵。测试人员扮演入侵者权限以试图突破防线。系统安全设计的准则为：让黑客侵入系统所需的代价更为昂贵。
3. 压力测试：在正常资源下，使用异常的访问量、频率或数据量来执行系统。可尝试执行以下操作：①输入数据量增加一个量级以观察输入功能的响应；②在虚拟操作系统下，产生大小为最大内存量的数据。
1.4验收测试
1.4.1概念
针对用户需求、业务流程的正式的测试，确定系统是否满足验收标准，由用户、客户或其他授权机构决定是否接受系统。
横向步骤：测试计划-测试设计-测试开发-测试执行-测试评估
测试计划：
1.4.2分类
1. 用户验收测试；
2. 运行验收测试：运维角度；
3. α测试：软件公司内部人员模拟用户行为进行操作；
4. β测试：组织各方面的典型用户在日常工作时使用软件，收集用户异常情况及改进建议。
5. release版本：正式提交版本；
