软件包含哪些内容

数据 程序 文档

软件生命周期

1. 需求分析
2. 概要设计
3. 详细设计
4. 编码
5. 测试
6. 验收
   

瀑布模型

1. 计划
2. 需求分析
3. 设计
4. 编码
5. 测试
6. 运行-维护
   

螺旋模型

螺旋模型是一种演化软件开发过程模型，它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。

测试流程

1. 获取测试需求
2. 编写测试计划
3. 指定测试方案
4. 开发于设计测试用例
5. 执行测试
6. 提交缺陷报告
7. 测试分析于评审
8. 提交测试总结
9. 准备下一版本测试

软件测试过程模型

• V模型
  

• W模型
  

• H模型
  H模型适合外包测试公司 来一个需求用户需要提供软件，需求，设计，标准
  大型中上型的测试部门都是独立的

优点

早准备，早执行，效率高

• X模型
  X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。 适合有经验的测试人员

一个标准的软件测试过程中，应当包含但不仅限包含以下测试活动
需求分析、测试计划、测试设计、测试执行、测试总结.

软件测试过程理念

1. 尽早测试
2. 全面测试
3. 全过程测试
4. 独立迭代测试

按照测试技术划分

1. 黑盒测试
2. 白盒测试
3. 灰盒测试

测试运行主题划分

1. 手工测试
2. 自动化测试

软件测试原则

• 所有测试的标准都是建立在用户需求之上。
• 软件测试必须基于“质量第一”的思想去开展各项工作，当时间和质量冲突时，时间要服从质量。
• 事先定义好产品的质量标准，只有有了质量标准，才能根据测试的结果，对产品的质量进行分析和评估。·软件项目一启动，软件测试也就是开始，而不是等程序写完，才开始进行测试。
• 穷举测试是不可能的。
• 第三方进行测试会更客观，更有效。
• 软件测试计划是做好软件测试工作的前提。
• 测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。

遇到的问题

1. 时间不够的情况下还有大量内容没测试。软件能不能发布上线
2. 严重bug没修复但是赶着上线能不能通融放任
3. 需求重要吗 ？错误的需求对测试的影响
4. 你觉得软件测试在什么阶段开始比较好
5. 软件发布了但是有缺陷是测试人员的错误吗
6. 你写过测试计划吗，包含什么内容，测试计划可以修改吗
7. 设计与编码有什么区别
8. 对已经发现缺陷的模块如何进入深入测试
9. 软件项目不着急的时候 测试任务完成了你会做什么
   10.软件项目上线了 还需要测试吗

什么是测试用例

• 设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的预期结果
• 如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那就表示软件程序人员已经测出软件有缺陷，这时候就必须将这个问题标示出来，并且通知软件开发人员。软件开发人员接获通知后，将这个问题修改完成于下一个测试版本内
• 软件测试工程师取得新的测试版本后，必须利用同一个用例来测试这个问题，确保该问题己修改完成。

测试用例模板

测试用例编号	测试项	依赖用例	测试步骤	输入数据	预期结果	结果测试	测试人	备注
1	测试目的

测试用例模板说明

1. 编号
   类型分类
   • 功能 Function
   • 界面UI
   • 性能Performance
   • 安全 Security
   • 接口 Interface

编号规则 TestCase_项目名_模块名_功能名_测试类型_0001

2. 测试项 必须是确定的不能存在不确定性

测试目的 一句话表明目的 例如 谷歌浏览器打开百度

3. 依赖用例

一般功能流程上 下游的功能测试依赖上游的功能测试的用例

4. 测试步骤

用最朴实的语言写出软件操作步骤

5. 输入数据

单独整合测试数据 必须和测试步骤中的数据保持一直

6. 预期结果

准确，对象的准确，内容的准确，原则每一个操作都要有结果，一般结果会在重要步骤设定预期结果，例如：跳转到某页弹出对话框提示用户密码错误。一般和测试目的密切相关。测试目的决定了测试步骤和预期结果

7. 测试结果

要求测试完成添加结果，没有执行保持空。测试结果只有俩 通过 失败，和预期结果一直就通过，不一致就不通过

