<<软件测试实战>>读书笔记

软件测试基础

1. 软件的复杂度已经超越了人的理解能力

    1. 虽然高抽象的层次语言，程序框架，程序库等提高了人的生产力，但是还是需要开发者深入理解细节，可以减少开发时间，但是无法减少开发者学习整个技术栈的时间
    2. 对于复杂的软件，如果测试人员不能掌握全部的信息，那么他的测试策略已经会错误(对于开发也是如此)，所以需要和各个工作岗位的人进行协作
    3. 软件复杂，所以测试用例需要进行迭代，持续地评估和反思
    4. 大规模的软件中,对于少量代码的变更都不能掉以轻心
    5. 单凭人的脑力已经很难应对复杂的软件测试了，测试人员需要考虑测试自动化来对付这种情况
   

2. 测试步骤

    1. 第一个测试周期
    	1.1 从显而易见的简单测试开始 (因为这个时候测试人员对于软件还不熟悉)
    	1.2 记录还需要测试什么
    	1.3 检查有效用例并观察发生了什么  (根据第一步的信息开始设计第二步和第三步)
    	1.4 做一些快速的测试
    	1.5 总结对程序和问题的认识  (开始反思，总结，准备下一阶段的测试)
    	
    2. 第二个测试周期
    	2.1 在进行任何测试之前都给予评估
    	2.2 评审对不修复的问题的意见
    	2.3 找出上次的测试笔记，加入新的笔记，并且开始测试
   

3. 测试人员的工作效率取决于他对软件和项目的理解，而不是他的测试技术(对于开发也是如此)

    1. 理解产品
    2. 理解用于期望
    3. 理解产品的架构和源码(做到这点已经不是单纯地测试了)
    4. 回避浪费时间却没有收益的任务
    5. 了解产品的元素和项目团队，知道出问题找谁
    6. 良好地同事关系
   

缺陷报告

1. 程序员要阅读缺陷报告，了解缺陷的症状和步骤，好的缺陷报告可以帮助程序员快速定位问题，坏的缺陷报告只能浪费调试时间

2. 产品经理要阅读缺陷报告，了解缺陷的症状和严重性，好的缺陷报告可以帮助产品经理设定优先级，差的缺陷报告会误导他做出错误的决定

3. 在大型项目里面，缺陷报告是对于一个开发和测试评测的一个工具

1. 报告缺陷是为了让缺陷得到修复

    1. 清楚说明对用户的危害
    2. 提供尽可能多的技术信息，方便程序员调试
    3. 今早提交缺陷报告
    4. 报告发现的所有缺陷，即便有些缺陷难以重现
   

2. 七大产品元素

    1. 结构，在文件级别，构成的元素是各种文件，在代码级别，是各种类，函数等
    2. 功能，软件相关功能
    3. 数据，比如测试图片，有BMP,PNG等格式
    4. 接口，比如用户界面，系统API等
    5. 平台
    6. 操作，可能的操作组合
    7. 时间
   

3. 测试人员应该先提出假设，然后再实验，特别是在发现一些本来重现过但是没有办法再重现的问题

测试文档

1. 识别风险

    1. 自动化测试用例:该区域有自动化测试用例吗?? 测试在定期运行吗?? 测试通过率是多少?? 测试覆盖了哪方面，没有覆盖哪方面?
    2. 手动测试:  有人手动测试该区域吗? 经过测试，对该区域有多少信心? 如果满分是10分，打多少分??
    3. 代码变更: 该区域近期存在代码变更吗? 变更频繁吗? 近期是新增功能，代码重构，还是缺陷修复??
    4. 代码复杂度: 代码规模是多少，代码是否复杂，如果复杂是10分，改区域得多少分?
    
    5. 产品缺陷: 该产品缺陷多吗？？ 有哪些典型的缺陷，哪些缺陷已经被修复，哪些缺陷还没有被修复
   

测试建模

	1. 两因素组合测试，可以暴露由两个因素变量共同作用而引发的缺陷
	2. 多因素组合测试, 生成的测试集可以覆盖任意N个变量
	
1. 启发式建模方法
2. 输入与输出模型建模
3. 系统生态图
4. 实体关系模型
5. 状态机模型

测试开发

1. 自动化测试应切合当前的产品
2. 自动化测试应聚焦风险，重点解决产品面临最大的风险，不必面面俱到
3. 自动化测试应该在资源允许的范围内尽力扩展测试领域，提供多样化的测试
4. 自动化测试应该讲究实用，测试人员需要根据项目语境选择合适的开发策略


自动化测试金字塔:
最底层是单元测试和组件测试，由开发人员维护
然后是中层是面向业务的自动化测试
顶层是少量基于图形界面的自动化测试
金字塔上方是手工测试