大话软件测试_读书笔记

本文为《大话软件测试》的读书笔记，仅作为本人梳理知识所用，并且只对本人认为的重点进行记录。
本书是以问答的形式来进行软件测试的基础知识普及的，因此感觉相对于之前看的基本纯理论的书来说，更加轻松，但是其中的内容也有一定深度，对于面试可能有一定作用。

第一章，软件需求

关键点
需求不应只由产品经理关注，每一个开发和测试都应该接触。

测试的根本目的是验证需求，围绕需求保证软件质量，BUG（缺陷）是这个过程中的一个产物，不应以找BUG为目标。

1.1需求的含混性

一定要根据客户的具体描述来定义需求；
不能只根据客户的描述来定义需求，只有让他们见到实物才能知道真正的需求是什么。
找到客户的关注点。

1.2用户需求

在业务需求（市场人员主导）的基础上进行用户访谈、调查、整理，从用户角度体现业务价值。
最终将概念化的需求转化为可实现的具体细则，输出PRD产品需求文档（功能要求、开发要求、兼容性要求、性能要求、扩展要求、产品文档要求、外观要求、发布要求、技术支持和培训要求等）注重特性的重点描述。

第二章，PRD审核

PRD是测试执行的源头，需要对每一个标点都需要整个开发团队包括测试进行认真的审核。

2.1PRD分类

2.1.1软件产品定位

a产品背景/定位；潜在客户群；用户问题；特点/特性；产品结构图。

b功能性需求；非功能性需求。

c用户期盼超出能力；非技术因素决定技术选型；预期的使用环境。

2.2软件产品定位a

2.2.1产品背景

背景分析：市场状况、用途、未来增长趋势、竞争能力、需求规模、发展前景。

2.2.2目标潜在客户群

具有购买能力和购买需求。
潜在客户-价值客户-忠实客户

2.2.3用户问题

从问题（单纯的问题）总结需求。
根据客户规模制定需求列表。

2.2.4特性

创新点？优越性？独特价值？相关领域影响？市场同类型的区别？

2.3产品需求

功能性、非功能性、文档、项目需求优先级。

2.3.1功能性需求

特性、安全性、交互性。

2.3.2非功能性需求

性能、易用性、可靠性（故障频率和可恢复性）、可支持性、可移植性。

2.3.3文档需求

用户手册教程等

2.3.4项目优先级

P1强制完成，影响发布
P2对发布很重要
P3重要，但不是一定要

2.4审核PRD

完整性、正确性、一致性。

2.4.1完整性

演绎法、比较法、分解法（主谓宾）、标签法。

2.4.2正确性

明确用户动机（不是WHAT而是WHY）；
表达方式正确。

2.4.3一致性

需求之间不相互矛盾。

2.5范围约束

用户的期盼超出能力；
非技术因素决定技术选型；
预期使用环境限制。
（不要被PM和DEV忽悠）

第三章，用户故事

画面式场景模拟用户行为（用户写或者PM整理，不能涉及专业术语）
用户角色；
某项功能（具体操作）；
客户实现目标/价值。

第四章，审核FS（功能规格书）

4.1含混性

含混性=实现需求最大花费/最小花费，不能过大

4.2交付目标

版本是否清晰

4.4假设和依赖

不能有过多假设和依赖（操作系统、环境、集成包）

4.5功能描述

相对于PRD中更加具体，如安装路径、端口、网段、输入输出等具体步骤。

4.6审核功能描述

需求或特性描述是否准确；
可扩展性；
技术合理性；
集成和升级风险；
理解一致性（主要在数据库、接口、API方面）；
设计一致性

第五章，功能性测试准确性和合适性

5.1功能测试隐含需求

1、隐含需求（行业规则等，如缺少沟通则极易出错）
2、计算机领域规范
3、由于不了解相关技术导致指标错误。

第六章，软件功能测试用户故事

执行者、行为、目标+状态（属性）、方式（接口）、验证点。

6.2数据输入

是否添加中断保存机制
特殊字符（全半角、简繁体、html、JS函数、日文）
带空格字段
数字型边界：输入某些特殊字符和负数时不能崩溃
前后一样的字段数值一致
删除不存在的数据
拷贝数据时不应该全都一样，内嵌属性不应一样

数据库锁机制！

https://blog.csdn.net/C_J33/article/details/79487941

6.2.10一份好的日志

保存成独立的文件；
必须是可以被并行执行的；
起码三级级别；
接口要灵活；
格式统一（最少有时间戳；等级&#x