1、测试人员尽早介入
尽量在需求阶段就开始介入,其好处不言而喻,尽早发现问题可以有效的降低项目风险和修复成本。让质量保障的工作贯穿整个软件开发的生命周期,有效的进行 缺陷预防。
2、验证需求
为每个需求提供 质量度量标准,具体而言就是针对需求划分2个分类:满足需求分类和不满足需求分类。要明确满足需求和不满足需要的具体度量标准,是模糊的需求明确化。对于不易明确化的需求,可以进行需求划分,把大需求划分为若干个可以明确的小需求。验证需求时需要验证的属性:
- 正确性:根据用户的需求进行验证。是否正确的完成了用户的真实需求。
- 完整性:用于保证需求中没有遗漏任何必须的元素。避免遗漏原始需求。
除了功能性需求之外,非功能性需求也需要验证,具体包括:性能、安全、可用性、兼容性、可访问性等。非功能性需求可以分为系统级需求和功能级需求。非功能性需求检查表如下:
- 一致性:是否有互相矛盾的情况。排除有歧义的地方。
- 可测性:需求是否可以测试并且有准确的预期输入和结果。否则需要提醒相关风险。
- 可行性:保证需求可以在有效的资源内被完成。比如:预算、进度、技术等。
- 必要性:确认需求是否为必须,如果去除是否有任何问题。
- 优先级:为每个需求确定其优先级,便于后期在必要时对需求进行取舍。
- 明确性:需求的陈述需要精确且可测量。比如:性能指标不能以很快来描述。
- 可追溯性:明确需求被哪些功能模块所调用。保证在需求变化的时候可以追溯影响的范围。
3、需求就绪后立即设计测试过程
测试过程是对需求可测试性的再次确定,在有效的时间内为每个需求设计尽可能的测试过程,必要的情况下可以按照优先级来顺序完成,在需求得到精化后需要同步更新测试过程。测试过程应当包含:需求的输入数据、需求的验证步骤、已知的预期结果。
4、确保需求变化的传达
如上3所述,需求在变化后需要尽快的通知到所有相关的涉众。包括设计、编码、测试。这样才能保证需求能够被完整的消化,否则可能会引发较多的无效缺陷。
5、注意在现存系统上进行开发和测试
基于现存的系统进行开发或者重构,往往会有很多问题。比如:新旧系统的一致性等。如果要避免2个版本的并行开发的问题,则需要按照如下流程来管理开发项目:
- 使用确定版本作为基准版本
- 把该版本程序进行文档化【如果有则可省略】
- 基准版本有更新时也要文档化
- 固化形成的有效开发过程
6、了解手头的任务和相关的测试目标
判断一个程序功能是否正确的要素:
- 合法输入有正确的返回
- 非法输入有对应的提示
- 不论何种输入程序都不应挂起、崩溃或退出
- 可以在预定的时间内一直正常运行
- 实现了功能性、非功能性需求
了解测试目标的途径如下:
- 理解系统。从更高的层次来理解需求,而非独立的思考需求本身
- 尽早介入
- 理解企业文化和过程。为更好的适应和提出改进意见做准备
- 实现的范围
- 测试期望。高层、客户对测试的期望
- 吸取教训
- 工作量大小
- 解决方案的类型。复杂的解决方案,还是简单的解决方式
- 技术选择。根据技术栈确定待测对象
- 预算。根据预算来确定投入的测试工作量
- 时间表。根据时间表来调整测试时间
- 版本提测方式。迭代提测还是大版本提测
在对系统有了全面的了解后,就可以知道系统的规模和相应的工作量、客户的问题及潜在的风险。通过这些信息来了解当前的测试任务,并据此确定测试目标及对应的测试框架。最终形成测试计划或者测试策略文档。
7、考虑风险
标签:需求,功能性,版本,验证,50,阶段,测试,提测,软件测试 From: https://blog.51cto.com/u_15918230/5954452