软件测试的定义
采用人工或自动化的手段，运行软件或直接观察软件的过程，其目的是检验软件是否满足用户的需求，或弄清软件和需求之间的差别
阐述了软件测试3个方面的内容
1.测试方法
可以是人工进行的
也可以是自动化的
2.软件测试的过程
可以运行软件进行测试
还可以不运行软件而直接观察软件进行测试
3.软件测试的根本目的
检验软件是否满足用户需求
有时还需要定量的检测软件和需求之间的差距
软件测试目的
1.证明
测试行业的早期，60年代，希望通过程序测试发现错误、修复错误，直到再也找不到错误，从而证明软件没有错误
现代软件测试理论认为，软件中不可能完全没有错误，软件测试永远做不到发现软件中的所有错误。测试做不到证明软件没有错误
现代软件测试理论认为，软件测试可以证明软件在规定使用方式下的可用，还可以证明在某些异常情况下的表现
2.检测
70年代，软件测试目的逐渐转变为不为了证明没有错误，而是目的就仅在于不断检测错误
现代软件测试理论认为，检测的不仅仅是错误，应该叫缺陷，缺陷包括了错误，还包括了不是错误但是可优化的缺陷
3.预防
现代软件测试理论认为，通过尽早测试、尽早修复，可以避免问题延后发现带来的损失扩大化
现代软件测试理论认为，通过测试发现问题、找出原因，进行改进，可以避免同类问题的再次发生
软件生命周期
计划阶段
1.提出总体目标、总体规划
2.进行可行性论证
3.制订计划
需求分析阶段
对产品进行详细的需求定义
项目型产品
需求分析人员和用户进行沟通，掌握用户需求
分析需求，编写软件需求说明书
SRS评审后将作为合同附件，具有法律效应
市场型产品
需求分析人员进行市场调研，调研市场需求，调研未来发展预测
分析需求、预测未来趋势，编写软件需求说明书
SRS文档评审后成为各部门协调工作的准则
软件需求说明书
Software Requirement Specification(SRS)
该文档的评审通过签字发布是该项目实施过程中的第一个重要里程碑(milestone)
设计阶段
概要设计
将软件产品从结构上逐层分解，描述每个小整体的规格要求，以及各个小整体如何衔接来实现整体规格要求
编写和评审概要设计说明书 —— High Level Design(HLD)
详细设计
针对概要设计分解出来的单元内部逻辑进行设计
编写和评审详细设计说明书 —— Low Level Design(LLD)
详细设计说明书中的内容是关于一个个单元的伪代码
编码阶段
按照伪代码编写一个个单元的代码
测试阶段
单元测试
针对每个单元的内部运行逻辑进行的测试
集成测试
针对单元之间、模块之间、子系统之间的接口进行的测试
逐层组装、一边组装一边测试
系统测试
针对产品整体检验是否满足用户需求的测试
验收测试
1.项目型产品
甲方为主、乙方配合，由甲方来执行检查的用户验收测试活动
2.市场型
项目团队主导、用户执行的验收测试
alpha测试 —— 内测，项目团队邀请极少量用户到测试环境内，在项目组成员的指导和控制之下执行的验收测试
beta测试 —— 公测，产品开放给少量用户，由用户在真实的使用环境自由执行的验收测试
运行维护阶段
用户的使用和维护
在使用中提出改进意见，产品研发团队实施改进，待改进产品交付用户后，本产品生命周期结束
项目团队成员组成
项目经理
Project Mananger，PM
产品经理
如果既有项目经理又有产品经理，则通常负责项目中一个独立产品的研发
客户经理
负责和客户沟通的人员，通常由业务部门或市场部门的人员担任
需求分析人员
设计人员
架构师 —— 主要设计人员
游戏行业叫策划
UI设计叫美工人员
编码人员
很多公司需求分析、设计和编码由同一类人担任，角色叫开发人员
测试人员
QA
Quality Assurance，质量保障，配合项目经理针对项目团队制定流程规范、
监督团队按规范实施、进行流程改进的人员
CMO
Configuration Management Operator，配置管理员
管理项目中所有代码和文档的配置项
大部分公司配置管理员同时兼任产品发布人员
软件研发的模式
瀑布式
先做需求分析、然后设计，再编码，最后测试
一个阶段未完成、下一个阶段不会开始
项目管理流程简单，但应对需求变更响应不及时
迭代式
每个迭代周期内是一个小瀑布流程
最初计划项目分多少迭代周期完成研发、每个迭代周期内完成多少内容的需求分析、设计、编码和测试工作
项目管理流程难度大，但应对变更更方便
常见迭代模式
螺旋式 —— 基于风险分析的增量开发
原型法 —— 主要用于引导用户进行需求分析，先开发原型，再使用原型产品来引导用户提出新需求
敏捷 —— 频率非常高的迭代模式，有很多独特的产品研发思想和做法
网友评论