软件测试项目心得：行业发展需努力，分享工作实践成果

从事软件测试工作将近十年时间了，近期在整理项目笔记之际意识到，众多新手依旧在反复踏入我们往昔所踩过的坑。这篇文章会将我这些年来最为关键的测试经验予以分享，全部都是实实在在的内容，不存在啰嗦多余之言。

测试模型选对事半功倍

先说说软件测试，它可不是一开始就着手去写用例的。在项目启动的那个时候，就得挑选好测试模型，其中最为常见的有两种，分别是V模型以及W模型。V模型会将开发阶段跟测试阶段逐一对应起来，这种模型适合那种需求清晰明确的小型项目。而W模型着重强调测试活动要与开发活动同步开展，在每一个开发阶段都存在与之相对应的测试，如此一来缺陷能够被更早地发现。

我们去年做了一个电商项目，前期运用了V模型，然而需求发生变更之时，测试用例全都得重新编写。之后改成了W模型，测试人员在需求分析阶段便介入其中，提前发觉了十几个逻辑矛盾之处，节省了后期大量的返工时间。究竟选择哪种模型，关键在于项目需求是否稳定。

需求分析决定测试成败

有不少测试人员，在拿到需求文档之后，便即刻着手去写用例，然而这实际上是一个极大的误区。理解测试需求并非单纯的去看那些文字，而是要深入剖析用户内心真正所期望达成的目标。举例来说，若用户声称“系统要快”，此类需求显得过于含混不清，尚需进一步细化成为“首页加载时间不得超过2秒”以及“查询响应需在1秒之内”这般具体明确的指标。

在针对某银行项目开展工作期间，需求文档撰写了200页之多，然而于测试环节却发觉，有三分之一的需求彼此间存在矛盾状况。随后依据3.2.1节所提到的办法，先行实施需求评审，将每一个功能点都逐一进行梳理通过一遍，在确证理解之后才着手开展工作起来。对于测试需求进行分析这是需要耗费时间的，不过这所花费的时间是值得的，它能够防止在后期出现大量的无效工作发生。

测试用例设计有章可循

将测试用例写好属于测试人员的核心能力范畴，一个完整的测试用例起码涵盖编号、标题、前置条件、测试步骤以及预期结果这五个要素，这便是 4.2 节所提及的最小集，众多新人倾向于写得极为复杂，实际上简单清晰才是最为关键的。

是找Bug最有效的手段之一的是边界值分析法，测试一个要求1到100数字的输入框时，不要只测50，要测0、1、2、99、100、101这些边界点，适合处理多个输入条件组合情况的是因果图法则，比如“如果用户是VIP且消费满1000元，则打8折”，这种逻辑用因果图能把所有测试路径清晰梳理出来。

测试工具实战技巧

以大幅提升效率的测试管理工具而言，于QC（Quality Center）里组织测试用例之际，提议依照模块 - 子模块 - 用例这般的层级结构去创建文件夹，依靠如此创建文件夹会对于查找便利以及维护便捷有所助益。测试需求与测试用例需要进行关联，可在需求变更之时能够迅速定位到受到影响的用例。

把测试需求从Excel导入，这可是个能够节省时间的技巧。首先呢，要将需求整理成具有固定格式的表格，这里面包括需求编号、名称、描述等字段。之后呢，用于批量导入系统，如此一来，能够省下最少半天的手工录入时间。定制字段功能同样是十分实用的，比如说像增加“优先级”“版本号”这些自定义字段，进而能够让需求管理变得更加灵活。

单元测试是质量基石

虽单元测试是由开发人员去执行的，然而测试人员在这其中是需要懂得进行审核操作的。单元测试的步骤具有这样一些，那便是准备测试环境，编写驱动模块以及桩模块，执行相应测试并且分析该测试的结果。测试内容所主要覆盖的方面包含函数接口，且有局部数据结构，还有独立路径，以及边界条件，另外还有错误处理这些方面的内容。

