某软件的一个模块的需求规格说明书中描述

高分求助一道软件测试题关于黑盒测试的

1. 黑盒测试： 1）等价类划分法设计测试用例输入条件有效等价类边界值无效等价类边界值商品货架R 0整数 100 R为整数范围R>100 101R为小数 1.5R为字符 aR为特殊字符 @顾客付款P 0整数 100 P为整数范围R>100 101P为小数 1.5P为字符 aP为特殊字符 @零钱组合 50,5,1的组合 1,1,1 除了50,5,1其它正整数的组合 51,6,05,5,5 组合中有负数 -1,1,550,5,1 组合中有小数 1.5,1,11,5,5 组合中有字符 A,a,z1,1,5 组合中有特殊字符 @，%，&注意：要设计测试用例还必须考虑要输入是R和P组合，输出是零钱的组合。

但是使用等价类分析如上表，但愿能给你解答的思路2）这道题不太能整理一个的思路。

就不能帮到你了。

3）用因果图法设计以下程序的测试用例。

这到问题比较简单画了个图片给你4）决策表，化简（合并规则）后的决策表（1为真，0为假，-表示任意）。

条件桩功率大于50马力 0 - - 1维修记录不全 0 - 1 -已经运行10年 0 1 - -结果维修 0 1 1 12. 白盒测试，4组测试用例可以达到要求X 17 9 8 0Y 11 6 5 0路径覆盖 bfg beg adg acg条件覆盖 T1,T2,T3,T4 T1,T2,F3,F4 F1,F2,T5,T6 F1,F2,F5,F6语句覆盖、判定覆盖判定/条件覆盖也是100%。

建议：如果想要更全面，可以再考虑条件组合覆盖率，还要多加4个测试用例

软件需求规格说明书

给你推荐一款档案管理软件，广东绍林科技开发有限公司的3Hmis 460档案管理软件。

一：20年专业档案管理经验。

国家档案局测评最高级‘良好’级软件。

二：档案文件按密级按职能权限管理，安全性极高。

三：配套‘傻瓜式’用户手册，看完就可以马上建立自己的专业且符合国家标准的档案管理系统。

对档案管理人员自身技能提高亦有很好的帮助。

四：完善售后售前服务，轻松应对所有问题，没有任务经验的朋友也可以在短时间内掌握软件。

上网一搜“绍林科技”就查到了。

如何从软件开发的角度分析一个软件并将软件开发说明写出来？

首先，你需要明白为什么需要文档。

你要理解文档和代码一样重要，都是开发人员的劳动成果（artifact）。

其次，你要确定你采用的周期模型和开发方法。

不同的模型或方法会有不同的文档需求，这需要你自己裁剪直到适合你的开发团队，别忘了，文档也是为了提高开发效率、质量用的，让开发人员过多的写一些无味的文档，反而会降低效率。

再次，你要作出一些文档模板，模板中对文档的用途和结构做出明确的说明。

最后，就可以填充啦。

附一个RUP的需求描述文档模板 1.0 简介 [介绍本文档的整体结构。

] 1.1 目的 [说明本软件需求规格说明书的目的。

软件需求规格说明书不仅需要完整的描述系统的行为，还需要说明非功能性的需求、设计约束以及其它相关的因素。

] 1.2 范围 [简要介绍本需求规格文档适用的项目/应用程序及其主要特性或其它子系统、相关的用例模型和受其影响的其它任何事物。

] 1.3 定义、术语和缩写 [详细定义正确地理解本文档的相关术语，包括定义、首字母缩写词和缩略语。

可以通过引用术语表说明。

] 1.4 参考资料 [说明本文档引用的任何其它相关文档。

要列出文档的标题、文档编号、日期、和出版单位并说明文档的来源。

] 1.5 概要 [说明本文档余下部分包含的内容及组织方式。

] 2.0 说明 [本节列出影响产品和需求的一般因素，但不需列出具体的需求，只需描述将在第3节中详细描述的需求的背景，以便于理解需求。

这包括：产品总体效果，产品功能，用户特征，约束、假设和依赖，以及需求子集等。

特别关键的是除了需要说明产品是或说解决什么，还要说明产品不是或不是解决什么。

] 2.1 用例模型 [如果使用了用例模型，本小节概述适用于本系统的用例模型或子模型，包括所有用例和角色的名称和简要说明及用例图和关系。

可将用例报告作为附件在此引用。

] 2.2 假设与依赖 [说明所有重要的技术可行性、子系统或组件的可用性或可作为此说明书所描述的软件的基础的其它相关假设。

] 3.0 需求描述 [详细描述软件的需求。

其详细程度能够使设计人员设计出满足这些需求的系统；测试人员能够测试此系统是否真的满足这些需求。

在使用用例建模时，这些需求采用用例和可用的其它补充文档捕获。

] 3.1 用例报告 [用例模型通常定义了系统的主要功能性需求和一些非功能性需求。

对用例模型中的每个用例都需要在此引用或附上用例报告。

保证清晰的标明每个需求。

] 3.2 补充说明 [描述没有包含在用例中的其它需求。

此处应包含补充需求说明中适用于此系统的具体需求说明或特征，并重新提炼以足够详细地说明此系统。

这些信息可直接记录在此文档中，也可以作为附件引用到单独的补充说明文档。

同样要保证需求被清晰的定义。

] 4.0 辅助信息 [辅助信息使此文档更容易使用。

这可以是目录、索引、附录、用例示意图、用户界面原型等。

如果包含附录，要明确说明此附录是否是需求的一部分。

]

