软件测试周刊（第14期）：质量保障的趋势

这里记录过去一周我们看到的软件测试及周边的行业动态，周五发布。

本周刊开源（GitHub: SoftwareTestingWeekly ），欢迎提交 issue，投稿或推荐软件测试相关的内容。

科普

边缘计算

维基百科上的定义：

边缘计算（Edge computing），是一种分布式运算的架构，将应用程序、数据资料与服务的运算，由网络中心节点，移往网络逻辑上的边缘节点来处理。

边缘运算将原本完全由中心节点处理大型服务加以分解，切割成更小与更容易管理的部分，分散到边缘节点去处理。边缘节点更接近于用户终端设备，可以加快资料的处理与发送速度，减少延迟。

在这种架构下，资料的分析与知识的产生，更接近于数据资料的来源，因此更适合处理大数据。

知乎「溪亭日暮」的回答更容易理解：

边缘计算是将计算资源部署靠近用户和数据源的网络边缘侧，通过更靠近数据源的位置（如路由器、基站）执行计算，为用户提供高带宽、低延迟、低能耗、高安全的计算服务。

边缘计算与云计算，两者最直观的效果区别， 打个比方：

假设不使用边缘计算，服务器可以接 1000 个设备。而如果使用了边缘计算，服务器则可以接 10000 个设备。

提升了一个数量级。

 

云计算、雾计算和边缘计算的区别是什么？

 

知乎「与子同袍」的比喻非常形象：

• 每户市民自己进行分拣处理垃圾，叫边缘计算。
• 垃圾在垃圾桶侧、垃圾车、垃圾站处理，叫雾计算。
• 把垃圾不管三七二十一，先拉到垃圾场集中处理，叫云计算。

文章

1. 为什么所有APP都想访问你的通讯录？

潘涛

你有没有过这样的经历，在跟朋友聊天提及某个物品时，很快就在电商平台获得了相关推荐，可能你之前压根儿就没搜过。

 

是不是很神奇？其实一点儿也不神奇，就是隐私泄露了。

 

周鸿祎曾经说过，一些 APP 会偷偷录音或者拍照，然后给我们推送喜欢的内容。

 

电话、定位、拍照、录音……手机 APP 的权限几乎已经渗透到了日常生活的每个方面，它们在记录、上传、分析你的喜好、关系网... 而这些权限的使用居然都是你默认同意的。

 

作者调研了 20 款头部 APP，其中有 17 款想要通讯录权限，甚至有些 APP 还申请了「新建/修改/删除联系人」权限，更有甚者还想要「读取通话记录」。

 

为什么所有 APP 都想访问你的通讯录？

 

因为平台需要更多的用户信息。

 

在大数据时代，掌握信息就意味着掌握了金矿，这早已不在是什么服务的必要性，而是一种商业趋势。通过不断地给用户的社交关系、日常习惯以及消费行为等信息贴“标签”，最后汇聚成的就是每一个人的用户画像。

 

企业有了用户画像，所有的短视频、信息流、广告都能以最精确的方式触达用户，而不用再拐弯抹角寻求它们可能的受众。

当然，也包括为你个性化定制的广告。

 

如何避免隐私泄露呢？

1. 在权限申请方面，iOS 比 Android 更谨慎，所有权限都可以手动打开或关闭。
2. 要从正规的应用市场上下载 APP。
3. 注意 APP 想要申请的权限，别随意授权。
4. 把乱申请的 APP 移出你的手机。

2. 软件质量保障的发展趋势是什么？

林冰玉

2020 年 11 月凯捷（Capgemini）发布了第 12 期《World Quality Report 2020-21》，本文尝试进行解读。

 

日趋成熟的工程实践给质量保障带来了很大的便利，但核心的测试思维模式仍然至关重要，人们对质量保障的期望也越来越高。

先说目标

质量保障和测试的目标早已不是发现 BUG 这么简单，而是：

1. 保障业务：业务是企业存活的关键，QA 需要为业务增长和业务成果作出贡献。
2. 把关质量：在上线前发现尽可能多的缺陷是 QA 的最基本职责。
3. 保障用户体验：人们对产品质量的要求越来越高，QA 确保终端用户满意度和用户体验。
4. 保护品牌形象：质量的好坏会直接影响到品牌形象，QA 多了项保护企业形象和品牌的目标。
5. 质效双赢：既要快速交付，又要保障产品的高质量。
6. 自动化：完善的测试自动化和流程自动化是高质量交付的前提，要让质量保障流程更加智能化。
7. 质量赋能：好的质量需要团队协作已然达成共识，为团队中不同角色赋能，助其快速完成质量检测就成了目标。

 

