软件测试技术

1、测试分析与任务分配

测试对象分析：

测试目标定义：确定本次或本轮测试活动预期达到的目标。测试任务是测试目标实现的过程，测试目标是结果。测试目标分隐性和显性的需求，隐性需求需结合自身背景提取。测试目标应尽可能定性或定量评价，如实现覆盖率、性能指标、缺陷修复率、兼容性覆盖率等。
项目背景分析：根据项目背景分析，了解该测试对象属于什么行业，有无相关系统或平台，是否有特殊的业务要求等。通常从产品会议、需求大纲、产品待办事项等相关资料获取。
测试任务识别：根据每个sprint的内容确定，一个sprint包含多少待开发、测试的用户故事或需求类别，由团队评估决定，一旦确定sprint内容，测试任务随之确定。敏捷测试任务，主要包括工作量评估、测试准备、测试执行。
工作量评估：一个sprint，测试时间占开发时间30%-40%。测试工程师参加每日站立会，根据sprint的开发进展，及时更新工作量评估，调整工作状态。
测试准备：根据测试目标、设计测试用例、构造测试数据、开发接口脚本、自动化脚本及性能测试脚本。
测试执行：搭建测试环境、执行测试用例、分析输出测试结果、跟踪处理缺陷等。
测试资源分析：不同的测试任务对应着不同的资源需求。比如测试用例设计时，需参考、应用产品待办列表、需求大纲、用户故事、sprint计划等文档资料。测试环境搭建时，需获取支撑产品的软、硬件资源。
测试风险分析：风险级别取决于发生不确定事件、危险的可能性及产生影响的严重度。测试过程中可能存在的风险来源于3种类型：项目风险、产品风险、外因风险。
- 项目风险：团队组织因素[人员之间的沟通、个人素质、规程]、技术因素[需求调研开发问题、开发技术技能掌握程度、环境资源、低质量的软件需求开发、架构设计、编码及测试设计、测试执行、未完成的数据准备、环境保障等]、供应商。
- 产品风险：产品来源于不特定的用户，无明确需求主体。
- 外因风险：如政府监管、自然灾害等。

测试任务分配：测试任务识别后，测试工程师与团队成员沟通，确定各自的测试任务。一般是由项目经理分配任务。

　　测试工程师任务：熟悉产品需求、分析测试需求、测试用例设计、测试用例执行、缺陷跟踪处理、日报填写等，具体的事务需跟进实际工作确定。

2、软件测试的对象

包括程序、规程、数据和整个软件开发期间各个阶段所产生的文档。如需求规格说明书、概要设计文档、详细设计文档、用户手册等。

　　1、测试分析阶段的主要任务是编写测试计划：包括确定测试的内容和目标、明确测试范围、制定测试策略和用例设计方法、识别风险、安排人力和设备资源，以及估算测试的时间等，测试自己需要经过项目团队的评审。

　　2、测试设计阶段主要利用各种测试用例设计方法编写测试用例，并准备测试数据。设计的测试用例需要经过开发人员、测试人员、项目管理人员、需求分析人员的评审，并达成一致。

　　3、测试执行阶段需要搭建环境，执行测试用例，并跟踪和分析发现的缺陷。

　　4、测试总结阶段分析总结测试的结果、对照质量标准进行质量评估，以及撰写测试报告并给出结论。

3、软件测试分类

3.1 测试方法划分

按测试方法划分，可分为黑盒测试、白盒测试、灰盒测试、静态测试、动态测试、手工测试、自动化测试。

　　1、黑盒测试：功能测试、数据驱动测试或基于需求规格说明书的功能测试，通过测试活动来检查被测对象每个功能能否正常使用，是否满足用户的需求。

黑盒测试方法能更好更真实的从用户角度来检查被测系统界面、功能等方面需求的实现情况，但黑盒测试基于用户需求进行的，无法了解软件设计层面的问题。

黑盒测试重点检查的是被测对象界面、功能、兼容性、易用性等方面的需求。

A)功能不正确或遗漏

如果明确的用户需求，检查此类的错误轻而易举，测试工程师在测试过程中仅需根据详细的用户需求规格说明书一一检查，然而这仅是理想情况，现实测试活动中，明确可靠的用户需求可能仅是一种奢望，这个时侯又该如何进行检查呢？针对没有明确的用户需求的情况，可以从这三方面进行测试：

1.由业务部门提供概要的需求文档；
2.由研发部门提供Function List（功能列表）；
3.根据业务经验判断。

B)界面错误

与功能检查一样，界面错误一般集中在错别字、界面布局等方面，并且缺陷级别通常都定位较低。

