需求阶段的测试因素
1、 需求遵守方法论需求分析规程越规范、正式，测试过程越简单。需求过程通过一个预定义的方式来收集、分析事实、做出判定并记录需求，并将用于设计过程中。
测试内容：
1，是否标识出适当的组织政策、标准和规程；
2，是否根据需求方法记下需求；
3，系统操作期间是否会有新的标准、政策和规程生效；
4，需求阶段的人员是否与规程一致；
5，所有的标准、政策和规程进入系统是否会有效。等……
2、 定义的功能说明
用户的满意情况只能在达到系统目标之后才能确定。而达到这些目标也
只能在目标是可度量的时候才能进行度量。定性的目标（如：可靠的稳定性、性能良好等）不是可度量的目标，而定量的目标（如：在0.002秒进行过电压保护功能）是可度量的目标。
测试内容：
1，收集的应用程序所需的数据是否达到了所需的可靠性水平；
2，是否在指定时间段内收集了数据；
3，是否以书面的形式定义了用户的需求并确认；
4，需求的说明是否可度量；
5，项目的解决方案是否解决了需求；
6，是否将可度量的目标应用于系统分为手动和自动的；
3、 确定可用性规范
使用系统所必需的工作量和技术水平都应该在需求阶段确定。经验表明，
不会经常使用到那些难以使用的应用程序或功能，而经常会用到易于使用的功能系统。除非把易于使用的规范包含在技术规范中，否则默认情况下，该规范将由系统分析人员工编辑人员创建。
测试内容：
1，是否标识出用户的技能水平；
2，在设计用户功能时是否采纳了行业心理学家的建议；
3，是否在需求阶段与用户工作人员进行交谈以确定他们所关心的问题；
4，是否标识出用户责任是否提交给用户来评论。
4、 确定的维护规范
与发生最有可能更改区域一样，还应该具体确定预计的维护程度。随后，
规范将确定维护的方法（比如：用户引入的参数整定）以及时间跨度，在该时间跨度内需要安装某种维护修改；比如：电子商务系统中，价格的修改必须对在信息服务进行修改后的24小时内是可操作的。
测试内容：
1，是否定义了项目预期的寿命；
2，是否已经定义预期的修改频率；
3，是否定义了保持系统更新功能的重要性；
4，是否决定有谁来执行项目的维护；
5，是否标识出预计的最大修改范围；
6，是否标识出在开发过程中引入修改的方法；
7，为了维护而正确记录现场的实际情况是否包含了相应的条款。
5、 确定可移植性的需求
在不同类型的硬件上运行系统的能力、随后把系统移植到另一种硬件上
的能力，或是把系统软件从一个版本移到另一个版本中的能力都应该详细陈述出来，作为需求的一部分。应该把应用程序开发成一种可移植的程序，这种需要将显著成为影响到需求的实现。
测试内容：
1，在项目周期内是否发生硬件的重大变更；
2，在项目周期内是否发生软件的重大变更；
3，应用系统是否会在多个地点运行；
4，如果是在线应用程序，那么是否会使用不同的终端；
5，所建议的解决方案是否依赖于特定的硬件/软件；
6，应用程序是否会应用于其它国家；
7，是否把可移植性记录到文档中。
6、 定义系统接口
应该定义将作为来自其他计算机系统输入的信息以及传递到其他计算机
系统的输出。这种定义不仅包括传递信息的种类，还包括了接口的时间安排以及作为接口结果发生的预计的处理。其他可能需要处理的接口因素包括隐私、安全以及信息的保留。
测试内容：
1， 是否标识出从其它应用系统接收的数据；
2， 是否标识出将用于其它系统的数据；
3， 是否定义了接口数据的可靠性；
4， 是否定义了数据传送和接收时间；
5， 是否定义了接口的方法；
6， 是否把接口记录到文档；
7， 是否考虑接口系统对未来的需求。
7、 创建性能标准
应创建系统预计的效率、经济性和有效性。在创建了上述目标之后，用
户不满意程序几乎可以保证和可操作系统一起发生。需求阶段的最终产品应该是源自应用程序的成本/收益的计算。根据应用程序系统的开发的成本计算信息，设计出相关性能标准规程，在该规程基础上进行开发。
测试内容：
1， 是否有其它组织的不确定性能软件和硬件；
2， 是否定义了性能/成本的关系；
3， 应用程序的性能是否引起由于项目的实际成本发生重大变化；
8、 可操作规程
可操作的考虑必须在需求阶段详细指明。在用户驱动的嵌入式应用系统
中尤为重要。为运行系统，必须在终端上遵循该操作规程（换言之，该规程必须为让终端为处理事务做好准备）。
测试内容：
1， 是否标识出了事务的容量；
2， 是否确定了处理时间；
3， 是否确定处理频率；
4， 是否确定了在线储存文件；
5， 处理是否需要通信功能；
6， 是否需要光学扫描之类的特殊处理功能；
7， 是否期望计算机操作执行诸如数据输入之类的特殊任务；
8， 确定计算机操作是否得到了项目需求的建议。
9、 定义了系统的容错能力
应该定义了系统的控制的预计的可靠性。比如，需求阶段应确定如下的
控制需求：24小时电力测量保护控制装置必须处理的过载保护时过流时在整定范围内的容错能力，如果还没有确定这种容错能力，那么就没有设计和度量在过流段内的处理可靠性的基础。如果没有定义缺陷的预计水平，通常认为是零缺陷的。在处理过程中让一些缺陷发生而不是控制或度量缺陷的数量，这常常是更经济且对用户是有好处的。
测试内容：
1， 是否标识出重要容易出错的模块；
2， 是否标识出风险的正确性和完整性；
3， 是否确定出错时中止系统的方法；
4， 是否标识出重要功能所需的精确度；
5， 是否建立用于确保能及时输入所有事务的规程；
6， 是否指定了监控重要功能出错的规程；
7， 是否为不正确不完整的数据建立规程。
10、 明确的授权规程
授权需求具体制定了授权的方法，通过该方法将确保实际中是根据
管理测试开发过程的目的来处理事务的。
测试内容：
1， 是否标识出所有关键事务；
2， 是否确定对各关键事务进行授权的规则；
3， 授权规程是否与事务控制的资源价值相致，不要浪费资源去控制一些没有价值的事务；
4， 是否定义了各事务的授权人员；
5， 规范是否确定了由系统自动生成的事务；
6， 规范是否确定需要同时处理给事务授权的人员；
7， 是否确定了给计算机生成事务的授权规则；
8， 是否监控计算机生成事务合理性的规程。
11、 明确的文件完整性需求
必须指定用于确保软件系统文件完整性的方法。这通常包括包含在
文件中以及独立的自动化应用程序中的控制总数。这些控制必须确保细节记录与每个控制文件相对应。
测试内容：
1， 是否标识出项目的重要计算机文档；
2， 是否标识出每个人关键文件的数据成分；
3， 是否标识出关键控制字段；
4， 是否确定用于关键字段的内部文件的完整性方法；
5， 是否确定了一个多用户系统中有一个用户是负责数据的完整性；
6， 是否确定对关键字段独产控制的方法；
7， 是否来自文件的完整性控制所期望的可靠性程序的基础上确定了偏差。
12、 明确系统恢复重建需求
系统恢复重建涉及到处理精确度的证实和系统出问题之后的恢复
项目组管理人员必须明确是否应该执行恢复过程以及执行的时间。如果认为恢复是必需的，那么项目组必须指出执行恢复过程所处的时间跨度。根据每天中的某一刻或每一周的某一天，在恢复（复归）系统时必须保留的数据，以及影响其它功能的数据的种类和内容。
测试内容：
1， 是否建立恢复系统重建立规程；
2， 需求文档是否充分并且与标准一致；
3， 是否确定了从某个点已完整性点恢复重建处理的标准；
4， 是否陈述了跟踪处理事务直到恢复重建功能程序对它进行控制；
5， 是否为所有恢复重建阶段指明了恢复时保留的数据。
13、 明确系统失效时的影响
应该明确系统在失效或连续性失效产生的影响，如果系统失效只导
致最小的损失或没有损失，那么就不必要确保失效不发生，如果失效发生在至关重的地方，那么就得明确在至关重地方失效的影响。
测试内容：
1， 是否定义了应用系统失效时所引起的经济损失；
2， 失效带来的经济损失是否得到扩充从而可以显示不同时段的损失（比如：一小时、一天、一周、一月、一年）的损失；
3， 建议的失效处理程序是否可靠且可行；
4， 如果系统失效，是否有必要的恢复该系统的判定；
5， 万一系统失效不能操作，是否有其它处理程序；
6， 如果需要其它操作是否要指定出来；
7， 一旦系统失效，是否定义了通知用户的规程；
8， 是否指明了预期的系统连续正常工作的时间。
14、 明确系统权限
应该指定相应的安全需求以显示系统资源与人之间的关系。安全需
求应指明控制中将要用到的所有可用资源，然后指出谁可能访问这些资源并将用于什么操作目的。比如：可能授予查看测控保护装置记取数据权限，但不能进行整定修改权限。
测试内容：
1， 是否明确标出系统的所有资源；
2， 是否标识出系统资源的使用者；
3， 是否标识出系统权限的管理者；
4， 是否建立一个与授权访问资源的用户对用表；
5， 是否指重要资源的要重要性；
6， 是否建立一个用于监控的非法访问规程；
7， 是否建立了惩罚非法访问者的程序。 新人，慢慢看吧！ 好多啊，楼主辛苦了！:handshake 弱弱的说一句
不晓得在说什么
测试的对象是什么？
楼主有没有整理一下？还是直接从别的地方copy过来的？
表砸我……
页:
[1]
