整理软件测试分析资料

*软件研发生命周期：需求分析--》设计---》编码--》测试--》发布维护

需求分析：需求文档规格书

设计：软件研发计划和方案
编码：开发写代码
测试：测试人员测试，执行测试用例，测试报告……
发布：产品

*软件测试的基本流程：
获取测试需求（-需求评审）--------编写测试计划（人员分工）--------制定测试方案-------设计测试用例（什么方法测试）--------执行测试用例（用例评审）-------提交bug（跟踪管理bug）------测试报告（开测试总结会议）

1,获取测试需求：首先我们会参与需求 的评审，当需求确定后我们测试的工作就可以启动了，启动后还是进一步学习理解需求，当需求理解完成后。
我们测试组长会做一个测试计划，给我们组员进行分工，分工完成后每个人开始负责各自负责模块的测试设计，编写用例，用例编写完成后会进行测试组内评审，评审完成后等开发转测，就开始执行测试，执行  测试过程中发现bug就提交给开发，并对bug进行跟踪管理，了解一下bug的原因以及解决的方法，解决的时间，对于解决时间比较长的bug我还会实时的取提醒一下开发按时解决这个bug，直到bug的解决。开发bug解决后，我们会根据bug的解决方法，判断一下开发解决这个bug改动了那块代码，哪些功能点可能受到影响，根据这些信息圈定一个bug回归测试的范围验证bug是否解决是否引入新问题，如果没有就关闭bug，这个执行过程一直持续到整个测试完成，最后我们会出一个测试报告，测试工作基本就结束了，测试完成后我们还会召开一个总结大会，回顾总结我们测试工作中那些工作做得好，可以继续发扬光大，那些工作做得不好需要改进，我就指定改进措施优化流程。

评审学习过程：产品经理讲解需求-----（理解之后）进行反讲------最终产品，开发，测试需求理解一致

反讲内容：测试人员从测试角度分析这个需求是个什么样的需求（软件的基本功能和运行的业务流程，功能模块和组织结构），要如何测试，需要准备哪些数据，使用什么工具，

适合什么用例设计方法，测试有什么难度，有没有什么风险。
开发就从开发角度讲一下这是什么需求，要怎么开发，采用什么技术

有什么难点，有什么风险，最终通过反讲的形式使得产品、开发、测试三方需求理解一致。

2.编写测试计划：工作人员的投入-----人员分工------各项任务的时间要求-----启动---暂停----结束---预估风险---等等
由项目经理编写测试计划：首先估计工作量，工作量估计完成后按照各个需求的时间要求，进行任务分工，每个人的工作量要相对平均，每个人的工作难度要与其个人能力匹配，从激发员工潜能培养员工角度，工作难度要略高于其个人能力。

还有考虑人员的互备，当有人员流动时，他的工作如果更重要紧急可以有人迅速顶上。

工作中互备人员要对对方负责的模块、业务熟悉了解，可以安排互测，通过互测的方式互相熟悉。

另外计划中还要考虑风险，并且要制定风险的应对措施以及责任人对风险进行跟踪管理。

另外在指定计划时可以参考以往类似项目的计划。

注意：使用甘特图排工作计划时，一般只排两周的工作任务，两周到了再排两周，是一个循序渐进的过程。

估计工作量：基于对需求的理解，凭经验并参考相似项目的历史数据。

我们工作中以用例数来量化整个测试工作，包含测试计划、测试设计、测试执行、写报告、总结等所有的工作。

我们在估工作量时，我需求理解完成后，会估计这个需求要写多少条用例，通过用例数再推算工作量。

我们基点是5.6或者5.7条一天。按照用例数估算完成工作量后还要再加20%-30%左右的余量。

测试计划内容：测试目标----测试概要----测试范围----重点事项----质量目标-----资源需求----人员组织-----测试策略------发布提交----测试进度和人员安排-----测试开始/完成/延迟/继续的标准-------风险分析
1、 测试目标：对测试目标进行简要的描述。

2、 测试概要：摘要说明所需测试的软件、名词解释、以及提及所参考的相关文档。

