其他考点

Posted on Wed, 25 Dec 2024 17:15:10 +0800 by LiangMingJian

1.性能测试 #

1.1 性能测试的对象 #

• 需要高吞吐量的业务。
• 需要高服务器负载的业务。
• 存在高商业风险的业务。

1.2 性能测试的分类 #

• 负载测试：当负载逐渐增加时，考察系统各项性能指标的变化。
• 压力测试：确定系统的瓶颈，获得系统的最大服务级别。
• 强度测试：考察系统在低资源情况下的运行能力，反应系统对异常情况的抵抗能力。
• 容量测试：考察系统某项指标的极限值，反应系统最大负载或工作量。
• 基准测试：与已有标准进行比较测试，要求获取一致且可再现的结果。

2.Web 网页测试 #

2.1 Web 网页测试的定义 #

• Web 项目是基于浏览器 B/S 架构的一类项目，当 Web 服务端更新内容或程序升级后，客户端会自动同步更新。
• Web 项目测试与其他项目的测试内容和测试手段基本相同，只是测试的重点与工具不同。

2.2 Web 功能测试的内容 #

• 链接测试：要求检查所有链接是否正确链接到指定界面，指定页面是否存在，并且保证 Web 应用中没有必须输入 Url 跳转的孤立界面。
• 表单测试：要求检查表单是否存在漏洞，是否有做非法字符过程。
• Cookies 测试：要求检查 Cookies 是否有时间限制，是否安全。
• 数据库测试：要求检查是否存在数据库漏洞。

2.3 Web 性能测试的内容 #

• 连接速度测试
• 负载测试
• 压力测试

2.4 负载压力测试的性能指标 #

• 客户端交易处理性能指标
• 服务器资源监控指标
• 数据库资源监控指标
• Web 服务器监控指标
• 中间件监控指标

2.4 客户端性能指标 #

• 并发用户数：负载压力大小指标，不能用来判断业务执行效率
• 处理时间：从接收到一个消息到送出其结果之间计算机的历时时间。
• 周转时间：从提出要求到求得结果所需要的时间。
• 交易通过率：业务执行效率指标
• 响应时间：业务执行效率指标，包括处理时间和传输时间，指从按下传送键到得到结果为止所需要的时间。
• 交易执行吞吐量：业务执行效率指标
• 每秒点击率：业务执行效率指标，网站上某一内容被点击次数与显示次数比（业务执行效率指标）
• 平均事务响应时间：业务执行效率指标

2.5 服务器性能指标 #

• CPU占用率
• 内存占用量
• 每秒进程切换数

2.5 Web 可用性测试的内容 #

• 导航测试
• 图形测试
• 内容测试
• 整体界面测试

2.6 Web 安全性测试的内容 #

• 注册登录的方式
• Web 应用系统是否有超时限制
• 相关信息是否写进了日志文件，并支持跟踪
• 当使用套接字与服务器交流时，信息是否加密，信息是否完整
• 服务端是否存在漏洞

2.7 Web 易用性测试的内容 #

• 安装测试：包括安装手册，自动化程度，选项和设置，中断，修复，升级和卸载。
• 界面测试：
  • 界面整体测试：对界面的规范性，一致性，合理性以及定制性进行测试。
  • 界面元素测试：主要包括窗口，菜单，图标，文字和鼠标。
• 功能易用性测试：功能是否便于使用，是否人性化。
• 辅助系统测试（帮助测试）：包括帮助手册，使用说明等。

3.文档测试 #

3.1 文档测试的内容 #

• 文档测试的内容包括软件生命周期中所有文档。
• 文档测试时，需要准确按手册描述使用程序，检查每条程序，查找容易误导用户的内容。
• 文档测试不能修改错误设计

3.2 常用的计算机文档 #

• 开发文档：可行性研究报告，软件需求说明书，数据要求说明书，概要设计说明书，详细设计说明书，数据库设计说明书，模块开发卷宗。
• 用户文档：用户手册，操作手册，联机帮助，样例，最终用户许可协议
• 管理文档：项目开发计划，测试计划，测试分析报告，开发进度月报，项目开发总结报告

3.3 文档测试内容 #

• 检查软件返回结果跟文档描述是否一致属于一致性方面。
• 检查所有信息是否真实正确属于正确性方面。
• 检查术语符合行业规范属于术语范畴。
• 文档面向读者应该定位要明确，不能一个文档面向所有级别。

