技术06期：测试系统软件需要重视哪几点？

导读

2007年5月18日，众多使用诺顿防病毒软件的中国个人用户和企业用户在重启系统后出现蓝屏，系统不能正常使用。即便诺顿当日下午便给出了解决方案，但他作为专业安全公司的信誉依旧受到了严重影响。

该事故源于诺顿当日在更新中将两个简体中文版的Windows系统文件误当成病毒。这个本该在实验室测试中轻易发现的问题，却由于技术或管理种种原因被疏漏了。

因软件缺陷而导致重大负面影响或巨大损失的例子数不胜数，业内顶级厂商也不能幸免究其原因，几乎都归入软件测试不够充分。由此可见，一方面是软件测试的重要性，另一方面是做好软件测试不是一件容易的事情。

▐ 如何做好软件测试？

软件测试流程图

❶ 需求分析，发挥主动性

正常的需求在产出时，产品要分析该需求的价值，影响范围和实代价的。

可是目前大多情况属于有需求就组织评审，然后开发测试与上线。

产品主导型的开发模式非常常见，作为测试我们无法主导需求和项目。在需求评审时，作为一个测试人员必须了解这次需求的内容，影响到哪些现有的功能，涉及到的操作系统或是类别等，然后准确的评估出工作量，防止因评估不足造成后期测试不充分。

再者，关注开发和产品的讨论，如果开发说哪一部分比较难实现，最后如何实现？其中做出的变动和难点就是测试时必须重点关注的部分。不能因为这些暂时和你没有联系就忽略，后期会带来很大的麻烦。

❷ 用例设计与评审，做到不遗不漏

测试用例是每个测试人员工作过程中必须要完成的工作。在测试工作中用来指导测试工作，而且是相关业务的一个文档沉淀。

► 测试用例要素：

测试用例名，执行步骤，预期结果这三点是必须要写清楚的。再者就是测试方案选择必须全面，作为测试人员必须能根据需求想到要实施哪方面的测试。

► 设计用例时，要设计两类：

一类是开发自测和验收提测试标准的冒烟测试用例，一类是针对需求的全面测试用例。

写完用例要主动联系相关人员进行用例评审，强调开发自测，在评审过程是及时修改不合适的用例。

❸ 测试流程，注重项目控制

其实项目的流程控制在需求开始的时候就应该重视起来，只是很多时候我们没有意识到这是测试的工作。有的是产品来控制，有的是专门的项目经理来控制。测试人员是一线的工作人员，必须具备关注整体项目的意识。

需求一旦明确就要时刻按排期来关注项目的情况。中间变更需求的时候，要评估是否影响项目进度，如果影响了重新进行排期。如果开发提测试晚了，是否影响上线时间，如果可能会影响，马上就要给相关的人员发预警邮件，通知大家详细的情况。

同时在测试过程中，发现了bug必须详细描述问题，不管是jira，禅道或是其他的bug管理方式，一个bug要写清楚以下几点：Bug问题描述，bug重现步骤，是否有前置条件，预期结果，实际结果，以方便开发去进行修改。同时给bug准确分级，实时跟踪进度，保证项目按期完成。

❹ 上线回归与项目总结

一个需求上线完成后，要及时进行线上回归，提醒相关的人员进行自动化线上回归或是监控工作。同时必须回归我们在需求评审的时候考虑到的可能影响到的原有的功能，以确保新功能的完全上线成功。

而作为测试人员，在一个项目完成后，不管公司是否要求，需要对项目做相应的文字总结。总结整个项目过程中遇到的问题，最后的解决办法或是当时讨论的处理办法，有哪些需要注意的问题？有什么可以借鉴的方案或是改进策略？项目中有没有通用性的问题等等。

如果公司有相应的项目总结方案，那测试时需要多关注一些数据。如冒烟测试是否一次通过，Bug数及不同级别的bug数，参与开发人员对应的Bug数，提测试次数，上线次数等等。而后借助于第三方工具进行图表化相应的数据，然后相关问题的总结，改进方案都需要进行详细的总结。

总结：

测试，从来都不简单，也容不得半点马虎，只有知行合一，踏踏实实把每个环节做到极致，才能通过用户应用的最终考验。

关于我们

▼

如果您感兴趣，欢迎加入PUSHI AI社群，共同探索AI。关注普适极客►申请“入群”，不定期还有福利活动噢~

导读