C)数据访问性错误

数据访问性错误通常发生在接口上。比如，A系统需调用B系统的某些数据，并设定了定时自动调用数据的功能。

D)性能错误

黑盒测试阶段，可以从业务响应速度、业务并发处理能力、业务成功率、系统资源耗用等方面去衡量。比如，在做B/S结构软件测试的时候，在打开页面的时候，可以明确感知到页面的展示速度，这种感知就是对被测对象响应速度的判断。

E)初始化和终止性错误等

玩过游戏的读者都知道，打开游戏的时候通常都有一段等待时间，游戏会加载一些运行时必须的配置信息，一旦这个过程出问题，即出现了初始化问题，可能导致程序闪退。

所谓终止性错误，指某个应用在出现错误后无法保留当前工作状态，执行其提示的操作后，导致程序崩溃，无法正常工作。

　　2、白盒测试：基于程序代码内部结构的测试。白盒测试中，需要深入考查程序代码的内部结构、逻辑设计等。白盒测试需要具备很深的软件开发功底，精通相应的开发语言。

白盒测试方法主要包括代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法，其中最为常用的方法是代码检查法。

代码检查：包括桌面检查、代码审查和走查等，主要检查代码和设计的一致性，代码对标准的遵循、可读性，代码逻辑表达的正确性，代码结构的合理性等方面；发现违背程序编写标准的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题，包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容。

　　3、灰盒测试：结合黑盒、白盒两种测试方法，一方面考虑程序代码的功能性表现，另一方面，又需要考虑程序代码的内部结构。

　　4、静态测试：就是静态的、不执行被测对象程序代码而寻找缺陷的过程。通俗的讲，静态测试就是用眼睛看，阅读程序代码、文档资料等，与需求规格说明书进行比较，找出程序代码中设计不合理以及文档资料有错误的地方。

一般在通过评审的方式，找出文档资料、程序代码中存在缺陷的地方，并加以修改。

　　5、动态测试：实际的执行被测对象的程序代码，执行事先设计好的测试用例，检查程序代码运行得到的结果与测试用例中设计的预期结果之间是否差异，判定实际结果与预期结果是否一致，从而检验程序的正确性、可靠性和有效性，并分析系统运行效率和健壮性等性能状况。

动态测试有四部分组成：设计测试用例、执行测试用例、分析比较输出结果、输出测试报告。

动态测试有三种主要的方法：黑盒测试、白盒测试以及灰盒测试。

　　6、手工测试：模拟终端用户的业务流程应用软件系统，检查被测对象实际表现与预期结果间的差异，测试工程师手工运行被测对象。

测试工程师设计、执行测试用例，比较实际结果与预期结果，记录两者的差异，最终输出缺陷报告和测试报告。

　　7、自动化测试：利用测试工具，编写代码，模拟用户的业务使用流程，自动运行来查找缺陷。

自动化测试的引入，大大的提高了测试的效率和测试的准确性，而且写出的比较好的测试脚本，还可以在软件生命周期的各个阶段重复使用。

3.2 测试阶段划分

按测试阶段划分，可分为需求测试、单元测试、集成测试、系统测试、用户测试、回归测试。

　　1、需求测试：需求调研完成后，由测试部门或者需求小组进行需求的测试，从需求文档的规范性、正确性等方面检查需求调研阶段生成的文档，测试工程师最好是有经验的需求分析人员，并且得到了需求调研期间形成的DEMO。在许多失败的项目中，70%～85%的返工是由于需求方面的错误所导致的，并且因为需求的缘故而导致大量的返工，造成进度延迟、缺陷的发散，甚至项目的失败，这是一件极其痛苦的事情，所以，在有条件开展需求测试的时候，一定要实施需求测试。

　　2、单元测试:模块测试，就是对程序代码中最小的设计模块单元进行测试。

单元测试是在软件开发过程中进行的最低级别的测试活动。在单元测试活动中，主要采用静态测试与动态测试相结合的办法。首先采用静态的代码走查，检查程序代码中不符合编程规范，存在错误或者遗漏的地方，同时使用代码审查的方法，项目小组检查项目代码，以期发现更多的问题，然后再使用单元测试工具，比如JUnit、TestNG等工具进行程序代码内逻辑结构、函数调用等方面进行测试。单元测试一般可以发现大约80%的软件缺陷。

　　3、集成测试：组装测试，就是将软件产品中各个模块集成组装起来，检查其接口是否存在问题，以及组装后的整体功能、性能表现。