3、 测试范围：测试计划所包含的测试软件需测试的范围和优先级，哪些需要重点测试、哪些无需测试或无法测试或推迟测试。

4、 重点事项：列出需要测试的软件的所有的主要功能和测试重点，这部分应该能和测试案例设计相对应和互相检查。

5、 质量目标：制定测试软件的产品质量目标和软件测试目标。

6、 资源需求：进行测试所需要的软硬件、测试工具、必要的技术资源、培训、文档等。

7、 人员组织：需要多少人进行测试，各自的角色和责任，他们是否需要进行相关的学习和培训，什么时候他们需要开始，并将持续多长时间。

8、 测试策略：制定测试整体策略、所使用的测试技术和方法。

9、 发布提交：在按照测试计划进行测试发布后需要交付的软件产品、测试案例、测试数据及相关文档。

10、 测试进度和任务人员安排：将测试的计划合理的分配到不同的测试人员，并注意先后顺序.如果开发的Release不确定，可以给出测试的时间段.对于长期大型的测试计划，可以使用里程碑来表示进度的变化。

11、 测试开始/完成/延迟/继续的标准：制定测试开始和完成的标准；某些时候，测试计划会因某种原因(过多阻塞性的Bug)而导致延迟，问题解决后测试继续。

12、 风险分析：需要考虑测试计划中可能的风险和解决方法。

3.制定测试方案：主要是：测试点，采用的测试方法和策略，采用的测试工具…..
概述------被测试对象------测试模型-----测试需求---------测试工具-------测试设计-------缺陷跟踪设计管理--
1.概括：描述方案编写的目的、用途、适用的范围、适用的对象

2，被测试对象：测试点（测试项），应测试特性和不被测试的特性（软件的六大特性）

软件的六大特性：功能性、可靠性、易用性、效率、可移植性、可维护性
测试过程中不只要覆盖功能测试，还包括，易用性，兼容性，安全测试，性能测试，GUI 测试，稳定性测试，安装测试，文档测试，异常场景测试等等。

3.测试模型：测试的环境-------测试的类型和策略---------操作流程

测试的环境：测试组的图

测试的类型：功能，性能，兼容等
策略：重点项关注某模块功能，方法和工具（性能用xx工具测试）
操作流程：限制性xx模块再执行xx模块，用例执行顺序（高，中，低））

4.测试需求：环境需求------测试工具需求

环境需求：软硬件，服务端客户端

网络环境：网速，外网，网络安全方面
5.测试设计：工具设计（自研）-------代码设计（自动化脚本，封装函数）--------测试用例设计
测试用例的优先级：

P0	核心功能测试用例（冒烟测试），确定此版本是否可测的测试用例，此部分测试用例如果fail会阻碍大部分其他测试用例的验证。
P1	高优先级测试用例，最常执行以保证功能性是稳定的；基本功能测试，和重要的错误、边界测试
P2	中优先级测试用例，更全面地验证功能的各个方面，异常测试，边界、中断、断网、容错、UI等测试用例
P3	低优先级测试用例，不常常被执行，性能、压力、兼容性、稳定性、安全、可用性等等。

6.缺陷跟踪设计
缺陷状态（生命周期）：发现缺陷-（测试）--------提交缺陷（测试）----------确认（开发/分配对接人）-------修复（开发人员）-------验证（测试）-------关闭（测试）|
提交缺陷：方式 word 、excel、缺陷管理工具（禅道等）--》缺陷报告
缺陷管理工具：bugfree --》禅道

Jira
缺陷的描述：测试环境------ 操作步骤--------期望结果-------实际结果------结果分析

缺陷的严重等级：
（1）致命的（Fatal）。致命的错误，造成系统崩溃、死机，或造成数据丢失、主要功能完全丧失，闪退等。（修复的优先级：立刻解决）
（2）严重的（Critical）。严重错误，指功能模块或特性没有实现，主要功能部分丧失，次要功能全部丧失，或致命的错误声明。（修复的优先级：高优先级）

