你的测试流程复盘了吗?-软件测试从美好开始之二

发布于 2021-05-11 20:32 ，所属分类：软件测试工程师学习资料

我们，一起学习+涨薪不掉队！

转｜Mack gongzhong号 软件测试经验与教训

分享你的测试成长经历，吴老师免费送书！

在昨天的文章中，谈了关于测试前准备和测试需求分析阶段的注意点，今天继续我们昨天的话题。另外关于这两个阶段还可以看看我gongzhong号里的两篇文章《如何跟开发就测试范围进行沟通？》《如何学习？》

3、测试用例设计

测试需求收集完毕后，开始测试设计。测试用例是什么？测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。设计测试用例需要考虑以下问题：

3.1 测试用例的基本格式

多数公司都有自己的用例模板，作为新手前期先理解公司的用例模板即可。

有的公司模板规定的非常细致，也有的公司模板字段非常简单，这一般是跟公司所面临的现状有关。有能力的话可以尝试对模板进行优化——建议阅读这篇文章《如何使用测试文档》。

在我的QQ群（169974486）文件有一个PPT《测试用例&BUG描述》，里面有几个范例可以参考一下。

3.2 复用测试用例

现在很多软件公司都有意识建立自己的组织资产库（若没有你可以建议创建，一般老总都会同意的），在资产库里会有公司做过的项目的资料。在进行测试用例设计时，可以找一找其他项目中是否有可以复用的用例，特别是相同业务类型和相同软件结构项目的测试用例，会有很大的借鉴意义，甚至经过对测试用例简单修改就可以应用到当前被测试的软件。“ 拿来主义 ” 可以极大的开阔测试用例设计思路，也可以节省大量的测试用例设计时间。

除此之外，建议自己整理一些常见功能的测试用例库（如登录）、测试点，比如， WEB 软件系统在系统测试过程中，会有一系列的范式，比如针对接口就会有很多测试点。在设计测试用例的时候，不妨到网上去搜索相关的测试点，然后，在设计测试用例的时候不断的去完善它，以作为下次测试用例设计的基础。

我的群空间文件里有我整理的《黑盒测试框架》，可以作为参考。

3.3 加强测试用例的评审

参加用例评审可以迅速发现自己思维方式和文档编写上存在的不足，并快速的成长。文档评审有很多需要注意的地方，不过今天本文不做细述，如有需要加我聊吧（shalayang）。

3.4 定义测试用例的执行顺序

如何将测试用例跟版本迭代相结合，是让很多人包括资深测试人员苦恼的事情。

比较好区分的有如会导致服务器不稳定（或重启）的，这部分用例放在最后；或者测试进度紧张的情况下，把低优先级、耗时较多的用例进行裁剪......

不过更多的时候，我们的苦恼在于测试进度紧张，我们即使加班也难以完成工作，或者时间虽然相对宽裕，但某些用例看起来并没有必要一遍遍执行......在我带团队的时候，这类问题都是我负责决定，不会让测试工程师为这些事烦恼，所以作为新手，或许你可以在面临这类问题时跟领导进行沟通。这类问题的一般处理原则是根据重要程序分优先级，做测试任务裁剪。对我来说，可以接受下属十件工作完成8件（每件工作完成100%），但不能接受每一件都做，却都只完成80%。

另外，测试新手还会有一个困惑：当测试进度紧张时，是否可以抛开用例进行测试？对此我从测试管理角度说说我的看法。

如果测试的项目是一个不那么重要，或者业务逻辑比较简单的项目，而当我对测试负责人很熟悉，清楚他做事的态度和工作能力，那可以在这种时候抛开用例进行测试，以保证项目按时上线为主。

如果项目逻辑复杂或很重要，上线以后一旦出现问题非常严重，这个时候必须保证按照用例执行。如果项目经理以项目上线为理由来施压，那我们就以数据回答，告诉他以现在的人力资源，做了哪些事情，没做哪些测试，没做的测试可能带来哪些风险，让他自己决定是否一定要上线（他们一般会找高层或客户再次沟通）。如果是，那么上线后出现问题由他承担主要责任——这里顺便说一句，我坚持认为测试人员不应把自己当作“守门员”，我们在公司中应努力营造服务文化，而非“控制文化”。

4、测试用例执行

测试用例设计完毕后，接下来的工作是测试执行，测试执行中应该注意以下几个问题：