再说趋势

趋势 1. QA 在敏捷和 Devops 团队里承担质量协调者角色

随着敏捷和 DevOps 的普及，QA 需要在团队承担起质量协调者的角色，这就要求 QA 不仅要有技术能力（如自动化测试），还要有测试思维和较强的分析能力。

 

应对此趋势的策略有：

• 研发团队共同承担质量保障职责，测试不仅要左移，还要右移。
• 质量不仅是研发部门的事，业务部门也同样需要重视质量。
• 研发团队需要跟业务走得更近才能更好的理解业务，为业务服务。
• 将质量数据可视化，让大家更清晰直接的了解质量状态。
• 跟用户更多的沟通，主动寻求反馈，不断改进产品质量。 

 

趋势 2. 对人工智能（AI）和机器学习（ML）寄予厚望

大家对 AI 和 ML 给质量保障带来收益的期望还是很高，但实际在应用上没有显著的进展，这主要跟相关技能欠缺有关。

 

即便如此，很多组织还是将其放在新的质量保障解决方案和工具的选择标准中，他们认为，智能技术将提高成本效益，减少手动测试，缩短产品上市时间。

 

应对此趋势的策略有：

• 专注于重要、投入产出比更高的事情。
• 持续学习，加强相关知识和经验的积累。
• 鼓励团队采用有 AI 功能的工具，制定 AI 系统的测试策略，从现有的最佳实践学习积累。

 

趋势 3. 控制质量管理预算和成本

数字化转型加速导致需要管理的线上资产增加，质量管理成本控制面临更大的挑战。企业都在思考如何降本增效，一方面降低人力成本，另一方面在考虑通过采购工具、测试环境迁移到云端、引入新的（AI、ML 和测试自动化）技术来降低成本。

 

应对此趋势的策略有：

• 测试基础设施迁移到云，减少测试环境和测试工具的成本。
• 采用分析技术、AI 和 ML 增加测试的智能化。
• 高薪聘请更聪明的人，加强公司内部人员能力建设，可以借用外部优秀的力量对已有人员进行培训。
• 从整个交付团队的角度来确定那些最有价值、最具潜力的质量保障计划，采用最高效的方式实现。

 

趋势 4. 加强自动化测试能力的建设

自动化已经成为数字化转型的核心，不仅是测试自动化，也包括流程自动化。有 37% 的人认为自动化带来了期望的收益，但另外的人认为并没有。原因是跟如何度量收益有关，也跟人员能力有关，能力跟不上就无法发挥工具的最大作用。

 

应对此趋势的策略有：

• 改变由于交付压力导致的测试时间被压缩的现状，通过自动化，测的更快，而不是测的更少。
• 工具选型时把眼光放长远，要考虑兼容性和可扩展性，要能应对业务和技术的变化。
• 在自动化和技能需求之间求取平衡，组织要减少对某种技能的依赖，或者使自动化更具包容性。
• 没有一个工具能搞定一切，需要按需采用适合的工具。
• 尝试智能化，利用 AI 和 ML 技术处理自动化中的挑战。

 

趋势 5. 新技术应用于测试环境管理（TEM）和测试数据管理（TDM）

 

发展趋势：

• 采用云和基于云的技术来管理 TEM 和 TDM 需求。
• 开发管理测试数据的工具，尽管大多数用于数据脱敏。
• 服务和数据虚拟化技术也已应用于 TEM 和 TDM。
• 流程和治理比技术面临的挑战更大。

 

应对此趋势的策略有：

• 组织内创建可以共享的 TEM 和 TDM。
• 共建 TEM 和 TDM，尽享其所有功能。
• 制定成熟的 TEM 和 TDM 治理方案，保证可用性。

3. 关于「需求」我的 N 条经验

老K

关于需求的来源：

1. 正经的需求来源于：用户和数据。但是数据也是用户产生的，所以：需求来源于用户。
2. 上述结论对于乔布斯这样的天才无效，人家是先把产品做出来，然后再告诉用户你有这个需求。
3. 竞品是不是需求来源？是，但这类需求来自竞品的用户。
4. 不正经需求是怎么来的？是老板、产品经理拍脑袋想出来的，这些大多是伪需求。
5. 拍脑袋这事儿，C 端产品经理常干！B 端产品经理想干，但拍不出来...

