软件测试是软件开发中非常重要的一环，今天就软件测试的基本工作过程为大家整理一些简单的介绍，方便日后的工作和学习。
什么是软件测试？
特定的环境、特定的条件下运行软件，验证其能正常运行，并发现其缺陷，对软件的质量进行评估的过程。
软件测试的工作过程有哪几步？
需求、计划、方案、用例、执行、总结。
1、测试需求
测试需求分析：分析识别测试范围，解决测什么的问题，方便测试的跟踪和管理。
测试需求分析的流程：需求采集—>需求分析—>需求评审。
测试需求分析的评审：完整性、准确性、一致性、易理解性、无歧义性。
测试需求分析的时间：开发需求完成后。
参考依据：
（1）狭义依据：需求规格；
（2）广义依据：参照上面的测试需求分析来源。
在测试需求不明确的情况下，如何保证测试质量？
（1）多方收集需求；
（2）多与开发人员沟通；
（3）若有以前的系统，参照以前的系统；
（4）找类似的产品熟悉；
（5）到网上查找与系统相关的业务知识、专业术语。
测试需求分析的来源：
（1）开发文档：需求规格、概设、详设、数据库结构设计文档、模块功能图等；
（2）用户需求：与用户或需求分析人员沟通，需求调研的会议纪要，与用户邮件往来；
（3）软件雏形：可运行软件，软件的框架；
（4）相关的规划及标准：各行各业的标准、国家标准、行业标准、企业标准、项目标准、国家法律法规；
（5）类似的产品：公司内部相同的旧版本产品，行业其他公司类似的产品；
（6）测试知识经验库：测试人员的业务背景、系统业务知识的积累、个人的测试经验积累；
（7）其他隐性的需求：产品利益相关者的建议、会议纪要、备忘录、沟通记录、邮件往来等。
测试需求分析的内容：
（1）业务流程图的分析；
（2）用户和角色的分析；
（3）数据库结构的分析；
（4）测试要点的分析。
测试需求分析的方法：
（1）测试功能点分析法；
（2）功能交互分析法；
（3）质量特性分析法；
（4）测试类型分析法。
2、测试计划
测试计划：管理层文档，对测试过程、测试活动起到指导的作用，解决做什么的问题。
测试计划编写时间：测试需求完成之后。
评审人：项目经理、QA、开发、产品、设计人员。
输出文档：总的测试计划文档。
测试计划的内容：
（1）项目背景，缩略语（专业术语）；
（2）测试的参考文档、测试的交付文档；
（3）测试目标、测试范围、测试环境、测试工具、测试策略、测试风险；
（4）人力资源的分配、工作量的估算；
（5）测试时间、进度安排、任务分配、培训计划等；
（6）出入口准则（准入准出标准）等。
测试风险：质量、时间进度、成本、变更、人员变动等；
QA与QC的区别：QA为质量保证、QC为质量控制。
冒烟测试：在测试之前，对软件进行可测性检查，保证基本功能，基本流程可通，提高工作效率。
回归测试：包括完全回归和部分回归（根据操作频率和风险选择）。
集成策略：
（1）非增量式集成：大爆炸式集成；
（2）增量式集成：自顶向下、自底向上、三明治。
测试准入条件：
（1）测试用例编写，测试评审完成；
（2）开发人员完成编码，并完成自测；
（3）冒烟测试通过；
（4）开发组提交了测试申请单；
测试准出条件：
（1）时间标准：项目时间用尽；
（2）缺陷修复：致命/严重缺陷比率为0%，一般<5%，轻微<10%;
（3）测试用例执行覆盖率为100%；
（4）测试用例对需求覆盖率>95%；
（5）缺陷修复率达到一定的标准；
（6）收益比：存在bug，但是修复需要花费的时间大于受益，测试停止；
（7）完成软件测试验收报告，并且报告结果达到认可。
3、测试方案
测试方案：技术层面文档，主要对被测软件测试特性、方法、环境等进行规范，解决怎么做的问题。
测试方案的编写时间：测试计划完成之后。
参考依据：测试计划、测试需求分析、测试规格、概设、详设。
评审人员：测试人员、开发人员、项目经理、QA。
测试内容：
（1）项目背景、测试目标、测试范围、测试环境、测试策略、测试工具；
（2）测试特性的分析；
（3）测试特性方法的分析；
以最少的用例更全面的覆盖需求，测试不能发现潜在的缺陷；
缺陷的级别：致命、严重、一般（不超过15%）、轻微（不超过20%）、建议。
缺陷处理状态迁移图：新建—打开—已修正—已关闭—拒绝—延迟—重新打开。
缺陷优先级的考虑方面：
（1）缺陷本身的严重级别；
（2）功能的重要性方面；
（3）功能发布的时间进度；
（4）功能的可见性方面；
（5）从操作频率方面；
（6）从安全性方面。
4、测试用例
参考依据：参考方案、需求分析的结果、需求规格。
评审人：测试工程师、QA、开发人员、测试经理。
输出文档：测试用例文档。
用例设计需考虑的方面有哪些（以最少的用例更全面的覆盖需求，以此发现更多的缺陷）？
（1）编写所有必填项（一个用例）；
（2）编写所有项包括必填和非必填（一个用例）；
（3）一个完整的流程一次性走完（一个用例）；
（4）编写预期结果：包括前台、后台、数据库等方面；
（5）新增和修改的链接为同一界面（代码一致为前提）：在修改中只需测试进入界面的默认情况，其余字段只需在新增上测试，修改所有字段点击保存、重置，修改后直接返回需要提示；
（6）删除：子信息有调用情况（全删、不能删除），例：品牌和商品，删除品牌时则提示，物理删除：可到数据库中回滚，数据库不存在；标志删除：到回收站用来做历史记录，后台可看，前台不可；
（7）登陆：账号长度限制，正确登陆，不正确登陆；
（8）业务流程图：场景法、基本流和备选流，串行用乘，并行用加；例：银行取款流程图；
（9）查询：精确查询和模糊查询，like“%x%”；多条件搜索可用正交法、再补充。
测试用例过程：
（1）输入—动作—输出；
（2）输入—测试环境—测试目的—执行条件—动作—输出；
（3）为了达到某种特定目标而设计的一组测试输入、执行条件和预期结果，其目的是为了检测某个程序或何时是否满足某个特定的需求。
测试用例的作用：便于软件质量的度量，方便测试任务的跟踪管理，方便缺陷的提交。
如何衡量测试用例的好坏：清晰、准确、完整、简洁、一致。
黑盒测试用例设计方法：包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。
白盒测试用例设计方法：语句覆盖率、条件覆盖率、判定覆盖率、条件判定覆盖率、组合覆盖率、路径覆盖率。
关于因果图法：
（1）因果图关系：（输入与输出）恒等、非~、与^、或V；
（2）输入约束：异E最多只能一个为1、或I最少有一个为1、唯一O有且只有一个唯一；要求R两个取值一样如C1为1C2也为1；
（3）输出约束：强制M两个输出互异。
#对于搜索框的测试用例设计#
（1）单个条件；
（2）所有条件；
（3）任意几个条件组合：应用正交实验法再补充情况；
（4）不符合条件查询；
（5）条件中有相互冲突的条件，需单独测试；
（6）输入合理的查询条件后，点击返回需有提示。
5、测试执行
参考依据：测试用例（需求）。
输出：缺陷报告。
测试执行注意事项：
（1）注意用例执行的先后顺序：数据流向、优先级、时间进度安排；
（2）执行的前置条件、测试环境、备注里的特殊说明；
（3）发现问题/缺陷时，应立即保留证据，再重现缺陷；
（4）缺陷至少重现3次，并初步定位到问题；
（5）测试过程中，根据实际情况维护测试用例。
测试用例的执行结果：
（1）未测试：Not test；
（2）通过：pass；
（3）失败：failed；
（4）阻塞：black；因为其它的问题导致用例无法执行；
（5）观察：investigates。
Q：什么时候需要维护测试用例？
（1）需求、编码、设计发生了变更；
（2）执行过程中发现用例描述有错误；
（3）发现的缺陷不能对应用例，需补充用例；
（4）发现重复、冗余的用例需删除；
什么是缺陷（遗漏、错误、额外实现）？
（1）需求规格说明书中明确要求实现的未实现；
（2）需求规格说明书中虽未明确规定，但实际需要实现的缺陷；
（3）未正确实现（错误实现）；
（4）实现了需求规格中明确不需要的功能（额外实现）或实际不需要的功能；
（5）性能、易用性等方面，站在用户的角度，会认为不够完美的。
bug的内容：bug描述、重现步骤、实际结果、预期结果。
缺陷的生命周期：
提交->确认->分配->修复->验证->关闭
缺陷的内容：
缺陷编号、模块、项目名、版本、缺陷标题、缺陷级别、优先级、缺陷类型、测试环境、缺陷描述（bug描述、重现步骤、实际结果、预期结果、修改建议）、状态、缺陷引入原因、缺陷引入条件、发现人、发现时间、修改人、修改时间、关闭人、关闭时间、附件、对应的用例编号。
对于偶然发现，并难以重现的缺陷如何处理？
（1）先保留证据（抓包、截图、视频等）；
（2）本机重现问题，无法重现则换电脑重现；
（3）若重现，则根据缺陷的实际影响情况定义缺陷的严重级别；若无法重现，则找开发人员协助重现；在开发人员的协助下仍未能重现，则需要对此问题边重现边录视频（最多两小时），若2小时内重现则从发现问题的前半小时开始分析，若2小时内未重现，则需直接提交缺陷，降低缺陷的级别，将缺陷改成延迟状态，该缺陷至少历经半年或者在用户现场历经多个版本后关闭。
6、测试报告
定义：对于测试过程、产品质量进行评估，并对测试结果进行总结、下结论。
依据：测试用例的执行情况，缺陷数据的统计结果。
评审人：整个项目人员。
测试报告评估人：测试经理、测试人员。
测试报告的内容：
项目背景、测试目标、测试范围、测试环境、测试策略、测试工具、测试人力资源、测试时间、测试用例数据统计、缺陷数据统计、遗留问题、测试风险、测试过程开发、产品质量评估、测试结论、经验教训与建议、附录。
编写测试报告的目的是什么？
（1）用于项目经理决策提供依据；
（2）用于下一个项目维护提供方便；
（3）对测试进行评估。
www.learun.cn
资料：windy
网友评论