7、测试步骤描述要简单、清晰,并且要清楚每一个步骤的描述,我们平常的鼠标和键盘的每一动作都代表一个操作步骤 。比如:第一步,输入用户姓名;第二步,输入登录密码;第三步,用户点击登录 。步骤写的明确时就利于提高用例的可操作性 。
8、用例的预期结果要完整而且清晰,并且要将各个输出的结果写出来,包括:返回值的内容、数据库相关字段的记录、界面的响应结果、输出结果的规则符合度、日志的检查和对其它业务影响的检查 。
9、测试用例级别要划分清楚,这样在测试执行时有主次之分 。
11、评审用例很关键,因为经过测试用例的评审可以发现:用例设计的结构安排是否清晰、合理;是否覆盖所有的需求功能点;是否存在冗余的用例;是否具有很好的可执行性;是否存在对需求理解上的差异等 。评审需要项目经理、需求分析人员、架构设计人员、开发人员和测试人员都参与,也需要客户方的开发人员和测试人员 。
12、召开测试用例评审会议,在会议上大家可以提问互答,对模糊不清的地方可以进行讨论 。这样可以站在不同的角度,站在很多人的思维和思考方式下设计用例 。
13、站在用户的角度来设计用例,以用户的使用逻辑及操作习惯为出发点,从用户实际可能的操作场景考虑,一定要脱离系统提供功能 。
14、测试用例需要不断更新和维护,不要认为测试用例的设计是一个阶段,测试用例的设计也需要迭代,在软件开发的不同的阶段都要回来重新审视和完善测试用例 。并且需要在测试执行时利用发散思维不断的构造和完善测试用例 。
总的来说,写出好的测试用例需要我们不断的积累和完善,需要我们不断的在工作中去总结 。写出好的测试用例没有简单的公式或规定可以遵循 。即使是多年以来在测试方面感兴趣的人也很难做到这一点 。
6.如何做好测试需求分析个人总结测试需求主要通过以下途径来收集:1) 与待测软件相关的各种文档资料 。
如软件需求规格、Use case、界面设计、项目会议或与客户沟通时有关于需求信息的会议记录、其他技术文档等 。2) 与客户或系统分析员的沟通 。
3) 业务背景资料 。如待测软件业务领域的知识等 。
4) 正式与非正式的培训 。5) 其他 。
如果以旧系统为原型,以全新的架构方式来设计或完善软件,那么旧系统的原有功能跟特性就成为了最有效的测试需求收集途径 。在整个信息收集过程中,务必确保软件的功能与特性被正确理解 。
因此,测试需求分析人员必须具备优秀的沟通能力与表达能力 。
文章插图
- 道德品质的典型事例怎么写
- 转正心得报告怎么写
- 厨房案例怎么写
- 自制川贝枇杷膏的做法和比例 自制川贝枇杷膏的做法
- 物业电工试用期转正怎么写
- 骨密度如何检测 骨密度如何看骨龄
- 大学生住院费用医保报销比例 住院大学生医保能报销多少
- 将就的拼音怎么写
- c测试程序怎么写
- 急性阑尾炎病例怎么写