3.4 需求说明书评测内容 #

• 系统定义的目标是否与用户要求一致
• 系统需求分析阶段提供文档是否齐全
• 文档中描述是否完整，清晰地反应用户要求
• 与其他系统成分的重要接口是否已进行描述
• 项目的数据流和数据结构是否足够且确定
• 所有图表是否清楚，在不补充说明是能否理解
• 主要功能是否已包括在规定的软件范围之内，是否已充分说明
• 软件的行为与其必须处理的信息和完成的功能是否一致
• 设计的约束条件或限制条件是否符号实际
• 是否考虑了开发的技术风险
• 是否考虑需求的其他方案
• 是否考虑过将来可能提出的软件需求
• 是否制订了检验标注
• 有没有遗漏，重复或不一致
• 用户是否审查了初步的用户手册或原型
• 项目开发计划中的估算是否受到影响

3.5 概要设计说明书评测内容 #

• 可追溯性：软件设计的每一成分都可追溯到某一项需求
• 接口：软件的内部接口和外部接口要明确定义，模块要满足高内聚和低耦合的要求，模块的作用范围在其控制范围内
• 风险：确认该软件设计在现有技术条件和预算内能按时实现
• 实用性
• 技术清晰度：确认该软件能以一种易于翻译为代码的形式表达
• 可维护性
• 质量
• 多种选择方案：查看是否考虑过其他选择方案
• 限制：评估该软件的限制是否现实

4.测试计划设计 #

4.1 测试计划结构 #

1. 测试计划标识符
2. 引言：描述要测试的软件项和软件特征
3. 测试项
4. 要测试的特征
5. 不要测试的特征
6. 方法
7. 测试项通过准则
8. 暂停准则和恢复要求
9. 测试交付项：标识可交付的文档
10. 测试任务
11. 环境要求
12. 职责：标识负责管理，设计，准备，执行，监督，检查和解决的各小组
13. 人员配备和培训要求
14. 进度：标识测试计划里程碑
15. 风险和应急
16. 批准：负责人签名

4.2 测试文档规范 #

• 为了便于同行的交流，提高测试过程各阶段的可视性和测试工作的可管理性，GB/T 9386-2008 《计算机软件测试文档编制规范》（替代GB/T 9386-1988 《计算机软件测试文件编制规范》）规定了一组基本的测试文档的格式和内容要求。
• 测试计划：测试计划描述测试活动的范围、方法、资源和进度。它规定被测试的项、被测试的特性、应完成的测试任务、负责每项工作的人员以及与本计划有关的风险等。
• 测试说明：测试说明包括测试设计说明，测试用例(案例)说明，测试规程说明
• 测试报告：测试报告包括测试项传递报告，测试日志，测试事件报告，测试总结报告

4.3 测试设计说明结构 #

1. 测试设计说明标识符
2. 要测试的特征
3. 方法细化
4. 测试用例标识
5. 特征通过准则

4.4 测试用例说明结构 #

1. 测试用例说明标识符
2. 测试项
3. 输入说明
4. 输出说明
5. 环境要求
6. 特殊的规程要求
7. 用例间的依赖关系

4.5 测试总结报告结构 #

• 测试总结报告标识符
• 摘要
• 差异
• 测试充分性评价
• 结果汇总
• 评价
• 活动总结
• 批准

5.技术评审 #

• 正式的技术评审 FTR(Formal Technical Review) 是软件工程师组织的软件质量保证活动。
• 评审产品，而不是评审生产者的能力。
• 要有严格的评审计划，并遵守日程安排。
• 对评审中出现的问题要充分讨论，但不一定要当场解决，而是形成行动计划在评审后处理。
• 限制参与者人数，并要求评审会之前做好准备。

6.信息 #

• 信息指接收者事先不知道的消息，与不确定性紧密相关。接收者在接收到信号后不确定性消失或减少，那么接收者从不知到知，从而获得信息。信息论奠基人香农把信息理解为——用以消除随机不确定的内容。
• 信息化是人类社会发展的一个高级过程，其核心是通过全体社会成员的共同努力，在经济和社会的各个领域充分应用基于现代信息技术的先进社会生产工具，创建信息时代社会生产力。信息化就是开发利用信息资源，促进信息交流和知识共享，提高经济增长质量，推动经济社会发展转型的历史进程。
• 随着信息技术的发展突破，信息资源日益成为重要生产要素，无形资产和社会财富。
• 信息、材料和能源共同构成经济和社会发展的三大战略资源，有效合理的利用这些资源，可以促进生产力的发展，可以实现资源之间的相互转化。
• 事物运动是绝对的，其状态改变无时不有，无处不在，信息是事物运动状态的表征，具有无限性和普遍性。
• 由于人们认识能力和认识目的的不同，从同一事物获取的信息与信息量也不同，信息具有相对性。
• 信息不是事物本身，不能独立存在，必须借助某种载体才能表现出来。
• 信息是可传递的，信息在空间上传递称为通信，在时间上传递称为信息存储。

