石大远程在线考试－《软件工程课程设计》答案

李老师

{ 项目名称 }

{ 测试用例标题 }


文件状态：
[√] 草稿
[  ] 正式发布
[  ] 正在修改        文件标识：        CENTEN-Project-TEST-CASE
        当前版本：        X.Y
        作    者：       
        完成日期：        Year-Month-Day
        审 批 人：       


版 本 历 史

版本/状态        作者        参与者        起止日期        备注

                               

                               

                               





目 录
0. 文档介绍        5
0.1 文档目的        5
0.2 文档范围        5
0.3 读者对象        5
0.4 参考文献        5
0.5 术语与缩写解释        5
1. 接口－路径测试用例        6
1.1 被测试对象（单元）的介绍        6
1.2 测试范围与目的        6
1.3 测试环境与测试辅助工具的描述        6
1.4 测试驱动程序的设计        6
1.5 接口测试用例        6
1.6 路径测试的检查表        7
2. 功能测试用例        8
2.1 被测试对象的介绍        8
2.2 测试范围与目的        8
2.3 测试环境与测试辅助工具的描述        8
2.4 测试驱动程序的设计        8
2.5 功能测试用例        8
3. 健壮性测试用例        9
3.1 被测试对象的介绍        9
3.2 测试范围与目的        9
3.3 测试环境与测试辅助工具的描述        9
3.4 测试驱动程序的设计        9
3.5 容错能力/恢复能力测试用例        9
4. 性能测试用例        10
4.1 被测试对象的介绍        10
4.2 测试范围与目的        10
4.3 测试环境与测试辅助工具的描述        10
4.4 测试驱动程序的设计        10
4.5 性能测试用例        10
5. 图形用户界面测试用例        11
5.1 被测试对象的介绍        11
5.2 测试范围与目的        11
5.3 测试环境与测试辅助工具的描述        11
5.4 测试驱动程序的设计        11
5.5 测试人员分类        11
5.6 用户界面测试的检查表        11
6. 信息安全性测试用例        12
6.1 被测试对象的介绍        12
6.2 测试范围与目的        12
6.3 测试环境与测试辅助工具的描述        12
6.4 测试驱动程序的设计        12
6.5 信息安全性测试用例        13
7. 压力测试用例        13
7.1 被测试对象的介绍        13
7.2 测试范围与目的        13
7.3 测试环境与测试辅助工具的描述        13
7.4 测试驱动程序的设计        13
7.5 压力测试用例        14
8. 可靠性测试用例        14
8.1 被测试对象的介绍        14
8.2 测试范围与目的        14
8.3 测试环境与测试辅助工具的描述        14
8.4 测试驱动程序的设计        14
8.5 可靠性测试用例        15
9. 安装/反安装测试用例        15
9.1 被测试对象的介绍        15
9.2 测试范围与目的        15
9.3 测试环境与测试辅助工具的描述        16
9.4 测试驱动程序的设计        16
9.5 安装/反安装测试用例        16
附录：评审意见        16

0. 文档介绍
提示：请用户根据项目的实际测试状况，裁剪本测试用例模板。
0.1 文档目的

0.2 文档范围

0.3 读者对象

0.4 参考文献
提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下：
[标识符] 作者，文献名称，出版单位（或归属单位），日期
例如：
[AAA] 作者，《立项建议书》，机构名称，日期
0.5 术语与缩写解释
缩写、术语        解 释
       
       
       
       
…       
1. 接口－路径测试用例
1.1 被测试对象（单元）的介绍

1.2 测试范围与目的

1.3 测试环境与测试辅助工具的描述

1.4 测试驱动程序的设计

1.5 接口测试用例

接口A的函数原型       
输入/动作        期望的输出/相应        实际情况
典型值…               
边界值…               
异常值…               
接口B的函数原型       
输入/动作        期望的输出/相应        实际情况
典型值…               
边界值…               
异常值…               
…               