用户需求说明书文档模板怎么编写？

用户需求说明书模板文档标识：当前版本：1.0当前状态：草稿发布日期：2015-5-20发布：修改历史日期版本作者修改内容评审号变更控制号目录1引言... 31.1 编写目的... 31.2 项目背景... 31.3 术语定义... 31.4 参考资料... 32 综合描述... 32.1产品介绍... 32.2 目标范围... 32.3 用户特性...42.4 约定假设... 43 用户需求（可剪裁）... 43.1 总体需求（可剪裁）... 43.2 内容需求（可剪裁）...54 功能需求... 54.1 数据需求（可剪裁）...54.2 接口需求（可剪裁）... 64.3 权限控制需求（可剪裁）... 64.3.1 系统安全要求（软硬件）... 64.3.2 用户角色... 64.3.3 角色权限控制... 65 非功能需求... 65.1 用户界面需求（可剪裁）... 65.2 性能需求（可剪裁）... 75.3 压力需求（可剪裁）... 75.4 主流技术应...参考链接 http://wenku.baidu.com/link?url=sWqyWqKYVsb_h5AwACh8Lr0U39s6_7EV63vsvlWpai_0t-uZoXwqlidc72WMN5K7hz8HcJ_RNqUMIVXkxQMsj-IWjUwMdOO-g2qGqa_kERC

软件测试具体是做什么的？（面试人员说刚开始做的是处理一些代码非...

软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试工具，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。

执行测试用例后，需要跟踪故障，以确保开发的产品适合需求。

使用人工或者自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别. 它是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度（correctness）、完全度（completeness）和质量（quality）的软件过程；是SQA(software quality assurance)的重要子域。

Grenford J.Myers曾对软件测试的目的提出过以下观点：（1）测试是为了发现程序中的错误而执行程序的过程；（2）好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；（3）成功的测试是发现了至今为止尚未发现的错误的测试。

然而，这种观点指出测试是以查找错误为中心，而不是为了演示软件的正确功能.但是只从字面意思理解，可能会产生误导，认为发现错误是软件测试的唯一目的，查找不出错误的测试就是没有价值的测试，实际上并非如此！(1)测试并不仅仅是为了找出错误.通过分析错误产生的原因和错误的发生趋势，可以帮助项目管理者发现当前软件开发过程中的缺陷，以便及时改进；(2)这种分析也能帮助测试人员设计出有针对性的测试方法，改善测试的效率和有效性；(3)没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法软件测试完整分类，参见：软件测试的完整分类以上的都是官话！其实说白了，软件测试就是在开发人员做出软件投放市场前，尽可能早的找出软件当中所存在的BUG！因为任何软件在理论上来说都是存在问题的，都不是完美的！尽早的找出漏洞，公司的损失也就越低！这也就是软件测试人员越来越受重视的原因！其实软件测试是一种相当乏味枯燥的工作，一般面公司都比较偏向稍微内向的人，另外测试人员还要具备相当的口才，方便与开发人员还有客户交流！

新系统开发前进行什么分析填空题

需求分析奠定了软件工程和项目管理的基础。

我们在建造软件系统这座大厦的时候，如果需求分析的基础不够坚实和牢固，那么往往会导致软件系统问题百出，甚至被马上丢弃。