7.信息化办公 #

7.1 电子政务 #

• 电子政务是指国家机关在政务活动中，全面应用现代信息技术、网络技术以及办公自动化技术等进行办公、管理和为社会提供公共服务的一种全新的管理模式。
• 电子政务建设不是简单的将政府原有职能和业务流程计算机化或网络化，需要配合政府结构的跳转以及业务流程的重组，因此与传统政务的业务流程，办公手段有较大不同。是政务活动的一种新的表现方式，是一项重要的政府创新。通过电子邮件或WWW网站，公众能与政府更有效的进行沟通。

7.2 电子政务的类型 #

• G2G：政府间电子政务
• G2B：政府-商业机构间电子政务
• G2C：政府-公民间电子政务
• G2E：政府-雇员间电子政务

7.3 电子商务 #

• 电子商务通常是指在全球各地广泛的商业贸易活动中，在因特网开放的网络环境下，基于客户端/服务端应用方式，买卖双方不谋面地进行各种商贸活动，实现消费者的网上购物、商户之间的网上交易和在线电子支付以及各种商务活动、交易活动、金融活动和相关的综合服务活动的一种新型的商业运营模式。

7.4 电子商务的类型 #

• B2B：商家（泛指企业）对商家的电子商务
• B2C：商家对用户的电子商务
• C2C：用户对用户的电子商务

7.5 企业信息化 #

• 企业信息化指企业将信息技术手段应用到企业生产和运营关联中，利用信息技术来改造和提升自己业务和管理水平的过程。信息共享和业务协同是企业信息系统的重要目标。
• 企业信息系统项目的基础是企业项目战略规划，规划的起点是将企业的战略目标和信息需求转换为信息系统的目标，实施信息系统项目是为企业建立数据处理中心，以满足各级管理人 员关于信息的需求，它坚持以应用为中心的原则。
• 企业信息化建设应当是自上而下地规划和自下而上地分步实现。这样的信息系统才能按部就班地以模块化建设，并照顾到企业各管理层的需求，最终使得信息系统能支持企业的战略目标，向整个企业提供一致的信息。

7.6 企业信息化的原则 #

• 先进性：尽可能采用先进而成熟的技术，在一段时间内保证其主流地位。
• 开放性：采用国际通用标准和技术以获得良好的开放性。
• 经济性：在满足需求的基础上尽可能的节省费用。
• 高可用性：系统要有高的平均无故障时间和尽可能低的平均故障率。

7.7 EAI 企业应用集成 #

• EAI（Enterprise Application Integration，企业应用集成）是将基于各种不同平台、用不同方案建立的异构应用集成的一种方法和技术。
• EAI 通过建立底层结构，来联系横贯整个企业的异构系统、应用、数据源等，实现企业内部各系统间无缝地共享和交换数据。

7.8 EAI 企业应用集成内容 #

• 界面集成：这是比较原始和最浅层次的集成，但又是常用的集成。这种方法是把用户界面作为公共的集成点，把原有零散的系统界面集中在一个新的、通常是浏览器的界面之中。
• 业务过程集成：当对业务过程进行集成的时候，企业必须在各种业务系统中定义、授权和管理各种业务信息的交换，以便改进操作、减少成本、提高响应速度。业务过程集成包括业务管理、进程模拟以及综合任务、流程、组织和进出信息的工作流，还包括业务处理中每一步都需要的工具。
• 应用集成：为两个应用中的数据和函数提供接近实时的集成。在一些 B2B 集成中用来实现CRM 系统与企业后端应用和 Web 的集成，构建能够充分利用多个业务系统资源的电子商务网站。
• 数据集成：为了完成应用集成和业务过程集成，必须首先解决数据和数据库的集成问题。在集成之前，必须首先对数据进行标识并编成目录，另外还要确定元数据模型。这三步完成以后，数据才能在数据库系统中分布和共享。
• 平台集成：要实现系统的集成，底层的结构、软件、硬件以及异构网络的特殊需求都必须得到集成。平台集成处理一些过程和工具，以保证这些系统进行快速安全的通信。

