软件测试:原理、方法与管理（读书笔记1）

第一章 软件测试生命周期

1.1软件测试基础

1.1.1软件测试的目的

    测试目的决定了如何来组织测试。

    如果测试的目的是尽可能多的找出错误，那么测试应该针对对软件中比较复杂的部分或者以前出错比较多位置。

    如果测试的目的是给最终用户提供具有一定可信度的质量评价，那么测试就应该针对在实际应用中会经常用到的商业假设。

 （1）软件测试是为了发现错误。

 （2）测试是为了证明程序有错误，而不是证明程序无错误。

 （3）一个好的测试用例在于发现了至今未发现的错误。

 软件测试：软件测试是为了发现错误而执行的程序的过程。

1.1.2

（1）测试可以评估软件项目产品是否达到预期目标和是否能被客户端接受。

（2）测试不紧包括对代码，还包括对需求的测试。

1.2 软件开发和软件测试的关系。

需求分析阶段------测试需求分析：分析测试过程中所需要的资源、配置、各阶段评审通过的标准。

概要设计、详细设计阶段-----制定集成测试计划和单元测试计划。

程序编写阶段------测试脚本、测试案例准备。

测试阶段---实施测试，提交测试报告。

1.2.1软件开发模型

1、边做边改模型：拿到项目需求立即编写程序，调试通过后交付给用户。如果程序错误或者新的需求，开发人员再修改直到用户满意。

    （缺少规划和设计，忽略需求，没有考虑程序的可维护性和任何文档，作坊式开发方式）

2、瀑布模型：制定计划、需求分析、软件设计、程序编写、软件测试、运行维护六个基本活动自上而下、如同瀑布流水，逐级下落。

   （线性过程太理想化，已经不适合先点软件开发模式，被业界抛弃。早期的错误可能等到开发后期才能被发现）

3、快速原型模型：尽快建立原型，之后确认客户需求，所建造的原型会被丢弃或者迅速修改。

4、增量模型：交付一个满足客户需求子集的一个可运行产品。

（容易退化成边做边改模型）

5、螺旋模型：结合了瀑布模型和快速原型模型，强调了风险分析，适用于大型复杂的系统。

6、演化模型：用于事先不能完整定义需求的软件开发。用户给出核心需求，看到核心需求后。提出增强系统能力的需求。可以看做是重复执行的多个瀑布模型。

7、喷泉模型：面向对象的生存期模型。就像喷泉的水喷上去又可以落下来，可以落在中间也可以落在最底部。各个阶段可以相互重叠多次反复。

8、智能模型：4GL技术，紧限于事务信息系统的中小型应用程序开发。

9、混合模型：几种不同模型组合成一种混合模型。

1.2.2模型中的测试

1、软件测试环境的搭建

（1）硬件环境

（2）软件环境

（3）网络环境

（4）数据准备

（5）测试工具

测试工具有：

静态测试工具

动态测试工具

黑盒测试工具

白盒测试工具

测试执行评估工具

测试管理工具

搭建测试环境的注意事项：

（1）尽量模拟用户的真实使用环境。与生产环境保持一致。

（2）测试环境应该与开发环境独立。

2、软件测试的模型

v模型

、

w模型

1.2.3 敏捷测试

1.3软件测试过程

单元测试-》集成测试-》系统测试-》验收测试

集成测试大多使用黑盒的测试方法。

测试计划-》测试方案-》测试策略

测试用例主要内容：

测试环境、测试输入、测试操作、预期结果、评判标准

测试用例的类型

等价类划分测试用例：合理的等级类，不合理的等价类，尽可能多的覆盖尚未被覆盖过的合理等价类。

边界值测试用例：输入值的范围是【1,100】，可取0、1、100、101作为测试数据。

功能测试用例：占测试用例集的50%~80%

1、功能是否符合要求 2、功能是否完整 3、功能是否有作用  4、功能是否无错误

