笔记内容及图片整理自XJTUSE “软件质量保证” 课程ppt，仅供学习交流使用，谢谢。
对于软件测试中产品/服务/成果的质量，需要细化到每个质量特性上，因此出现了较为公认的软件质量模型，包括McCall质量模型、ISO/IEC 9126质量模型等。
软件质量模型
McCall质量模型
具有归属于3个方面的11个质量因子，并通过多对多的关系与23个质量标准相关联。
产品操作方面：正确性、可靠性、有效性、完整性、易用性
产品修复方面：可维护性、易测性、适应性
产品转变方面：可移植性、可重用性、互操作性
McCall模型中一次性改进所有质量因子并不现实，因为部分质量因子之间是负相关的，例如改善易用性常常会降低系统效率。
ISO/IEC 9126质量模型
具有6类质量特性，并能分解为20个质量子特性，质量特性与子特性间是一对多关系。
功能性：合适性、准确性、互操作性、安全性
可靠性：成熟性、容错性、可恢复性
易用性：易懂性、易学性、可操作性
有效性：时间行为、资源利用
可维护性：可分析性、可变性、稳定性、易测性
可移植性：适应性、可安装性、共存性、替换性
与考虑内部质量的McCall模型相比，ISO/IEC 9126模型强调对用户可见的属性。
软件测试角色
软件测试工作通常需要多名不同类型的测试人员，测试任务独立于开发任务。本教材采用了统一软件开发过程RUP的划分方法。RUP的目标是支持在可预测时间和可预测预算内生产满足最终的用户需求的高质量软件，它将不同类型的测试人员划分为四类角色：测试经理、测试分析师、测试设计师、测试员。
测试经理
测试经理对整个测试工作负责，包括明确测试任务与目标、制定测试计划、安排测试人员、协调测试工作所需的各类资源，目的是解决测试过程中碰到的各类问题。
测试分析师
测试分析师分析被测软件的特征，明确并细化测试目标，设计、执行、分析测试用例结果，编写软件缺陷报告。
测试设计师
测试设计师负责定义测试方法并保证测试工作的顺利进行，测试设计师本质还是开发人员，目的是开发通用测试基础框架，尽可能保证被测软件可测性。
测试员
测试员负责测试工作的执行，将测试用例用于被测软件并记录测试结果，测试员是测试工作的执行者，对自动化测试能否成功起重要作用。
RUP测试流程
RUP测试流程具有较高的代表性，不仅适合迭代式软件开发，经过改造还能适合其他模型。RUP测试流程描述了测试经理、测试分析师、测试设计师、测试员这四类测试角色的任务与职责，具体包括6个主要环节：定义评估任务、测试与评估、完成验收任务、验证测试方法、确认构建稳定性和改进测试资产。
定义评估任务
定义评估任务是测试团队开展具体测试工作前的第一步，主要目标是确定测试工作的重点，对于每次迭代来讲，该环节的主要任务包括：
1）明确具体的测试工作目标
2）制定详细的测试工作计划
3）确定合适的资源使用策略
4）确定测试工作的范围与边界
5）给出将要采用的测试方法
6）明确如何监督与评估测试过程
定义评估任务考虑测试团队的高层目标，需要测试经理、测试分析师、测试设计师的参与。
对于每次测试来说，测试团队的工作目标包括：
1）发现尽可能多的缺陷
2）评估软件质量
3）检查是否与规格说明书一致
4）检查与现有同类产品是否一致
5）最小化维护成本和用户投诉
6）检查软件是否满足用户期望
测试计划
测试团队根据测试目标为被测软件制定较详细的测试计划，从而基于该测试计划来合理安排每位测试人员的工作。
制定测试计划时应考虑被测软件的特征、测试团队的人员组成、测试周期、测试目标等因素，明确规定测试工作的范围、方法、资源、进度，明确责任人的任务，评估可能存在的风险。测试工作范围不完全等同于开发工作范围，由于软件开发多采用迭代模式，每次迭代后测试目标会发生变化。
测试方法
测试方法也称测试策略，旨在确定将要具体使用的测试技术，从而完成预期测试工作。好的测试方法包括多样化、风险为中心、产品特定、实际可行、可解释的五个方面。
多样化——采用多种测试技术以增加发现各类软件缺陷的概率
风险为中心——由于穷尽性测试不现实，以风险为中心测试尽可能降低风险
产品特定——不同产品具有不同特征面临不同风险，因而要选择特定的技术组合
实际可行——测试方法不能超过时间、预算、资源、员工能力等实际的限制
可解释的——测试方法需要能够自我解释清楚以得到团队认可
测试与评估
测试与评估的目标是使测试工作达到合适的广度和深度，从而能够对每个测试项进行充分的评估。对于每个测试周期，该环节聚焦如何达到可接受的广度和深度，这是整个测试周期中最为核心的环节，主要参与角色是测试分析师和测试员。
测试
选择合适的测试技术来匹配测试方法，典型测试技术包括用户测试、易用性测试、UI测试。
用户测试——站在用户角度进行测试，重点关注执行测试的人
易用性测试——执行测试来检验软件是否易于使用，重点关注软件易用性和用户体验
UI测试——测试软件界面以判断它是否符合期望标准，重点关注测试的内容是否符合预期
测试需要考虑以下5个维度：
1）测试者：谁执行测试工作
2）内容：要测试什么
3）问题：测试哪类问题
4）活动：如何测试
5）评估：如何判断测试用例是否通过
评估
每个测试周期，测试人员都需要对每个测试项进行检验和评估，记录必要信息并对可能存在风险的区域提供反馈。测试员的主要工作是执行测试用例并记录结果，发现问题后填写缺陷报告，缺陷报告质量的高低决定该缺陷被修复的概率。
由于测试工作与开发工作相互独立，开发人员往往不愿意修复报告出来的缺陷，测试人员可采用以下方式激励开发人员：
1）强调缺陷的严重性
2）指出缺陷会影响很多用户使用
3）表示修复缺陷很有挑战性
4）表达领导对于缺陷的重视
5）说明竞争对手由于该缺陷产生大量损失
跟随测试
跟随测试是一种探索性测试，有助于开发人员理解缺陷并加快缺陷的修复，跟随测试的思想是在发现失效后继续进行测试以发现缺陷的所有影响，它包括以下4类：
1）改变测试行为
2）改变选项和配置
3）改变运行环境
4）改变测试数据
完成验收任务
完成一个测试周期的工作后需对测试工作进行总结，评估软件质量，检验软件产品是否满足当前迭代目标。对于每个测试周期，完成验收任务的工作包括：
1）优化测试用例集
2）给出针对测试发现问题的解决方案
3）客观评价软件质量
4）检查测试周期内质量回归问题，即多少已修复的缺陷再次出现
5）为项目团队其他成员提供专业信息
其他环节
验证测试方法
验证测试方法是确定测试方法是否可行，是否满足项目限制，是否达到既定覆盖率，其主要参与者是测试设计师和测试经理。为了使得测试方法可行，可能需要通过增加软件可见性、采用基于组件的架构、使用仿真器等设备三种方法以增加软件的可测试性。
确认构建的稳定性
确认构建的稳定性是确认构建足够稳定从而值得进行后续的测试，有助于及时阻止不合适的测试工作从而减少浪费，其主要参与者是测试员。在实际项目中，构建稳定性测试通常采用以自动化测试为主，手工测试为辅的模式。
改进测试资产
改进测试资产目的是在后续测试周期甚至其他软件项目中尽可能地复用资产。由于测试过程中测试人员花费了许多时间费用开发测试思想、方法、用例、脚本、自动化测试框架、配置等资产，实现有效的重用能带来很大收益。