8. 备注

正常执行而做的特殊准备

测试用例的设计与作用

• 有效性:测试用例是测试人员测试过程中的重要参考依据。
• 可复用性:良好的测试用例具有重复使用的功能，使得测试过程事半功倍，提高测试效率。
• 易组织性:即使是小的项目，也可能会有几千甚至更多的测试用例，测试用例可能在数月甚至几年的测试过程中被创建和使用。
• 可评估性:从测试的项目管理角度来说，测试用例的通过率是检验代码质量的保证。
• 可管理性:测试用例也可以作为检验测试人员进度、工作量以及跟踪/管理测试人员的工作效率的标准。

黑盒测试用例设计方法

黑盒测试用例设计方法概述

• 输入 ，软件 ，输出 只是操作软件不进行代码审计，看看每一个步骤对软件的影响

等价类划分法

• 把程序的输入域划分成若干部分，然后从每个部分中选取少数代
  表性数据作为测试用例

• 每一类的代表性数据在测试中的作用等价于这一类中的其他值，
  如果某一类中的一个例子发现了错误，这一等价类中的其他例子
  也能发现同样的错误。

• 反之，如果某-类中的一个例子没有发现错误，则这一类中的其
  他例子也不会查出错误

等价类划分步骤

确定定价类原则

• 在输入条件规定了取值范围或值的个数的情况下，可以确立一个有效等价类和两个无效等价类

1. 一个文本框规定，输入字符个数为6~18位

一个有效等价类:范围内个数。 两个无效:小于6;大于18个。

• 在输入条件规定了输入值的集合或者规定了"必须如何” 的条件的情况下，可以确立一个有效等价类和一个无效等价类

1. 输入11为的手机号

11位有效，不是11位就是无效

• 在输入条件是一个布尔量的情况下， 可确定一个有效等价类和一 个无效等价类

1. 输入11为的手机号

11位有效，不是11位就是无效

• 在规定了输入数据的一组值(假定n个),并且程序要对每一个输入值分别处理的情况 下，可确立n个有效等价类和一个无效等价类

1. 登录输入用户名密码 一个有效n个无效

用户名有效 密码无效

• 在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)
• 在确知己划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类

边界值分析法

1. 边界值只是一个特定的数据。例如,文本框需要输入6到18位字符。
   边界值有:。

1. 6个字符。
2. 18个字符。

2. 文本框输入字符的个数要求不大于150字符
   • 不能为空
   • 字数最多149个字符

边界值的选择原则

• 如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据
• 如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1的数作为测试数据
• 根据规格说明的每个输出条件，使用前面的原则①
• 根据规格说明的每个输出条件，应用前面的原则②
• 如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例
• 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构边界上的值作为测试用例。

因果图法

判定表法

场景法

正交实验法

功能图法

缺陷概述

缺陷定义

• 软件未实现产品说明书要求的功能
• 软件出现了产品说明书指明不应该出现的功能
• 软件实现了产品说明书未提到的功能
• 软件未实现产品说明书虽未明确提及但应该实现的目标
• 软件难以理解、不易使用、运行缓慢或者（从测试的角度看)最终用户会认为不好

缺陷的属性

缺陷类型

软件严重的程度

缺陷的修复优先级

缺陷的状态

###缺陷的来源

缺陷的根源

缺陷的生命周期

1. 发现缺陷
2. 提交缺陷
3. 确认缺陷
4. 分配缺陷
5. 修复缺陷
6. 验证缺陷
7. 关闭缺陷

缺陷的识别

识别的依据

1. 需求文档 设计文档 产品原型 测试用例

缺陷的报告

1. 缺陷编号-项目名词-模块名称-功能名称-0001
2. 所属模块 1 ，2 ，3 ，模块
3. 优先级
4. 严重程度
5. 缺陷概述 一句话描述缺陷的情况
6. 缺陷描述 描述缺陷重现步骤预期结果和实际结果描述出来
7. 提交人
8. 备注 生产缺陷的特殊情况 bug截图作为备注信息