软件测试对象分析

软件测试对象分析

测试目标定义

测试目标定义，确定本次或本轮测试活动期望达成的目标，与测试任务不同，测试任务是具体的事务，测试目标是结果，测试任务是测试目标定义的实现过程。

以ECShop项目为例，测试目标是通过实施功能、安全、兼容性、接口及性能测试，验证每个Sprint中的业务是否已满足产品需求中定义的功能、安全、UI、兼容性、性能等需求。

测试目标定义需结合用户显性及隐性需求，显性需求通常在产品需求或用户故事中已明确定义，隐性需求则由测试工程师根据自身技术、项目经验结合软件背景、用户背景、运营背景等因素综合考虑分析提取。

测试目标定义后，即可根据测试目标识别测试任务，确定测试范围后，测试目标应尽可能定量或定性评价，如功能实现覆盖率、性能指标、缺陷修复率、兼容性覆盖率等。

项目背景分析

所有产品或项目研发都有初期设计背景，通过对项目背景分析，测试工程师可了解该测试对象属于什么行业，有无相关系统或平台，是否有特殊的业务要求等。

例如，为设计给老人使用的手机，应尽可能将字体放大、声音放大、增大电池容量、减少充电次数。

不同行业可能具有一些符合自身行业特性的需求，如金融行业，除了功能之外更关注数据安全性及性能，政府企业对外业务系统，与功能相比，更为关注安全性，而App则侧重于用户交互。

了解产品或项目所属行业，有利于测试工程师采用针对特定行业的测试方法或经验，从而提高测试效率及质量。

针对一个全新的产品或项目，可能没有与之耦合的系统或平台，但如果是升级软件或衍生系统，则需分析与之耦合的业务系统是否存在交互接口，如果存在，则设计测试策略时需考虑接口测试方法。

测试工程师实施测试对象背景分析时，通常从产品会议、需求大纲、产品待办事项列表等相关资料获取。

测试任务识别

测试目标定义后，需将目标分解，识别具体测试任务。敏捷测试与传统软件测试双V模型有所区别，敏捷测试中测试工程师的任务通常由敏捷开发团队根据每个Sprint的内容确定，一个Sprint包含多少待开发、测试的用户故事或需求列表，由团队评估决定，一旦确定Sprint内容，测试任务随之确定。

Scrum开发模型中，产品需求演变为用户故事有着明确的要求，表述用户故事时，不能从开发者的角度考虑，不允许使用技术类的术语表述需求，这点避免了需求脱离实际用户场景。

但作为测试工程师，测试实施时不仅仅从用户角度考虑，还需考虑产品的整体设计，除了功能性、易用性之外，还可能考虑产品的移植性、效率等特性，因此测试工程师必须深入了解被测对象的应用场景、用户需求。

敏捷测试任务，主要包括工作量预估、测试准备、测试执行等几个方面。

工作量预估

根据经验，一个Sprint中，测试时间通常占开发时间的30%-40%左右，因此，测试工程师估算测试时间时，应当先了解开发时间是多少，然后根据开发时间及任务节点，规划测试时每项工作的工作量，然后以列表形式记录。

测试工程师参加每日站会后，根据Sprint的开发进展，及时更新工作量预估，有问题及时调整。

测试准备

测试活动执行前，测试工程师需根据测试目标，设计测试用例(如果需要)、构造测试数据、开发接口脚本、自动化脚本及性能测试脚本。

测试用例设计，一般可根据用户故事的粒度及敏捷开发团队要求决定，如果用户故事编写相对细化，可明确验证功能，则无须编写测试用例，直接以用户故事作为测试依据。

如果用户故事仅列出了用户的期望，存在较多校验性的功能，则需利用等价类、边界值、正交试验、状态迁移等方法进行用例设计，便于后续的测试执行活动。

测试过程中可能需要大量的数据，尤其是测试流程性业务时，测试工程师需确定构造数据的方法以及脚本。例如测试环境搭建时，可利用sql语句恢复测试数据、利用一些批量生成身份证号码的软件，模拟身份证信息等。

敏捷测试很多时候要求将测试执行过程自动化，比如接口测试，此时需编写自动化测试脚本，要求测试工程师具有编程能力及使用工具的能力。

性能测试与自动化测试相同，都需要进行测试脚本的开发与优化。

测试执行

测试执行阶段，测试工程师需搭建测试环境、执行测试用例、分析输出测试结果、跟踪处理缺陷等。

测试环境搭建，如果很复杂，可能由开发工程师搭建，但笔者建议测试工程师自己搭建，这样便于了解更深层面的架构情况。

测试环境搭建工作需掌握较多的知识，测试任务识别环节，测试工程师应当向开发工程师明确产品的运行环境，然后准备相关资源。如果自己不具有环境搭建的知识，则需提前学习。

除产品的测试环境外，可能还需要测试管理环境，如测试用例管理、缺陷管理等，一般会选择一个较为全面的管理工具，如ALM或禅道。

测试执行时所发现的问题可及时记录，便于后期的缺陷跟踪。