在开展集成测试之前，需进行深入的单元测试。从个体来讲，可能解决了很多的缺陷，但所有的个体组合起来，就可能出现各种各样的问题。1+1<2的问题，此刻尤为突出。集成测试阶段主要解决的是各个软件组成单元代码是否符合开发规范、接口是否存在问题、整体功能有无错误、界面是否符合设计规范、性能是否满足用户需求等问题。

　　4、系统测试:将通过集成测试的软件，部署到某种较为复杂的计算机用户环境进行测试，这里所说的复杂的计算机用户环境，其实就是一般用户的计算机环境。

系统测试的目的在于通过与系统的需求定义作比较，发现软件与系统的定义不符合或与之矛盾的地方。这个阶段主要进行的是安装与卸载测试、兼容性测试、功能确认测试、安全性测试等。

系统测试阶段采用黑盒测试方法，主要考查被测软件的功能与性能表现。如果软件可以按照用户合理地期望的方式来工作的时候，即可认为通过系统测试。

系统测试过程其实也是一种配置检查过程，检查在软件生产过程中是否有遗漏的地方，在系统测试过程中做到查漏补缺，以确保交付的产品符合用户质量要求。

　　5、用户测试：用户确认测试，在系统测试完成后，将会进行用户测试。正式验收前，需要用户对本系统做出一个评价，用户可对交付的系统做测试，并将测试结果反馈回来，进行修改、分析。面向应用的项目，在交付用户正是使用之前需经过一定时间的用户测试。

　　6、回归测试：缺陷修复完成后，需重新执行测试用例，以验证缺陷是否成功修复，并且没有引发新的缺陷。

回归测试可以发现在产品发布前未能发现的问题，比如时钟延迟、软件性能问题等。

4、测试用例

4.1 测试用例属性管理

测试用例常用格式中包括了用例属性、适用阶段、优先级三个通用字段。

用例属性：用以描述测试用例的测试目的。比如功能测试、性能测试、UI测试、接口测试、安全测试、配置测试、运维测试。

适用阶段：软件测试阶段从测试对象来分，可分为单元测试、集成测试、系统测试、验收测试、维护测试等。

优先级：用例优先级，表述测试用例执行的先后顺序，一般分为3个级别：高、中、低。
- 高优先级：覆盖用户频繁使用、系统核心功能、流程验证、风险高的测试点，设计用例时优先级设为高，通常占总用例的20%-30%左右。
- 中优先级：验证功能容错、边界、多平台配置等校验方面的用例，通常占总用例的60%左右。
- 低优先级：验证UI界面、用户满意度等易用性方面的用例，执行频率较低时，可将此类用例设置为低级别，一般占总用例数的10%左右。

4.2 测试用例评审管理

测试用例评审目的：为了确保团队成员对需求的理解保持一致，不存在二义性，减少测试过程中无效用例、无效缺陷的产生。敏捷测试过程中，项目团队所有成员都应该参与用例评审活动，并且时间控制在30分钟左右。

评审时机：评审前，测试工程师应当根据任务分配及时间节点规划完成相关用例设计。

评审步骤：测试用例设计完成，项目经理或测试工程师组织评审会议。

　　　　其常用流程如下：

　　　　A) 项目经理提前2小时与测试工程师确认待评审用例全部完成;

　　　　B) 项目经理通知项目团队成员参加评审会议；

　　　　C) 测试工程师根据测试用例优先级逐条讲解测试用例；

　　　　D) 记录员记录评审过程中出现的问题；

　　　　E) 过程中产生的问题讨论超过3分钟，则项目经理中断讨论，另行处理；

　　　　F) 会议结束后测试工程师确认问题解决工时以及第二次评审会议时间；

　　　　G) 会议结束后记录员整理问题并邮件发送问题；

　　　　H) 问题责任人解决问题；

　　　　I) 测试工程师确认问题修复，发起第二次评审。

4.3 测试用例变更管理

通常引起测试用例更新的原因有如下几点：

　　1)需求变动。产品团队可能在产品开发过程中，提出了新的需求，或者对已经存在的需求提出变更。

　　2)用例完善。可能由于刚开始的考虑不周，后续对需求有了新的认识，认为有必要再添加新的用例来进行测试，增加测试用例的覆盖度，此时也可以进行用例的更新。

　　3)缺陷引起用例更新。测试用例执行过程中，可能发现了一些缺陷，通过最后对缺陷的分析，发现之所以出现这些缺陷，是因为测试用例的设计缺陷造成的。所以，反过来需要重新设计测试用例，避免缺陷的误提。当然，软件版本的更新也可能引起用例的更新。