设置测试用例：检查代码逻辑结构和使用的数据是否符合系统需求。

压力测试用例：找出安全临界值。可以考虑一下几点：1、cpu的处理速度 2、cpu使用率 3、磁盘空间 4、内存容量 5、虚拟内存容量 6、使用者数量  处理信息量多少

错误处理测试用例：设计一些可以让被测试软件发生错误的环境来查看软件是否依然运行正常。可以考虑一下几点：1、防范错误发生、如何处理错误、如何告知错误。

回归测试用例：确保改动的程序不会引起其他问题。考虑方向是指必须确保核心功能和其他主要功能运作正常。测试用例重复被使用。

状态测试用例：

结构测试用例：白盒测试，以程序内部逻辑为基础设计的测试用例。几种常用的覆盖包括：语句覆盖、判定覆盖、条件覆盖、条件组合覆盖、路径覆盖等。

其他测试用例：性能测试用例、兼容性测试用例、发行验证测试用例和界面测试用例。

设计测试用例的原则

1、一个好的测试用例能够发现之前没有发现的错误

2、测试用例应该由输入测试数据与对应的预期输出结果组成

3、在设计用例时，应该包含合理的输入和不合理的输入

测试用例应该注意以下策略：

1、测试用例的代表性：能够代表各种合理和不合理、合法和非法、边界和越界以及极限的输入数据、操作和环境设置等。

2、测试结果的可判定性：测试执行结果的正确性是可判定的或可评估的。

3、测试结果的可再现性：同样的测试用例，系统的执行结果应该相同。

在任何情况下都必须使用边界值分析方法，经验表明这种方法设计的测试用例发型程序的错误能力最强。

好的测试用例特征：

1、可以最大限度找出软件隐藏的缺陷。

2、可以最大效率找出软件缺陷。

3、可以最大限度满足测试覆盖要求。

4、既不能太复杂，也不能过分简单。

5、可以清楚的判定软件缺陷。

6、测试用例包含期望的正确结果。

7、待查的输出结果或者文件简单明了。

8、测试案例不重复

9、测试用例内容清晰，格式一致，分类组织。

测试用例文档：

测试用例文档应该有文档模板，必须符合内部规范要求。

测试用例文档由简介和测试用例两部分组成。

简介：测试目的，测试范围，定义术语、参考文档、概述等。

测试用例：逐一列出各测试用例。每个测试用例包括信息：用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果（含判断标准）、出口标准、注释等。

基本要素：测试索引、测试环境、测试输入、测试操作、预期结果、评价标准。

测试用例的设置

早期的测试用例按功能设置，后来引进了路径分析法。按功能测试是最简捷的，按用例规约遍历测试每一个功能即可。对于涉及复杂操作的程序模块，其各个功能的实施是相互影响的，紧密相关的，可以演变出数量繁多的变化。没有严密的逻辑分析，产生的遗漏在所难免。

一般情况下功能、路径混合的模式设置用例。

测试用例的设计方法

设计基本事件的测试用例。这项工作应该参照需求设计规格说明书，根据关联的功能、操作按照路径分析法设计测试用例。而对孤立的功能则直接按照功能设计测试用例。基本事件的测试用例应该包含所有需要实现的需求功能，覆盖率达100%

设计备选事件和异常事件的测试用例。比较复杂，因为设计阶段形成的文档对备选和异常事件分析和描述不够详尽，而测试本身则要求验证全部非基本事件，并同时尽量发现其中软件缺陷。

等价类划分、边界值分析法、错误推测法、因果图、逻辑覆盖法等测试用例。

1.4软件测试级别

1.4.1单元测试

单元测试是在软件开发过程中进行的最低级别的测试活动，例如c++程序，单元测试的对象可能是类，也可以是成员函数。单元测试的对象是软件设计的最小单位。常采用白盒测试的方法设计用例。

单元测试的策略：自顶向下，自低向上，孤立策略。