1.6 路径测试的检查表
检查项        结论
数据类型问题
（１）变量的数据类型有错误吗？
（２）存在不同数据类型的赋值吗？
（３）存在不同数据类型的比较吗？       
变量值问题
（１）变量的初始化或缺省值有错误吗？
（２）变量发生上溢或下溢吗？
（３）变量的精度不够吗？        
逻辑判断问题
（１）由于精度原因导致比较无效吗？
（２）表达式中的优先级有误吗？
（３）逻辑判断结果颠倒吗？       
循环问题
（１）循环终止条件不正确吗？
（２）无法正常终止（死循环）吗？
（３）错误地修改循环变量吗？
（４）存在误差累积吗？       
内存问题
（１）内存没有被正确地初始化却被使用吗？
（２）内存被释放后却继续被使用吗？
（３）内存泄漏吗？
（４）内存越界吗？
（５）出现野指针吗？       
文件I/O问题
（１）对不存在的或者错误的文件进行操作吗？
（２）文件以不正确的方式打开吗？
（３）文件结束判断不正确吗？
（４）没有正确地关闭文件吗？       
错误处理问题
（１）忘记进行错误处理吗？
（２）错误处理程序块一直没有机会被运行？
（３）错误处理程序块本身就有毛病吗？如报告的错误与实际错误不一致，处理方式不正确等等。
（４）错误处理程序块是“马后炮”吗？如在被它被调用之前软件已经出错。       
…       

2. 功能测试用例
2.1 被测试对象的介绍

2.2 测试范围与目的

2.3 测试环境与测试辅助工具的描述

2.4 测试驱动程序的设计

2.5 功能测试用例
功能A描述       
用例目的       
前提条件       
输入/动作        期望的输出/相应        实际情况
示例：典型值…               
示例：边界值…               
示例：异常值…               
功能B描述       
用例目的       
前提条件       
输入/动作        期望的输出/相应        实际情况
……

3. 健壮性测试用例
3.1 被测试对象的介绍

3.2 测试范围与目的

3.3 测试环境与测试辅助工具的描述

3.4 测试驱动程序的设计

3.5 容错能力/恢复能力测试用例
异常输入/动作        容错能力/恢复能力        造成的危害、损失
示例：错误的数据类型…               
示例：定义域外的值…               
示例：错误的操作顺序…               
示例：异常中断通信…               
示例：异常关闭某个功能…               
示例：负荷超出了极限…               
               
               
               
               


4. 性能测试用例
4.1 被测试对象的介绍

4.2 测试范围与目的

4.3 测试环境与测试辅助工具的描述

4.4 测试驱动程序的设计

4.5 性能测试用例
性能A描述       
用例目的       
前提条件       
输入数据        期望的性能（平均值）        实际性能（平均值）
               
               
               
性能B描述       
用例目的       
前提条件       
输入数据        期望的性能（平均值）        实际性能（平均值）
……



5. 图形用户界面测试用例
5.1 被测试对象的介绍

5.2 测试范围与目的

5.3 测试环境与测试辅助工具的描述

5.4 测试驱动程序的设计

5.5 测试人员分类
类别        特征
A类       
B类       
……       
       

5.6 用户界面测试的检查表
检查项        测试人员的类别及其评价
窗口切换、移动、改变大小时正常吗？       
各种界面元素的文字正确吗？（如标题、提示等）       
各种界面元素的状态正确吗？（如有效、无效、选中等状态）       
各种界面元素支持键盘操作吗？       
各种界面元素支持鼠标操作吗？       
对话框中的缺省焦点正确吗？       
数据项能正确回显吗？       
对于常用的功能，用户能否不必阅读手册就能使用？       
执行有风险的操作时，有“确认”、“放弃”等提示吗？       
操作顺序合理吗？       
有联机帮助吗？       
各种界面元素的布局合理吗？美观吗？       
各种界面元素的颜色协调吗？       
各种界面元素的形状美观吗？       
字体美观吗？       
图标直观吗？       
       
…       

6. 信息安全性测试用例
6.1 被测试对象的介绍

6.2 测试范围与目的

6.3 测试环境与测试辅助工具的描述

6.4 测试驱动程序的设计

6.5 信息安全性测试用例
假想目标A       
前提条件       
非法入侵手段        是否实现目标        代价－利益分析
……               
               
假想目标B       
前提条件       
非法入侵手段        是否实现目标        代价－利益分析
……               
               

7. 压力测试用例
7.1 被测试对象的介绍

7.2 测试范围与目的

7.3 测试环境与测试辅助工具的描述

7.4 测试驱动程序的设计