　　4)设计文档变更。开发工程师设计文档的变更，往往会带来测试用例的变更，比如第三点，如果“商品类别名称”的字段大小改成了“Varchar（100）”，那么对应的用例就应该改为“输入类别名称超过100个字符，进行商品类别添加操作”。

4.4 测试用例设计

测试用例设计的几条基本准则：

　　1）代表性：能够代表各种合理和不合理的、合法的和非法的、边界和越界的以及极限的输入数据、操作和环境配置等。

　　2）可判定性：测试执行结果的正确性是可判定的或可评估的。

　　3）可再现性：对同样的测试用例，系统的执行结果应当是相同的。

常用的测试用例设计方法有等价类、边界值、正交试验、状态迁移、流程分析等。

4.5 用脑图高效地设计测试案例

1.常规测试用例设计遇到的问题

（1）测试用例里面写死了数据和业务步骤。

　　不同测试人员都按照具体步骤来测试，就好比车载导航，变成“导航测试”，如果需要测试其他路径和其他业务时，有些测试人员就再复制一个用例出来，稍微改一个数据，造成用例泛滥。

（2）测试用例依然没有思考的过程。

　　负责第一次编写的测试人员与负责执行的测试人员，没有再继续跟开发有交互测试过程，更没有深入的思考，而是按照用例执行，这种效果等于是走过场。

（3）遇到十几个，甚至几十个步骤的功能，用例编写耗时。

2.脑图的设计模式

　　使用思维导图进行用例设计的实践中，首先需要分离出来两个中心，分别是“需求分析”和“模块用例分析”。

2.1 如何做需求分析

需求分析的思维导图设计思路，基于思维导图的需求分析为：明确需求、继承需求、隐含需求。

明确需求来源：项目开发合同、项目开发计划、系统与子系统设计文档、软件需求规格说明书（含接口需求规格说明）、用户需求说明书、软件设计说明。
继承需求：相关产品或上一版本的软件需求说明书、相关产品或上一版本的测试需求或测试报告、相关产品或上一版本在使用过程中遇到并且需要解决的问题汇总。
隐含需求：有关产品使用场景的梳理数据、该产品相关的行业标准、非专业人士不清楚的特性指标（如六性要求和稳定性要求）。

2.2 模块测试用例分析和设计

模块测试用例分析和设计基本思想：从点到面的思维导图的探索方式。

4.6 几个高效的测试设计方法[软件测试的设计方法]

1 基于业务场景的测试设计

场景：从用户的角度来描述系统的运行行为，反映系统的期望运行方式，由一系列的相关活动组成的。

业务场景：事件触发来控制流程，事件触发时的情景便形成了业务场景，而同一事件不同的触发顺序和处理结果形成事件流。

业务场景的来源：需求，需求描述用户期望的功能，获取用户需求的途径：

与用户直接沟通交流。
从需求规格说明书中获取。
与产品经理进行需求的讨论。
与研发人员一起参与产品设计的评审。
与销售人员的沟通交流。
分析产品老版本或者同类竞争产品。
从售后人员接到的用户投诉进行分析。

业务场景的测试目的：是根据需求、业务分析用户的意图和行为，使设计的业务场景能够贴合用户的实际操作，以此业务场景形成的测试案例能够最大限度地测试出产品是否符合用户需求和行为习惯。

基于业务场景的测试减少了两类主要的错误：

不正确的规格说明，如果做了用户不需要的功能，或者是缺少了用户需要的功能。基于业务场景的测试是从需求出发，测试人员站在用户的角度去使用产品，如果软件的功能不符合需求或者测试场景，那么这个功能就是不正确的。同样功能缺失也是如此，所以基于业务场景的测试能够很大程度上发现软件设计上的问题。
没有考虑子系统间的交互作用。如一个子系统的建立，导致其他子系统的失败。以往的测试方法大多偏重于具体功能的输入和输出情况下的测试验证，对于发现系统级别问题的灵敏度较低，甚至在后期才慢慢发现，严重影响项目进度。

基于业务场景的测试：就是对测试的产品功能或业务流程进行模拟测试，以提高测试效果。

1．创建业务场景的方法创建业务场景常用的方法如下。

理解需求，列出产品中主要的业务流程
列出可能的用户，分析他们的兴趣和目标
考虑恶意用户，他们可能如何攻击你的程序
列出系统事件，系统如何处理这些事件
列出特殊事件，系统如何容纳这些事件
列出收益并创建端到端的任务来检查它们
与用户面谈，找出以前系统中他们最不满意的地方
与用户一起工作，观察他们怎么工作，做什么
阅读类似的系统会做什么
研究对这个系统的以前版本和竞争对手的抱怨
创建一个模拟业务，认真对待这个模拟业务并处理相关的数据
试着把竞争对手和以前版本的真实数据转换到新的系统