8.数据环境 #

• 数据环境是詹姆斯·马丁为解决"数据处理危机"而提出的重要概念，是针对不同的管理层次需要，所采取的数据处理和管理方法的总称。
• 计算机的数据环境分为以下四种类型。
• 数据文件：不使用数据管理系统
• 应用数据库：使用数据管理系统
• 主题数据库：数据库的建立基本独立于具体应用
• 信息检索系统（数据仓库）：自动信息检索，决策支持和办公自动化，数据动态变化

9.通用评价过程与特性 #

9.1 GB/T 18905 软件工程产品评价中确定的通用评价过程 #

• 确定评价需求：包括确定评价目的，确定产品类型，指定质量模型
• 规定评价：选择度量，建立度量评定等级，确定评估准则
• 设计评价：制定评价计划
• 执行评价：进行度量，与评价准则相比较，评估结果

9.2 评价过程的主要目标是提高评价过程特性 #

• 可重复性：由同一评价者按同一评价规格重复评价同一产品可以产生同一种结果
• 可再现性：由不同评价者按同一评价规格重复评价同一产品可以产生同一种结果
• 公正性：评价不偏向任何特殊的结果
• 客观性：评价结果应是客观事实，即不带有评价者的感情色彩和主观意见

9.3 适用对象 #

• 评价者用的过程适用于计划获取或复用已有软件的组织使用

10.缺陷数据统计 #

10.1 缺陷探测率 DDP #

• 缺陷探测率（DDP）=开发人员和测试人员发现错误数 / 总BUG数（开发人员+测试人员+客户）

10.2 故障总数估计 #

• 植入估计法：设 $N_s$ 是测试前故意植入的故障数，$n_s$ 是测试后发现的播种故障数，$n_0$ 是测试中发现的原有故障数，则原有故障总数估算值为 $N_0=n_0 * N_s/n_s$。
• 分别测试法：由两个测试人员同时互相独立测试同一程序，记甲发现故障总数 $B_1$，乙发现故障总数 $B_2$，两人发现相同的故障总数为 $b_c$，则原有故障总数估算值为 $B_0=B_1 * B_2/b_c$。

10.3 故障风险曝光度 #

风险曝光度 = 错误出现率 X 错误造成的损失

11.测试执行 #

11.1 测试过程 #

• 测试需求分析
• 制订测试计划
• 测试设计
• 测试执行
• 测试分析和总结

11.2 测试管理 #

• 测试过程管理
• 测试人员和组织
• 测试计划和进度管理
• 测试风险管理
• 测试成本管理
• 测试产出物管理

11.3 软件样品登记 #

• 部件或文档的唯一标识符
• 部件的名称或文档标题
• 文档的状态，包括物理状态和变异状态
• 样品的版本，配置和日期信息
• 接收的日期

12.测试质量度量指标 #

14.串联系统的故障率 #

• 串联系统的故障率等于串联的每个元件的故障率乘积。
• 平均故障间隔时间等于故障率乘积的倒数。

11.3 IIS 下多站点的配置 #

• 采用虚拟主机时，发布的站点可以存在多个独立域名。
• 采用虚拟目录时，发布的站点没有独立的域名，而是在主域名下建立虚拟目录。

6.哈希表 #

6.1 哈希表的定义 #

• 哈希表是一种搜索结构，当数据量大时，哈希搜索的效率高，平均时间复杂度O(1)。

6.2 哈希查找 #

• 在插入时，根据待插入元素的关键码，以此函数计算出该元素的存储位置并按此位置进行存放。
• 在搜索时，对元素的关键码进行同样的计算，把求得的函数值当作元素的存储位置，在结构中按此位置取元素比较，若关键码相等，则搜索成功。

6.3 哈希冲突 #

• 对于两个数据元素的关键字 Ki 和 Kj(i != j)，有 Ki != Kj (i != j) ，但 HashFun( Ki ) == HashFun( Kj ) ，将该种现象称为哈希冲突或哈希碰撞。

6.4 常见的求哈希值方法 #

