《测试架构师修炼之道》读书笔记

前话

　　说实话，看完这本书花的时间不多，这本书更多的是讲概念策略方面的内容（而且个人觉得整个策略太过繁杂，特别是用例选择方面，在敏捷流程下不太可行，只能摘取其中有用的部分），而不是技术方面的内容，所以不感兴趣的部分就没有花太多时间研读，更多的是想给自己一个启蒙。作为一个工作在一线的测试人员，希望从更多的角度来看这个行业，也为自己的职业发展道路增加多一点可能性。

 

笔记

笔记一：“测试六段”

其实也是一般大公司给技术人员定级的标准，希望不管是开发还是测试，都可以精进自己的技术之路，扩大自身影响力。

测试一段：能根据测试用例的描述步骤来执行测试用例，能对照用例的预期结果发现产品的问题，能够清晰准确地将问题记录下来后反馈给开发，开发能够读懂问题描述的含义；

测试二段：对产品需求有一定的了解，能够根据产品需求分析、设计产品的测试用例，发现问题后能够进行初步定位；

测试三段：对产品的需求和实现都有较为深入的理解，设计用例时会注意用例的有效性，测试用例时会考虑使用自动化测试等方法提升测试执行的效率；

测试四段：深入理解产品需求和实现，理解产品质量，理解产品的隐形需求，对产品性能、可靠性、易用性等非功能属性的测试均有所涉及，并掌握其中的测试方法，会使用测试缺陷分析技术，会评估产品质量；

测试五段：不断追求最适合产品的测试技术，关注测试过程改进，推动产品测试技术的进步；

测试六段：走向前端，做缺陷预防，能将测试方法标准化，并固化为测试工具和流程。

 

笔记二：对于测试策略的选择

“平台性的产品”（不会直接发布给用户）和“会发布给用户的产品”使用的测试策略是不一样的

“快速开发的产品”和“战略性产品”的测试策略也是不一样的

“继承性的产品”和“全新开发的产品”的测试策略又是不一样的

 

笔记三：测试相关概念

测试分析不仅能够帮助测试更好地认识产品，准备测试，还能反过来帮助开发确认需求，确认产品在非功能属性（如性能，可靠性，易用性等）方面的设计。测试的意义，不仅在于测试发现bug，为产品发布提供信心，还在于缺陷预防，切实提升产品质量

测试策略解决的是产品“测试目标”（why）以及“测什么”（what）和“怎么测”（how）的问题

测试计划是在明确了“目标”，“测什么”和“怎么测”后，确定由“谁”（who）在“何时”（when）花费多长时间来进行相关的测试

 

笔记四：软件产品质量六属性

1 功能性：包含适合性，准确性，互操作性，安全性

2 可靠性：成熟性，容错性，可恢复性

3 易用性：易理解性，易学性，易操作性，吸引性

4 效率：时间特性，资源利用率

5 可维护性：可分析性，可修改性，稳定性，可测试性

6 可移植性：适应性，可安装性，共存性，易替换性

 

笔记五：可靠性的三层递进要求

第一层：设备最好不要出故障

第二层：设备出现故障了不要影响主要的功能和业务

第三层：如果影响了主要功能和业务，系统可以尽快定位并恢复

 

笔记六：参数类的测试点和数据类的测试点

1 参数类的测试点有两个重要的特点：

第一，”参数值“的个数是有限的，可以通过遍历的方式来测试覆盖到

第二，系统会对不同的”参数值“作出不同的处理或响应

2 数据类的特点是：

第一，数据的取值是一个范围，通常不能用遍历的方式来测试覆盖

第二，系统对允许输入的”数据“作出的处理或响应往往是一样的

 

笔记七：四步测试策略制定法

step1：明确“产品质量目标”

step2：进行“风险分析”

step3：适配“产品开发流程”

step4：进行“测试分层”

 

笔记八：产品质量评估模型

1 多维度：能够覆盖质量评估的多个维度，能够帮助评估者全面分析和考虑

2 定量和定性：指标和分析相结合，能够有效避免在只有指标的情况下，被“绕”过去，变得形同虚设