在建造软件系统的过程中，如果我们经常习惯地沿用一些不规范的方法，其后果便是产生一条鸿沟──开发者开发的与用户所想得到的软件存在着巨大的“期望差异”。

因此“需求”这个名词的定义不仅仅是从用户角度对系统外部行为的描述，以及从开发人员角度对系统内部特性的描述，其关键的一点是“需求”必须文档化。

需求的类型软件需求包括三个不同的层次──业务需求、用户需求和功能需求。

除此之外，每个系统还有各种非功能需求。

业务需求（BusinessRequirement）表示组织或客户高层次的目标。

业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。

业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。

使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。

用户需求（UserRequirement）描述的是用户的目标，或用户要求系统必须能完成的任务。

用例、场景描述和事件响应表都是表达用户需求的有效途径。

也就是说用户需求描述了用户能使用系统来做些什么。

功能需求（Functional Requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。

功能需求有时也被称作行为需求（behavioral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。

功能需求描述是开发人员需要实现什么。

非功能需求（Non-functional Requirement）定义了软件产品为满足用户业务需求而必须具有的除功能需求以外的特性。

包括系统的完整性（联机帮助、数据管理、用户管理、软件发布管理、在线升级等）、性能、可靠性、可维护性、可扩充性、对技术和业务的适应性等。

需求分析的任务 1 解决的问题 1）齐全、准确地找出目标系统全部的功能、性能、限制； 2）找出全部的输入流、输出流； 3）找出所有的加工； 4）产生完整的分层的DFD、数据字典、加工的描述； 5）补充的意见。

2 综合要求确定对系统的综合要求，系统功能要求，系统性能要求，运行要求，将来可能提出的要求。

3 任务图1为需求分析任务图，需求分析阶段要完成的具体明确的最终任务就是形成一份经开发方和用户认可或达成共识的软件需求分析文档（需求规格说明书、修改后的项目开发计划、初步的用户手册、确认测试计划、数据要求说明书）。

这个文档能清晰准确地说明系统将要开发什么，能够规定出详细的技术需求，包括所有面向用户、面向机器和其它软件系统的接口。

可以说需求文档在开发过程中一直起指导作用。

为了更好地完成软件开发第一阶段的需求分析任务，提高质量，需求管理是必不可少的。

需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更，主要体现在跟踪和控制需求变更管理。

需求管理是开发工作有效进行的保证，是一种很高层次的系统行为，涉及整个开发过程和产品本身。

需求分析的方法需求分析方法由对软件问题的信息域和功能域的系统分析过程及其表示方法组成，大多数的需求分析方法是由信息驱动的。

信息域具有三种属性：信息流、信息内容和信息结构。

常用的需求分析方法有：面向数据流的结构化分析方法（SA），面向数据结构的Jackson方法（JSD），面向数据结构的结构化数据系统开发方法（DSSD），面向对象的分析方法（OOA）等。

选择那种方法要根据哪些资源在什么时间对开发人员有效，不能盲目套用。

这里着重阐述面向数据流的结构化分析方法（SA）。

面向数据流的结构化分析方法面向数据流的结构化分析方法（Structured Analysis，简称SA），是面向数据流进行需求分析的方法，是需求分析使用最多的方法之一。

SA也是一种建模活动，该方法使用简单易读符号，根据软件内部数据传递、变换的关系，自顶向下逐层分解，描绘出满足功能要求的软件模型。

适用于数据处理类型软件的需求分析，这一方法除了简单，容易掌握之外，还能和设计阶段的结构化设计（SD）衔接，从而取得良好的设计结果。

自顶向下逐层分解的分析策略 SA方法的基本手段：“分解”和“抽象”。

这是系统开发技术中控制复杂性的两种手段。

它先将系统“抽象”成一个模型，此模型是有输入和输出并有系统名称的盒子，然后打开这个盒子，对它进行逐层分解，直到能被理解，可以实现为止。

因此分析的策略是自顶向下，逐层加细，由抽象到具体的过程。

如图2。

结构化分析方法使用工具 SA方法利用图形等半形式化的描述方式表达需求，简明易懂，用它们形成需求规格说明书中的主要部分。

描述工具是 1）数据流图：描述系统由哪几部分组成，各部分之间有什么联系等等。

2）数据字典：定义了数据流图中每一个图形元素。

3）描述加工逻辑的结构化语...

开发软件的给介绍个开发软件的给介绍一个

展开全部首先，你需要明白为什么需要文档。