|
|
知识路径： > 软件评测知识 > 软件测试类型 > 按工程阶段分类 > 软件生命周期测试策略 > 软件测试策略 >
|
被考次数：3次
被考频率：中频率
总体答错率：44%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
相关知识点：13个
|
|
|
|
|
分析设计阶段的测试工作是评审与测试相结合的过程，主要包括需求说明书评测、概要设计说明书评测、详细设计说明书评测以及软件编码规范评测等。下述章节将详细论述。
|
|
|
|
|
|
由于软件应用系统针对的行业广泛，因此在需求分析阶段可能存在着承建单位对业主单位的业务需求理解不全面、不准确的情况，常发生承建单位认为某一个业务功能的实现非常简单，而实际上业主单位业务标准的要求却很复杂的情况。在这种情况下，如果不通过评测进行相关的质量控制，往往造成承建单位按照自己的理解进行开发。如果不进行评测，或者评测之后没有充分发现问题，则给系统造成重大隐患，或者造成返工与延期。
|
|
|
|
因此，在此阶段评测的工作重点是与承建单位的分析人员、设计人员一起对需求说明书进行审查，并协调业主单位完成需求说明书的评审确认。
|
|
|
|
什么样的需求说明书是良好的，需求说明书编写应该遵照怎样的框架，针对需求说明书的评测有哪些主要内容等，这些在下述章节将详细论述。
|
|
|
|
|
|
1979年由Balzer和Goldman提出了作出良好规格说明的8条原则。
|
|
|
|
原则1：功能与实现分离，即描述要“做什么”而不是“怎样实现”。
|
|
|
|
原则2：要求使用面向处理的规格说明语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规格说明。
|
|
|
|
原则3：如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。描述该目标软件与系统的其他系统元素交互的方式。
|
|
|
|
|
|
原则5：系统规格说明必须是一个认识的模型，而不是设计或实现的模型。
|
|
|
|
原则6：规格说明必须是可操作的。规格说明必须是充分完全和形式的，以便能够利用它决定对于任意给定的测试用例，已提出的实现方案是否都能满足规格说明。
|
|
|
|
|
|
原则8：规格说明必须局部化和松散的耦合。它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落（理想情况）。同时，规格说明应被松散地构造（即耦合），以便能够很容易地加入和删去一些段落。
|
|
|
|
尽管Balzer和Goldman提出的这8条原则主要用于基于形式化规格说明语言之上的需求定义的完备性，但这些原则对于其他各种形式的规格说明都适用。当然要结合实际来应用上述的原则。
|
|
|
|
|
|
需求说明书是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。如下表中列出了需求说明书的框架。
|
|
|
|
|
|
|
|
|
|
需求说明书评测作为需求分析阶段工作的复查手段，应该对功能的正确性、完整性和清晰性，以及其他需求给予评测。评测的主要内容是：
|
|
|
|
|
|
|
|
③文档中的所有描述是否完整、清晰，准确地反映用户要求；
|
|
|
|
|
|
|
|
|
|
⑦主要功能是否已包括在规定的软件范围之内，是否都已充分说明；
|
|
|
|
⑧软件的行为和它必须处理的信息、必须完成的功能是否一致；
|
|
|
|
|
|
|
|
|
|
|
|
?是否详细制定了检验标准，它们能否对系统定义是否成功进行确认；
|
|
|
|
|
|
|
|
|
|
为保证软件需求定义的质量，评测应由专门指定的人员负责，并按规程严格进行。评审结束，应有评审负责人的结论意见及签字。除承建单位分析员之外，业主单位人员和测试单位都应当参加评测工作。需求说明书要经过严格评测，一般，评测的结果都包括了一些修改意见，待修改完成后再经评测，才可进入设计阶段。根据上述讨论的评测内容，可以制定需求说明书评测规范，如下表所示。
|
|
|
|
填表说明：Y—是，TBD—不确定，N—否，NA—不适用。
|
|
|
|
|
|
|
|
|
|
在需求说明书评测结束后，测试单位应将评测意见以专题报告的形式提交业主单位。
|
|
|
|
|
|
. 设计说明书的框架。如下表所示为软件设计规格说明的大纲。
|
|
|
|
|
|
|
|
软件设计的最终目标是要取得最佳方案。“最佳”是指在所有候选方案中，就节省开发费用，降低资源消耗，缩短开发时间的条件，选择能够赢得较高的生产率、较高的可靠性和可维护性的方案。在整个设计的过程中，各个时期的设计结果需要经过一系列设计质量的评测，以便及时发现和解决在软件设计中出现的问题，防止把问题遗留到开发的后期阶段，造成后患。
|
|
|
|
|
|
①可追溯性：即分析该软件的系统结构、子系统结构，确认该软件设计是否覆盖了所有已确定的软件需求，软件每一成份是否可追溯到某一项需求。
|
|
|
|
②接口：即分析软件各部分之间的联系，确认该软件的内部接口与外部接口是否已经明确定义。模块是否满足高内聚和低耦合的要求。模块作用范围是否在其控制范围之内。
|
|
|
|
③风险：即确认该软件设计在现有技术条件下和预算范围内是否能按时实现。
|
|
|
|
④实用性：即确认该软件设计对于需求的解决方案是否实用。
|
|
|
|
⑤技术清晰度：即确认该软件设计是否以一种易于翻译成代码的形式表达。
|
|
|
|
⑥可维护性：从软件维护的角度出发，确认该软件设计是否考虑了方便未来的维护。
|
|
|
|
⑦质量：即确认该软件设计是否表现出良好的质量特征。
|
|
|
|
⑧各种选择方案：看是否考虑过其他方案，比较各种选择方案的标准是什么。
|
|
|
|
⑨限制：评估对该软件的限制是否现实，是否与需求一致。
|
|
|
|
⑩其他具体问题：对于文档、可测试性、设计过程等进行评估。
|
|
|
|
在这里需要特别注意：软件系统的一些外部特性的设计，例如软件的功能、一部分性能以及用户的使用特性等，在软件需求分析阶段就已经开始。这些问题的解决，多少带有一些“怎么做”的性质，因此有人称之为软件的外部设计。
|
|
|
|
为评测设计是否达到目标，必须建立衡量设计的技术标准。如下：
|
|
|
|
①设计出来的结构应是分层结构，从而建立软件成分之间的控制。
|
|
|
|
②设计应当模块化，从逻辑上将软件划分为完成特定功能或子功能的构件。
|
|
|
|
|
|
|
|
⑤设计应当建立能够降低模块与外部环境之间复杂连接的接口。
|
|
|
|
⑥设计应能根据软件需求分析获取的信息，建立可驱动、可重复的方法。
|
|
|
|
根据上述讨论的评测内容以及评测标准，可以建立概要设计说明书评测规范，如下表所示。
|
|
|
|
填表说明：Y—是，TBD—不确定，N—否，NA—不适用。
|
|
|
|
|
|
|
|
|
|
|
|
详细设计说明书的评测标准和评测内容与概要设计说明书基本相同，这里不再赘述。如下表所示为详细设计说明书评测规范。
|
|
|
|
填表说明：Y—是，TBD—不确定，N—否，NA—不适用。
|
|
|
|
|
|
|
|
|
|
|
|
程序实际上也是一种供人阅读的文章，有一个文章的风格问题。程序良好的风格表现在源程序文档化、数据说明的方法、语句结构和输入/输出方法这四个方面，软件编码规范评测也是围绕这四个方面展开。下面分别论述评测内容以及相应的评测标准。
|
|
|
|
|
|
①符号名的命名。符号名即标识符，包括模块名、变量名、常量名、标号名、子程序名、数据区名以及缓冲区名等。这些名字应能反映它所代表的实际东西，应有一定实际意义。例如，表示次数的量用Times，表示总量的用Total，表示平均值的用Average，表示和的量用Sum等。
|
|
|
|
名字不是越长越好，应当选择精炼的、意义明确的名字。必要时可使用缩写名字，但这时要注意缩写规则要一致，并且要给每一个名字加注释。同时，在一个程序中，一个变量只应用于一种用途。
|
|
|
|
②程序的注释。夹在程序中的注释是程序员日后与程序读者之间通信的重要手段。注释绝不是可有可无的。一些正规的程序文本中，注释行的数量占到整个源程序的1/3~1/2，甚至更多。注释分为序言性注释和功能性注释。
|
|
|
|
序言性注释通常置于每个程序模块的开头部分，它应当给出程序的整体说明，对于理解程序本身具有引导作用。有些软件开发部门对序言性注释做了明确而严格的规定，要求程序编制者逐项列出。有关项目包括：程序标题；有关本模块功能和目的的说明；主要算法；接口说明：包括调用形式，参数描述，子程序清单；有关数据描述：重要的变量及其用途，约束或限制条件，以及其他有关信息；模块位置：在哪一个源文件中，或隶属于哪一个软件包；开发简历：模块设计者，复审者，复审日期，修改日期及有关说明等。
|
|
|
|
功能性注释嵌在源程序体中，用以描述其后的语句或程序段是在做什么工作，或是执行了下面的语句会怎么样。而不要解释下面怎么做。要点：描述一段程序，而不是每一个语句；用缩进和空行，使程序与注释容易区别；注释要正确。
|
|
|
|
③标准的书写格式。视觉组织用空格、空行和移行来实现。恰当地利用空格，可以突出运算的优先性，减少编码的错误；自然的程序段之间可用空行隔开；移行也叫做向右缩格。它是指程序中的各行不必都在左端对齐，都从第一格起排列，这样做使程序完全分不清层次关系。对于选择语句和循环语句，把其中的程序段语句向右作阶梯式移行。使程序的逻辑结构更加清晰。
|
|
|
|
|
|
在设计阶段已经确定了数据结构的组织及其复杂性。在编写程序时，则需要注意数据说明的风格。为了使程序中数据说明更易于理解和维护，必须注意以下几点。
|
|
|
|
①数据说明的次序应当规范化。数据说明次序规范化，使数据属性容易查找，也有利于测试，排错和维护。原则上，数据说明的次序与语法无关，其次序是任意的。但出于阅读、理解和维护的需要，最好使其规范化，使说明的先后次序固定。
|
|
|
|
②说明语句中变量安排有序化。当多个变量名在一个说明语句中说明时，应当对这些变量按字母的顺序排列。带标号的全程数据也应当按字母的顺序排列。
|
|
|
|
③使用注释说明复杂数据结构。如果设计了一个复杂的数据结构，应当使用注释来说明在程序实现时这个数据结构的固有特点。
|
|
|
|
|
|
在设计阶段确定了软件的逻辑流结构，但构造单个语句则是编码阶段的任务。语句构造力求简单、直接，不能为了片面追求效率而使语句复杂化。
|
|
|
|
比如：在一行内只写一条语句；程序编写首先应当考虑清晰性；程序要能直截了当地说明程序员的用意；除非对效率有特殊的要求，程序编写要做到清晰第一，效率第二，不要为了追求效率而丧失了清晰性；首先要保证程序正确，然后才要求提高速度，反过来说，在使程序高速运行时，首先要保证它是正确的；避免使用临时变量而使可读性下降；对编译程序做简单的优化；尽可能使用库函数；避免不必要的转移；尽量采用基本的控制结构来编写程序；避免采用过于复杂的条件测试；尽量减少使用“否定”条件的条件语句；尽可能用通俗易懂的伪码来描述程序的流程，然后再翻译成必须使用的语言；数据结构要有利于程序的简化；程序要模块化，使模块功能尽可能单一化，模块间的耦合能够清晰可见；利用信息隐蔽，确保每一个模块的独立性；从数据出发去构造程序；不要修补不好的程序，要重新编写。
|
|
|
|
|
|
输入和输出信息是与用户的使用直接相关的。输入和输出的方式和格式应当尽可能方便用户的使用。一定要避免因设计不当给用户带来的麻烦。因此，在软件需求分析阶段和设计阶段，就应基本确定输入和输出的风格。系统能否被用户接受，有时就取决于输入和输出的风格。输入/输出风格还受到许多其他因素的影响。如输入/输出设备（终端的类型，图形设备，数字化转换设备等）、用户的熟练程度以及通信环境等。不论是批处理的输入/输出方式，还是交互式的输入/输出方式，在设计和程序编码时都应考虑下列原则。
|
|
|
|
①对所有的输入数据都要进行检验，识别错误的输入，以保证每个数据的有效性；
|
|
|
|
②检查输入项的各种重要组合的合理性，必要时报告输入状态信息；
|
|
|
|
③使输入的步骤和操作尽可能简单，并保持简单的输入格式；
|
|
|
|
|
|
|
|
⑥输入一批数据时，最好使用输入结束标志，而不要由用户指定输入数据数目；
|
|
|
|
⑦在交互式输入时，要在屏幕上使用提示符，明确提示交互输入的请求，指明可使用选择项的种类和取值范围。同时，在数据输入的过程中和输入结束时，也要在屏幕上给出状态信息；
|
|
|
|
⑧当程序设计语言对输入/输出格式有严格要求时，应保持输入格式与输入语句要求的一致性；
|
|
|
|
|
