本文探讨了单元测试不仅是测试手段，更是改善代码设计的工具，强调TDD和BDD在敏捷开发中的重要性。提出了快速执行的单测、数据驱动测试和Mock工具的使用方法。同时，介绍了如何制定合理的测试策略，平衡测试资源与迭代速度。安全测试应融入日常工作中，涵盖需求评审、代码扫描和敏感数据保护等多个环节。此外，分享了设计文档的编写要点，以及团队协作和写出优秀设计文档的技巧。
转载自软件测试周刊
1.单元测试只是测试吗？
阿里巴巴技术质量
单元测试只是测试吗？作者认为单元测试除了是一种测试手段外，更是一种改善代码设计的工具，容易写单测的代码往往也具有更加良好的设计。因而是任何自动化测试工具都无法取代的。
这里需要强调一下 “工具” 属性，工具能放大人的智力或者体力，让干活的时候不会这么累，比如你去种树带把铲子，你肯定不会把铲子当成负担的，因为他是你种树的工具，你写 Java，肯定不会因为 IDEA 启动时间长，就把它当成一种负担，因为 IDEA 也是你写 Java 的一个工具，很多人把写单测当成一种负担，往往就是没有意识到"单测"是一种工具，单纯把他当成一种测试。
a. 为什么单测能够验证代码结构的合理性？
b. TDD 和 BDD 会严重拖慢敏捷迭代速度吗？
人们往往会觉得 TDD 和 BDD 会严重拖慢迭代速度，值得讽刺的是，TDD 和 BDD 恰恰是敏捷开发实践的重要组成部分。我们学习敏捷开发的时候，不能只学习到它的 “快”，而忽略了敏捷开发所提出的质量保证方法。敏捷开发所谓的“快”，是指在代码质量充分保证下的“快”，而不是做完功能就直接上线。
c. 如何做单测？
- 执行速度：全量跑一次单测要在 30 秒到几分钟内，否则就失去了单测的意义。
- 数据驱动测试：将测试用例的逻辑与数据分离，测试代码依次读取测试数据，校验其是否符合预期。这样不用写代码就实现了用多组测试数据进行测试的目的。
- 用好Mock工具：Mockito 是用来测试少量的不得不进行外部调用的代码。PowerMock 是用来测试设计得不好的遗留代码的。
d. 如何学习写单测？
多实践，多看看别人好的单测怎么写，比如学习一些公认优秀的开源项目。
2.测试策略模型探索
搜狗测试
测试作为软件质量的把控，经常存在这样的一个误区：所有提测的功能都需要进行全面的测试，否则上线后就可能存在质量风险。而此时，也会迎来项目经理的质疑，此需求开发一周，为啥测试需要两周，测试为啥这么久？
迭代中总会遇到测试资源和时间很紧张的状态，对我们来说，如何制定一个合理的测试策略，在有限的测试资源下既能保证产品质量也能满足产品迭代周期？
测试策略的理解
”测试策略“即：”测什么“和”怎么测”。具体可以按照以下6点问题进行回答，分别是：
① 测试的对象和范围是什么？
② 测试的目标是什么？
③ 测试的重点和难点是什么？
④ 测试的深度和广度是什么？
⑤ 如何安排各种测试活动（先测试什么，再测试什么）？
⑥ 如何评价测试的效果？
测试策略的制定思路
3. 从零开始内建你的安全测试流程
福禄网络研发团队
安全问题，没发生的时候我们可以侥幸，一旦发生生产安全问题，对很多公司来说可能就是黑天鹅事件了。平台的安全，是我们测试中不可舍弃的一环，而且需要长期持续的关注。
但是很多公司没有专职的安全测试，首先是专业性较强，要做好不容易，其次是不一定比第三方安全平台更划算，那我们该怎么做呢？
作者的思路是将安全测试融入日常的测试工作：
- 需求阶段：用破坏性思维去评审需求
- 代码层面：使用静态代码扫描和第三方组件扫描
- 数据脱敏：在存储和传输时对敏感数据加密
- 跨目录权限
- 跨站脚本
- SQL注入
- 越权：对用户权限进行测试
- 上传下载：对文件大小、文件类型和文件内容进行限制。
- 服务器端口：通过nmap进行服务器的端口扫描，非必须的端口要关闭
- 业务需求维度：如密码强度、验证码等
工具
1. 将文本转换成手写体的工具 - Text to Handwriting
开源前哨
一个印度小哥说：我讨厌编写作业，所以我做了这个工具，可以将文本转换成看起来像手写的一样。
于是 https://github.com/saurabhdaware/text-to-handwriting 就诞生了。
效果如下：
在线使用 https://saurabhdaware.github.io/text-to-handwriting/
2. 可视化访谈结果 - 移情图？
PM搞事情
在访谈中我们很容易引导被访谈者朝着自己希望的方向去思考，这样往往会失去一些客观性，我们更希望的是，对方按照自己的角度去感同身受的思考问题。同时我们也想用一种更好的方式记录下访谈结果，将内容更方便的传递给需要的人。怎么办呢？ 移情图（Empathy Mapping）是一个好工具。
移情图，又叫共情图，是由 XPLANE 公司的创始人 Scott Matthewe 发明的，是在深入了解用户需求时会用的一种设计策略，通常在访谈后立即完成制作。
在进行用户研究时，它不仅可以帮助我们有效的捕获有关用户的行为和态度，同时还可以帮助我们将其结果可视化地传达给同事，使整个团队都能站在用户的立场，感同身受的理解需求本身，并以此为共识，对齐目标，将整个团结起来。
最常见的移情图模型：一个正方形，被分成了几个象限，中间一个大圆圈，代表用户，其他每一个象限都代表了一个维度空间，分别为：所思和所感（Think & Feel）、所听（Hear）、所看（See）、所说和所做（Say & Do）、痛点（Pain）和收益（Gain）。之所以把痛点和收益单独放在底部，是因为这两个维度将直接决定用户是否选择使用我们的产品，我们的产品是否能帮助他们解决痛点或从中获取收益。
3. 一个简单的 Mock 工具 - Moco
搜狗测试
Moco 本身支持 API 和独立运行两种方式。通过使用 API，开发人员可以在 JUnit、JBehave等 测试测试框架里使用 Moco，极大程度地降低了集成点测试的复杂度。
Moco 可以提供以下服务：
• HTTP APIs
• Socket APIs
• REST API
开源地址：https://github.com/dreamhead/moco
方法
1. 团队制胜六步工作法
中生代技术
三条非常重要的原则：
原则 1：人的问题是技术团队最根本的问题
原则 2：团队中每个成员都是不错的
原则 3：能简单决不复杂
2. 如何写出一份优秀的软件设计文档
架构之家
设计文档是确保正确完成工作的最有用工具。它的主要目标是通过强迫你思考设计并收集其他人的反馈来提高你的效率。作为一般经验法则，如果你正在处理可能需要 1 个工程师月或更长时间的项目，那么你应该编写设计文档。但不要止步于此 - 许多小型项目也可以从迷你设计文档中受益。
设计文档中应该包含哪些内容？
• 标题和参与者
• 概览：高度概括且内容能让公司所有人都读懂，不超过3段。
• 背景：描述项目的必要性以及跟技术战略和产品战略的关联性。
• 目标和非目标：描述项目的目的和可衡量的目标，非目标是指不会修复哪些问题。
• 里程碑：一个可衡量的检查点列表
• 当前解决方案：描述当前实现，并提供流程图/用例图。
• 推荐解决方案：系统架构，有细节。
• 替代方案：除了上述的解决方案，你还想到了什么？购买第三方解决方案？或者使用开源的？优缺点都有哪些？
• 监控和警报
• 跨团队配合方面：工作量？钱？性能？安全漏洞？副作用？
• 讨论：任何你不确定的公开问题或有争议的决定等。
应该怎么写呢？
• 写得尽可能简单，使用简单的话、短句、列表、例子等。
• 添加大量的表格和图示，包括数字。
• 试着写的有趣，提前发给他人审核。
言论
1、程序员最大的谎言是什么？
图片
1、这不是 Bug，是一个 Feature。
2、技术面试 VS 实际工作
如果对软件测试有兴趣，想了解更多的测试知识，解决测试问题,以及入门指导，帮你解决测试中遇到的困惑，我们这里有技术高手。如果你正在找工作或者刚刚学校出来，又或者已经工作但是经常觉得难点很多，觉得自己测试方面学的不够精想要继续学习的，想转行怕学不会的， 都可以加入我们==
==，群内可领取最新软件测试大厂面试资料和Python自动化、接口、框架搭建学习资料！
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
