4.需求文档理解、提出有效测试
1.软件测试人员越早介入测试,越早发现问题,就能越早的修复问题,越早发现问题,修复的成本越低,越晚发现问题,修复的成本越高。
2.软件测试人员测试需求文档,有几个路径,其中的一个方法,就是需求评审。
需求评审通常是由产品人员组织的,由相关人员参加,相关人员指的是参与这个项目的人员;项目经理,开发管理人员,测试管理人员也会参与,以便对项目有所了解,更好的安排排期,及工作;如果此项目涉及到不同部门,有条件的情况下,可邀请不同部门的相关人员来讲解这个需求的背景。并不是所有的项目都必须要兴师动众地进行需求评审,有些很小的模块或者项目,可以由产品人员召集项目的参与者,如测试人员或者开发人员,如果发现有疑问的地方,也可以召集产品,开发,进行小范围的需求评审。
需求评审前的几点准备:
1、在需求评审会前,先看需求文档,有时,会有几个项目同时在进行测试,而没有时间看需求文档的现象,这个要测试管理者在项目排期时,考虑到这种情况,而预留一定的看文档的时间。
2、在读需求文档的时候,记录下对文档不同的异议,或者,不明白的地方。
3、了解该项目的需求背景。
4、了解该项目所涉及到的原理。
5、了解该项目所涉及的知识点。
需求评审会的几点注意事项:
1、产品人员要解读需求,以便相关人员,更好地理解需求。
2、需求评审会上,有争论的歧义点,要做好记录。
3、做好会议记录。
4、会后,将会议记录发送给相关人员。
5、及时的更新需求文档。
因为一些原因,需求文档,会有一些遗漏的点,比如,这个需求未召开需求评审;或者,由于,时间紧迫,未充分解读需求文档;或者,参加需求评审会的测试人员与实际执行测试的人员不同,且测试人员经验不同等情况。此时,在写测试用例时,或者,在测试时,也可以去发现需求文档不合理或者遗漏的点。
测试用例流程
1、[测试](javascript:;)前首先明确测试范围(特别是要明确哪些是不需要测试的);
2、详细分析需求和开发文档,了解这个产品功能的来源(可站在用户的角度考虑问题),为什么要做这样的功能(可扩展思维,考虑一些反向用例),希望最后的结果是什么(可明确输入结果是否正确),还有行业常识和计算机知识、约定俗成(属于隐藏的需求)这些都需要考虑清楚。
3、划分测试功能点
4、根据不同功能点分别考虑各种输入条件、对应的输出表现,还需考虑用户实际使用的情况(有效的进行测试)、与其他部分关联使用的情况、非正常情况(不合理、非法、越界以及极限输入数据)操作和环境设置(方便复现问题)等。
5、我一般通过功能图分析法,场景法来分析测试需求并转换成功能点;通过域分析方法【等价类、边界值】、因果图(输入条件的各种组合判定,相互制约情况)、判定表法来进行[测试用例](javascript:;)的转换,通过错误推测法进行补充;
要求主次分明,注意功能点间逻辑层次,不能走哪测试到哪,要有明确的目标(即时碰到不好复现的问题,也能通过分析推测出现问题点)。
6、最后抛开用例,发散思维,在出现问题多的地方进行探索性测试。(有时间的话多了解一下行业动态,包括熟悉竞争对手的软件,会对你考虑用户实际情况的思维有提高)
总体思路:先正常,后异常,这样可以确保正常情况下功能能够走通。