（3）一般的（Major）。不太严重的错误，如次要功能模块丧失、提示信息不够准确、用户界面差和操作时间长等。（修复的优先级：正常排队）
（4）微小的（Minor）。一些小问题如有个别错别字、文字排版不整齐等，对功能几乎没有影响，软件产品仍可使用。（修复的优先级：低优先级）

缺陷的定义：所有不满足需求或超出/少于需求的缺陷

1.软件没有实现产品说明书要求的功能（少了）
2.软件出现了产品说明书未提及的功能（多了）
3.软件产品要符合说明书的要求
4.软件难以理解，用起来比较困难，运行缓慢
****缺陷的严重程度和优先级有什么关系？
（1）没有任何关系，不要认为严重的缺陷修复优先级就高
（2）碰到优先级和严重程度的也只是偶然
例如：企业的logo错误，不影响任何功能，但是必须优先修复

软件测试阶段的四大活动：设计计划----制定方案----编写测试用例----执行用例（在被测试软件上执行测试用例）

测试计划和方案的区别：
计划核心内容：人员的投入、人员分工、各项任务的时间要求启动、暂停、结束等等的
编写人员：测试经理或者是项目上测试的负责人
方案的核心内容：测试点，采取的测试方法和策略，采用的测试工具
编写人员：资深的测试人员，一般都是多人分工完成
区别：计划在整个测试中起指导作用，计划是从管理的角度出发规范和控制测试活动，方案是从 技术的角度出发规范和控制测试活动。

软件测试四大阶段：单元测试（函数）、集成测试（模块）、系统测试（整个软件）、验收测试（整个软件）
单元测试：也称模块测试，针对软件设计的最小单位
目的：检查每一个程序单元能否正确的实现需求文档的功能，性能，接口，等
发现各模块内部可能存在的各种错误。
集成测试：也称组装测试，是检验程序单元或部件的 接口关系。
逐步集成符合需求文档要求的程序部件或整个系统。

集成测试常见测试方法（集成方法）：

1、大爆炸集成：所有模块一次性集成到一块进行测试。

 优点：测试方法简单，易行。

 缺点：测试不充分 当模块较多时，一次集成会出现大量错误。

2、自顶向下集成：从最顶层模块开始集成，逐步集成底层模块。

     优点：集成较容易，测试和开发可以并行工作，可以较早进行验证。

     缺点：底层验证被推迟，容易测试不充分。

3、自底向上集成：从最底层模块开始集成，逐步集成顶层模块

      好处：可以尽早验证底层模块

      缺点：顶层模块被推迟验证，不能及时发现顶层模块的问题。

4、三明治集成：是一种混合测试策略，综合了自顶向下和自底向上的优点，把系统分成三层：顶层、中间层、底层。

        从顶层和底层同时向中间层集成。

        优势：具有自顶向下和自底向上的优点

        缺点：中间层不能尽早测试。

 大多数集成测试采用三明治集成。

系统测试：全面的针对整个系统进行测试，模拟所有的软件用户的操作，验证软件是否符合需求规格书。

验收测试：是产品检验的最后一个环节，依据需求规格文档对整个系统的测试与评审，决定是否接收或拒收系统。

系统测试分析方法：

三个方法一个思路（质量模型分析法、功能交互分析法、用户使用场景分析法）
一：质量模型分析法：针对每个功能/非功能特性适用质量模型分析法

六大特性：功能性、可靠性、易用性、效率、可移植性、可维护性
1.功能性：
功能性：（保密安全性、适合性、准确性、互操作性、依从性）
保密安全性 ：需要分析被测试软件有没有敏感的数据，有没有需要提高安全性的数据。例如：密码是否是掩码显示，传输的过程中是否加密处理，提醒测试人员关注数据的敏感性，如何才能让软件更安全（传输、存储加密）

适合性 ：需要考虑软件中包含哪些比较合适的功能，写入需求文档中，作为开发和测试的依据关键点： 有没有 （两个角度：需求文档中有，软件中没有；需求文档中没有，软件中有）提醒测试人员关注软件和需求的一致性。

准确性：关键点，对不对
提醒测试人员关注软件的功能实现的是否正确，是否跟文档中描述的功能和实际业务操作的结果是一样的。

