正确性Correct
完整性Complete
一致性（内部、外部）Consistent
可测试性Testable
相对于传统软件开发，敏捷软件开发中关于用户故事的划分，Bill Wake也曾经提出过INVEST原则：
Independent独立的：用户故事相对于其他用户故事来说，应该是独立的。用户故事的依赖性可能导致任务估算的困难，进而影响计划的制定。通常情况下，可以使用组合或拆分用户故事的方式减少其相互之间的依赖性。
Negotiable可协商的/便于沟通的：一个用户故事的卡片应该包含故事详情的简短描述，详情通过讨论阶段完成。一张包含足够详情的用户故事卡片实际上是减少了和客户的沟通。
Valuable有价值的：每个用户故事都应该对客户有价值。一个让用户故事有价值的方法就是让客户写下来。一旦一个客户意识到一个用户故事并不是一个契约而是可协商的，用户将非常乐意写下他们。
Estimate-able可估算的：开发者应该可以估算用户故事，以确定优先级或进行故事规划。一些阻止开发人员估算的障碍包括：缺乏领域知识（这时应进行更多的沟通）、故事太大了（这时应对用户故事进行拆分）。
Small粒度合适的：一个用户故事应该在工作量上短小，且不超过2–3人周的工作量。超过这个范围，将会在范围划分和估算上出现问题。
Testable可测试的：用户故事只有可测试才可以确认何时完成。如，“软件应易于使用”，这个用户故事是不可测试的，因而开发和测试时也缺少明确的完成标准。
这五条特性中，独立性、价值性、可估算性、可测试性，都是对于传统软件需求划分也适用的。这样结合起来，软件需求也应该满足如下原则：
正确性
完备性
独立性
价值性
可估算性
粒度合适
可测试性
将这七点直接凑在一起，也有些不合逻辑，貌似是在从不同的层面上讨论需求的定义原则。使用下图可以对其分类整理，可以从内容、粒度、价值属性、可测试性四个维度对其进行约束。
内容维度：正确、完整且相互独立无依赖；
粒度维度：粒度合适，可估算（不存在无法估算或估算可能极其不准确的需求）；
价值属性：对用户有价值的需求，才值得实现；
可测试性：可测试性定义了需求实现的判定准则和工作范围，如果无法判断是否实现，即缺少明确的工作范围定义，后期可能导致项目的范围蔓延。
测试需求是主要是整理测试焦点(包括一些界面、输入域、业务流程、数据等)，并明确测试焦点的优先级，为测试用例的设计提供测试所需的功能点信息。测试需求的分析也会体现用例设计方法，有的测试需求分析文档中也会指导性的明确焦点的测试用例设计方法。可以说，测试需求是告诉你要测什么，而测试用例是告诉你怎么测。
好的测试需求能发现需求中显性和隐性的测试焦点，从而能更好的指导测试用例的设计，能更好的提高被测模块整体功能的覆盖率。
测试需求分析会根据不同阶段的测试类型会有不同的侧重点。我是做系统测试的，主要注重系统或软件是否满足用户需求的情况。平时做测试需求时会比较明确系统的功能模块和测试点明细整理，也会把测试案例设计方法同时加入到分析文档中。
欢迎分享，转载请注明来源：优选云
微信扫一扫
支付宝扫一扫