7.5 压力测试用例
极限名称A        例如“最大并发用户数量”
前提条件       
输入/动作        输出/响应        是否能正常运行
例如10个用户并发操作               
例如20个用户并发操作               
…               
极限名称B       
前提条件       
输入/动作        输出/响应        是否能正常运行
               
…               

8. 可靠性测试用例
8.1 被测试对象的介绍

8.2 测试范围与目的

8.3 测试环境与测试辅助工具的描述

8.4 测试驱动程序的设计

8.5 可靠性测试用例
任务A描述       
连续运行时间       
故障发生的时刻        故障描述
       
       
……       
统计分析
任务A无故障运行的平均时间间隔        （CPU小时）
任务A无故障运行的最小时间间隔        （CPU小时）
任务A无故障运行的最大时间间隔        （CPU小时）
任务B描述       
连续运行时间       
故障发生的时刻        故障描述
       
       
……       
统计分析
任务B无故障运行的平均时间间隔        （CPU小时）
任务B无故障运行的最小时间间隔        （CPU小时）
任务B无故障运行的最大时间间隔        （CPU小时）

9. 安装/反安装测试用例
9.1 被测试对象的介绍

9.2 测试范围与目的

9.3 测试环境与测试辅助工具的描述

9.4 测试驱动程序的设计

9.5 安装/反安装测试用例
配置说明       

安装选项        描述是否正常        使用难易程度
全部               
部分               
升级               
其它               
反安装选项        描述是否正常        使用难易程度
               
               

附录：评审意见
提示：测试组长邀请开发人员和同行专家，对《系统测试用例》进行技术评审。






{ 项目名称 }

产品需求规格说明书


文件状态：
[√] 草稿
[  ] 正式发布
[  ] 正在修改        文件标识：        CENTEN-Project-RD-PRS
        当前版本：        X.Y
        作    者：       
        完成日期：        Year-Month-Day
        审 批 人：       

版 本 历 史

版本/状态        作者        参与者        起止日期        备注

                               

                               

                               




目 录
0. 文档介绍        4
0.1 文档目的        4
0.2 文档范围        4
0.3 读者对象        4
0.4 参考文档        4
0.5 术语与缩写解释        4
1. 产品介绍        5
2. 产品面向的用户群体        5
3. 产品应当遵循的标准或规范        5
4. 产品范围        5
5. 产品中的角色        5
6. 产品的功能性需求        6
6.0 功能性需求分类        6
6.M FEATURE M        6
6.m.n Function M.N        6
7. 产品的非功能性需求        7
7.1 用户界面需求        7
7.2 软硬件环境需求        7
7.3 产品质量需求        7
7.N 其它需求        7
附录A：需求建模与分析报告        8
A.1 需求模型1        8
A.N 需求模型N        8
附录B：需求确认        9

0. 文档介绍
0.1 文档目的

0.2 文档范围

0.3 读者对象

0.4 参考文档
提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下：
[标识符] 作者，文献名称，出版单位（或归属单位），日期
0.5 术语与缩写解释
缩写、术语        解 释
       
       
       
…       

1. 产品介绍
提示：
（1）说明产品是什么，什么用途。
（2）介绍产品的开发背景。

2. 产品面向的用户群体
提示：
（1）描述本产品面向的用户（客户、最终用户）的特征，
（2）说明本产品将给他们带来什么好处？他们选择本产品的可能性有多大？

3. 产品应当遵循的标准或规范
提示：阐述本产品应当遵循什么标准、规范或业务规则（Business Rules），违反标准、规范或业务规则的产品通常不太可能被接受。

4. 产品范围
提示：阐述本产品“适用的领域”和“不适用的领域”，本产品“应当包含的内容”和“不包含的内容”。说清楚产品范围的好处是：（1）有助于判断什么是需求，什么不是需求；（2）可以将开发精力集中在产品范围之内，少干吃力不讨好的事情；（3）有助于控制需求的变更。

5. 产品中的角色
提示：阐述本产品的各种角色及其职责。各种角色的具体行为将在功能性需求中描述。

角色名称        职责描述
       
       
       
       

6. 产品的功能性需求
6.0 功能性需求分类
提示：将功能性需求先粗分再细分，下表中的 Feature A, Function A.1等符号应当被替换成有含义的名称。
功能类别        功能名称、标识符        描述
Feature A        Function A.1       
        …       
Feature B        Function B.1       
        …       