互操作性：分析被测试软件与其它软件有没有交互，如果有，就要进行测试。提醒测试人员关注软件和其它软件之间的交互作用。

依从性：主要是法律法规，行业标准，在测试的时候可以暂时不考虑

2.可靠性：
可靠性（成熟性、容错性、可恢复性）
成熟性：内部处理问题的能力 == 》内部代码，长时间稳定性测试

容错性：针对的是抗打击，抗错误的能力（提醒测试人员关注输入错误的情况）

可恢复性：提醒测试人员关注异常情况，例如：闪退，断电等异常情况，再次打开软件是否能快速恢复

对应的软件测试类型：稳定性，功能测试（异常测试）

3.易用性：
易用性（易理解性、易学性、易操作性、吸引性）

易理解性：分析软件中帮助信息，提示信息是否易懂

易学性：是否容易被使用，用起来是否方便，特别是操作手册类

易操作性：操作的时候是否容易，方便，原则：能选择的绝对不能让输入，关注的软件的使用方便

吸引性：提醒测试人员关注软件的界面：布局是否合理，美观，具有吸引性。（GUI测试）

4.效率：
效率（有一定压力）：时间：资源的利用率，对应的是性能测试

5.可移植性：

可移植性（适应性、易安装性、共存性、易替换性）

适应性：提醒测试人员关注软件在使用的情况，在不同的环境下是否正常操作：操作系统，分辨率，浏览器

易安装性：提醒注意安装过程

共存性：分析被测试软件和别的同类型软件是否能够共存

易替换性：升级、重新安装，一定要注意历史数据的校验

6.易维护性：

开发考虑的比较多，关系更大，还要考虑符合法律法规，行业标准，测试，分析是否容易等等。具体测试的时候可以暂不考虑。

小结：质量模型分析法主要是用来提醒测试人员，测试过程中不只要覆盖功能测试，还包括，易用性，兼容性， 安全测试，性能测试，GUI 测试，稳定性测试，安装测试，文档测试，异常场景测试等等

二、功能交互分析法：对质量模型分析法延伸和补充

功能模块和模块之间有交互，有没有影响

前提：模块和模块之间有彼此直接的交互关系：
A -> B； B- > ，A:C之间不是直接交互，不建议使用此方法

依据：需求文档：功能和功能之间的执行顺序，功能和功能之间有依赖关系

实际操作：多个功能同时使用，同时操作。经常会出现的问题：冲突

冲突的情况：资源占用、端口占用

默认常见的处理方式：文件  配置文件：独占

                          数据文件：非独占

设 备：听筒，摄像头，硬盘   独占       端口：独占

分析不同模块之间的优先级，根据优先级高低进行测试用例设计

三、用户使用场景分析法：对质量模型分析法和功能交互分析法的补充

针对整个软件的使用流程考虑

    场景分析法特别适用于业务流程测试，必须要站在用户的使用习惯角度去分析，去测试：

    场景在多数情况下，用户都是为了某些达到特定的目的，将多个功能联合起来使用。例如：登录--》浏览商品 --》加入购物车 --》结算 --》提交订单              # 目的，购买商品

一个思路：单个功能的分析采用质量 模型分析法；多个功能之间采用功能交互分析法，所有功能合并一起采用用户场景分析法。

软件测试的方法：静态测试、动态测试；黑盒测试、白盒测试、灰盒测试；手工测试、自动化测试方法

静态测试：静态检查程序代码、界面、文档中存在错误的过程

不通过软件运行执行测试，主要以代码走查、文档评审为主。

动态测试：通过运行软件执行测试，输入相应的测试数据，检查实际输出结果

黑盒测试：把软件比作封闭的盒子，不关心软件内部代码的具体实现，根据软件对外展示出的功能进行测试。系统测试阶段采用黑盒测试。

白盒测试：把软件比作一个打开的盒子，可以看到软件代码的实现，针对代码的实现验证代码是否存在问题。单元测试阶段采用的测试方法。

