软件测试基础
-
软件的复杂度已经超越了人的理解能力
1. 虽然高抽象的层次语言，程序框架，程序库等提高了人的生产力，但是还是需要开发者深入理解细节，可以减少开发时间，但是无法减少开发者学习整个技术栈的时间
2. 对于复杂的软件，如果测试人员不能掌握全部的信息，那么他的测试策略已经会错误(对于开发也是如此)，所以需要和各个工作岗位的人进行协作
3. 软件复杂，所以测试用例需要进行迭代，持续地评估和反思
4. 大规模的软件中,对于少量代码的变更都不能掉以轻心
5. 单凭人的脑力已经很难应对复杂的软件测试了，测试人员需要考虑测试自动化来对付这种情况 -
测试步骤
1. 第一个测试周期
1.1 从显而易见的简单测试开始 (因为这个时候测试人员对于软件还不熟悉)
1.2 记录还需要测试什么
1.3 检查有效用例并观察发生了什么 (根据第一步的信息开始设计第二步和第三步)
1.4 做一些快速的测试
1.5 总结对程序和问题的认识 (开始反思，总结，准备下一阶段的测试) 2. 第二个测试周期
2.1 在进行任何测试之前都给予评估
2.2 评审对不修复的问题的意见
2.3 找出上次的测试笔记，加入新的笔记，并且开始测试 -
测试人员的工作效率取决于他对软件和项目的理解，而不是他的测试技术(对于开发也是如此)
1. 理解产品
2. 理解用于期望
3. 理解产品的架构和源码(做到这点已经不是单纯地测试了)
4. 回避浪费时间却没有收益的任务
5. 了解产品的元素和项目团队，知道出问题找谁
6. 良好地同事关系
缺陷报告
1. 程序员要阅读缺陷报告，了解缺陷的症状和步骤，好的缺陷报告可以帮助程序员快速定位问题，坏的缺陷报告只能浪费调试时间
2. 产品经理要阅读缺陷报告，了解缺陷的症状和严重性，好的缺陷报告可以帮助产品经理设定优先级，差的缺陷报告会误导他做出错误的决定
3. 在大型项目里面，缺陷报告是对于一个开发和测试评测的一个工具
-
报告缺陷是为了让缺陷得到修复
1. 清楚说明对用户的危害
2. 提供尽可能多的技术信息，方便程序员调试
3. 今早提交缺陷报告
4. 报告发现的所有缺陷，即便有些缺陷难以重现 -
七大产品元素
1. 结构，在文件级别，构成的元素是各种文件，在代码级别，是各种类，函数等
2. 功能，软件相关功能
3. 数据，比如测试图片，有BMP,PNG等格式
4. 接口，比如用户界面，系统API等
5. 平台
6. 操作，可能的操作组合
7. 时间 测试人员应该先提出假设，然后再实验，特别是在发现一些本来重现过但是没有办法再重现的问题
测试文档
-
识别风险
1. 自动化测试用例:该区域有自动化测试用例吗?? 测试在定期运行吗?? 测试通过率是多少?? 测试覆盖了哪方面，没有覆盖哪方面?
2. 手动测试: 有人手动测试该区域吗? 经过测试，对该区域有多少信心? 如果满分是10分，打多少分??
3. 代码变更: 该区域近期存在代码变更吗? 变更频繁吗? 近期是新增功能，代码重构，还是缺陷修复??
4. 代码复杂度: 代码规模是多少，代码是否复杂，如果复杂是10分，改区域得多少分? 5. 产品缺陷: 该产品缺陷多吗？？ 有哪些典型的缺陷，哪些缺陷已经被修复，哪些缺陷还没有被修复
测试建模
1. 两因素组合测试，可以暴露由两个因素变量共同作用而引发的缺陷
2. 多因素组合测试, 生成的测试集可以覆盖任意N个变量
1. 启发式建模方法
2. 输入与输出模型建模
3. 系统生态图
4. 实体关系模型
5. 状态机模型
测试开发
1. 自动化测试应切合当前的产品
2. 自动化测试应聚焦风险，重点解决产品面临最大的风险，不必面面俱到
3. 自动化测试应该在资源允许的范围内尽力扩展测试领域，提供多样化的测试
4. 自动化测试应该讲究实用，测试人员需要根据项目语境选择合适的开发策略
自动化测试金字塔:
最底层是单元测试和组件测试，由开发人员维护
然后是中层是面向业务的自动化测试
顶层是少量基于图形界面的自动化测试
金字塔上方是手工测试