• 直接定址法：：取关键字的某个线性函数为散列地址：Hash(Key)= A X Key + B。适合查找比较小且连续的情况
• 除留余数法：设散列表中允许的地址数为m，取一个不大于m，但最接近或者等于m的质数，按照哈希函数：Hash( key ) = key % p ( p <= m ) ，将关键码转换成哈希地址。
• 平方取中法
• 折叠法
• 随机数法
• 数学分析法

6.5 使用线性探查法解决冲突 #

• 给出一组元素，它们的关键码为：37，25，14，36，49，68，57，11，散列表为 HT[12]，表的大小 m=12 ，11 是最接近 m 的质数，因此 Hash(key)= key % 11，得出哈希值。在添加元素时，使用散列函数值确定元素的插入位置，如果此空间有值，产生冲突，则依次查看其后的下一个桶，直到发现空位置插入新元素。

7.矩阵 #

7.1 矩阵的定义 #

• 由 m × n 个数 aij 排成的 m 行 n 列的数表称为 m 行 n 列的矩阵，简称 m × n 矩阵。元素是实数的矩阵称为实矩阵，元素是复数的矩阵称为复矩阵。而行数与列数都等于 n 的矩阵称为 n 阶矩阵或 n 阶方阵。

7.2 矩阵计算 #

• 加，减，数乘，转置

• 共轭，实部不变，虚部取负

8.7 极限编程的十二个最佳实践 #

1. 计划游戏（快速制定计划、随着细节的不断变化而完善）
2. 小型发布
3. 隐喻
4. 简单设计
5. 测试先行
6. 重构
7. 结对编程
8. 集体代码所有制
9. 持续集成
10. 每周工作40个小时
11. 现场客户
12. 编码标准

9.软件体系风格 #

9.1 软件体系风格的定义 #

• 软件体系结构风格（Architectural Styles）是描述特定系统组织方式的惯用范例，强调了软件系统中通用的组织结构。
• 一个软件体系结构风格定义了构件和连接件类型的符号集，及规定了它们怎样组合起来的约束集合。

9.2 软件体系风格的类型 #

• 数据流风格：批处理序列，管道/过滤器
• 调用/返回风格：主程序/子程序，面向对象，层次结构
• 独立构建风格：进程通讯，事件系统
• 虚拟机风格：解释器，基于规则的系统
• 仓库风格：数据库系统，超文本系统，黑版系统

9.3 主程序-子程序风格 #

• 主程序-子程序是结构化程序设计的一种典型的调用/返回风格，从功能的观点设计系统，通过逐步分解和细化，形成整个系统的体系结构。

9.4 面向对象风格 #

• 与前面的主程序-子程序风格比，虽然同是调用/返回风格的一种，但面向对象风格中的构件变成了对象，并且连接的方式也发生了相应的变化。
• 面向对象风格强调设计，全面的系统考虑，以及现实世界的对应关系。
• 对象对客户隐藏了实现的细节，实现了对内部表达的保护(封装数据/状态的完整)，可以在不影响客户的情况下改变对象的实现(低耦合，高重用，可维护)，方便系统的升级。
• 面向对象风格的缺点是对象交互时需要知道彼此的标识，多个对象对同一资源的访问(A和B同时需要使用C)可能对出现问题。

9.5 分层体系风格 #

• 分层体系风格是调用/返回风格的一种，它的组织为层次结构，每一层给外层提供服务，又作为它内层的客户。在某些系统中，内层只对相邻的层可见，组织间通过连接件（层间的协议）定义层次间的交互方式。
• 分层体系风格支持基于抽象程度逐渐递增的系统设计，支持层重用，支持功能增强，具有高扩展性，可维护性
• 分层体系风格的缺点是行为改变难以进行传递，上面的层过分依赖下面的层提供服务，相关数据传达时间长，数据传输低效，层次大小的难以清晰界定，并且缺少合适的、正确的层次抽象方法。

9.6 管道-过滤器风格 #

• 管道-过滤器风格是数据流风格的一种，它把系统任务分成若干连续的处理步骤，这些步骤由通过系统的数据流连接，一个步骤的输出是下一个步骤的输入。
• 管道-过滤器风格使得软构件具有良好的隐蔽性和高内聚、低耦合的特点，系统中已有的过滤器很容易用于新的待设计系统。
• 管道-过滤器风格允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成，支持软件重用，每个过滤器是作为一个单独的任务完成，支持与其它任务并行执行，任何两个过滤器都可被连接起来。因此，系统维护简单，容易进行扩展。
• 管道-过滤器风格由于过滤器是对输入的批量转换处理，对输入和输出有相应的说明限制，通常会导致进程成为批处理的结构。同时由于全局变量的共享很困难，因此通信交互性不强，当数据传输量很大而又有很多小的过滤器时代价较大，执行效率并不理想，交互性差，出现错误时如何做处理比较困难。