关于需求的定义：

1. 定义需求的需要：

• • 用户：广义的用户，包括线上产品的用户和公司内部的市场、运营、客服等等…
  • 场景：不同用户在同一场景下需求是不同的，同一用户在不同场景下需求也是不同的。

1. 「如实记录用户想要的产品功能」是需求调研时常见的误区，产品经理要做的是挖掘背后的原始需求。

关于需求的真伪：

1. 转述需求一定失真，不要听销售/客服转述用户需求，要直接从真实用户处获取。
2. 需求有真伪之分，伪需求肯定不会做；真需求，也不一定会做，还要看需求覆盖用户量、用户使用频次、迫切程度、付费意愿等等…

关于需求的管理：

1. 带有政治任务的需求无视上条规则，优先级 P0！
2. 众所周知，“已经记入需求池了”是不做的意思。
3. 需求管理的第一课：学会拒绝需求。

关于需求的变更：

1. 产品经理最痛苦的事儿莫过于在开发过程中改需求，比这还要痛苦的是在测试过程中改需求。
2. 需求变更的原因很多：原始需求有误、不清晰、不完善；业务变化、环境变化导致需求变化；想出更好的解决方案等；
3. 在改需求这件事儿上，其实产品经理的抵触情绪比开发更强烈，但我们往往是先说服自己再去跪求开发。

工具

1. 一款专注记录分析移动端操作行为的利器：DiDiPrism

 

如何能从上帝视角来理解用户，让我们知道用户到底是如何使用我们精心设计的产品的？ 埋点。

 

滴滴开源了一款专注记录分析移动端操作行为的工具：DiDiPrism（小桔棱镜），提供了APP操作回放、操作检测、以及数据可视化能力。

DiDiPrism 的能力：

• 操作回放：视频回放 / 文字回放
• 端侧实时操作行为检测
• 数据可视化（待开源）

DiDiPrism 的亮点：

• 零入侵：业务代码无需任何适配。
• 高可用：各项能力已在生产环境平稳运行一年以上。
• 丰富灵活的操作行为策略支持：基于 DSL 实现丰富的操作行为策略支持。
• 功能全面：围绕移动端操作行为全方位能力覆盖。

 

开源地址：https://github.com/didi/DiDiPrism

2. 一键搜尽天下藏书（电子书）：熊猫搜书

同时搜索 20 多个网站的电子书，总有你想要的：

https://ebook.blinkol.com/#/

方法

1. 如何在GitHub上面精准搜索开源项目？

觉非

在 GitHub 上一个开源项目有很多关键的信息，如：

• name: 项目的名称
• description: 项目的简要描述
• README：README.md
• stars：项目的点赞/喜欢/收藏数
• forks：项目的拷贝数
• pushed：项目的更新日期
• language：项目的编程语言

 

这些信息都是可以用于精准搜索的。

 

比如：搜索描述信息中有 test 的 Python 项目。

 

搜索信息就是：in:description test language:python，结果如下图所示：

 

更多搜索的技巧：

先指定按什么搜索？

• 按项目名称搜索：in:name xxx
• 按 readme 搜索：in:readme xxx
• 按 description 搜索：in:description xxx 

再增加筛选条件：

• stars 数量大于 xxx: stars:>xxx
• forks 数量大于 xxx: forks:>xxx
• 编程语言是 xxx: language:xxx
• 最后更新时间大于 YYYY-MM-DD：pushed:>YYYY-MM-DD

2. 如何测试iOS的耗电量？

搜狗测试

耗电量是衡量 APP 性能表现的一个重要指标。耗电量与很多因素有关，比如定位的精度，界面的卡顿，网络的乱用等。

耗电的概念：

• Idle ：表示 APP 处于休眠状态，几乎不使用电量。
• Active：表示 APP 处于工作状态，用电量比较高，不同的高度意味着不同的工作。
• Overhead：表示调起硬件来支持 APP 功能所消耗的电量，这部分是支持硬件工作必要的电量消耗。
• Fixed Cost（固定开销）：横线以下所包区域是固定开销。
• Dynamic cost（动态开销）：横线以上所包区域是动态开销。

 

省电的四个基本原则：

