基于需求的测试
来源:互联网 发布:淘宝卖家免费工具 编辑:程序博客网 时间:2024/04/30 08:08
转载:http://softtest.chinaitlab.com/qtpm/908588_2.html
测试人员的首要职责是找bug,但是最重要、最根本的职责应该是在软件产品发布前确保公司的软件产品满足顾客的需求。
测试组采用RBT(Requirements-based testing),基于需求的测试方法会使测试更加有效,因为它使测试专注于质量问题产生的根源。
研究报告指出,多年来,大部分的软件项目不能按计划完成,不能有效控制成本。大部分项目失败的首要原因是软件质量差,导致大量的返工、重新设计和编码。其中软件质量差的两大原因是:软件需求规格说明书的错误、有问题的系统测试覆盖。
需求规格说明书中的错误
我们经常听到最终用户抱怨、不用我们的软件,而这些软件还通过了严格的测试和QA。对于这点我们不会感到惊讶,原因是我们知道需求从一开始就是错误的。
一项调查(James Martin (“An Information Systems Manifesto,” Prentice Hall, 1984)表明56%的缺陷其实是在软件需求阶段被引入的。而这其中的50%是由于需求文档编写有问题、不明确、不清晰、不正确导致的。剩下的50%是由于需求的遗漏导致的。
有问题的测试覆盖
要获得满意的测试覆盖率是很难的。尤其现在的系统都比较复杂,功能场景很多,逻辑分支很多,要做到完全的覆盖几乎不可能。
再者,需求的变更往往缺乏控制,需求与测试用例之间往往缺乏可跟踪性。
RBT三大最佳实践
1、 Test early and often.尽早测试,频繁地测试
确认需求的业务价值。
各利益相关方应该对需求进行评审。
通过用例检查需求的完整性
应用语言分析技术确保需求文档清晰一致,不会引起同一问题不同人有不同的解释。
2、 Test with your head, not your gut.不要单凭经验测试
不要依赖测试人员的经验来设计测试用例,应该采用系统、严格的测试用例设计方法,而不是依赖有经验的测试人员的技巧。通过这样的方式来增加测试覆盖的有效性。格式化、结构化的需求文档有助于测试人员评估需求的测试覆盖率。
通过测试用例评审来检查测试用例存在的错误,并且找出需求的不足之处。
3、 Test with measurement and improvement in mind.测试过程中要保持度量
在使用基于需求的测试方法的过程中,保持对需求的可追踪性非常重要。保持需求与测试用例及测试之间的可追踪性有助于监视进度、度量覆盖率,当然也有助于控制需求变更。
- 基于需求的测试
- 基于需求的测试(RBT)
- 基于需求的测试研究-静态测试
- Risk and RBT(风险及基于需求的测试)
- 基于需求的测试用例设计方法
- RBT三大最佳实践(基于需求的测试)
- Risk and RBT(风险及基于需求的测试)
- 没有需求的测试
- 基于android的浏览器需求
- 测试的一些基本需求
- Web Service的测试需求
- 静态测试 --需求测试的核心
- 基于UFT12.0,满足N个用户申请新店铺需求的测试脚本的自动化实现
- 测试需求
- 基于usecase的需求分析过程
- 基于用例的需求管理框架
- 基于用例的需求管理
- 需求阶段测试工作的开展
- ubuntu修改主机名后无法解析主机
- Choosing innodb_buffer_pool_size
- MSVCRTD.lib(crtexe.obj) : error LNK2019: 无法解析的外部符号 _main,该符号在函数 ___tmainCRTStart
- PHP DOM
- 如何利用多核CPU来加速你的Linux命令 — awk, sed, bzip2, grep, wc等
- 基于需求的测试
- 转职的道路
- The InnoDB Buffer Pool
- 黑马程序员-java基础
- 在linux下运行sfml example
- 使用bootstrap设计的后台管理界面
- Configuring the Rate of InnoDB Buffer Pool Flushing
- K&R快速排序的解释
- Optimizing InnoDB Disk I/O