2．创建业务场景的原则

设计一个好的业务场景应遵循以下原则

独立性。要尽可能地让一个业务场景独立于其他的场景。业务场景之间的依赖使得制订计划、确定优先级、估算工作量都变得很困难。通常我们可以通过组合场景和分解场景来减少依赖性。
可协商。一个业务场景的内容要是可以协商的，业务场景不是合同。一个业务场景只是对场景的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个场景描述如果带有太多的细节，实际上会限制和用户的沟通。
有价值。每个业务场景都必须对用户具有价值（无论是用户还是购买方）。一个让业务场景有价值的好方法是让用户来写下它们。一旦一个用户意识到这是一个业务场景并不是一个契约，而且可以进行协商的时候，他们将非常乐意写下来。
可以估算。开发团队需要去估计一个业务场景，以便确定优先级与工作量和安排计划。但是让开发者难以估计场景的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者业务太大了（这时需要把业务进行分解）。
短小。一个好的业务场景在工作量上要尽量短小。业务场景越小则设计业务场景和测试执行时也越简便；业务场景越大，在安排计划、工作量估算等方面的风险就会越大。
可测试。一个业务场景是可以测试的，以便于确认它是可以完成的。如果一个业务场景不能够测试，那么就无法知道它什么时候可以完成。一个不可测试的业务场景例子：软件应该是易于使用的。

理解场景分析法与基于业务场景的测试设计的异同：

本质上的不同：场景分析法是一种测试方法；基于业务场景的测试设计是一种测试设计思路[主要使用的方法有：等价类划分法、边界值分析法、因果图法、场景分析法]。
对象的差异：场景分析法面对的是具体的功能，对测试过程的每一步具有严格的限定；基于业务场景的测试设计面向产品的需求，通过需求来确定业务场景。
设计上的不同：场景分析法从具体功能的角度进行分析，设定功能测试的基本流和备选流，每一步都是明确的；基于业务场景的测试设计则从业务需求的角度出发，保证业务场景能够覆盖需求即可，满足用户的业务要求。
测试覆盖程度不同：场景分析法对测试的功能需要设计足够多的用例进行测试覆盖，覆盖率较高；基于业务场景的测试设计通过对用户业务进行优先级别排序，选取用户主要的业务需求（符合二八法则，即 20%的功能项满足用户 80%的业务需求），重点设计满足用户 80%业务需求所对应的功能。剩余80%的功能项（可能只满足用户20%的需求）可以采用其他的测试方法进行补充测试，以此来提高效率的同时提高测试覆盖率。

场景分析法：测试方法，一般把场景分为基本和备选流。从一个流程开始，通过描述经过的路径来确定业务过程，经过遍历所有的基本流和备选流来完成整个场景。基本流和备选流往往是产品被同一事件的不同触发顺序和处理结果而形成的事件流，事件触发时的情景便形成了场景。通过描述事件的不同触发情景，能够更好地使测试人员理解场景，并设计出适合的测试用例，使测试用例更容易被理解和执行。

基于业务场景的测试设计：测试设计思路，可以适用于任何产品，对于被测试系统耦合度较高、业务流程或事件比较复杂的产品，往往能够提高测试的效率。

基于业务场景测试的优缺点：

优点：

通过分析需求，从需求出发，站在用户的角度进行测试，使测试具有很强的实用性。
从整个系统的角度体现数据的流向及紧密的业务流程关系，能够比较真实地模拟用户实际使用业务的情况，测试系统是否“流程走得顺，数据流得通”。
通过运用业务场景来描述系统的功能点或业务流程，使业务场景贯穿于整个产品功能，易于发现各功能模块之间接数据和业务流向的问题，从而提高测试的有效性。
学习产品。如果想要设计出符合需求的和用户逻辑的场景，需仔细理解需求说明书或直接与用户沟通，分析产品的功能和想要达成的效果。通过学习还可以更好地分辩产品的问题，为业务场景设计和测试提供材料。
将需求文档和测试联系起来。需求文档是测试设计的主要依据，业务场景设计同样也不例外并且尤为重要。
暴露产品的设计缺陷。业务场景的设计依赖于需求文档和用户沟通等，对产品整体业务流程进行测试，通过业务场景测试可以充分暴露出产品的设计问题。
探索产品的专业用法。产品设计完成后，第一批用户就是测试人员，测试人员根据业务场景进行测试，对产品的使用进行记录，为编写用户操作手册积累素材。

使用业务场景测试的缺点如下：

缺点：