当进行单元测试用例设计之际，条件组合测试以及路径测试是不可或缺的。条件组合测试会将所有条件取值的组合情形予以覆盖，路径测试呢则可保证程序里的每条语句最少被执行一回。循环测试需要留意普通循环、嵌套循环以及边界循环的各异状况。在一个金融项目当中我们发觉，把路径测试做好能够将隐藏得最为幽深的逻辑错误发掘出来。

性能测试从规划到分析

性能测试并非仅仅录制个脚本就直接运行，首先得对性能需求加以分析，明确清楚用户数这一指标，明确清晰响应时间这一情况，明确精准吞吐量等类似指标，接着要展开测试场景的设计工作，针对单业务基准测试而言是去摸透每个接口所具备的基础能力，对于混合业务场景来说则是要模拟实际上真实用户进行操作的情形，测试数据务必要构造得真实，就好比在对登录功能进行测试之时，准备一万个彼此不同的账号相较于重复使用同一个账号会准确许多，就是这样。

处理服务器能力得提前去做估算，依据用户业务状况展开分析，进而预测高峰时段的并发量。在给一个政府项目开展性能测试之际，发现他们所估算的服务器配置严重欠缺，后续按照9.3节的方法再次计算，把配置从4核8G提升到16核32G，上线之后系统能够稳定运行。对测试结果进行分析需关注响应时间、TPS、资源利用率这些核心指标，定位到瓶颈之后开展调优。

缺陷分析与度量改进

并非单纯数个数那般简单的是缺陷统计，需从多个角度去展示数据，像是按照模块分布来展示，依照严重程度分布予以呈现，根据发现阶段分布来进行展现，这些图表能够直观地告知团队问题集中于何处，下一步应当侧重测试哪个地方，关于测试用例执行统计以及需求覆盖统计同样是颇为重要的，对于覆盖率低于90%的模块需要补充用例。

于给客户开展测试有效性剖析之际，需呈现出确凿的数据。我们时常运用的乃是缺陷检出率，其计算方式为“测试所发现的缺陷数量除以总的缺陷数目”。此一指标越高便意味着测试越具成效。另外存在一个指标为漏测率，即上线之后客户所发觉的Bug除以总的Bug数量。在某一项目当中我们的检出率达成了95%，客户极为满意，于次年再度签订了合同。

测试团队管理经验

依据项目规模来确定组建测试团队，小项目两三个人便足够，大项目或许需十几人甚至更多，每个岗位的职责要清晰明确，测试经理承担整体规划的工作，测试设计负责编写用例，测试执行承担跑用例的任务，缺陷管理员负责跟踪Bug状态。

体现在进度与质量这两个维度上的，是项目经理针对项目所实施的控制。我们每周都会召开一回测试进度会，会上会汇报诸如用例执行数、通过率以及未修复缺陷数等关键数据。测试用例度量能够从数量、质量以及效率这三个维度着手开展，就像每人每日编写用例的数量是多少，用例的缺陷发现率又是多少这样。这些数据对团队持续改进起到了助力作用。

测试报告的撰写方法

那份最终作为测试工作交付成果的测试报告，在其开头部分，得清晰明确出测试范畴，也就是要确切讲述明白测试过的那些模块都有哪一些，以及未曾进行测试的那些模块是哪些。而在它的测试环境部分呢，需要绘制出对应的部署架构图来，同时还要标注出其中服务器配置、网络拓扑以及软件版本这些相关信息。至于测试结果分析这一块，要涵盖需求覆盖状况、用例执行情形以及缺陷分布情况等方面。

在量化分析之中，需要给出确切具体的数字，举例而言，总共执行了多少数量的用例，通过率为百分之多少，发现了多少Bug，修复了多少，遗留问题具体是哪些。在测试结论方面，要明确地给出针对产品质量的评估，究竟是“可以上线”还是“建议延期”。我们存在着一个项目的测试报告，被客户评定为模板，原因在于数据足够充分、结论清晰明了、建议具备可执行性，是这样的情况。

最末想要询问诸位，于你所从事过的项目里，哪一个测试阶段最为易于出现问题，你又是怎样予以解决的呢？欢迎于评论区域分享你的经验，要是觉得这篇文章具备效用的话记得点赞收藏，以使更多测试同行得以看到。