软件测试：管理篇

发布时间：2024-03-23 19:09:21 来源：互联网

.

软件测试：管理篇本节内容测试需求分析和测试策略制定测试方案的设计测试执行流程的设计测试报告的输出（在系统测试阶段）测试策略制定需求，是软件设计与测试的来源。需求

软件测试：管理篇

本节内容

测试需求分析和测试策略制定
测试方案的设计
测试执行流程的设计
测试报告的输出（在系统测试阶段）

测试策略制定

需求，是软件设计与测试的来源。需求除了终端用户的功能需求外，还有设计性需求、可靠性需求、可测试性需求、性能需求、安全性需求等。需求也是要进行测试的。
需求，设计，编码，开发，测试一系列阶段中，需求成本最低，测试成本最高。
对于测试工作而言，所有的需求最后都需要转换为测试需求。

从测试需求开始

50%以上的错误来源于需求的错误。
测试需求的识别是后续的测试工作的基础，也是起点。
测试需求主要来源于业务需求。我们在拿到需求后，要能识别测试需求，接着是分析此测试需求，最后确定并提取出测试对象。
提取出了测试对象后，接下来需要确定对每一对象如何进行测试，拿出具体的方法及措施出来，这便是测试策略制定的问题。
完整的需求文档包括以下内容：

功能需求
非功能性需求
性能需求
安全性需求
扩展性需求
可靠性需求
可移植性需求
易用性需求
兼容性需求

需求分析注意事项：

测试应该尽早的介入，从用户需求阶段就要介入。
不断变化的需求需要及时的收集和整理。
没有需求文档时，需要测试人员不断的收集原始的客户需求，（敏捷的测试对于需求文档的要求比较低。）
应有质疑、坚持的精神，当需求不明确时，可以将需求追溯到终端用户。

案例1：手机的日历提醒事件丢失了

A是软件测试部负责此日历行程的测试工程师，在做日程提醒事件测试时，他发现如果手机电力不足（不足于开机），而这段时间正好有提醒事件发生，则在下次开机后不会再提醒，即发生在没电池时段内的提醒事件会丢失。
而对于这种特殊情况，需求并未有明确定义（需求只定义了到达约定的时间便进行响铃提醒，并弹出事件窗口）。于是A找到需求、开发讨论关于这种特殊情况的处理。开发认为，电力不足的情况下，本来就不可能开机，提醒事件也就不可能弹出来，目前的处理是合理的。需求设计人员认为，如果在不能开机的情况下，提醒事件需在下次开机后进行积累提醒，如果用户一个月没用此机，事务每天又多的话，再次开机后的消息太多了，光关闭这些事件窗口都不是—件易事，用户未必欢迎。最后这个问题就此搁浅（挂起）了。
无独有偶，当该产品上线约一年后，从市场返回一张更改申请单，上面反映“客户一天晚上，取出机子的电池在机外充电。后来由于忙于其他事情，3天后才再次打开MP4来使用后发现，这3天内的提醒事件一个都没有，导致她把提前3天预订飞机票的事给忘了，误了她的一桩大事。后来打电话到某公司当地办事处进行投诉。