在早期不稳定的代码上，业务场景测试的效果不如其他方式，因为用户场景比较庞大，业务场景测试比较复杂，包含许多特性，一旦某个特性出错或没有实现，就会阻碍测试的进行。
基于业务场景的测试主要对用户的业务需求进行测试设计，而满足用户 80%业务需求相对应的功能可能仅占全部功能的 20%，导致无法全面覆盖产品功能。
业务场景测试经常发现的是设计问题，而不是代码问题，代码问题更适合由其他的测试来发现。

2 基于风险的测试设计[以产品质量风险作为测试的出发点和测试活动的主要参考依据]

基于风险的测试设计：测试人员根据不同的风险度（通过出错的严重程度和出现的概率计算）来决定测试的优先级和测试的的覆盖范围。通过基于风险的测试来降低产品质量风险和项目风险是一种测试设计思路，按照该思路进行测试设计能够很大程度上提升产品的质量和项目成员的信心。

风险：可能存在的问题或有可能发生的事件。也就是说：在某一特定环境下，在某一特定时间段内，某种损失产生的不可预料的后果。风险是潜在的，只有具备了一定条件才可能发生，但是也不一定成为现实，还需达到一定的触发条件，风险才能真正产生。

风险具备的 4 种特性：不确定性、有害性、客观性和无形性。

风险与测试之间的关系：在实际的软件测试过程中，二八法则可能更符合风险和测试之间的关系：测试对象80%的风险来自于20%的功能。

基于风险的测试设计：根据风险分析结果，优化测试方法、测试资源和测试顺序，更好地利用测试资源（时间、环境和人）获得最佳的测试效果。

基于风险的测试设计的目的：为测试提供指导，发现测试过程中的风险并进行分析、预防和转移。

基于风险的测试设计的特点：将产品潜在风险的严重程度作为测试安排的依据和目标，针对业务功能潜在的风险，安排适当的测试方案、资源和测试周期，就可以有效地发现更多的系统缺陷，将测试从被动变为主动，提高测试效率、降低产品的质量风险。

基于风险的测试设计的意义如下：

通过识别、评估和防控风险使产品质量提高
将基于风险测试设计并结合其他测试方法提高测试覆盖率
可以快速提升对产品质量的信心

常见的风险：

测试时间的风险(项目具体里程碑时间、客户或者用户要求产品提交的时间)
测试过程的风险(包括测试文档的编写和评审、测试的执行、测试场景的缺失以及测试平台和测试工具选择不当)
- 测试计划或方案设计有误：测试计划设计不能指导整个测试过程，测试方案没有正确采用测试方法和技术，或者某些测试方法被忽视掉，如边界测试、错误推测法、判定表驱动法和正交试验法等，从而导致测试不充分。
- 测试用例设计问题：因对需求没有进行完整的测试分析，导致测试用例设计不能完整覆盖需求；因测试方法使用不当或方法缺失导致测试用例不完整；设计测试用例的预期结果存在歧义。
- 测试用例执行风险：因测试进度原因或是回归测试原因导致测试用例执行不充分。
- 场景缺失或部分缺失：因关注点主要放在功能测试上而导致忽略了业务场景测试，或是导致部分业务场景的缺失。
- 测试数据准备不充分：测试过程中测试数据准备不完整，或是测试数据没有依照业务流程进行准备而导致测试数据不准确。
- 工具的风险：测试工具有许多种，测试人员对测试工具选择不当，会给产品带来难以预知的风险。
- 研发人员修复缺陷带来的风险。
- 潜在未测试的区域的风险。
资源的风险
- 人员风险—测试人员的风险。
- 资料的风险
  - 文档缺失：部分测试文档不完善。如缺少原始需求、测试计划、测试方案、测试用例以及项目后期的验收大纲等，导致测试覆盖率较低、测试不全面、测试杂乱无序。
  - 需求发生变更：需求变更在产品生命周期中较频繁，将会影响到整个测试，甚至重新制订测试计划和设计测试用例。
  - 设计不充分（计划、方案、用例和测试数据）：由于设计文档人员的个人原因或是时间限制等方面的原因导致输入测试的文档设计得不充分、不完整，遗漏了一些重要内容，造成测试不全面，覆盖率低。
  - 质量标准不统一：由于文档和测试过程中的质量标准没有统一的标准，导致测试人员和开发人员认识不同。
  - 文档质量问题：输入测试的文档内容含糊、表述不清以及内容不完整，都将影响测试质量和初期测试设计质量。