9.7 仓库风格 #

• 仓库体系风格是以数据为中心的体系结构，适合于数据由一个模块产生而由其他模块使用的情形。
• 仓库体系风格的优点是能在有限的范围内实验不同的问题解决者和诱导启发式的控制方法，容忍哪些不可靠的问题解决者，知识源可以重用，规模伸缩性好（方便添加新数据）。
• 仓库体系风格的缺点是测试困难，难以保障最佳解决方案，且控制策略通常需要启发诱导，计算开销大（工作量可能比较大，浪费多），数据修改困难，系统的复杂度高。

9.9 分布式架构 #

• 支持大量并发用户；容错和灾备能力；可灵活扩展的优点

10.设计模式 #

10.1 设计模式的定义 #

• 设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。
• 使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性、程序的重用性。
• 采用设计模式能复用相似问题的相同解决方案。

10.2 设计模式的三大类 #

• 创建型模式（Creational Pattern）：对类的实例化过程进行了抽象，能够将软件模块中对象的创建和对象的使用分离。包括：（5种）单例模式、工厂模式、抽象工厂模式、建造者构建模式、原型模式

• 结构型模式（Structural Pattern）：关注于对象的组成以及对象之间的依赖关系，描述如何将类或者对象结合在一起形成更大的结构，就像搭积木，可以通过简单积木的组合形成复杂的、功能更为强大的结构。包括：（7种）适配器模式、装饰者模式、代理模式、外观模式、桥接模式、组合模式、享元模式

• 行为型模式（Behavioral Pattern）：关注于对象的行为问题，是对在不同的对象之间划分责任和算法的抽象化；不仅仅关注类和对象的结构，而且重点关注它们之间的相互作用。包括：（11种）策略模式、模板方法模式、观察者模式、迭代器模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式

10.3 设计模式的 UML 类图 #

23种设计模式 UML 类图图解

10.4 MVC 设计模式 #

• MVC 模型-视图-控制器是一种设计模式，它强制性地使应用程序的输入，处理和输出分开，使应用程序分为模型，视图，控制器 3 个模块，各自处理自己的任务。
• 视图是用户看到并与之交互的界面，对于Web应用来说，可以概括为HTML界面，但有可能为XHTML、XML和Applet；主要负责呈现，也就是用户界面。
• 模型就是业务流程/状态的处理以及业务规则的制定。业务模型的设计可以说是MVC最主要的核心；主要负责数据和业务逻辑。
• 控制器是接受用户输入并调用模型和视图完成用户需求，控制器本身不输出任何内容并执行任何处理，只是接受请求并调用其他模式。
• MVC 的优点有：耦合性低；重用性高；部署快；生命周期成本低；可维护性高；
• MVC 的缺点有：运行效率低；调试困难；不适合小型，中等规模的应用程序；增加系统结构和实现的复杂性；视图与控制器间的过于紧密的连接并且降低了视图对模型数据的访问；
• MVC常用的框架有：Struts、Spring、ZF、.NET MVC等。

17.软件开发文档 #

• 软件开发文档可分为开发，管理和用户文档。
• 开发文档应当包括软件需求说明，可行性研究报告和项目开发计划。
• 文档是影响软件可维护性的决定因素。由于长期使用的大型软件系统在使用过程中必然会经受多次修改，所以文档比程序代码更重要。
• 软件文档应该描述如何使用这个系统，描述怎样安装和管理这个系统，描述系统需求和设计，描述系统的实现和测试，以便系统维护。

8.软件测试文档 #

• 测试计划：为了描述软件特性的测试而编写的文档计划，为了规范化测试内容，测试需要用到的资源等。
• 测试用例：用于描述测试用例的具体细节工作，测试用例一般根据测试计划及测试策略来编写。
• 测试缺陷：描述测试过程中相关缺陷信息，让团队成员更好的了解测试缺陷类型。
• 测试报告：一份完整的描述测试结果的报告，对测试结果进行统计分析及总结。
• 测试需求文档，测试环境配置说明，缺陷报告，测试总结分析。