白盒测试用例设计
- 语句覆盖：程序中每条语句至少执行一次
- 判定覆盖：程序中每个判断的取真分支和取假分支至少经历一次
- 条件覆盖：程序中每个判断的每个条件的可能取值至少执行一次
- 判定/条件覆盖：每个判断的所有可能的条件取值组合至少执行一次
- 条件组合覆盖：每个判断的所有可能的条件取值组合至少执行一次
- 点覆盖：程序执行时至少经过程序图中每个节点一次
- 边覆盖：程序执行路径至少经过程序图中每个边一次
- 路径覆盖：程序的每条可能路径都至少执行一次
黑盒测试用例设计
- 等价类及其划分：将程序的输入数据集合按输入条件划分为若干个等价类，每一个等价类相对于输入条件表示为一组有效或无效输入，然后为每一等价类设计一个测试用例。
- 边界值分析：避免处理边界情况时发生错误
- 因果图法：检查各种输入条件的组合
- 错误推测法：根据经验来设计程序测试用例
面向对象设计的原则
- 单一职责原则（SRP）
- 开闭原则（OCP）
- Liskov替换原则
- 依赖倒置原则（DIP）
- 接口分离原则（ISP）
- (1)单一职责原则：每个类只做单一的事情。有利于算法的间接性和清晰性、使代码变得容易测试和维护、提高代码重用度。
- (2)开闭原则：开放扩展、关闭修改、提倡和遵循将系统的类体结构设计成易于扩展和不允许修改的原则。
- (3)Liskov替换原则：尽量在不知道子类的情况下，使用父类去构造程序，是程序具有足够的抽象性。
- (4)依赖倒置原则:依赖于抽象，不要依赖于具体
- (5)接口分离原则：不要将多个操作设计在一个接口之中，而应尽量将其分散。
UML
统一建模语言UML 用来对软件系统进行需求描述，软件构造，可视化建模和文档编制，具有直观性、严格性和标准性特征。
标准建模语言UML的重要内容可以由下列五类图型来定义：
- 用例图
- 静态图
- 行为图
- 交互图
- 实现图
UML中包含三种主要元素
- 基本构造块
- 规则
- 公共机制
设计模式与框架的含义及区别
设计模式是在系统设计中为了获取更好的可重用性和可扩充性而被不断重复使用的设计方案。框架是整个或部分系统的可重用设计，表现为一组抽象构件及构件实例间的交互。
区别：设计模式解决抽象、局部的问题，框架是对问题完整的抽象解决方法
小结：软件项目管理
软件项目管理是软件工程中的保护性活动，它先于任何技术活动之前开始，贯穿于软件工程始终，具有无可替代的重要作用。
软件项目管理活动覆盖项目估算，风险预测，进度安排，计划制定，品质保证，配置管理和针对整个项目进程的跟踪、度量活动。项目管理的重点是人员、问题和过程。实施项目管理的基本目标是保证人员高效、问题明晰、过程可控。
软件项目管理包含哪些活动？
- 启动软件项目：明确目标、界定范围、初步确定解决方案。
- 项目度量：包括对过程的度量和对产品的度量两个方面。度量是为了对产品和过程进行定量的管理。
- 估算：包括对项目规模、工作量、成本、进度、资源需求等各个方面的估算。
- 风险分析：为了最大限度地规避开发过程中可能会发生的风险。包括风险识别、风险预测、风险跟踪等保护性活动。
- 制定计划:开发计划应当界定每项细分的工作任务所需要的时间、人力资源、阶段划分、工作产品形式、启动/结束条件等，是工作能高效率地进行。
- 实施跟踪和控制:项目管理中，必须以计划为准绳，以度量数据为依据，对实际工作进行跟踪和检查，出现较大偏差时要及时进行调控。实现对软件开发过程的有效控制。
人员角色管理（项目参与者）
- 高级管理者
- 项目（技术）管理者
- 开发人员
- 客户代表
- 最终用户
软件风险
软件风险的特性：
- 不确定性
- 危害性
风险的分类
- 已知风险
- 可预测风险
- 不可预测风险
五个主要的商业风险是：
- 市场风险
- 策略风险
- 营销风险
- 管理风险
- 预算风险
风险管理
- 风险识别
- 风险评估
- 风险评价
- 风险缓解与监控
软件质量
- 软件需求是度量软件质量的基础，不满足需求的软件就不具备质量
- 软件人员必须遵循软件过程规范，用工程化的方法来开发软件
- 往往会有一些隐含的需求没有明确地提出来，如果软件只是满足那些规定的需求而没有满足那些可能存在的隐含需求，软件质量也不能保证。
SQA活动
- 为项目准备SQA计划
- 参与开发该项目的软件过程
- 复审各项软件工程活动
- 审查指定的软件工作产品
- 确保软件工作及工作产品中的偏差已记录在案，并按照预定的规程进行处理
- 记录所有的不符合部分，并报告给高级管理者，对不符合部分进行跟踪，直到问题得到解决
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