Feature C        Function C.1       
        …       

6.m Feature M
提示：此处写一些承上启下的文字。
6.m.n Function M.N
名称、标识符       
功能描述       
优先级       
输入       
操作序列       
输出       
补充说明       

……
7. 产品的非功能性需求
7.1 用户界面需求
需求名称        详细要求
       
       
…       
7.2 软硬件环境需求
需求名称        详细要求
       
       
…       
7.3 产品质量需求
主要质量属性        详细要求
正确性       
健壮性       
可靠性       
性能，效率       
易用性       
清晰性       
安全性       
可扩展性       
兼容性       
可移植性       
…       
7.n 其它需求


附录A：需求建模与分析报告
建议用Rational Rose对产品需求进行建模与分析。
A.1 需求模型1

A.n 需求模型N
附录B：需求确认
提示：主要分两步：（1）需求评审，（2）需求承诺。对需求的评审应当采用“正式技术评审方式”，将产生一份“需求评审报告”。在获取责任人（Stakeholders）对需求的承诺之前，该《产品需求规格说明书》必须先通过需求评审。

需求评审报告摘要
需求文档        输入名称，标识符，版本，作者，完成日期，…
需求评审报告        输入名称，标识符，评审日期，…

评审结论        [  ] 工作成果合格，“无需修改”或者“需要轻微修改但不必再审核”。
[√] 工作成果基本合格，需要作少量的修改，之后通过审核即可。
[  ] 工作成果不合格，需要作比较大的修改，之后必须重新对其评审。

评审意见       




评审小组成员       
输入评审小组成员


需求承诺
需求文档        输入名称，标识符，版本，作者，完成日期


客户承诺        承诺…


签字，    日期

项目经理承诺        承诺…


签字，    日期







{ 项目名称 }

模块设计报告


文件状态：
[√] 草稿
[  ] 正式发布
[  ] 正在修改        文件标识：        CENTEN-Project-SD-MODULE
        当前版本：        X.Y
        作    者：       
        完成日期：        Year-Month-Day
        审 批 人：       

版 本 历 史

版本/状态        作者        参与者        起止日期        备注

                               

                               

                               




目 录
0. 文档介绍        4
0.1 文档目的        4
0.2 文档范围        4
0.3 读者对象        4
0.4 参考文献        4
0.5 术语与缩写解释        4
1. 模块命名规则        5
2. 模块汇总        5
2.1 模块汇总表        5
2.2 模块关系图        5
3. 子系统A的模块设计        6
3.N 模块A-N        6
4. 子系统B的模块设计        6
4.N 模块B-N        6
5. 其他        6

0. 文档介绍
0.1 文档目的

0.2 文档范围

0.3 读者对象

0.4 参考文献
提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下：
[标识符] 作者，文献名称，出版单位（或归属单位），日期
例如：
[AAA] 作者，《立项建议书》，机构名称，日期
0.5 术语与缩写解释
缩写、术语        解 释
       
       
       
       
…       

1. 模块命名规则
提示：模块设计人员确定本软件的模块命名规则（例如类、函数、变量等），确保模块设计文档的风格与代码的风格保持一致。可以从机构的编程规范中摘取或引用（如果存在的话）。


2. 模块汇总
2.1 模块汇总表
提示：这里模块是指相对独立的软件设计单元，例如对象类、函数包等等。

子系统A
模块名称        功能简述
       
       
…       
子系统B
模块名称        功能简述
       
       
…       

2.2 模块关系图
提示：参考体系结构设计文档








3. 子系统A的模块设计
3.n 模块A-n
模块名称       
功能描述       

接口与属性        提示：用专业的设计（开发）工具来设计本模块的接口与属性，说明函数功能、输入参数、输出参数、返回值等。此处粘贴即可。

数据结构
与算法        提示：不论是采用经典的还是专用的数据结构与算法，都应该作必要的描述。不仅用于指导程序的实现，还可以让人们清楚地了解该对象类是如何设计的。

补充说明       

4. 子系统B的模块设计
4.n 模块B-n
模块名称       
功能描述       

接口与属性        提示：用专业的设计（开发）工具来设计本模块的接口与属性，说明函数功能、输入参数、输出参数、返回值等。此处粘贴即可。