1.4.2集成测试

  在集成测试之前，单元测试应该已经完成，集成测试中所使用的对象应该是已经经过单元测试的软件单元。这一点很重要，因为如果不经过单元测试，那么集成测试的效果将会受到很大影响，并且会大幅增加软件单元代码纠错的代价。

集成测试的策略

自顶向下：深度优先、广度优先

自低向上

集成测试的计划书实例

引言

1.1编写目的
本文是描述****集成测试的大纲文章，主要描述如何进行集成测试活动？如何控制集成测试活动？集成测试活动的流程以及集成测试活动的工作安排。本文主要的读者对象是项目负责人，集成部门经理，集成测试设计师。
1.2背景
项目名称：***集成测试
项目相关对象：******************
1.3定义
**********：********************
1.4参考资料
《*********》测试项目
本测试主要为***系统的集成测试，***的版本为2.0,测试是***的最终集成测试，是建立在开发组程序员开发完毕自己的测试以及开发组测试的基础之上被测特性
3.1操作性测试
主要测试操作是否正确，有无误差？分为两部分：
3.1.1返回测试
由主界面逐级进入最终界面，按EXIT键逐级返回，检查返回时候屏幕聚焦是否正确
比如：
1. 进入“系统设置”
2. 进入“频道搜索”
3. 进入“自动频道搜索”
4. 按EXIT键返回，检查当前聚焦是否为“频道搜索”
5. 按EXIT键返回，检查当前聚焦是否为“系统设置”
3.1.2进入测试
由主界面逐级进入最终界面，按MENU键返回主界面，再次进入，检查是否聚焦正确
比如：
1. 进入“系统设置”
2. 进入“频道搜索”
3. 进入“自动频道搜索”
4. 按MENU键返回主界面
5. 当前聚焦是否为“系统设置”
6. 进入“系统设置”，当前聚焦是否为“频道搜索”
3.2功能测试
测试机顶盒中每个应用的功能是否正确
3.3性能测试
3.3.1疲劳性测试
测试连续开机1个月不关机器，每3天去运行一次应用。看系统的稳定性
3.3.2大容量数据测试
前段***数据库表中含有大量数据，测试***功能不被测特性
测试方法
1. 书写测试计划
2. 审核测试计划，未通过返回第一步
3. 书写测试用例；
4. 审核测试用例，未通过返回第三步
5. 测试人员按照测试用例逐项进行测试活动，并且将测试结果填写在测试报告上；（测试报告必须覆盖所有测试用例）
6. 测试过程中发现bug，将bug填写在bugzilla上发给集成部经理；（bug状态NEW）
7. 集成部经理接到bugzilla发过来的bug
7.1 对于明显的并且可以立刻解决的bug，将bug发给开发人员；（bug状态ASSIGNED）；
7.2 对于不是bug的提交，集成部经理通知测试设计人员和测试人员，对相应文档进行修改； （bug状态RESOLVED，决定设置为INVALID）；
7.3 对于无法修改的，将这个bug放到下一轮次进行修改；（bug状态RESOLVED，决定设置为REMIND）
8. 开发人员接到发过来的bug立刻修改；（bug状态RESOLVED，决定设置为FIXED）
9. 测试人员接到bugzilla发过来的错误更改信息，应该逐项复测，填写新的测试报告（测试报告必须覆盖上一次中所有REOPENED的测试用例）；
10. 如果复测有问题返回第六步（bug状态REOPENED）
11. 否则关闭这项BUG（bug状态CLOSED）
12. 本轮测试中测试用例中有95%一次性通过测试，结束测试任务；
13. 本轮测试中发现的错误有98%经过修改并且通过再次测试（即bug状态CLOSED），返回第五步进行新的一轮测试；
14. 测试任务结束后书写测试总结报告；
15. 正规测试结束进入非正规测试，首先是ALPHA测试，请公司里其他非技术人员以用户角色使用系统。发现bug通知测试人员，测试人员以正规流程处理bug事件；
16. 然后是BETA测试，请用户代表进行测试。发现bug通知测试人员，测试人员以正规流程处理bug事件。
几点说明：
O 测试回归计划为三次；
O 测试用例应该写得比较详尽，步骤一定要标明清楚（应该包括：编号，测试描述，前置条件，测试步骤以及测试希望结果）；
O 对于测试人员觉得应该进行的测试项目，测试人员应该报告测试设计人员，完善和健全测试用例；
O 测试报告与测试用例分开，测试报告标明测试用例序号以及是否通过Y/N；
O 对于集成部经理无法决定的上交项目负责人决定；
O 性能测试中的疲劳性测试可以结合在功能测试部分，即测试期间不关闭机器；
O 性能测试中的大容量数据测试放在测试后部分轮次（第二步，只需要进行一次）测试通过标准
测试结果与测试用例中期望的结果一致，测试通过，否则标明测试未通过。
6.1测试结果审批过程
6.1.1测试回归申请结束
测试人员提出申请这轮测试结束，提交集成部经理；
集成部经理召集本组人员开会讨论；
讨论通过，进行下一轮测试，并且部署下一轮测试的注意事项，流程等内容；
如果发现这轮测试还存在问题没有解决，延期下一轮测试时间，讨论下一步工作应该如何进行。
6.1.2测试结果申请结束
测试人员提出申请测试结束，提交集成部经理；
集成部经理召集本组人员开会讨论；
1. 讨论通过，结束测试任务；
2. 如果发现测试还存在问题没有解决，延期测试结束时间，并且讨论下一步工作应该如何进行。挂起和恢复
7.1挂起条件
O 进入第一轮测试，测试人员大体了解一下产品情况，如果在一小时之内发现5个以上（含5个）操作性错误，或者3个以上（含3个）功能性错误，退回测试组测试；
O 遇到有项目优先级更高的集成测试任务；
O 遇到有项目优先级更高的集成任务；
O 在测试复测过程中发现产品无法运行下去；
O 人员，设备不足。
7.2恢复条件
O 符合进入集成测试条件（一小时之内发现5个以下（不含5个）操作性错误，或者3个以下（不含3个）功能性错误）；
O 项目优先级更高的集成测试任务暂告完成；
O 项目优先级更高的集成任务暂告完成；
O 复测过程中产品可以运行下去；
O 人员，设备到位。测试文件
O 测试计划书
O 测试用例
O 测试报告
O 测试总结测试任务
O 制定审核测试计划
O 制定和审核测试用例
O 进行测试活动
O 书写测试报告测试环境需求
10.1硬件需求
***********
10.2软件需求
************
10.3测试工具
*************
10.4测试需要的条件
**************
10.4.1 需要的文档
O 用户手册
O 应用手册
O 安装说明
10.4.2需要完成的任务
O 程序员本人测试
O 测试组完成测试角色和职责
O 集成（测试）经理：控制并完成测试任务和测试过程，决定测试人员提交上来的bug是否需要修改；
O 测试设计人员：书写集成测试用例；
O 测试人员：按照测试用例进行测试活动；
O 开发人员：MHP程序bug修改；
O 用户代表：进行BETA测试。人员和培训
O 集成测试经理有责任对测试相关人员进行测试流程，规章制度培训；
O 测试设计人员有责任对测试人员进行测试操作培训测试进度
测试工作 进度（人*工作日）
测试计划 8
测试设计 60
测试执行总共进度 30
每次回归进度 10
测试报告 2风险及应急计划
设备不到位：加紧设备购买；
人员不到位
人员请假：请假人员回来加班或赶紧测试进度/申请调配新的人员；
人员离职：调配新的人员；
人员调配到其他部门或项目：调配新的人员；
开发人员开发频频出错：通知开发部门，商量策略；
其他原因的测试工作频频被挂起或者挂起后迟迟恢复不了：加班或延期审批
集成部经理 技术部经理
姓名：姓名：
日期：日期：