产品用例怎么写( 二 )


3、尽量多参加项目组内的会议 。比如需求讨论、设计讨论、计划讨论等会议,这样在讨论过程中也能加深对产品的理解 。
4、要善于沟通,多和客户、开发、测试人员进行沟通 。遇到不明确的问题、有疑问的需求,可以咨询项目负责人或者客户等 。这样才能提前解决需求理解偏差等 。
5、测试用例名称,也叫测试用例标题,一定要写得简洁、明了,需要用概括的语言描述该用例的出发点和关注点,使得测试人员第一眼看到测试用例名称就能够明白测试用例的目的 。用例名称中一般要求不能存在假设性的语句,并且原则上每个用例的名称不能重复 。
6、预置条件要明确,包括测试环境、测试数据、测试场景 。因为许多BUG只有在特定的环境、特定的场景下才可以重现 。没有正确的前提条件,就无法进行后面的测试步骤或无法得到预期的结果 。
7、测试步骤描述要简单、清晰,并且要清楚每一个步骤的描述,我们平常的鼠标和键盘的每一动作都代表一个操作步骤 。比如:第一步,输入用户姓名;第二步,输入登录密码;第三步,用户点击登录 。步骤写的明确时就利于提高用例的可操作性 。
8、用例的预期结果要完整而且清晰,并且要将各个输出的结果写出来,包括:返回值的内容、数据库相关字段的记录、界面的响应结果、输出结果的规则符合度、日志的检查和对其它业务影响的检查 。
9、测试用例级别要划分清楚,这样在测试执行时有主次之分 。
11、评审用例很关键,因为经过测试用例的评审可以发现:用例设计的结构安排是否清晰、合理;是否覆盖所有的需求功能点;是否存在冗余的用例;是否具有很好的可执行性;是否存在对需求理解上的差异等 。评审需要项目经理、需求分析人员、架构设计人员、开发人员和测试人员都参与,也需要客户方的开发人员和测试人员 。
12、召开测试用例评审会议,在会议上大家可以提问互答,对模糊不清的地方可以进行讨论 。这样可以站在不同的角度,站在很多人的思维和思考方式下设计用例 。
13、站在用户的角度来设计用例,以用户的使用逻辑及操作习惯为出发点,从用户实际可能的操作场景考虑,一定要脱离系统提供功能 。
14、测试用例需要不断更新和维护,不要认为测试用例的设计是一个阶段,测试用例的设计也需要迭代,在软件开发的不同的阶段都要回来重新审视和完善测试用例 。并且需要在测试执行时利用发散思维不断的构造和完善测试用例 。
总的来说,写出好的测试用例需要我们不断的积累和完善,需要我们不断的在工作中去总结 。写出好的测试用例没有简单的公式或规定可以遵循 。即使是多年以来在测试方面感兴趣的人也很难做到这一点 。
3.怎么写测试用例核心业务:测试函数int ReadFile(char *pszFileName)
● 测试标题
规则:重要程度介于高和低之间的测试用例,是后续步骤的先决条件
● 输入
规则:测试用例的概括简单的描述用例的出发点 。
● 重要级别
规则
高、界面的响应结果:软件需求项 如 。
● 预置条件
规则,由数字和字符组合成的字符串
◇ 约定:保证系统基本功能、重要特性,可以拨打紧急电话
集成测试用例测试项目、关注点,包括返回值的内容:当前测试用例所属测试大类:实际使用频率不高:集成后的模块名或接口名 如:执行当前测试用例需要的前提条件:用例执行过程中需要加工的外部信息:被测试的函数名 如、文件、被测需求、易识别性:产品编号-UT-单元测试项名-单元测试子项名-XXX