技术解决过程域 [Technicl Solution]
技术解决过程域 [Technical Solution]
技术实现包括以下内容：
设计产品和产品组件
管理产品组件之间的接口
编译和调度产品组件
产品的集成、发布
确保需求是能被满中的
产品交付使用 [测试团队、外部客户]
设计
高阶设计阶段
架构设计
详细设计
界面设计
数据库设计
模块设计
数据结构与算法
架构设计原则：
合适性
结构稳定性
可扩展性
可复用性
--------------------------
合适性：
适合功能、非功能需求
市场决定产品命运，而不是技术
没有最好的，只有最合适的
开发多个候选方案，选择最合适的
稳定性：
稳定的需求决定体系结构
易变的需求决定体系可扩展性
可扩展性：
变化是永恒不变的主题，是否适应变化决定了产品的前途
稳定与扩展的关系：辩证的关系
只是稳定，不可扩展，则产品没有前途
稳定是可扩展的基础，结构稳定才能可持续的扩展
预留接口
可复用性：
可复用性是设计出来的
公共部分
抽象
复用提高生产率
用户界面设计原则：
易用性
操作简单
容易使用
风格一致
及时反馈信息
出错处理
美观
布局合理
色彩搭配适当
数据库设计原则：
选择合适的数据库
数据库优化
优化表结构
规范化(第三范式)
优化数据环境参数
增强硬件性能,内在、CPU等
模块设计原则：
透明
接口公开，内部实现隐藏
高内聚
一个模块内部各元素之间的关联度要高
低耦合
模块之间的依赖程度要低
[
模块的性能决定了系统的性能
单个模块的性能决定了系统某个功能的性能
模块间的协作性能决定了系统的整体性能
]
编码
编码规范
单元测试
代码评审
----------------------
编码规范
基本的编码规范
排版
注释
命名
高级的编码规范
针对特定语言的经验总结 [c\c++\Java]
单元测试
作用及价值：
增加我们对程序的信心
测试可以让我们相信程序做了我们期望做的事情
尽早发现BUG
一个BUG被隐藏的时间越长，修复这个BUG的代价就越大
做回归测试的根本
单元测试的需要：
学习测试工具
学习测试方法
写测试用例
测不出BUG的可能性：
代码质量高[可能性较低]
测试方法、测试策略不对、测试用例质量不高、覆盖率低
编写单元测试
利用工具
测试方法
等价类、边界值、逻辑覆盖
测试策略
根据逻辑复杂度确定是否值得编写测试用例[循环、判断层次]
使用断言而不是打印
测试覆盖率：代码覆盖、分支覆盖、路径覆盖
不写单元测试可能出现的后果：
项目不断播延期
无休的加班
对项目失去信心
大量开发人员离职
产品不能推向市场
审计
QA 审计要点
是否写了测试用例
测试用例是否达到了组织要求的覆盖率
是否记录了测试的BUG
是否分析了BUG的原因，类型分布
代码评审
类型：
正式审查
非正式走查
自查
交叉检查
四眼走查
会议走查
代码评审可能出现的问题：
编码规范
排版
命名
注释
设计需求满足的问题
编码是否符合设计、需求
代码评审策略
每日/每周走查
新手必查
核心代码必查
如何保证代码评审效果
引入代码静态检查工具
运用代码评审检查单
检查单要更新、维护
检查单数据要统计
编程高手
经验
培训
指导
标杆
重构[单元测试用例是重构的保证]
定义：不改变软件外部行为的前提下，调整程序结构，搞高可理解性，可维护性
优化软件结构
找出BUG
重构时机：
修改BUG的时
代码评审时
添加新功能时
技术实现包括以下内容：
设计产品和产品组件
管理产品组件之间的接口
编译和调度产品组件
产品的集成、发布
确保需求是能被满中的
产品交付使用 [测试团队、外部客户]
设计
高阶设计阶段
架构设计
详细设计
界面设计
数据库设计
模块设计
数据结构与算法
架构设计原则：
合适性
结构稳定性
可扩展性
可复用性
--------------------------
合适性：
适合功能、非功能需求
市场决定产品命运，而不是技术
没有最好的，只有最合适的
开发多个候选方案，选择最合适的
稳定性：
稳定的需求决定体系结构
易变的需求决定体系可扩展性
可扩展性：
变化是永恒不变的主题，是否适应变化决定了产品的前途
稳定与扩展的关系：辩证的关系
只是稳定，不可扩展，则产品没有前途
稳定是可扩展的基础，结构稳定才能可持续的扩展
预留接口
可复用性：
可复用性是设计出来的
公共部分
抽象
复用提高生产率
用户界面设计原则：
易用性
操作简单
容易使用
风格一致
及时反馈信息
出错处理
美观
布局合理
色彩搭配适当
数据库设计原则：
选择合适的数据库
数据库优化
优化表结构
规范化(第三范式)
优化数据环境参数
增强硬件性能,内在、CPU等
模块设计原则：
透明
接口公开，内部实现隐藏
高内聚
一个模块内部各元素之间的关联度要高
低耦合
模块之间的依赖程度要低
[
模块的性能决定了系统的性能
单个模块的性能决定了系统某个功能的性能
模块间的协作性能决定了系统的整体性能
]
编码
编码规范
单元测试
代码评审
----------------------
编码规范
基本的编码规范
排版
注释
命名
高级的编码规范
针对特定语言的经验总结 [c\c++\Java]
单元测试
作用及价值：
增加我们对程序的信心
测试可以让我们相信程序做了我们期望做的事情
尽早发现BUG
一个BUG被隐藏的时间越长，修复这个BUG的代价就越大
做回归测试的根本
单元测试的需要：
学习测试工具
学习测试方法
写测试用例
测不出BUG的可能性：
代码质量高[可能性较低]
测试方法、测试策略不对、测试用例质量不高、覆盖率低
编写单元测试
利用工具
测试方法
等价类、边界值、逻辑覆盖
测试策略
根据逻辑复杂度确定是否值得编写测试用例[循环、判断层次]
使用断言而不是打印
测试覆盖率：代码覆盖、分支覆盖、路径覆盖
不写单元测试可能出现的后果：
项目不断播延期
无休的加班
对项目失去信心
大量开发人员离职
产品不能推向市场
审计
QA 审计要点
是否写了测试用例
测试用例是否达到了组织要求的覆盖率
是否记录了测试的BUG
是否分析了BUG的原因，类型分布
代码评审
类型：
正式审查
非正式走查
自查
交叉检查
四眼走查
会议走查
代码评审可能出现的问题：
编码规范
排版
命名
注释
设计需求满足的问题
编码是否符合设计、需求
代码评审策略
每日/每周走查
新手必查
核心代码必查
如何保证代码评审效果
引入代码静态检查工具
运用代码评审检查单
检查单要更新、维护
检查单数据要统计
编程高手
经验
培训
指导
标杆
重构[单元测试用例是重构的保证]
定义：不改变软件外部行为的前提下，调整程序结构，搞高可理解性，可维护性
优化软件结构
找出BUG
重构时机：
修改BUG的时
代码评审时
添加新功能时
