测试用例的设计步骤
前言
设计测试用例的时候,需要有清晰的测试思路,对要测试什么,按照什么顺序测试,覆盖哪些需求做到心中有数。测试用例编写者不仅要掌握软件测试的技术和流程,而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。
以下是本篇文章正文内容,如有表达不全的问题还请指出,本文中插入的图片由网上下载,如涉及版权问题联系我删除。
一、测试需求分析
- 看需求文档,整理测试需求;
- 归纳、分类或细分测试需求;
- 测试用例设计,一个或多个测试用例集对应一个测试需求。
二、业务流程分析
- 在做复杂的测试用例设计前,先画出软件的业务流程;
- 分析主流程
- 分析条件备选流程
- 分析数据流向
- 分析关键的判断条件
三、测试用例设计
黑盒测试用例设计
黑盒测试的测试用例设计方法有:等价类划分、边界值划分、因果图分析和错误猜测,白盒测试的测试用例设计方法有:语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖。
功能测试:测试某个功能是否满足需求的定义,功能是否正确,完备。
适合的技术:由业务需求和设计说明导出的功能测试、等价类划分
边界测试:对某个功能的边界情况进行测试。
适合的技术:边界值划分
异常测试:对某些功能来说,其边界情况无法简单的了解或某些操作不完全是正确的但又是可能发生的,类似这样的情况需要书写相关的异常测试。
适合的技术:由业务需求和设计说明导出的特殊业务流程、错误猜测法、边界值分析、内部边界值测试。
性能测试:检查系统是否满足在需求中所规定达到的性能,性能主要包括了解程序的内外部性能因素。内部性能因素包括测试环境的配置,系统资源使用状况;外部因素包括响应时间,吞吐量等。
适合的技术:业务需求和设计说明导出的测试
压力测试:压力测试又称强度测试,主要是检查系统运行环境在极限情况下软件运行的能力,比如说给一个相当大的负荷或网络流量给应用软件兼容测试:测试软件产品在不同的平台,不同的工具,相同工具的不同版本下功能的兼容性。
四、测试用例评审
测试用例设计完成后,为了确认测试过程和方法是否正确,是否有遗漏的测试点,需要进行测试用例的评审。
测试用例评审一般是由测试leader安排,参加的人员包括:测试用例设计者、测试leader、项目经理、开发工程师、其它相关开发测试工程师。测试用例评审完毕,测试工程师根据评审结果,对测试用例进行修改,并记录修改日志。
五、测试用例更新完善
测试用例编写完成之后需要不断完善,软件产品新增功能或更新需求后,测试用例必须配套修改更新;在测试过程中发现设计测试用例时考虑不周,需要对测试用例进行修改完善;在软件交付使用后客户反馈的软件缺陷,而缺陷又是因测试用例存在漏洞造成,也需要对测试用例进行完善。一般小的修改完善可在原测试用例文档上修改,但文档要有更改记录。软件的版本升级更新,测试用例一般也应随之编制升级更新版本。测试用例是“活”的,在软件的生命周期中不断更新与完善。
总结
以上就是今天要讲的内容,本文仅仅简单介绍了测试用例的设计步骤的一些基础内容,有描述错误的地方请指出,感谢观看。