认识达内从这里开始

随着互联网的不断发展，越来越多的软件开发程序员也都转型软件测试的领域，而本文我们就简单来了解一下，成为软件测试程序员需要掌握哪些测试知识。

需求评审的策略

(1)分层次评审

一般，可以分成如下的层次：

*目标性需求指整个系统需要达到的业务目标，是高层次的、基本的需求，是企业的高层管理人员所关注的。如果让具体的操作人员去评审目标性需求，容易导致“捡了芝麻，丢了西瓜”的现象。

*功能性需求指整个系统需要实现的功能和任务，是目标之下的二层需求，是企业的中层管理人员所关注的。

*操作性需求指完成每个任务具体的人机交互〔UI)需求，是企业的具体操作人员所关注的。

(2)分阶段评审

应该在需求形成的过程中进行分阶段的多次评审，而不是在需求终形成后才进行仅有的一次评审分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，这样就降低了需求分析返工的风险，提高了评审的质量。

这点对于敏捷开发模式特别有效。需求按版本为单位划分，根据版本进行需求评审(确定做啥，是不是那样做)，通过后开发针对该版本需求进行开发，测试根据需求进行用例编写和维护，然后按这种模式进行迭代。

注意事项

精心挑选评审人员->定制规范化评审流程->准备好评审材料->做好结果跟踪工作等

联系与区别

软件测试有很多方法，如等价类、边界值、语句覆盖、条件覆盖、路径覆盖、场景法等等。当你掌握和了解这些方法之后，怎么运用到实际项目中呢。就需要制定测试策略，在测试项目中什么时间、什么任务，什么目标，需要运用哪个或哪些方法或哪些工具、怎么组织起来去解决完成，这就是策略。

1、设计思想

a)测试点来源与定位

来源

测试点来源：一、显式需求二、隐式需求。一个需求点可以对应多个测试点

定位测试点

测试点其实也就是测试目的。用例定义了“怎么测”，而测试点则定义了“为何测”，所以，设计前必须明白测试点是什么，且一个用例仅对应一个测试点。

理由：便于统计，测试用例对整个测试过程的质量控制和评估有很重要的意义：

一、测试需求覆盖率分析。如果一个用例包含几个测试点，那么不利于需求覆盖分析

二、用例成功率分析。一个用例中有多个测试点，肯定会造成用例数量减少，用例失败率大大增多，那么你做的用例成功率还有什么意义?

三、缺陷分析。如果用例失败了，就生成一个缺陷。如果一个用例中写了多个测试点，回归的时候如果有指定回归用例，那用例中那些些与缺陷不相关的测试点也可能也被回归，增加工作量。

以下3点想法帮助你更好的定位测试点

1.站在用户使用角度来考虑，看你定位的“测试点”是否有实际意义

2.考虑你定位的“测试点”的完成能否标志着用户实际业务流程的一个阶段性结束?

3.考虑你定位的“测试点”的完成，是否可以为其他用户或业务提供输入数据，以供完成下面的工作?

综合2-3点：划清界线，点到即止

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。