灰盒测试：介于白盒和黑盒测试之间，灰盒测试关注输入、输出的正确性，同时也关注内部表现。但是不像白盒测试那样细致。集成测试阶段适用灰盒测试。

阿尔法测试：在公司内由非测试人员进行测试，类似公司内验收（内测）。

贝塔测试：有公司外的人员（部分人员，不是全部用户）进行测试（公测）。

系统测试各大阶段：

1. 计划：编写测试计划

计划编写依据：项目管理计划、开发计划

2、设计：写方案，分析测试需求，分析测试点

编写人员：一般是测试团队分工协作完成。

测试设计工作往往与计划工作并行开展。

设计作用：从技术角度规范和控制测试活动。方案写完需要评审

1. 编写用例（实现）：设计测试用例

用例设计：往往也是测试团队分工完成 。用例编写完成需要评审

1. 执行测试用例

执行前提：编码完成

测试执行准备：

1、准备测试环境：把被测软件搭建部署起来。

涉及工作：安装linux操作系统、安装数据库、安装web服务（apache、tomcat、nginx）、安装依赖软件等

2、准备测试数据：冒烟测试：验证软件基本功能。

系统测试在功能测试正式开展之前执行冒烟测试。冒烟测试时间较短，只验证基础和核心功能是否正常。

转系统测试：测试组内进行评审，判断是否达到系统测试条件，如果达到，则正式通知项目组全体人员，开始执行系统测试。

3、执行测试：

 1、发现bug并提交开发，还要对bug进行跟踪管理：了解bug的原因、解决的方法、解决的时间。开发人员解决bug后测试需要验证bug是否解决，是否引入新问题，需要依据bug的原因及解决方法确定验证的测试范围，确保问题解决的同时没有引入新问题。

 2、工作报告、工作总结：报告分周报、日报、月报。总结内容不限、形式不限、时机不限。

 测试报告：按照实际工作内容总结测试工作的各种情况。

编写人员：测试负责人，往往需要团队成员协助。

 主要内容：测试结论、各种统计数据。

 统计数据作用：测试结论的依据。为后续项目做参考。

通过数据分析研发过程中可能存在的问题，找到原因，制定措施，优化研发流程。

召开发布会议，发布上线

系统测试主要测试类型：功能测试、性能测试、GUI测试、易用性测试、兼容性测试、可靠性测试、安全性测试、文档测试、稳定性测试、健壮性测试、特定场景测试 等等

1、功能测试：规格书实现的功能是否相等或多、少某些（需要从需求和业务角度考虑）

2、性能测试：测试软件匹配性能需求的能力。

性能测试工具：jmeter、loadrunner

（1）响应时间：系统对请求作出响应的时间。

2-5-8原则：如果系统2秒内作出响应，会感觉系统响应很快。

2-5秒内作出响应，会感觉系统响应还可以。

5-8内作出响应，会感觉响应很慢但是还可以接受。

超过8秒还没有响应，会感觉很糟糕，会认为系统已经失去响应，从而发起二次请求或离开改软件。

（2）并发用户数：指系统可以同时承载的正常使用系统功能的用户数量。

（3）吞吐量：系统在单位时间内处理请求的数量

（4）服务器的资源利用率：cpu的使用率、内存的占用率、磁盘的读写速率

app性能测试额外关注指标：

       1、手机端的资源利用情况：cpu、内存的使用率

       2、耗电量

       3、启动速度

       4、界面的滑动、跳转速度

3、GUI测试（界面测试）：关注人机界面展示。

1、整体风格：色彩使用、界面元素排版布局

2、针对具体元素考虑：

（1）单选框：首先考虑是否需要设置默认值。选择一下，只能单选

（2）复选框： 首先考虑是否需要设置默认值。选择一下，可以多选

（3）输入框：首先考虑尺寸大小，考虑输入超过最大限制是否可以继续输入，输入框回显

（4）密码框：首先考虑尺寸大小，考虑输入超过最大限制是否可以继续输入，只能掩码显示，不能支持复制、剪切。

（5）下拉框：首先考虑尺寸大小，关注下拉菜单内的值是否完整、正确。是否需要设置默认值。

