测试用例的评审

从网上搜索测试用例的评审,也能搜出好多,我这里把自己能想到的或是借鉴于他人的都在这里进行总结和归纳。

  测试用例的设计很重要,无论你采用的是敏捷测试还是传统的开发模式,测试用例都应该要文档化,并且根据项目的schedule,把握好粒度。而QA lead要根据项目的实际情况,先定好模板,制定好测试用例的编写规范。测试用例设计出来,质量如何?这就需要对测试用例进行评审,这个过程非常重要,对测试人员的能力提高,测试效率的提高都有很好的作用。如果公司流程没有这个硬性要求,项目再忙,也要抽出一定时间,召集相关人员开个哪怕是非正式的评审会议,大家一起讨论用例并给出意见和建议,及时发现问题,并完善测试用例的设计。

  何时进行用例的评审,一般情况下是在用例的初步设计完成之后进行评审,如果需要或时间允许,在整个详细用例全部完成之后还会进行二次评审,三次评审等。

  大体分文三个级别的评审:

  a)部门评审,测试部门全体员工参与的评审。

  b)公司评审,这里包括了项目经理,需求分析人员,架构设计人员,开发人员和测试人员。

  c)客户评审,包括了客户方的开发人员和测试人员。

  测试用例的评审检查单(Checklist for Test cases):

  1)Has the correct template been used?(是否使用了正确的模板?)

  2)Have all the scenarios specified in the requirement –explicit, implicit, nonfunctional and  been converted into test conditions?(是否覆盖了需求规格说明,包括内在需求和外在和非功能需求?)

  3)Have the related areas that include possibly be affected by the implementation of the requirement been identified and included in the test cases?(case是否对需求变更的部分进行对应的调整和增加?)

  4)Have the following details been filled up correctly? Requirement references, test procedure, expected result, priority, author’s name, date created…(测试用例是否正确填写了测试对应的需求,测试步骤,预期结果,优先级,作者姓名,创建日期等..)

  5)Has the test date set, if required been generated appropriate? (测试用例是否包含测试数据,测试数据的生成是否正确?)

  6)Have the required negative scenario between identified in the test conditions? (是否包含了负面测试用例?)

  7)Have the testing techniques—equivalence partitioning, boundary value analysis be used? (是否使用了等价类划分和边界值分析的测试方法?)

  8)Have the steps been correctly given in appropriate sequence for each test scenario? (测试步骤是否被阐述清楚?)

  9)Have the expected result been identified correctly? (预期结果是否表达正确?)

   ● Expected results should respond to the user actions given in each step/action.(每个步骤都应给出相应的测试结果)

   ● Ensure that too many things are not included to be verified under one expected output.(给出一个预期结果的验证步骤不要太多)

   ● Ensure that separate cases are written for multiple verifications of the application’s behavior. (每条case最好验证一个问题)

   ● Vague statements like “Appropriate message/value/screen” etc. should not be part of expected result. Every detail should be clearly spelt out. (预期结果中不要使用模糊的语言)

摘至:http://www.51testing.com/html/60/n-228860.html

在很多的软件公司,软件测试用例设计完成后,都需要进行检查或者评审,一般评审的依据都有哪些那?以下可以作为软件测试用例检查的标准:

  1、操作步骤应与描述相一致

  2、操作步骤应仅包含与被测项相关的内容,即没有多余的或不相关的内容

  3、期望结果应是确定的、唯一的

  4、可重用(对被测项的当前版本和后续版本)

  5、可跟踪(与软件测试需求相对应)

  6、软件测试用例执行后是应将软件测试环境恢复到执行前的状态

  7、软件测试用例是应有正确的名称和编号

  8、软件测试用例应标注有执行优先级

  9、软件测试用例目的的描述应包含该用例用于测试什么内容

  10、应包含了所采用的测试方法的描述

  11、应包含相关的配置信息:环境、数据、前置测试用例、用户授权等

  12、操作步骤和期望结果应完整、一致、清晰

  13、应指明:系统返回的任何错误信息或屏幕快照需保存

  14、用词规范、准确、一致

  15、每个软件测试用例的操作步骤<=15

  16、自动化测试脚本必须带有注释

  17、自动化测试脚本的注释应包含:目的、输入、期望结果等

  18、场景测试用例的执行顺序应符合实际的业务流程

  19、场景测试用例应覆盖最复杂的业务流程

  20、对于由系统自动生成的输出项应注明生成规则

  21、对于查询和表格,应设计产生数据的用例

  22、软件测试用例应包含对中间和后台数据的检查

  23、场景测试用例中应包含每个业务流程环节的中止和回退相关的设计和组合

  24、如果存在不可测需求,应列出并进行说明

  25、软件测试用例应确保所有的软件测试需求被覆盖

 

 

### 测试用例评审的目的和意义 测试用例评审的核心目标是通过团队协作的方式,确保测试用例的质量、全面性和有效性。以下是测试用例评审的主要目的和意义: 1. **确保需求覆盖** 评审过程能够确认测试用例是否全面覆盖了所有的功能需求,避免遗漏关键的功能点或业务逻辑[^1]。这有助于在早期阶段发现未被考虑的需求,从而减少后期返工的可能性。 2. **提高测试质量** 通过评审,可以识别测试用例中的缺陷和不足,并对其进行改进。这种集体审查的过程能够显著提升测试用例的设计质量,确保其符合预期标准[^2]。 3. **发现潜在问题** 在评审过程中,团队成员可以从不同的角度审视测试用例,发现其中可能存在的错误、不一致或模糊之处。这有助于降低测试执行阶段的风险,确保测试结果的可靠性[^1]。 4. **促进知识共享** 评审不仅是对测试用例的技术审查,也是一个团队学习和交流的机会。通过分享经验和技术,团队成员可以共同提升测试能力和业务理解水平[^1]。 5. **优化测试策略** 评审可以帮助团队评估当前的测试方法和工具是否合适,并提出改进建议。这种优化能够提高测试效率,缩短测试周期[^1]。 6. **明确优先级安排** 评审过程中需要检查测试用例的优先级是否合理,确保高优先级的测试用例得到充分关注。这对于资源有限的情况下尤为重要,能够最大化测试工作的价值[^3]。 7. **增强可执行性** 评审还可以验证测试用例的可执行性,包括前提条件、执行步骤、输入数据和期望结果是否清晰、正确。同时,确保每个测试用例都有明确的验证方法,以减少歧义。 8. **减少冗余和增加复用性** 评审有助于识别并删除冗余的测试用例,同时鼓励设计简洁且具有高复用性的测试用例。这样不仅可以节省时间和资源,还能提高测试工作的效率。 9. **加强负面测试** 评审应特别关注负面测试用例的数量和质量,确保软件在异常情况下的健壮性。通常建议负面测试用例的数量为正面用的4倍,以充分验证软件的保护机制[^3]。 ```python # 示代码:一个简单的测试用例结构 class TestCase: def __init__(self, precondition, steps, input_data, expected_result): self.precondition = precondition self.steps = steps self.input_data = input_data self.expected_result = expected_result def execute(self): # 模拟测试用例执行逻辑 print(f"Executing test case with input: {self.input_data}") if self.input_data == self.expected_result: print("Test Passed") else: print("Test Failed") ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值