软件质量模型和软件测试的常识知识
1. 软件质量模型
1.1. 软件的功能性
1.1.1. 适用性：
所提供的功能是用户所需要的，用户所需要的功能软件系统是否已提供。
1.1.2. 准确性：
软件系统提供给用户的功能是否满足用户对该功能的精确度要求。
1.1.3. 互操作性：
软件系统和一个或多个周边系统进行信息交互的能力。例如
不同型号的打印机与word之间的协议可能不一致，导致消息传递过程中发生错误。
▲应该将被测软件系统和周边系统的各种主流型号进行互操作性测试。
1.1.4. 保密安全性：
软件系统保护信息和数据的能力。
Ⅰ、防止未得到授权的人或系统访问相关的信息或数据
Ⅱ、保证得到授权的人或系统能正常访问相关的信息或数据。
不同的系统对于安全性的需求差别很大
常见的安全性测试：
⑴用户验证：登录密码验证、IP地址访问限制等
⑵用户权限管理:验证低级别用户是否具有了高级别用户的权限，各级别用户权限都得到了实现。
⑶系统数据的保护:对例如系统文件、用户密码文件等进行隐藏、密码验证、内容加密、备份。
1.1.5. 防DoS攻击
DoS (Denial of Service)攻击：拒绝正常用户访问服务的攻击。
Dos攻击在众多网络攻击技术中是一种简单有效并且具有很大危害性的攻击方法。它通过各种手段消耗网络带宽和系统资源，或者攻击系统缺陷，使正常系统的正常服务陷于瘫痪状态，不能对正常用户进行服务，从而实现拒绝正常用户访问服务。
例如：
1.1.6. 防溢出攻击
例如：溢出攻击
正常输入：IE: http://www.baidu.com/
异常输入：IE: http://www.baidu.com/……（恶意代码）
1.1.7. 加密、解密：
在计算机通讯中，采用密码技术将信息隐蔽起来，再将隐蔽后的信息传输出去，使信息在传输过程中即使被窃取或截获，窃取者也不能了解信息的内容，从而保证信息传输的安全
1.1.8. 防病毒
1.2. 软件可靠性
1.2.1. 成熟性
软件系统防止内部错误扩散而导致失效的能力。
▲子系统、模块、单元模块的设计人员应该仔细分析和自身有接口关系的子系统、模块、单元模块，识别出这些接口上可能会传递过来的错误，然后在自己子系统、模块、单元模块内部对这些可能的错误预先进行防范，规避这些错误传递到自身而引起自身的失效。
1.2.2. 容错性
软件系统防止外部接口错误扩散而导致系统失效的能力。
▲设计人员应该充分分析外部接口可能产生的错误，然后在设计上对这些错误一一予以防范，防止这些外部传入的错误波及自身而失效。
1.2.3. 易恢复性
系统失效后重新恢复原有功能、性能的能力
①原有能力恢复的程度
②原有能力恢复的速度
1.2.4. 可靠性依从性
遵循相关的标准（国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。
1.3. 软件易用性
1.3.1. 易理解性
用户在使用软件系统的过程中，系统交互给用户的信息是否准确、清晰、易懂，能帮助用户准确理解系统当前真实的状态，指导其进一步的操作。
1.3.2. 易学性
软件系统提供相关的辅助手段，帮助用户学习使用它的能力。例如：是否有用户手册，用户手册是否有中文版，是否有在线帮助，界面上控件是否有回显功能等。
1.3.3. 易操作性
例如：
①Nokia手机和Moto手机在编辑短消息时的方便性差异。
②GUI界面，菜单层次不要太深
③安装软件的过程
错误：给用户大量的安装步骤，每步又有大量分支选项（把用户当成本软件的专家）
▲测试时应该以非专业的角度来测试过程，往往需要α、β测试。
1.3.4. 吸引性
美观：GUI界面、手机外观等
新颖：如夏新手机来电跳舞功能
1.4. 软件效率（性能测试）
1.4.1. 时间效率
系统在各业务场景下完成用户指定的业务请求所需的响应时间。
1.4.2. 资源效率
系统在各业务场景下完成用户指定的业务请求所消耗的系统资源，如CPU占有率、内存占有率、通信带宽占有率、软件内部消息包资源占有率等。
1.4.3. 效率依从性
遵循相关的标准（国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。
1.5. 软件可维护性
1.5.1. 易分析性
软件系统提供辅助手段帮助开发人员分析识别缺陷、失效产生的原因，找出待修复部分的能力。（降低缺陷定位的成本）
1.5.2. 易改变性
对软件缺陷的修复容易被实施（降低修复缺陷成本）
▲设计上封装性好、高内聚（同层次设计时，一个实体只完成一个功能）、低耦合，为未来可能的变化留有扩充余地。
1.5.3. 稳定性
例如：代码中的有物理含义的数字，一定用宏代替。
1.5.4. 易测试性
（降低发现缺陷的成本）
①软件可控制：
软件系统提供辅助手段帮助测试工程师控制该系统的运行，实现其测试执行步骤的能力（通过打点、改变内部状态、值等手段）
②可观察：
软件系统提供辅助手段帮助测试工程师获得充分的系统运行信息，以正确判断系统运行状态和测试执行结果的力。
a、设计单独的测试模式
b、提供单独的测试版本
▲测试部（一般指测试系统工程师）应该在需求分析阶段就提出可测试性需求，可测试性需求和软件产品其他需求一起纳入需求包被分析设计并实现。
1.6. 软件可移植性
1.6.1. 适应性
软件系统无需做任何相应变动就能适应不同运行环境（操作系统平台、数据库平台、硬件平台等）的能力。
▲解决平台无关、可移植性问题的一个常用思路是构造出一个虚拟层，虚拟层将下层细节屏蔽，对上层提供统一口。
1.6.2. 易安装性
主流平台 全部测试用例
非主流平台 10%测试用例
1.6.3. 共存性
软件系统和在公共环境与其共享资源的其他系统共存的能力。
▲测试不仅需要关注自身特性的实现，还要关注本软件是否影响了其他软件的正常功能。
1.7. 易替换性
软件系统升级能力（在线升级、打补丁升级等）
2. 软件测试的常识知识
2.1. 测试部门的组织结构
2.2. 软件测试和SQA的关系
2.2.1. 什么是SQA
2.2.2. SQA与测试
2.3. 软件测试的一些基本原则:
2.3.1. 不要试图穷举测试
穷举测试指的是测试时考虑所有可能的输入值，测试最优秀的测试用例是用最少的测试用例达到最高的覆盖率
2.3.2. 软件测试要尽早执行
2.3.3. 软件测试应该追溯需求
2.3.4. 缺陷的二八定理
80%的缺陷集中在20%的模块中，测试人员要抓主要矛盾。