（6）超链接：考虑连接的对不对，考虑超链接上的内容与链接到的内容是否一致。

4、易用性测试：关注用户体验

具体体现：能选择不输入、支持快捷键操作、菜单级数不超3级，提供导航式操作，提供帮助手册、提示信息。

最终目标：软件要易理解、易学习、易操作、有吸引性。

5、兼容性测试：指测试软件在不同的软件之间、操作系统平台上、不同的网络环境中是否能很好的运行

主要考虑兼容内容：1、操作系统

           2、应用软件的兼容性：framework、jdk、flash

           3、浏览器兼容性：IE、Firefox、Chrome

           4、分辨率兼容性

               其它：操作系统语言、时区

APP兼容性测试：

安卓：考虑兼容多个安卓版本、考虑兼容不同手机厂商系统、考虑兼容不同屏幕尺寸。

IOS：一般考虑最新IOS版本、一般考虑最新型号的手机，一般往前倒推1-2个版本。

6、可靠性测试：可靠性是指软件不管怎么用都不出问题，或问了问题也能很快解决 

异常测试：测试软件出现异常（故障）后是否可以恢复，以及恢复的程度和时间，往往需要人为制造故障。
7、安全测试：测试系统受到恶意攻击时，系统的自我保护能力，病毒防护能力。

从功能测试角度考虑软件安全性：

           1、密码要有一定长度和复杂度要求

           2、改密码必须验证老密码

           3、是否需要使用HTTPS安全协议。

           4、是否存在超时验证

           5、密码要加密传输、加密存储（sha-one）

           6、是否有防爆力破解机制（连续登陆失败达到一定次数锁定账号或IP）

           7、用户相关数据的校验必须在服务端进行。

8、健壮性测试： 健壮性是指在异常情况下，软件还能正常运行的能力。健壮性有两层含义：一是容错能力，二是恢复能力。

比如一个产品，你怎么折腾它，它都不会坏，或者很难坏，就算坏了也能保护用户数据之类的。

9、稳定性测试：测试系统在一定的负荷下，长时间运行的情况。

负荷：有一定的数据量、有一定的用户量、软件要运行

测试时间单位：N天。    发现问题：内存泄漏

文档测试：测试文档的正确性和可用性。

熟悉软件方法的六个纬度（测试角度）

1.架构：无架构 ---- 例如：单机版  安装，卸载

B/S 浏览器 ---- 兼容性，功能，性能，GUI

 服务器 ---- 环境搭建（大的平台有专人负责部署小的平台，需要提供部署文档）C/S 客户端 ---- 安装，卸载，功能，兼容性，GUI （比如 5年前 qq 和现在 QQ）

服务器 ---- 环境搭建，功能

P2P 端到端：两端是平等的，比如：飞秋 功能

2.功能：软件实现的功能
3.数据：输入的数据：输入的信息，传入的图片文字等等

输出的数据：输出的信息和文件

预置的数据：软件自带的数据（默认值，下拉框选项等等）
4.平台：提醒测试人员关注软件的运行的平台（操作系统，浏览器，分辨率等

5.操作：提醒测试人员关注用户的使用方法

6.时间：提醒测试人员关注软件是否收到时间的限制

例如：时区，跨时区聊天，聊天记录如何显示

夏令时，冬令时：夏季作息时间，冬季作息时间

测试用例设计方法：
1、等价类划分2、边界值分析3、输入域测试法4、状态迁移法

5、流程分析法6、判定表驱动法7、正交试验法8、因果图法

9、错误猜测法10、异常分析法11、场景法

一、等价类划分

等价类划分是把所有可能输入的数据划分为若干等价类。

等价类划分可以分为有效等价类，无效等价类。

二、边界值分析

输入条件规定了值的范围，则应取刚到这个范围的值以及刚刚超越这个范围的值，作为测试输入数据。

边界值分类：

上点：边界上的点（刚刚等于）

离点：离边界值最近的点（一般都是取相差一个单位的点）

内点：在范围内任意取一点

如果是闭区间， [6,18] ,离点肯定是在区间之外  5,19

如果是开区间，（6,18），离点在区间之内，7,17

