软件测试教程 第七节 测试管理篇
在之前的课程中，我们没有涉及测试管理部分的工作。这部分工作往往在公司中由team leader的角色来承担。包括整个测试过程的组织、测试方案的制定、测试报告的输入、以及进一步的测试的分析与改进。
在本节课中我们将涉及以下内容：
- 测试需求分析和测试策略制定
- 测试方案的设计
- 测试执行流程的设计
- 测试报告的输出
测试需求分析和测试策略制定
需求，是软件设计与测试的来源，但是需求除了终端用户的功能需求外，还有设计性需求、可制造性需求、可测试性需求、性能需求、安全性需求等。
对于测试工作而言，所有的需求最后都需转化为测试需求。之后分析这些需求，并以此为根据来制定测试策略，合理选择各种测试技术。比如是否需要自动化测试？是否需要性能测试？回归测试的范围是什么？是否需要专项测试？黑盒测试能否满足，要不要白盒测试或者灰盒测试？
从测试需求开始
50%以上的错误来源于需求的错误
测试需求的识别是后续的测试工作的基础，也是起点。测试需求主要来源于业务需求。我们在拿到需求后，要能识别测试需求，接着是分析此测试需求，最后确定并提取出测试对象。
提取出了测试对象后，接下来需要确定对每一对象如何进行测试，拿出具体的方法及措施出来，这便是测试策略制定的问题。
多管齐下溯需求
完整的需求文档包括以下内容：
功能需求
非功能性需求
性能需求
安全性需求
扩展性需求
可靠性需求
可移植性需求
易用性需求
兼容性需求
测试应该尽早的介入
不断变化的需求需要及时的收集和整理
没有需求文档时，需要测试人员不断的收集原始的客户需求
应有质疑精神，当需求不明确时，我们可以将需求追溯到终端客户
【案例】手机的日历提醒事件丢失了
A是软件测试部负责此日历行程的测试工程师，在做日程提醒事件测试时，他发现如果手机电力不足（不足于开机），而这段时间正好有提醒事件发生，则在下次开机后不会再提醒，即发生在没电池时段内的提醒事件会丢失。
而对于这种特殊情况，需求并未有明确定义（需求只定义了到达约定的时间便进行响铃提醒，并弹出事件窗口）。于是A找到需求、开发讨论关于这种特殊情况的处理。开发认为，电力不足的情况下，本来就不可能开机，提醒事件也就不可能弹出来，目前的处理是合理的。需求设计人员认为，如果在不能开机的情况下，提醒事件需在下次开机后进行积累提醒，如果用户一个月没用此机，事务每天又多的话，再次开机后的消息太多了，光关闭这些事件窗口都不是—件易事，用户未必欢迎。最后这个问题就此搁浅（挂起）了。
无独有偶，当该产品上线约一年后，从市场返回一张更改申请单，上面反映“客户一天晚上，取出机子的电池在机外充电。后来由于忙于其他事情，3天后才再次打开MP4来使用后发现，这3天内的提醒事件一个都没有，导致她把提前3天预订飞机票的事给忘了，误了她的一桩大事。后来打电话到某公司当地办事处进行投诉。
考虑可测试性需求
上节介绍的主要是用户角度业务性测试需求的提取，本节讨论站在测试角度本身可测试性需求的问题。可测试性需求需尽早发现，否则到项目后期，就会陷入一种欲罢不能的状态。
甚至对于一些需求，由于它很重要，但又不可测，软件的质量完全无法度量，只能在准生产或者生产环境来进行验证。
可测试性(Testability)
简单地说，是指软件可以被完全有效测试的程度。
这一概念的解释最早在1990年的IEEEstd.610.12中给出。Freedman在1991年提出把可测试性定义为可控性和可观察性的集合，随着时间的推移这一概念不断丰富完善。
目前软件可测试性要求主要包含可观察性（即可见性）、可控制性、可操作性、简单性和稳定性等。
由于前二者更具代表性，下面主要介绍它们的特性与使用场景。
可见性
指被测软件的状态、数据输出、资源利用和其他影响能被准确地测试到，以决定测试是否通过。
可见性，并不限制在UI界面中能看到数据或状态的输入与输出。一些软件由于工作本身服务于底层，如主机与客户端的通信，后台数据库的处理，这些数据的中间处理过程在UI层并不可见，此时就存在一种可测试性的问题。
当然解决类似问题的方法很多，如增加日志记录就是一种常用且很好的方式。通过日志记录的内容，测试人员可以很清楚软件的中间处理过程。
当我们发现某些功能不知道是否正确时，可以增加日志等方式来测试。
案例：
系统中要求每日晚上以后台任务的方式导入第三方系统的数据，并且以增量方式导入。
测试方法：
1、查看双方的数据库数据，两者保持一致
2、那么如何判断为增量还是全量呢？
增加导入日志来解决
在数据表中增加导入数据的时间戳
以上都需要开发人员预先在代码中进行处理。而这些需求是测试人员应该提出的而不是需求分析人员。
可控性
指能向被测软件输入预期的数据，或修改它的状态，如一个应用程序有事件触发的阀值，能够设置和重新设置那些阈值可简化测试。
测试过程中，常会遇到一些测试环境难于模拟，但实际情况又有可能发生的场景
案例：
需求要求用户消费满3000元并且注册一年后自动升级为银牌用户。系统的消费支持支付宝支付。
测试方法：
1、有支付宝模拟器可以进行正常的消费返回
2、可以进行修改系统时间，或者用户注册时间来进行测试
分析需求
识别庐山真面目
1、快速理解需求的捷径：需求宣讲
主要解决问题：需求理解不一致
方式：介绍需求背景、内容，进行答疑
案例：
需求要求注册时姓名可以输入16个字符
开发理解：16个字符，也就是英文16个，中文8个。
测试理解：无论英文、中文或其他语言都是16个。
2、需求也会错
需求文档也需要测试：正确性，必要性，完整性，一致性等
3、从设计需求中提取测试需求
软件需求是软件测试需求的主要来源，但不是全部来源，软件设计需求、软件概要设计、详细设计也都是测试需求的分析对象，是对测试需求的一种有力的补充。对于黑盒功能测试，几乎98%的需求都是来源于需求说明书，但有那么一小部分需求来自设计需求或概要设计、详细设计。也就那么小部分需求，如果我们没有意识到，就会给用户带来隐患。
【案例】设计需求转换为测试需求失败
问题现象：待测软件在Vista Home Bbasic 32系统下安装失败。
问题分析：测试人员在总结中提到“软件一直在各种宣称的支持平台上运行得很好，在不同的平台之间进行安装测试不下100次，但是最后一个版本开发人员更改了安装程序，来不及在每个平台上铺开进行用户场景的测试，而问题却恰巧就出现在没测试的平台上”。
测试要及时发现此问题，难道每次对发布的版本都只能通过在各种操作系统环境之下重新再测试一遍的穷举方式来网罗未知的问题吗？
所测试的软件是用C# (DotNET)开发的，而Dot NET开发出的软件运行与操作系统自身是否安装了Dot NET Framework有荚，且还与版本有关。在进行安装测试时，测试人员并没有分析到这些影响因素。此Bug是因为软件在安装过程中发现当前操作系统自带了Dat NET Framework 3.0组件，且版本比发布软件包中自带的高凸安装程序遇这种情况不会安装自带的Dot NET Framework 2.0 SP1补丁包，于是中断了安裴过程，并提示安装失败。
这里面包含着两方面的问题：
1、安装程序遇到这种情况，不应该失败，应该继续安装
2、Dat NET Framework 3.0是否向下兼容
思考一下：
测试要懂编程么？
测试策略制定
确定顶层方向性测试类别
在分析了需求之后，我们要确认测试业务涉及的测试类别，例如：
功能测试
性能测试
安全性测试
兼容性测试
文档测试
安装卸载测试
其他专项测试
思考案例：
一个全新上线的app需要做哪些测试？
一个增加了新功能的app需要做哪些测试？
一个只修改了页面广告的app需要做哪些测试？
部署测试策略
测试策略需要确认测试使用的测试技术、测试过程的管理和控制、测试团队的组建
根据测试的需要，选择测试技术，例如：
1、需不需要白盒测试？
2、自动化测试采用哪种工具？针对接口测试还是UI测试？
3、性能测试采用哪种工具？jmeter还是loadrunner？
4、app兼容性测试如何做？手工测试还是使用平台测试？
在测试方案中，我们也需要确认测试过程如何管理，确认管理使用的工具和方法，比如：用例的管理方式、bug的管理方式和工具。
在没有固定测试团队的企业，还需要考虑团队的组建，比如测试的人数，高中低级的配比，入场出厂时间等等。
确认测试资源，需要多少资源？资源是否到位？
测试计划的制定
根据不同的开发模式，确认测试计划，计划主要包括：什么人、什么时间、做什么事情。
测试的目标要明确，同时要确认跟踪机制。
案例：
参见《软件测试计划模板》
测试方案设计
每一个公司对测试计划和测试方案的定义都不一致。
不是每一个公司都有测试计划和测试方案。有些只有测试计划，有些只有测试方案，有些两个都有。
测试用例不是测试方案。
测试方案主要包括以下内容：
1、测试范围：由需求分析而来
2、测试策略：包括针对不同部分的测试方法、测试用例
3、测试控制：包括测试流程，测试执行，缺陷跟踪
4、其他：环境、版本管理等
5、测试风险
案例：
参见《FAT测试方案》
测试执行流程的设计
测试方案与用例的设计，是属于纯测试技术上的设计，但对于整个项目的测试过程，光有技术还不够，需要配合合适的测试流程，策划什么时候做什么事，达到什么要求。好的策划可以对项目的测试起到事半功倍的作用。
需求测试
基于需求的测试方法是基本的测试方法，而需求的质量直接影响到后续的开发和测试工作。
需求审核
需求测试
测试设计中进行需求测试
需求测试要素：正确性，必要性，完整性，一致性
需求测试应该尽早开始
内部发布版本测试
冒烟测试
版本测试中信息传递：修改内容，风险分析，配置管理
回归测试
- 确认回归内容
- 确认回归的方式：手工、自动化
- 用例的回归
- bug的回归
回归测试是自动化测试最好的用处
交叉测试
测试的枯燥性、重复性，引起的惰性
不同的思维模式
交叉测试多在测试的后期，功能基本稳定时进行
测试报告的输出
在项目测试完毕后，需要出具测试报告
测试概况
测试过程分析
测试结论
缺陷清单
案例：
参见《功能测试报告》
回顾整个测试过程
需求分析--测试计划--测试方案--需求测试-测试用例编写--测试执行（冒烟测试，回归测试，交叉测试）--测试报告
