mirror of
https://github.com/zhwei820/learn.lianglianglee.com.git
synced 2025-09-27 05:36:42 +08:00
1271 lines
34 KiB
HTML
1271 lines
34 KiB
HTML
<!DOCTYPE html>
|
||
|
||
<!-- saved from url=(0046)https://kaiiiz.github.io/hexo-theme-book-demo/ -->
|
||
|
||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||
|
||
<head>
|
||
|
||
<head>
|
||
|
||
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
|
||
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1.0, user-scalable=no">
|
||
|
||
<link rel="icon" href="/static/favicon.png">
|
||
|
||
<title>32 软件测试:什么样的公司需要专职测试?.md.html</title>
|
||
|
||
<!-- Spectre.css framework -->
|
||
|
||
<link rel="stylesheet" href="/static/index.css">
|
||
|
||
<!-- theme css & js -->
|
||
|
||
<meta name="generator" content="Hexo 4.2.0">
|
||
|
||
</head>
|
||
|
||
|
||
|
||
<body>
|
||
|
||
|
||
|
||
<div class="book-container">
|
||
|
||
<div class="book-sidebar">
|
||
|
||
<div class="book-brand">
|
||
|
||
<a href="/">
|
||
|
||
<img src="/static/favicon.png">
|
||
|
||
<span>技术文章摘抄</span>
|
||
|
||
</a>
|
||
|
||
</div>
|
||
|
||
<div class="book-menu uncollapsible">
|
||
|
||
<ul class="uncollapsible">
|
||
|
||
<li><a href="/" class="current-tab">首页</a></li>
|
||
|
||
</ul>
|
||
|
||
|
||
|
||
<ul class="uncollapsible">
|
||
|
||
<li><a href="../">上一级</a></li>
|
||
|
||
</ul>
|
||
|
||
|
||
|
||
<ul class="uncollapsible">
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/00 开篇词 你为什么应该学好软件工程?.md.html">00 开篇词 你为什么应该学好软件工程?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/01 到底应该怎样理解软件工程?.md.html">01 到底应该怎样理解软件工程?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/02 工程思维:把每件事都当作一个项目来推进.md.html">02 工程思维:把每件事都当作一个项目来推进.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/03 瀑布模型:像工厂流水线一样把软件开发分层化.md.html">03 瀑布模型:像工厂流水线一样把软件开发分层化.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/04 瀑布模型之外,还有哪些开发模型?.md.html">04 瀑布模型之外,还有哪些开发模型?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/05 敏捷开发到底是想解决什么问题?.md.html">05 敏捷开发到底是想解决什么问题?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/06 大厂都在用哪些敏捷方法?(上).md.html">06 大厂都在用哪些敏捷方法?(上).md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/07 大厂都在用哪些敏捷方法?(下).md.html">07 大厂都在用哪些敏捷方法?(下).md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/08 怎样平衡软件质量与时间成本范围的关系?.md.html">08 怎样平衡软件质量与时间成本范围的关系?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/09 为什么软件工程项目普遍不重视可行性分析?.md.html">09 为什么软件工程项目普遍不重视可行性分析?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/10 如果你想技术转管理,先来试试管好一个项目.md.html">10 如果你想技术转管理,先来试试管好一个项目.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/11 项目计划:代码未动,计划先行.md.html">11 项目计划:代码未动,计划先行.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/12 流程和规范:红绿灯不是约束,而是用来提高效率.md.html">12 流程和规范:红绿灯不是约束,而是用来提高效率.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/13 白天开会,加班写代码的节奏怎么破?.md.html">13 白天开会,加班写代码的节奏怎么破?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/14 项目管理工具:一切管理问题,都应思考能否通过工具解决.md.html">14 项目管理工具:一切管理问题,都应思考能否通过工具解决.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/15 风险管理:不能盲目乐观,凡事都应该有B计划.md.html">15 风险管理:不能盲目乐观,凡事都应该有B计划.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/16 怎样才能写好项目文档?.md.html">16 怎样才能写好项目文档?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/17 需求分析到底要分析什么?怎么分析?.md.html">17 需求分析到底要分析什么?怎么分析?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/18 原型设计:如何用最小的代价完成产品特性?.md.html">18 原型设计:如何用最小的代价完成产品特性?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/19 作为程序员,你应该有产品意识.md.html">19 作为程序员,你应该有产品意识.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/20 如何应对让人头疼的需求变更问题?.md.html">20 如何应对让人头疼的需求变更问题?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/21 架构设计:普通程序员也能实现复杂系统?.md.html">21 架构设计:普通程序员也能实现复杂系统?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/22 如何为项目做好技术选型?.md.html">22 如何为项目做好技术选型?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/23 架构师:不想当架构师的程序员不是好程序员.md.html">23 架构师:不想当架构师的程序员不是好程序员.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/24 技术债务:是继续修修补补凑合着用,还是推翻重来?.md.html">24 技术债务:是继续修修补补凑合着用,还是推翻重来?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/25 有哪些方法可以提高开发效率?.md.html">25 有哪些方法可以提高开发效率?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/26 持续交付:如何做到随时发布新版本到生产环境?.md.html">26 持续交付:如何做到随时发布新版本到生产环境?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/27 软件工程师的核心竞争力是什么?(上).md.html">27 软件工程师的核心竞争力是什么?(上).md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/28 软件工程师的核心竞争力是什么?(下).md.html">28 软件工程师的核心竞争力是什么?(下).md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/29 自动化测试:如何把Bug杀死在摇篮里?.md.html">29 自动化测试:如何把Bug杀死在摇篮里?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/30 用好源代码管理工具,让你的协作更高效.md.html">30 用好源代码管理工具,让你的协作更高效.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/31 软件测试要为产品质量负责吗?.md.html">31 软件测试要为产品质量负责吗?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
<a class="current-tab" href="/专栏/软件工程之美/32 软件测试:什么样的公司需要专职测试?.md.html">32 软件测试:什么样的公司需要专职测试?.md.html</a>
|
||
|
||
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/33 测试工具:为什么不应该通过QQ微信邮件报Bug?.md.html">33 测试工具:为什么不应该通过QQ微信邮件报Bug?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/34 账号密码泄露成灾,应该怎样预防?.md.html">34 账号密码泄露成灾,应该怎样预防?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/35 版本发布:软件上线只是新的开始.md.html">35 版本发布:软件上线只是新的开始.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/36 DevOps工程师到底要做什么事情?.md.html">36 DevOps工程师到底要做什么事情?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/37 遇到线上故障,你和高手的差距在哪里?.md.html">37 遇到线上故障,你和高手的差距在哪里?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/38 日志管理:如何借助工具快速发现和定位产品问题 ?.md.html">38 日志管理:如何借助工具快速发现和定位产品问题 ?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/39 项目总结:做好项目复盘,把经验变成能力.md.html">39 项目总结:做好项目复盘,把经验变成能力.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/40 最佳实践:小团队如何应用软件工程?.md.html">40 最佳实践:小团队如何应用软件工程?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/41 为什么程序员的业余项目大多都死了?.md.html">41 为什么程序员的业余项目大多都死了?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/42 反面案例:盘点那些失败的软件项目.md.html">42 反面案例:盘点那些失败的软件项目.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/43 以VS Code为例,看大型开源项目是如何应用软件工程的?.md.html">43 以VS Code为例,看大型开源项目是如何应用软件工程的?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/44 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的?.md.html">44 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/45 从软件工程的角度看微服务、云计算、人工智能这些新技术.md.html">45 从软件工程的角度看微服务、云计算、人工智能这些新技术.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/一问一答第1期 30个软件开发常见问题解决策略.md.html">一问一答第1期 30个软件开发常见问题解决策略.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/一问一答第2期 30个软件开发常见问题解决策略.md.html">一问一答第2期 30个软件开发常见问题解决策略.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/一问一答第3期 18个软件开发常见问题解决策略.md.html">一问一答第3期 18个软件开发常见问题解决策略.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/一问一答第4期 14个软件开发常见问题解决策略.md.html">一问一答第4期 14个软件开发常见问题解决策略.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/一问一答第5期 22个软件开发常见问题解决策略.md.html">一问一答第5期 22个软件开发常见问题解决策略.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/学习攻略 怎样学好软件工程?.md.html">学习攻略 怎样学好软件工程?.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/特别放送 从软件工程的角度解读任正非的新年公开信.md.html">特别放送 从软件工程的角度解读任正非的新年公开信.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
|
||
|
||
|
||
<a href="/专栏/软件工程之美/结束语 万事皆项目,软件工程无处不在.md.html">结束语 万事皆项目,软件工程无处不在.md.html</a>
|
||
|
||
|
||
|
||
</li>
|
||
|
||
</ul>
|
||
|
||
|
||
|
||
</div>
|
||
|
||
</div>
|
||
|
||
|
||
|
||
<div class="sidebar-toggle" onclick="sidebar_toggle()" onmouseover="add_inner()" onmouseleave="remove_inner()">
|
||
|
||
<div class="sidebar-toggle-inner"></div>
|
||
|
||
</div>
|
||
|
||
|
||
|
||
<script>
|
||
|
||
function add_inner() {
|
||
|
||
let inner = document.querySelector('.sidebar-toggle-inner')
|
||
|
||
inner.classList.add('show')
|
||
|
||
}
|
||
|
||
|
||
|
||
function remove_inner() {
|
||
|
||
let inner = document.querySelector('.sidebar-toggle-inner')
|
||
|
||
inner.classList.remove('show')
|
||
|
||
}
|
||
|
||
|
||
|
||
function sidebar_toggle() {
|
||
|
||
let sidebar_toggle = document.querySelector('.sidebar-toggle')
|
||
|
||
let sidebar = document.querySelector('.book-sidebar')
|
||
|
||
let content = document.querySelector('.off-canvas-content')
|
||
|
||
if (sidebar_toggle.classList.contains('extend')) { // show
|
||
|
||
sidebar_toggle.classList.remove('extend')
|
||
|
||
sidebar.classList.remove('hide')
|
||
|
||
content.classList.remove('extend')
|
||
|
||
} else { // hide
|
||
|
||
sidebar_toggle.classList.add('extend')
|
||
|
||
sidebar.classList.add('hide')
|
||
|
||
content.classList.add('extend')
|
||
|
||
}
|
||
|
||
}
|
||
|
||
|
||
|
||
|
||
|
||
function open_sidebar() {
|
||
|
||
let sidebar = document.querySelector('.book-sidebar')
|
||
|
||
let overlay = document.querySelector('.off-canvas-overlay')
|
||
|
||
sidebar.classList.add('show')
|
||
|
||
overlay.classList.add('show')
|
||
|
||
}
|
||
|
||
function hide_canvas() {
|
||
|
||
let sidebar = document.querySelector('.book-sidebar')
|
||
|
||
let overlay = document.querySelector('.off-canvas-overlay')
|
||
|
||
sidebar.classList.remove('show')
|
||
|
||
overlay.classList.remove('show')
|
||
|
||
}
|
||
|
||
|
||
|
||
</script>
|
||
|
||
|
||
|
||
<div class="off-canvas-content">
|
||
|
||
<div class="columns">
|
||
|
||
<div class="column col-12 col-lg-12">
|
||
|
||
<div class="book-navbar">
|
||
|
||
<!-- For Responsive Layout -->
|
||
|
||
<header class="navbar">
|
||
|
||
<section class="navbar-section">
|
||
|
||
<a onclick="open_sidebar()">
|
||
|
||
<i class="icon icon-menu"></i>
|
||
|
||
</a>
|
||
|
||
</section>
|
||
|
||
</header>
|
||
|
||
</div>
|
||
|
||
<div class="book-content" style="max-width: 960px; margin: 0 auto;
|
||
|
||
overflow-x: auto;
|
||
|
||
overflow-y: hidden;">
|
||
|
||
<div class="book-post">
|
||
|
||
<p id="tip" align="center"></p>
|
||
|
||
<div><h1>32 软件测试:什么样的公司需要专职测试?</h1>
|
||
|
||
<p>你好,我是宝玉,我今天想与你讨论一下,什么样的公司需要专职测试这个问题。</p>
|
||
|
||
<p>若干年前,网络上对于软件开发是否需要专职测试有过一次讨论,代表文章有:左耳朵耗子老师写的<a href="http://coolshell.cn/articles/6994.html">我们需要专职的 QA 吗?</a>,然后邹欣老师对此回复<a href="http://coolshell.cn/articles/6994.html">测试 QA 的角色和分工</a>。</p>
|
||
|
||
<p>从这些年业界发展趋势来看,看起来很多公司都不需要专职测试了,只需要开发兼任测试工作就可以了。比如,Facebook 号称自己没有专职测试工程师,Google 和 Amazon 虽然有专职的测试工程师,但都是开发人员对质量负责,开发人员写大量的自动化测试代码。但这样真的可行吗?</p>
|
||
|
||
<p>在回答这个问题之前,我们还是先来看看,软件测试的主要工作是什么?只有搞清楚软件测试的工作,才能搞清楚这部分工作是否可以由开发来替代,是否需要专职测试。</p>
|
||
|
||
<h2>软件测试的主要工作是什么?</h2>
|
||
|
||
<p>在前面开发篇内容的学习中,我们对开发的工作已经比较了解了:在需求确定后,开发人员开始针对需求进行架构设计,然后编码,最后对发现的 Bug 进行修复,保障线上稳定运行。</p>
|
||
|
||
<p>而软件测试也类似,也是从需求开始,在需求确定后要去对需求进行分析,然后做测试设计。</p>
|
||
|
||
<p>如果说架构设计是对业务需求在技术方面的抽象,那么测试设计更像是对业务需求的具象,把业务需求分解成一个个具体的用户操作步骤,也就是测试用例。然后在开发完成后,按照设计好的测试用例进行逐一的测试验证,将发现的 Bug 报告给开发人员,并跟踪 Bug 的修复。</p>
|
||
|
||
<p>如果对软件测试的工作简单总结一下,就是发现 Bug,报告 Bug,跟踪 Bug。</p>
|
||
|
||
<h4>软件测试怎么发现 Bug?</h4>
|
||
|
||
<p>这里面最难的就是发现 Bug,尤其是如何尽早、尽可能全面地发现 Bug。</p>
|
||
|
||
<p>举个例子来说,如果现在你需要开发一个用户登录的功能,你在开发完成后会怎么测试?</p>
|
||
|
||
<p>一个普通的程序员通常只会简单测试一下以下用例:</p>
|
||
|
||
<ul>
|
||
|
||
<li>输入正确的用户名、密码,能登录;</li>
|
||
|
||
<li>输入错误的用户名密码,提示错误,不能登录。</li>
|
||
|
||
</ul>
|
||
|
||
<p>而一个有经验的程序员还会测试一下其他情况,例如:</p>
|
||
|
||
<ul>
|
||
|
||
<li>用户名或者密码为空,是否提示错误;</li>
|
||
|
||
<li>没有注册的用户名和密码,是否会提示错误。</li>
|
||
|
||
</ul>
|
||
|
||
<p>但如果是一个专业的测试人员来测试,是不是只做上面的测试就够了呢?专业测试还会测试哪些内容呢?</p>
|
||
|
||
<p>对于专业测试人员来说,上面这些肯定是不够的,还需要有以下这些情况的功能性测试:</p>
|
||
|
||
<ul>
|
||
|
||
<li>
|
||
|
||
<p>用户名密码是否大小写敏感;</p>
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
<p>用户名或密码如果是用特殊字符,会不会导致程序异常;</p>
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
<p>用户名或密码如果特别长,是不是会有异常;</p>
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
<p>是不是所有主流浏览器和终端设备都能使用。</p>
|
||
|
||
</li>
|
||
|
||
</ul>
|
||
|
||
<p>这就完了吗?并没有。除了功能性的测试,还需要进行非功能性的测试,也就是像性能、安全性和用户体验等方面的测试。比如以下测试用例:</p>
|
||
|
||
<ul>
|
||
|
||
<li>
|
||
|
||
<p>是否可以通过发送数据包反复登录,暴力破解密码;</p>
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
<p>会不会有 Sql 注入的风险;</p>
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
<p>大量用户同时登录,页面会不会崩溃;</p>
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
<p>用键盘 tab、回车键是否可以操作。</p>
|
||
|
||
</li>
|
||
|
||
</ul>
|
||
|
||
<p>当然还会有其他测试用例,这里就不一一列举。为什么专业测试人员和开发人员的测试用例会差这么多?</p>
|
||
|
||
<p>因为开发人员的重点,是放在如何实现功能上,就拿上面用户登录的例子,开发人员会想着如何能校验用户输入的用户名密码,并给出相应的提示,对于异常流程和场景会相对考虑较少。</p>
|
||
|
||
<p>而对于测试人员来说,重点是在检测,也就是会考虑所有可能的用户使用场景,正常的、异常的,甚至各种极端情况,例如大量并发访问、黑客恶意破解,所以他们能想到更多、更全面的测试用例。</p>
|
||
|
||
<p>测试人员设计测试用例,就是要尽可能做到覆盖所有用户操作的可能,但理论上来说这是不可能的,因为组合是有无限多个的。不过从测试的角度看,没有必要每一个可能都去测试,可以通过一些科学的方法来通过有限的测试用例,保证尽可能多的测试覆盖。</p>
|
||
|
||
<p>有哪些方法呢?我给你举几个例子:</p>
|
||
|
||
<ul>
|
||
|
||
<li>等价类划分</li>
|
||
|
||
</ul>
|
||
|
||
<p>就是把所有用户可能输入的数据分类,如果一类数据对于发现 Bug 的效果是一样的,那么这类数据就是一个等价类,测试的时候只要从里面任意选取一个值就好了。比如一个输入框要求只能输入 1-100 之间的整数,那么 1 到 100 之间都是等价的,0 和任意负数也是等价的,101 和之上的整数也是等价的。</p>
|
||
|
||
<p>因为分类是有限的,这样就可以用有限的测试用例实现尽可能多的测试覆盖。</p>
|
||
|
||
<ul>
|
||
|
||
<li>边界值分析</li>
|
||
|
||
</ul>
|
||
|
||
<p>边界值是对等价类的补充,因为输入输出的边界是非常容易出错的一个地方。比如说上面输入框的例子,0,1,100,101 都是边界值,可以设计用例来测试是否会有可能出错。</p>
|
||
|
||
<ul>
|
||
|
||
<li>探索性测试</li>
|
||
|
||
</ul>
|
||
|
||
<p>探索性测试就是根据前面的测试结果,通过有效的策略进行测试。</p>
|
||
|
||
<p>举例来说,如果你玩过 RPG 游戏的话,里面通常会有走迷宫的地图,各种分叉,不同的分叉可能有不用的宝箱,如果你想打开所有的宝箱,那么就可以在遇到分叉的时候,每次优先走右边的分叉,除非右边已经去过了。</p>
|
||
|
||
<p>那么这里“右边的分叉是不是走过了”,就属于已经测试过的结果,策略就是优先走右边的分叉。关于探索性测试的介绍可以参考这篇文章《探索性测试揭秘》。</p>
|
||
|
||
<p>当然除了以上这几个主要的策略,还有很多其他的策略,比如说:</p>
|
||
|
||
<ul>
|
||
|
||
<li>
|
||
|
||
<p>场景设计;</p>
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
<p>因果图;</p>
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
<p>错误推测法。</p>
|
||
|
||
</li>
|
||
|
||
</ul>
|
||
|
||
<p>这里我就不一一介绍,推荐阅读《微软的软件测试之道》,这本书上有很多具体的测试方法的详细介绍。</p>
|
||
|
||
<p>借助这些方法,测试人员就可以对需求功能设计出完整的、有较高覆盖率的测试用例。</p>
|
||
|
||
<p>所以,有时候测试人员的工作看起来不过是用鼠标点点测试,但他们在拿到需求后,其实花了很多时间和精力分析需求,然后根据需求设计测试用例,准备测试数据。等到开发人员完成软件开发后,就按照设计好的测试用例逐一测试,这样就可以做到及时发现 Bug。</p>
|
||
|
||
<h4>软件测试怎么报告 Bug?</h4>
|
||
|
||
<p>在测试的过程中,如果测试人员发现了 Bug,就会通过 Bug 跟踪系统提交 Bug 给开发人员。Bug 跟踪系统其实跟我们在《14 项目管理工具:一切管理问题,都应思考能否通过工具解决》中介绍的任务跟踪系统是一样的,它可以方便地提交和跟踪 Bug。</p>
|
||
|
||
<p>测试人员要做的就是创建一个新的 Ticket,在 Ticket 的描述中,详细说明 Bug 是什么,具体的重现步骤,必要的话还要附上截图、日志等辅助信息。这样开发人员在收到 Bug 后就能快速定位问题,按照优先级对 Bug 进行修复。</p>
|
||
|
||
<h4>软件测试怎么跟踪 Bug?</h4>
|
||
|
||
<p>Bug 的跟踪,并不仅仅是要跟踪开发人员什么时候修复了这个 Bug,通常还包括对 Bug 修复的验证。</p>
|
||
|
||
<p>开发人员修复完一个 Bug 后,测试人员首先会验证这个 Bug 是不是真的被修复了,然后还要对整体功能做一个回归测试,确保不会因为修复 Bug 而引起其他功能出现问题。</p>
|
||
|
||
<p>回归测试是指修改了旧代码后重新进行测试,以确认修改没有引入新的错误或导致其他代码产生错误。</p>
|
||
|
||
<p>回归测试这一步很重要,因为通常开发人员在修复完 Bug 后,只会验证其修复的 Bug,而不会验证其他功能是不是会有影响。但实际上,软件项目中经常会出现修复一个 Bug,而导致系统其他功能出现问题的情况。回归测试,则能有效、及时地发现修复 Bug 导致系统不稳定的情况。</p>
|
||
|
||
<h2>什么样的公司需要专职测试?</h2>
|
||
|
||
<p>了解了测试的主要工作内容之后,我们再回过头来看看今天要讨论的问题:什么样的公司需要专职测试。</p>
|
||
|
||
<p>如果一个公司不需要专职测试,那么意味着专职测试的工作可以被其他工种替代,比如说由开发人员一起完成软件测试的工作。</p>
|
||
|
||
<p>想象一下,如果你是一名开发工程师,然后你要兼职做测试,那么你需要额外做好哪些工作?</p>
|
||
|
||
<p>首先,你在拿到需求后,除了做技术上的设计外,还需要做测试上的设计,借助测试方法设计测试用例。</p>
|
||
|
||
<p>这样做好处很明显,可以在写程序时,让程序更易于测试,设计时会对需求考虑更全面。缺点也显而易见,你不止要学习编程知识、了解业务,还要学习测试方法。也许对你来说可以做到,但是对于绝大多数开发人员来说,这是一个很高的要求。</p>
|
||
|
||
<p>然后在开发完成后,要对自己写的程序进行测试。这里可能存在一个问题,也就是如果你在程序实现的时候,漏掉了一个逻辑处理,比如说漏了检测 Sql 注入,那么你在测试的时候也不会想到要去测试这部分。</p>
|
||
|
||
<p>测试自己的程序还要克服一个心理障碍,就是要对自己的程序进行破坏性测试,才可能找到潜在的问题,但去“破坏”自己完美的程序,对大多数开发人员来说也是很难接受的一件事。</p>
|
||
|
||
<p>如果上面两个问题都能克服,你还得再考虑一个问题:如果项目进度比较吃紧,作为开发人员你会压缩哪部分时间?</p>
|
||
|
||
<p>正常来讲,测试时间必然要被压缩的,因为你首先得保证代码实现。这可能就导致只要项目进度一紧张,测试就被严重压缩了,进而会严重影响质量。</p>
|
||
|
||
<p>这样看来,完全由开发人员兼职测试,还是很有难度的,不仅对开发人员要求非常高,而且需要开发人员承担所有的开发和测试的压力。</p>
|
||
|
||
<h4>为什么 Facebook 可以做到没有专职测试呢?</h4>
|
||
|
||
<p>首先 Facebook 的工程师水平确实是高于业界平均水平的,有能力同时做好开发和部分测试工作;</p>
|
||
|
||
<p>其次,Facebook 的产品周期相对宽松,可以有时间完成自动化测试代码;</p>
|
||
|
||
<p>Facebook 在功能发布之前,先发布新功能到内部环境,几千内部员工先测试,部分充当了测试人员角色;</p>
|
||
|
||
<p>Facebook 的发布和监控也比较完善,有问题能通过监控及时发现,并且可以随时快速回滚或者发布补丁;</p>
|
||
|
||
<p>最后就是用户对这类社交产品的 Bug 相对容忍度比较高,想想看如果是波音飞机上的软件能这么做吗?</p>
|
||
|
||
<p>至于 Google 和 Amazon 这些公司,他们也是类似的情况:</p>
|
||
|
||
<ul>
|
||
|
||
<li>
|
||
|
||
<p>大量优秀的工程师,可以同时兼任开发和测试;</p>
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
<p>有大量的自动化测试代码覆盖;</p>
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
<p>强大的发布和监控系统;</p>
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
<p>时间进度比较宽松;</p>
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
<p>用户对 Bug 容忍度较高。</p>
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
<p>对于不能满足上面条件的公司,有专职的测试是更有利于软件项目开发和质量保障的。</p>
|
||
|
||
</li>
|
||
|
||
</ul>
|
||
|
||
<h4>大厂不设专职测试的启示</h4>
|
||
|
||
<p>虽然对于大部分公司来说,要做到完全没有专职测试还不现实,但这些大厂不设专职测试的实践还是有值得借鉴和思考的地方。</p>
|
||
|
||
<p>首先,用自动化测试代替重复性的手工测试是必然趋势。随着自动化测试技术的成熟,写自动化测试代码的成本逐步降低,而自动化测试,可以极大提高测试效率,尤其是像回归测试这种需要频繁进行的。</p>
|
||
|
||
<p>其次,测试设计是软件测试人员的核心竞争力。无论是自动化测试还是手工测试,测试用例是核心。无效的测试用例,用任何方法去测试,都不会达到良好的测试目的,只有测试用例设计好了,真正做到有效高覆盖,测试才是高质量的。</p>
|
||
|
||
<p>最后,开发人员和测试人员的更多融合是一种双赢。比如说测试人员可以给开发人员提供测试用例作为测试参考,开发人员可以写更多自动化测试代码,这些方式都能有效保障产品质量。</p>
|
||
|
||
<h2>总结</h2>
|
||
|
||
<p>今天我带你一起分析了什么样的公司需要专职测试。同时也学习了软件测试的一些基本知识,简单来说软件测试的工作,就是发现 Bug,报告 Bug,跟踪 Bug。</p>
|
||
|
||
<p>要能及时发现 Bug,需要针对需求进行分析和测试设计,把需求具象成一个个用户操作步骤的测试用例。通过一些科学的测试方法,像等价类划分、边界值分析、探索性测试,能有效提升测试的覆盖率。</p>
|
||
|
||
<p>公司是否需要专职测试,还是取决于公司的具体情况,例如是否有大量优秀的工程师可以同时兼任开发和测试,有大量的自动化测试代码覆盖,有强大的发布和监控系统,时间进度宽松,用户对 Bug 容忍度较高。</p>
|
||
|
||
</div>
|
||
|
||
</div>
|
||
|
||
<div>
|
||
|
||
<div style="float: left">
|
||
|
||
<a href="/专栏/软件工程之美/31 软件测试要为产品质量负责吗?.md.html">上一页</a>
|
||
|
||
</div>
|
||
|
||
<div style="float: right">
|
||
|
||
<a href="/专栏/软件工程之美/33 测试工具:为什么不应该通过QQ微信邮件报Bug?.md.html">下一页</a>
|
||
|
||
</div>
|
||
|
||
</div>
|
||
|
||
|
||
|
||
</div>
|
||
|
||
</div>
|
||
|
||
</div>
|
||
|
||
</div>
|
||
|
||
|
||
|
||
<a class="off-canvas-overlay" onclick="hide_canvas()"></a>
|
||
|
||
</div>
|
||
|
||
<script defer src="https://static.cloudflareinsights.com/beacon.min.js/v652eace1692a40cfa3763df669d7439c1639079717194" integrity="sha512-Gi7xpJR8tSkrpF7aordPZQlW2DLtzUlZcumS8dMQjwDHEnw9I7ZLyiOj/6tZStRBGtGgN6ceN6cMH8z7etPGlw==" data-cf-beacon='{"rayId":"70997c82ec343cfa","version":"2021.12.0","r":1,"token":"1f5d475227ce4f0089a7cff1ab17c0f5","si":100}' crossorigin="anonymous"></script>
|
||
|
||
</body>
|
||
|
||
<!-- Global site tag (gtag.js) - Google Analytics -->
|
||
|
||
<script async src="https://www.googletagmanager.com/gtag/js?id=G-NPSEEVD756"></script>
|
||
|
||
<script>
|
||
|
||
window.dataLayer = window.dataLayer || [];
|
||
|
||
|
||
|
||
function gtag() {
|
||
|
||
dataLayer.push(arguments);
|
||
|
||
}
|
||
|
||
|
||
|
||
gtag('js', new Date());
|
||
|
||
gtag('config', 'G-NPSEEVD756');
|
||
|
||
var path = window.location.pathname
|
||
|
||
var cookie = getCookie("lastPath");
|
||
|
||
console.log(path)
|
||
|
||
if (path.replace("/", "") === "") {
|
||
|
||
if (cookie.replace("/", "") !== "") {
|
||
|
||
console.log(cookie)
|
||
|
||
document.getElementById("tip").innerHTML = "<a href='" + cookie + "'>跳转到上次进度</a>"
|
||
|
||
}
|
||
|
||
} else {
|
||
|
||
setCookie("lastPath", path)
|
||
|
||
}
|
||
|
||
|
||
|
||
function setCookie(cname, cvalue) {
|
||
|
||
var d = new Date();
|
||
|
||
d.setTime(d.getTime() + (180 * 24 * 60 * 60 * 1000));
|
||
|
||
var expires = "expires=" + d.toGMTString();
|
||
|
||
document.cookie = cname + "=" + cvalue + "; " + expires + ";path = /";
|
||
|
||
}
|
||
|
||
|
||
|
||
function getCookie(cname) {
|
||
|
||
var name = cname + "=";
|
||
|
||
var ca = document.cookie.split(';');
|
||
|
||
for (var i = 0; i < ca.length; i++) {
|
||
|
||
var c = ca[i].trim();
|
||
|
||
if (c.indexOf(name) === 0) return c.substring(name.length, c.length);
|
||
|
||
}
|
||
|
||
return "";
|
||
|
||
}
|
||
|
||
|
||
|
||
</script>
|
||
|
||
|
||
|
||
</html>
|
||
|