- 环境的风险—测试环境的风险
  - 产品对硬件平台、操作系统、网络环境和测试数据具有很强的依赖性，在测试进行环境风险分析时，我们要分析仿真环境、交叉测试环境和测试环境，甚至包括生产环境的风险。
  - 测试环境问题：测试环境所需要的硬件设施未及时到位，使用的测试硬件环境不满足用户需求、产品需求或者项目需求，使用的软件环境如操作系统类型、操作系统干净程度等不满足要求，导致测试环境配置错误、测试准确性低。
  - 兼容性问题：测试环境中软硬件不兼容。
  - 测试程序版本不一致：程序版本导致测试不准确，由多种原因造成，包括开发人员没有提交最新程序版本和测试环境没有及时更新到最新的程序版本等问题。

基于风险的测试包括3个主要活动：

风险识别：找出项目和质量的风险[主要从弱点识别、威胁识别以及已有控制措施识别等方面进行风险的影响和可能性分析，确定风险的结果，并确定产品各业务系统所需要的防护级别。]
风险评估：基于可能性和影响逐项评估[对内部和外部风险进行分析确认和衡量]
风险防控：测试执行等活动发现风险并控制影响

常见风险识别的方法如下：

风险检查表：建立在以前开发类似的项目中曾经遇到的风险基础上，比如开发时利用了某种技术，那么有过这种技术开发经验的个人或者项目组，就能指出他们在利用这种技术时遇到过的问题。常见的风险列表。
头脑风暴会议：围绕项目中有可能会出现哪些范围、进度、成本和质量方面的问题这一议题展开，讨论并列举出项目可能出现的风险。
项目人员面谈：通过召开项目会议，分析出每个阶段存在的风险。
经验教训：项目结束时，召开项目总结会议，对测试过程中遇到的风险进行汇总，为下一项目提供参考。
问卷调查：根据以前项目经验，列出整个过程中的问题，包括文档的编写和人员的技能是否达到要求，测试之前测试环境是否准备完毕。

风险评估是在风险识别的基础上，对识别的风险进行评估。评估主要从下面几个方面入手：

风险概率分析，即对风险发生的可能性设置一个衡量尺度，如很高、较高、中等、较低以及很低。
风险影响的严重程度分析，即对风险发生后产生的影响严重程度进行评估，严重程度可划分为很大、较大、中等、较小和很小几个级别。
确定风险评估的正确性，要对每个风险的表现、范围和时间做出尽量准确的判断。
根据损失（影响）和风险概率的乘积来确定风险的优先级别，定制风险应对措施。

常用的风险控制策略:

风险避免。[在项目开始前，把一些环节或边界上的可能会有变化以及难以控制的因素列入风险管理计划中；比如确定采用的测试技术和方法；确定测试范围；确定测试用例的优先级，测试资源的分配。我们还可以对软件生命周期的所有过程进行日常跟踪，及时发现影响测试风险的各种征兆，采取适当措施避免风险。]
风险弱化。将风险事件的概率或结果降低到一个可以接受的程度。例如，制定文档标准或模板，并建立相应可行的管理机制和变更措施，以保证文档及时产生和适时变更。制定测试流程，在日常测试工作时，严格按照测试流程执行，避免盲目性测试。对测试生命周期中的必要工作进行评审，以便能够及时发现问题并解决问题，包括对不同的测试人员在不同的测试模块上相互调换。
风险承担。通过资源、时间和成本的控制进行风险承担，如：做资源、时间和成本等估算时，要留有一定余地，不要过度饱和。对每个关键的测试工程师培养后备人员，做好测试人员流动的准备，采取适当措施确保当人员产生变动时，其所在项目的测试工作不会受到严重影响，仍然可以正常有序地开展。

风险控制策略的选择：

1）测试时间进度风险控制：该风险触发时，可采取与客户协商的方式，顺延交付产品或者推迟交付已有的低优先级的功能和特性，或采取降低对低优先级的功能或特性的测试要求。
2）测试方法：测试负责人需要有良好的测试技术基础和一定的实践经验，能很好地把控测试计划和测试策略；能够对测试人员进行测试技能培训；能够从根本上解决测试方法问题。
3）需求变更：适时对需求变更进行跟踪，并及时同项目经理、产品经理和研发人员进行沟通，以确认最新的需求并适当调整测试。
4）测试质量保证：依照测试生命周期过程，对每个阶段输出的资料都要进行相关评审，对整个过程进行监控。
5）测试用例与数据设计不充分：尽可能地让测试经验丰富的人员设计，以保证测试用例和数据的充分性，如测试负责人或测试专家。
6）测试环境：在测试环境配置前，对所有相关的环境检查进行列表核对，在测试环境配置完毕后，由指定人员按已列出的环境检查内容逐一检查。

