（注：本帖参考宴斌《软件测试入门》一书，记录学习笔记，与大家分享，无商用目的。如不慎侵权，烦请私信联系协商解决。）
软件质量体系
CMM（软件能力成熟度模型）为企业的软件过程能力提供了一个阶梯式的进化框架，阶梯共有五级:
第一级：初始级（Initial);
第二级：可重复级（Repeatable);
第三级：已定义级（Defined);
第四级：受管理级（Managed);
第五级：优化级（Optimizing)。
软件生命周期
需求管理（Requirements Management)——>软件项目计划（Software Project Planning)——>设计阶段——>编码阶段——>核实阶段——>系统维护阶段
流程中的组
系统分析人员：提出测试需求并跟踪，确定测试的对象/方法和范围。
软件开发人员：提供开发计划SDP，参与制定和评审测试计划；提供软件功能需求规格/需求分析/测试建议等文档，参与制定和评审测试方案和案例；响应测试需求，跟踪解决缺陷。
测试人员：设计测试用例，执行测试，撰写测试 告等；
配置管理人员:对测试文档测试代码及相关配置项进行配置管理；
质量保证人员：质量保证，参与相关评审。
其他人员：PM/项目组/测试组/SQA/SEPG/SCM/售前/售后/市场等都要参与进来。
测试定义：使用人工或自动手段来运行或预定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期效果与实际效果之间的差别。
测试的目的：尽可能地发现程序中的错误，提高产品可靠性。
测试规律：
木桶原理：产品质量的关键因素是分析、设计和实现，测试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会影响最终产品的质量。应该说，测试是提高产品质量的必要条件，也是提高产品质量最直接。最快捷的手段，但决不是一种根本手段。反过来说，如果将产品质量的砝码全部押在测试上，那将是一个恐怖而漫长的灾难。
八二原则：在分析。设计、实现阶段的复审和测试工作能够发现和避免80%的BUG，而系统测试又能找出其余BUG中的80%，最后的5%的BUG可能只有在用户的大范围、长时间使用后才会暴露出来。因为测试只能怪保证尽可能多地发现错误，无法保证能够发现所有的错误。对八二原则的另一说法是，80%的程序缺陷常常生存在软件的20%的程序空间里。
测试原则
测试的工作是有计划的；
zero-bug是一种理想，good-enough是原则，在软件测试成本和软件质量效益间找到一个平衡点；
不应测试自己开发的程序；
要尽早进行测试；
测试应当追溯到用户需求；
测试设计和测试操作进行分离；
软件缺陷具有免疫性，必须更换不同的测试方法额测试数据；
测试本身应该被测试；
测试和质量关系密切，测试活动需要有规划和监控及明确的输出；
其中，要尽早发现和修正缺陷主要原因为：
1） 缺陷的修复成本随着阶段推移急剧上升，产品发布后修成一个缺陷的成本将是需求阶段的100倍，甚至更高；
2） 缺陷具有放大的特点，缺陷修改延迟几个星期甚至几个月将使得系统更容易出错（“软件缺陷具有生长和生育能 力”） ；
3） 设计判定和一些小的代码限制及条件很容易被忘掉；
4）尽早修正缺陷可以节省重新分析设计的时间；
5）早期的问题反馈有助于防止类似错误的产生；
6） 大量的缺陷和问题跟踪工作将被减轻；
7） 如果必要的话，可以重新设计和编码，而这个工作越往后期越不可能；
8） 需求和设计时出现的缺陷占很大比例。
测试的主要内容
1.测试要考虑到所有出错的可能性，同时要做一些不是按常规做的、非常奇怪的事。
2.除了漏洞之外测试还要考虑性能问题，保证软件运行良好，非常快，没有内存泄露，不会出现软件运行越来越慢的问题。
3.测试要考虑软件的兼容性。
测试生命周期：对测试人员进行业务培训，测试需求分析，编写测试计划，编写测试案例，测试执行，编写测试 告
流程中的文档：测试计划，测试规范，测试案例，测试 告，缺陷或测试 告。
测试需要完成的工作：需求评审，制定测试计划，设计测试，实施测试，对测试进行评估。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！