如果是 [6,18)  ,离点   5,17

总结：闭区间离点在外，向外退一个单位，如果是开区间，向内一个单位

等价类划分和边界值的区别：

1）边界值分析不是从某个等价类中随便挑选一个作为代表，而是这个等价类的每个边界值作为测试条件

2）边界值不仅考虑输入的情况，还要考虑输出的情况，输出的时候会产生空间问题。

三、 输入域测试：在等价类划分，边界值分析的基础上，考虑特殊值的输入和极限值（超大，超多，超长的）输入

建议：准备一些特殊字符串

100个字符，200个，300,500字符串（包含大小写，中英文，全角，半角，特殊字符，空格，数字等等）

四、状态迁移法：业务流程测试使用比较多

使用步骤：

     根据需求提取全部状态  

     绘制状态迁移图

     根据状态迁移图确定迁移路径

     根据迁移图的路径构造测试数据编写测试用例，覆盖迁移路径，一条路径一个测试用例

五、流程分析法：主要是针对业务流程测试使用

前提：非常熟悉被测试对象的业务流程（正常流程，异常流程）

流程分析法使用的步骤：

    1、画出或者读懂流程图

2、确定测试路径

3、针对测试路径编写设计测试用例

流程分类：

    基本流程：按照正确的时间实现的流程

备选流程：经历了波折但是最终达到目的地的流程

异常流程：操作不成功的流程

流程图的作用：提醒，参考，目的是将复杂的业务用简单明了的方式表达。

但是只提醒大的功能点，只关注流程是否能走通，各个环节的细节功能点是不表达。

六、判定表驱动法：判定表是分析和表达多逻辑条件执行不同操作的情况的工具

条件桩：判定表中列出所有的输入

条件项：所有输入取值真假的全排列组合

动作桩：判定表中列出所有可能输出

动作项：每一个条件对应的输出

条件：输入      动作：输出

七、正交实验法（正交分析法）

正交分析法：适用于多条件组合查询测试和兼容性测试

        正交表可以从全排列组合中自动筛选出若干组合

使用步骤：

    1、明确有哪些输入条件需要进行组合（只有一个值的输入可以不需要组合）

    2、选择合适的正交表

    3、正交表为依据，编写测试用例

原理：正交表保证输入中任意两两组合输入的值的全排列，两两测试没问题，进而推导出更复杂的组合测试也问题不大。

正交表与判定表的区别：

判定表法是人工对输入条件进行全排列组合，正交法是实验借助于教学工具，从全排列组合中选出组合组成的正交表。

八、因果图法：适合于描述对于多种条件输入的组合方式（辅助生产判定表的）

优点：在于能发现设计中存在的不足，适合于检查程序输入条件涉及的各种组合情况
缺点：因果图使用的局限性;当原因和结果很多的时候，他们之间的关系连接线就会很多导致因果图的可读性变差。不适用与太多复杂的因果关系。

九、输出域测试分析法

 从输出的 角度看看覆盖等价类，边界值

输出等价类只有有效等价类，原因是：输入和输出并不是一一对应的线性关系

十、错误猜测法：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。

基本思想：列举出程序所有可能的错误和容易发生错误的特殊情况，根据情况选择设计编写测试用例。

错误猜测法主要是一种补充测试用例方法。

十一、异常分析法

针对系统可能存在的异常操作引起软件的故障的分析方法，测试软件在出现异常时容错性和故障恢复的能力

用例设计方法的综合选择：

（1）任何情况下都必须使用等价类划分

（2）涉及数值输入范围等考虑边界值分析

（3）程序功能说明含有输入条件组合情况的可选择判定表法

（4）对于查询、参数配置类软件用正交实验法

（5）不同时期条件的有效性、状态设计不同的测试数据用状态迁移图

（6）对于业务流程清晰的系统，可用场景法贯穿整个过程

（7）错误推测法可追加一些测试用例

其他测试方法：

回归测试：对新版本测试时，重复之前某一个重要版本的所有测试用例

目的：（1）验证之前版本产生的bug已全部修复

（2）确认修复的这些bug没有引发新的bug