3 基于任务驱动的测试[以任务驱动为导向的测试]

任务：交派的工作或担负的职责与责任。

测试任务：为完成某个测试流程所执行的活动。一个测试项目可以分成多个任务，每个任务是一个逻辑执行单元，不可再分。

任务驱动测试：整个测试项目以通过执行测试任务的方式来达成。在完成所有任务测试后，即完成了测试项目。

通过任务的形式约束测试，提高测试效率。
降低研发、测试成本和周期。
尽快确认和保障产品质量。

基于任务驱动的测试设计具有以下特点：

以任务为导向，测试目的和范围明确。
具有明确的输入条件和数据，测试内容清晰。
严格依据测试结果判定测试是否通过。

基于任务驱动的测试模式：第三方测评、外包测试、OEM 测试和自动化测试。

第三方测试：

第三方测评受客户委托申请验证产品的质量并出具测试报告，以达到客户评判、验收产品获取相应认证报告的目的。

第三方测评有别于软件厂商自己进行的测试，其目的是为了保证测试工作的客观公正性以及相关资质和能力的证明。第三方测评主要包括需求分析审查、设计审查、代码审查、单元测试、功能测试、性能测试、可恢复性测试、资源消耗测试、并发测试、健壮性测试、安全测试、安装配置测试、可移植性测试、文档测试、验收测试和资质能力认证等。对于通过测试的产品出具测评报告或证明，以说明产品具有相应的资质或能力。测评是软件测试的一个阶段性结论，用所生成的测评报告来确定测试是否达到完全和成功的标准。

外包测试：

　　软件外包测试是指软件企业将软件开发项目中的全部或部分测试工作，外包给专门公司或组织完成。由于不同企业或不同软件项目的特殊性，会选择不同程度或模式的外包策略。测试外包的模式分为现场测试、外部测试和分布式测试。

OEM 测试：

　　OEM 测试是一个过程，是一个以合同为依据的测试。OEM 测试一般是在乙方的产品完成开发并完成内部测试后，提交给甲方进行测试验收，验收产品是否与合同约定的一致。

自动化测试：

　　自动化测试根据测试任务选择不同的软硬件资源，将手工测试的测试用例和测试结果，转化为自动化执行和结果判定的运行程序。可以看出，基于任务驱动的测试都是具有明确的输入与输出来作为判定条件，不要求测试者有过多的测试思路扩散。第三方测评需要根据测评规范和方案对产品进行测试评估，依据测试结果对产品进行合格性判断；外包测试则是由外包合同对测试项目的具体内容进行详细的说明，并依据合同中的测试内容进行测试执行和结果判定；OEM 测试则由依据技术合同等方案设计OEM验收方案，依据方案对产品进行测试和结果判断；自动化测试依据手工测试的用例和结果进行自动化测试平台的搭建，把测试用例和数据作为输入，并依据预期测试结果对自动化测试结果进行判断。

基于任务驱动的测试以任务驱动为导向，可以实现以下目的：

通过任务的形式约束测试，提高测试效率。
降低研发、测试成本和周期。
尽快确认和保障产品质量。

基于任务驱动的测试设计的特点：

以任务为导向，测试目的和范围明确
具有明确的输入条件和数据，测试内容清晰
严格依据测试结果判定测试是否通过

基于任务驱动的测试设计的优缺点:

优点：

测试公平公正且专业透明
节约成本
权威性
严格的文档审查

缺点：

测试可能不全面或测试深度不够
沟通不畅会影响测试进度
需要增加保密成本

如何进行基于任务驱动的测试：

1．明确约束条件和目的
2．测试任务的划分
3．测试实施
4．测试结果的判定

测试任务的把控：

1．测试内容[测试内容是基于任务驱动测试的关键，任务可以是功能测试、性能测试、本地化测试、兼容性测试、硬件测试和安全性测试等]
2．沟通交流[明确沟通方式和方法]
3．过程控制[基于任务驱动测试的监管团队一定要具备技术、管理和商业社交的能力]

5、软件测试发展路线

6、软件测试里程碑

定义自己所需的阶段，或里程碑。简单举例显示主要的里程碑有：

产品需求文档（PRD）或市场需求文档（MRD）的评审和签发；
产品规格说明书（Spec）的评审和签发；
测试计划、测试计划书的评审和签发；
测试用例的设计、评审和签发；
功能测试；
系统测试；
验收测试。

posted @ 2020-02-29 17:32 wendyw 阅读(1826) 评论(0) 编辑收藏举报

刷新页面返回顶部

折翼の翅膀