4.1 搭建软件测试环境，执行测试用例

全方位的观察测试用例执行结果：测试执行过程中，当测试的实际输出结果与测试用例中的预期输出结果一致的时候，是否可以认为测试用例执行成功了呢？答案是否定的，即便实际测试结果与测试的预期结果一致，也要查看软件产品的操作日志、系统运行日志和系统资源使用情况，来判断测试用例是否执行成功了。全方位观察软件产品的输出可以发现很多隐蔽的问题。以前，我在测试嵌入式系统软件的时候，执行某测试用例后，测试用例的实际输出与预期输出完全一致，不过在查询 CPU 占用率地时候，发现 CPU 占用率高达 90 ％，后来经过分析，软件运行的时候启动了若干个 1ms 的定时器，大量的消耗的 CPU 资源，后来通过把定时器调整到 10ms ， CPU 的占用率降为 7 ％。如果观察点单一，这个严重消耗资源的问题就无从发现了。

加强测试过程记录：测试执行过程中，一定要加强测试过程记录。如果测试执行步骤与测试用例中描述的有差异，一定要记录下来，作为日后更新测试用例的依据；如果软件产品提供了日志功能，比如有软件运行日志、用户操作日志，一定在每个测试用例执行后记录相关的日志文件，作为测试过程记录，一旦日后发现问题，开发人员可以通过这些测试记录方便的定位问题。而不用测试人员重新搭建测试环境，为开发人员重现问题。

及时确认发现的问题：测试执行过程中，如果确认发现了软件的缺陷，那么可以毫不犹豫的提交问题报告单。如果发现了可疑问题，又无法定位是否为软件缺陷，那么一定要保留现场，然后知会相关开发人员到现场定位问题。如果开发人员在短时间内可以确认是否为软件缺陷，我们可以给予配合；如果开发人员定位问题需要花费很长的时间，我们就没必要因此耽误自己宝贵的测试执行时间，可以让开发人员记录重现问题的测试环境配置，然后，回到自己的开发环境上重现问题，继续定位问题。

与开发人员良好的沟通：测试执行过程中，当你提交了问题报告单，可能被开发人员无情驳回，拒绝修改。这时候，只能对开发人员晓之以理，做到有理、有据，有说服力。首先，要定义软件缺陷的标准原则，这个原则应该是开发人员和测试人员都认可的，如果没有共同认可的原则，那么开发人员与测试人员对问题的争执就不可避免了。很多时候开发并不是不认可我们提交的问题，而是因为项目上线时间在压着（他们的口头禅：我们改不完），我们提交的bug在他们看来并不影响使用（他们也认可确实是有问题），那么我们可以从客户角度来跟他们晓之以情动之以理，若还不行，请测试经理去沟通。

及时更新测试用例：测试执行过程中，应该注意及时更新测试用例。往往在测试执行过程中，才发现遗漏了一些测试用例，这时候应该及时的补充；往往也会发现有些测试用例在具体的执行过程中根本无法操作，这时候应该删除这部分用例；也会发现若干个冗余的测试用例完全可以由某一个测试用例替代，那么删除冗余的测试用例。

总之，测试执行的过程中及时地更新测试用例是很好的习惯。不要打算在测试执行结束后，统一更新测试用例，如果这样，往往会遗漏很多本应该更新的测试用例。

4.2 学会安排自己的时间

要时刻认识到我们是不可能发现全部缺陷的。因为若要发现全部的程序错误，我们必须要检查所有可能有问题的地方，要在所有可能发生的不同条件下观察这些地方，还需要一种十分可靠的方法，当所有类型的程序错误发生时，都能够识别出来！如果测试员认为自己能够做到这些，那么要么是产品非常简单，要么测试员的想象力太差。

认识并承认自己不能做所有的事，并学习如何分配自己的时间。网上现在可以很方便的搜到一些时间安排的书籍，多看看。

4.3当心“完备的”的测试

有一些测试员承认自己不知道是否发现了产品中的全部问题，但仍然不准确的讨论结束测试的含义。我们常常听到这样一句话：“对这个产品我需要测试5天”这句话可以理解为，你在五天内对产品进行完备的测试，也可以理解为你会在五天内发现所有问题，这显然不可能的。

“完备性”测试常常是隐含地表达出来的，而不是明说出来的。不管是哪种情况，我们都很有必要小心的对待这个概念。

“完备的测试”都有哪些含义呢？比如说：