育才学习网1. 为什么要写测试需求
我们不应该把测试计划写得冗长以致让人畏惧，也不能写得很短以致毫无意义，被忽略。
模板是个好东西，但是模板会把作者的注意力从计划的目标转移-目标会因项目不同而不一样。计划可以是非常复杂，不精确和耗费时间的过程，但是写出来的测试计划不会把这些反映出来。
计划是关于如何做某样事情的思考。缺乏计划，授权给大家，依赖他们的技能、承诺、团队协作，这不仅不是银弹，而且有很多缺点。
例如，没有历史记录的保持，更难衡量和评估每个人的工作成绩。测试计划通常作为关于质量的重要文档呈现给管理层。
项目的4个因素由不同的文档来覆盖：时间-由项目计划覆盖，成本-由合同覆盖，范围-由需求文档覆盖，质量-由QA计划或测试计划覆盖。测试计划的内部作用和外部作用。
外部是给顾客一个信心，关于测试过程、技能、资源、工具等的信息。内部作用有3个：作为测试计划的结果，让相关人员和开发人员来评审。
存储计划执行的细节，让测试人员来进行同行评审。存储计划进度表、测试 。
2. 软件测试需求高级列表是什么
用户需求：描述了用户使用产品必须要完成的任务，在软件开发活动中，属于最基本的需求。
系统需求：描述了软件设计人员、编程人员必须要完成的任务。系统分析员通过分析用户需求，把用户的需求转变成开发设计人员看得懂的系统需求。
测试需求：描述了软件测试人员必须要完成的任务。测试工程师通过分析系统需求，产生测试需求，作为测试活动的指导。
测试需求分析过程，下面举个例子给你说明下：
用户需求由最终用户提出，通常比较笼统，例如用户可能会这样描述其需求，
UR1 “能够上网缴电话费”
系统分析员的工作就是分析用户需求，把用户的需求转换成开发设计人员能够理解的系统需求。系统需求从技术层面上对用户需求进行分析，把用户的需求分解成若干个功能点，例如
SR1 登录缴费系统
要求加密传输，密码不少于6位等
SR2 输入电话号码
要求验证号码的正确性
SR3 查询特定的电话费
查询结果中要包含各类明细
SR4 缴费
连接网上银行页面，要根据不同商业银行的网银，做不同的判断；
缴费结果一定要明确显示
… …
在测试小组参与后，资深测试工程师要根据系统需求，编写相应的用户需求。用户需求一定要保证对系统需求的100%覆盖，即系统需求的所有功能点在用户需求中必须有所反映。例如
TR1-1 登录成功
TR1-2 登录失败
……
上述的TR1-1到TR1-2都对应于系统需求的SR1（功能点）。
测试工程师要编写测试用例，依据是测试需求，测试用例要保证对测试需求的100%覆盖，即测试需求的所有检查点在测试用例中必须有所提现。例如
TCF1-1-1
输入用户名huior，对应的密码987654，以及验证码
预期结果：用户正确登录缴费系统，进入欢迎界面
TCF1-2-1
输入不存在的用户名huior_error，密码123456，以及验证码
预期结果：提示“用户名不存在”的错误，返回登录界面
TCF1-2-2
输入正确的用户名huior，密码 123456，以及验证码
预期结果：提示“密码错误”，返回登录界面
TCF1-2-3
输入正确的用户名huior，密码 987654，以及错误的验证码
预期结果：提示“验证码错误”，返回登录界面
… …
至于你说的高级列表，不知道是否指优先级。
3. 需求测试怎么做
欢迎进入IT技术社区论坛，与300万技术人员互动交流 >>；进入 需求测试软件测试 软件测试V模型要求我们在需求阶段就开始制定系统测试的计划，开始考虑系统测试的方法。但这还不是足够的。全面的质量管理要求我们在每个阶段都要进行验证和确认的过程。因此在需求阶段我们还需要对需求本身进行测试。这个测试是必要的，因为在许多失败的项目中，7 0 %~8 5 %的返工是由于需求方面的错误所导致的。并且因为需求的缘故而导致大量的返工，造成进度延迟、缺陷的发散，这是一件及其痛苦的事情。因此我们要求在项目的源头（需求）就开始测试。这类测试更多的还只是静态手工方面的测试，当然也有一些自动化的工具，但这些工具会要求我们按照某个固定的格式进行需求的表述（例如形式化的方法），因此在适用性上会受到限制。通过静态手工方法进行需求测试中最常使用的手段是同行评审。 通过评审来测试需求
同行评审是业界公认的最有效的排错手段之一。我们在需求测试过程当中，使用最多的也是同行评审（Peer Review），尤其是正规检视（Inspection）。正规检视是由Michael Fagan 在I B M 制定出来的一种非常严格的评审过程。
好的需求应当具有的特点
一个良好的需求应当具有一下特点：
完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
正确性：每一项需求都必须准确地陈述其要开发的功能。
一致性：一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。
可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。
无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。
健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。
必要性：“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如Use Case或别的来源。
可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。
可修改性：每项需求只应在S R S 中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。
可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（f i n e - g r a i n e d ）的方式编写并单独标明，而不是大段大段的叙述。
另外应当对所有的需求分配优先级。如果把所有的需求都看作同样的重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度