软件质量作业第四次.docx
以下为本人软件质量与软件测试课程的部分关键笔记，有需要的可以借鉴一下
1. 软件缺陷的表现形式
软件产品在开发或维护的过程中存在错误。
系统所要实现的某种功能失效或违背。
2. 软件缺陷的等级划分
Critical：不能执行正常工作功能或重要功能。或者危及人身安全。
Major：严重地影响系统要求或基本功能的实现，且没有办法更正。（重新安装或重新启动该软件不属于更正办法）
Minor：严重地影响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法）
Cosmetic：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。
Other：其它错误。
3. 软件缺陷的主要状态
Submitted: 已提交的缺陷
Open :确认“提交的缺陷”，等待处理
Rejected: 拒绝“提交的缺陷”，不需要修复或不是缺陷
Resolved :缺陷被修复
Closed :确认被修复的缺陷，将其关闭
4. 软件缺陷产生的原因
首先，在软件开发的过程中，软件缺陷的产生是不可避免的。
从软件本身来看:系统结构复杂、对数组的范围考虑不周全、系统崩溃后没有自我修复或备份功能、新技术的采用
从团队工作来看：需求不清晰、开发人员互相理解不一致、没有充分沟通、技术水平参差不齐
从项目管理来看：需求分析、评审、测试质量不高、对客户的需求不是十分清楚、和用户的沟通不彻底、开发周期短、流程不够完善、文档不完善、风险估计不足
5.软件测试停止依据
软件系统经过单元、集成、系统测试，分别达到单元、集成、系统测试停止标准，并通过验收测试，并已得出验收测试结论。
或者软件项目需暂停或终止时，测试应随之暂停。
6.软件测试的原则
②穷尽测试是不可能的
③测试尽早介入
④缺陷具有集群性 80%的错误是由20%的模块引起的
⑤测试用例需要经常性的评审和修改，以防“抗药性”
⑥如果系统不满足用户需求，寻找，修改也没有任何帮助
⑨必须检查每个实际输出结果
7.5w1h
Why 为什么要测试
Who 参与者是谁 谁来执行
When 什么时候测试
Where 测试哪部分 到哪部分结束
How 如何测试 如何组织人员 风险 进度 质量
8. 软件测试的组成阶段
9.软件测试用例的组成元素
用例ID；
用例名称；
测试目的；
测试级别；
参考信息；
测试环境；
前提条件；
测试步骤；
预期结果；
设计人员
10.软件用例的编写原则
系统性。对系统业务流程要完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系；对模块业务流程要说明子系统内部功能、重点功能以及它们之间的关系 Ø
连贯性。对系统业务流程要说明各个子系统之间是如何连接在一起，若需要接口，各子系统之间是否有正确的接口，若是依靠页面链接，则页面的链接是否正确；对模块业务流程要说明同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯 Ø
全面性。应尽可能覆盖各种路径、尽可能覆盖各个业务点，并要考虑跨年、跨月的数据以及大数据量并发测试的准备
正确性。输入界面后的数据应与测试文档所记录的数据一致，而预期结果也应与测试数据发生的业务吻合
符合正常业务规则。测试数据要符合用户实际工作中的业务流程，同时也要兼顾各种业务的变化以及当前该业务行业的法律、法规
人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例；不允许出现与知名人士、小说中人物名等雷同情况。
可操作性。测试用例中要写清楚测试的操作步骤，以及不同的操作步骤相对应的测试结果
11.软件测试用例的评价标准
应该制订统一的模板、根据项目实际情况编写测试案例编写手册、用例编写要步骤明确，输入输出要素清晰，并且与需求和缺陷相对应、应严格根据需求规格说明书及测试需求功能分析点进行，要求覆盖全部需求功能点、最后注重用例的可复用性
12.V模型
v模型的重点就是当一个软件开发的时候，研发人员和测试人员需要同时工作，测试在软件做需求分析的同时就会有测试用例的跟踪，这样，可以尽快找出程序错误和需求偏离，从而更高效的提高程序质量，最大可能的减少成本，同时满足用户的实际软件需求。
13. 静态测试的方法
文档评审、代码走查：开发者讲解，不做现场修改
代码审查（严格版的代码走查） 技术评审
14. 技术评审的流程
①申请评审：联系协调者确认入口准则
②评审计划：选择审查者指定评审计划，准备评审包，设置目标
③启动会议
④评审准备：（提前一天）
⑤小组评审会议：记录发现的问题，由协调者推动会议
⑥返工：修改目标文档
⑦跟踪：验证返工
⑧结束