数据结构
与算法        提示：不论是采用经典的还是专用的数据结构与算法，都应该作必要的描述。不仅用于指导程序的实现，还可以让人们清楚地了解该对象类是如何设计的。

补充说明       

5. 其他
软件工程设计实验
软件项目开发题目和完成内容要求

【本文主要对此课程的授课目的、内容、授课形式和考核条件进行了叙述，并提供给学生一些可选题目，供学生选择完成。学生也可根据文中提供的选题评分依据自拟自己喜欢的题目。】







××××××××系统

体系结构设计报告


文件状态：
[√] 草稿
[  ] 正式发布
[  ] 正在修改        文件标识：        Legend-Net-DZYW-SD-ARCHITECTURE
        当前版本：        0.1
        作    者：       
        完成日期：        2005-05-10
        审 批 人：       

版 本 历 史

版本/状态        作者        参与者        起止日期        备注
0.1        谢国正        黄海强                通过项目建议书整理

                               

                               




目 录
0. 文档介绍        4
0.1 文档目的        4
0.2 文档范围        4
0.3 读者对象        4
0.4 参考文献        4
0.5 术语与缩写解释        4
1. 系统概述        5
2. 设计约束        5
3. 设计策略        5
4. 系统总体结构        5
5. 子系统N的结构与功能        6
6. 开发环境的配置        6
7. 运行环境的配置        6
8. 测试环境的配置        6
9. 其它        6

0. 文档介绍
0.1 文档目的

0.2 文档范围

0.3 读者对象

0.4 参考文献
提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下：
[标识符] 作者，文献名称，出版单位（或归属单位），日期
例如：
[AAA] 作者，《立项建议书》，机构名称，日期
0.5 术语与缩写解释
缩写、术语        解 释
       
       
       
       
…       

1. 系统概述
提示：（1）说明本系统“是什么”，（2）描述本系统的主要功能。

2. 设计约束
提示：
（1）需求约束。体系结构设计人员从需求文档（如《用户需求说明书》和《软件需求规格说明书》）中提取需求约束，例如：
        本系统应当遵循的标准或规范
        软件、硬件环境（包括运行环境和开发环境）的约束
        接口/协议的约束
        用户界面的约束
        软件质量的约束，如正确性、健壮性、可靠性、效率（性能）、易用性、清晰性、安全性、可扩展性、兼容性、可移植性等等。
（2）隐含约束。有一些假设或依赖并没有在需求文档中明确指出，但可能会对系统设计产生影响，设计人员应当尽可能地在此处说明。例如对用户教育程度、计算机技能的一些假设或依赖，对支撑本系统的软件硬件的假设或依赖等。

3. 设计策略
提示：体系结构设计人员根据产品的需求与发展战略，确定设计策略（Design Strategy）。例如：
        扩展策略。说明为了方便本系统在将来扩展功能，现在有什么措施。
        复用策略。说明本系统在当前以及将来的复用策略。
        折衷策略。说明当两个目标难以同时优化时如何折衷，例如“时－空”效率折衷，复杂性与实用性折衷。


4. 系统总体结构
提示：
（1）将系统分解为若干子系统，绘制物理图和逻辑图，说明各子系统的主要功能。
（2）说明“如何”以及“为什么”（how and why）如此分解系统。
（3）说明各子系统如何协调工作，从而实现原系统的功能。

5. 子系统N的结构与功能
提示：
（1）将子系统N分解为模块（Module），绘制逻辑图（如果物理图和逻辑图不一样的话，应当绘制物理图），说明各模块的主要功能。
（2）说明“如何”以及“为什么”（how and why）如此分解子系统N。
（3）说明各模块如何协调工作，从而实现子系统N的功能。

6. 开发环境的配置
提示：说明本系统应当在什么样的环境下开发，有什么强制要求和建议？

类别        标准配置        最低配置
计算机硬件               
软件               
网络通信               
其它               

7. 运行环境的配置
提示：说明本系统应当在什么样的环境下运行，有什么强制要求和建议？

类别        标准配置        最低配置
计算机硬件               
软件               
网络通信               
其它               
8. 测试环境的配置
提示：说明本系统应当在什么样的环境下测试，有什么强制要求和建议？
（1）一般地，单元测试、集成测试环境与开发环境相同。
（2）一般地，系统测试、验收测试环境与运行环境相同或相似（更加严格）。
9. 其它