• 识别：明确 APP 要在特定时刻必须完成哪些工作，如非必须，延后执行或直接省去。
• 优化：优化 APP 的功能实现，用更有效率的方式。
• 合并：如非立刻获取，则延后合并执行，比如合并网络请求。
• 减少：在满足需求的基础上，尽量减少做重复工作的频率。

 

耗电大户：

• 网络：数据传输越多，请求越多，耗电也就越多。
• 定位：定位精度越高，定位时间越长，耗电也就越多。
• CPU：APP 做的每件事几乎都需要用 CPU，所以 CPU 是电能消耗大户。
• GPU：每次更新到屏幕上都需要消耗电能处理像素信息，特别是动画或视频，所以 UI 不可见时，应避免更新其内容。
• 传感器和蓝牙：动作数据更新、蓝牙活动频繁都会很耗电。

以上参考：https://www.jianshu.com/p/bd2c1ce5c02a

 

测试工具：Sysdiagnose

Sysdiagnose 是苹果的日志系统，苹果经常会询问是否要官方帮忙诊断和定位各种问题，使用的就是 Sysdiagnose 的日志。

 

Sysdiagnose 能获取到哪些数据？

Sysdiagnose 很庞大，记录电池、第三方 APP、各种系统功能和应用的所有运行情况。通过 Sysdiagnose 可以获取电量消耗，电压，电流，温度，甚至系统的 CPU、GPU 等耗电都有详细的数据。

 

Sysdiagnose 只能获取自己的 APP 数据吗？

除了自己的 App，也可以获取到其它 APP 的数据，这样更方便对比测试。

 

Sysdiagnose 的数据靠谱儿吗？

都是苹果系统的数据，可靠性高。

 

如何使用 Sysdiagnose 进行耗电测试？

STEP 1. 下载证书：用开发者账号登录苹果开发者官网，在「 Profiles and Logs 」页面下载 「BatteryLife」 的 「Profile」。

STEP 2. 安装证书：将证书隔空投送到手机，安装之后，手机无需越狱也可以获得数据。

STEP 3. 准备工作：

• 手机先充电到 80% 以上，拔线之后静置 10分钟；
• 然后将屏幕亮度调到最低、关闭蓝牙、关闭消息推送、音量最低、关闭个人热点、关闭后台进程，开启定位（按需）；

STEP 4. 执行测试：但需注意：

• 若是对比测试，两次的初始电量应保持一致；
• 记录每个场景的开始和结束的时间，场景之间间隔 1分钟，每个场景的操作时间也要固定； 

STEP 5. 同步数据：测试结束后，手机静置约半小时（因为写入数据库会有延迟），然后手机连接电脑，同步数据；

如下图所示：

STEP 6. 打开设备日志文件夹：

• macOS：/Library/Logs/CrashReporter/MobileDevice/[设备名]/
• Windows：C:\Users[用户名]\AppData\Roaming\Apple Computer\Logs\CrashReporter\MobileDevice\[设备名]\

STEP 7. 找到数据文件：文件格式以 powerlog 开头，以 .PLSQL 或 .PLSQL.gz 结尾。

STEP 8. 找到数据表：用 DB Browser for SQLite 打开 powerlog 文件，切换到「浏览数据」，找到 PLBatteryAgent_EventBackward_Battery 表。

STEP 9. 分析 PLBatteryAgent_EventBackward_Battery 表。

 

此表记录整机的电量数据，包括电流、电压和温度，每20秒一条数据：

说明：

• 表中第二列 timestamp 是时间戳 ，是每行电池状况记录的时间点。
• 表中第四列 Rawlevel 是对应时间点的电量值。
• 通过测试场景开始和结束的具体时间点，找到对应的 Rawlevel，并计算差值，即可计算出该测试场景的耗电量精确数据。

言论

1、领导说「辛苦了」，你该怎么回答？

我记得有人说过：辛苦就对了，至少证明我还活着。

 

2、全都是套路...

3、...，行了吧！

任何话只要加上『行了吧』，都会让人火力程度提升 80%。

 

-- 来自网络

图片

1、可爱的设计

2、是

3、客户需求与实际产品，程序员：又不是不能用！

订阅

 

本周刊每周五发布，会同步更新在微信公众号。

 

微信搜索“毕小烦”或者扫描下面的二维码，即可订阅。

如果文章对你有帮助，请随手点个赞吧！

 

(完)