在使用脑图进行用例设计的实践中，首先需要先出来两个中心。 两个中心分别是“需求分析”和“模块用例分析”。
对于明确需求，主要参考指标总结如下几点：
软件开发合同
项目开发计划
系统/子系统设计文档
软件需求规格说明书（含接口需求规格说明）
用户需求说明书
软件设计说明
对于继承需求，主要是该项目或产品的上游内容已有需求或指标，而这一块儿往往是最容易忽略的地方，所以单独拿出来统计分析。正如在做该项目之前，已经有过一个版本存在，并经过了大量的测试与实践，也进行了各种修改以及需求的完善，那么在设计本项目需求分析属性时，就应该继承上一版本的可用需求或指标，避免只是针对本项目的明确需求分析不到位，导致项目质量不过关。
所以，对于继承需求的参考指标，总结如下几点：
相关产品或上一版本的软件需求说明书
相关产品或上一版本的测试需求或测试报告
相关产品或上一版本在使用过程中遇到并且需要解决的问题汇总
隐含需求的指标需要十分有经验的测试设计人员的思考，要对项目或产品非常熟悉，甚至对该产品所属行业清晰明了。
主要的参考内容如：
有关产品使用场景的梳理数据
该产品相关的行业标准
非专业人士不清楚的特性指标（如六性要求、稳定性要求）
对于每一个子功能，都需要依据以下四个方面进行编写：
风险识别：任何项目都会有风险，那么我们应该提前想到各种可能的风险，然后想办法去识别、解决或避免它。在一开始使用脑图设计用例时，如果没有识别到风险，也不应该把该子项删除，而是保留，因为这样可以时刻提醒测试人员要有风险意识。另外，使用脑图设计用例的出发点就是要让每一个人思考，以思考作为测试的其中一个基准点，可以更好的提高测试质量。
目标、要素：此处主要是填写本子功能要达成的目标，或者是为了达成目标要解决的问题以及前提条件。如果该子功能是由多个更小的模块组成，还要写清楚模块的情况，便于接下来设计测试用例，提供测试依据，避免遗漏。
测试要点：这里是设计测试用例的主要属性，要对每一个测试要点设计测试，但是不要求设计人员把测试步骤写的太过详细，甚至可以不写测试步骤，我们需要写的是描述，需要说清楚我们要验证什么、测试什么。具体的就由测试执行人员进行。但是，为了避免测试遗漏，我们需要在测试描述中，写清楚测试项所采用的测试方法，例如基本的边界值或者等价类的设计方式，然后还要描述清楚该模块正常执行和异常执行下，不同的结果反馈。
业务场景：此处是对功能点的一个贯穿，使用场景法进行测试设计。尽量设计尽可能少的业务场景把本功能的所有需求点都涵盖进去，保证基本的业务流是可靠可用的。同时，整个功能性测试设计层级中，有一个“业务总场景”，目的就是把被测试产品的整个业务线连起来，做一次较全面的测试。场景的数量尽量少，但是要精炼，把各个要素、节点都包含进去。
需要注意的是，以上所有的测试描述，尽量写事实或预期，不要出现过多的步骤性和“死”点（需求明确说明的除外），这样的好处是让测试设计者和执行者，都能充分理解测试的内容，并且给足了他们测试方法或要素等的提示，避免了测试不全，也杜绝了本应让自动化工具执行的重复性的工作。
功能性测试与适应性、准确性、功能性依从(功能性)、成熟性(可靠性)、易测试性(维护性)方面的质量子特性相对应。
功能性测试需要测试软件产品的功能，完全不考虑程序内部逻辑结构，针对软件界面和功能进行测试。检查程序功能是否符合需求规格说明书的规定。
黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件，采用黑盒技术设计测试用例的方法有等价类划分、边界值分析、错误推测、因果图和综合策略。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/162468.html