冒烟测试：验证一个软件的基本功能是否实现，是否具有可测性

随机测试：基于直觉和经验，测试发现一些边缘性的错误

猴子测试：没有任何的主观意识和想法参与进来，让一些意想不到的操作造成错误的结果。

如何理解软件测试：

软件测试概念：软件测试是一个发现产品缺陷的过程，是贯穿于产品研发的每一个流程，为了提升产品质量的存在，保证产品符合客户需求。

测试目的：测试目的是想以最少的人力，物力和时间找出软件中潜在的各种错误与缺陷，通过修正各种错误和缺陷提高软件质量。

利用测试过程中的结果和信息，为后续研发和测试过程改进提供基础，避免后续重复同样的错误。

因为没有经过测试的软件很难在发布之前知道该软件的质量，软件发布后由于潜在的软件缺陷和错误会造成的隐患以及带来商业风险（损失）。

软件测试过程理念：

• 尽早测试

1. 测试人员早期（软件需求提出）参与软件项目

（2）尽早的开展测试执行计划

• 全面测试

1. 对软件进行全方面测试（需求文档，设计文档，程序代码，相关数据）
2. 软件开发及测试人员（有时包括用户）全面的参与测试中

• 全过程测试

（1）测试人员对测试的全过程进行全程的跟踪

（2）充分关注开发过程

• 独立的迭代测试

1. 测试活动应该是循环往复不断的进行

软件测试的原则：

1. 所有测试标准都是建立在用户需求之上
2. 测试不能保证没有缺陷（测试只是发现缺陷）
3. 软件测试计划是做好软件测试的前提
4. 对测试结果一定要有一个确认的过程
5. 对发现错误较多的程序段，应进行更深入的测试
6. 采用相应的方法去设计测试用例从而提高测试的效率，更多的发现错误，提高程序的可靠性。

在线系统项目介绍：

主要是可用于教育培训机构或个人企业的培训考试的学生在线考试的系统。

分为两个子系统：（前端学生考试系统，后台管理系统）

前端学生考试系统主要流程：
主要是学生登录系统，点击我的考试可查看考试的相关信息并开始考试，考试时可跳跃答题，做完可点击交卷。也可查看所有历史考试信息及成绩，和证书，修改密码等。

后台管理系统主要流程：
管理员（教师）登录后台，可对学生信息的信息进行管理，试题试卷的统计，系统数据修改，信息通知中心，（发布考试信息，时间，什么学科以及人数之内的信息）。
证书管理业务（发证主要是培训机构或企业给学生发证）等操作管理。

我主要负责的3个模块是：用户管理中心、考试管理中心、信息通知中心

用户管理主要是管理学生的信息导入啊，考试管理中心主要是管理考试试卷成绩导入查询等，信息通知中心，发布考试的信息（时间，学科，人数，取消考试，延期…）领取证书

除了管理用户信息试卷发布信息

主要的共同点就是对于信息的一些增删改查功能：

主要用等价类划分、边界值分析、和输入域测试

测试点：
导入文件：（类型，大小（是否有进度条啊）数量，同名，导入后删除源文件，导入后数据库路径（内容），导入后查看文件，文件内容为空，必填字段不填）

删除：（单独删除，批量删除，正确性啊，点击删除里的取消是否正确取消，跳行跳页删除）

修改：修改的班级姓名啊涉及输入框的情况会考虑到边界值，输入域，是否有限制，比如输入字符100.200.300.500的情况

还有就是输入的类型要求：中文，数字，字母，字母+数字啊，比如我不按照要求输入特殊符号，看看如何显示

查询：页面信息显示正确性，导入的学生信息排序是否按照最新的排序，（单独，批量，跳行查询，查询内容导出（信息格式，大小，内容正确）

等去测试设计用例，用例编写用特定的模板就可以了。

每个功能模块编写以后，我们可以从业务流程出发，去考虑是不是覆盖了所有的用例如果没有就进行用例的补充

最后：还需要补充UI界面测试，兼容性测试，性能测试，安全测试等用例，最后用例编写完成后就需要提交评审。