软件测试人需要掌握的测试知识架构体系（上）
软件计划与可行性研究（问题定义、可行性研究）；需求分析；软件设计（概要设计、详细设计）；编码；软件测试；运行与维护。
一、软件的生命周期(SDLC)
1、生存周期划分
各阶段的任务彼此间尽可能相对独立，同一个阶段各项任务的性质尽可能相同，从而降低每个阶段任务的复杂性，简化不同阶段之间的联系，有利于软件开发过程的组织管理。
2、生存周期基线：
功能基线
指派基线
产品基线
3、SDLC的六个阶段
1）定义及规划
此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。
2）需求分析
在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。“唯一不变的是变化本身。”，同样需求也是在整个软件开发过程中不断变化和深入的，因此我们必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。
3）软件设计
此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。软件设计一般分为总体设计和详细设计。好的软件设计将为软件程序编写打下良好的基础。
4）程序编码
此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。
5）软件测试
在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。
6）运行维护
软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。要延续软件的使用寿命，就必须对软件进行维护。软件软件生存周期的维护包括纠错性维护和改进性维护两个方面。
二、软件测试在软件生命周期（瀑布模型）中的对应关系
周期模型：典型的几种生命周期模型主要包括：瀑布模型、快速原型模型、迭代模型。
三、软件测试过程
第一步：对要执行测试的产品/项目进行分析，确定测试策略，制定测试计划。该计划被审核批准后转向第二步。测试工作启动前一定要确定正确的测试策略和指导方针，这些是后期开展工作的基础。只有将本次的测试目标和要求分析清楚，才能决定测试资源的投入。
第二步：设计测试用例。设计测试用例要根据测试需求和测试策略来进行，进度压力不大时，应该设计的详细，如果进度、成本压力较大，则应该保证测试用例覆盖到关键性的测试需求。该用例被批准后转向第三步。
第三步：如果满足“启动准则”（EntryCriteria），那么执行测试。执行测试主要是搭建测试环境，执行测试用例。执行测试时要进行进度控制、项目协调等工作。
第四步：提交缺陷。这里要进行缺陷审核和验证等工作。
第五步：消除软件缺陷。通常情况下，开发经理需要审核缺陷，并进行缺陷分配。程序员修改自己负责的缺陷。在程序员修改完成后，进入到回归测试阶段。如果满足“完成准则”（ExitCriteria），那么正常结束测试。
第六步：撰写测试报告。对测试进行分析，总结本次的经验教训，在下一次的工作中改。
软件测试过程管理，主要包括软件测试是什么样的过程，如何评价一个软件测试过程，如何进行配置管理和测试风险分析以及测试成本的管理。
四、软件测试流程（与第三条对应）
1、制定测试计划
2、编辑测试用例
3、执行测试用例
4、发现并提交BUG
5、开发组修正BUG
6、对已修正BUG进行返测
7、修正完成的BUG将状态置为已关闭，未正确修正的BUG重新激活
五、测试用例
测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
测试用例的要素为：版本号、模块名称、用例编号、用例名称、用例级别、预置条件、验证步骤、期望结果（含判断标准）、测试结果、测试时间、测试人员等。（其中核心要素为预置条件、验证步骤、期望结果）
测试用例的设计方法：等价类划分、边界值分析、错误推测法、因果图法、场景设计法
一份好的测试用例所要达到以下几点要求：测试用例必须完成对需求的完整覆盖（即用例和需求的双向可追溯性）；测试用例必须是可执行的；测试用例的结果唯一性；测试用例必须简洁明了
六、缺陷报告（提交bug）
一份有效的缺陷报告要素通常包括：标题、前提、测试环境、操作步骤、实际结果、期望结果、出现的频率、优先级、严重等级、附件（一般是图片形式）。
另外还会有一些附加信息，如测试人员、开发负责人等。
标题：简明扼要，无歧义
优先级Priority（4个等级）：软件被修复的紧急程度
1–立即解决：缺陷导致系统几乎不能运行使用 或 严重妨碍测试的执行（需立即修改）
2–高优先级：缺陷严重，影响到测试了（当天或第二天要及时解决的）
3–正常：一般错误
4–低优先级：可以在开发有时间的时候处理，如页面文本框对齐显示
严重等级Severity（4个等级）：缺陷引起的故障对用户使用系统的影响
1–致命的：主流程不通，导致系统功能缺失、用户数据被破坏、系统崩溃、死机
2–严重的：影响流程的 比较严重的，比如系统主要功能部分未实现
3–一般：系统的次要功能没有完全实现，但不影响用户的正常使用
4–较小：操作不方便或遇到麻烦，但不影响功能的使用，如字体不美观、按钮大小不合适、文字排列对齐等（属于建议性或者美观方面的）
一般来说，缺陷越严重，优先级越高，但也有例外：
1）从用户角度看，缺陷不是很严重，但可能影响到测试执行了（优先级高严重等级低）
2） 有些缺陷比较严重，但由于技术的限制，暂时没法修改。这时优先级就降低了。有时候，用文字很难清楚描述缺陷，此时用图片（画笔指明问题）就很直观了。
3）如何有效的报告缺陷？
单一准确：每个报告只针对一个缺陷，如果有多个缺陷，可能开发只修正了其中一个，其他的没有得到修改，加长了缺陷的生命周期
可以再现：不能忽视或省略任何一项操作步骤，特别是关键性的操作，如描述的不够清楚，RD（Research and Development engineer）就会过来沟通怎么操作的，浪费了大家的时间
完整统一：完整的描述信息
短小简练：使用关键词
特定条件：有些问题只在特定环境下存在
文章来源：网络 版权归原作者所有
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系小编，我们将立即处理