3 过程+结果：不仅评估测试的结果，还对过程进行分析和评估

 

笔记九：测试过程分析

1 测试用例执行率

2 测试用例执行通过率：包含测试用例首次执行通过率，测试用例累计执行通过率

3 测试用例和非测试用例发现缺陷比

我们希望“通过测试用例发现的缺陷”和“发散测试，也就是非测试用例发现的缺陷”的比值能够在一个合理的范围内

如果发散测试发现的缺陷较多，就需要对这些缺陷的原因进行分析

比如产品实现细节未考虑此测试点，功能交互方面未考虑此测试点，边界值或异常分支未考虑此测试点，测试场景未考虑此测试点······

 

笔记十：缺陷分析

1 缺陷密度

2 缺陷修复率

3 缺陷趋势分析

数学中对曲线趋势进行分析时，会用到“凹凸性”和“拐点”的概念。

拥有凹函数特性的曲线，呈现出递增的变化趋势

拥有凸函数特性的曲线，呈现出递减的变化趋势

拐点就是凹函数和凸函数中间的连接点，即函数的变化趋势出现改变的点

1）理想的“累计发现的缺陷趋势”曲线

在一个新的测试阶段开始的时候，希望“累计发现的缺陷趋势”为凹函数，说明测试团队每天能够发现的缺陷数目呈现越来越多的趋势，当前的测试策略（测试人力投入，测试方法等）能够有效发现产品的缺陷，并且未来还可能发现大量缺陷

在测试策略不变的情况下，测试一段时间后，出现“拐点”，说明当前的测试方法已经不能有效去除系统的缺陷，当前的测试可以按照计划结束，进入下一阶段的测试

2）“累计发现的缺陷趋势”的“拐点”出现得过早

“拐点”的出现，意味着测试团队在这个测试阶段里已经无法有效发现产品的缺陷

可能的原因：测试团队的投入发生了变化，且影响了测试；测试发生了阻塞，无法有效开展测试活动；测试策略不当，已经发现不了产品的缺陷

3）“累计发现的缺陷趋势”的拐点未出现

说明在这个测试阶段里，测试团队仍然可以发现产品大量的问题

可能的原因：测试团队未按照测试策略进行测试，可能使用了更多/更复杂的方法来发现缺陷；版本质量太差，缺陷密度高于预期

4）缺陷是否收敛

判断缺陷趋势是否收敛时，需要具备以下两个条件

“累计发现的缺陷趋势”为凸函数

“累计发现的缺陷趋势”和“累计解决的缺陷趋势”两条曲线越来越靠近，最后逐渐趋于一点

 

笔记十一：差异性分析沟通提纲示例

1 和之前相比，产品的“底层”或一些“公共模块”是否有修改？为什么要进行修改？修改的代码量有多大？据你所知，这些修改会影响哪些功能？

2 和之前相比，“**功能”是否进行了功能/性能/可靠性/可维护性/易用性/可移植性/可维护性方面的优化？为什么要进行优化？修改的代码量有多大？这些修改会影响其他功能吗？

3 和之前相比，和“**功能”相关的开源代码是否进行了版本升级？

4 和之前相比，“**功能”的流程是否有所变化？变化是有哪些？

5 和之前相比，新版本在资源分配（如内存/CPU的分配）上有什么不同，是否会对“**功能”造成影响？

6 针对修改，你（开发）准备做哪些自测（或已经做了哪些自测）？

7 有没有我（测试）需要特别关注的地方？

 

笔记十二：测试执行顺序

如果有两种测试方法，都对测试对象进行测试，先进行复杂的，再进行简单的。或者说，尽量先执行复杂的，难的用例，再进行简单的测试用例。这样考虑的原因是，希望缺陷能够在测试的前期发现

 

笔记十三：冒烟测试

在开发人员将版本转给测试人员时，测试人员先对这个版本进行一次测试，确认版本没有阻塞测试的问题，能够按照测试策略完成测试。这是如果测试不通过，可以考虑是否有规避问题的方法，如果有，考虑到修改缺陷，制作版本，开发自测，冒烟测试的成本，建议继续测试。